6 Guide Conditioning
This chapter contains knowledge articles related to Guide Conditioning.
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:
- The Fusion customer identifies the OGL guide conditioning requirements for each cohort.
- As per the guide conditioning requirements, the Fusion administrator creates the Shell Role(s) in the Fusion Application.
- The Fusion Administrator then adds the Shell Roles to the respective cohorts.
- For Self Service customers:Add the Shell Role(s) to the OGL Custom Roles list.
- Go to the OGL console.
- Go to Settings > Custom Roles.
- Select New Role.
- Enter the OGL Role Name and the Application Role Value.
- Select Save Roles.

- 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.
How to use FQIDs in EPM Application
This topic helps you to use the FQIDs in the EPM Application.
- What is FQID?
FQID (Fully Qualified ID) is a unique identifier used to segment or restrict a guide to a particular page within an application.
- Why we use FQID?
- It's important to understand that within the EPM application, the FQID serves as a precise identifier for a page or component, making it ideal for scenarios where a guide needs to be triggered only under very specific conditions.
- In the EPM application, FQIDs are used to manage complex interactions where different pages or elements may have similar characteristics but require distinct handling.
- Utilizing FQID in the EPM application ensures that guides appear exactly where intended, maintaining accuracy and preventing users from encountering guides on irrelevant pages.
- How to use FQID?
- Go to the application you want to work with.

- Inspect the page by right-clicking and selecting "Inspect" or
pressing F12 to open the Developer Tools.
- Navigate to the Console tab in the Developer Tools.
- In the console section, type the following command and press Enter:
iridize.diagnose()
- A new pop up will open.
- In the popup, select the second option: Guides Break and Stop
Running.
Note:
For more information regarding the Diagnostics Tool, just click Diagnostic Tool - Copy the page ID value.
- After selecting the option, several points will be displayed. Look for the point Page ID.
- Once you locate the Page ID, copy the value as shown in the
below attachment. You will need this information to set up the
guide's activation condition.
- Go to the application you want to work with.
- Go to the guide you've created (e.g., a process guide or message
guide).
- Open the "Activation Settings" tab.
- Select "Advanced Condition" to configure the activation
criteria.
- In the condition settings, choose "When page has session
variable.
- Set the key as "g_efsOglFqId", In “Enter Session Variable” field which
will be consistent across all EPM applications.
- Select "Equals" for the condition type.
- In the “Enter Session Variable value” field, paste the FQID value that
you copied earlier.
- Click on Done and then Save & Exit the
configuration.
Full Image of the condition is displayed below in the screenshot.
To decide between "Display in Help Panel" and "Display in Autoload" based on the guide type, follow these criteria:
- Display in Autoload: Choose this option if the guide is a
standalone guide with only one tip. This will automatically show the
guide without requiring the user to open it manually.
- Display in Help Panel: Choose this option if the guide is a
sticky guide with more than one step. This will place the guide in the
help panel, allowing users to access it as needed.
- So, your choice depends on the number of steps in the guide.
- One step: Display in Autoload
- Multiple steps: Display in Help Panel
- Display in Autoload: Choose this option if the guide is a
standalone guide with only one tip. This will automatically show the
guide without requiring the user to open it manually.
- Refresh the application.
- Check the Help Panel to see if the guide is available on the
targeted page.
- To confirm that the guide is restricted to the specific page, navigate to a
different page within the application.
- Verify that the guide is not available on the other pages.
- By following these steps, you ensure that the guide is only accessible on the intended page.
How to Configure JD Edwards Roles to OGL Content
Oracle Guided Learning allows you to configure role-based access to ensure that users only see the content relevant to their roles. This helps develop Guided Learning content tailored to each user role. This content should be specific to the tasks and processes that each role needs to perform. To achieve user role segmentation in Oracle Guided Learning (OGL) for JD Edwards, you need to follow a series of steps to define the different user roles that will have access to the appropriate guided learning content. Here’s a high-level overview of the process.
- Fetch your list of JD Edwards Application Roles to be used for OGL
content.
In Oracle JD Edwards Application, from the Home Page Navigate to User Profiles as below.
Fastpath to Task GH0092 ->User Management->User Profiles
Select Roles Only option and click on Find button in the User Profiles. On the Grid click on Go to end to list all roles.
OGL Administrators may add applicable JDE roles as OGL values to their OGL application and create mapping list to achieve OGL role segmentation.
To have these roles in Excel file or CSV we can use Export feature


