Roles and user management
- Updated: 2025/01/12
Assign roles to users to ensure they have appropriate access based on their responsibilities. This helps strengthen security, streamline workflows, and maintain accountability within the organization. To interact (create, edit, view, delete) with a dashboard in CoE Manager, you must have a role that has permission to access the dashboard.
You can enforce role-based access control (RBAC) in CoE Manager to enable users to access specific features based on the assigned roles and the accessibility provided to them. The benefits of creating roles include:
- Increased security by controlling users access according to their specified roles. This helps protect data from unauthorized access.
- Ability to create user roles based on the organization's requirements. This helps eliminate ambiguity and reduces errors and conflicts, enabling teams to work more efficiently.
- As teams grow, RBAC makes it easier to onboard new users.
To access and manage various pages and options in CoE Manager, users must be assigned a role with the appropriate permissions. Permissions are inherited downward, meaning a user assigned to a role on a page or option will also have access to all its descendant pages. The user's default access level for a page and its options is determined by their role assignment. Each role corresponds to one of three access levels: Admin, Edit, or View.
The following table identifies the roles and their associated access levels.
Role | Access level | Manage roles | Read | Edit | Create | Copy | Move | Delete |
---|---|---|---|---|---|---|---|---|
Owner | Admin | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Sponsor | Admin | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Admin | Admin | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Collaborator | Edit | Yes | Yes | Yes | Yes | Yes | No | No |
Viewer | View | No | Yes | No | No | No | No | No |
The following table identifies the roles and their associated access levels for various dashboard pages.
Role | Dashboard | Read only dashboard | Opportunities | Ideas | Pipeline | Deployed | Admin-Program | Admin-Advanced | Admin-Tech | Admin-Developers | Admin-Users | History |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Admin | Yes | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Collaborator | Yes | No | Yes | Yes | Yes | Yes | No | No | No | No | No | No |
Owner | Yes | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Sponsor | Yes | No | Yes | Yes | Yes | Yes | No | No | No | No | No | No |
Viewer | Yes | No | Yes | Yes | Yes | Yes | No | No | No | No | No | No |
Dashboard viewer | No | Yes | No | No | No | No | No | No | No | No | No | No |
The following table identifies the roles and their associated access levels for the options in the opportunity page.
Role | Opportunity summary | Details | Activities | Execution tracking | Transaction tracking | Workflow | Change request | History |
---|---|---|---|---|---|---|---|---|
Admin | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Collaborator | Yes | Yes | Yes | Yes | Yes | No | Yes | No |
Owner | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Sponsor | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Viewer | Yes | Yes | Yes | Yes | Yes | No | No | No |
Keep the following considerations in mind while assigning roles:
- The access level defines the default permission for the role on a particular page. With additional configuration logic; however, the admin can further restrict permissions. For example, the admin can define page visibility logic allowing only users holding the finance team role to see the finance page. Even though users hold other roles with admin access level, if they do not hold the finance team role, they will not see the page.
- Roles are multi-user. There is no limit on the number of users that can be assigned to a role.
- Users can be assigned to multiple roles on a single work page.
- When a user holds multiple roles, the default access level for the user will be the highest level of their assigned roles. This logic applies to inherited roles as well. For example, if a user is assigned an admin access level role at the program level and then assigned an edit access level role to a descendent project within the program, the default access level for the user on the project will be the admin access level.