This chapter contains the following:

Overview of Application Configuration and Extension

By default, the application provides robust functionality, tailored to support most of the business requirements an organization could have. But you can still make changes to your application to best fit your specific business or personal needs.

Types of Changes

The types of change you can make depend on whether you're an administrator or a user, the pages you're changing, and who you're making the changes for.

  • Configuration: These changes are made by administrators, and such changes affect many users. For example, you might hide some menu items in the Navigator, or create a new page for all users.

  • Application Extension: These changes are made by one or more application developers and administrators using Visual Builder Studio, and such changes affect all users. For example, you may want to add a new field to a table, or rearrange the fields in a form. There's one application extension for each base application, which many people contribute to.

  • Personalization: These changes are made by individual users, and they affect only the users who made the changes. As an administrator, you can't make personalizations for any specific user. Personalizations are also limited to certain types of changes, such as hiding infolets or resizing table columns.

Note: Configurations, application extensions, and personalizations are preserved when you move on to a newer release update.

Here's a visual representation of how changes are categorized.

 Diagram of a flowchart that categorizes application
changes into personalizations, configurations, and application extensions
based one how many people the changes affect.

What You Can Change

When you make a change to the data model, that change is available to other aspects of the application. For example, after you add an attribute to an object, you can use that attribute in these related artifacts:

  • Web-based view page

  • Associated mobile page

  • Associated reports

Generally, you use Application Composer to change the data model. You can then reflect those changes in the UI by using Visual Builder Studio, Page Composer, or Application Composer. If you see the Edit Pages in Visual Builder option in the Settings and Actions menu of a page, you know that you must use Visual Builder Studio to edit that page.

For information about configuring business intelligence, see the Creating and Editing Analytics and Reports guides relevant to your products.

Examples of Configurations and Extensions, and the Tools to Use

You can configure and extend the application using browser-based composers and other tools. Some configuration tools, such as Application Composer and Visual Builder Studio, are available only for specific product families. Let's look at some of the key things you can do with these tools. Not all tasks are listed here.

Modify the UI

Use these tools and work areas to modify the UI:

  • Page Composer: Configure application page components, such as page content, layout, and more for other users.

  • Visual Builder Studio: Extend application page components for certain applications.

  • Application Composer: Create fields, objects, and relationships between objects.

  • User Interface Text: Edit text that appears on multiple pages.

  • Appearance: Change the look and feel of the application pages.

  • Page Template Composer: Edit global page template.

  • Structure: Configure the Navigator and the icons on the home page for navigation.

  • Announcement: Create, edit, and delete announcements displayed on the home page.

Here are some changes that you can make to pages, and the corresponding tools or work areas to use. You can modify certain pages only in either Page Composer or Visual Builder Studio.

Task Tool or Work Area

Add, move, delete, show, or hide components on a page, including fields

Page Composer or Visual Builder Studio

Add validation to a field

Page Composer

Add external content

Page Composer

Change a page layout

Page Composer or Visual Builder Studio

Add business logic to display certain layouts

Visual Builder Studio

Manage saved searches

Page Composer

Modify dialog box content

Page Composer or Visual Builder Studio

Modify attributes for a flexfield on a page

Page Composer

Change properties for UI components on a standard page

Page Composer or Visual Builder Studio

Edit variables, constants, and events as needed

Visual Builder Studio

Configure the UI Shell template

Page Template Composer

Update a UI text across all pages, such as to change "buyer" to "customer" on all pages where the term "buyer" is used

User Interface Text

Change the look and feel of application pages


Tip: In Page Composer, you can make changes using the WYSIWYG view. However, in some cases, you can also use the Source view.

Update the Branding

This table shows examples of where you can change the branding to your own logo, and the corresponding tools or work areas to use.

Task Tool

Change the logo in the global header


Change the logo that appears in report output

Layout editor in the BI application or external applications, such as Microsoft Word

Configure the Navigator and Icons on the Home Page for Navigation

Use the Navigation Configuration page in the Structure work area to configure the Navigator and the work area icons or Apps section on the home page. For example, you can show or hide certain items and reorganize what's there. You can also add a business object to the Navigator.

Configure the Home Page

Here are some things you can change on the home page, and the work area you use to make those changes.

Task Work Area

Change the layout of the home page


Configure the icons for infolet pages in the page control on the home page. You can rename these icons, change their visibility settings, and reorder them.

Home Configuration page in the Structure work area

Create, edit, and delete announcements on the home page.


Add Attributes to Business Objects

You can use flexfield tasks in the Setup and Maintenance work area to add user-defined attributes to most business objects, except for those in Oracle CX Sales and Oracle B2B Service products. With flexfields, you create your own attributes without coding. A flexfield captures data for a specific purpose, such as information about job positions or inventory items. Each attribute is a segment of a flexfield, and corresponds to a reserved column in the application database.

