• Dynamic tabs use the Level 2 tab bar located in the application's primary layer. Tab text is not truncated. Tab component overflow is handled by overflow icons.
• In the dynamic tabs model, all pages must appear inside a tab.

Consider the following:

• Deselecting a tab by selecting or opening another tab does not trigger validation on the unselected tab.
  For more information on validation, see the Save Model Guidelines.
• Direct user interaction on a selected tab is the only way to update tab content.
  • Data changes made by other users or background processes do not automatically update tab content.
  • Changes made in one tab do not automatically update content in other tabs. Users must manually update affected tabs to see changes in data.
• Users do not have to save changes in a current tab before selecting or opening another tab.
  • On each dynamic tab, data changes are cached until users initiate an explicit save or submit action.
• When users try to navigate away from a work area in which there are unsaved changes, the system must launch the Unsaved Changes Warning dialog box.
  • For more information on validation, see the Save Model Guidelines.
• Returning an unselected tab to a selected state does not trigger an automatic refresh of the tab's data.

• Are always open and cannot be closed
• Appear in a fixed position at the start of the tab bar
• Are employed for the Work Area Entry tab

Dynamic tabs:

• Are opened and closed by way of direct user interaction
• Appear after the static tab on the tab bar
• Are employed for the following tabs:
  • Manage
  • Detail
  • Compare

New tabs always open to the right of existing tabs.

Figure 2.1. New dynamic tabs open after existing tabs

• Users can close a dynamic tab only when it is in a selected state. Users cannot close a dynamic tab when it is not selected.
• A tab closes after users select a final page-level action.
  • If users select a final page-level action on a page to which they have navigated inside a Detail tab, selecting that final action ultimately navigates them back to the root page in that tab. For more information, see the Drill-Down Navigation section of this guideline and the Page Actions Guideline.
• Users can close dynamic tabs by clicking the Close icon button on a selected tab.
  • Users cannot close the Work Area Entry tab or other static tab types.
• Only dynamic tab types should have a Close icon button.
• To be consistent with the Save Model Guidelines, the Unsaved Changes warning dialog box appears when applicable.
• Where appropriate, users can close a dynamic tab from a dialog box.

The Dynamic Tabs model employs four tab types to effectively manage the number of open tabs and minimize tab proliferation. The four dynamic tab types are:

1. Work Area Entry tab
2. Manage tab
3. Detail tab
4. Compare tab

This table compares the tab types employed in the Dynamic Tabs model.

Each dynamic tab work area has a persistent tab that supports the work area entry experience by orienting users to the state of the work. The Work Area Entry tab has the following characteristics:

• The Work Area Entry tab appears in a static tab type that is open and is selected by default when users first navigate to the work area.
• The Work Area Entry tab appears in a fixed position at the beginning of the tab bar.
• The Work Area Entry tab cannot be closed.

An Overview tab is recommended for the Work Area Entry tab because it provides status and summary information across all objects in the work area. The tab text and page header for this tab read "Overview."

• If the work area does not contain business intelligence, a Worklist, or analytics, such as a static Manage tab, can be employed instead of the Overview tab. 
  • Using a static Manage tab is considered a less desirable entry experience because, unlike the Overview tab that delivers tasks and information to the user, a Manage tab requires users to search.
  • The tab name should be "Manage <Object Type> or <Business Process>" (for example, "Manage Intrastat Transactions").
  • If "Manage <Object Type>" is employed as the Work Area Entry tab, the corresponding task name should not appear in the Tasks pane.
    

In rare cases, you can also possibly employ more than one static tab in a dynamic tabs work area. Work with your pillar user experience team to determine whether multiple static tabs are appropriate for your flow. If you use multiple static tabs, ensure that these conditions are met:

• No more than three static tabs can appear in a dynamic tabs work area.
• The Work Area Entry tab always appears first in the tab bar, and the Work Area Entry tab is selected by default when users first accesses a work area.
• If you use other static tabs, these tabs should appear after the Work Area Entry tab.
• The dynamic tabs should always appear after the static tabs.

For more information, see:

• The Work Area Entry Page Guidelines
• The Work Area Overview Page Content Display Guidelines

• If a work area has multiple objects, each object has its own Manage tab.
• A work area has no more than one Manage tab for each object type.
• The Manage tab is typically a dynamic tab unless it is employed as the Work Area Entry tab (instead of an Overview tab).
• Users cannot navigate inside of this tab type.

Figure 3.1. In a work area, each object type will have its own Manage tab

Some task flows begin with transactional search. In flows such as this, a subflow may open a dialog box or open in a new tab. You cannot drill down within a Manage tab.

• A dialog box opens.
• A new tab opens or an open tab is selected.

When opening a new tab, Tasks pane links and regional area searches interact with Manage tabs in similar ways, but they vary in their interactions with Manage tabs that are already open. Table 3.2 highlights these interactions.

Users can open Manage tabs from the Tasks and Search panes in the regional area:

Figure 3.2. Each object type in a work area has its own Manage tab

When a Manage tab is already open, clicking its corresponding link in the Tasks pane selects that tab. Here is a diagram that illustrates this Tasks pane interaction.

Figure 3.3. No more than one Manage tab opens for an object type in a Dynamic Tabs work area

• Object type: A type of entity (for example, an item is a common object type in Oracle Supply Chain Management).
  
• Object: An object is a specific instance of that object type (for example, Item WM100).
  
• State: A state is one of the possible conditions in which an object may exist.
  • Common examples in Oracle Fusion include read-only and editable states such as Item: WM100 (read-only) and Edit Item: WM100.

