Scope of roles and permissions in Engage

The platform has two system-defined roles that cannot be deleted. Each enables different permissions and determines access to sections within Engage, depending on its scope.

In addition, users with the Administrator role can create and manage new roles, assigning them specific permissions according to the team's needs.

Default roles: 

1. User (default): Profile with a standard operational scope and access to the product's main functionality.
2. Administrator: Role with full capabilities, including operational, management, and user governance.

 The table below details the scope of each role, the enabled menu sections, and the permissions granted in each case.

 Key definitions:

✓ Role: a named set of permissions that determines which sections of the platform a user can access.

✓ Permission: full access to a specific section of the platform.

Role management applies only to the Administrator and enables:

1. Create a new role
   1. Role name (unique)
   2. Description (optional)
   3. Set of permissions (multiple selection from the catalog)
2. Edit an existing role: you can modify the name, description, and permissions fields.
3. Delete a role
   1. Only if it is not assigned to any user.
   2. Default roles cannot be deleted.
4. View role details
5. List of associated permissions.
6. Number of assigned users.
   1. Assign a role to a user (only one per user).
7. Change a user's role.
8. View a user's role in:
   1. User list.
   2. User detail view.

 In the Access Control section of Engage, you can perform all the necessary actions to manage each member of your team's profile who uses this platform. Learn more in the following article  Access Control in Engage.

 Principles and limitations:

1. One user = one role: each user can have only one role assigned.
2. Permissions:
   1. Each permission grants full access to a section. Permissions are not assigned at the field or functionality level.
   2. Access to a section enables all its functionalities.
3. The role defines access:
   1. Permissions are not assigned directly to individual users. Instead, a permission is created, then incorporated into a role, and finally, the role with the defined scope is granted to a user.
   2. There are no dynamic, conditional, or contextual permissions.
   3. Users inherit their permissions exclusively from the assigned role.
   4. There is no access control based on time, IP, or environment.

> Behavior rules:

1. Users only see the navigation items for the sections they have access to in the menu.
2. Changing a role immediately updates user permissions.
3. If a role loses a permission, users assigned to that role also lose it.
4. Removing a permission removes both visibility and access to the section.
5. A user without a role (invalid status) cannot access any section.

> Routing and APIs.

1. The backend validates permissions on each request.
2. Unauthorized access is handled as follows:
   1. UI: hidden or blocked section
   2. API: 403 Forbidden response