For Oracle CX Sales, Oracle B2B Service, and other products, you can use Application Composer to add attributes to business objects or create custom objects so that you can track and store any additional data you might need. For example, you can add new attributes (also referred to as custom fields) to an existing object, or create entirely new custom objects. There's no fixed limit on the number of custom objects that you can create. After you create an object, you can also edit its attributes.

Tip: You use the custom object's security node in Application Composer to secure custom object data.

Modify Reports and Analytics

Predefined analyses, dashboards, and reports help you meet business intelligence (BI) requirements. But you can still modify the reports and analytics to fit specific business needs. You start in the Reports and Analytics work area, and go from there to do more in the BI application. Let's see some examples of the changes you can make, and the corresponding tools or work areas to use.

Task Tool or Work Area

Create an analysis

Reports and Analytics work area or the BI application

Create or change report layout

Layout editor in the BI application or external applications, such as Microsoft Word

Add more pages, or tabs, to dashboards

The BI application

For more information, see the Creating and Administering Analytics and Reports guides relevant to your products.

Manage Help Content

Many pages have help icons that you click to open help windows. Here, you can add your own content, such as your company policies or best practices. You can also find help on some UI elements, such as hints that appear when you click in a field.

This table shows a few examples of changes that you can make to help, and the corresponding tools to use.

Task Tool or Work Area

Add help that users can see in help windows

Help windows

View and edit all of the help that anyone added to help windows

Manage Help Content task in the Setup and Maintenance work area

Modify text that's displayed when the user hovers over UI elements, such as a button, link, icon, or tab title

Page Composer

Simultaneously replace multiple occurrences of a word or phrase that appears in the help for UI elements

User Interface Text

Note: You must have the appropriate job roles to add and edit help.


Personalization refers to the changes that every user of the application can make to certain artifacts in the UI. These changes apply only to the user who made them. They remain every time the user signs out of the application and signs back in.

Here are some examples of personalizations, specific to a user:

  • How they use the UI, such as changes to the column width of a table

  • What they want to save, such as search parameters

  • What they want to see, such as the work area icons to show or hide on the home page

Context Layers

Overview of Context Layers

You can use context layers to control which specific set of users your application changes apply to. All you need to do is make sure that you use a context layer to make application changes and your sandbox is set to the correct context layer. A sandbox is a testing environment that sets apart untested changes from the mainline environment so that these changes don't affect the mainline metadata or other users in the environment. If you're using the Unified Sandboxes feature, which you get by default, you set the context layer when you create your sandbox. If you have opted out of this feature and are using classic sandboxes, you may get the option to select a context layer while using a configuration tool to make application changes. If a tool doesn't give you the option to set a context layer, then your changes are made to the Site layer, which applies to all users.

Note: Changes made using the User Interface Text tool are made in all layers, and not just the Site layer.

Available Layers

Different product families have different context layers. But, every application has these layers:

  • Site: Changes made in this layer affect all users of the application.

  • User: Changes made in this layer affect just one specific user. But, you can't use this layer to make changes for other users. Personalizations are stored in this layer, and users can make personalizations only for themselves.

Here are the layers you can use when you configure different product families:

  • Customer Relationship Management

    • Site

    • External or Internal

    • Job Role

  • Human Capital Management

    • Site

    • Country

    • Organization

    • Time Card Layout

  • Default Layer

    • Site

How Layers Work

Layers are applied in a specific order.

  1. User

  2. External or Internal

  3. Job Role

  4. Site

You won't see changes that were set at a layer that's higher in the hierarchy. The higher the level, the more specific its context is. Layers at higher levels exist within the scope of the layers below them. This means that when a value is set for a context layer, it's set within the scope of the context value for the layers below it.

You can have multiple configurations for an object or a page at the same time, but this is possible only when either of these conditions are met:

  • Configurations are in different layers

  • Configurations are in the same layer, but the layers have different context values

When a user opens an object or a page, the configurations at the highest layer applicable to an object or a page are given precedence. Let's say you added three columns to a table and then configured these columns for each context layer in this way:

  1. At the Site layer, you added three columns to the Sales table, namely, Promotion Name, Sales Points, and Partner Name.

  2. For the external developer, the Sales Points column is hidden.

  3. For the internal sales role, the Sales Points column isn't hidden.

Liam, who's an internal sales representative, personalizes this page for himself and hides the Sales Points column.

This is how different users see the column:

User Sees Sales Points Column?

Internal sales role


External developer


External recruiter




Here's a visual representation of these configurations in different context layers and values.

Image showing the configurations in different context

Examples of How the Appropriate Configurations and Personalizations are Applied

