Navigation Model Guidelines Print this Page
Return to Top

The Oracle Fusion Navigation model provides user navigation through a system and represents the organizational model of the system using components in the user interface (UI). The following diagram illustrates the primary components in the UI Shell that make up the model. Other navigation elements, such as Tasks and Related Object panes, worklist items, and local area toolbars are addressed in detailed design.

Figure 1. The navigation heirarchy of the UI Shell, from the main Navigator menu to the transaction dashboard and down to the work areas

This section covers the Navigation model, specifically the main Navigator menu and identification of work areas and dashboards that populate the Navigator (also know as the main menu).

Design Goals

The Navigation model design goals of Oracle Fusion applications:

  • Present a consistent navigation model to users across the system.
  • Match the user's conceptual model. Base navigation on users tasks and the objects they work on.
  • Minimize navigation items and levels. As user studies show, it is more important that users feel confident on their path than it is to reduce the levels in the path. Basing the navigation on key user objects helps with both minimal levels and user confidence of the path.
  • Support multiple ways of navigating. We know that different users have different ways of thinking about navigation, so we must plan to support these various methods. At the same time, we want to reduce confusing and unplanned redundancy where the users don’t know which way to go. Each navigation entry should be distinct with an obvious orientation (for example, task versus user object).
  • Locate related tasks and information. Consider how best to support the tasks so that users can be focused, productive, and efficient in completing them. This organization includes avoiding making the user navigate away from a task to get the needed information to complete it.
Defining the Navigation Model from Task Decomposition
Return to Top

The following diagram illustrates how what you collect during the decomposition process is used in the Navigation model and UI Shell.

decomp to model
Figure 2. Once the users' tasks, subtasks, and objects have been analysed and broken down using the task decomposition process, that data will determine the required dashboards and work areas that ultimately drive the hierachy of the main Navigator menu.
Identifying Work Areas
Return to Top

Based on the decomposition analysis of your users' tasks and objects, you can determine which dashboards and work areas you'll need. All Oracle Fusion content will be contained in or accessed from a work area or a dashboard.

What Are Work Areas?
Work areas are where most users perform most of their work to accomplish necessary tasks. Work areas provide all the tools and related user objects needed to perform tasks without requiring users to navigate away. In this way, work areas enable users to continue working without having to go through inefficient search and results patterns that interrupt or delay their work.

How Do I Identify Work Areas?
Work areas are groups of activities and tasks centered around a business goal (and associated activities and user objects). A user object is what the user is working on when completing his or her tasks. For example, if a user needs to pay an invoice, Invoice is the user object. See examples that follow.

Centering a work area around a user object, such as an invoice or customer, naturally groups tasks functionally and conceptually.  When determining how to group tasks within work areas, consider how best to support the tasks so that users can be focused, productive, and efficient in completing these tasks. Also remember that a work area is optimized for a user role, but it may be used by other roles.

Large user objects, such as customer or invoice, are typically the focus of many different business goals. In any case, you must focus the work areas on the business goals in order to group or separate the tasks and activities into appropriately sized work areas with manageable cognitive loads.

For more information about work areas, see the Introduction to Work Areas Guideline.

Identifying Transaction Dashboards
Return to Top

There are three kinds of dashboards:

  1. Home dashboard
  2. Transaction dashboards
  3. BI dashboards
During the Navigation Model process, you will need to identify only Transaction dashboards. 

What Is a Transaction Dashboard?
Transaction dashboards are core to the business process. These dashboards provide centralized, role-based launching pads into key tasks, as well as a way to monitor the status of the underlying transactions, per business domain (sales, finance, customer relationship management, projects, supply chain, manufacturing, and so on), corporate function (employee, manager, executive, and so on), or user object (appraisals, learning, expenses). The dashboards offer users quick navigation to a work area when appropriate, or they can support lightweight actions (like approve) directly and in context.

When Should I Include a Transaction Dashboard?
Transaction dashboards are needed when a user role needs to monitor access or act upon information across related activities and user objects in a particular domain.

For more information about dashboard types, see the Dashboards Guideline.

Structuring the Navigator
Return to Top

Once you have identified the work areas and dashboards in your product, you are ready to create your Navigator structure. To create your Navigator structure, you create a descriptive heading and list the work areas and dashboards that you have identified under it.  The heading varies depending on how your product is structured. You may structure your work areas in one of two ways, each of which should represent a major business goal:

  • Multiple user objects with associated activities
  • One user object with multiple work areas

The following illustrations highlight each approach.

Multiple User Objects and Associated Activities
Return to Top

If your product is centered around multiple user objects with associated activities, then the heading will be a User Object Group heading that describes the objects under it.  Sometimes this user object group heading will link to a dashboard, depending on the results of your analysis in identifying transaction dashboards.

user object group
Figure 3. Organizing your main Navigator menu based upon multiple user object groupings

Multiple User Objects and Associated Activities Example

When you label your user objects, ensure that you have used simple noun forms as shown in the following illustration. The use of the terms "work area" and "dashboard" are not included. The following menu items are listed for an employee (worker) role.

user object group example
Figure 4. A list of menu items generated using the concept of the multiple user object groupings and their associated activities
User Object with Multiple Work Areas
Return to Top

If you have business goals supported by your product that are centered on a single large user object, then your work areas will be broken into business goals, represented as activities. Your heading will also likely be the name of that user object. Sometimes this user object heading will also link to a dashboard, depending on the results of your analysis in identifying transaction dashboards.

user object activity
Figure 5. Organizing your main Navigator menu based upon a user's object with multiple work areas
Consolidated Menu
Return to Top

A full outline of the menu for a fixed asset manager is depicted in the following table. In this case, the fxed asset manager is also a line manager. As indicated in the previous figures, you may have secondary levels within your product. You must determine your user object and task hierarchy in order to know what levels to include. Also notice that there is a Tools section in the Navigator. Do not duplicate these tools as work areas under your group headings. In general, do not cr eate tool-based work areas. Instead, arrange the tools around the activities and user objects that are used to accomplish the business goal.

Fixed Assets                 

Employee Resources

Manager Resources





Analysis and Reporting


   Absences & Vacation



Financial Adjustments



Process Monitoring




Setup and Maintenance







Expenses and Requisitions








   Charge Cards







   My Compensation





   Job Requisitions







Expenses and Requisitions








   Charge Cards




   Purchase Requisitions




Time Reporting

Time and Labor




   Absences and Vacation




   Time Reporting


The following figure displays the same menu that would appear for users. However, this figure is a rendering for illustrative purposes only; the actual menu may be different.

main menu
Figure 6. Full outline of the Fixed Assets Manager menu as listed in the previous table

Here is a rendering of a Navigator menu with tertiary level links appearing in a submenu.

fixed asset manager with fly-out menu
Figure 7. Tertiary menu item links available from one of the a secondary menus when selected by the user
Creating the Navigation Model Schematic
Return to Top

The Navigation Model Schematic enables you and the gatekeepers to understand in an immediately visible way the high-level navigation as it occurs for any given role.

You will use the information that you have compiled in the decomposition spreadsheet, including roles, tasks, and work area mappings, to create one schematic for each role supported by each product. The schematic is not a detailed wireframe design--it is only a representation of how the high-level navigation works.

The Navigation Model Schematic depicts:

  • Navigator structure and content for a role
  • Transaction dashboards
  • Work areas with associated tasks and roles

Here is an example Navigation Model Schematic.

Figure 8. Example of a high-level role based Navigational Model schematic
About Oracle | Legal Notices | Terms of Use | Your Privacy Rights