Skip to Content

GRC 10.1 ARM-Access Request Workflow Implementation

Hi Team

During GRC Access Control Implementation ,the most of the concerns of the business is towards the access risks present in the landscape and how is it addressable from GRC AC perspective. I have tried to cover all aspects of the implementation of ARQ Workflow .As the per the business we had some requirements which i guess many of our colleagues will have during Access Request Workflow Implementation.


1) Risk analysis should happen automatically on access request submission

2) Role Owner should approve all the assignment of roles to user and in case of SOD voilations it request should route to SOD Owner stage

3) SOD owner should address all the SOD access risks and mitigate it and finally approve the request.The request should not be approved without mitigating SOD risks.They need HARD STOP on approval.

4) For access removal there should not be any approval but the request needs to be validated by Security Admin before its implementation.


For requirement 1, We need to enable to below parameter in SPRO in GRC system.

SPRO->Governance Risk and Compliance->Access Control->Maintain Configuration Parameters

Risk   Analysis – Access request 1071 YES Enable risk analysis on form   submission
Risk Analysis 1023 2(Permission level) Default report type for risk analysis

For requirement 2 ,the Workflow(Account Creation/modification) needs to be created in MSMP with stage approval on GRAC_ROLEOWNER stage with routing rule enabled for rule id  GRAC_MSMP_DETOUR_SODVIOL and therafter maintain route mapping


For requirement 3,We need to enable to below parameter in SPRO in GRC system.

SPRO->Governance Risk and Compliance->Access Control->Maintain Configuration Parameters

Risk   Analysis – Access request 1073 YES Enable SoD violations detour on   risks from existing roles

Now,maintain the SOD routing in MSMP

For requirement 4

Create a Delete Request Path in MSMP with any stage for Security Admin(Agent id: GRAC_Security) so that when user or his/her manager raises delete request it gets validated by security admin and after validation security admin should submit the access request for it.

The Delete request will lock the user in backend(System  can be chosen by requestor) and also it can set the validity dates. For roles removal, Requestor needs to select all the roles by clicking on existing assignment and chose remove actionfor the Roles.

The actions to be maintained for Delete Request-

1) Change and Lock user

2) Remove

Issues: 1) SOD owner was able to mitigate the SOD access risks and approve the request but also SOD Owner was able to approve the request without mitigating the Risk.The HARD BLOCK is not working.

Go to below path

Governance, Risk and Compliance > Access Control > Maintain AC Applications and BRFplus Function Mapping. Within the transaction SPRO follow the path “Governance, Risk and Compliance” > “Access Control” > “Maintain AC Applications and BRFplus Function Mapping” and click the execute button.

Request Mitigation Policy application id is deleted from the screen to enable hard stop of approval of access request form in SOD owner stage with SOD access risks.

Issue 2: Access Request in Editable mode for Approver i.e.Approver has an option to deselect the risk analysis in Permission level and approve the request.This may dilute the Requirment 1.

The Webdynpro GRAC_OIF_REQUEST_APPROVAL  needs to customized to change the risk analysis in Read only mode for the approver.

In SE80, open the web dynpro in test-admin mode and copy the link which was opened and added the HIGHLIGHTED string to it. The REQ ID can be fetched from GRACREQ table

After hitting the above link, the request will open in customize mode and then we can go to go risk violations tab and right click on Permission level level and go to settings configuration and make the tabs in Read only mode and save it.

I hope the document will help everyone here.

Appreciate your feedback.

Best Regards


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