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.
 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.
 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).
 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.
 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.
 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.
 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.
 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).
 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.
Thanks Colleen,for sharing the document.
Thanks for the encouragement to write a document and also peer reviewing 🙂
Excellent - Excellent - Excellent !!!
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?
technically you can so long as for each type you do not give the option to initiate 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
Thanks for the explanation.
Have a good day.
Thanks & regards
Exelent doucment from your end and it is very useful to every one,keep on posting like this type of docuements....... 🙂
Very nice and any one can understand MSMP easily now.
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.
Most of those descriptions, are covered in the GRC 300 training
I have looked at it, I just wanted to know if there were further details/documentation on these.
Thanks Colleen for sharing such a nice, compact and more friendly document on GRC MSMP.
great document Colleen 🙂 I missed that one coz it was during my holiday 🙂
Always meaningful and knowledge sharing inputs from you Colleen.
Thanks for bringing this to our knowledge.
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
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.
Thanks for your reply Colleen. It seems that there is not flexibility for each request type and notifications at the end of requests...disappointing:(
Have you considered raising this in Ideas Place?
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
Thanks Colleen. Appreciate it.
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.
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!
Will do Gretchen. I thought Colleen can point me to some existing documentation related to adding a new stage.
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?
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.
I was trying to find them in the drop down in step 2; finally I just created them from scratch and it worked.
very beautifully designed and explained.. i loved it..
Best document on MSMP understanding ... Really appreciate it and thanks a lot . keep it up
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
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
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?
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!
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 ?
I have the following scenario - let's assume there are two paths - one without approvals (e.g. auto-approval) and one that requires two approvals.
Obviously those two will run with different pace as to the one without approvals being ready far ahead of the one with approvals.
The question -> Is there a concept in MSMP called Merge (known from other Workflow engines) where two patch can be joined back to one single path.
For the scenario, this would mean that when the approval path is done, to join into one single path with the other path that was approval-free.