MSMP Configuration in SAP GRC Access Control
MSMP Configuration in SAP GRC Access Control
SAP GRC 12.0 Access Control standardizes SAP business workflow technology and supports more
flexible and tailored access requests and approver views. It also helps to simplify the
provisioning process.
This is where the SAP GRC 12.0 User Provisioning tool can help. The key engine that drives this
process of the approval workflow is called MSMP- Multi Step Multi Process.
Prerequisites:
The following configuration should have been completed as part of the initial post-installation steps:
1. GRC_MSMP_CONFIGURATION BC Set has been enabled
2. Perform Automatic Workflow Customizing
3. Perform Tasks Specific Customizing
4. Activate Event Linkage
5. Define number ranges for Access Requests
6. Connectors assigned to the PROV integration scenario
MSMP Configuration:
Run T-Code SPRO and navigate to GRC---Access Control---Workflow for Access Control---Maintain
MSMP Workflows.
These 7 steps allow you to customize and maintain the Multi-Stage Multi-Path
(MSMP) process workflows for Access Control 12.0.
• There can be only one initiator rule for each Process ID in MSMP configuration
• In case there is a custom requirement a BRF Plus rule needs to be created and these
additional setting has to be done
Routing Rules
• Similar to Initiator rules, except that they are activated during the workflow process
• Additional configuration is required to finalize the use of Routing Rules in the MSMP
workflow
• The rule and its available results must be declared & Routings must be maintained
2. Maintain Rules:
Maintain Rules includes a list of all available rules to be used when configuring a
workflow. If a new rule is created it must be added to this list. This is also where the
default initiator is configured.
It is required to maintain a list of all possible results returned by an initiator/routing
rule by using the Results button. These values will be mapped to a path in step 6.
3. Maintain Agents:
Agent Rules:
The persons that will either be notified or approved during the workflow. Conditions analyzed for an
agent rule do not have to be unique because the rule can return multiple results if the business
process requires such. The rule must be declared as an agent, including its purpose. The Agent can
be defined as GRC API rule, PFCG User Group, PFCG Role, Directly Mapped users.
4. Variables and Templates:
Notification and Variables Rules:
Identifies the possible variables that can be used in the request notification template. Additional
configuration is required to finalize the use of the Notification and Variables rule. The rule and
variables must be declared.
5. Maintain Paths:
In this step, we can specify the approval agent. We can decide if the approval path will be one stage
or two stages. Here we can specify the path ID and agent ID. In this setting, we look for the
GRAC_DEFAULT_PATH and identify the Stage in the Path. This shows that there are two stages which
are manager and Security. Now we need to understand how the approvers are assigned to the
stages.
6. Maintain Route Mapping:
From Step 2 we added the Rule Result value i.e. GRAC_DEFAULT_RESULT and Path Id is
GRAC_DEFAULT_PATH to which it is mapped for.
Always the Global Initiator must be used, if multiple paths are required the Global
The initiator must return different result values
7. Generate Versions:
In the last step, all changes will be saved and activated.