MSMP - Multi Step Multi Process – GRC’s

answer to Workflow Configuration

Flexibility

SAP GRC 10.0 introduced the new concept (well not so new now) of MSMP workflow engine as a configurable
layer that sits on top of SAP Standard Workflow for Access Controls. This provides flexibility to enable a single
request to be split and routed to different approvers in parallel as well as multiple approval steps depending on
business requirements.

I must admit, I found the MSMP a little confusing at first. To the logical me, numbers and steps must imply
sequence. Lesson learned: they do not. The sequence you follow is entirely dependent on what you are trying
to achieve. This document is an attempt to explain the relationships between the steps for rules, agents and
notifications.

The diagram below maps the steps 1 through to 6 of the MSMP. Step 7 has been excluded as it is the
final step of any MSMP change to generate a new version. It has been drawn using the names of items in
MSMP but at a higher level (for example in Notifications Settings does not specify the notification template or
notification event). Green has been used to represent Agents used for Approval and Notification; Red for Path
mappings; and purple for the use of the rules. BRFPlus has been used to represent the Initiator rule; however,
this could easily have been a SE37 Function Module, etc.

Generated by Jive on 2015-02-21+01:00

1
MSMP - Multi Step Multi Process – GRC’s answer to Workflow Configuration Flexibility

Rule to Path Mappings

For the purposes of explaining the MSMP, I am basing this on a simple BRFPlus flat line Initiator Rule with two
Request Types: (01) New User and (02) Change User.

BRFPlus

Generated by Jive on 2015-02-21+01:00

2
MSMP - Multi Step Multi Process – GRC’s answer to Workflow Configuration Flexibility

The intention of this initiator rule is to route the entire request to a different path depending on
the type of request type. In this example, a decision table has been used to capture three returns
results: NEW_REQ; CHANGE_REQ and OTHER_REQ. The additional scenario (OTHER_REQ) has
been included as a catch all – if another request type is activated without updating the BRF+/
MSMP then the request will still be handled without error on request submission.

[1] Process Global Settings

The Process Global settings step must reference the Initiator Rule for the Process Id (i.e.
SAP_GRAC_ACCESS_REQUEST). Each Process Id has one and only one active Initiator Rule. The Initiator
rule is the first one called by the workflow engine for the Access Request. Although not shown in the diagram, a
global notification rule is also specified. Agent and Routing Rules are not mentioned in this step.

[2] Maintain Rules

The BRFPlus Function Id is defined as a rule in the MSMP. For Initiator and Routing Rules, the Rule Results
table must be maintained. This table must map each result from the function (i.e. the BRFPlus decision table)
to a Trigger Value which is handled in the route mappings (skip to step 6).

[6] Maintain Route Mappings

The trigger value results specified in the Maintain Rules Step are mapped to a specific path and stage (stage
not shown on the diagram). This mapping determines which path is executed. Each trigger value must be
specified in this step to identify the path to direct the request to. Different results for the rule can be mapped to
the same path/stages.

[5] Maintain Paths

Multiple paths are defined depending on requirements. For example, a different path has been defined for each
request type (NEW_PATH, CHANGE_PATH and OTHER_PATH). Within each Path, Stages are defined for
each approval level. The Stage can then be configured to determine screen layout (end user personalisation
button, etc.), routing of request (via routing rule), escalation and notifications. A Path with No stages will trigger
automatic approval.

Agents for Approval and Notifications

For this example, an Agent Rule based on PFCG User role has been defined for Manager. Any user assigned
to the security role is considered a Manager.

Generated by Jive on 2015-02-21+01:00

3
MSMP - Multi Step Multi Process – GRC’s answer to Workflow Configuration Flexibility

[3] Maintain Agents

Agent rules are defined for each set of users to approver requests or receive notifications. The role is either
Approval or Notifications. Therefore, if the same Agent is required for both then two Agents Rules must be
defined. In this example agents have been shown using the colour purple/blue for the Approval Agents and
green for the Notification Agent. In this example, agents are defined based on a PFCG Role.

[5] Maintain Paths

For each Stage of a Path, an Approval Agent is specified (except for automatic approval where no agent is
mentioned). The Manger Approval Agent will receive the request in their POWL inbox in GRC. An additional
Agent can be specified within task settings for escalation (in this example, Senior Manager) if the Approval
Agent for the stage does not respond in the specified time.
Multiple notifications can also be defined at each Stage for specific events (such as NEW_WORK_ITEM). The
Agent must be of notification type. In this situation, a notification is defined for each combination of Agent,
Event and Template. This provides flexibility to send different communications to the agents depending on the
stage of the path.

[1] Process Global Settings

Notifications can also be defined on this step for specific event types. Similar to Maintain Paths, the
combination of Agent, Event and Template is specified. This notification is sent for REQUEST_SUBMISSION
(at the start) or END_OF_REQUEST (once all paths have been completed and the request has finished
processing).

Generated by Jive on 2015-02-21+01:00

4
MSMP - Multi Step Multi Process – GRC’s answer to Workflow Configuration Flexibility

[4] Variable & Templates

This step is used to define the notification templates and fields. They template references the SE61 Document
where the contents of the email is specified. The Variables are configured in the MSMP and referenced within
the SE61 document to personalise the message to the specifics of the request.

Starting out with the MSMP?

SAP delivers default MSMP configuration via the following BC Sets below:
• GRC_MSMP_CONFIGURATION - BC Set for msmp workflow for standard and sample Config
• GRC_MSMP_SAMPLE_CONF - BC Set for MSMP workflow configuration for sample paths
• GRC_MSMP_STD_CONF - BC Set for standard MSMP workflow configuration

As a starting point, I recommend you activate the BC sets so you can see the examples provided. They do
not include BRFPlus rules and the Initiator Rule only has one result value. However, this configuration is a
good starting point to work out how to use MSMP before you configure your system. Once you have mastered
MSMP you challenge is more related to defining your business process for access request approvals which will
determine what rules, paths and stages you need to configure.

Time to get Technical?

The following SAP document provides the technical steps to create and maintain a BRF+ initiator rule and
the add and maintain it within the MSMP. It does not exactly follow the example here but key difference is the
decision table. My document has kept it simple with request type whilst this one include additional request
attributes.

BRF plus Flate Rule - GRC Integration - Governance, Risk and Compliance - SCN Wiki

Constructive feedback is welcomed. Please suggest how this document can be improved or topics that may be
worth discussing. I am attempting to produce material that explains some of the concepts rather than include
each step on how to configure a scenario. By understanding the MSMP, it is then through practise that you can
master configuring complex scenarios. I hope this document helps you to understand MSMP a bit better.

Generated by Jive on 2015-02-21+01:00

5