Skip to Content

BRM Role Methodology via Condition Groups

3/Nov/2016 – Blog updated for re-tagging. Content migrated from SCN

This document has been written to explain how you can customise the ROLE METHODOLOGY steps depending on role criteria. The configuration requires the use of a BRF+ rule that using CND_GRP (condition group) as the rule result.


Please note, that this is not the same as Condition Group Mappings for Default Approvers (specified via NWBC screens). If you are interesting in the condition group mappings for default approvers then click here: BRM Default Approvers via Condition Groups


What’s it all about?


Business Role Management makes use of the role maintenance process steps known as the Role Methodology. You have two options with configuring Role Methodology:

  • Default only – every role will have the same set of methodology steps. You can alter the default in IMG, however the steps apply to all roles. The default is also the methodology steps that is loaded when you first choose to create a new role.
  • Custom BRF+ – configure use of condition groups and map different role methodologies depending on the role criteria. This provides great flexibility to have different steps depending on role information; require approval for some and not others; and a different sequence of steps.


Why isn’t the default enough?


This all comes back to your BRM design (funny that). If you have business rules that determine different scenarios for roles then you will want a set of steps to match them. For example, you might decide the Process Owner (i.e. Role Content Owner) does not need to approve Derived Roles so you don’t need an approval step. You might have decided Business Roles don’t need Test Documentation (random example here). You might even decide you’d rather a different sequence of steps depending on the role (i.e. Approve role before making a change).


Put simply, default methodology is inflexible and may not match your business process for role management. Configuring multiple methodologies allows you to match process to steps in the system.



Just a few lessons learned before we hit the configuration


From configuring this functionality and also responding to questions in SCN, there a few lessons learned I thought I’d share relating to this topic.


Why do some roles miss some role methodology steps?


Okay, I’m going to contradict myself to what I said above. The default methodology is meant to apply the same steps to all roles regardless of role criteria. However, the GRC component has an additional mapping table in the back-end that determines which methodology steps apply to the specific role. For example, a business role is a non-technical role and therefore, would never require a step to “Maintain Authorisations”. As a result, if you were to add “Maintain Authorisations” as a step for a Role Methodology that applies to business roles, it still will not appear in your NWBC screens.



When is the role methodology going to take place?


When you build a role for the first time, the calculation of the role methodology does not occur until after you press save on the DEFINE ROLE stage. Only the attributes related to the definition phase can be used as the criteria for the role methodology. Initially, the default methodology will appear. On save of the Define Role stage a “recalculation” of the methodology will occur.


The Role Methodology is not determined until:

  • Create New Role > After the Role Definition is saved (default methodology will load)
  • Maintain Role > On open the methodology will load (possibly you may need to Reapply Methodology if the configuration has changed)
  • Reapply Methodology – it will check if layout needs to change and adjust accordingly



My approach has been to include 1 step for the default methodology – Define only. This removes all other steps from the user. When they press save, the role is then evaluated and the process steps are calculated and added to the NWBC screen to continue role maintenance. My thought was this makes it clear to the user that the steps will be defined once they specify the role attributes.



What does this mean in the NWBC?


The Default Role Methodology (box selected in Define Methodology Processes and Steps in IMG) will load when a new role is created, regardless of role type (as per screen shot below).


1 nwbc default.png


On completing and saving of the Define Role > Details information, the BRFplus rule is executed and the methodology is updated. The GRACROLE table stores the methodology for the role and the step is it up to.


2 NWBC methodology.png


If changes are made to the role methodology, the administrator can choose to “Re-Apply”. The Role Definition in GRACROLE table is re-evaluation and if it does not match the methodology, the methodology will reset.



Summary of Steps to configure Methodology


This section does not capture the Business Role Manage configuration steps for other aspects of BRM (such as role type, project, etc). This is a high level overview of the step intended to show you how the configurations comes together. It is not meant to act as step by step instructions.


  2. BRFplus Function for METHODOLOGY
  3. Assign Condition Groups to BRFplus Functions
  4. Define Methodology Processes and Steps
  5. Associate Methodology Process to Condition Group




