Take a scenario: Where you have a requirement for


1) User Authentication data source is LDAP

2) User Details Data source is HR(for Manager)

3) SAP User ID is stored in physical attribute in LDAP.

4) HR system infotype 0105 subtype 0001 stores SAPID

5) HR system infotype 0105 subtype 9000 stores domain id



Whenever a user is authenticated in LDAP using SAMACCOUNTNAME the same is passed to HR for details data source information and it also gets validated against Infotype 0105 subtype 0001 to obtain manager and other details.


When SAMACCOUNT id is passed and SAP ID in infotype 0105 and subtype 0001 is stored, it will not match.


Hence a development on target system has to be made where it can validate against infotype 0105 subtype 0001 in /GRCPI/CL_GRIA_USR Method is GET_USR_DETAILS

Now the details can be fetched for access request.


Since the requirement is authentication data source is LDAP.

And SAP ID is stored in physical attribute and Manager should come from HR system.

You have to remove Manager mapping for LDAP in maintain mapping for connector and connector group.

And Enable below parameter.


Access request validations           5023            YES     Consider details from multiple data sources for missing user details in access request

In Data Source sequence for User details keep LDAP above HR.


It will fetch all details from LDAP and change the SAP User ID in Access Request form.


Fill other details from HR system including Manager.




Troubleshoot your issue at your own! - Try Component Specific Questions (CSQ) for faster resolution.


CSQs are the set of suggestions which put forward the latest KBA,Notes,WIKI docs, blogs and videos to serve you a quick resolution for the customer. The CSQ section appears right after business Impact section while creating the Incident with the heading 'Questions Specific to the selected application area'.
See below:




When the customer attempts to create an incident at SAP Service Market Place or via Solman and selecting a component, a set of customized recommendations and specific questions are prompted. With this, you will be immediately led towards a potential solution without sending an incident to SAP Support. This way, it helps you finding the resolution of your issues faster minimizing the overall time and effort for both the parties. Therefore, we always encourage customers to ensure that they are mentioning the correct component to get with the right set of CSQs for the specific issue area, else you will not get appropriate results for resolution. These CSQs are specific to each GRC component and their sub-components i.e, Access Control CSQs are different from Process Control/Risk Management and so on, and further they are categorized by their sub-components – Access Request Creation(ARQ), Access

Risk Management(ARA), Business Role Management(BRM), Emergency Access Management(EAM).






It is a generic text which is displayed for a particular component. Now, it becomes the action item for the customer to look for the most appropriate answer as per the business requirement. For example, CSQs for ARQ- there are categories like Notifications, workflow, provisioning, Password self service, Model user, dumps etc. Therefore, customer will have to check the particular area their issue belongs to. If they find a relevant solution and it resolves the issue, they can skip creating the Incident further and leave Incident wizard without saving. Otherwise, please continue with Incident description and add other related things to complete the Incident helping our engineers understand your issue more effectively.


Similarly, there are CSQs for process Control, Risk Management and Sustainability Performance Management. Going forward, Audit Management/Fraud Management CSQs will also be updated in their Incidents.


These CSQs are updated every quarter consisting the details of latest code corrections/hot fixes via Notes/KBAs, WIKI documents, blogs at SCN forum and additional quick updates. This is a really easy and quick way of troubleshooting your issues at your own prior to sending the Incident to SAP Support. This helps finding the solution at a very short span of time.

Dear All,


With continuous to how to create a risk in risk management Creation of Risk in Risk Management GRC V10.0


This document will gives you how to create/use key risk indicators tab in Risk



We can create two types of KRI

Standard KRI Instance

Manuel KRI Instance




Click in create standard KRI instance

It will ask for KRI instance Name and KRI Implementation



How to create KRI Implementations

KRI implementations can be created under Key Risk Indicators link




Click on KRI Implementations to create


To create KRI Implementation we need KRI template

How to create KRI template






Click on create button to create KRI template



Provide the KRI template name and select Value type from drop down



To select other details like system, Business process and Component

We need to go back to SPRO for maintenance

SPRO>GRC>Risk Management>Key Risk Indicators






Click Save to create KRI Template

Now created KRI template will be available in KRI template catalog like below



Now we can select the KRI template in creation KRI implementation



Provide KRI Implementation Name and select the created KRI template from F4




Select the connector type from drop down

Connector types are configured and maintained in SPRO



Maintain the connector names with system in Maintain Connectors and select connector type




Maintain the script for SAP table, where we need to provide the SAP table name.



Once we select the connector type, then connector and script field will be populated



Don’t save now, it will give error



Now go to Implementation details tab

In this tab we can select required fields for output value with options



Now Save

The created KRI implementation will be available in KRI Implementation catalog




Now we can use the created KRI implementation in Risk at Key Risk Indicators tab




Provide KRI Instance name and select the KRI implementation from F4 list

Select monitoring frequency, time frame then only Test Instance button will be enabled.



Now you can Activate KRI Instance, it will be available in Key Risk Indicators tab of Risk




We can create business rules for created KRI instance.

If you click on request localization of KRI instance then we cannot create business rules.

Status will become Localization Requested and Create button will be disabled.



Select the KRI Instance and Open

Click on Complete



Now status will change to Localized



Again Select the KRI Instance and Open

Click on Confirm



Now status will change to Active







Dear all,


We are using GRC system as central system for access request to users from different entities with different composite roles (The roles are created based on Business process and entity)


Approvals based on Functional area, Business Process and Company


Access request type: New


FI (Business Process) - XXXXXXXXXXXXXX (Composite role)-ABC Specific to Company/Entity-Approver A

FI (Business Process) - XXXXXXXXXXXXXX (Composite role)-DEF Specific to Company/Entity-Approver B


Approver Agent rule is based on business process, Functional area and Company in access request






Go to BRF+, select the application click on Activate button



Now close the BRF+

Go back to Generate MSMP Rule for process screen and re execute the same.

Now open tcode BRF+

Select the application, right click on it and select COPY




Click on COPY

Now Application ZAPPROVER_BP_FA101232 is available for us to use which is in inactive status


Now create decision table from application by right click on application




Click on create and Navigate to object


Now select the Result data object as GRFN_MW_T_AGENT_ID


Where T indicates for table


Now go to Condition columns select from context data objects from insert columns



Select Functional area,Business Process and Company


Click on OK




Click on Insert row   to provide values for table contents



Select Direct Input value for Function Area



Select the value from F4 (It will show the values which are maintained in SPRO)


SPRO>GRC>Access Controls>Role Management>Maintain Functional Areas





Function are can be anything it is just for identification of role in BRF+


We can define the companies in SPRO

SPRO>GRC>Access Controls>Role Management>Define Companies


Now the maintained functional areas will be appear in BRF+ to provide direct value input for functional area.



Select the functional area, relevant business process and company with required approver in USER ID field



Now check, Save and activate the decision table.


Now go to Function and select the decision table in Top Expression



Now check, Save and Activate the Function.

Function rule id will used in MSMP for agent rule to approve

  Rule ID: 40A8F0333BE91ED58F82621E018D40D7


Now approval will be triggered based selection of Business Process, Functional area and company (under user details) in access request


Hope this is useful if anyone has same/Similar kind of requirement.





Dear all,


The overview of this document is creation of risk in risk management with basics.

Hope it is helpful for others.


The prerequisites to create a risk we need to create required organization units and relevant risk categories

The organization units and Risk categories as created in master data work center



Risk can be created in Assessment work center.

Click on Risk and Opportunities





Click on Create to select type of risk



Where we can create different types of risks (Operational/Corporate) and Opportunity



We need to provide the risk name, select organization unit, risk category and select drivers and impacts for risk

To select the risk category from list we need to create required risk categories in master data work centers under

Risk and Responses at Risk Catalog



In master data work center we can create Risk Category and Risk Template, after creating, reflects under the classification hierarchy node and Risk Templates are created under risk category.



After providing required values we need to select Allow assignment is YES, then only we can select risk category while creating risk.

Now select the risk category for risk.



Now select, add the Impacts and Drivers


Drivers are nothing but events that could cause the risk to occur

Impacts are nothing but consequences if the risk event were to occur


We need to define Impacts and Drivers in SPRO:SPRO>GRC>Shared Master data Settings





Select Impacts and click on ADD

It will show the category and description which we maintained in SPRO


Repeat the same for drivers also.

We can assign multi drivers and impacts for Risk.


Now go to Roles tab in Risk

Initially roles tab does not show anything in role column to assign the owners



To assign role owner for risk in roles tab we need to maintain role assignment for entity in SPRO

SPRO>GRC>General Settings>Authorizations>Maintain entity role assignment




Click on Maintain entity role assignment, select the required entity with role



Now these role assignments will appear under roles tab of Risk



Now select the role and click on assign button to assign owners (we can assign single owners or multi owners also)


Now we can submit the risk

Once we click on Submit button then Risk status will be changed to active.






Workflow configuration


1.Perform automatic workflow customization

SPRO->Governance, Risk and Compliance->General Settings->Workflow->Perform Automatic Workflow Customization



Select the node Maintain Runtime Environment and click on F9 as below

click on F9.png

2.SPRO->Governance, Risk and Compliance->General Settings->workflow->Perform Task-Specific Customization


Expand the GRC PC component and make sure you define General/Background task for entries as below through 'Attributes' button.The workflow item will not be received if the task is not maintained.

The final screen will look like:

perform tasks pecific.png

3.Activate the Event Linkage

Event Linkage.png

Make sure all the relevant events are activated under GRC and GRC PC folder as below




4.Maintain the Event Queue


This is an optional setting. But its recommended to maintain , so the workflow run smoothly


SPRO->Governance, Risk and Compliance->General Settings->Workflow-> Maintain the event queue settings

Event Queue.png

Select the 'Switch on Event Queue' and click on Event Linkage as above


Verify the below events have 'Enable event linkage' selected. If any of the events have to be enabled, go to details button and enable the same


5. SPRO->Governance,Risk and Compliance->General Settings->Workflow->Maintain the event queue settings-> Click on Background job tab->Click on Schedule background job-> make sure the job is in Released status


background job.png

6.Enable event Trace- this is an optional setting but it is highly recommended to activate

Go to Transaction SWELS

Select Switch on




Workflow Troubleshoot tips:


1. Check the Planner log

Transaction SLG1

Object : GRPC

Subobject : PLANNER and enter the planner ID, in the external Id field along with the timeframe


The mesage associated with the log can give more information


2.Event Trace

From the Event Trace , you can determine if the workflow is triggered successfully or not

Transaction-  SWEL

Input the Case ID into the Creator Object instance (Get the case ID from the Planner log)


This will help to verify the receipt of the work item


3. In addition to these, make sure the relevant agent determination is in place

SPRO->Governance, Risk and compliance->General Settings->Workflow->Maintain Custom-Agent Determination Rules


4. Based on the Agent determination rules, check role assignment


5. Maintain the fallback receiver using

SPRO->Governance, Risk and Compliance->General Settings->Workflow->Maintain Fallback Receiver

If this is maintained, the workflow will get notified to the fallback user, making someone aware of these tasks


6.If there is an issue where there is no recipient for the task when the fallback receiver is not setup. In that case, the user can go to transaction SWPR

Based on the data, fix the role assignment


The core functionality in SAP GRC is Risk and Impact Analysis which will help the organizations to achieve their motto "GET CLEAN and STAY CLEAN". During one of the implementations I am working for we noticed lot of issues/bugs with the risk analysis functionality and based on our findings decided to write a blog which can be useful for others to consider below scenarios during implementation


Mitigation Policy Configuration - To restrict approvers from approving requests with Unmitigated Risks

First enable configuration parameter 1072 - Mitigation of critical risk required before approving the request as YES. This is applicable for both Critical Action and Critical Permission Risks.

Mitigation Policy can be configured using BRF+ to enforce the approvers to mitigate the risks before approving an access request. Under the Application Mapping, there is the Application ID: 'Request Mitigation Policy'. The BRF+ Function for this App ID is maintained by default. The BRF+ rule is created to identify which risk requires mitigation and which risk does not require. If there is no BRF+ Rule created for Mitigation Policy, then please remove the entry from IMG.


Once this entry is deleted, kindly execute the scenario again. Now the Approver cannot approve the request if risks are not mitigated. This was the purpose of un-checking the Task Setting 'Approve Despite Risks', so that risks that are not mitigated, do not get approved.

Note: If maintaining the BRF+ Rules then it is necessary to maintain the entry in SPRO.

If you want to make use of BRF+ mitigation policy with corresponding decision table and it works as below





Reference SAP Notes


1614290 - Risk Analysis Mandatory for Access Request

Locked and Expired Users

When a user account is locked or expired and when the same user try to create an access request then Risk Analysis/Impact Analysis will not return any results and this is as per design.

We identified few issues where users already have some roles assigned to their user accounts and now when they raise new requests with the roles which conflict with the existing roles or the roles requested in the request itself have violations but since users are LOCKED or EXPIRED risk analysis didn't return any violations.

We identified during our weekly risk analysis report that few users have SOD conflicts with the roles assigned to them and up on investigation this is the issue with LOCKED or EXPIRED users.

We enabled the below configuration to fix our issue

One User Request Per System

Risk analysis functionality has one limitation in access requests but SAP addressed it with One User Request Per System functionality.

Eg: Approve Purchase Request(PR) and Release Blocked Invoices

Now we have defined a rule in the system that "Approve Purchase Request and Release Blocked Invoices" as a HIGH SOD risk violation. But a smart user can raise two GRC access requests as below:

Request 1 - With Approve Purchase Request Role - Individually this request is clean and has "No Risk Violations"

Request 2 - Release Invoices Role - Individually this request is clean and has "No Risk Violations"

But once both the requests get approved, user will get access to the roles which have HIGH risk violations. This issue can be addressed in different ways:

1. Role Owners should take the responsibility when approving the roles to verify whether user really require access to that role,but system wise it will not stop them from approving these requests.

2. Enabling the risk analysis as MANDATORY before approving the request at last stage of approval so that if one request is first approved and user got the role 1, at least request 2 now shows the violations when risk analysis is run again before approving, but still if both the requests approved at the same time then still this option will not stop the user getting access to these conflicting roles.

To address this issue, SAP has given an option in the configuration which allows the users to raise ONE USER REQUEST PER SYSTEM at a given time. So, the users cannot raise a second request when there is a pending request for the same system which will help to address the issue mentioned above.

Since these days most of the customers of GRC having business roles we have identified this configuration having issues with the way it is working for business roles. We are able to get it fixed by SAP and enabled the below configuration in our system which has helped to address kind of issues discussed above

In EUP configuration, you can enable below option as One User per Request per System is part of the end-user personalization customizing so it is mainly based on the screen elements on the request.

Also implement below note to fix One User per Request per System EUP configuration issue with Business Roles.

2168444 UAM: One request per system not working correctly with business role and for IDM

Simulation Button in ARQ Request/Approval Screen

There is a button called SIMULATION in access request creation/approval screen. Actually risk analysis in ARQ will perform both Risk Analysis and Impact Analysis for the user and SIMULATION button also gives the same option.

We have noticed few issues in the way SIMULATION button is working and how using this button approver/risk reviewer can wipe out risk violations in access request though the roles selected in the request have violations

Steps to Replicate lssue with SIMULATION button:

1. Create a access request which has RISK VIOLATIONS.

2. At approval stage you can see the risk violations under RISK VIOLATIONS tab

3. Now change the approval status for the role causing violations to REJECT and then click on SIMULATION button and run risk analysis and click on APPLY button in Simulation screen.

4. Now all violations will be removed from the request. Now again change back the role approval status to APPROVE and then click on SIMULATION button and without running risk analysis and click on APPLY button from SIMULATION screen.

5. System doesn't prompt to run risk analysis and violations are wiped out

We haven't reported this issue to SAP but since this button access can be controlled using risk analysis authorization objects, we have removed this button access to our Users and Approvers from Request Submission and Request Approval Screens.

In order to hide the SIMULATION button from the Access Request creation screen, remove the following permission from the role:


Authorization Object: GRAC_RA

ACTVT:  70 (Administer)

Risk Analysis behavior during business role removal

We have identified a different risk analysis behavior during business role removal.

Below are the sequence of events:

  1. User has already been assigned with a Business role. This business role has a composite role which actually caused Critical Action risk violations for the user.
  2. To remediate this, requester raised an access request for Business role removal so that as part of removal the role causing violation also gets removed.
  3. Since the role which is creating violations is being removed via business role removal, ideally the risk analysis shouldn't show any violations in the request. But request still shows risk violations with the same role which is being removed from the user.
  4. To validate the behavior, we have created another request for removing composite role creating violations directly than through the business role and now request shows NO VIOLATIONS.

With the above steps we confirmed that during business role removal risk analysis behavior is incorrect. We have raised this to SAP and working with SAP to get it fixed.

Please implement the fix 2213465 - AC 10.X ARA: Risk Analysis for Business Role Removal

Risk Violations bypassed at Approver Stage

We have setup the configuration in such a way that no unmitigated access can be provision to the user in our production system.

All seems to be working fine however we found one scenario where approvers managed to bypass the risk violations and managed to approve the requests despite having violations in the request.








This is a product bug where if you close the browser it doesn't save the approval status change however save the risk analysis result based on the approval status. SAP has acknowledged this issue as bug and are providing the fix I will update this blog with the fix details once we get it

SOD violations are removed after re-running the risk analysis

<To be Updated>

Risk violations are not shown due to the roles not being generated

<To be Updated>

BRM Impact Analysis - Behavior

BRM Role change process involves Risk Analysis and Impact Analysis

1. Risk Analysis - To make sure that the role being created/modified don't have any SOD violations.

2. Impact Analysis - To make sure that the role being created/modified doesn't create any SOD violations for the users already assigned to it or the Composite/Business roles using it.


BRM User Impact analysis report shows the user level violations even though the assigned role validity is expired for the user.

Eg: User A has ROLE B. In BRM I am modifying role B and the changes being made will create SOD violations for user A with other roles assigned to user A. Then Impact analysis report should show those violations in the Impact analysis report which is the intended behavior.

But Role B assigned to user A is already expired validity. Even then Impact analysis shows that user will get violations with the role which is already expired.

In general, Risk/Impact analysis doesn't consider validity dates of the roles, but if Impact Analysis report gives the report with expired roles for the user then they are FALSE POSITIVES.

Raising this issue to SAP to understand from them the behavior as well Will update the blog with the details given by SAP

BRM Role Change and ARQ Request at the same time

This issue is one of the product limitation So, I wanted to understand from other consultants as well on how they are handling this scenario

1. Role Management Team is modifying a role using BRM in Development. As part of BRM process role changes are made and Risk/Impact analysis is done.

2. Risk analysis is done against the contents of the role in BRM and Impact analysis is done for Users assigned to this role and Roles (Composite or Business) using this role and Risk/Impact analysis shows no Violations (assume)

3. Now assume that there is a pending Access Request for the same role being modified through BRM and the user in the access request will get SOD violations because of  BRM role change but since the request is not yet completed and role is not yet assigned user will not be shown in Impact analysis report.

4. After Risk/Impact analysis phase in BRM there is certain time gap to finish approval and transport process and if the pending access requests with that role are approved during this time users will get that role but users will be shown in Risk analysis report after transporting the role modified through BRM.

So, there is a chance for risk violations to pass through because of this BRM role change and ARQ pending requests for the same role during that time.

Can the members of the community share their views on this scenario and how they are handling it as this is product limitation

Looking forward for all your inputs in improving this blog with all other additional details


Thanks for reading.


Best Regards,

Madhu Babu Sai

For the tips described below, I used a Process Control testing case.



A Control Test of Effectiveness was planned in my fresh GRC sandbox.



Note: These tips can be used in most of activities in GRC which use Extended Workflows.



System details:


GRCFND_A V1100 Support Package 06


GRCPINW V1100_731 Support Package 06




The objective is to check all the possible errors during the creation of a Control Test of Effectiveness.I am planning the task and correcting the issues as it comes.



First step is to create the central structure in NWBC -> Business Processes.


Central structure.PNG


After the central structure is created, the following must also be created:


  • Organization
  • Local Subprocess
  • Local Control



As soon as I created the objects, I try to open the local control and I receive an ASSERT_CONDITION VIOLATED.



Illegal case type – Case customizing was not configured in the system



Checking in table SCMGCASETYPE, the case types are not in the system.



This check is performed in Class and Method below:





This happened because I did not configured Case Management from client 000 into the copied client.



So it is mandatory after the client copy is performed to perform the Case Customizing.



To execute this task, the following KBA can be followed:



  • 2107509 - Transfer client-specific Customizing



How case customizing should look like:


Case Customizing.PNG



Now, we can create and display organization and local objects:






Control tester is assigned:



first control.PNG



It is very important to compare the HR role assignments in table HRP1852 with SPRO -> 'Maintain Regulation Role Assignment':



I am working with SAP standard roles, however if customized roles are used, these configurations can lead to confusion.



As shown above, I have assigned my user CONTROL_OWN as the control tester.



SAP_GRC_SPC_SOX_PRC_TESTER is assigned to SOX regulation.






Checking this role in HRP1852, I can see my users there:






CONTROL_OWN has 2 entries as it is assigned to 2 different objects.



With authorizations set, it is time to schedule the plan.



Creating Plan in Planner Screen



First Step: Plan Activity: Test Control Effectiveness



Second Step: Choosing Regulation:


Note that there is no Regulation shown in the Drop Down list




Checks to know whether this is not a configuration issue:



  • Is Regulation created?



If not created, it must be added


regulation 4.PNG



Relate regulation to Plan usage in SPRO must be configured. Test Control of Effectiveness is configured to both regulations:



If not created, it must be added



regulation 2.PNG



Check whether ‘Need Regulation’ is selected in Plan activity for Process Control



If not created, it must be added



regulation 3.PNG


If all these steps were followed then, the following SAP note must be implemented:



  • 2072420 - Regulation is missing while creating test control effectiveness in the Planner Note After processing with these steps, the regulation is there:

Note After processing with these steps, the regulation is there:



Third Step:

The organization, which the plan will be triggered, needs to be selected.

Organizations available.PNG

Fourth Step:

The local object will appear for selection, unless you have already scheduled a plan for the same organization in the same time frame.

Control details.PNG

Fifth Step:

Checking recipients:


If the recipients column is empty, the work items will be addressed to the fallback receiver.



The fallback receiver will start to receive the notifications for three reasons:

  1. If the user is not assigned to a role in HRP1852
  2. If the role is not mapped in SPRO -> Maintain Regulation Role Assignment (when using role regulation specific)
  3. If the user does not exist anymore in the system



If you have users assigned in HRP1852 and not in Maintain Regulation Role assignment, it means that you are working with Cross Regulation roles.



There is one issue, which was introduced in Support Package 18 of GRC 10.0.


All the work items are forwarded to the fallback receiver when customer is using cross regulation roles.


This issue is corrected by the following SAP note:


  • 2154060 - CCM Owners not receiving Issues created by Automated Monitor

Plan Activation and Completion:

If you want to debug the activate Plan button, set a breakpoint in the following Webdynpro Component, View and Handler:


Webdynpro ComponentViewEvent Handler

After job activation, the planner monitor shows the jobs status as "With Exceptions":

with exceptions.PNG

This is because the workflow was not triggered.

If you check, no workflow items were created in transaction SWIA for the time frame the plan was activated:


Configuring workflows according to SAP note 1621649:


  • Automatic workflow customizing
  • Perform Task-Specific Customizing


In my system, the task specific customizing was not configured. After configuring it:


Assign agents.PNG


Event Linkage also needs to be performed:




The following objects must have the event linkage as well as event queue





If the event queue is activated, the event queue job must be enabled to handle situations where large events are triggered at the same time.


event queue.PNG



One good tip is to enable the workflow trace through transaction SWELS



even trace.PNG

The workflow trace can be seen through transaction SWEL.

Triggering the workflow again:

The logs can be seen because SWELS is activated:




In transaction SWIA, all the workflows steps and workflow logs are available:


Workflow started.PNG


  • Workflow started – Plan was activated and workflow created
  • Workflow completed – background job GRFN_BP_SCHEDULER is completed
  • Sub Workflow handler started – WS75900005
  • READY – A task of the sub workflow that requires a dialog user to perform an activity

If you press shift + F8 on this screen, you can see workflow logs that present the historical path of the plan. In the workflow log, you can see the agents that are waiting for the work item:




Clicking on the agents button, you can see:


SOX control owner.PNG


The symbol at the side of the user’s name means that the work intebox is going to the user’s inbox.


By pressing Shift + F9, you can access the workflow list with technical details



Workflow log.PNG



Checking agent's work inbox:



