Skip to Content

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

3/Nov/2016 blog updated for re-tagging due to SCN migration

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.




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.




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.


[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).


[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.

You must be Logged on to comment or reply to a post.
  • Colleen,

    Thanks for the well presented document.

    Can we activate standard workflows and test various request types in DEV before actually implementing real-time business scenarios?


    • Hi Harry

      technically you can so long as for each type you do not give the option to initiate workflow:

      • Access requests - you don't use the functionality (ie user cannot complete user request form for access or firefighter)
      • functions, risks, etc - you don't set that config parametes
      • BRM - you configure Role methodology and exclude approval step
      • you do not schedules job for access reviews, etc that are via workflow

      But am not sure you would activate wf config without intending to use it?

      if msmp is not configured the user will get an error when they submit their workflow



  • HI Collen,

    Exelent doucment from your end and it is very useful to every one,keep on posting like this type of docuements....... 🙂


  • Hi Colleen

    Great Document.

    Just want to know if you or anyone has Descriptions/Documentation for Each field on Task Settings/Stage Definition on the Maintain Stages under 5. Maintain Paths.

    This will really assist.



  • Thanks Colleen! Are you or anyone aware if we can have one final, end of path,  or end of request notification for one request type. It seems that the end of path (with badi applied note 1738377) and end of request notifications are universal for all types of requests. Thoughts? Thanks!!!

    For instance, if you want to create a notification very specific to new users and a different one for change users, it seems that is not possible as the end of request is controlled in a global way.

    The end of path badi, allows a end of path notification but it also uses the same document for all request types...

    Thanks in advance!

    GRC10 SP14 here

    • Hi Gustavo

      Sorry I'm not on a GRC system to test this out and confirm. I noticed you have posted a question so perhaps one of the more experienced members will be able to respond.

      Pretty good to know about the BADI. As more people configure MSMP I can see these scenarios cropping up. If the Global Notifications catered for a notification rule then you could configure it but when it's just the document and agent it does make it difficult.



  • G'Day Colleen,

    Thank you for a wonderful post. The graphical representation of various aspects of MSMP is awesome. The detail (colour coding etc) is incredible. It is so much more easier to comprehend. I was gonna prepare one for myself to make sense of all of this but you saved me the trouble.

    I could not figure how the Agents (GRAC_Manager/Role Owner etc) are linked to the end user. In 5.3 you can specifically mention in CAD but here there isn't a direct linkup (well that's how it seemed). However after a lot of reading and mucking around on the system I finally managed to understand how it works and thanks to your article it clarified things even further. Also I finally managed to understand what a 'catch all is'. So once again thank you for taking the time to prepare a much needed post. Appreciate it.

    Just one query if I may though. Would you be kind enough to clarify when one would use a BRF+ Rule and a BRF+ Flat Rule? I know the latter cannot be used for all scenarios, so an example or two would be awesome.



    • Glad to hear you are getting a heap of value out of the GRC content

      Yes catch all is my personal suggestion but more goes back to process flow - you want to cater for all scenarios

      BRF rule vs flat rule - you should be able to search for this. In a nutshell if you have a request (think user access) and it has line items (each role being requested) you can use the flat rule to eveluate each option and route each line item to a different approver. Or you can just deal with the request as a whole and send it one step. This is where the multi-process comes from in MSMP. You have a single workflow item but GRC routes parts of it to different approvers



  • Excellent document Colleen. Thanks for putting this together.

    Wonder whether you can provide some guidance on something I am struggling with. I simply want to add an additional stage to GRAC_USER_ACCESS_REVIEW workflow to pass the request back to the Security Team once it is approved by the role owner. This is just to make sure roles marked for removal by role owners during the UAR are appropriate. Can I do this with the standard workflow I am using in GRC, or do I need to create a new rule, agents etc.?

    I looked at creating a new stage under GRAC_DEFAULT_PATH.  All I see is GRAC_UAR_REVIEWER agent under available agents. Appreciate your help. I did search for documentation on MSMP workflow in SAP Marketplace, but could not find anything useful.

    Kind regards,


    • Sonny,

      Yours is a rather complicated question. You are not just asking for a point of clarification of Colleen's document. May I suggest that you be kind to Colleen and post it as a question in the discussion forum, so that anyone can respond, rather than pressing her to be your freebie consultant? Just speaking for myself as a blogger here, when I see a string of tangential questions, it is a disincentive to publishing documents on SCN.



    • Hi Sonny, I have just started looking into setting up a UAR in GRC 10.1, the question you have posed is exactly what i am looking for. Have you had any luck finding answers?

      Any guidance or document reference is appreciated. Thanks!

    • Hi Sonny

      more than happy to assist (If I can) but Gretchen is right. Your would receive more visibility by asking a your own question (more members will be able to see it)

      Looking forward to seeing your question raised. When you do, please include as much content of what you have tried to attempt (MSMP screen shots help) as well as what outcome you are after (i.e. add a stage for security). How well you detail your requirements will impact the ideas suggested to you.



  • Hi, I am working on 10.1 - We have been on 10.0 for two years.  I am adding additional criteria to my initiator rule and therefore have 3 new rule results.  I have activated all parts of my brfplus initiator.  Now I am in MSMP and I cannot seem to find my new rule results when trying to add them in MSMP - Step 2 - Maintain Rules.  Any suggestions?

    • Hello Jeanne:

      I suppose you have made changes to your initiator for Process id: SAP_GRAC_ACCESS_REQUEST. If so, you can select the initiator in your stage 2 (maintain rules) and add Rule Results for Rule Value and Trigger Value and Maintain the same in Stage 6 (maintain route mapping) for the same Rule ID.

      Hope this helps.


  • Thanks Colleen

    Is there a way to pass parameters in the url?

    I.e. selecting a template for the user and skipping to step 2 (user details)? new user request. We are on GRC10 NW 7.4



    • Hi Antonette

      I recommend you create a new discussion/question for these and outline what you are trying to achieve. I have seen a few questions and forum members discuss passing parameter but there might be solutions out there if you properly detail your requirements.

      This document was attempting to explain the concepts behind MSMP for the workflow configuration



  • Great!!

    I'm beggining with MSMP and this is one of the best info I've found.

    Highly valuated for all I guess.

    I'm trying to send a notification email at the end of the process but with no approving sending. Here, my colleague has told me that I can't send a notification email without having determined first the Agents for Approval.

    Can I do this?

    • Hi Jose

      To clarify, are you after an "auto approve" and send a notification at the very end?

      If so, you can route the request to a Path with not Stages (autoapprove) and then have a global notification at the end of request (once all approvals are done).

      Alternatively, if you have multiple steps in your approval but need to route some down the auto-approve, you could put a "APPROVE" (sorry can't remember exact name) notification on the last stage that was approved to send your communication out.

      I recommend you draw a flow diagram of the approvals vs the  notification steps. You might find a way to match up with the stage or global notifications and the events (NEW_ITEM, FORWARD, etc)



      P.s if you require further assistance, please create your own discussion and explain your requirements as well as what you have done. Your question is quite high level and I may have misunderstood it. The key is to know your process flow before you attempt to configure the system - and that's down to pen and paper!

  • Hi,

    It is a very helpful document.

    I have some doubts given below :

    1) should rule id  be unique for every route path?

    2) how does GRC differentiate the access work flow? suppose my 1st Access request ( request type new account creation for back end system ABC)  goes to Path1 (2 stage approval) & 2nd Access request ( request type new account creation for different system XYZ) goes to PAth 2( 3 stage approval).  

    What is needed to do for system to understand the the this request should go to path 1 & another one go to path 2 ?