Best Practices from Oracle Development's A‑Team

Simplified Role Hierarchy in R10


Our teammate Jack Desai published an article last year about Fusion Application Roles Concept. It gives you a great overview about the design to grant access to certain functionalities to specific users. His article familiarizes you with the concepts of Abstract Roles, Duty Roles, Job Roles or Data Roles and how they are used in a Role Based Access (RBAC) model in Fusion Applications.

Starting with the current Fusion Apps Release 10 further improvements in the role concept have been implemented resulting in flatter role hierarchies. More detailed information about the Simplified Reference Roles Models can be found in Oracle Support DocId 2016990.1.

The following article below will give a short introduction and overview about the changes and perform a brief comparison of features between role hierarchies in R10 and pre-R10.

Role Hierarchy Changes in R10

As shown in the drawing below the main change is a simplification of complex structures in pre-R10 releases. For this purpose the old Duty Roles have been deprecated and replaced by newer versions with different and leaner assignments. These assignments can be other roles or even privileges. The previous model sometimes had many Duty Roles assigned to Job Roles. As a result creating custom Job Roles could become a challenge.


By introducing a simplified reference model the following benefits were achieved in R10:

  • New model provides a clean reference
  • For customers not using any customized roles the new features have been seamlessly activated, so customers won’t even notice these changes as the new features were installed during the R10 upgrade or provisioning process.
  • For Oracle Applications Cloud some new capabilities have been implemented to allow new features in an isolated model
  • Last but not least with R10 we’re having a reduced number of roles compared to the role model pre-R10

The most visible aspect of the Release 10 simplification is the introduction of an Application Job Role and a reduced number of duty roles when compared to the role model in the previous release. Also worth to mention is that newly created Application Role Names start with a prefix “ORA_”.


As shown in figure above these changes in R10 include also an evolutionary process of modifications in terms of privilege assignments to duty and/or application roles. However the new role reference model doesn’t necessarily affect the setup details of these privileges (i.e. Entitlements, Resources etc). If there are changes for privileges in R10, theses might have been caused by functional and technical requirements in Fusion Application. Almost obvious to say that these changes in R10 are valid for entire Fusion Applications and work the same way for on-premise and Oracle Cloud instances.

Comparison of sample roles Pre-R10 vs R10

When comparing the both role models we should start with the similarities between pre-R10 and R10 role models as they are:

  • The set of privileges to control assignment of features or functionality is the same in both role models
  • In case of using an existing privilege that Oracle Application Cloud has modified to improve existing functionality, then both models benefit from the improvement.
  • The duty roles are organized by application sources (i.e. Product Pillars), such as Customer Relationship Management (CRM), Human Capital Management (HCM) and Financial Supply Chain Management (FSCM) in both role models.

As mentioned above the main differences are the hierarchical organization of roles under the Enterprise Job Role level. The figure below illustrates these changes for the sample of Sales Enterprise Job Role:

  • Every Duty Role named “Sales Representative Duty” in pre-R10 is an individual implementation per Application Source like CRM, FSCM etc
  • It is also possible to assign different duty roles in the context of an Application Source to the Enterprise Job Role

As shown in our sample below the Sales Representative Duty role exists for various application sources and could give the impression they refer to the same role as they are sharing almost the same display name in pre-R10 releases. In reality these are different roles! For instance the Sales Representative Duty role for CRM can be found under a role name ZBS_ENT_SALES_REPRESENTATIVE_DUTY while the role with same display name exists in HCM with the name ZBS_ENT_SALES_REPRESENTATIVE_DUTY_HCM.

In R10 we see that there are also Sales Representative roles assigned to Sales Representative Enterprise Role, but we notice the following differences:

  • The suffix “Duty” as part of the displayed name is gone as these are Application Job Roles assigned at top level now
  • All these same visible names refer also to the same role ORA_ZBS_SALES_REPRESENTATIVE_JOB
  • As mentioned above the internal names of these new roles start with a prefix “ORA” and can be easily identified as a new role by its name
  • By the suffix “JOB” these roles can be identified as an Application Job Role while Duty Roles are registered with a suffix “DUTY”


As said the Application Job Role with the display name "Sales Representative" refer to the same role with name ORA_ZBS_SALES_REPRESENTATIVE_JOB across all Application Sources. Furthermore the usage of Role Categories has been introduced. These role category assignments put roles into a dedicated context and can be used for isolation in Cloud. In our sample the "Sales Representative" role is assigned to a Role Category named “CRM_ENTERPRISE_DUTY”. The Application Role Hierarchy might differ for roles with same names (like "Sales Representative") across the various Application Sources. For instance the "Sales Representative" role for HCM has the following Application Role Hierarchy assigned :


The same Application Job Role for FSCM contains a different Application Role Hierarchy used in that specific application context:


For a better illustration of differences between these both role models pre-R10 vs R10 sample screenshots of Fusion Apps Authorization Policy Management (APM) are shown below.


Starting point is the External Role “Channel Account Manager” in a pre-R10 instance with the internal name ZPM_CHANNEL_ACCOUNT_MANAGER_JOB as shown above. The screenshot below highlights the Application Role Mapping with various different Duty Roles assigned.


In R10 this External Role is unchanged (means: same name) but Application Role Mapping is different as shown in screenshot below. As mentioned previously there are Application Job Roles assigned in R10. Only a few duty roles for OBI are reused for technical reasons to provide continuity for some features. These are roles used by internal systems, such as role codes that end with _PRIV_OBI, which are used to secure reports. These roles don’t have the ORA_ prefix in the role code. You must never modify these roles.


In pre-R10 releases Duty Roles had the term “DUTY” included in internal name and also in display name (see screenshot below).


This role setup changes in R10 (below) as the prefix ORA has been added for newly created roles. As screenshot below indicates, the term JOB is added as suffix for Application Job Roles.


Another new feature is the assignment of Job and Duty Roles to specific Role Categories as shown below. The existing assignment is not to be changed by an user for standard roles.


As shown in the screenshot below the pre-R10 Duty Role has a dedicated layout in Application Role Hierarchy


In R10 the Application Role Hierarchy looks different as it has been reworked and flattened.


Duty Roles in R10 follow the name scheme with ORA as prefix and DUTY as suffix as shown below.


Policies assigned to these Duty Roles in R10 might be the same as those in pre-R10. Any changes between releases will have been caused by functional or technical requirements in various Application Sources during release changes (being done automatically when upgrading a certain release).


Screenshot below shows the detailed privileges (Entitlements) at the lowest level to grant access to pages, page flows, data or interfaces (all of then are called "Resources"). As said these structures are not affected in R10 by switching to a simplified role reference.


Upgrade of role customization in R10

In case any custom job roles have been created in pre-R10 instances a migration to the simplified reference role model is necessary. As shown in the figure below the links to old duty roles must be removed and another link to the according Application Job Role in R10 created. Detailed instructions can be found in various documents under Oracle Support DocID 2016990.1.



This post provides an introduction to recent changes in the Role Model in R10. It is supposed to be seen in the context of the previous post about RBAC in Fusion Applications. Some more changes have been seen in R10 for security related topics and more posts on this site will follow to cover those.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha