3/Nov/2016 Blog updated for re-tagging due to SCN migration
This document has been written to explain the Default Approver functionality in Business Roles Management and provide the high level steps to configure. Please note, the configuration of this CND_GRP (Condition Group) is not the same as Role Methodology (I will cover this is a separate document). Both concepts do however use BRF+ and IMG Configuration to achieve.
For more detailed configuration steps, refer to the BRM Wiki for this topic: Implement Condition Groups in Role Management - Governance, Risk and Compliance - SCN Wiki
Default Approval Usage
The purpose of default approval is to allow you to centrally maintain approvers based on a set of criteria to default to your roles. In doing this, you do you reduce human error of assigning the incorrect role assignment or content approver to the role. These Access Control Owners are used as Agents in MSMP for Business Role Management Approval and Access Request Management workflows.
Requirements for Approver Setup
For approvers to be assigned to a BRM role they must be setup in GRC system and the following configuration in place:
- SAP GRC User Masters via SU01
- NWBC Access Control Owners (assign as Role Owner)
- NWBC Role Owners (User to Condition Group)
- BRFplus Function for APPROVER
- Assign Condition Groups to BRFplus Functions
- Default the approvers on the role
Steps 3 onwards will be detailed in this document.
Pen to Paper and Get your Design Right
Before you start to configure these you need to determine your mappings. To do this you need think through the following:
- Role Content Approvers
- Who is allowed to approve a security role content change (i.e. the BRM workflow approval and role certification)?
- Is it the same approver for all roles?
- Do you have different Role Owners based on an attribute (you might split based on Process Area and/or Role Type, etc)?
- Role Assignment Approvers
- Who is allowed to approver access to the roles (i.e. the ARQ/CUP/UAR workflows)?
- Same types of questions as the ones you needed to answer for Role Content Approval
The system will allow you to have different approvers for Role Content and Role Approval for the same condition group. If you find yourself thinking that you need managers to approve, etc, for access request then you would not use the Role Owner Agent in the MSMP. Role Owner approval would be useful where you have specific roles requiring approval by a central person/area (such as a sensitive roles).
To assist in your Condition Group to Approver Mappings and BRF+ configuration, it is useful to start building up a spreadsheet as you identify your scenarios. For each of these scenarios you come up with, you will need to create a condition group. However, you need to consider that each role can only “calculate” one condition group in the return (more on this later).
Build your BRF+ Rule
For the purpose of this document, I am only showing a simple decision table (this is the level also covered in GRC300 training) as the goal of this document is to show how the default proposals for approver work as opposed to how to configure BRF+.
Via the IMG (path Governance, Risk and Compliance > Access Control > Role Management > Generate BRFPlus Applications, Approvers, and Methodology Functions) you can generate the ERM BRF+ rule to contain the correct data structure and decision table for your rule.
You need to complete the Application Name and the BRF+ Approvers Rule (note, these names are used in the next step as well).
Within the BRF+ you need to maintain you decision table with the result field for condition group. When you maintain this, you need to capture all possible role scenarios. For example, if you are building you condition groups based on Business Process then make sure each business process is mapped to condition group.
If you put the effort into your design, you should rarely need to modify the BRF+ as it is transported. You might find need if you introduced new modules or criteria. However, condition groups should remain fairly static whilst the approvers assigned to them can change.
Tell BRM what to logic to execute when the “Default Approver” button is pressed
This step is really known in the IMG as “Assign Condition Groups to BRFPlus Functions” as per the screen shot below. However, this is actually the link from the user’s front end (via a few steps in code) to know what BRF+ function to execute.
This is where I used to get confused with the different “condition groups” as GRC has used condition group a few times for different purposes. In this particular step I pretend condition group is actually Scenario. You need to set up a Scenario for APPROVER.
You can only maintain one entry for the APPROVER and that is the BRF+ Application and Function that you just created above. Unlike other areas of GRC, this time you provide the actual name instead of the alphanumeric Id.
SAP delivered configuration in the backend included table GRACCNDGPTYPE that maps the Scenario (condition group) and identifies the output as the GRAC_CNDGP which is maintained as the result for the BRF+ function. Shown below for those interested…
Assign the Condition Group to Users
Navigate to NWBC > Access Management > GRC Role Assignments > Role Owners (entries are stored in table GRACCNDGPAPV) to map the Condition Groups to the Access Control Owners (assumption that you have created the SU01 Account in GRC and also defined the user as Role Owners).
The following rules apply in this step:
- There is no check to verify that you have selected a valid condition group
- Although no check, enter condition group Ids that you specified in your BRF+ results
- A user can be assigned to multiple condition groups
- A user can be assignment approver, role content approver or both for the specified condition group
- Multiple uses can be assigned to a condition group (necessary if you are separating approvals)
- Alternative approver is optional
- Updating this table will not automatically update the approvers. You will need to edit the role and default the approvers in again (or mass update the impacted roles)
Make sure you have at least one approver for each condition group to avoid errors (or lack of default approvers) when users press the “Default Approver” button in BRM.
Time to Default the Approver
If your configuration is completed and correct, next time you press Default Approver:
- You will be asked to confirm that you want to proceed
- All current entries for the role will be removed
- The BRF+ function will be evaluated and condition group returned
- The approvers assigned to the condition group will added back to the table
In the example below, although the same approver remains they no longer have role content approval rights. If no other approvers are added, this will be an issue unless the methodology does not require an approval step.
Improvements
This functionality is good to consistently default approval. However, its shortcoming is managing changes to approvers. For example, if a person leaves the companies or changes job their approval activities are transition to someone else then you need to update each role to default the new approvals. As a result, I raised this idea (quite some time ago). If you like this functionality and agree with this shortcoming, then please upvote the idea.
Regards
Colleen
- SAP Managed Tags:
8 Comments
