Hello everyone! If you have already read the blog post - Role Overview in SAP PaPM Cloud Standard Model (Part 1/2) , you are familiar with the roles in SAP Profitability and Performance Management Cloud Standard Model (SAP PaPM Cloud SM). But if you are also exploring SAP Profitability and Performance Management Cloud Universal Model (SAP PaPM Cloud UM), you might be wondering: Are the user roles the same in both SM and UM?
If I say they are not the same, there might be some of the follow up questions like: What user roles are available SAP PaPM Cloud UM? Is there a way to create different teams and limit access to some environments, processes or activities for specific user groups? Is there a possibility to even limit data read/write access for specific users?
If you have some of the questions above, you should stay on this blog post to learn more about all these topics.
Currently there are 5 big sections in SAP PaPM Cloud UM which are Model, Process, System, Administration and Report and 39 user roles. In order to easily differentiate them, they are highlighted in different colors, wherein among the various roles the 5 powerful roles are highlighted in black:
Orange – Modeling related screens.
Blue – Process related screens.
Yellow – System related screens.
Green – Administration related screens.
Purple – Report related screens.
For more information about these Roles you may refer to SAP Help Portal Roles Templates for SAP PaPM Cloud UM.
Let’s first take a look on the tabular overview which screens from these 5 application groups are accessible to user based on roles mentioned above.
Now let’s dive deep in each application group and check available buttons based on a role.
MODEL
The table below shows all the available buttons in Model applications and indicates if a certain role has access to each button. Note that for all functions in Model section, Edit action is available for roles the same as for Model Entity. There are 3 cases:
Let me explain this through an example.
User with MODEL_ALL role will be able to see all environments in the tenant and perform any action e.g. edit, no matter if he is part of a Reader/Writer team.
User with MODEL role that is part of Reader Team only will be able to see the environment where he is part of a team, but not to execute any actions e.g. edit.
User with MODEL role that is part of both Reader and Writer teams will be able to see that environment and perform all actions e.g. edit.
User with MODEL_READ role will only be able to see the environment where he is part of a Reader Team, but won’t be able to perform any action e.g. edit, even though he is part of Writer Team as well.
The same behavior applies to all other buttons that are showed in the screenshots below.
PROCESS
The table below shows all the available buttons in Process applications and indicates if a certain role has access to each button. Note that Display Runtime Environments, Functions, Fields and Connections are only visible with PROCESS_ALL, PROCESS and PROCESS_READ roles. There are 4 cases:
Take note that for certain actions in Activity such as Copy, Create, Delete and Edit, it’s the Process role that grants these accesses, and Activity role is relevant for other actions such as Confirm, Reject etc.
Let me explain this through an example.
User with PROCESS_ALL role will be able to see all processes and activities in the tenant and perform any action e.g. edit, confirm etc., no matter if he is part of a Reader/Writer team.
User with PROCESS role that is part of Reader Team only will be able to see the process and activity where he is part of a team, but not to execute any actions e.g. edit, confirm etc.
User with PROCESS role that is part of both Reader and Writer teams will be able to see that process and activity and perform all actions e.g. edit, confirm etc.
User with PROCESS_READ role will only be able to see the process and activity where he is part of a Reader Team, but won’t be able to perform any action e.g. edit, confirm, even though he is part of Writer Team as well.
The same behavior applies to all other buttons that are showed in the screenshots below.
SYSTEM
The table below shows all the available buttons in System applications and indicates if a certain role has access to each button. There are 4 cases:
Let me explain this through an example.
User with SYSTEM_ALL role will be able to see all System objects in the tenant and perform any action e.g. edit, no matter if he is part of a Reader/Writer team.
User with COMMENT role that is part of Reader Team only will be able to see the comment where he is part of a team, but not to execute any actions e.g. edit.
User with COMMENT role that is part of both Reader and Writer teams will be able to see that comment but perform actions only for his own comments or create new ones.
User with COMMENT_READ role will only be able to see the comment where he is part of a Reader Team but won’t be able to perform any action e.g. edit, create, even though he is part of Writer Team as well.
The same behavior applies to all other buttons that are showed in the screenshots below.
ADMINISTRATION
The table below shows all the available buttons in Administration applications and indicates if a certain role has access to each button. There are 2 cases:
Let me explain this through an example.
User with ADMINISTRATION_ALL role will be able to see all Administration objects in the tenant and perform any action e.g. edit.
User with CONTAINER will be able to see and execute any actions e.g. edit.
User with CONTAINER_READ role be able to see but not execute any actions e.g. edit.
The same behavior applies to all other buttons that are showed in the screenshots below.
REPORT
The table below shows all the available buttons in Report applications and indicates if a certain role has access to each button. There are 3 cases:
Let me explain this through an example.
User with REPORT_ALL role will be able to see all reports and pages in the tenant and perform any action e.g. edit, no matter if he is part of a Reader/Writer team.
User with REPORT role that is part of Reader Team only will be able to see the report where he is part of a team, but not to execute any actions e.g. edit. User also won’t be able to open report’s page if he doesn’t have PAGE role.
User with REPORT and PAGE roles that is part of both Reader and Writer teams will be able to see that report/page and perform all actions e.g. edit.
User with REPORT_READ and PAGE_READ roles will only be able to see the report/page where he is part of a Reader Team but won’t be able to perform any action e.g. edit, even though he is part of Writer Team as well.
The same behavior applies to all other buttons that are showed in the screenshots below.
Now that you know what roles are available in SAP PaPM Cloud Universal Model and what are they capable of, you can start configuring your user groups in the system in order to differentiate actions that are needed based on business roles.
To make that easier, you can also create multiple teams for different user groups in the system and even limit or grant additional access to them for specific data sets. If you want to find out how to do that, track our upcoming blog posts and Teams Management together with Data Privileges and Locks is exactly one of the next topics.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
4 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |