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 request1071YESEnable risk analysis on form   submission
Risk Analysis10232(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 request1073YESEnable 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


It may be difficult to believe that 2015 is flying by so quickly, but planning is already underway for SAP TechEd 2015 in Las Vegas.

SAP TechEd logo.png

The design team for the ASUG education sessions this year is Tammy Powlas, ASUG volunteer Kristen Dennis, and myself, along with our SAP Point of Contact Peter McNulty. Tammy posted a very informative blog in the Business Intelligence space to entice BI people to start thinking about presenting.,Plan Now for Call for ASUG Speakers for SAP TechEd Las Vegas . I am not going to repeat everything she already said so well, but I do want to encourage you to review her post and to consider presenting.


You might be thinking, I don't see a GRC track at TechEd, and if you are thinking that, you are right: there is not a track solely dedicated to GRC. However, the Security, Secure Development, and Configuration track covers SAP security products as well as standard features, capabilities and recommendations. In this track we welcome and encourage customers to present on SAP Access Control, SAP Identity Management, SAP Threat Detection, SAP Single Sign-on, security redesign projects, secure development and configuration - really, just about anything related to the security function in your SAP landscape. Lessons learned from implementations and upgrades, tips and tricks, believe me when I say that ASUG's Design Team wants to offer more than just SAP HANA all the time. Certainly, if you have a SAP HANA security success story, we welcome it, too, but think bigger. We have a lot of education slots to fill, and the feedback we have received is that customer presentations are highly desired. So put on your thinking cap now and get ready for the call to open on April 20.


Here is the expected timeline  (Source: SAP):

TechEd Timeline.png

ASUG members who are not customers are also welcome to submit an abstract; just keep in mind that customer presentations are preferred. If you are a consultant who had a successful security or GRC project, perhaps you can persuade one of the customers on the team to present and tell your mutual success story. I hope to see many abstracts submitted on security, IdM, GRC, and other related topics.

From my experience, in many companies country risk is treated separately to risks registered in their Enterprise Risk Management (ERM) framework and reported independently to the Board - most often by using political risk maps.


To me, this is an error as country risk has a direct impact on operational risks and this impact should be materialized so that the correct mitigation strategy can be decided and applied.


First, let me define what I mean by country risk. To me, it is the potential negative events arising from political, economic and societal uncertainty in a given country.

Many equate country risk to political risk but as you can see in my definition, I believe that political risk is only a component of country risk - albeit an important constituent - it does not cover its complete scope.


This concept is very mature within investment companies as it is usually one of the criteria applied when deciding whether to invest in one country or another but I think it applies more widely.


All companies face a country risk, some with a higher level than others but all companies operate at least in one country. So, even if this country is rather “stable” today, this risk should still be recorded, assessed and monitored as situations can evolve sometimes more rapidly than expected.


Direct links with your ERM framework


Consider the following situations:


  • Do you have operations? If yes, then regulatory changes decided by a government can affect you directly and subject you to new regulatory obligations;
  • Do you have production facilities? If yes, in extreme cases, you may be facing unilaterally decided nationalizations;
  • Do you have sales activities? If yes, then these can be significantly impacted by the national economic climate, especially if you are in a B2C business;
  • Do you have employees? If yes, then these can be at risk if there is a sudden outburst of unrest. On a less drastic scale, a change in labour laws can also directly influence your HR organization and even decrease your profitability;
  • Do you invest in innovation? If yes, you may have to agree to technological or knowledge transfer to be able to supply the local market with your products, increasing your competitive risk.


In another post (The Critical Role of Marketing Executives in the Risk Management Process) I had discussed the fact that reputational risk is a direct result from other risks. Well, I believe that country risk is at the opposite side of the spectrum and can be a trigger for many operational risks.


As such, even in low risk profile countries, assessing and regularly reviewing the risk level is part of a sound risk management practice.


How to assess country risk?


There isn't one common agreed measure to assess this risk category but I would like to try to suggest a simple method:


  • Likelihood of occurrence: here would be assessed the combined probability of potential evolution of the political, economic and societal conditions. Some countries have a stable political environment either because it appropriately represents the opinion of the population or because the government secures its re-elections by different means. Nevertheless, this does not mean that societal conditions can’t evolve rapidly, as precisely illustrated during the Arab Spring. Taking into account these three criteria will therefore result in a more truthful probability of occurrence;
  • Impact: here would be documented the potential direct impact of a country risk for your company and its different activities carried out in the country: manufacturing, sales, R&D, etc.;
  • Speed of Onset: here would be assessed the velocity with which the risk can occur. For instance, in countries where political representation effectively embodies public opinion, a change in the political landscape can be rather long compared to personalized regimes where a change in leader can bring a system down rapidly. This is likely to be the most difficult criteria to assess, but publicly available geopolitical analyses can be a good starting point.


Then what?


Here is why I believe political risk maps can’t be used as is by companies as country risks: not all companies will be affected in the same way by changing events. Integrating this risk category in your ERM framework means that you can not only assess a macro-impact at your company level, but that you can also document the influence of this country risks on your objectives and on other risks in the ERM framework: potential effects on your supply chain, manufacturing activities, sales process, etc.


From there, appropriate mitigation strategies for these operational risks can be defined and implemented.


The intent of this post is certainly not to say that all countries are at risk, far from it, but that internal and external influences can lead to a rapid change in the rules of the game for your organization and its activities and that this should be monitored so as to avoid being taken off guard.


What about you, do you monitor country risk?

There are frequent questions why "Custom Field" option is disables when the Details are not saved while creating an Role via BRM application.


  • The Details (First Phase) are becoming mandatory because the Role ID is required to initiated the BADI IF_GRFN_API_CUSTOMFIELD_BADI, then BADI can become active on the Fields that are desired by Custom Fields.


  • Logically the Post Exit method POPULATE_ROLE_ATT in ZFILL_ROLERELAT_CUSTFIELDS is not called when creating a role in BRM application. Because the Role ID is required for the second phase.


  • The functionality flows, first phase the basic attributes of the Role eg Role Name has to be defined and in second phase enhanced attributes would be defined like Owners/Approvers then BADI for Customer Fields is called.

Hi GRC Community


Do you get frustrated by functionality that it lacking? Do you see something in the solution and consider it an incident but are then told it’s by design? Are you creative and love to continually improve this product? Are you stuck in a situation where you have to minimise custom developments for the GRC system? Are you nodding your head in agreement? Are you the type of person who strives for continual improvement? Is that a Yes?


Then time to take a journey to the SAP ideas Place for the GRC Products. This is your opportunity to have your voice heard and get the support of the community. It is a direct connection to the SAP GRC Product Owners – a great opportunity that can be hard to come by.


pic ideas.png

Here’s the Ideas Places for GRC component:

SAP Access Control: Home

SAP Process Control: Home

SAP Risk Management: Home



Create Your Idea

  • You will need to register your account if you have not done so already
  • Assumption you have searched to make sure there is not duplicate idea
  • Make sure you create it under the appropriate category
  • Take your time to provide as much information as possible
    • Did the idea come about from a SCN thread?
    • Did you get requested to raise it in response to being told it’s not an Incident in Marketplace?
    • Do you have screen shots or uploads to better explain your example
  • Let your network know about your idea and get their support



Vote and Comment

But hey, if you’re not an Ideas person then you get still join in. If anything, you are integral to an idea being considered. Vote in Support. Vote in Disagreement (some times the ideas have flaws). Just Vote! Add your feedback in comments.


SAP GRC team will only review ideas that have at least 10 votes.



GRC Product Team Listens and Reviews

The regularly review the Ideas Space and their next review is February 20 2014 – less than 10 days away. They will only review suggestions with more than 10 votes – Ideas cost money to develop. They will not consider ideas without customer support.


GRC Product team will add comments, request further feedback or review the idea in conjunction with their road map. You might find your idea accepted and scheduled for delivery (what an achievement) or you might find the idea is dismissed if it doesn’t fit the product road map. But hey, if it's dismissed at least you'll know why.



Get involved

So dear community, we have an opportunity to provide improvement suggestions to improve GRC. It may not help you today but with a strong voice and support of the community, your idea could be there to help you next time.


There are lot of ideas created in the past two years that are still valid. They have less than 10 votes and aren’t getting considered due to lack of support. Someone may have a proposed a solution to your current challenge but their voice is not loud enough to be heard. Time to shine some light on the ideas and get behind them.



And remember to check back regularly for new ideas!


Vote on! The count down is on!





     I am striking a discussion away from the technical aspects of GRC. The reason being, it is interesting to know how all the technical build-up and maintenance actually helps the organizations. I have a very basic and limited understanding in this area, that I have put across here and would really like to get more information to understand the overall picture.


     From the purpose of SAP GRC, it is clear that it caters to regulatory compliance based on certain legal acts / laws. These are specific to industries and geographies. We usually implement SAP GRC Access Control with majorly separation / segregation of duties in mind. This primarily in turn caters to help comply with certain regulatory laws. For example, the major one we hear of - SOX (Sarbanes-Oxley) Act.


     Now, SOX Act consists of over 50 legal sections. Most of which are not specifically IT related. SAP GRC Access Control's Separation of duties caters to the SOX Act's Section 404, which deals with Internal controls. This requires the management of an organization to have enough internal controls to assess risks and prevent frauds. Similarly, having approval logs, audit logs as part of SAP GRC features caters to the SOX Act's section 802, which deals with altering documents. This requires that no documents is altered in the due course of business in an organization.


     I, having worked specifically on Access Control part of SAP GRC, usually get to only look at the side of the separation of duty policies heavily. I know that Process Control does cater to specific regulatory compliance much more than what Access Control does, that being its purpose.


     So, please share your experiences, regarding how you have used SAP GRC Access Control or Process Control to cater to which regulatory compliance and how.




The Dotcom boom of late 90’s, also saw some major corporate scams like Worldcom, Enron & Adelphi.  Some national headlines in US media (“Data theft at nuclear plant went unnoticed for six months” – June 10 , 2006 New York Times, XYZ Manufacturer violates EU pollution laws” – July 06 2006 CIO Tech Informer “US imposes record $100 Million penalty for export control violations” – March 27, 2007 Washington Post, etc.) would accentuate the changed milieu.  This necessitated a major emphasis on data security & vigorous audits (financial / system audits).  Sarbanes-Oxley (commonly called as SOX) act came into existence.  (The sections of the bill cover responsibilities of a public corporation's board of directors, adds criminal penalties for certain misconduct, and requires the Securities and Exchange Commission to create regulations to define how public corporations are to comply with the law).  There was a growing need of more transparent corporate governance, a well-designed whistle-blower policy framework & detail audit log (of who did what & when).


IT firms took these challenges into cognisance & turned it into opportunity to come up with security solutions, seamlessly integrated with organizations’ ERP softwares. ERP players like SAP acted upon it swiftly & integrated security solutions into SAP under a growing niche product suite called GRC (Governance, Risk & Compliance). SAP’s GRC 10.1 suite handles it through 3 sub-modules of 

Access Control, Process Control & Risk Management.


  • Access Control – It involves managing user roles, who will (& who can) do what in the systems. The principle of Segregation of Duties (SoD) needs be considered while providing access. A simple example of SoD is, never to provide the same user access of creating new vendors as well as issuing/printing cheques. Giving too little access to user hinders work, whereas giving too much access attracts risk, so due care needs to be taken while designing access control. It also involves super user management & emergency access management.
  • Process Control – This involves checks and balances built into the business processes to avoid/minimize occurrences of fraudulent activities. There are three different types of controls need to be designed: Preventive Controls, Detective Controls & Corrective Controls. The other way to look at building a healthy internal control environment is, following below 5 steps.  1. Documentation 2. Testing 3. Remediation 4. Analysis 5. Optimization.  (The details under each will be covered in a separate article)
  • Risk Management – It helps reduce the risk of failing to comply with the regulations for financial reporting, trade regulations, factory act/s & environmental protection. At a very high level, Risk Management involves:  Identify the risks, analyse the risks, identify risk owners & coordinate responses.


Considering the growing need of ERP-agnostic solutions, many IT consulting companies (like Infor Approva, Greenlight Corp etc) came up with GRC solutions which complement the ERP software (like SAP, Oracle, Microsoft Dynamics) or seamlessly integrate with it. 


If we talk of India, the Indian corporate world was shaken by Satyam scam, Reebok India & a recent case in India’s top IT firm. In India, Clause 49 came into existence from 31st Dec 2005, for the improvement of corporate governance of all listed companies. (Which entails - It would be necessary for Chief Executives and Chief Financial Officers to establish and maintain internal controls and implement remediation and risk mitigation towards deficiencies in internal controls, among others)


In short, the question ‘Do-I-need-to-implement-GRC’ is no more relevant. Instead it should be, “What are we going to implement under GRC and when?”

Hello GRC Community-


Every month, GRC Product Support together with our Development team will share with you information proactively to help keep you up to speed on important news. The Newsletter will be uploaded to KBA 2123844 . This is our first edition and would like to hear from you any ideas that you think will help to make the newsletter more valuable. Please contact me directly (email in my profile) and we will work to incorporate your ideas into future editions.


Thank you everyone, hope you find some of this information useful.


Ramelyn Paredes
Director and Global Functional Manager (GRC and EPM)
SAP Active Global Support

Is it 2015 already!?! Wow, how time flies. The SAP governance, risk, and compliance (GRC) team is already off to a fast start for 2015. Given this, I thought I’d use this week’s GRC Tuesday blog to reflect on 2014 as well as look forward into 2015.


2014 New Products

2014 was both a busy and successful year for those of us who watch over GRC here at SAP. I hope the same was true for you and your organization. One measure that I use to rate how busy we’ve been is the number of new products we’ve launched. In 2014, we made five entirely new products available to you, our customers, for use when dealing with a number of specific risk and compliance challenges. I invite you to learn more about each of these solutions:


2014 Awards and Recognitions

I can also measure our success by looking at the awards and other recognition that our solutions have garnered. In the last year, our GRC solutions have been rated and recognized as world-class more than a few times. One example is that Ventana honored us with their Overall Business Technology Innovation Award for our SAP Audit Management and SAP Fraud Management solutions. This award and others like it help you to understand the capabilities we’ve included, as well as just how successful our customers have been through their use.


2014 Customer Successes

But I’m even more proud of the accomplishments that our customers made using our solutions and technologies as a cornerstone of their GRC programs. Our customers’ success is the greatest measure of our own. GRC 20/20 recognized Exxaro, its implementation partner CQS, and SAP with a 2014 GRC Value Award in the domain of Internal Control Management. Exxaro is one of South Africa’s largest mining and materials companies. This award recognizes the efficiency, effectiveness, and agility of Exxaro’s controls program. Read this case study for more information. Way to go Saret and team!


2014 Internal SAP Implementation

A second 2014 GRC Value Award was given by GRC 20/20 to SAP for its implementation of an integrated GRC architecture and use of technology to support and enable a global risk assessed internal control monitoring and assurance program. Yes, of course, we use our own products, but this is not the typical “drink your own champagne” use of one’s own software products. SAP’s own risk, compliance, controls, and policy teams are world-class. These teams impressively support all of SAP’s GRC requirements and this award is proof. In fact, some that know our GRC programs well have indicated that this is the most comprehensive, successful, and global implementation of GRC in the world. Congrats to the SAP’s own GRC team!


And now some predictions for 2015…

Uh oh! They tell me that I’ve run out of time and space here. Tune in next time for my thoughts on the GRC market in 2015 and how SAP will help your organization meet its risk and compliance requirements.



Originally posted to the SAP Analytics blog

Predicate and Propositional logic was the only subject in university that I failed (if only partial points were awarded for partial proofs!). Yet, I find myself applying this form of mathematics all the time in work as part of troubleshooting and problem solving. I must admit also, I can barely do the proofs anymore (goes to show what happens when you stop practising). However, the parts of this maths discipline is around reasoning and logical deductions - the type of mathematics we all use daily without realising. Yep – problem solving! By understanding logic and the concepts, it has helped me to troubleshoot and simply requirements. And in some cases, it has help me provide solutions to questions asked in this space.


So what has this really go to do with GRC? A tad random for me to be writing about something with no direct connection to GRC. Then again, the thought for this blog came to me after assisting a few recent questions relating to MSMP and BRF+ Decision tables. Members of this community were not asking how to resolve an error (that is, they knew how to configure workflow) but more around their design of their workflow and decision table entries (they didn't know what values to specify for the steps). Logically, it became evident that logic was missing.


I won’t attempt to provide a lesson in this mathematics (I couldn't imagine anyone willing to learn from a self-proclaimed failure). However, I thought I might share a slither of my thought process and approach to designing the decision table rules in hope it can help you to determine yours.


I have used this recent question from GRC space as an example of breaking it down - GRC 10.0 BRM : Issue with Decision Table. My workings this blog are not 100% the same as to the answer I gave as I have separated the steps out. However, the answer I provided would also have covered the requirement.



Step 1 – Gather and Record your Requirements


This step does not require changes to your system. Hold back on configuring your system until your think your requirements through. Therefore, you’re working with pen and paper and figuring out your design.


Requirements gathering in its simplest form involves obtaining business statements of what is needed. In this step, avoid the use of technical jargon and write your requirements out in simple English (or whatever your native language is).


You can ask yourself questions such as:

  • Do I have different workflow scenarios depending on the request?
  • What sort of scenarios are they?
  • Will these scenarios require different approval steps?
  • Who are my different approvers (agents)?


In this example, the requirements were already provided (off to a good start to designing the table)


If I select Composite Role it has to go Approver 1 irrespective of any criticality of the role whereas for Single Role if the role criticality is HIGH it has to go to Approver 2 and If the role criticality is MEDIUM and LOW it has to go Approver 3.



Step 2 – Identity your Inputs attributes

By the time you get to step 2 you should have written down all of the scenarios that you can think off for your requirements. The next stage is to go through and find the condition values (attributes) that you can use to configure your rules.


My approach on this one is to go through your statements with a highlighter and colour the attributes that you can see exist for the request type. Depending on how visual you and are how complex your requirement, you might want to use different colours to group the attributes.


For later use (in step 3) you can also highlight the output paths. In this case, these output paths are the identified Approver groups (return results).


1 bus req highlight.png


Once you have gone through and found your condition values, you can then group them together as to identify the attributes:

  • Role Type (e.g. Composite Role, Single Role)
  • Criticality Level (e.g. High, Medium, Low, Any) – in BRF+ it will display as “Crit. Lvl”


At the end of this analysis, you now know that you have two input attributes to use. You can now build the structure of your decision table (you know the inputs from this analysis and you have the outputs due to the rule type – initiator).


2 decision table structure.png


Step 3 – Sequence and Simplify your conditions

As entry to this step, you know you the attributes to enter as the column headings. In this stage, you need to return the original business requirements and rewrite them as a pseudo-logic format based on your inputs and outputs.


3 rule break down.png

Now an example of where Logic comes in (allows you to build a logically equivalent rule) and shows an example between how I wrote suggested the solution versus how it was built is Rule 1.


4 rule example for logic.png

A Logical equivalent of this rule would be replacing the criticality is asterisk with the use of an OR operator and listing out ALL POSSIBLE VALUES for Criticality level


5 rule example for logic equiv.png

The risk of switching to the OR operator is if new Criticality Levels are built, then you have not factored them into this scenario. You then have to update the decision table. For this reason, when you requirement does not require the use of the attribute, I would specify the asterisks. However, the two rules above will return the same result (so long as there are only those 3 criticality levels).


You could approach this sequencing and simplification by drawing a decision tree. If you have completed business process flows, you may not even need to go through this process as the steps are already defined for you. Example of the decision tree, provides a visual flow of your rules which may help you validate them later when you test the rules. It is also a useful approach to use when you are analysing gaps in your requirements.


6 decision tree.png


When breaking this one down, as it was a simply scenario, I realised immediately that 3 lines were needed for the different scenarios. However, where it becomes more complex, you might need to work through a decision flow and refine it until you can see all of the scenarios.


Step 4 – Add your catch-all

Depending on how thorough your rules are, you may have no rules left to capture. This step is important to analyse the business rules that you have devised to make sure you did not miss any possible combinations. If you miss a scenario then your end user will receive an “on submission” of the workflow error.


In this step, you need to look at your business rules and compare to your IMG configuration to determine if there are any possible inputs not yet catered for. In some cases you may be able to simplify your rules by changing the OPERATOR. In other scenarios, you may need to add additional rules (another line item).


As an example, ROLE TYPE is a potential gap. The original requirements only considered two roles types – Single and Composite. However, there are other roles types to choose from (profile, derived, composite, etc). It is hard to know if this is an oversight as part of it comes back to IMG configuration for choosing which role types are in scope. For the purposes of this blog, let’s assume that all role types are required.

The second potential is PRIORITY. If you only list the explicit values – LOW, MEDIUM and HIGH – you risk missing any other configured values. You also risk future IMG configuration requiring creation of a new criticality but the BRF+ decision table is forgotten. For example, there might be a value call CRITICAL.


There are a few ways to add the catch-all


Option 1 Rewrite your rules to cater for them

In the case of the first attempt – you can go through your rules and incorporate it. The risk of this path is that you implicitly include it in an Approver Path instead of going back to your business requirements and confirming them. This option really depends on how well you captures you business requirements in the first place.


For example, in rule 2 and 3 change it to Role Type <> Composite instead of Role Type = Single. For rule 3, change the criticality to not equal high. You have now removed the gap for Role Type and Criticality.


7 catch all rewrite.png


Your risk is whether you have interpreted the requirement correctly in simplifying. For example, what if Non-Composite Roles that have Criticality level of Critical need to go to a different approver (approver4)? This rule will not provide that option. Therefore, your simplification becomes invalid.



Option 2 Add entries to the bottom for each scenario

For each gap, you need to define the requirement and capture it. For example, you have determined that there are only two role types (Single and Composite) but there is another Criticality level – Critical – and you want to route to Approver2.


8 catch all add entries.png


If you have a decision flow diagram, then you would need to update it to reflect the new rule. For each scenario, you would add a new rule to your table.



Option 3 Edit your Existing Rules to Expand

An alternative to Option 2 could involve editing the existing rules to include the missed scenarios. This would depend on the missing gap. Using the same requirement Options 2 (criticality of critical for single roles should go to Approver2) would result in editing rule 2.


9 catch all edit entry.png


Option 4 Wildcard catch all at the very end

If your decision table properties has been configured to only return a single result (which is the first rule evaluated) then you can add a wildcard catch all to the very end. This rule will only be evaluated if all other rules have failed. In this case, would configure an Approver_X (unknown) and consider routing it in MSMP to an Administrator to investigate.


10 catch up wildcard.png


Step 5 – Build and Test your decision table

Finally, you’re at the stage where you have translated your business requirements into business rules. Time to hope into BRF+ and create the decision table. Once you have completed, activate the decision table, functional and application. Finally, you can simulate your rules to verify that you receive the expected result based on your inputs (your decision tree might even help you with your test scenarios).


11 decision table complete.png

Note: configuration screen shot taken from the original thread referenced at the top




Hope this helps you think through your rules and apply a little logic. If you happen to be interested in logic as a topic (and succeed where I failed), this site is useful http://www.logicmatters.net/tyl/ and includes a Teach Yourself Logic Guide.


What is your approach to breaking down BRF+ rules? Do you take a similar approach or do something different altogether? I would love to hear your thoughts in the comments below.




Surely 2014 was the year of simplicity with SAP's emphasis on simplification, simplicity, "Run simpler," or any of the variations on that theme trumpeted loudly and clearly at every SAP event and opportunity. This new emphasis seemed to be well received by customers, and why not? Who *wouldn't* want their SAP landscape to be simpler and easier to support and sustain? Security is no exception: doing more with less, squeezing a lean team harder to support more projects, more systems, and more users is just the given these days. Assuming that we start with at least a minimum number of well trained and competent SAP security staff, what does it take to simplify security to make it sustainable and bring about sustainable compliance? Here are some suggestions for your consideration.


Consistent security design

In my experience, there is not a "one size fits all" of security design except to say that sustainable results are more likely to be achieved with a consistent design. Are your security roles built using the derived role functionality, the enabler role model, or a haphazard mix of both? Is the design task-based, job-role based, or not clearly one or the other? If Business Role Management (BRM) is in use, is the model easy for the business users to understand? Is it your organization's practice that security roles have standalone integrity, or do some unknown number of them not fully functional unless some other functional role is assigned, which is not documented but "everyone in the plants knows that?" Are end user roles restricted from assignment to the SAP support team, or are exceptions frequent? Whatever approach the organization takes, taking it consistently and documenting it thoroughly will make your security much more sustainable in the long run, reducing the confusion among the people requesting access and the demands on the security resources to maintain and explain it.

Security design aligned with the business model

Whatever the basis of your security role designs, aligning the designs with the business is imperative for simplification. Otherwise, the requesters and role approvers will find themselves in an endless cycle of submitting requests to the security team for adding and removing roles from the users, and adding/ removing access from roles,  in frustrating attempts to get the access levels just right. But what if the jobs are not defined in a consistent manner? Then there is really very little the security team can do until the HR function works with the business to review the job  and task descriptions to improve the consistency.

Organizational standards

In my experience and observation, it is often the case that the organization's management wishes to have users' access restricted organizationally, often for compliance reasons. Whether the division is geographically based, product/service line based, data sensitivity based, or some other reason, sustainable security and compliance is much easier to achieve when the rules are documented, applied consistently, and enforced via automation. There is not much point in stating that users with access to one business unit should not have access to data of another business unit, when one functional area has a different idea from another of what organizational values represent each business unit, and end users are frequently granted roles from more than one functional area.


Furthermore, when the rules must be enforced manually, and approved exceptions are kept in a spreadsheet or file drawer instead of in a GRC toolset, compliance is anything but sustainable.

Governance model

So how does an organization that is lacking in any of these areas bring about the changes that are needed for sustainable security and compliance? In my experience, governance is the key. Role designs should not only be required to meet a documented standard, they should also be subject to periodic governance review. If role designs are any which way that the role owner and/or his/her business lead wish, if organizational standards are only a suggestion instead of a policy, if exceptions are numerous and monitored manually,  the security team will find themselves in an endless cycle of role and user modifications, which can take so much time and effort that value-added proactive initiatives, such as automating the user access review or some of that manual monitoring, are forever on the back burner. Without a governance model that has teeth, the security team may find themselves the scapegoats for the breaches and non compliance that are almost inevitable.


I hope that some of these suggestions spark improvement ideas that help bring about simpler and more sustainable security and compliance in your SAP landscape. Are any such initiatives already in the works for 2015 at your organization or among your clients? I welcome your comments and observations. What did I miss that you have found to be key to sustainable security and compliance?



I am currently working on GRC 10.1 SP05. I could see lot of customers also working on same SP or upgraded to same SP. There are lot of issues in GRC 10.1 SP05 which we came across. I am just updating the issues with relevant SAP notes here just to make it easy for the guys who come across the issues just like mine. Also I am requesting others to contribute by adding in the details which we might had missed out.


There are still lot of issues which we are working on and will update this blog regularly based on our issues and fixes.


NOTE: There can be few SAP notes which SAP might have released specific to us, but if the issue is relevant in your system you can request the same from SAP

101 Blog.png


Access Request Module (ARQ)

Issue 1

Work Inbox – Simplified Not Working

When launching the Work Inbox - Simplified from IE8, it generate the following error messages and it will only display the "Work Inbox" header but the rest of the body are blank.

The following are the error messages:

1. Error


2. ExceptionTypeError: Access is denied.

Replicate the Scenario using below steps

  1. From GRC, execute Tcode NWBC. It will launch IE8 to display Business Client for HTML.
  2. From the Work Inbox section click on Work Inbox - Simplified link. It will launch another IE8 browser for Work Inbox.


Related SAP Note for fix

UI5 libraries which were used for Simplified Access Request have recommendations for IE9 and above, hence it don’t work properly in IE8, so customers using this functionality should upgrade to IE9 and above.

1974672 - Keyword Search in simplified access request/ Approver in Box not opening

Issue 2

We are getting the error "Text 265 Not Found" every time we click the "View Provisioning Logs".

In ST22, it shows some ABAP dump. I have attached the ABAP dump for your analysis.


Steps for Reconstruction 

NWBC->My Home->My Profile->Request Status-> Select a Request -> click on View Provisioning Logs

Related fix

You have missed some Text elements in your system due to which this error is being thrown. For the resolution of this issue, kindly follow the steps mentioned below:

a. Go to Transaction SE24.

b. Enter CL_GRAC_UIBB_ACCESS_REQ_ASSIST and click on display.

c. Click on Goto and select Text elements.

d. Click on edit icon (Ctrl+F1).

e. Enter '265' in Sym and 'Request Key' in Text field.

f. Save and Activate.


Issue 3

This is more of a query. We are trying to configure the system that it automatically perform the risk analysis while submitting an access request. We have configure this and this with config parameter 1071. We found that this functionality is running risk analysis only for one type of risks (Action level, Permission, Critical Action or Critical Permission) based on config parameter 1023, which means it shows incomplete risk analysis results. We want to configure it to run risk analysis for all type of risks.

Related Solution

In that case, you can either remove 1023 parameter from Configuration Parameter list (as mentioned in SAP Note 1733984).


You can maintain multiple values under 1023 parameter (as mentioned in SAP Note 1776542).

This would resolve the issue.

Issue 4

The ABAP program GRAC_REPOSITORY_OBJECT_SYNC didn’t sync the data properly of an EP Connector (X PORTAL). It only properly sync the roles but it didn’t sync the users properly.

It work for other EP Connector (Y PORTAL). They belong to the same connector group (PORTAL_GRP).

The X_PORTAL is a SAP NW 7.4 Portal while Y PORTAL is an SAP NW 7.0 Portal.

We have configured our EP Connector using the instruction in SAP Note 1977781 - GRC 10.1 Enterprise Portal Configuration

We have also applied the instruction in SAP Note 1647157 - How to Setup Access to the SPML Service on AS Java

Replicate the Scenario using below steps

Tcode SE38


Select Profile, Role, User and Role Search check box.

Connector: <Portal Connector>

Run it in foreground.

Related fix

1889792 - UAM: Portal sync results in time out/ Portal Object not getting synched

2008685 - Portal sync in GRC 10.0 is not working

1940769 - Timeout problem in GRAC_REP_OBJ_SYNC

Issue 5

We are always getting ABAP dump every time we run the program GRAC_REPOSITORY_OBJECT_SYNC.

We are consistently getting the error 'SQL error "SQL code: 3135" occurred while accessing table "GRACRLCONN"

Related fix

Jobs are terminated because of the huge Database space Usage and that’s why it is giving dump. So we advised you to schedule a job by selecting option which is really required. If the requirement is related to user only then you should select only user option rest you can uncheck. In this way, you can execute parallel jobs as much as you can. But if you really want to schedule a batch job with all the options then you should schedule one at a time. This is not the application issue it’s all because database usage.

This is a known limitation of any database that can't handle big SQL statements and you can experiment the same issue when you select the data for a particular table in standard ABAP transaction SE11/SE16.

Ex:  Table USR02 and you can put high volume of users into the selection criteria and you will see the same issue.

You may also check Note - 1847034 - Runtime error for very large OpenSQL statements, for additional details.

Issue 6

Currently the GRC system allows all kinds of file types to be attached in the GRC system (Eg. on the BRM and ARQ screens). These file types includes .html or .exe which could contain malicious scripts. If the system is able to prevent certain file types from being uploaded, then the risk is minimized.

Please refer to SAP note 1232736 for the same functionality in SAP GRC Access Control 5.3.

Since it was there in 5.3 our customer is expecting the same in latest version as well

Related fix

Please implement note 2058231 (manual and automatic corrections) in your system. After implementing this note you will have to implement a BADI as shown in the document attached to the note. Then you can maintain configuration parameter 2401 in IMG for the allowed types of files.

Issue 7

We have enabled mitigation control assignment workflow based on the client’s requirement. Workflow is configured to have first level of approver by supervisor who will perform risk analysis and mitigate the risk at this stage.

Based on the GRC 10.1 behavior we have noted below shortfalls:

  1. On request level, access request approver in this case supervisor does not get confirmation on the mitigation control approval submission. There is a submit button and after clicking that the request does not show the mitigation control workflow number.
  2. Mitigation Control assignment number does not match with the access request number and hence the mitigation control approver have no idea about which access request is this approval for. This is major short fall for client which are expected to have high volume of mitigation control assignments.


Related SAP Suggestion

Request number of Control Assignment workflow is generated separately and it would be considered as a separate workflow. Normal Access Request workflow has different request number and flow and control assignment workflow has different request number and flow. These cannot be merged.

However, as far as the linkage is concerned, you can submit this idea on SAP Idea Place and let our Product Management team consider based upon the feedback/voting from the globe or if possible.

Issue 8

We have configured stage level approval and rejection level to "Request" which mean the approver on the stage allowed to approve the whole request or reject whole request. In the above configuration we should not be shown approve and reject button at line item level near user access tab. We have observed that approve and Reject button are still visible and they are non-functional.

Related SAP Fix

2057413 - UAM: Approve/Reject button at Line Item Level not working according to stage level setting

Fix for visibility of reject button under other options after fixing the issue of APPROVE/REJECT buttons at Line Item Level

2066115 - UAM: Reject option not displayed while request approval

Issue 9

For Screens like Model User, Existing Assignment and My Profile there was not feature to filter the records in the upper table

Related SAP Fix

1984995 - Missing Filter for Model User, Existing Assignment and My Profile

Issue 10

We want to achieve that user can only select role from his business process in access request.

The business process field is getting populated from LDAP. We have configured the role selection that business process field is mandatory and non-editable in role selection screen. This works fine that user can only select role from his business process.

We noticed that user cannot edit the auto populated business process field but he can add another business process field on role selection screen and the role search works as 'OR' between both of the business process. This means user can select the roles from both business processes. This system behavior defeats the purpose of having a field as mandatory and Non-Editable in role search. This is a product bug.

Related SAP Fix

2068938   UAM: Duplicate actions shown in the ACTION OVS in access request role search and role search restriction not working in access request

Issue 11

There is no authorization control available to control user as such that they can administer their own jobs. The users should not be allowed to view, delete the result of background job scheduled by other users.

We have run the trace for the back ground jobs and found it doesn't check any authorization object so we can control. This is very basic behavior which should be implemented.

No authorization control for the user to view and adminster his own’s job

The role only has object GRAC_BGJOB with 70. The users will need to adminster their own job and not others job.

Based on the trace enabled only GRAC_BGJOB

User able to delete and administer all jobs in GRC system

Related SAP Fix

Need to put this in GRC Ideas place

Issue 12

We are facing an issue while searching for users from LDAP. If we type a user ID and press ENTER then User details are populated correctly from LDAP. However if we click on button to search user from pop-up screen then system doesn't shows any search result from LDAP.

This was working fine before we implemented a SAP Note 1982896. This functionality is broken by this note.

Related SAP Fix

Kindly implement the note 2025895 after implementing the note 1982896 to resolve the issue

1982896 - UAM: Fuzzy Search is not working on User ID and copy request is not copying line items.

2025895 - UAM: Users not searched from HR/LDAP connectors if Realtime search parameter 2050 is YES

Issue 13

We are facing issue while downloading the default role template to upload default roles. Once we click on default role template button there is no action from system.

Related SAP Fix

2044932 - FPM Search GUIBB: dump or empty screen

2018804 - UAM: Dump in default roles while clicking the Import from file button

2067320 - Default role file import does not support connector group with space

Issue 14

We noticed that in unlock account users are able to add role via existing account option. This should be not allowed. We have given only existing "Unlock Account" action to the unlock request type. This is a bug in system functionality.

Related SAP Fix

2101596 - UAM: In Existing assignment, systems are selectable though request doesn't have any system action.

2048988 - System are selectable in existing assignments for Assign ob


After applying the above notes everything was working fine and then we found out that Business roles are being added from existing assignments when creating unlock account request. Waiting for update from SAP for this issue

Issue 15

We have mapped the business role as default role in our configuration with other single and composite roles. If a user submit the request and this request fulfills the default role criteria, however only single and composite roles are auto populated in request. The configured business roles are not populated in request.

We have already implemented SAP Note “2030797 - Default role is not getting populated in Access Request in case of Business Role”

Related SAP Fix

2077121 - UAM: Business Role as default role is not working for Request level

Issue 16

We are using this GRC End User Login services for all new users to request access to the SAP system. The new users have an LDAP account. We are using SiteMinder to authenticate the user to its LDAP before calling the SAP Webdynpro application. We have enabled the parameter SAP SSO parameter login/accept_sso2_ticket=1 to accept an SSO ticket.

We are having problem on the GRC End User Logon services (Webdynpro application grac_uibb_end_user_login) to authenticate from SiteMinder. The Webdynpro application doesn’t recognize that the user have already been authenticated by SiteMinder. It still show the screen asking for UserId and password.

Is there a configuration that we need to do for the Webdynpro application to authenticate to it?

Related SAP Suggestion

SiteMinder validation is not supported in GRC End user login. Kindly refer the note 1575897 and create an enhancement request in the Idea Place

1575897 - Logging Enhancement Request - Business Objects Access Control

Issue 17

While raising the access request the user selects business role and its validity date for business role is not set automatically. Valid to date is cleared in case of Business Roles. Business Roles doesn’t have validity date.

Related SAP Fix

2095046 - UAM: Business Role Valid to date is blank

Issue 18

We noticed that the drop downs on access request page are not sorted based on description. For Example while selecting the roles the dropdown for Functional Area, Business Process, and Company. These drop downs are not sorted based on the description. These are sorted based on ID which is not visible to the user in drop down. This causes a confusion to the user as they need to browse through the whole list which may go up to 100 line items.

Related SAP Fix

2061817 - UAM: Access Request field values are not sorted with short description

Issue 19

We have configured our LDAP server as a user data source. Our LDAP server has 2 fields (Mail, Mid Mail) which stores the Email ID. System is able to pull the mail information correctly if it is available in any of these fields.

The issue happens when we try to search for users by using Email ID. The search with email ID doesn't work. It simply doesn't return the result.

Related SAP Fix

2102827 - Search LDAP User Using ID and Email Address

Issue 21

We have created an ABAP Webdynpro iView for the GRC application grac_oif_request_approval. This is to ensure that the link will use SSO automatically when clicked inside an email. Everything is working fine except when the user start clicking any link inside the ABAP Webdynpro application. All of the sudden, the link being generated is using a Portal NavigationTarget instead of the usual link generated when launch from SAP ABAP ICM. Because it generated a different link, it doesn't call the correct ABAP service to display the content.

May we know how to force the Portal to use the link generated will follow the link when it is being launch from SAP ABAP ICM.

Related SAP Fix

Waiting for SAP to help with this issue

Issue 22

Every time the user is creating an access request to lock a user in Portal, the following message are generated in the access request log:
Could not update user Attribute "lockreason" on namespace "com.sap.security.core.usermanagement" of principal "UACC.R3.DATASOURCE.S8".
Object class name does not exist in IDM.
By the way, our Portal UME is using a Backend SAP ABAP.

Related SAP Fix

Waiting for SAP to help with this issue

Issue 23

The default role upload is not working if we include business roles as part of default role. It checks for the system of the role however the system is not applicable in case of business role. This is causing the issue.

We compared the behavior by leaving the system field blank and found that in back-end it stores as "ALL SYSTEM", however if set the business role manually(Without upload) it stores as "BUSINESS_ROLE". Could you check this functionality and provide a fix for us.

Related SAP Fix

2084889 - Default role file import is not working for business role

Issue 24

We noticed that if an Approver (A) delegate his rights to another approver (B). The approver (B) gets the request in their work inbox however they don't get the notification. This cause that delegated approver (B) will not be aware of any new access request routed for his approval.

Related SAP Fix

1589130 - GRC AC 10.0 - MSMP Notification Override BADi - Enabling

1734548 - Delegated Approver is not receiving the Email

2028411 - Workflow delegation BADI not executed during delegation in Access Controls


Business Role Management (BRM)

Issue 1

When risk analysis is performed at the Critical permission level for certain roles with inactive Authorization objects through BRM, the risk is flagged by the system. However, this behavior is not consistent for all roles. In some cases, the roles with the same inactive authorization objects are not flagged.

Related SAP Fix

2036645 - Role Risk Analysis shows inactive authorization objects

Issue 2

We found that Role Search while creating an access request is not correct. The search result is impacted by parameter max no. of result row. It seems system is considering the parameter

"Max no. of result row" to look into the list of role.

For example:

If this parameter is set to 100 then system look for roles only in first 100 roles and shows only 3 roles as result.

If we set this parameter to 50 then system look only in first 50 roles and returns only 2 roles.

Related SAP Fix

2059283 - Role Search is not accurate

Issue 3

Unable to search Business role based on action maintained in single role on role search screen when business role having composite role and that composite role having single role.

Related SAP Fix

2093026 - Unable to search Business role based on action maintained in single role on role search screen

Issue 4

We are facing an issue while importing Composite roles in BRM. System does not import any of composite roles in BRM. We are trying to import the roles from back-end and selecting the role parameters during import process. With the same steps we managed to import all the single roles however not able to import any of the composite role. We have already run authority sync and repository sync job. We have also imported all the single roles associated with composite role.

Related SAP Fix

2027477 - Composite role import is not working

Issue 5

The issue is that when role owner is approving the role changes then he should be aware what all mitigation controls are applied to the role. This can only be possible if include mitigated risk is by default checked while system auto trigger the risk analysis before generating the role.

Risks were not displayed in the Analyze Risks - Role Generation Phase even though risks were displayed in Risk Analysis Phase

Our methodology is as follow:

Define --> Maintain Authorization --> Risk Analysis --> Generate --> Maintain test case --> Approval --> Complete

Related SAP Fix

2075894 - BRM: Risks are not displayed in the Role Generation Phase

Issue 6

We are facing issue in role certification. When user click on the link from role certification. The user is able to view the define tab of role in display mode however if he try to navigate to maintain authorization or risk analysis process step. System gives a dump "Assert Condition violated"

The role owner is not able to see the list of approvers and company mapped with the role. This information is required to certify the role. This information should be available to the role owner in display mode.

Related SAP Fix

2061588 - Assertion failed dump with no edit authorization in role methodology

Issue 7

We found that role prerequisites are not available in Role Parameter import template. These are also a role parameter same like functional area, Company, Business Process. Please rectify the problem and provide a fix to us. We need to upload prerequisite for 6000+ roles. This parameter should be part of Role Import Template.

Related SAP Fix

SAP has provided a Z program and related step by step document. Anyone has the same requirement let us know, I can share the program details here

Issue 8

We found that Role Owner search under "Define Role" Methodology step is working correctly. There are 2 fields (Owner & User ID) to search. If we put user ID (S80*) in user ID field it gives no result. However if we put user ID (S80*) in Owner field we get the search result. If we put user name (MADHU) in Owner field then there is no result and if we put user name in User ID then we can get the result.

The search is not working correctly as per the parameter provided. If we provide Owner it looks in User ID and if we provide User ID it looks into role owner name.

Related SAP Fix

2092209 - Text for user name in approver search help during role definition is ambiguous


Access Risk Analysis (ARA)

Issue 1

We are trying to transport the ruleset from SPRO but it gives error.

Related SAP Fix

1968082 - Not able to create transport for SoD Rules after upgrading to NW 740 SP04

Emergency Access Management (EAM)

Issue 1

We have noticed that some Notification variable for Firefighter log review doesn't get filled in the notification template. Following are the parameters which are nor working.




Related SAP Fix

1983997 - LINK_WORKITEM variable not filled for FF Log Review Report Workflow

Issue 2

We noticed that the FF Log Review report doesn't have any option to relate the logs with the Original Access Request. We want to see this mapping in log review request so that reviewers will be able to match the request justification raised by firefighter and match the activities performed by him.

As we understand this is not available in standard product but this is very critical requirement for Log Review. Could you please let us know any possible workaround to achieve this requirement.


Related SAP Fix

Waiting for SAP update


Issue 3

We are running the GRAC_SPM_LOG_SYNC_UPDATE as a background job in our GRC system to extract GRC SPM log from our ECC Production system. We noticed that we need to increase the parameter rdisp/max_wprun_time considerably high (around 43200 secs) in the ECC system, otherwise the background job will fail in GRC. Our policy is that that the rdisp/max_wprun_time should only be set to 3600 secs (1 hour). This is to ensure that the work process are not block which will lead to system standstill.


If we reset the rdisp/max_wprun_time to 3600 secs, the GRAC_SPM_LOG_SYNC_UPDATE job will fail and the SPM logs that is not sync will also grow, which will make the job runtime even longer.


Is there a way to optimize the GRAC_SPM_LOG_SYNC_UPDATE job performance so that it will fit in the rdisp/max_wprun_time of 3600 secs? Can it have the same behaviour as BW extraction job which is not affected by the parameter rdisp/max_wprun_time even though it runs longer than 3600 secs?


Related SAP Fix

Please check this Notes. It describes the ways of optimizing the performance of EAM sync job.

1617529 - Best Practices For Improving Performance of EAM Log Sync job

1741151 - GRC 10.0 Indexing on CDHDR table in case of time out issue due to huge data

2047097 - Communication failure with remote system (SAP Query)

Reports and Analytics

Issue 1

The access rule library auto pop out once the group rule level is changed.

Please follow flowing steps for reproduction and refer to the attached screenshot.

1. Click on the “Reports and Analytics”

2. Click on Dashboard report “Access Rule Library”

3. Click on the pie chart with high violations and close the window

4. Now change the group level to “Critical Permission”

5. The window is auto populated without users actions

This behavior is an irritant and need to be resolved as this is bug.

Related SAP Fix

2061888 - In Access Rule library report, popup gets open without user action

Issue 2

The report "User to Role relationship" is not working as expected. If there is a role which doesn't have a profile then this report doesn't pick the role in output.

The expected output for this report is to include all the roles which are assigned to the user irrespective of profile of the role as this report is to show the relation between role and user instead of user and profile.

Related SAP Fix

2093024 - User to Role Relationship report not showing roles that does not have any profile generated

2107567 - User to role relationship shows empty profile even for generated roles

Issue 3

Change log report does not show results when the search criteria is in lower case. The report does not have option to save the file in excel.

Reports and Analytics -> Audit Reports -> Change Log Report

Related SAP Fix

2061392 - Role name is case sensitive while executing the change log report

Issue 4

As a part of the UAT phase following issue was noticed in the GRC 10.1 with SP Level 5. The role library dashboard does not have export option in the drill down list.

Related SAP Fix

2062839 - Export option not visible in the drill down of role library report

Issue 5

We noticed that that some reports are giving results in foreground mode however if we schedule the same job in background then it doesn't give any result.

List of Reports which are failing.

1. Role Relationship with User Group (No Output)


Related SAP Fix

2073736 - Role Relationship with user/user group is not working in background option

Issue 6

We have seen incorrect data being populated in the SAP standard dashboard report “Access Requests”. The numbers shown in access request pie chart and shown in request by types for similar period and similar filter criteria are not shown correctly.

Related SAP Fix

2064801 - UAM: Incorrect values displayed in access request report and drill down doesn't display data in provisioning report

Issue 7

We noticed that that some reports are giving results in foreground mode however if we schedule the same job in background then it doesn't give any result.

List of Reports which are failing.

Approver Delegation (Dump)

Related SAP Fix

2083663 - UAM: Approver Delegation report is generating short dump when it is run in background

Issue 8

We noticed that user group filter for the report (List Expired and Expiring roles) is not working. The User group is a very good criteria to list out the appropriate report to consume by user administrator.

Related SAP Fix

2066074 - List Expired and Expiring Roles for Users Report not working

*** Anyone interested to collaborate with the details which can add more value to this blog post, please let me know ***

The Public Company Accounting Oversight Board, established by Congress as part of the Sarbanes-Oxley Act, has responsibility to oversee audits by public companies. Since 2012, the PCAOB has been particularly active, and in September of 2014 the PCAOB announced significant changes to auditing standards have been released and take effect for companies with a fiscal year starting December 15th, 2014 or afterwards - less than two weeks from the time of this writing.


In addition to changes and proposed changes to accounting standards, the PCAOB has been actively releasing staff guidance in the form of practice alerts, directing additional validation of source reporting assumptions, ensuring that system-generated reports are complete and accurate, and verifying top-down risk assessments are conducted (one auditor acquaintance of mine recently termed the current PCAOB validation process “brutal”).

So What Does this Mean for Me?

Practically speaking, SAP customers publicly traded in the U.S. have been seeing and will continue to see increased scrutiny from their external auditors. So what does this mean for SAP customers with U.S. Sarbanes-Oxley obligations? And in particular, what does this mean for SAP customers with SAP Access Control/GRC in place to monitor separation of duties and automate security design and role assignment?


Canned Access Control/GRC reports and rule sets are relatively easy to verify assumptions around completeness and accuracy. That said, the SAP-delivered  rule set is not one size fits all – some high risks for certain industries will be medium risks for others, and vice-versa. For those of you who like to spend this time of year planning strategy for the coming year, I recommend considering the following questions when planning your FY 2015 audit report improvements to stay ahead of trends in SOX reporting requirements:


  • Have we conducted a top-down risk assessment with high, medium and low SOD risks in our AC/GRC rule set(s) in scope, and have the results been verified and signed off on by senior management? And are we able to trace rule set changes to findings in this risk assessment?
  • Mitigating controls are, by design, limited to being effective for one year. Still, many SAP customers will re-apply them for another year without giving a whole lot of thought to the underlying assumptions. Did your risk assessment ensure that the residual risk after mitigating controls is in effect is acceptable? And is there traceability of these management signoffs to your mitigating controls?
  • Are my technical controls for my GRC landscape adequately defined and documented? Have we spent time adequately negative testing GRC roles (for example, can mitigating controls owners approve firefighter requests?)
  • Have my risk owners been adequately defined by senior management and adequately documented?
  • Have my BPOs been adequately defined by senior management?


Final Thoughts

The PCAOB practice and standards changes have had and will continue to have an impact; the full extent of that impact has yet to be determined. That said, early compliance will have significantly less organizational impact than mid-year remediation.  It never hurts to plan ahead!


Related Reading





In MSMP, Access Controls 10.0 and 10.1 provides extremely flexible and powerful tool to configure workflows. In this document we will see how to create BRF+ (NOT line item by line item) MSMP agent rule by taking example of real business case in context of Access Request.



In GRC 10/10.1 SAP has provided different ways for determining agents for a stage in access request. This scenario is more to determine the Role Owner for a role using Custom BRF+ application based on Functional Area field.

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 BRF+ decision table. Hence, this blog has been created which will be helpful for the consultants who have the requirement to use Functional Area as an attribute in determining the agent for roles. The below mentioned BRF+ agent rule is developed assuming each role will have a unique functional area


Ref SAP Note: 1890452 - Functional area attribute for role is not picked up by BRF+ rule

Ref Discussion on SCN: http://scn.sap.com/thread/3661923


Steps to build the BRF Rule:


Creating BRF+ Rule for determining Agent based on Functional Area

You have to generate the BRF Rule via Transaction SPRO in GRC system. Follow the below steps in your GRC system.

Run the transaction SPRO, Go to IMG => Governance, Risk and Compliance =>Access Control =>Workflow for Access Control  => Define Workflow related MSMP rules.


Directly execute Tcode GRFNMW_DEV_RULES

  • Fill generation criteria (Process ID, Rule type, etc.)
  • Specify Generation options
  • Generate rule shell (Execute button)


Click Execute or Press F8. This now generates a successful message for BRFPlus Rule with name and ID. You can run BRF+ Tcode and can check the newly created BRF+ application there.

Now you can see the created BRF+ application as shown below.

Functions Signature Update

In BRF+ function, change the mode to “Event Mode” and activate the function as shown below

  • Since Function mode has been changed to “Event mode,” the result data object has changed automatically, so it has to be reset manually
  • In “Signature” tab of BRF Function, change the result data object to GRFN_MW_T_AGENT_ID


Create Ruleset in BRF+ Application

Create Ruleset in your BRF+ application by clicking on “Create Ruleset” button under “ASSIGNED RULESETS” tab of function. Ruleset is a combination of business rules that can only be assigned to a function in the BRFPlus framework.


Enter any name for the Ruleset and click on “Create and Navigate to object” as shown below

Ruleset will be created and you will be shown a success message as shown below

Create Rule within Ruleset - Create Expression of Type “Loop”

  1. Click on “Insert Rule” button to create new rule
  2. From within rule, click on “Add” -> “Process Expression” -> “Create” to create a new expression
  3. Create expression of type “Loop” and provide suitable name and description




Loop gets created as shown below. Processing Mode and Loop Mode maintain as mentioned below.

Create Rules within Loop Expression

First Rule





Create expression of type “Table Operation” and provide suitable name and description. In this Table Operation, we will fetch the Functional area value from Functional area table and return the result in to Functional Area field which is part of structure GRAC_S_API_ROLE_FUNC_AREA





Second Rule

Create an expression of type DECISION TABLE as shown below and create a rule change agent ID in agent ID structure after processing each entry in Decision table.












Third Rule

Third rule is used to assign value to context as shown below. This rule will be included in your loop for inserting the values into Agent ID table after processing each LineItem.



When an employee joins the company he requires SAP Access. The general process I the manager or supervisor of the employees sends an email to the SAP Security with the required roles and the user is provisioned in the required backend systems. This process does works but everything is manual and there is no clear audit trail. There is also no guarantee that the roles were properly assigned.




This is where the SAP GRC 10.0 User Provisioning tool can help. The key engine which drives this process of the approval workflow is called MSMP - Multi Step Multi Process. This will automate the process. Let us understand the MSMP from high level so beginner can understand the configuration


Step 1 ( Process Global Settings) - Execute MSMP Configuration from the SPRO menu to come to MSMP main screen. Here you need to note the process ID which is SAP_GRAC_ACCESS_REQUEST and it is liked to GRAC_AR_INITIATOR. Only one initiator can be linked to the process id.



Step 2:  (Maintain rules) - In this step we are going to look at the result value of the GRAC_AR_INITIATOR which drives the path of the work flow. Here the GRAC_DEFAULT_RESULT is the result value. This value will be used to find out how the request is going to flow when you create a request


MSMP_2_Maintain Rules.jpg


Step 6 (Maintain Route Mapping) – In this step we look for the GRAC_DEFAULT_RESULT and see which path it is mapped to GRAC_DEFAULT_PATH


MSMP_3_Routing Path.jpg


Step 5 Maintain Path – In this setting we look for the GRAC_DEFAULT_PATH and identify the Stage in the Path. This shows that there are two stages which are manager and Security. Now we need to understand how the approvers are assigned to the stages. The approvers assigned to the stage are ZGRC_MANAGER and ZGRC_SECURITY






Step 3 Maintain Agents – In this step we are looking are defining the agents and linking them to the PFCG role. The users assigned to this role will be the approvers of the request coming to this stage




Now when you create a request the following high lighted request which are mapped to Process id SAP_GRAC_ACCESS_REQUEST will follow these two steps and get provisionined into the system


Hope this help. Give your feed back and comments


Filter Blog

By author:
By date:
By tag: