Implementing Authorization Objects to restrict users' viewer rights



My company has several subsidiaries and the data of all of them is loaded into Celonis. We want to grant analysts from all subsidiaries the ability to access analyses in Celonis, but we don’t want them to be able to see data that is related to any of the other subsidiaries.

To the best of my knowledge, the way to implement such a restriction via Authorization Objects, which can then be applied to specific users (i.e. analysts from the subsidiaries) in order to restrict their viewing rights. From the menu: “You can add authorization objects here which can be used to automatically filter the dataset users.”

I have taken a look at the sample “query-definitions.xml.sample” file in the installation folder, but it’s still unclear to me how the concept is supposed to function - either via “the values are manually entered below” or via “the values are queried from a database”.

The parts that I’m unsure about are:

  • “On this screen you can configure the source of the mappings either from a database or from manual input”. --> What is supposed to be mapped to what?

  • “To be able to use these objects, they have to be linked to a user and a data model, which is possible in the respective views.” --> Which views are meant here?

  • If choosing the manual option, how is the definition of possible values supposed to be formatted?

Any help would be very much appreciated! :slight_smile:

(Also, here are the sample query definitions.)



Hello Lars,

I believe the easiest way to do what you would like to do is to assign the user rights to the different folders directly. If you click on a folder, you can add user permissions on the upper right side of the new menu popping up.



Hello Henry,

thank you for your input!

Unfortunately, I don’t see how I could implement this solution without creating different data models for each folder - with each data model having a respective view restriction. Because of computational demands, this would be infeasible in our current situation.

Please let me know if I misunderstood you of if I can clarify some point :slight_smile:


Hello, @lars.mrtns

There are three options in Celonis to limit data access:

  1. Quick and dirty - create copies of your analysis, enter additional filters as part of load script and give different users/groups access to different analysis. Fast, but prone to typos in filters and costly to maintain if you have complex filter conditions or change analysis a lot. Does not require extra data model.
  2. Manual - Create authorisation object (query), attach it to data model, go to each user and specify allowed value(s) for the user. More robust then option 1, however you still have to do it on user by user basis
  3. Automated - same as manual, however allowed values for the users retrieve from the table in database (assuming you have this data somewhere in the source system).

I believe that @h.boeddeker was talking about option 1.



Thank you for the elaboration on the approaches! This is extremely helpful.

The only part that I still don’t understand (for approach 2. and 3.) is what the authorization object query is supposed to look like. What should the output of the query be? Should the query simply select the column in the activity table, which contains the values in dependence of which the data is filtered for the user?

Also, regarding the user mapping: what would the “USER_BUKRS_MAPPING” table that’s referenced in the sample config look like?

If I’m overlooking an explanation of these things in the documentation, please let me know. In any case, I’m thankful for you help :slight_smile:


Hi, Lars!

Documentation for authorisation objects is a … bit counterintuitive :scream:

Here is my step-by-step guide. Lets say you want to do option 2 and limit access by BUKRS:

  1. Create database source in system settings (pointing to the same place as your data model)
  2. Create authorisation object in admin GUI, name it, specify that you want to enter values manually for the user and values will come from databse. Choose data source created in previous step and specify query which will return all possible values. I.e. “select distinct BUKRS from myCasesTable”
  3. Click synchronise button and you should see all possible BUKRS from your data model
  4. Go to to your data model and attach authorisation object to your data model. Specify which table/column you want to filter by. I.e. myCasesTable and BUKRS
  5. Go to specific user, click manage authorisations and attach created authorisation. Click add button on the right part of the screen and select allowed BUKRS from the list
  6. Done (I hope :grinning: )

All above will mean that each time specific user opens any analysis related to that data model Celonis will automatically apply “hidden” filter in load script: FILTER “myCasesTable”.“BUKRS” IN (… list of values allowed for user …)

Option 3 is basically the same but you will need somehow create table in you database which map username to allowed BUKRS values. Simplest table will be one with two columns: username and bukrs. In this case for authorisation object settings you will use query similar to “SELECT bukrs from myTableWithUserRights where username = ?” and Celonis will automatically substitute “?” with current user login.


That’s a perfect explanation (which should be copypasted to or linked in the docs :wink: ). Thanks a lot!


Dear Lars,

Just as a comment from my side since I know this what I call “protection and hiding orgy”.
Process Mining is about processes nothing more and nothing less,
Of course there are some Fields like NETVALUE which an impression of “Turnover” but it is not. When you would ask why and what is the reason for the protection you will find silence or misunderstanding what you really see (NET Value = not Turnover)
We have more then 50 Sales and Service Units and 8 Factories in one Datamodel.
This enable the business to compare and learn from each other.
The “sharing” is a MUST and extremely benifical to everybody.
We have now some great cross company dashboards for all our PPI (Process performance indicators) where every subsidary can find the aereas of improvement…

Good luck and have fun.

H. van der Zandt


Dear Hans,

Do you think that “share all” approach works on all levels of management? I agree that ability to build KPI based “ratings” is beneficial. On the other hand access to process details (vendor name, customer name, size of deal, etc) can lead to conflict of interest in case if middle level management use Celonis for day-to-day operations control.


Dear Nick,
This is exactly the discussions which should take place.
What do we want to protect for which reason and what do we loose.

I am not sure what you mean with “Middle Management” …“can lead to conflict of interest”.
What kind of “conflict” are you referring to? And is this a conflict relevant for the person or the company?

As said, our own managers had already a few pitt fals with that Field “NETVALUE” since it includes (in our case all VBAK entries including debit, credit, returns, rejected orders, consignment orders etc. etc.).
Process Mining is not a Financial BI tool. We use the Netvalue only for sorting etc. and get some inaccurate relative impressions between the companies, customers, suppliers etc.

Our strategy is actually the the other way around. We state that this tool gives 100% transparency about all world wide processes. To be able to learn from each other everybody can see each other processes
(All the accurate FI figures are in the BI Tool with all protections wanted).
Until now after 10 Worldwide subsidiaries we have not got any request in that direction.

The only thing we do protect by putting them in special Folders which are only available for certain User Groups (linked to similar AD groups) are:
Sensitive cockpits/analysis like:

  • Worlwide Process costs calculation and capacity planning
  • Worldwide PPI Target Fullfillment comparison
  • Celonis social network anaysis posibilities

Have fun.

Best Regards,


Hi Hans,

I understand and fully agree with your point.

The requirement was communicated to me as a direct order from our legal department, as in “allowing users from one BUKRS to get information about another BUKRS is illegal.”
However, I can easily see how the matter might be more nuanced and how company politics might be a significant factor.

If you have any resources that deal with the legal aspects around this topic (preferably EU-based), I’d definitely be happy if you shared them here.



Hi Lars,

I understand now what you are saying. The question here is what to these laywers mean with “information” since a E-mail Adress or name is also “information” but shared. Is process information shared amoung subsiduaries “shared information” or “information which needs to be protected”? I guess this needs to be defined and maybe a document setup to release this kind of “information”. Normally we talk only on clear financial information or user data.

I presume you are talking of a client with many subsidaries with own BUKRS (like we have in our SAP System). What of course is a no go is the ability to look at any “personal information”. We have a private policy for all employees for that reason. So no User name etc. ios being displayed. That is also the reason why we do not use the social network at the moment.

I would go for two solution paths:

  1. Find out what is ment with “information” which should not be shared
    2, In case even process information under the current company ploicy is forbidden the question is who is benefitting from that and the backdraws of it (which are huge) and should it therfore not be changed. /win-win situation for everybody.

Maybe you or others have some ideas about this topic.

Good luck and have fun!