Here are a couple of scenarios that show you what happens behind the scenes with context layers so that the appropriate configurations and personalizations are available to the appropriate users.

An Administrator Configures a Page for Sales Representatives

Let's say you're an administrator who wants to remove the Export button from the home page, but you want to remove it only for sales representatives. You select the Job Role context layer with the value Sales Representative, and then remove the button.

This is what happens after you make this change:

  1. The configuration engine in Oracle Metadata Services generates an XML file and then stores it in the Oracle Metadata Services repository. So the original file for the page remains untouched.

  2. When a sales representative opens the home page, the configuration engine checks the repository for XML files that satisfy these two conditions:

    • Does the file match the requested artifact, in this case, the home page?

    • Does the file match the active context, in this case, the Sales Representative job role?

  3. The configuration engine also looks for any XML files with personalizations that this specific sales representative made. But for now, let's assume our sales representative hasn't personalized anything.

  4. After the configuration engine finds an XML file that satisfies both conditions, that XML file is then layered over the base artifact, the original Sales page. In this scenario, the XML file removes the Export button from your sales representative's page.

Here's an image that shows you how this configuration is done.

The figure shows how an administrator can configure
the home page for a sales representative.

A Recruiter Personalizes a Page

Let's say you added three new work area icons A, B, and C to the home page. You added icons A and B at the Site layer for all users and icon C at the Job Role layer just for recruiters. But Liam, who's a recruiter, doesn't use icon B all that much. He can personalize his home page to show only icons A and C. When Liam does this, an XML file is generated for Liam's user layer with this change.

The next time Liam opens his home page, the configuration engine retrieves three XML files:

  • The file for the changes you made at the Site layer

  • The file for the changes you made at the Job Role layer

  • The file for the personalization Liam made

The file for the context with the lowest layer (Site) is applied first, and the file for the context with the highest layer (User) is applied last. In this scenario, this is what happens when each file is applied.

  • The Site layer adds icons A and B to the home page for everyone.

  • The Job Role layer adds icon C.

  • The User layer removes B from the home page because Liam chose to hide it.

When a different recruiter opens the home page, only the XML files for the Site and Job Role layers are applied. This user sees icons A, B, and C.

Here are two diagrams that show you how this personalization flow works. In the first image, you, the administrator, add icons A and B to the home page at the Site layer and icon C at the Job Role layer for recruiters. The image also shows Liam hiding B.

This figure shows how an administrator adds page
entries at different layers for recruiters.

The next image shows what happens when Liam and another recruiter open the home page.

This figure shows how different recruiters access
the same home page after the administrator configured it.

Example of Including Higher Context Layers While You Configure

When you select a context layer, you can also include higher layers to see the application changes from those layers while you configure in your selected layer. Here's an example that explains what happens using the Site, Country, and Organization layers.

What You See While Making Application Changes

Suppose this is what you do when you select context layers:

  • Select the Organization layer for configuration and select VMI Manufacturing as the value for that layer

  • Include the Country layer and select France as the value

Note: The Site layer is automatically included because it applies to everyone.

While you modify pages in Page Composer and make changes for VMI Manufacturing, you also see changes that apply specifically to VMI Manufacturing in France, based on these factors:

  • What was defined for each layer

  • Which is the highest layer with application changes for a specific artifact

Let's say you have a field that's hidden in the Site layer, but displayed in the Country layer for France. While modifying pages, you can't see the hidden field because Country is higher than Site.

What Your Application Changes Apply to

No matter what you see while making application changes, your changes apply only to the selected layer, that is, Organization. You now choose to hide the field, and that change applies only to the Organization layer for VMI Manufacturing.

Here's what users see after you make your change:

  • VMI Manufacturing in France still can't see the field because Country is higher than Organization.

  • Users with other job roles in France can see the field because the Country layer is not within the scope of the Organization layer, in this case, VMI Manufacturing.

  • VMI Manufacturing in any other country can see the field because Organization is lower than Country.

Business Process Models

The application is based on business process models that map out business flows. When you configure and extend your application, for example to add new pages, you can use these models to help you plan. For diagrams of business process models, see Oracle Fusion Business Process Models (1542019.1) on My Oracle Support at https://support.oracle.com.

How the Business Flows are Organized

The business flows are presented in a five-level hierarchy: industry (L0), business process area (L1), business process (L2), activity (L3), and tasks (L4).

  • The hierarchy goes from high-level concepts to specifics in the application.

  • L1 through L3 are business-driven and don't depend on any specific implementation in the application.

  • L4 aligns with specific features and functionality in the application.

How the Models Affect the Application

The application is organized around these hierarchy levels and flows, which focus on the activities and tasks that users do. Many aspects of the application are influenced by, if not directly based on, the business process modeling levels. For example, the levels affect the navigation, user interface, and parts of security.