Skip to Content

EAM: Requesting emergency access via access request workflow in SAP GRC – step by step.

1. Introduction – the need.

Your company is currently managing emergency access requests manually, based on approved ticket or request in another system or ticketing tool. You would like to enhance the usage of GRC AC tool and enable requesting for emergency access assignment in a way similar to requesting user regular access requests – via SAP GRC Access Request Management system. Your Audit team, however would like to limit number of people who can access this kind of access request, as it is critical from risk perspective.

2. Expected result – emergency access requests.

On the request type drop-down – you would like to see a new request type “Emergency access request”.


On the request detail (line item level) – you would like to see a new entry “Firefighter ID”.


Next after ‘Firefighter ID’ entry selection – and you would like to specify validity period for EAM assignment.


Next you would like FF account owner to approve this access via SAP GRC work-inbox, exactly in the same way as other access requests being approved. You expect one stage approval – being made by EAM account owner.


3. Enable new access request type for Emergency Access (step by step)

3.1 Activate superuser access request type for SAP GRC 10.

Go to SPRO – > GRC -> Access Control -> User Provisioning -> Define request type

In this Customizing activity, you can maintain the request types, and then assign actions to the request types. SAP delivers several standard request types. These standard request types represent actions that occur in the back end systems.



Click on box to activate


3.2 Select action for superuser request type.

Click on line item for Super User Access and next click on Select Action and ensure you have ‘Super User Access’.


3.3 Save and transport.

3.4 Validation. On your access request – > if you done everything correctly – you should be able to see new request type with Super User Access request type. Make sure you have appropriate authorization and additional authorization (request type ‘6’ in example case) will be required to see / create this access request as per expected solution requirements.

4. Build path for Super user access assignment request type (step by step)

Now when your new request type is available in the system, you need to make sure you have workflow path in place to handle those request.

4.1 Modification (or creation) of initiator rule

If you already have workflow for access request in place (as mentioned in Introduction) – you need to just update your Initiator rule to handle new request type. To update your current initiator rule – go to ‘BRF+’ transaction code and find your initiator rule (if you do not have it yet – first it need to be create see other documents for information in case you are wondering how to do this like:GRC Request with both System and Role Line Items

or  AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls ).

Next click on Table settings.


Make sure field ‘REQTYPE’ is on the list of Condition Columns.

Next modify new entry (/wp-content/uploads/2015/01/11_631095.png)in decision table and add new condition by clicking /wp-content/uploads/2015/01/12_631096.png and selecting  Direct Value Input from the list in ‘REQTYPE ”column.



In result section enter (in LINE_ITEM_KEY – contex parameter ITEMNUM) and Rule_Result (direct value input for example Z_EAM)


Next activate your function and transport changes

4.2 Building path for EAM access requests

Enter the transaction code ‘GRFNMW_CONFIGURE_WD’ and open Workflow navigator.

Select process for ‘SAP_GRAC_ACCESS_REQUEST’ and click edit


4.3 Define result for initiator rule.

Go to Maintain Rules and find your initiator rule.


and click on ADD button.

Next add your Rule result defined previously – in my case it was Z_EAM.

4.4 Define Path

Define the path name and stage


Create new path in my case Z_EAM:


4.5 Maintain Stages

Next you add one stage – there is standard agent available GRAC_SPM_OWNER. Whoever you define as EAM owner will be now approving emergency access requests. 


4.6 Maintain route mapping

Assign this new created path Z_EAM to result you have from your initiator rule (in my case also Z_EAM)


4.7 Activate the Workflow version

Last step and you done with your configuration – you can now start to create access control workflows.


Please share and contribute in this document to make it better.

Looking forward to hear from you.

Best regards,


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


        Thanks for reply, I have seen that links also, every time I got somewhere lost connection for result which we are setting in BRF+ for rule.


        So need bit more details for where are defining result for that rule




        Bhupinder Singh Arora

        • HI Bhupinder


          it might be easier to let us know where you get lost


          This document and the others show the link. BRF+ decision table output is the rule result. You make these values up and then reference them in the MSMP for the Initiator rule. The document I wrote on MSMP provides a diagram to show this connection.




  • Hi Colleen,

    thanks for the great post!


    I got a question on section

    4.1 Modification (or creation) of initiator rule:


    I would need to get different results based on the EAM ID entered in the Access Request. One might be critical and needs another result.

    But I am not able to get the EAM ID from the request line items in BRF+ in order to have a DBLookUp or so to run over the EAM ID.

    Any idea?

    Thanks and best regards,


    • Hi Markus,


      thanks for review for my post:) You can also rank it if you want - just click on stars- below the text.

      Coming to your question - EAM ID - is not available in standard. What I would suggest is to create separate user groups for each EAM ID and next based on user group differentiate your workflow paths,



      • Hi Filip,


        thanks for your great document.



        regarding getting EAM ID, you suggested to create separate user groups for each EAM ID.


        I tried this but from the debug log the user group is only for the user id not the EAM ID. is there any more information how to get user group for EAM ID?


        Thanks and best regards

        Yongbiao2015-4-23 10-12-42.jpg

        2015-4-23 10-12-42.jpg
        • Hi Yongbiao,

          the other way around. First you assign USER ID (1:1 to EAM ID) to USER GROUP, based on user group you differentiate the path (different one).

          Can you share how did you got this advance view for debugging?


  • Hi Filip,

    I have configured the MSMP workflow as suggested and am using the standard agent GRAC_SPM_OWNER however no approvers are getting determined.

    Owners have been assigned to the FFID for which access request has been raised.

    Any idea what could be the issue?

    Is there any way to unit test the agent id to check the approvers? I tried putting a breakpoint in the FM GRAC_MSMP_SPM_OWNER_AGENT which i think determines the approvers as per the MSMP runtime logs to check but the MSMP workflow did not stop there when the access request was submitted.