- Create mapping list for JDE Roles with OGL Roles.
OGL roles for JDE should be set up as per the roles set in Oracle JD Edwards Application. Navigate to OGL settings/OGL values.
- Go to the OGL console.
- On the Main Navigation Menu, select Settings > Application > OGL Values.

Table 6-1 OGL Values
Legend Name Comments 1 Search Box Provides dynamic search functionality. 2 New Item button Adds a new empty line to the list. 3 OGL Role Name field In the OGL Role Name field, enter the Role Name.
(This is the Role name for your role and will be displayed in the item activation condition.)
Note:
The name field cannot be empty, and duplicate values and special characters are not allowed.
4 OGL Value field In the OGL Value field, enter the Role Value.
(This is the value of the role as defined in your Oracle JD Edwards Application
Note:
The value field cannot be empty; duplicate values and special characters are not allowed(i.e., whitespace).
These values are role names in Oracle JD Edwards application, Corresponding OGL Role will be used in OGL Activation rules to display OGL Guides in OGL Widget.
For example:
If Oracle JD Edwards user has two roles namely SYS_Admin and SYS_UserOGL should have corresponding roles as belowOGL Role OGL Value AdminRole SYS Admin UserRole SYS User In this case names “AdminRole” and “UserRole” can be used in Activation rules for OGL to display OGL Guides in Widget
5 Cancel Discards any changes that were made and closes the interface.
6 Save Saves the changes made to the field. The button only becomes active when an acceptable value is entered in the field.
- Pass the OGL value into Activation condition.
Simple Condition Activation settings
- Locate the activation settings where you need to configure
conditions.
Click on Activation to enter the configuration page.
- Select Type as Simple Condition.
Choose Simple Condition from the available options from the dropdown.
- Add a New Condition.
Click on the (+) button to add a new condition.

- Create Condition.
Select Create Condition Type and choose Role from the dropdown.
- Configure the Condition.
Set the Connector to (is) or (is Not). This typically means you are defining a condition where a role must be included in a specified set.
- Select the Role.
Choose the Role you want to add from the dropdown.
- Enable the checkbox.
Enable the Display in the Help Panel or Autoload checkboxes as needed.
- Save & Exit.
Click on Save & Exit to close the configuration.
- Locate the activation settings where you need to configure
conditions.
- Locate the activation settings where you need to configure conditions.
Click on Activation to enter the configuration page.
- Select Type as Advanced Condition.
Choose Advance Condition from the available options from the dropdown.
- Add a New Condition.
Click on the (+) button to add a new condition.
- Create Condition.
Select Create Condition Type and choose User from the dropdown.
- Configure the Condition.
Set the Connector to (has) or (has not). This typically means you are defining a condition where a condition must be included in a specified set.
- Select the Field subtype.
- Select the user_role under Name dropdown.
- Select the ‘Equals’ under operator dropdown.
- Enter the operand value enclosed with square brackets if you have multiple roles use
Pipeline which works has OR condition.
- Enable the checkbox.
Enable the Display in the Help Panel or Autoload checkbox as needed.
- Save & Exit.
Click on Save & Exit to close the configuration.
Before rolling out the segmented content to all users, conduct thorough testing to ensure that the role-based segmentation is working as expected. Have users from different roles log in and verify that they can only access the content intended for their role. After deployment, continuously monitor user feedback and usage analytics to ensure that the role-based segmentation is effective. Make adjustments as necessary to improve the user experience.
For more detailed instructions and best practices, refer to the official Oracle Guided Learning documentation or contact Oracle support for personalized assistance.