• Overview
• Personalization Methods
• Recommendations

Personalization refers to the set of features that enable end users to change the Oracle Fusion Applications user interface (UI) to fit their needs when working. Users can make changes that are as simple as the collapsed or expanded state of a region or as elaborate as creating a saved search or adding content to a dashboard using the Oracle Composer. Personalizations can persist within the current sign in session or across sign in sessions.

Users can personalize the UI in three different ways:

1. Implicit runtime personalizations: through direct manipulation and affordances built in to the component
2. Explicit runtime personalizations: through secondary personalization, accessed directly from the UI component on the application page
3. Oracle Composer personalizations (edit mode): in a page editor that enables end users to change the default layout and content of selected dashboards and workarea pages

Changes that users make to a given page apply only to that page, unless a changed element is part of a shared taskflow. With shared taskflows, if users change an element on one page, the settings for that element are changed on all other pages where that taskflow appears.

Personalization does not include changes made by an administrators or technical users that apply to multiple users (by role, business unit, locale, and so on). These changes are called administrative customizations.

Personalization differs from preferences. Preferences represent a subset of profile options and typically are settings related to data that apply across the end users' experience of the entire application suite (preferred language, date format, and so on). For more information, see the End User Preferences Guidelines.

Implicit Runtime Personalizations

Implicit personalizations refer to changes made at runtime through direct manipulation and through affordances built into the component.

You can also think of implicit personalizations as state management, that is, remembering the state of the interface as users navigate around the suite of applications. Examples of state management include collapsing or expanding a region, repositioning a splitter, hiding or showing columns in a table through the built-in View table menu, or selecting the weekly view instead of the daily view of a calendar.

The following image shows examples of table column attributes supported by the ADF Change Persistence Framework.

Figure 1. Example of supported implicit personalizations in table columns

The following image shows an example of a calendar component with support for the following views: day, week, month, and list. You can select whether the view persists within the session or across sessions, depending on how you configure it.

Figure 2. The Calendar component

Implicit Personalizations Within a Session and Across Sessions

Implicit personalizations may be persisted within a session< or across sessions, depending on the requirements of the application flow. Within session refers to the duration of a session between login and logout. Across session preserves the state of the supported attributes across sign in and sign out sessions by leveraging Oracle Metadata Services (MDS).

Creating Custom Implicit Personalizations

Beyond the set of automatically supported attributes, you can also create the following implicit personalizations that persist both within and across sessions:

• Changing an attribute value
• Adding or removing a facet
• Adding or removing a child component
• Reordering child components
• Moving a child component to a different parent

Note: If you want to create these types of user customizations, you must add code that calls the application programming interfaces (APIs) to maintain the persistence.

Explicit Runtime Personalizations

This method is used when an additional UI is required to specify run-time personalization settings for a component or region. These types of personalizations are typically presented in a dialog box and must be persisted across sessions (through MDS) due to the explicit nature of the action.

The following image shows the interface that you use to create saved searches when this personalization functionality is native to the query component and does not require additional coding.

Figure 3. Example of the UI used for personalizing saved searches

The following image shows an example of additional settings for a calendar. The UI needed to specify these calendar settings is provided in a dialog box that must be coded by development and is persisted across sessions by leveraging MDS.

Figure 4. The Personalization dialog box for a calendar component

Oracle Composer Personalizations

Oracle Composer is the page-editing tool that enables end users and administrators to make changes to application windows. Oracle Composer is a design-time-at-runtime page editor. It has a design view and a source view. The design view enables users to both run the application and make some edits to the interface. Edits to the interface are limited to implicit personalizations and the properties of the following Oracle WebCenter framework components:

• panelLayoutCustomizable: Defines a region whose layout you can easily change in Oracle Composer
• panelCustomizable: Defines a region where you can add content from the Composer Resource Catalog
• showDetailFrame: Defines a dialog box that you can be move, resized, hide (if placed inside the panelCustomizable component), and add from the Composer Resource Catalog

The source view includes a navigation tree that lists all of the components that you can use on a page and a WYSIWYG view of the page. Both views enable users to select and edit the properties of any component that has been enabled for customization. The tools available in the source view are reserved for administrative customizations by users with administrative privileges only and are not available for end-user personalizations.

Oracle Composer changes always persist across sessions through MDS. This includes both implicit and explicit personalizations available at runtime outside of Oracle Composer. For example, end users can collapse or expand a region, hide a column, or create a saved search both at runtime and within Oracle Composer. However, changes made within Oracle Composer always persisted across sessions by saving all changes to the MDS End User customization layer.

Types of Pages That You Can Use Oracle Composer to Personalize

You use Oracle Composer primarily to personalize dashboards. A few work areas can also leverage Oracle Composer.

Typical Flow

To personalize a dashboard or work area:

1. Navigate to the dashboard or work area that you want to personalize.
2. Select the Personalize global menu, then the Edit Current Page option.
3. The current page opens in Oracle Composer.
4. Make changes in Oracle Composer.
5. Save.
6. Close and return to the run view of the page.

The Global Personalization Menu

The following image shows the global Personalization menu with the option to edit the current page.

Figure 5. The global Personalization menu

The menu options on the global Personalization menu are:

• Set Preferences
  
  Launches the Preferences UI.
  
  
• Edit Current Page
  
  Opens Oracle Composer. This menu option appears only if the work area or dashboard (JSPX page) is enabled for editing in Oracle JDeveloper.
  
  
• Restore Default Content and Layout
  
  Removes explicit and implicit customizations from the current end user layer. This option is always available because it also removes implicit customizations.

When users select Edit Current Page from the Personalize global menu, Oracle Composer is launched in the context of the running work area or dashboard. This places the application in Edit mode, running in a sandbox that caches any changes that users makes until they click Save or Close from the Oracle Composer toolbar.

Figure 6. The dashboard within Oracle Composer with the Change Layout control open

Figure 7. The dashboard within Oracle Composer with the catalog open

Note: Content in the catalog varies per dashboard. This image shows only a sample.

Automatically Supported Attributes (Implicit Personalizations)

After you consider performance as described in the following table, you should enable implicit personalizations everywhere within a session and selectively across sessions.

Figure 8. Enabling implicit personalizations everywhere within a session and selectively across sessions

You must avoid these two situations:

• Not enabling personalization anywhere across sessions for fear of performance issues
• Enabling across sessions everywhere and ignoring performance considerations

General Recommendations

Follow these guidelines when enabling users to personalize certain page or component elements within Oracle Fusion Applications flows:

• Dashboards
  You can enable dashboards for personalization at runtime (in Run mode) and through Oracle Composer (in Edit mode). As mentioned earlier:
• In Run mode, users can remove and reorder content by dragging that content across a page.
• In Edit mode, users can add content to the page and change the layout. You must seed dashboard regions in the Oracle Composer catalog for each dashboard.
• Dashboard regions
  When needed, you can provide support for dashboard region personalization through the toolbar and controls in the region.
• Work area overview pages and transaction pages
  Work area overview pages should rely on implicit personalizations and on explicit personalizations that do not require the use of Oracle Composer.
• Saved searches
  You can enable personalization in tables that leverage the saved search functionality. Exceptions:
  • Rarely used self-service flows
  • Flows where users do not often repeat searches
    
• Forms
  Avoid adding form personalizations for end users. If you must provide these personalizations, you must provide your own UI (in a secondary dialog box). Do not provide these personalizations through the Oracle Composer property inspector.