When logging with the agent and accessing his/her work inbox, the work item is there waiting for actions:



test of.PNG

The case is available also in table GRPCCASETL

The case reached user's inbox as the Agent is correctly assigned in SPRO -> Governance, Risk and Compliance -> General Settings -> Workflow -> Maintain Custom Agent Determination Rules:

SOX tester.PNG

If you pass the evaluation, you can check the table mentioned above to see detail (GRPCCASETL).





To be continued ...


CLICK HERE for the Part II***

This is a continuation of the troubleshoot guide for planner. Click Here to access the part I of the guide.




Reporting an issue:


Issue is created as I set the test to fail status:




The Owner of the issue is I827528.


Just the Control Owner or the ICMAN have authorizations to Receive an Issue:



This user must have power user roles or must be the control owner (in this case, as I am working with SOX regulation, the user must be a SOX control owner).



The business event responsible to deliver this task is:





Accessing the task to remediate the issue:





This information can be seen in table GRPCCASEIS.






Creating a Remediation Plan:



When you assign a remediation plan, you set the user you want to be the owner during creation:


Remediation plan.PNG


In CONTROL_OWN’s inbox, there is a new task:


crate remediation.PNG



Test was set to complete. You can also check this information in table GRPCCASEPL.







We can see the progress of the workflow in SWIA:



The yellow highlights are the tasks which were completed.


Workflow log.PNG



If you need further information about the step you are in, you can access the task information in the container of the work item ID.



Workflow details.PNG



if you have some doubts on the workflow information, you can start debugging sessions based on the Task information:







Upon clicking on the highlighted task TS75900020, I can see the following screen:



test log.PNG



We know Class and Method that are used when this event is triggered. Setting a breakpoint at this point allows users to debug this event.



Going back to the Close issue activity:



After pressing submit button within the work item, the status of the work items goes to Reserved



Close issue.PNG



The status reserved will continue there until the remediation is not closed by the owner.

After completing the test, the evaluation is sent back to the SOX Control Tester for a Re-Evaluation.

If approved, the process is closed.  The test result is set to Pass.


Process is completed in Planner Monitor.

Process is completed.PNG

If you check SWIA after performing all these steps, the whole workflow is completed.

More information will be added upon contribution.

Dear all,


I referred some SAP notes,KBA's,threads which are answered by Alessandro Banzer and Madhu Babu,found some standard behavior(As we know) of GRC access controls product.

Thought to share with you all,hope its helpful.


1.Transaction description is not available in consolidated log report in EAM.

Ans: The transaction description is not available in the consolidated report due to performance issue. As in 10.0 there are multiple systems and logs come from multiple systems of different basis release. Now for showing transaction description RFC calls have to be made for each system. So it was found that fetching the transaction description for each system is degrading the performance of the log report, hence the per the design the transaction description has not been supported in EAM reports

2. Results mismatch in risk analysis in Reports and Analytics and risk analysis in Access Management

Ans: The risk analysis in Reports and Analytics  tab is always offline analysis and hence you should have run the Batch Risk Analysis to populate the violations data.

The risk analysis in Access Management is real time analysis.

Both the results are same only when the batch risk analysis ran and completed successfully.


3.If any role from the User Account has been rejected or removed, UAR notifications are not sent to the User for whom the access review.

Ans: As per the standard functionality, notifications to users are not supported

If you want to send notification to user, then go for customization

Note: 2138427

4.Removal of direct and indirect role assignments using User Access review

Ans: 1.An indirectly assigned role, particularly through HR, (Position based), cannot be removed from SU01 directly.

         2.GRC requires a system call from HR trigger, (Position change), to remove the indirectly assigned roles.

          (Indirect role can be removed from PO13,but cannot be removed in SU01.)

         3.From GRC product functionality, a UAR request will only remove the direct assignments

Note: 2066401

5.We cannot use functional area as attribute for role in BRF+ rule,as Functional area is a table.  It is possible to maintain multiple

functional areas in roles,so it is not possible to directly use functional area as attribute for roles in decision table.

     Instead we can use business process or create a table operation to read functional area of the roles using BRF+ procedure.

Note: 1890452

6.While updating the user assignment from Business Role Management (BRM), the change document in plugin system shows that the updated user-id is,the user who executed the update assignment from BRM and not SM59 user.


The change document in plugin system would show that the updated user as logged in user, who executed the update assignment and not SM59 user-id.

This is to track that who actually executed the provisioning.

7.Change log reports does not give any results for user id search

The User ID filter in the Change Log Report is intended to search for the changes made by the specific user in the USER ID field,on any particular

object within GRC NWBC.

     The Audit logs shown for the Access Request would not be captured in this report.

This is only intended to capture the changes made to the objects within GRC. Check for the Configuration Settings in
IMG for Access Control, it contains the parameters to enable the logging for various GRC objects like Risks/Functions (within ARA functionality), Roles (from within BRM) and similar.Objects under Param Group "Change Log" in GRC are under the scope of this report. (Available in IMG - Maintain Configuration Settings for Access Control).

8.Changing Mitigation control ID for an assignment, creates a duplicate mitigation assignment rather than updating old assignment.

It is a standard behavior of system to create a new assignment based on control ID entered. If any change is done to control ID, it will trigger a new assignment. We can do a mass change with the help of program GRAC_UPLOAD_MIT_ASSIGNMENTS and GRAC_DOWNLOAD_MIT_ASSIGNMENTS.

Note: 2026425

9.An error message 'Mitigating ID is not unique' appears when the approver tries to approve the control id workflow request second time wherein Control Id is same as in the first workflow.

If the workflow is ENABLED - the error happens only while approving the work item.If the workflow is NOT enabled - the error is shown at the time of creation, when you press SAVE.

This is as per the Mitigation Control Workflow functionality - it allows to submit 2 Control IDs with same name,

but does not allow approval. (This scenario can be very business specific, should avoid creating controls with same name/IDs).

We cannot show any error message during control creation in case of workflow, because Control Id will not be
generated till the time it is completed.

Once the workflow for Mitigation Control has been initiated and sent to the Approver's Inbox, it will not show this error message until

this first workflow is completed and Control Id is created.

When the two Mitigation Control Workflows are created and sent to the same approver, the approver will be able approve only one workflow. Second  time, when he will attempt to approve the second workflow which has same control name, it will display the error message saying 'Mitigating ID is not unique', because there is already a Control Id with same name existing in the system.


