Expand all | Collapse all

Why to fully customize ERP Cloud roles

  • 1.  Why to fully customize ERP Cloud roles

    Posted 03-31-2020 11:43
      |   view attached
    Some food for thought... Would love to hear others feedback on this.

    Role Design – Seeded, Hybrid, or Custom Roles?

    We will start out with the most important and fundamental question in delivering security for Oracle ERP Cloud: what to do with out of the box seeded roles.

    There are three types of roles: seeded roles, hybrid roles, and fully customized roles.

    Seeded roles are roles that have been provided by Oracle – loaded as part of the installation of the software.  They get their name because they are seeded with the application.  The majority of new ERP Cloud implementations are exclusively using seeded roles to get the implementation functioning correctly for the "go live".

    Seeded roles inherit other roles.  However, seeded roles are primary made up of Duty roles.  Duty roles can be thought of as process roles as they include groupings of privileges related to subprocesses within a business process.  For example, one duty role would have the privileges necessary to enter invoices in the payables module.  A different duty role would have the privileges necessary to process payments in the payables module.  These two duty roles may role up to a Payables Specialist job role.

    So, to go into more detail – there are seeded job roles and seeded duty roles.  Each Job role is made up of one or more Duty roles as illustrated above.  Each Job role can also have privileges directly assigned to it.

    When Oracle patches a client's system (quarterly), they can add or remove privileges within a Duty role and can add or remove privileges within a job role.  In this same way, they can add or remove Duty roles within a Job role.

    When building a custom Job role, you can simply customize the Job role, but leverage the seeded Duty roles, as is, or you could also customize the Duty roles and use the custom Duty roles in the build of the custom Job role.  This is what we'd refer to as a hybrid role.  It is a custom Job role with at least one or more seeded Duty roles.  This means that when a patch is applied to the system, privileges could be added or removed from the Job role because the seeded Duty role could have privileges added or removed.  If privileges were to be added to multiple Duty roles with the patch, and some of those Duty roles are now custom, they would not allow for the updates.  A partial update would then take place.  This can cause serious issues to hybrid roles.

    A fully customized role would be a Job role that doesn't leverage any seeded Duty roles.  If a role is custom and all Duty roles within that Job role are customized, a patch would not impact the role design.

    To recap the different types of roles:

    • Seeded role – implemented by Oracle as part of the way the application is designed. This leverages only seeded Duty rules
    • Hybrid role – a custom Job role that leverages at least one seeded Duty role
    • Fully Customized Role – a role customized by the client that leverages only custom Duty roles in its design.

    Remember that Oracle will patch the Seeded roles and Duty Rules four times a year.  Also remember that many Duty roles have privileges that should not be used due to Sensitive access risks (one or more privilege will need to be removed) or one or more privilege that will cause an SoD conflict within that role or between that role and another role. 

    An organization has a choice to make as it relates to role design.  It can either:

    • Use Seeded roles
    • Use Hybrid roles – meaning the Duty roles will be updated to have privileges either deleted or removed.
    • Use Fully customized roles – meaning the roles will not be impacted by the patches at all.

    Seeded role

    Pros: roles will inherit all changes

    Cons: changes may introduce new sensitive access risk and segregation of duties conflicts.  Most seeded roles also inherently have sensitive access risks and segregation of duties conflicts.

    Hybrid roles

    Pros: roles will inherit some changes.  This could be good from an operational perspective because the user(s) have access to that role will gain new privileges (new abilities being provided by Oracle), if applicable.

    Cons: roles may inherit a privilege that will not be identified as having risk leading to a Sensitive Access risk or to cause an SoD conflict.  A partial update could take place causing the role to "break" and some functionality may be lost due to the missing pieces.

    Fully Customized roles

    Pros: a patch will NOT impact the abilities of the role.  No new privileges will be added unless the role is specifically modified to add the privilege.  This is the least risky approach from a GRC perspective.  This will enable companies the ability to fully test the new functionality in a development environment to ensure the process works as is expected and wanted.  They can then add the functionality to the custom job role exactly where it is required and desired.  Training can take place to ensure it is used properly. There will be no surprises to functionality showing up unexpectantly.

    Cons: new privileges that are added to that module will not be made available to those being assigned this custom role.  For the functionality to be made available, it needs to be added to the Duty roles or directly to the Job role.

    Most commonly implemented approach when risks are made clear to management

    The most commonly implemented approach taken by management when the risks are made clear is to go with fully customized roles.  This approach would allow management to defer having to made changes to roles every quarter since none of the fully customized roles would be patched. 

    There are two caveats to this:

    1. Management rarely is willing to pay the system integrator or another firm (like ERP Risk Advisors) to fully customize the roles. Usually the system integrator will say the development of fully customized roles aren't in scope.  And, most often, the contract between management and the system integrator favors the system integrator – after all the contract between the two organizations don't often go into this level of detail.
    2. By the time this approach is explained to management, there usually isn't enough time in the project ( or budget) to execute this approach (If the organization isn't live yet).

    Therefore, every organization goes live with, is a combination of Seeded, Hybrid roles, and maybe a few fully customized roles. 

    Unfortunately, Oracle doesn't provide a thorough way to easily and completely identify the impact of the patches during the quarterly patching process.  Even if they did, management often only has two weeks from the time the patch is applied in a non-production environment until it is applied to the production environment.  That is NOT enough time to do a full impact analysis and to identify what changes are needed to the roles to keep their organization in compliance with the objectives they have identified related to SoD conflicts and Sensitive Access risks.

    Thus, when faced with the facts, management typically agrees to move to fully customized roles.  In doing so, they accept the following:

    • Risks are minimized by not allowing roles to be updated by patches
    • Some roles may not work fully because the patch may add something that is needed to work after the patch. Thus, users need to perform testing of their roles as part of the two-week patch window.  If they identify something that isn't working the role needs to be remediated
    • A process needs to be put in place, at least annually, to identify what has been introduced through patches, how that needs to be rolled out to users, and what changes to rolls will be needed to use the new functionality.


    Most companies realize that staying with seeded roles introduces too much risk and move to custom roles. When moving to custom roles, t(here is no 'stick your head in the sand and do nothing' option.  Management MUST do a patch impact analysis at some point.  By fully customizing the roles, they can delay the patch impact analysis to once per year.  By using seeded roles or hybrid roles, they must do a patch impact analysis each quarter.  There is no right answer.  Whatever choice management makes, they must put a governance process in place to manage the operational, fraud, security, and compliance risks.

     Contact me at for questions or comments on this.  A copy of the above can be downloaded per the attachment.

    Jeffrey Hare
    ERP Risk Advisors
    Greeley CO
    (970) 324-1450


  • 2.  RE: Why to fully customize ERP Cloud roles

    Posted 06-18-2020 10:43
    Edited by Heather Robinson 06-18-2020 10:48
    Interested in an on-demand webinar version of the post above? I'd like to share a link for readers to hear Jeff from ERPRA discuss this process first hand in our on-demand session here: 

    Heather Robinson
    Fastpath Solutions, LLC
    Des Moines, IA