2Configure and Extend Your Applications

This chapter contains the following:

Overview of Application Configuration and Extension

Familiarize yourself with the types of changes that you can make using various configuration tools at either runtime or design time, for all users or only some. Read this chapter to learn how you can modify your application using the different tools.

This chapter covers:

  • How to personalize applications

  • How to do runtime extensions

  • How to make application changes using context layers

  • What you can extend using which tool

  • How to test role-specific application changes

Most user interfaces are implemented using Oracle Application Development Framework (Oracle ADF) and standard Java technologies. The foundation of the applications includes the service-oriented architecture (SOA) business processes. Business intelligence framework provides a number of reporting capabilities while the identity management works to control access at each level.

Oracle sales and service applications are built using a common data model. Because of this commonality, 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 the web-based view page, to an associated mobile page, and to any associated reports. Generally, the tools and processes you use to modify one application are the same tools and processes to modify all applications.

Runtime Changes

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. This is the layer where personalizations are stored, 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 when a value is set for a context layer, it's set 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 sales representative, personalizes this page for himself and hides the Sales Points column.

This is how these columns appear for different users:

User Column

Internal sales role

Sales Points column is not hidden

External developer

Sales Points column is hidden

Liam

Sales Points column 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 Quick Create panel 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 Quick Create panel 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 Quick Create panel 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're a recruiter. Your administrator has added 3 new page entries A, B, and C to the springboard on the home page. A and B are added at the Site layer for all users, and C is added at the Job Role layer for just recruiters. But you don't use page entry B all that much, and want to hide it from your springboard. You can do this by personalizing your springboard to show only page entries A and C. Personalizations are done in the user layer, and applicable only to the user who made them.

To hide page entry B, you go to your springboard and click the Personalize Springboard icon. After you deselect page entry B, click OK. When you do this, an XML file is generated for your user layer with this change.

The next time you access your home page, the configuration engine fetches 3 XML files:

  • The file for the changes your administrator made at the Site layer

  • The file for the changes your administrator made at the Job Role layer

  • The file for the personalization you 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 you're a recruiter.

  • The third file removes B from the springboard since you 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 will have A, B, and C on their springboard.

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

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

The next image shows you and another recruiter accessing the same home page. The numbers and letters show the sequence of the steps.

This figure shows how you and another recruiter
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.

Field Display Labels

You can change the display labels (strings) that appear in your applications using Application Composer and User Interface Text Tool. These tools enable the administration of strings. Your tool selection depends on the scope of the changes that you want to make. For large-scale changes or changes to labels in locales other than English, use the User Interface Text Tool. For changes on a single page or to all labels for a custom object in the English locale, use Application Composer. Read this topic to learn more about best practices for changing display labels.

Display Labels

A single field label, such as Products, can occur across your applications on a variety of pages. However, just because the same field label appears multiple times doesn't mean that it's the same field across all pages. In fact, it's probably not. Note that there is a difference between a field label instance and a field label value. The value is what is seen on a page. The instance is the actual field location where the label value is retrieved from. Typically, multiple display label instances may exist that have the same value. This is especially true for common labels such as Account and Customer.

For example, you want to change Products to Our Products, but the field label Products appears throughout your applications 500 times. You don't have to change the Products display label 500 times. However, you will probably need to change it more than once. Again, this is due to the underlying architecture of your applications where multiple display label instances can (and do) exist with the same value.

Display Labels and Multiple Languages

Your applications are fully globalized and support multiple languages. English is installed by default and additional languages can be requested. When additional languages are installed, any user can change the current session locale (language) of their login session through the Preferences menu. However, string administration tools can change display labels to any language, regardless of the session locale. For example, the active session locale can be French, but you can use any string administration tool to enter Korean display label values. As a result, Korean display label values will be seen, even if the session locale is French. Keep this in mind when making changes to field display labels.

To modify display labels in multiple language refer to the topic, Changing a Specific Field Label.

Changing Display Labels Across Multiple Pages

The User Interface Text Tool, sometimes referred to as the String Editor, administers the vast majority of display labels. It is designed for bulk display label search and replace. This tool supports all installed languages and can be used to create and modify locale-specific label values.

