Advanced Guide Conditioning Using Shell Roles

Fusion Roles

In Fusion Applications, users are segmented into groups based on their roles. These roles help customize the Fusion features for different groups, such as employees, contractors, managers, etc. For instance, employees are restricted from accessing certain features, while managers have exclusive access to additional features that correspond with their roles. This is achieved by segmenting user access using Standard and Custom Roles.

Example of Standard and Custom Roles in Fusion:

OGL Guide Conditioning Using Standard and Custom Roles

OGL utilizes the same user segmentation roles as Fusion to ensure proper guide conditioning. This means that specific OGL guides will only be accessible to certain user roles in Fusion. For example, in the case of managers, OGL uses the role code for managers from Fusion to ensure that only designated guides are accessible to users identified as managers.

However, Fusion applications have a limitation in segmenting users into sub-cohorts using Standard Roles and Custom Roles since the Fusion Security Console team has chosen not to include many of these attributes in LDAP (Lightweight Directory Access Protocol). And therefore, Fusion doesn't have the capability to segment users according to their specific job designation, the business unit within the organization, or the departments within the same business unit. For example, Fusion segments users into employees and managers. But Fusion doesn't segment the employees into sub-cohorts, like Junior Analysts or Developers.

Therefore, OGL cannot use the current Fusion role codes for tailoring guides to specific cohorts, such as Developers or a particular business unit within the organization.

What is a Fusion Shell Role and How it is Useful for OGL Guide Conditioning

A Shell Role, as its name implies, is a dummy role that Fusion users can have in addition to their Standard and Custom Fusion roles. They are empty roles. Shell Roles are created by the client administrators, and they do not provide access to any of the Fusion features. These dummy user roles are assigned and restricted to, and only to, a specific group of employees that represents a cohort or a sub-cohort, like a specific employee group (Analysts, engineers, etc.), a business unit of an organization, or even a department within a business unit.

Once assigned to cohorts, the role code of the same Fusion Shell Role is added to the OGL console to customize the OGL guides to specific cohorts. So, this sub-level user segmentation in Fusion enables OGL to develop and deploy unique content for specific employee groups, a business unit of an organization, or even a department within a business unit.

Important:

• Customers/users are responsible for creating Shell Roles in Fusion Application, as per the requirements.
• As a Self-Service customer, you can create Shell Roles in Fusion and include them in the OGL Custom Roles list on your own.
• As a Managed Service customer, you can create Shell Roles on Fusion and provide them to your Project Manager. Oracle will then include these Shell Roles in the OGL Custom Roles list.

Example of Fusion Shell Roles used in OGL Custom Roles:

Process in a Nutshell

Here is an overview of the process:

1. The Fusion customer identifies the OGL guide conditioning requirements for each cohort.
2. As per the guide conditioning requirements, the Fusion administrator creates the Shell Role(s) in the Fusion Application.
3. The Fusion Administrator then adds the Shell Roles to the respective cohorts.
4. For Self Service customers:
   Add the Shell Role(s) to the OGL Custom Roles list.

   1. Go to the OGL console.
   2. Go to Settings > Custom Roles.
   3. Select New Role.
   4. Enter the OGL Role Name and the Application Role Value.
   5. Select Save Roles.
      
5. For Managed Service customers:

   Supply the Shell Role(s) details to your OGL Project Manager. Afterward, Oracle adds the Shell Roles to the list of OGL Custom Roles.