1Overview

This chapter contains the following:

Overview of Configuration

Oracle applications by default provide robust functionality, tailored to support most of the business requirement 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

You can make 2 types of changes, based on who's making the change and for whom.

  • Configurations: These are changes made by administrators, and these changes affect many users. For example, you hide a page entry in the springboard for specific job roles, or create a new page for all users.

  • Personalization: These are changes made by individual users, and they affect only the users that made them. For example, you change the column width of a table for yourself.

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

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

An administrator can't make personalizations for any specific user other than themselves. Personalizations are also limited to certain types of changes such as springboard and infolet personalizations, and resizing columns and tables.

Configurations are preserved when the application is updated to a newer release.

What You Can Change

You can configure many aspects of the application, for example the user interface, business intelligence, and data model.

The application is built using a common data model. So, when you make an application change in one area, that change is available to all objects in the application. For example, if you add an attribute to an object, you can easily add that attribute to these related artifacts:

  • Web-based view page

  • Associated mobile page

  • Associated reports

Generally, you use the same tools and processes to configure all applications. For more information on configuring business intelligence, see the Creating and Editing Analytics and Reports guides relevant to your products.

Configurations and Extensions

Examples of Configurations and Extensions

You can make configurations and extensions using browser-based composers and other tools. All users or a subset of users can view and use these configurations and extensions. If your role has an administrative privilege, you can access most configuration tools to modify the user interface (UI), create and modify objects, and so on. Some configuration tools, such as Application Composer, are available only for specific product families.

Modifying the UI

To modify the UI, use:

  • The User Interface Text tool to edit text that appears on multiple pages. For example, you can change the term, "buyer" to "customer" if that is your preferred term, and the change affects all pages where the term is displayed.

  • The Appearance work area to change the look and feel of the application pages.

  • The Announcements work area to create, edit, and delete announcements displayed on the home page.

  • Page Composer to configure application pages for other users. For example, you can:

    • Add fields

    • Add validation

    • Change default content

    • Rearrange regions

    • Add external content

    • Save queries

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

Configuring Navigation

Use the Structure work area to configure the Navigator and springboard. On the Navigator, select Configuration > Structure.

Adding User-Defined Attributes to Business Components Using Flexfields

Most business components, except those in Oracle Engagement Cloud products, support using flexfields to add attributes to objects. Use flexfields to create your own attributes without programming. A flexfield captures data that is related to 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.

Modifying Reports and Analytics

Predefined analyses, dashboards, and reports help in meeting business intelligence requirements. You can modify them to fit specific business needs, for example, change the layout.

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

Managing Help

Use the Manage Help Content page to:

  • Add and edit help files in the application Help

  • Determine which help files to show in specific help windows

You can open the Manage Help Content page from any help window, or from the help site.

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

Tools for Configurations and Extensions

You can configure and extend your application to suit your business needs.

Choose an appropriate tool based on the types of configurations and extensions to make, such as:

  • Page modifications

  • Branding modifications

  • Object modifications

  • Security modifications

  • Business intelligence modifications

  • Help content management

Note: The following tables present only the key tasks for application changes, not all tasks.

Page Modifications

This table shows some types of modifications that you can make to pages, and the corresponding tools to use. You can modify only certain pages in Page Composer.

Modification Task Tool

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

Page Composer

Change a page layout

Page Composer

Create a site-level search for all users

Page Composer

Change a page title

Structure

Modify dialog box content

Page Composer

Modify attributes for a flexfield on a page

Page Composer

Change properties for user interface (UI) components on a standard page

Page Composer

Configure the UI Shell template

Page Composer

Update a text string wherever it appears across all pages

User Interface Text

Change the look and feel of application pages

Appearance page

Change the announcements on the home page

Announcements page

Branding Modifications

This table shows some types of modifications that you can make to use your own branding logo, and the corresponding tools to use.

Modification Task Tool

Configure the UI Shell template

Page Composer

Change the logo and application name in the UI

Appearance page

Change report layouts

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

Object Modifications

This table shows some types of modifications that you can make to objects, and the corresponding tools to use.

Modification Task Tool

Add an attribute to a business object using flexfields (not Oracle Engagement Cloud)

Setup and Maintenance work area

Add a business object page to the Navigator menu

Setup and Maintenance work area

Security Modifications

This table shows a security modification that you can make to objects, and the corresponding tool to use.

Modification Task Tool

Add data security to a custom object

Setup and Maintenance work area

Business Intelligence Modifications

This table shows some types of modifications that you can make to business intelligence (BI) analytics and reports, and the corresponding tools to use. For more information, see the Creating and Administering Analytics and Reports guides relevant to your products.

Modification Task Tool

Create report layout

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

Change report layouts

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

Create a report

The BI application

Modify analyses

Reports and Analytics work area or the BI application

Configure dashboards

The BI application

Help Content Management

This table shows some types of changes that you can make to help, and the corresponding tools to use.

Modification Task Tool

Modify text that is displayed when the user hovers over a button, link, icon, or tab title

Page Composer

Manage help files and determine the help links to show on help windows

Help windows or Applications Help

Simultaneously replace multiple occurrences of a word or phrase that appear in the embedded help

User Interface Text

Some product families have additional tools available for application changes, for example, Application Composer and Business Process Composer.

Personalization

Personalization refers to the changes that every user of the application can make to certain artifacts in the user interface (UI) at run time.

Note: Personalization changes remain for a user each time the user signs in to the application.

Personalization includes:

  • Changes based on how you use the UI, such as changing the width of a column in a table

  • Changes that you select to save, such as search parameters

  • Changes you make to the springboard and infolets

Context Layers

Overview of Context Layers

You can use context layers to configure pages for specific sets of users. All you need to do is make sure that your sandbox or configuration tool is set to the correct context before you make your changes. If you have enabled the Unified Sandboxes feature, you set the context when you create your sandbox. If you haven't, you can select the layer from the configuration tools you want to use. If a tool doesn't have the option to set a context layer, then its changes are made to the Site layer.

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

Available Layers

Different application families have different context layers. 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. An administrator can't make a personalization for another user.

You can configure different layers that are available for different application families:

  • Customer Relationship Management

    • Site

    • External or Internal

    • Job Role

  • Human Capital Management

    • Site

    • Country

    • Organization

    • Time Card Layout

  • Others

    • Site

Layer Rules

Layers exist in a hierarchy. The lower a level is in the hierarchy, the more specific its context is. Layers at lower levels exist within the scope of the layers above them. This means that the value is set for a context layer within the scope of the context value for the layers above it. Let's say you're configuring a page for the developer job role. When you select Job Role as the context level and set the value as Developer, you must also specify a value for the External or Internal layer.

An object or a page can have multiple configurations at the same time. But this is possible only when at least one 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 requests an object or page, configurations at the lowest layer applicable to them are given precedence. Let's say you added three columns to the table. You then configured these columns for each context layer as follows:

  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 is not hidden.

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

This is how these columns appear for different users:

Users Columns

Internal sales role

Sales Points is not hidden

External developer

Sales Points is hidden

Liam

Sales Points is hidden

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

Image showing the configurations in different context
layers

Examples of Working with Context Layers

Here are a couple of scenarios where you use context layers to make sure that the appropriate configurations and personalizations are available to the appropriate users. For instance, job role is a layer. You can configure a page to make certain changes visible to only a specific job role, such as a sales representative.

An Administrator Configures a Page for Sales Representatives

Let's say you want to remove the Export button from the Sales home page. But you want to remove it only for sales representatives. Here's what you do before you make your changes:

  • Make sure you have the role you're trying to make changes for. If you don't, your security administrator can help you with that.

  • Create and activate a sandbox.

    • If you have enabled the Unified Sandboxes feature, select Page Composer as a configuration tool when you create your sandbox, and set the context layer as Job Role with the value, Sales Representative.

    • If you haven't enabled Unified Sandboxes, set the context layer as Job Role with the value, Sales Representative in Page Composer before you make your changes.

Once all these conditions are met, you can remove the Export button from your page. When you make this change, the configuration engine in Oracle Metadata Services generates an XML, and then stores it in the Oracle Metadata Services repository. So, the original file for the page remains untouched.

When a sales representative requests access to the Sales 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 Sales home page?

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

The configuration engine also looks for additional XML files with personalizations made by the specific sales representative who requested access to the Sales home page. But for now, let's assume our sales representative hasn't made any personalizations. Once the configuration engine finds an XML file that satisfies both these conditions, that XML file is then layered over the base artifact. 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 page entries A, B, and C to the springboard on the home page. You added page entries A and B at the Site layer for all users and page entry C at the Job Role layer for just recruiters. But Liam, who is a recruiter, doesn't use page entry B all that much, and wants to hide it from her springboard. Liam can do this by personalizing her springboard to show only page entries A and C. Personalizations are done in the user layer, and are applicable only to the user who made them.

To hide page entry B, Liam goes to the springboard and clicks the Personalize Springboard icon. She then deselects page entry B and clicks OK. When she does this, an XML file is generated for Liam's user layer with this change.

The next time Liam accesses your 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 changes Liam made

The files are always applied in the order of their decreasing scope. The file for the context with the largest scope is applied first, and the file for the context with the most specific scope is applied last. In this scenario, this is what happens when each file is applied.

  • The first file adds page entries A and B to the springboard for everyone.

  • The second file adds page entry C since Liam is a recruiter.

  • The third file removes B from the springboard since Liam chose to hide it.

When a different recruiter accesses this page, only the XML files for the Site and Job Role layer are applied. This user has A, B, and C on the springboard.

Here are two diagrams that show you how this personalization flow works. In the first image, you as an administrator add page entries A and B to the home page at the Site layer. You add page entry 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 Liam and another recruiter accessing the same home page. The numbers and letters show the sequence of the steps.

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

Example of Using Context Layers in Application Changes

While making application changes, when you use the dialog box to select the context layer, you can also include lower layers to view the application changes from those layers.

The following scenarios explain what happens based on your selected layers. For these examples, the available layers are Site, Country, and Job Role.

What You See While Making Application Changes

Suppose you choose to:

  • Edit the Job Role layer and select Sales Representative 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 modifying pages in Page Composer, you see changes that apply to sales representatives in France, based on:

  • What was defined for each layer

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

What Your Application Changes Apply to

No matter what you see while making application changes, your changes apply only to the selected layer for your changes, that is, Job Role. For example, say a field is hidden in the Site layer, but displayed in the Country layer for France. No changes exist for the field in the Job Role layer for sales representative. Since Country is higher than Site, you see the field displayed while modifying pages in Page Composer. However, if you choose to hide the field as part of your changes, then that change applies to the Job Role layer for sales representatives. Users with other job roles in France may still see the field. However, Job Role is higher than Country. So, no sales representatives in any country can see the field, unless a layer higher than Job Role applies to any of these users and has the field displayed.

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.

Business Process Modeling Levels

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 a high-level, conceptual view to a low-level, application-specific view.

  • 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.

Business Process Models In the Application

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