Note: You cannot modify list of value fields (also known as choice lists) using the User Interface Text Tool. Instead, use Setup and Maintenance. In some cases, you can also use Application Composer to modify these special types of fields.

For example, you want to change the display label Products to Our Products wherever it appears throughout your applications.

To make a large-scale change of a display label value across multiple pages:

  1. First, sign in as an application implementation consultant and confirm that you are working in an active sandbox.

  2. Using the Navigator, select User Interface Text from the Configuration category.

  3. Click Search and Replace.

  4. In the Search For and Replace With boxes, enter the word or phrase that you want to change and the corresponding replacement.

    Tip: For optimal results, enter search criteria that produces the smallest possible number of search results. This makes it simpler to preview all possible matches in the next step. To do this, instead of entering Products, enter ^Products$. Behind the scenes, the search engine finds label values where Products is the entire display label value.
  5. Click Match Case.

  6. Click User Interface Text and Global Menu Label Text to search only the display label category that contains the vast majority of UI display labels.

    All other check boxes can be deselected.

  7. Click Preview Changes to review, modify, and exclude individual occurrences before you save your changes.

Changing Specific Display Labels

Sometimes you will only want to change a specific instance of a field label, rather than the labels of all the fields with the same name. For instance, the Opportunity page includes multiple instances of the label Account, but you might only want to change one. If you're working in an English locale, make this change using Application Composer. If you're in a non-English locale, use the User Interface Text tool.

To change an individual field name using Application Composer, look at the object's fields, then change each one with the same name to a unique value. For example, if you want to change the Account field and there are four instances of it, then change each one to something like Account 123, Account 456, and so forth. Then you can look at the object's UI to identify the one you want to change. After making the change, update the others to their original names, and make a note in the Description field for each one to help others in the future.

For a non-English-localized environment, you can't just use Application Composer to change the field name, because Application Composer is supported only for an English locale. Instead, access the User Interface Text tool after changing each field label to a unique name. In the User Interface Text tool, specify the language you want to change to in the Language list, then enter the unique name of the field you want to change in the Search box and the name you want to change to in the Replace box.

See Changing a Specific Field Label: Explained.

Changing Custom Object Display Labels

For example, you want to change all the display labels for a custom object, Trouble Ticket. In this case, use Application Composer.

Use Application Composer to change a display label value for custom object and custom field display labels. The change is displayed everywhere the original label value was displayed, across all UI channels.

Note, however, that if you use Application Composer to change display labels for standard object and standard object standard fields, the change is not displayed everywhere. This is because Application Composer changes only one instance of a label, while there are typically multiple instances of a label in use for every standard object and standard object standard field. In this case, Application Composer and Page Composer are similar tools: both tools change one and only one instance of a display label. Again, only the User Interface Text tool has the potential to change every instance of a display label.

Application Composer is an English only tool. It reads and writes only to English label data sources. Application Composer reads and writes in English display label data sources only, even if a non-English locale is the active session locale.

Tip: To add non-English display label values for custom objects, custom fields, standard objects, and standard fields, use the User Interface Text tool.

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.

Application Configurations Testing

What's Required for Testing Configurations in the Sandbox

If you are creating configurations for a specific job role or if you are creating your own objects, then you must be provisioned with additional job roles to view and test those configurations in the sandbox. You can enable the testing of both types of configurations using the steps described in this section.

What's Required for Role-Specific Configurations

If you are creating configurations for a specific job role in either Application Composer or Page Composer, then you must assign yourself that same job role to be able to test the configurations in the sandbox. For example, if you are creating your own page layout for the Sales Manager job role, then you must have the Sales Manager job role to view and test the layout. If you later create a different layout for salespersons, then you must deprovision the Sales Manager job role and provision yourself with the Sales Representative job role instead.

What's Required for the Objects You Create

If you are creating your own objects, then you must assign yourself the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role. The application automatically generates this object role the first time you create an object in the application. Unless users have this role, they cannot view or test the objects they create.

