In the Admin module, ACL: Roles is where you manage roles. A role is a set of permissions given to a user or a whole department, so each person can reach only the functions their job needs. Use this section to review the preset roles, create your own, and control what each role can see and do.
Permissions
Access to ACL: Roles is granted by the AclAssign permission (Admin section), which opens the Permissions, Roles / Permissions, Users / Roles, and Users / Permissions submodules. Which roles have that permission is decided during implementation, usually the Administrator and Property/Asset Manager roles. Editing the privilege definitions themselves (adding, editing, or removing a permission) needs the separate AclDefine permission. The system does not grant this access by job title, so an administrator who is not given AclAssign cannot manage roles.
What a role is
A role bundles permissions together and assigns them to a user or a department, so users get exactly the access their position requires while the system stays secure. When you create a user, you choose their role; that choice sets the permissions attached to the user. One user can hold several roles at once.
Preset roles
Roles depend on your implementation, but every new instance comes with a set of ready-made roles:
Administrator has the highest level of access and can manage all aspects of the application.
Management oversees operations and makes strategic decisions based on data.
Property/Asset Manager manages properties and assets, ensuring their upkeep and value.
Reception handles front-desk operations, including guest management and basic administrative tasks.
Regional Manager manages properties and operations in a specific region or territory.
Support IT provides technical support and keeps the application running smoothly.
Technician (FM) handles facility management tasks, including repairs, maintenance, and inspections.
Role groups
Roles fall into three groups, and a role can only be assigned within its own group. You cannot give an internal role to a tenant or external-service user, or the other way round.
Internal roles – Administrator, Property/Asset Manager, Support IT, Technician (FM), and any new roles created by an administrator.
External Service – External Service, External Service - Admin, and an additional External Service role, assignable only to a user from an External Service company.
Tenant – Tenant, Tenant-admin, and Tenant-community, assignable only to a user from a Tenant company.
Create or copy a role
An administrator can create a new role to fit the implementation and copy the permissions from an existing role as a starting point. Existing roles cannot be deleted, so plan new roles before adding them. An administrator can also change which roles a user has, within the same role group.
See what a role can access
To see the exact permissions attached to a role, open the Roles / Permissions tab in the ACL: Roles submodule. It shows, role by role, what each one can access and change in the application. The Roles / Permissions tab lists role permissions only. Exceptions set on individual accounts do not appear there, and those exceptions win wherever they differ from the role. The permissions of one specific user are shown on the Users / Permissions tab.
Permissions set on a single user
Besides roles, Singu lets you set a permission directly on one person’s account, on the Users / Permissions tab in ACL: Roles. An entry there takes precedence over the role.
The exception works both ways. It can add a permission the role does not grant, and it can remove one the role does grant. Either way the individual entry decides and the role permission stops applying.
In practice this means a role with a permission switched on is no guarantee the user has it. When someone reports a missing button despite the correct role, check their account on Users / Permissions before looking anywhere else.
Exceptions are set by someone holding AclAssign, who also removes them so the account falls back to the permissions its role grants.
Permissions
Access to this section depends on the permission below. The first column is the Admin module section, the second is the permission name, and the third explains what it grants.
Admin module section | Permission name | Description |
|
| Grants access to the Permissions, Roles / Permissions, Users / Roles, and Users / Permissions submodules. |
|
| Define the privilege dictionary itself: add, edit, or remove a permission. This is separate from assigning roles. |
Frequently asked questions
Why can't I manage roles even though I'm an administrator?
You cannot manage roles without the AclAssign permission (Admin section), because access to ACL: Roles is driven entirely by permissions, not by the job title of your account. There is no automatic bypass for administrators. If you have lost access to the Permissions section, someone with the permission must grant AclAssign to your role to restore it.
Can I delete a role?
No, you cannot delete an existing role; role deletion is not available. You can create new roles and change which roles a user has, but old roles stay in the system. Because of this, plan a role before creating it, and if a role is no longer needed simply stop assigning it to users.
Why can't I assign a role to a user?
You cannot assign a role to a user when the role belongs to a different group than the user. Internal, External Service, and Tenant roles are kept separate: an internal role cannot be given to a tenant or external-service user, and vice versa. Check which company the user belongs to, then pick a role from the matching group. A user can still hold several roles from the same group.
How do I see what a role can do before assigning it?
To see what a role can do, open the Roles / Permissions tab in ACL: Roles, which lists the exact permissions for each role. Reviewing this first helps you pick the right preset role or decide which permissions to copy into a new one.
The role has the permission switched on, but the user still cannot see the function. Why?
A permission set directly on a user account takes precedence over the role and can remove it. The Roles / Permissions tab does not show those exceptions, so the role looks correct while the user does not actually hold the permission. Open the Users / Permissions tab, find the person, and check whether there is an individual entry against the permission in question. Removing that entry restores the permission from the role.