Detail tabs are used for the following actions:

• Create
• Edit
• View
• Others

Detail tabs include the following characteristics:

• The Detail tab type is the only tab type inside of which users can navigate.
  
  
• Different states of the same object may appear simultaneously in separate tabs.
  • Conversely, a specific state of an object may appear in no more than one tab at a time.
    • For example, only one tab can display Edit Shipment: 595. If, on the Manage Shipments tab, users highlight Shipment 595 and click Edit, the corresponding unselected tab is selected. A duplicate of this object state does not open in a new tab.
    • This behavior may not be consistent when record navigation is employed inside a Detail tab.
      
      
  • Tab text displays the object type and object name but, unlike the page header, does not include the action name (see Table 3, the Naming Guide in this document). The page header is governed by the Header Syntax section of the Headers Usage Guideline. Here are examples of two tabs, each of which contains a different state of the same object:
    
    • Tab text: Shipment: 123; page header: Edit Shipment: 123
      
    • Tab text: Shipment: 123; page header: Shipment: 123 (read only) 
      
      
• If users have open tabs that represent different states of the same object, changes made in one tab do not automatically update data in other related tabs. Users must manually refresh a related tab to update its data.
  
  • For example, changes made on the Edit Item: WM100 tab will not cause content to automatically refresh on the read-only Item: WM100 tab.
     
• For information about tab closure, see the Closing a Dynamic Tab section of this document.
  

Figure 3.4 shows an example of two tabs that represent edit and view states of the same object. Note that page headers should follow the Header Syntax section of the Headers Usage Guideline.

Figure 3.4. Examples of two tabs that represent edit and view states of the same object

Here is a naming guide table for tab text and page headers inside Detail tabs.

Tasks pane links and regional area searches open new Detail tabs in similar ways. However, with the exception of the Create action, interactions differ when a Detail tab is already open. Table 4 shows a comparison of these interactions.

The following characteristics apply to Detail tabs:

• Multiple tabs that represent the same object can open only for unique states of that object.
• A Detail tab (other than for Create) should not be duplicated. For example, two unique Create Shipment tabs can be open at the same time, but two tabs for Edit Shipment: 123 cannot.
• If an object state that already appears in an open Detail tab is called again, the open Detail tab is selected without its content automatically updating.

Note: Follow these implementation guidelines to prevent the duplication of a Detail tab:

• When opening an object state in a dynamic tabs work area, set the property called reuseInstance to True. When a flow is already open in an existing tab, clicking a link to open the same object state selects that tab but does not refresh its data.
• If the reuseInstance value is incorrectly set to False, a duplicate dynamic tab containing that object state (for example, Edit Shipment: 123) opens.

When users navigate from within a Detail tab, the subflow may open in a dialog box or, in the case of an open Detail tab, the contents can update by way of navigation within that tab. Two types of tab navigation are available within a Detail tab:

• Drill-down navigation: For more information, see the Record Navigation: Drill Down Details design pattern.
• Record navigation: For more information about navigation across parallel or peer records, see the Record Navigation: Page Details design pattern.

Based on the Record Navigation Drill Down Details Design Pattern, drill-down navigation drills down into and up out of a Detail tab. Drilling down inside a Detail tab results in the following:

1. Tab text: Remains unchanged.
   
2. Page header: Updates to reflect changes in navigation and resulting tab content.
   
3. Navigation path: For every level of drill down, the navigation path is retraced in reverse when users select each level's final page-level action. The final step is tab closure by way of a page-level action.
   • If the user drills down from a read-only state to an editable state, clicking a final action on the editable state closes the tab. Users do not return to the read-only state before the tab closes. For more information, see the Page Edit design pattern.
4. For more information about final page actions, see the Page Actions Guidelines.

In drill-down navigation, the tab text remains the same while the page header updates to reflect the task or subobject to which users have navigated. Here is an example of this flow type.

Figure 3.5. Initiating a drill-down action from within a Detail tab

The record navigation model applies to navigation among peer objects inside a Detail tab. This model occurs most often as a result of the following:

• Navigation by way of the record navigation component (see figure 3.6). For more information, see:
  • The Record Navigation: Page Details design pattern
  • The Page Actions Guidelines
  • The Single Task Guided Process design pattern set
• Creating an object. Create tab actions include:
  • Save and Create Another. For more information, see the Page Actions Guidelines and the Save Model Guidelines.
  • Save. See the Save Model Guidelines for a description of this interaction.

Here are common types of record navigation that can be employed inside Detail tabs.

Figure 3.6. Examples of linear and nonlinear record navigation used only within Detail tabs

Record navigation within a Detail tab yields the following changes:

1. Tab text: If not embedded inside a drill-down flow (see figure 3.5), tab text updates to reflect changes in tab content.
2. Page header: The page header updates based on navigation and reflects changes in tab content.
3. Navigation path: The path differs from the drill-down model in that tab content does not retrace its navigation path to the point of origin.

In the record navigation model, Detail tab text and page headers update as users navigate across peer objects.

Figure 3.7. Representation of the Record Navigation model

• The tab text is "Compare" (the tab text does not include the object type).
• For the page header, see the Compare Objects design pattern set.

Here is an example of tab text and page header naming on a Compare tab. Figure 3.8. Tab text and page header naming on Compare tabs

• Page Actions Guideline
• Save Model Guideline
• Introduction to Work Areas
• Work Area Entry Page Guidelines
• Work Area Overview Page Content Display Guidelines
• Compare Objects design pattern
• Transactional Search/Results: Search Results design pattern set
• Warning Message design pattern