Skip to main content

Celonis Product Documentation

Permission Management Overview

The Execution Management System provides a comprehensive permission management system that allows defining permissions on the member level or on the role level in a coarse or granular fashion.

This document will explain the different granularities (application, container, or object), and how groups can be used to achieve role-based access control (RBAC). Finally, we will showcase frequent setups.

Permission granularities

Permissions can be set in coarse, medium, and fine granularity.

  • Coarse would correspond to application-level permissions.

  • Medium would correspond to container-level permissions.

  • Fine would correspond to object-level permissions

An application such as Process Analytics uses containers to organize its objects.

The objects live inside these containers:

30999614.png

Process Analytics, containers are called Workspaces and objects are the Analyses.

In Data Integration, containers are called Data Pools and objects are referred to as Data Models.

For instance, you might want to award a group of members to administrate all data models via "EDIT ALL DATAPOOLS".

Application Level

Permissions on the application level are only available for team admins, and thus accessible in Admin and Settings

They can define which groups or members are awarded general permissions to do anything inside containers or objects.

30999613.png

Container level

Permissions on the container level are awarded via the context menu on the container (the three dots).

These container-level settings are documented on each application page:

30999615.png

Object Level

Permissions on the object level are set on the object itself, via the context menu (the three dots).

30999616.png

Role-Based Access Control

Role-Based Access Control, or RBAC for short, allows defining a set of roles.

These roles are awarded permissions to perform certain actions.

Users can have one or more roles, and authorized by their role can then perform simple actions.

This setup has a huge advantage: It scales since individual permissions become obsolete.

Roles in the EMS

The user part of the EMS licensing model has two parts: a members and an analyst limit.

Anybody who is a team member has to have one of the three following roles:

Member - view content depending on permissions

Analyst - create / view / edit / delete content depending on permissions

Admin - create / view / edit / delete all content and administrate the team

All team members count towards the member limit, while analysts and admins also count toward the analyst limit.

Pay close attention to terminology

In the EMS, the term role is used to highlight the level that a user has. This has license reasons. Please see to the right what the user roles are.

It is not to be confused with the roles that you define to be used by your team members.

RBAC in the EMS is achieved via groups which you can regard as roles in the traditional sense

Example setups

These examples showcase a few RBAC setups, using Groups to realize the role.

Example setup 1

Desired state: There should be two different projects. Nobody in one project should be able to see or use anything from the other project. A project in this context could also mean a department or subsidiary.

Role Name

Role Description

Viewer

This role should only allow viewing content.

Analyst

This role can do all of the above, plus edit and create content.

No access to anything else though.

Data Engineer

This role can do all of the above, plus manage the data pipeline.

Admin

This role can do all of the above, plus manage team-wide settings and permissions

How to realize this in the EMS: The roles are implemented as groups in the EMS. The admin role permits seeing and manipulating everything inside a team. It does not make a lot of sense to have an administrator who can change settings that affect the whole team, but who can only see half of the content.

Role name

Group name

Group role

Group Permissions

Project1_Viewers

Viewer

Process Analytics - Project 1 Workspace:

USE ALL

Project1_Analysts

Analyst

Process Analytics - Project 1 Workspace:

CREATE ANALYSES EDIT ALL ANALYSES EDIT WORKSPACE DELETE ALL ANALYSES

Project1_DataEngineers

Analyst

Data Integration - Project 1 Data Pool:

USE ALL DATAMODELS ADMIN

DATA PUSH API

Process Analytics - Project 1 Workspace:

USE ALL

CREATE ANALYSES

EDIT ALL ANALYSES

EDIT WORKSPACE

DELETE ALL ANALYSES

Project2_Viewers

Viewer

Project 2 Workspace:

USE ALL

Project2_Analysts

Analyst

Project 1 Workspace:

CREATE ANALYSES EDIT ALL ANALYSES EDIT WORKSPACE DELETE ALL ANALYSES

Project2_DataEngineers

Analyst

Data Integration - Project 2 Data Pool:

USE ALL DATAMODELS ADMIN

DATA PUSH API

Process Analytics - Project 2 Workspace:

USE ALL

CREATE ANALYSES

EDIT ALL ANALYSES

EDIT WORKSPACE

DELETE ALL ANALYSES