MSMP WORK FLOW CONFIGURATION Video Link

This will enable Multistage multipath work flow which help to complete the access request auto
provisioning part. We are going to view the Access request approval work flow

Check the below process id’s with description to know the purpose of using it

Path: Execute T code SPRO: Access controlworkflow for access controlmaintain MSMP
workflows.

We have 7 stages as shown below

We can view Sap delivered process id’s by clicking display /change can view process global settings

By clicking next we can move to the next stages, Maintain rule, agents. Etc
 Stage 1

Two notifications

 Request submission notification

Note: It’s a standard template. By using SE61 we can change & create additional template

EOR (End of Request) Template id–Which help to create a notification mail with the standard
template

 Once GRC request got completed, user get notified via mail Template
 Template id (GRAC_AR_CLOSE) comes from stage 4 variable & templates
EOR recipient id - It make sure to send the notification to respective user

 End user who is going to get the notification. Recipient (agent) id GRAC_USER comes from
stage 3 Maintain Agents

Submission template : will notify User once grc request got submitted (GRAC_AR_SUBMIT)

Submission recpt id: it notifies the respective requestor ( who raise) (GRAC_REQUESTOR)

Escape path: If no approvers found or auto provisioning failure it comes to this path. By clicking check
box we enable condition & we defining the path ( as per path it will go to Escape path -security team)

This path coming from stage 5 maintain path

All the rule ids will be configured or maintained for the selected process id

Example : Select the any one of the Process id in stage 1

 Below we selected SAP_GRAC_ACCESS _REQUEST (Access request approval work flow)

All relevant rule id’s will be maintained for process id Access request approval work flow in stage 2
 Rule kind

[Link] Rule: This rule will determine the path of the submitted request. In which path that
request (create user, add role, remove role, extend role validity) should go.

 For any process id, initiator rule should be one, but we can have a multiple path.

Ex: Extend role validity request will have multiple paths with different approvers

[Link] rule: In particular stage (Grc manager, role approver) we have some agents ( Approvers) we
can define who are all the approvers for the stages by using agent rule.

[Link] rule: route the request based on our input. Ex: GRC manager found some SOD Conflicts in
the request. So, re-route in to different path. `````````````````````````````````````

[Link] variable rule: It’s creating Email notification based on variable rule.

ex: Request number differs for each request it comes from variables

Note: Initiator and Routing rule will define the path.

Initiator and Routing rule will have a result for individual Rules. Ex: Once we clicked the Initiator rule
we can see the rule result as below. We can add rule result for existing rule id.

This marked option only will appear for Initiator and Routing rule.

Also, we can add the new unique rule id with description, Rule type, rule kind then add rule result
for that as below.
Stage 2 Maintaining Rule type for the Rule id

Note: BRF (Business Rule Frame work) plus: In GRC system we can execute the t code to design the
new customized rule or view the existing customized rule

[Link] plus rule: Fetch the Rule Result (from GRC BRF plus) based on conditions inside the rule.

2. ABAP class-based rule: This rule will be defined by ABAP developers based on business
requirement.

[Link] rule: it’s a kind a ABAP coding rule same as (ABAP class-based rule)

Stage 2 -Global rule:

By default, we have to enter the initiator and notification rule id as below. So both the rules will
work based on this selection in stage 2
Stage 2 – Maintain rule result for Initiator & Routing rule

These results will help to configure the path into stage6

Below we maintain the rule result in stage 2

The same will be configured in stage 6

We define approver & notification agent for the selected process id in stage1

Stage 3: Options to be filled

Agent purpose can be Approval or notification

Notification: Notification mail will be sent to the person who needs to be communicated
(This person can’t approve any request, just can receive the notification mail about request status)

Agent types : Directly mapped user, PFCG role, PFCG user group & GRC API Rule

Directly mapped users: We can create a group in MSMP stage 3 then add approver user id
(ex:AR_APPROVER2) to use as a recipient.

PFCG role: Based on recipient (user) role assignment- Users can play as a approver who are all
assigned with this role.
PFCG Users Group: Recipient (user) can be selected, based on users group assigned in SU01

GRC API Rule: API (Application programming interface)

Recipient (user) can be selected based on the rule (BRF plus rule, ABAP class-based rule, Func
module rule)

In below- The rule used here, should be maintained in stage 2 – maintain rule.

Stage 4 Variables & Template

This step is used create an Email notification with the suitable Template

Once GRC request got submitted, approved, rejected, routed or closed user get notified via mail.
Template: Standard mail format

Ex: GRAC_AR_CLOSE once access request got closed, end user will get the request status email

Variable: Respective End-user details will be filled for the Standard mail format

As per variable, e mail will be sent to respective end-user.

User details (first name, last name, mail id) will vary from one request to another.

In below, Marked in orange colours are Variables, Remaining text are Standard template

Stage 4 page will be displayed as below with standard template & variables
Modify the template: SE61  Doc class always General Text, lung: English->edit then modify or
change the template for the template id (GRAC_AR_CLOSE)

Stage 5 Maintain Path

Maintain path and maintain stages of the path will be present in this stage.
Stage seq no: By using stage seq number we can define; how many approver stages should be

present for the process which was selected in stege1.

So all GRC access request will go to these approvers stages only.

Ex: We have set only TWO stages of Sequence number 001,002

GRAC_DEFAULT_STA
001 GE ZGRAC_MANAGER

GRAC_DEFAULT_STA
002 GE ZGRAC_ROLEAPPROVER

 So, once GRC request got submitted it will go to GRC Manager approval first since we have
mapped agent id ZGRAC_MANAGER for 001
 Next it will go to Role approver approval as per the seq no 002
 Note: Stage config id GRAC_DEFAULT_STAGE can be same for 001,002,003, etc

Stage config id: This id (GRAC_DEFAULT_STAGE) to specify the stage

Agent id: Approver of the specific stage

Approvers type: All approvers or any one approver. If we select all approver, all the approvers
(agents) should approve the request to move the next stage.

one of the approvers – if any one approved the request will go to next stage

Routing enabled: option yes or no….

If yes: we have to define where this request has to go exactly if its routed. need fill rule type, rule id,

routing level

ex: is there any risk appears, it will be routed into different path

If no: nothing to be filled under rule type , rule id, routing level as like this

Below is a edit (by clicking Modify)mode for the stage

Modify task settings: Once clicked the Modify task setting option, the page will appears as below
Here we can see the purpose of filling each option under Task settings

Path reval new roles: Here we have 3 options, approver would evaluate as per the selection

Ex: Selected Only new role in evaluation path: Assume in GRC request we have 5 roles, but approver
will evaluate only newly created 2 roles since we selected first option.

If we selected 3rd option (all roles in request) all 5 roles will be evaluated by approver

Risk analysis mandatory: If we select Yes approver must to run the risk before approve the request,
If selected No, its not necessary
Approval level: If we select Request, approver can approve whole request, if selected role- particular
role alone they approve it. If system and role : Particular system with relevant role can be approved.

Comments Mandatory: if we select

Approval: Approver has to approval comments, Rejection: has to add the Rejection comments

Both: when approved or rejecting it comments to be added