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:

  1. SAP GRC User Masters via SU01
  2. NWBC Access Control Owners (assign as Role Owner)
  3. NWBC Role Owners (User to Condition Group)
  4. BRFplus Function for APPROVER
  5. Assign Condition Groups to BRFplus Functions
  6. 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.

 

1 Generate.jpg

 

You need to complete the Application Name and the BRF+ Approvers Rule (note, these names are used in the next step as well).

 

2 Decision Table.jpg

 

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.

 

3 IMG Config.jpg

 

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…

 

4 table config.jpg

 

 

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).

 

5 nwbc mapping.jpg

 

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.

 

6 end result.jpg

 

 

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

To report this post you need to login first.

7 Comments

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

  1. Raj Kumar Salla

    Colleen,

    As usual excellent doc from you.

    Also i supported your Idea.

    I really enjoyed on clicking Default approvers to see Approvers arepopulated 🙂

    “Associate  Methodology Process To Condition Group” under Role Management looks like can be ignored for this situation. Am i correct?

    Regards

    Raj

    (0) 
    1. Colleen Hebbert Post author

      Thanks for your feedback and upvoting the idea.


      I have another document that’s work in progress to explain the methodology scenario. It’s on the list of this week 🙂 It is not required for default approvers but can cause confusions as “condition group” is used twice in BRM for different purposes (I got caught out the first time).

      (0) 
  2. Sara G

    Dear all.

    I have the following requirement:

    1. Requestor creates access request and sends out to the next stage role owner
    2. This role owner is dynamic and is selected based on the User Group assigned into the form Access Request.

    So i was wondering if with requirement could be covered with this Condition Group or maybe i have to consider an alternate solution – like for example an Agent Rule.

    My initial solution with the Condition Group was:

    • To define the following decision table:

    usergroup.JPG

    As you can see my condition column is USER_GROUP and the result is the GRAC_CNDGP.

    I have added the User Group field and the structure behind – GRAC_S_REQUEST_RULE_LINE – manually cause this field is not given by default.

    • Remove the role owners from the roles cause i have defined the role owners in the following table Role Owners. As you can imagine the GRAC_CNDGP are mapped into the table below with the User Role Owners:

    roleowners.JPG

    So i was expecting the following

    1. I create an access request
    2. CondGroup checks which is the user group and then sends out the workitem to the role owner defined into the table showed below.


    However it is not working because GRC indicates there is not RoleOwner defined to the role.

    So my questions are:

    • Can i use the Condition Group functionality with another attributes not related to the roles like for example the User Group?
    • I know with Agent rule i could cover this functionality, however i am thinking in the future maintenance and i would like to avoid to maintain BRF+ anytime there is a new roles or there are new approvers.

    Kind regards and thank you very much in advance.

    Sara.

    (0) 
    1. Colleen Hebbert Post author

      Hi Sara

      This condition group is all about defaulting the approvers into BRM (in which they then become Role Content Approvers or Role Assignment Approvers for the BRM or ARQ workflows)

      You could consider using that table and a BRF+ Dblook up similar. I never configured an Agent Rule in BRF+ – first and lasts time I attempted I thought you could only return on approver per line instead of multiple approvers.

      If you are going to try to leverage this table, you might want to look a a function module or similar to return the values instead of BRF+. This is where I get out of my depth and would need to call on the expertise of a developer.

      For Role Review workflow, the program needs to the Role Content Approver to be in the approval table in BRM. I don’t think you can avoid leaving the BRM approvers out of the role even though the MSMP rules are not using them. I think same also applies for UAR.

      Regards

      Colleen

      (0) 
  3. Zarina S

    Hi Colleen,

    Excellent document.

    I have a query. Can we use this condition group of default approvers based on location.

    Our requirement is single roles should be approved by owners based on location. We have around 20 locations.

    Please advice.

    Zarina

    (0) 
    1. Colleen Hebbert Post author

      Hi Zarina

      When you build the BRF+ rule have a look to see if Location is an attribute that you can add to the decision table. Once you do this, setup a condition group for each location and map the approver to the appropriate condition group. You will then default the approver

      This assumes the role “belongs” to one location… and that location is an attribute that you can define the decision table by.

      Regards

      Colleen

      (0) 

Leave a Reply