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

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

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.

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