IMPORTANT: If the control is created WITHOUT WORKFLOW, this error message appears at very beginning and therefore, system will restrict the duplicate, the second time.

Note: 2130931

10.Mitigation Controls change History

Mitigation controls are integrated with Process Control, and whenever a new mitigation control is created, the entry is saved in tables starting with HRP*,example:      HRP1000 holds the mitigation control object ids.

These object ids are converted from Process Control ID to Access Control ID, to be displayed in the Access Control screens.

There is no change history available for it.

Mitigation control changes can be tracked by having the "Mitigation Assignment" and "Mitigating Control Maintenance" workflow requests.

In order to have the control changes and assignments to generate workflow requests, configuration parameters 1061 and 1062 should be set to YES.

     Mitigation assignments for Roles and Users are stored in below tables

      Profile: GRACMITPROF

Note: 2027376

11.When a user request is created for a user who already has mitigation control assigned, the SOD detour path does not get initiated.

As per the design, if a mitigation control is assigned to a risk then the SOD detour is not initiated.

If a user access is altered and new risks arise then detour would be initiated.

But for existing risks where the Mitigation control is already assigned, the request will not take the SOD detour.

Note: 2073883


12.Difference in the results displayed for "Access Risk Analysis" and "Access Risk Assessment".

Check the "Permission Level" check box before running the "Access risk Analysis".This is required because "Access Risk Assessment" always runs at Permission Level by default and to keep the results in sync with "Access Risk Analysis", it should also be run at "Permission Level".

Note: 1689067

13.HR Triggers not works multiple positions for an employee.

HR Triggers functionality currently does not support fetching roles for multiple positions.

SAP HR storing only one position in PA0001, the GRC code is prepared to receive only one job position from this table.This means there is not such a LOOP to go through the found entries in PA0001, the code only reads from it expecting only one entry.

Note: 1990364

14.Behavior of user sync if two different systems are having same User ID with different user name


     As per Application behavior, user sync depends on the User Data Source


Say you are having 2 systems X and system Y. If none of them are listed in the user data source then the latest

connector sync will have the data in  GRACUSER table.

System X: User ID ABC: User Name: ABCX

System Y: User ID ABC: User Name: ABCY.

Run user sync for system X.

ABCX gets updated in GRACUSER table.

Run user sync for system Y

ABCY gets updated in GRACUSER table. In this case, the older value ABCX would be overwritten by ABCY as none of the system is

listed as a Detail Data Source.


If connector X is maintained in detail data source connector.

Then on running user sync for connector X, ABCX will be updated in GRCAUSER table

On running user sync for Y, ABCX will remain as it is as its connector X is maintained as a User detail data source in IMG.

Note: 2041653

15.When the firefighter tries to use firefighter logon pad from web interface (NWBC/GRC Portal) then Firefighter ID logon is not happening


Firefighter ID session is supported from SAP GUI. One can login into GRC box via SAP GUI and then use GRAC_SPM/GRAC_EAM transactions for firefighter ID logon AND NOT via Web interface.


Note:   2059142


16.When request for Risk or Function changes (using Risk workflow /  Function Workflow) reaches to the approver, the changes done in the risk/function is not being highlighted to the approver.


Means the approver is not able to check what changes have been done to the Risk / Function


As per the product design, all the change history is not visible for an approver. If Approver would like to check the changes made for Risk or Function, he/she can check it's change history by opening that particular Risk or Function in Access Risk.


Note: 1907345

Looking forward to add more into this page so that its easy to refer and helpful for others.feel free to add if you have any such information.



This is a guide to provide compatibility between GRC components in all GRC systems. As there are many questions raised regarding compatibility of GRC with plug-ins, SAP_BASIS versions and enhancement packages, I decided to put this information all together in one single guide. Starting from Virsa to GRC 10.1.

Search for compatibility information in service.sap.com/pam


Table of contents


Virsa 4.0


This version of virsa is out of maintainance since 15.03.2014.

Access the Migration Guide if you want further instructions on how to move from 4.0 to 10.0.

If you want to know what will be migrated:

Access Control 4.0 Migration to v10.0 - Governance, Risk and Compliance - SCN Wiki

Compatibility of Virsa 4.0 with Netweaver Releases:

  • 2072255 - Is VIRSA 4.0 Supported on EHP 7?

Virsa 5.3

Compatibility of Java Packages and VIRSA components:

AC 5.3 Java SP15-SP21 can be used with VIRSANH SP16 to 22 (SP10-16 for 710/730) for those customers that are not able to upgrade both Java and ABAP stacks simultaneously.

Compatibility of Virsa 5.3 with Netweaver Releases:

  • Is Virsa 5.3 compatible with Netweaver 7.4 (SAP_BASIS 740)?
    • Implement the following SAP note to make 5.3 compatible with NW 740:
      • 1918850 - GRC AC5.3 plug-in Compatabile for SAP_BASIS 740 release


  • VIRSAHR and VIRSANH is compatible with NW 730 from SP17 onwards.
  • VIRSANH and VIRSAHR is compatible with NW 711 after implementation of 1675165 note.


Be aware that Virsa 5.3 will be out of maintenance from 31.12.2015.


From 5.3 to 10.0


If you are migrating from Virsa 5.3 to GRC 10.0 you need to know that:

  • GRC 10.0 does not work with front-end Java anymore. The new GRC model is all based in ABAP and ABAP webdynpro
  • A new model concept was adopted (Foundation system and plug-ins systems). The foundation centralizes the master data.

To those who use Virsa 5.3 and are migrating to a new GRC version (10.0 or 10.1), the following guides and KBAs can be used during the migration:

  • Guide to migrate from 5.3 to 10.0
    • You can also find in this guide, information on how to export data from 5.3 Risk Analysis and Remediation and Superuser Priviledge Management to GRC 10.0.

If you still need to use Java front-end and have installed GRCPINW in the back-end system, you will see that:

  • GRCPINW overwrittes VIRSANH
  • GRCPIERP overwrittes VIRSAHR