Setup Overview

  1. While signed in as a user with security privileges, such as the setup user or the initial user you received when you signed up with Oracle, you edit all of the role-provisioning rules for sales administrators and add the required job roles. Here is a summary of the steps:

    1. In the Setup and Maintenance work area, use the following:

      • Offering: Sales

      • Functional Area: Users and Security

      • Task: Manage HCM Role Provisioning Rules

    2. Search for all role-provisioning rules containing the Sales Administrator job role.

    3. For each rule, you add the job roles required for testing. Selecting the Self-requestable option makes it possible for individual users to assign themselves each job role when needed.

    4. If you are creating your own objects, then you must also add the Custom Objects Administration role. You must select both the Self-requestable and the Autoprovision option for this role. This object role is required for all objects you create, so you want to provision it automatically for future to sales administrators.

    For details, see the Enabling Sales Administrators to Test Configurations in the Sandbox topic.

  2. Sales administrators, who are resources with the Sales Administrator job role, navigate to the Resource Directory and assign themselves the job roles they need. Setup users, who are not resources, can edit their own user records in the Manage Users work area and assign themselves the roles there.

    For details on how resources can assign themselves job roles in the Resource Directory, see the Assigning Yourself an Additional Job Role topic.

Enable Sales Administrators to Test Configurations in the Sandbox

Modify the provisioning rules to make it possible for sales administrators to assign themselves the job roles they need for testing configurations in the sandbox. For viewing and testing objects they create, sales administrators must have the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role. To test job role-specific configurations, they must have the same job role.

Modifying the Provisioning Rules for Sales Administrators

  1. Sign in as a setup user or the initial user you received when you signed up with Oracle.

  2. In the Setup and Maintenance work area, use the following:

    • Offering: Sales

    • Functional Area: Users and Security

    • Task: Manage HCM Role Provisioning Rules

    The Manage Role Mappings page appears.

  3. Search for the role mappings that provision the sales administrators:

    1. In the Search region, click the Role Name list and select the Search link.

    2. In the Search and Select window, enter Sales Administrator in the Role Name field and click Search.

    3. Select the role name and click OK.

    4. Click Search.

  4. On the Manage Role Mapping page, click Search.

    The Search Results display the mappings with the Sales Administrator job role.

  5. Click the mapping name of each mapping and make the following edits:

    1. In the Associated Roles region, click Add Row (the plus sign icon) and add the job roles required for testing.

    2. For each job role, select the Requestable and the Self-requestable options and deselect Autoprovision. You do not want the job roles assigned to the sales administrators automatically.

    3. If you are creating your own objects, then you must also add the Custom Objects Administration role. The application automatically generates this object role the first time you create an object. For this job role select all of the options: Requestable, Self-requestable, and Autoprovision. All users creating their own objects must have this role.

    4. Click Save and Close.

  6. When you have added the job roles to all the provisioning rules, click Done.

Assign Yourself Additional Job Roles Required for Testing

Sales administrators who are also sales resources can use this procedure to assign themselves the role they must test role-specific modifications in the sandbox. For example, an administrator testing UI modifications for sales managers, requests the Sales Manager job role or the equivalent customer-defined role. If you are creating your own objects, you can use this procedure to assign yourself the Custom Objects Administration role, if this role is not already assigned to you. The Custom Objects Administration role is required for testing your objects in the sandbox.

Note: You can only assign yourself job roles that are made self-requestable in the role-provisioning rules created by a setup user. A setup user has the privileges to create other users and manage application security.

Assigning Yourself an Additional Job Role

  1. Navigate to the Resource Directory.

  2. Select View Resource Details from the Actions menu in your record.

    Actions menu

    The Resource page appears.

  3. Select the Roles tab.

  4. Click Add Role.

    The Add Role window appears.

  5. Search for the role you want to use for testing by name or partial name, select it, and click OK.

    For testing objects you created, you must add the Custom Objects Administration role.

    Note: Available roles include only those that were set up as self-requestable during provisioning rule setup.

    The application returns you to the Resource page and displays the requested role in the Roles Requests region.

  6. You can remove a role you no longer need for testing by selecting it and clicking Remove.

  7. Click Save and Close.

    The new role becomes available for your use in a few minutes, pending the completion of a background process. It displays in the Current Roles region the next time you navigate to this page.