1. Security Management Logic

Security Management is split by Role and Scope depending on the object you want to give users access to. 

1.1 Role

• One user needs to have at least one role (but can have multiple ones).
• The role is a user group.
• The objective is to give access to Workspaces (Remote and/or Web), Models, Shortcuts.
• The list of roles by GBU has been defined and should not change frequently. 
• For example: two users can be Sales Manager for one GBU - they will see the same workspaces, shortcuts, models... The process will be identical.

1.2 Scope

• One user needs to have one scope/perimeter only (in order to avoid conflict/blocking between several users.)
• The scope is a user group.
• The objective is to give access to a specific list of DFUs or any other dimension (depending on an aggregated level).
• The scope is changing frequently depending on the Commercial Team organization in SAP/GBU.
• For example: two users can be Sales Managers for one GBU but with two different scopes - they will be able to work on the same workspace at the same time on a different set of DFUs.

2. Security by GBU

The logic and best practices are to:

• Use exclusively User Groups “Role” to set-up Models security - no exception for user group scope;
• Set-up security at the highest level of the structure: set-up will be inherited at each disaggregated level;
• Apply “deny” when data is not used for this user role, by Models - never at a more detailed level (and in the opposite way, apply "Allow" when data is used for the user role).

If a business request can’t follow these rules, a new user group "role" needs to be created - no exception can be applied.

As explained above, security is applied based on GBU and role. Here is the summary of GBU roles list.

3. Examples

Here are some examples on concrete cases, raised by tickets through the years.

3.1 Example #1 - Simple

For ex: for a Sales Employee of a given GBU

3.2 Example #2 - Complex

4. Useful documentation

EN MODELING Demand Planning 2018 (3).pdf