Activating this BC Set will provide the baseline configuration date for role types, steps, etc is populated. Regardless of your design, it is best to activate this BC Set and then make the necessary configuration changes.



[2] BRFplus Function for METHODOLOGY


The IMG provides a step to automate creation of the BRF+ rule by creating the application, function and decision table structure.




IMG Navigation: Governance, Risk and Compliance > Access Control > Role Management > Generate BRFPlus Applications, Approvers, and Methodology Functions


3 Generate BRFPlus.png


One the program has created the BRF+ function and decision table, you can then maintain the decision table. In this, you will need the CND_GRP as your output. Create a rule for each different role scenario you need to handle.


4 Decision Table for CND_GRP.png


The Column Name for GRAC_CNGP is the return result. These values must match the Condition Group Id in Associate Process Methodology to Condition Group.



[3] Assign Condition Groups to BRFplus Functions


IMG Navigation: Governance, Risk and Compliance > Access Control > Role Management > Assign Condition Groups to BRFPlus Functions


Within the IMG you need to tell GRC which BRF+ function to execute when Methodology is evaluated. Again, Condition Group is used but it is not the same as the CND_GRP that you mapped out in the previous step. You only need to create one entry for METHODOLOGY and map it to the Application/Function that you created. Unlike the MSMP, you do not enter the Application or Function Ids (alphanumeric number).


If this step is not completed, then BRM will only use default methodology.


5 Condition Group Type for Methodology.png


From a background table point of view, the GRACCNDGPTYPE contains technical information used to build/evaluate the Methodology rule.





[4] Define Methodology Processes and Steps


In this step you build each methodology scenario. For each scenario, you then define the necessary steps including the sequence. The Define step information will come as part of the BC Set. There should be no need to update this configuration unless you need to add the elusive Provisioning Step.


7 define methodology process.png


[5] Associate Process Methodology to Condition Group


IMG Navigation: Governance, Risk and Compliance > Access Control > Role Management > Associate Methodology Process to Condition Group


In this step of the configuration, you need to map the BRFPlus Results for Condition Group (CND_GRP) to the Methodologies that you just configured. You are able to map multiple condition group outputs to the same methodology step.


8 cnd to meth mapping.png


Useful Tables

Table Description/Comments
GRACCNDGPTYPET GRC ERM Condition Group Type Text
GRACCNDGPTPBRF Condition group type to BRF+ function assignment
GRACCNDGPMTH Condition Group to Method



Happy role building with Access Controls







P.S I would love to hear your thoughts on designing the role methodology configuration and lessons learned.

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

    As usual 6 stars rating on a scale of 5 for this article…..

    Need a special mention for this wonderful tip…

    My approach has been to include 1 step for the default methodology – Define only. This removes all other steps from the user. When they press save, the role is then evaluated and the process steps are calculated and added to the NWBC screen to continue role maintenance. My thought was this makes it clear to the user that the steps will be defined once they specify the role attributes.

    A small doubt though….please spare some time on this


    What about the approver condition group? Why do we use that?

    In the example, I didnt see the function name ZERM_ROLE_APPROVAL_ROLE created. Please throw some light on this

    Thanks in advance


    Deepak M

  • Hi Colleen,

    do you know, if it is possible to get the methodology step “generation” in the business role. I am confronted with the follwing issue, my business rule is generateable with conflicts, because I have only the methodology step access risk anaIysis available.

    I did the configuration for the Condition Group+BRF+ etc. but the Methodology phase”Generation” cannot be included.

    Do you know if the Generation Step is hardly exluded for business roles?

    Thanks for your feedback,



  • Hi Colleen,

    My Role naming convention, is not getting applicable, when i am trying to create a role.i.e I have defined Free text, Static text, etc., but the role name still remains blank, after filling up the all the fields, to its left(Business process, etc.)

    Could you say how it can be achieved, or can you include it in this document.



    • Hi Plaban

      Please open a discussion and show your configuration steps and screen shots as your issue is not the same as this blog