Understanding Users, Roles, and Permissions
  • 22 Jun 2023
  • 5 Minutes To Read
  • Dark
    Light
  • PDF

Understanding Users, Roles, and Permissions

  • Dark
    Light
  • PDF

Article summary

A user is anyone who accesses and uses Mambu via the UI or the API. Users are assigned permissions which determine the information they can access and the tasks they can perform. Each permission has a name and covers one action or a small subset of action - for example VIEW_CLIENT_DETAILS. Permissions can be assigned to users either directly or through a role. A role is a way to group permissions and to control other forms of access within Mambu.

For more information about roles, see Roles. For a full list of permissions, see Permissions.

Please Note

Roles or permissions may also be assigned to API consumers and apply in the same way. For more information, see API Consumers.

A list of permissions

Assigning permissions to a user

You may choose to assign permissions to a user directly or they can be assigned through a role. You cannot do both. We recommend assigning permissions to users through roles because it allows for more control over access in Mambu. For more information, see Access managed by role.

Please Note

Some permissions may only be assigned to a role, and cannot be assigned directly to a user.

Permissions assigned directly to a user

You can assign permissions directly to the user either via the Mambu UI or API. For more information, see Creating a User - Permissions.

Permissions assigned through a role

To assign permissions to a user through a role, you have to both create a role and assign all the relevant permissions to it, and assign the role to the user. A user can only have one role.

Roles make it easier to add or remove permissions for multiple users as you only need to update the permission at the role level and not for each individual user who has been assigned a permission.

Access managed by role

There are activities and groups of information where access can only be managed by assigning a user a role instead of assigning a set of permissions directly to a user.

These instances can be split up into two main types. The first type when access is granted to users that have a specific role assigned to them which is irrespective of what permissions are assigned to the role itself. For more information, see Access granted to roles irrespective of assigned permissions.

The second type is when users are granted access provided that they have a specific role assigned to them and that this role has specific permissions assigned to it. For more information, see Access granted only to roles with appropriate permissions.

Access granted to roles irrespective of assigned permissions

In some cases, you grant access to specific pieces of information in Mambu using roles. In these cases, the access is granted to those roles irrespective of what permissions are assigned to them.

Custom fields example

For example, when you are working with custom fields there are two types of access that you can manage. One kind of access is to determine which users can view, create, edit, or delete custom field definitions. Another kind of access is to determine which users are able to manage custom field values for specific custom field definitions.

To assign a user the right to view, create, edit, or delete custom field definitions you have to assign the appropriate permissions to them either directly or through a role; for example, by assigning the EDIT_CUSTOM_FIELD permission.

However, to allow a user to enter a custom field value for a particular custom field definition when it appears in a form they have to have a specific role assigned to them and that role has to be selected in the Rights section of that particular custom field definition. The permissions assigned to the role are irrelevant in this case. The only way the user can have access to enter a custom field value is to have their role selected.

For more information about custom field permissions, see Custom field permissions and for more information about granting access to roles to manage custom field information, see Custom Fields - Rights section.

Access granted only to roles with appropriate permissions

In other cases, you have to assign appropriate permissions to a role and subsequently assign the role to a user for them to have access. Assigning permissions directly to a user will not work unless the option to grant access to all users is selected.

For example, access to view menu items with views is managed at the role level with specific permission assignment. If the All Users option is not chosen for the Clients menu item then in order for a user to see the Clients menu item the role assigned to them must have the VIEW_CLIENT_DETAILS permission assigned to it and the role has to be selected in the Usage Rights section of the menu item form. If either of these conditions is not met, the user will not have access. For more information, see Menu item types and permissions.

Guidelines for assigning roles and permissions

Administrators

Administrators have access to sensitive data and can do practically anything in Mambu. We recommend you have a minimum of two administrators for account management purposes. For example, an administrator can reset another administrator's password. In the case of an account lockout it is useful to have another administrator in your organization.

We recommend a maximum of four administrators in your organization for data security.

General permission assignment

We recommend assigning the least amount of access a user needs to get their job done, meaning the least permissive role or the least amount of permissions.

For example, if you want a user to manage users, roles, access preferences, and federated authentication, we do not recommend assigning the administrator user type. Instead, we recommend you create a role titled "access admin" and assign this role to the user.

Limiting role and user management permission assignment

Role and user management permissions allow a user to alter the access settings for other users as well as their own user in the system.

Please be Aware

For security reasons, we strongly recommend tightly controlling which users have these permissions.

User management permissions:

  • CREATE_USER
  • EDIT_USER
  • VIEW_USER_DETAILS
  • DELETE_USER

Role management permissions:

  • CREATE_ROLE
  • EDIT_ROLE
  • VIEW_ROLE
  • DELETE_ROLE

Was this article helpful?

What's Next