1. Security Management Logic

Security Management is split by Role dans 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 concretely a user group.
• The objective behind is to give access to Workspaces (Remote and/or Web), Models, Shortcuts.
• The list of roles by GBU has been defined and should not changed 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 concretely a user group.
• The objective behind 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 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.

2.1. DP2 - Composites (CM)

i. Workspaces

The logic here is to use:

• Remote Workspaces for Demand Planners and PMI/PMI Admin. users;
• Web Workspaces for Regional Sales Managers and Account Managers users.

Workspaces are not visible by default - "Allow" is applied as below:

ii. Models

a. Core Models 

Forecast Models are not visible by default - "Allow" is applied as below:

b. User Models

User Models are not visible by default - "Allow" is applied as below:

iii. Shortcuts

Shortcuts are not visible by default - "Allow" is applied as below by folder:

iv. Master Tables

Security of Master Tables is usually set-up when related to User Management: when a new scope is created (new user or scope transition), the condition should be inputted in both visibility and modification columns.

2.2 DSCP1 - Soda Ash and Derivatives (SD)

i. Workspaces

ii. Models

iii. Shortcuts

iv. Master Tables

2.3 DP3 - Novecare (CS)

i. Workspaces

ii. Models

iii. Shortcuts

iv. Master Tables

2.4 DP3 - Oil and Gas (OG)

i. Workspaces

ii. Models

iii. Shortcuts

iv. Master Tables

2.5 DP3 - Special Chem (CH)

i. Workspaces

ii. Models

iii. Shortcuts

iv. Master Tables

2.6 DP1 - Aroma (PA)

i. Workspaces

ii. Models

iii. Shortcuts

iv. Master Tables

2.7 DP1 - Perox (PE)

i. Workspaces

ii. Models

iii. Shortcuts

iv. Master Tables

2.8 DP1 - Silica (SI)

i. Workspaces

ii. Models

iii. Shortcuts

iv. Master Tables

2.9 DP1 - Technology Solutions (TS)

i. Workspaces

ii. Models

iii. Shortcuts

iv. Master Tables

2.10 DSCP2 - Specialty Polymers (SP)

i. Workspaces

ii. Models

iii. Shortcuts

iv. Master Tables

3. Examples

Here are some examples on concret cases, raised by ticket through the years.

3.1 Example #1 - Simple

For ex: for a Sales Employee of a given GBU

3.2 Example #2 - Complex

For example, QSM-285899

4. Useful documentation

• QAD Documentation