After support package 04 of GRCPINW, the 5.3 function modules are included (support package 04 of GRCPINW and GRCPÍERP is equivalent to VIRSANH Support package 16 and VIRSAHR Support package 14 respectively. As the front-end is still based on Java, the minimum SP level required for the front-end system is 15.



From 5.3 to 10.1

All GRC 10.1 Support packages have 5.3 code included.



This is stated in the following KBA:

  • 1590030 - GRC 10.0, 10.1 Plug-in & AC 5.3 VIRSA (RTA) Co-Existence


Access Control 10.1 plugins are also supported with an Access Control 5.3 Java front end. You must be at minimum AC 5.3 SP22 for the front end and 10.1 SP07 for the plugin in order for this scenario to be supported.

Access Control 10.0


Below, you can find the most current support packages for GRC 10.0 (from SP 11 to SP 19) and their compatibility with components on the very left column.

PS: The support packages highlighted in green are relevant to GRCFND_A V1000.


10.0 Support Packs


SP 14SP 15SP 16SP 17SP 18SP 19SP 20SP 21SP 22SP 23
GRCPINWSP 14SP 15SP 16SP 17SP 18SP 19SP 20SP 21SP 22SP 23
GRCPIERPSP 15No SPSP 15SP 16SP 17SP 18SP 19SP 20SP 21SP 22
710 or 730
GRCPINWSP 14SP 15SP 16SP 17SP 18SP 19SP 20SP 21SP 21SP 22
GRCPIERPNot Av.Not Av.Not Av.Not Av.Not Av.Not Av.Not Av.Not Av.Not Av.Not Av.
731 or 740
GRCPINWSP 05SP 06SP 07SP 08SP 09SP 10SP 11SP 12SP 13SP 14
GRCPIERPSP 14No SPSP 15SP 16SP 17SP 18SP 19SP 20SP 21SP 22


* Prior to GRCFND_A SP10, the GRC system and all plug-in systems must be on the same support pack level. As of GRCFND_A SP10, backward compatibility has been introduced. Please refer to SAP Note https://css.wdf.sap.corp/sap/support/notes/1821368  for more details.


Compatibility of GRCFND_A V1000 with Netweaver Releases:


  • GRC foundation is compatible with Netweaver 702 Support package 06 onwards;
  • GRC foundation is also compatible with Netweaver 731 since GRCFND_A is on Support package 08;
  • GRCPINW and GRCPIERP is compatible with NW 730 from SP05 onwards.
  • GRCPINW and GRCPIERP are compatible with ECC 6.0 EHP7 (see requisites in SAP note 1820906)


Click Here to check what's new in GRC 10.0.



Access Control 10.1


The below tables shows the Compatibility Matrix in GRC 10.1.


PS: The support packages highlighted in green are relevant to GRCFND_A V1100.


10.1 Support Packs
SP 04SP05SP06SP07SP08SP09SP10SP10SP11SP12



Important Information:


- Please see SAP Note 1855404. There was an issue with the SP10 package and SP11 needed to be created which caused the 731/740 GRCPINW SPs to be out of sync with GRCFND_A and GRCPIERP


- When importing GRCPINW V1100_731 from SP 10, system will request Support Package 11 to be applied (Using MOPZ or updating directly from SAINT/SPAM). System is picking up the correct support package. It means that SP 11 will be installed in 731 plug-ins systems when foundation is still on Support package 10.



For GRC 10.1 Foundation and GRC 10.1 Plugin systems, it is recommended to have both systems at the same level, however GRCFND_A 10.1 will be compatible with all 10.1 plugins as long as the plugin SP level is equal to or lower than the Foundation. (ex: GRCFND_A cannot be on SP02 while the plugin is on SP04).


Compatibility of GRCFND_A V1100 with Netweaver Releases:


Access Control 10.1 GRCFND_A needs to be installed on NW740 (at least Support package level 02) and it is compatible with GRCPINW (700, 710, 730, 731).


Click Here to know what's new in GRC 10.1.



Information on Migration from GRC 10.0 to 10.1


You can connect to AC 10.0 Plug-in (GRCPINW & GRCPIERP) from AC 10.1 front-end as long as support pack of AC 10.0 plug-in is SP10 and above.


However, some new AC 10.1 functionalities such as Organization Rule Wizard, Custom User group creation and EAM DB log collection will not work.


What Databases work with GRC 10.1

(This information was brought by Kelly Ann Erickson):


First note that GRC 10.1 is installed only on SAP Netweaver systems beginning with SAP_BASIS version 740.


See installation guide for patch level needed for installation.


As for the database that works with SAP system, see the Product Availability Matrix to see which database versions are supported.  GRC works with

whatever databases NW 7.40 supports.


  1. Go to Support Portal: https://support.sap.com/home.html
  2. Then navigate to Release, Upgrade & Maintenance Info > Product Availability Matrix. Click on orange box labeled Enter the Product Availability Matrix.
  3. Then click on Display all Product Versions. At the top is an open search field, enter SAP Access Control 10.1 and click on the results to view.
  4. Click on General Information > Related Product Versions.  You will see a box labeled Required Product Versions.  In that box scroll down to SAP NetWeaver 7.4 and click on it.
  5. In next screen Click on Technical Release Information and you will see Database Platforms on the menu bar.  Click on it.


GRC 10.1 and Netweaver 7.5


GRC 10.1 (foundation system) is supported in NW 7.5 according to the following KBA:


2308327 - Is GRC 10.1 also supported for Netweaver 7.5?





The tables information was taken from:

  • 1352498 - Support Pack Numbering - GRC Access Control


The Netweaver compatibility was taken from:

  • 1680268 - Compatibility of Access Control Packages


The documenation was taken from:

  • 1243085 - Available Documentation for GRC Access Control


The co-existance of components (5.3 and 10.0 or 10.1) was taken from:

  • 1662113 - Using Access Control 5.3 with your 10.0 and 10.1 plug-in systems


The Migration from 10.0 to 10.1 was taken from:

  • 1590030 - GRC 10.0, 10.1Plug-in & AC 5.3 Virsa (RTA) Co-Existence

When we execute the log report in EAM, we would like to see the report based on which we can take a decision.

But, sometimes we get to see errors when we execute the log report in EAM. In this document, Please find some of the common issues along with solutions here.

Error No: 1

When we are executing consolidated log report under reports and analytics tab, we could able to see only transaction information not able to see descriptions of those transactions


  • The transaction description is not available in the consolidated report due to performance issue.
  • As in 10.0 there are multiple systems and logs come from multiple systems of different basis release.
  • Now for showing transaction description RFC calls have to be made for each system.
  • So it was found that fetching the transaction description for each system is degrading the performance of the log report, hence as per the design the transaction description has not been supported in EAM reports.
  • This can be found in SAP NOTE : 2010385


Error No: 2

Transactional logs are not giving any data



  • This error occurs due to missing authorization issue.


1. Assign the authorization S_TOOLS_EX to your RFC user in the target connector

2. Along with the Authorization issue, This SAP NOTE will help you: 1775432


Error No: 3

When the Consolidated Log Report is executed, the following error is displayed.



  • This kind of error occurs if the Service is deactivated. To solve this error:
  • Go to transaction SICF > Default host > SAP > BC> webdynpro > SAP > GRAC_UIBB_SPM_Tcode_REPORTS to check the service status.
  • Right click on this and activate it.  Now you will be able to open the "Transaction and session details" page without any error.


Error No: 4

Consolidated Log report is giving the error showing the following error:




  • There kind of error occurs due to large volume of data or due to some other reason the extended memory is used up and so the TSV_NEW_PAGE_ALLOC_FAILED exception is coming.

  • For resolving that problem, it is necessary to configure the memory parameters correctly. Refer to SAP Notes 146289 and 425207 to check the parameters to be maintained. This memory utilizing issue is caused by too much of data selected. So, If changing the parameters cannot solve the problem, then reduce the data selection by creating variants for log display.

Error No: 5

Reason code and Activity description is missing in reports




  • This error is due to missing of the text entry in T-code SE75 for object 'GRC'.
  • To Resolve this issue: Refer to SAP Note No: 1982125


Error No: 6

Audit Log Report is not displaying any data




  • The following reasons could be the cause:
    1. 1. Firefighter log sync job has not been run.
    2. 2. There are no records in the plug-in system for the transactions: SM20, SM21 and SM49



Everyone is free to correct the mistakes in this and

Add more issues of this type into the document.



Deepak M

This is a minor tip to check some access parameter is SPRO,


In “AC Configuration Settings” screen in SPRO as you can see it is not possible to use CRTL + F  (this was really annoying me)





But if you click in Printing button (CRTL + P)  the screen reorganize and you can use the CTRL + F




I know it's a little tip , but every colleague I showed liked





Rafael Guimbala

To exclude objects from Batch risk analysis (Dashboards) choose option Maintain excluded objects under :


Batch Risk Analysis >> Access Risk Analysis >> Access Control >> Governance, Risk and Compliance >> SPRO


There is this options:




To exclude one role (example role: Z_TEST):





If you want to exclude a range there is two ways:




Please Noticed the using of " * " the second line will not exclude any objects:






Dear all,


Find the information on dumps and errors in process controls,mainly these issues with missing configuration,missing authorization.

Hope its helpful.


1.Case Management


     SPRO->Governance, Risk and Compliance->Process Control->Cases->Check Customizing for Case Management


    Types of errors:

  1. Throws a dump “ASSERTION_FAILED CL_GRFN_API_IDENT=============CP”when opening controls in organization under master data
  2. We cannot open any Ad-Hoc Issues from My Homework center.
  3. Throws a error with “GRFN_ENTITY_API:102” when schedule automated monitoring job


     Solution: The entries should be green for case management, if not transport them

     SPRO->SAP Net Weaver->Application Server->Basis Services->Case Management->Set Status Administration->Create Status Profile and

     SPRO->SAP Net Weaver->Application Server->Basis Services->Case Management->Define Case Types


     Check Note 1526732 - Transfer client-specific Customizing


2.Configure Email Inbound Process


     SPRO->Governance, Risk and Compliance->Process Control-> Offline Work Process -> Configure Email Inbound Process


     Type of error:Job GRFN_OWP_SUB_JOB_SENDER for Offline Working Process throws error

                    “Assertion failed" dump in class  CL_GRFN_OWP_Deliver


Solution: SPRO->Governance, Risk and Compliance->Process Control-> Offline Work Process -> Configure Email Inbound Process

Insert a row with Communication Type as Internet mail.

Enter a valid Email Address in the recipient address column.

Enter the document class as "*".

Enter the Exit name - "CL_GRFN_OWP_DELIVER".

Enter the call sequence.Save the settings.


Note: Assign email id to all users who will be receiving notifications.


               Check Notes 1866809, 455140

3.Maintain Entity Role Assignment


          SPRO->Governance, Risk and Compliance-> General Settings -> Authorizations -> Maintain Entity Role Assignment


          Type of error: While submitting Ad Hoc issues, throws dump “The ASSERT condition was violated


          Solution: SPRO->Governance, Risk and Compliance-> General Settings -> Authorizations -> Maintain Entity Role Assignment

                    Click "New Entries"

                    Select the Entity " G_AI"

                    Select the Role "SAP_GRC_FN_ADISSUE_PROCESS"

                    Select check box "Unique"




          SPRO->Governance, Risk and Compliance->Process Control-> Scoping


          Type of error: 1.Throws dump “CL_GRFN_API_TIMEFRAME=========CP”while creating account group in master data


                                 2.Throws dump “CL_GRFN_API_TIMEFRAME=========CP”while running the MDUG (Master Data Upload Generator)

                                   in order to upload a template


          Solution: SPRO->Governance, Risk and Compliance->Process Control-> Scoping-> Maintain Scoping Materiality Analysis Frequency


5.Missing authorization


Type of error: Throws dumps “CL_GRFN_API_IDENT=============CP “for master data change reviewer in work inbox


Solution: Approver should have DISPLAY Authorization to the entity CONTROL and XCONTROL


6.In Programs


               Type of error: Execution of program GRFN_CHECK_CDF ends with dump “ASSERTION_FAILED


Solution: T code: SM30;

Inform T7771 as the Table/View and click on Maintain;

Select the custom info type used in the CDFs;

Click on Time Constraint on the Left Side Panel;

Make sure that Time Constraint field has value 2 or 3. Value 1 cannot be used in GRC;

If necessary, change the value of Time Constraint and save.


               Type of error: program GRPC_MASS_PROCESS_ASSIGNMENT throws dump


               Solution: While executing the program GRPC_MASS_PROCESS_ASSSIGNMENT, make sure

               that the organization unit used here is not locked.




Filter Blog

By author:
By date:
By tag: