Skip to main content

Celonis Product Documentation

Configuring variable Administrator permissions

Historically the role of the administrator had complete control and wasn't configurable and only admins could access features within Admin and Settings. This results in a key person dependency that isn't scalable or secure for enterprise organizations. Eg - One person shouldn't have complete control end to end. This help page will tell you how you can configure Admin and Settings features differently by User.

  • Changing what a user can access within Admin and Settings (Which menu items)

  • Configuring different levels of Admin role permissions.

Problem

A user given the role of Admin on our EMS platform has the authority to control everything, essentially, all-powerful. For many customers, this role type doesn’t provide the flexibility they need. Customers need varying levels of capability within the admin role, such as An Admin who can manage users but not set permissions and vice versa.

Solution

Create selectable permissions checkboxes for each of the features found in Admin and Settings that can be applied to the role of Analyst, thus creating flexibility in what a user can do within Admin and Settings.

How to

Create the ability to enable and disable Admin and Settings menu items by role (Analyst) and the user allowing for full permissions flexibility.

Below shows the potential roles that can be created.

Note

All roles will use the Analyst profile as the base. The existing Admin will remain with the existing permissions authority.

User Admin

A role that can manage users but not set content permissions.

Content Admin

A role that can only manage service permissions.

Systems Admin

A role who can manage SSO, IP restrictions, and system-related features only.

Super Admin

The existing admin role has complete authority.

41196608.png
Creating new admin roles use-case

As a Platform Admin, I want to create a lower authority admin role that can only manage users (Invite, Lock and Remove) = User Admin

  • All customers should have this feature available. If not please contact the Service Desk.

  • Select the user from Members and ensure their role is Analyst.

  • If Admin is selected they will maintain complete authority.

  • Ensure they are not in a group with Admin authority otherwise, they will maintain complete control.

  • Go to Permissions, find Team permissions, and select Edit (These are the permissions related to Admin and Settings)

  • Select the user or group (if more than one user) you wish to make a user admin.

  • Click on the template dropdown and select User Admin profile.

  • Double-check the correct checkboxes are ticked. If not select what is needed and create a custom template.

  • Double-check the relevant service level permissions such as Studio, Process Analytics to ensure those permissions don’t breach that of the role.

Considerations
  • Service Level Permissions: Unlike CPM4, EMS is a multi-service platform. Each service has its own permissions structure meaning the admin must check both Admin and Settings permissions and the service level to ensure the likes of a User Admin doesn’t have service level permissions allowing to delete a workspace or analysis.

  • Expanding the Analyst role: The new Admin and Settings permissions configurations are based on the Analyst role. Eg - To create a User Admin you would start with the analyst role and add the relevant checkboxes to create the User Admin profile. The role never becomes a true Admin since that role remains all-powerful.

  • Admin and Settings Menus items: Each team settings menu item has its own checkbox. Once selected that menu itemonlywill become available to the user. This means Analysts will now have access to Admin and Settings based on the checkboxes.

  • Self-assigning permissions: We are ensuring that it is not possible for a user with the role of Analyst to upgrade themselves to Admin or downgrade existing admins. Nor will they be able to add additional Admin and Settings checkbox items to their profile.

Re-cap on what has changed
  • The old process allowed a customer to set three types of roles - Admin, Analyst and Member. The admin is the only role that enabled the Admin and Settings service (other roles can't see this service). The admin has complete authority over the whole Team (They can do and see everything)

  • The role of Admin can also be granted as a group even if not granted as a member. This means a user who has analyst or member-only access could end up with Admin access if added to a group with the role set to Admin (It's important to ensure this doesn't happen. Upcoming features will look to clarify these scenarios more clearly)

  • Given that the analyst role already has the most flexibility. Eg - An analyst can have no authority essentially replicating a Member if nothing is provided or full view, edit, delete and create authority if granted. Therefore, the analyst role is a great foundation for creating variability within the Admin and Settings service.

  • It is now possible to select and allocate each and every menu item within Admin and Settings, thus creating the ability to give analysts a pseudo admin profile (As determined by the real Admin's).

  • This feature allows a customer to divide out administration duties without the need to give the user a full Admin profile. Note: The Admin role remains the same, no changes have been made to this role)

  • What this means is that a customer can now give people the authority to just invite members, even without having access to content. The only thing the user, in this case, can do is manage Members by having access to just the Members page within Admin and Settings.

  • This feature gives customers far more flexibility in allocating Admin and Settings features.

  • With Authority comes Responsibility. It becomes very important to ensure the wrong people are not given access to Admin features much the same as being careful not to invite the wrong people to Groups with admin authority (Future features will help identify who has what permissions beyond the current CSV extract)

  • Risk mitigation has been built into this process that prevents an Analyst with Admin features from upgrading their profile or downgrading existing Admins.