Cloud Documentation
Advanced Search


Extending Sales
Close Window

 

This guide also applies to on-premise implementations

Table of Contents

Show All | Collapse

5 Application Composer: Using the Application Composer

This chapter contains the following:

Using Application Composer: Overview

Extending Oracle Sales Cloud: How It Works

Customizing Sales Cloud Applications Across Application Boundaries: Explained

Customizing Oracle Sales Cloud Applications Using Application Composer: Explained

Defining Objects: Explained

Object Relationships: Explained

Defining Fields: Explained

Field Types and Field Properties: Explained

Check Box Fields: Explained

Currency Fields: Explained

Date Fields: Explained

Datetime Fields: Explained

Dynamic Choice Lists: Explained

Fixed Choice Lists: Explained

Formula Fields: Explained

Joins and Join Fields: Explained

Adding Join Fields to the Sales Account Object: Worked Example

Long Text Fields: Explained

Number Fields: Explained

Percentage Fields: Explained

Record Type Fields: Explained

Text Fields: Explained

Defining Pages: Explained

Creating a Work Area: Explained

Subtabs: Explained

Tree Nodes: Explained

Actions and Links: Explained

Saved Searches for Oracle Sales Cloud Objects: Explained

Making Saved Searches Available to All Users: Procedures

Securing Custom Objects: Explained

Importing and Exporting Custom Objects: Explained

FAQs for Using Application Composer

Using Application Composer: Overview

Read this chapter to learn about the primary task flows that are available in Application Composer.

In this chapter, you will learn about:

  • How application composer works, at a summary level

  • The concept of Web applications, and how you can complete some customization tasks across Web application boundaries in selected Sales Cloud applications

  • How to define custom objects

  • How to define custom fields for either a custom object, or a standard object

  • How to create, or modify, the user interface pages to display your custom objects and custom fields on various pages

  • How to edit saved searches that were created using Application Composer

  • How to secure custom objects, both in terms of what users can do on the object's work area, as well as the data that users can see

Other chapters in this guide also describe additional tasks flows that are available in Application Composer, such as creating object workflows and custom subject areas, writing Groovy scripts, and importing and exporting your customizations. Refer to the table of contents for these other chapters.

To navigate to Application Composer to make your application changes, select Application Composer from the Navigator, under the Tools > Customization category. Remember to always select the desired application from the Application choice list first, before making any changes. To test your changes in the actual application, use the Navigator to switch to the desired application to view your changes at run time.

Extending Oracle Sales Cloud: How It Works

Application Composer is a browser-based configuration tool that enables business analysts and administrators, not just application developers, to customize and extend Oracle Sales Cloud. Make the type of data model changes which, for non-Sales Cloud applications, can only be made by application developers. For example, easily create a new object and related fields, then create new desktop pages where that object and its fields are exposed to users. Application Composer is a design time at run time tool, which means that you can navigate to Application Composer directly from any Sales Cloud application, make your changes, and see most changes take immediate effect in real time, without having to log out and sign back in. Data model changes, such as the creation of custom fields, do require that you reauthenticate before you can see those changes.

Pattern-Based Application Design

Application Composer hides the complexity of customization from business analysts by leveraging a set of standard design patterns and wizards. You focus on the application changes that your business requires (object model extensions and layout changes, for example), and Application Composer creates the underlying object artifacts for you.

Access Application Composer from any Sales Cloud application at run time by using the Navigator menu, and selecting Application Composer under the Tools > Customization category. The first view of Application Composer is the main Overview page, which is the entry point into all your customization options.

This is a screenshot of the main Overview page in Application Composer.

From Application Composer's Overview page, you can make application changes such as:

  • Customize objects by adding new fields, or create entirely new objects.

  • Create foreign key-based relationships between two objects.

  • Customize desktop pages by exposing your newly created fields for an object, or create an entirely new work area for your newly created objects.

    Expose object relationships on desktop pages in the form of subtabs or tree nodes.

  • Write application logic, such as triggers, validation rules, and workflows, for an object or for use across multiple objects.

  • Implement functional and data-level security for custom objects.

  • Enable objects for custom reporting.

Getting Started: Application Composer's Overview Page

To access Application Composer, log in with the Customer Relationship Management Administrator job role. Then, select Application Composer under the Tools > Customization category in the Navigator menu to navigate to the main Overview page.

From the main Overview page, select the application you want to customize using the Application choice list. Then:

  • Use the object tree to select the object you want to customize, or click the New icon to create a new object.

    This is a screenshot of the object tree in Application Composer.

  • Use the links in main Overview page, also known as the local area, to select a customization task.

    Or, use the links in the Common Setup pane.

    This is a screenshot of the Common Setup pane in Application Composer.

Change the selected application in the Application choice list at any time to customize another Sales Cloud application.

Customizing Sales Cloud Applications Across Application Boundaries: Explained

When you customize applications using Application Composer, you always do so within the context of a Web application, such as Sales or Marketing. This is a critical selection because your customizations reside within that application only. Additionally, this concept of Web application "boundaries" is important because it directly impacts what you can do when making changes using Application Composer. Specifically, some customization tasks that you might want to complete across Web applications are available to you only between certain applications, not all.

This topic introduces you to the concept of Web applications, and also describes the customization tasks that cross Web application boundaries which you can complete only in selected Sales Cloud applications:

  • Customer Center

  • Marketing

  • Sales

Selecting a Web Application

To complete a customization task, such as create a new custom object, you first select an application (such as Sales or Marketing) on the main Overview page of Application Composer. The new custom object will belong only to the application that you select.

Tip

When you first open Application Composer, the default application is always Common. If you previously made customizations in another application, such as Sales, then you must manually change the application using the Application choice list to Sales, before you can review and update those customizations.

Web applications are also referred to as application containers.

This is a screenshot of the Application choice list, where you can select which application you want to extend

Cross-Application Customization Tasks

What is a cross-application customization task? This refers to any customization task that you can do to an object in one Web application by accessing an object in another Web application. For example, you might want to add a subtab to an opportunity's page (Oracle Fusion Sales) that displays marketing campaign records (Oracle Fusion Marketing).

In general, customization tasks that are available in Application Composer can be categorized into three areas:

  • Object model customizations

    For example, add a new field to an object, or create a new object entirely.

  • User interface customizations

    For example, show or hide a field. Or create a work area for a new top-level object.

    Tip

    A top-level object is an object that does not have a parent as part of its definition. In other words, it is not a child object. Top-level objects have their own work areas (a set of user interface pages such as an overview page and details page). A child object does not have its own work area, and appears instead as a subtab or tree node within the work area of its parent.

  • Scripting customizations

    For example, make a field conditionally required based upon a value in another field.

You can make object model, user interface, or scripting changes that cross Web application boundaries, provided that the object you are customizing exists in one of three Sales Cloud applications:

  • Customer Center

  • Marketing

  • Sales

Note

Crossing Web application boundaries is constrained to only the above three applications. In other words, if you are in Customer Center, Marketing, or Sales, then you can reference all objects (both custom and standard) from across those same three applications. Additionally, you can also reference standard objects (but not custom) from the Common application.

Object Model Customizations

When customizing an object's model in Customer Center, Marketing, or Sales, you can reference standard and custom objects from across those same three applications, plus standard objects from the Common application. The types of changes you can make include:

  • Dynamic choice lists

    A dynamic choice list is a field that contains a list of values which are populated from the actual data of another object.

    From a cross-application perspective, you can create a dynamic choice list field for an object in one Web application that is populated by the records from an object in another Web application.

    • For example, create a dynamic choice list field for the opportunity object (Sales) which is populated with sales lead records (Marketing).

      This lets customers see which sales lead an opportunity is converted from.

    • Or, create a dynamic choice list field for the sales account object (Customer Center) which is populated with competitor records (Sales).

      This lets customers see which competitor they need to compete against for a given customer.

  • Relationships

    A relationship is a foreign key association between two objects, and indicates a connection between two objects' data. (You create a relationship between two objects, so that you can later expose this connection on user interface pages through the use of child or related object subtabs or tree nodes.)

    From a cross-application perspective, you can create a relationship between two objects from different Web applications.

    • For example, create a relationship where the opportunity object is the source and the sales lead object is the target.

      This enables the creation of the sales lead object subtab on the opportunity object's details page. See the "User Interface Customizations" section in this topic.

      This lets customers see if more than one sales lead converted to a single opportunity.

    • Or, create a relationship where the sales account object is the source and the competitor object is the target.

      This enables the creation of the competitor object tree node on the Customer 360 tree. See the "User Interface Customizations" section in this topic.

      Tip

      Create a one-to-many relationship instead of a dynamic choice list, if there are usually multiple competitors for a given customer.

    Note

    Relationships enable not only user interface changes, such as subtabs and tree nodes. In addition:

    • Each object in the relationship becomes available for scripting against the other object. See the "Scripting Customizations" section in this topic.

    • Objects in a relationship are available to be selected as child objects, when defining a custom subject area.

Tip

Object model customizations include the creation of custom objects, as well. When creating a new object, consider whether you eventually plan to share that object between Customer Center, Marketing, and Sales. If so, create that object as a top-level custom object in Customer Center. On the other hand, if you need to share that object with any objects that exist under the Common Web application, then create that object as a top-level custom object in the Common Web application.

User Interface Customizations

When customizing an object's user interface in Customer Center, Marketing, or Sales, you can reference standard and custom objects from across those same three applications, plus standard objects from the Common application. The types of changes you can make include:

  • Subtabs and tree nodes

    You can display details that are related to the current object but derived from another object. You do this by adding subtabs to an object's details page, and specifying the source of subtab data, or by adding tree nodes to the object's tree, and specifying the source of tree node data.

    From a cross-application perspective, the source of subtab or tree node data can come from an object in a different Web application.

    • For example, add a Sales Leads subtab to the Opportunity details page.

    • Or, add a Competitor tree node to the Customer 360 tree.

Note that a relationship must first exist between the two objects, prior to adding subtabs or tree nodes.

Scripting Customizations

When writing groovy scripts as part of customizations to an object in Customer Center, Marketing, or Sales, you can reference standard and custom objects from across those same three applications, plus standard objects from the Common application, in your scripts. The types of changes you can make include:

  • When writing a script, access data from any standard object in any Sales Cloud Web application, as well as from any custom top-level object created in Customer Center, Marketing, or Sales, using the newView() built-in function. The newView() built-in function is described in "Accessing the View Object for Programmatic Access to Business Objects" in Application Composer Scripting Guide (ID 1354807.1) on My Oracle Support.

    Note that a relationship must first exist before you can script against other objects.

    • For example, write a script in a "before update" trigger on the opportunity object that counts the number of leads that involve this opportunity. At run time, when a user saves an opportunity record, the trigger populates a custom field on the opportunity with the number of related leads.

    • Or, write a script in a "before insert" trigger on the sales account object that retrieves information about the opportunity associated with the organization that the sales account is tied to.

Common Objects: Exceptions

Objects available in the Common Web application include common components such as tasks, interactions, and notes, as well as Master Data Management (MDM) and Common Party User Interface (CPUI) objects. These Common objects are available to you when customizing an object in Customer Center, Marketing, or Sales.

When customizing Common objects themselves, however, the object model and user interface cross-application customization tasks described above are not available. Scripting customizations are available, although you should proceed carefully when writing scripts for Common objects that access objects outside the Common Web application. Your scripts will work only when triggered within the context of the other Web application.

For example, when creating a note, you can write a script to insert details about an opportunity into a custom field on the note. This script will work only if a user creates the note from within Sales. If, however, the user creates the note from within Marketing, then the script will not work.

Customizing Oracle Sales Cloud Applications Using Application Composer: Explained

Application Composer provides a series of task flows which let you customize and extend an Oracle Sales Cloud application according to the needs of your users. For example, you can create fields for an existing standard object, and expose those new fields on the object's work area. Or, create a brand new custom object and related fields, then create a work area where that object and its fields are exposed to users. The task flows available to you are dependent upon the application that you are customizing.

Available Customization Task Flows

Different sets of customization task flows are available to you, depending on the application that you are customizing. See Customizing Oracle Sales Cloud Applications Using Application Composer (Doc ID 1516151.1) on My Oracle Support at https://support.oracle.com. This document provides a list of which task flows are available for use in these Sales Cloud applications:

  • Common

    This includes Master Data Management (MDM) and Common Party User Interface (CPUI) objects.

  • Customer Center

  • Marketing

  • Sales

  • Oracle Fusion Sales Catalog

You can also refer to the product-specific implementation guides to learn more about how a particular application works with Application Composer.

Defining Objects: Explained

One of the primary customization options available to you when using Application Composer is the ability to extend an Oracle Sales Cloud application's object model. Customize Sales Cloud objects by adding new fields to an existing object (standard objects), or create entirely new objects (custom objects). Standard objects are objects that are delivered with a Sales Cloud application, and made available to Application Composer for customization. Custom objects are objects that you create using Application Composer. You can create either top-level objects (objects without a parent) or child objects (objects created in the context of a parent).

Review these aspects of the object model extension process in Application Composer before you begin to customize or extend your Sales Cloud application's object model:

  • Browsing the object tree

  • Creating a custom object

  • Using the Object Overview page

  • Editing an object's attributes

  • Viewing child and related objects

  • Deleting a custom object

Application Composer's Object Tree

Access Application Composer from a Sales Cloud application at run time by using the Navigator menu. The first view of Application Composer is the main Overview page, which is the entry point into all your customization options.

This is a screenshot of the main Overview page in Application Composer.

On the main Overview page, the regional pane at left displays the object tree, which lets you browse an application's existing object configuration in a tree format. The object tree reflects the latest configuration of the application: both standard objects as well as custom objects.

To use the object tree:

  1. Select Application Composer from the Navigator menu, under the Tools > Customization category.

  2. On the main Overview page, select an application from the Application choice list.

  3. For each object node, whether standard or custom, expand it further to view and edit object details, such as an object's fields and UI pages where the object is exposed.

    This is a screen shot of the object tree in Application Composer.

    Note

    At the top of the object tree, you can also click the New icon to create a new custom object.

    For both standard and custom objects, you can view and edit the following details:

    • Fields

      Add new fields to an object.

    • Pages

      Modify the pages on which an object appears.

    • Actions and links

      Add actions or links to pages.

    • Server scripts

      Write application logic that controls the behavior of an object's records.

    • Saved searches

      Edit saved searches for an object.

    For custom objects, you can also view and edit details for:

    • Security

      Implement functional and data-level security for an object and its records.

Creating a Custom Object

To create a new custom object, you first select an application on the main Overview page of Application Composer. The new custom object will belong to the application that you select. After you select the application:

  1. Select the Custom Objects node or link in either the object tree or local area of the main Overview page.

    On the resulting summary table, click the New icon.

  2. Or, at the top of the object tree, click the New icon

  3. Complete the primary identifying attributes for a custom object:

    1. Display Label

      An object's display label is the user-friendly label for an object, and also becomes the default page title for the object's work area.

    2. Plural Label

      The plural label is used as the title of the object's work area. The label is also used as the search string in the regional search, as well as in the saved search on the object's run time overview page.

    3. Record Name

      Use the Record Name field to specify the display label for the object's RecordName field. The RecordName field stores the "name" of the record. For example, for an opportunity object, this RecordName field stores the opportunity's name. Accordingly, if you were creating this object as a custom object, then you would set the Record Name field to Opportunity Name.

      Typically, this field is the object's primary user-recognizable identifier for the object, and as such, is usually the identifier that run time users drill down on, from the overview page to the detail page.

    4. Object Name

      The object name is the internal name for the object.

    5. Description

Tip

To create a custom child object, click the Create Child Object button in the standard or custom objects summary table, or from an object's Object Overview page.

Once created, a child object cannot be changed to a parent object. Similarly, a parent object cannot be changed to a child object.

Child objects are discussed below.

Using the Object Overview Page

The Object Overview page provides a high-level overview of a standard or custom object. The Object Overview page displays the primary attributes for an object, plus a list of child objects and related objects, if any.

This is a screenshot of the Object Overview page for an object, in Application Composer.

To access the Object Overview page:

  1. Select an application on the main Overview page.

  2. Select a standard or custom object in the object tree.

  3. Or, select the Standard Objects or Custom Objects node or link in either the object tree or local area of the main Overview page, choose an object from the resulting summary table, and select the Edit icon.

From the Object Overview page, you can:

  • Edit the object's primary attributes, described in the previous section.

  • View the parent child relationships that were created for this object.

    You can also create new child objects from this page, which implicitly creates a new parent child relationship.

  • View the non-parent child relationships that were created for this object.

Editing an Object's Attributes

After an object has been created, you can edit its attributes from its Object Overview page.

To edit an object's attributes:

  1. Select an application on the main Overview page.

  2. Select the Standard Objects or Custom Objects node or link in either the object tree or local area of the main Overview page.

  3. From the resulting summary table, select an object and then select the Edit icon to navigate to its Object Overview page.

  4. On the Object Overview page, click Edit:

    • Change the object's display label, description, and record name at any time.

    • You cannot change the Object Name and API Name after the object has been created.

      A custom object's API name is automatically derived using the logical name followed by _c. You use the API name in Groovy expressions that you build with the expression builder, when writing business logic for the object.

Viewing Child and Related Objects

The Object Overview page displays a list of child objects and related objects, if any, that have been created for an object. You can also create new child objects from this page.

  • A child object is an object with a cascade delete relationship to a parent object. This means that if you delete the parent object, then all its children are automatically deleted. A child object does not exist outside the context of the parent object, and does not have its own work area. You cannot change a child object to a parent object after the child object has been created.

  • Related objects can exist independently of each other, even if one object is deleted. Related objects are connected in a foreign key-based relationship between two top-level objects, not as parent and child. These types of relationships include reference relationships and dynamic choice list relationships.

    Related objects can have either a one-to-many or a many-to-one relationship with the current object. Note that an object can be related to itself to model a hierarchy of the object. In this case, the object itself is displayed on its Object Overview page as a related object. For example, the Department and Sub-department objects would be displayed in this way.

    Note

    You do not create these types of relationships from this page. Instead, manage relationships from the Relationships page, which you can access from Application Composer's main Overview page. Or, create a dynamic choice list relationship by creating a dynamic choice list field for an object, which derives its choice list values from another object.

To create a child object for a standard or custom object:

  1. Navigate to an object's Object Overview page.

  2. Click the Create Child Object button. Creating a child object is the same as creating a custom object, except:

    • The current object is automatically displayed as the parent object.

    • Specify the Child Collection Name field to specify the internal name for this set of child object records, which can be used later when writing Groovy scripts.

Deleting a Custom Object

Application Composer does not support the deletion of either standard or custom objects. If you no longer need an object that was already published to the mainline code, optionally enter a note in the description that the object is no longer used.

Object Relationships: Explained

A relationship is a foreign key association between two objects, and indicates a connection between two objects' data. You can expose this connection on desktop pages through the use of child or related object subtabs or tree nodes. Using the Oracle Fusion CRM Application Composer, you can create one-to-many relationships between two objects within the same application, where one object's primary identifier is stored in another object's table. A relationship must exist before you can expose the "many" objects on a subtab or tree node that is displayed on the "one" object's details page or tree. For example, an account can have multiple service requests associated to it. To expose a list of service requests associated with a specific account as a subtab on the account's details page, you must first create a one-to-many relationship between the account and service request objects. You can create these relationships implicitly by creating a child object or by creating a dynamic choice list. Or, create relationships explicitly on the Create Relationship page.

Review these aspects of the relationship creation process in Application Composer before you begin to create relationships between objects:

  • Relationship types

  • Creating reference relationships

  • Adding subtabs or tree nodes

  • Many-to-many relationships

Relationship Types

Four types of one-to-many relationships exist:

  • Parent child relationship

    Parent child relationships are implicitly created when a custom object is created as a child of a top-level object.

    When a child object is created, it is created specifically in the context of its parent. A child object does not have its own work area, and the child object is deleted if the parent object is deleted.

    View parent child relationships on the parent object's Object Overview page. If a parent child relationship exists, then the child object is listed on the parent's Object Overview page in the Child Objects region. A top-level object can have many child objects.

    You can also view the parent child relationship from the child object's Object overview page. If a parent child relationship exists, then the parent object is listed on the child's Object Overview page in the Object Information region. A child object can have only one parent object.

    Relationships that are implicitly created from parent child relationships are also viewable on the Relationships page. The relationship name is automatically generated for you.

  • Choice list relationship

    Choice list relationships are implicitly created between two objects when you create a dynamic choice list field.

    View choice list relationships on an object's Object Overview page. If a choice list relationship exists, then the related object is listed on the object's Object Overview page in the Related Objects region.

    A dynamic choice list is a field that contains a list of values which are populated from the actual data of another object. For example, you might want to expose on a desktop page a dynamic choice list which lets users specify the HR representative of a given department. The HR Representative choice list is a field that you are adding to the department object, but the list of values is populated by actual employees from the employee object.

    In the previous example of making a list of accounts available for selection for a help request, an account can be tied to multiple help requests. The relationship that is created is a one-to-many relationship between the account and help request objects, which enables users to store an account identifier in the help request object's table. In this relationship, the account object is the source object and the help request object is the target object. If a source object is ever deleted from the system, then at run time, the dynamic choice list will have no values in it.

    Later, you might want to expose a related object subtab on the account details page which shows, for a single account, all the help requests that are related to it. You can create this related object subtab because the relationship was already created when you created the dynamic choice list.

    These objects are related objects, not parent child objects; related objects are not deleted if the current object is deleted.

    Relationships that are implicitly created from dynamic choice list relationships are also viewable on the Relationships page. The relationship name is automatically generated for you.

    Note

    Generally, the dynamic choice list that you create results in the implicit creation of a choice list relationship. The exception is if you create a dynamic choice list between a Sales Cloud object and a common object: resource, customer contact profile, account, address. In such cases, relationships are not implicitly created.

  • Reference relationship

    Instead of using a dynamic choice list to implicitly create a relationship between two objects, you can also manually create this relationship as a reference relationship.

    Reference relationships are explicitly created between two top-level objects using the Create Relationships page.

    View reference relationships on an object's Object Overview page. If a reference relationship exists, then the related object is listed on the object's Object Overview page in the Related Objects region.

    Using our previous example, perhaps you don't need to display an HR Representative choice list on a department desktop page, but you still want to add a department subtab to an employee's details page. In this case, manually create a reference relationship between the employee and department objects where the employee is the source object and the department is the target object. This enables the creation of the department subtab. Such a reference relationship, however, does not automatically create a corresponding HR Representative choice list for use on the department desktop page. In fact, once you manually create a relationship, you cannot reuse the relationship to create a choice list. This means that you should carefully consider the need for a choice list before you create a reference relationship.

  • Standard relationship

    Standard relationships are relationships that are already created between two standard objects by the Oracle Sales Cloud application.

    You can also view standard relationships on an object's Object Overview page. If a standard relationship exists, then the related object is listed on the object's Object Overview page in the Related Objects region.

Creating Reference Relationships

Create a foreign key-based, one-to-many relationship between two top-level objects explicitly using the Create Relationship page. Explicitly created relationships are also known as reference relationships.

You can also create a foreign key-based, one-to-many relationship by creating child objects and dynamic choice lists. These implicit relationships are discussed in related topics.

To explicitly create a relationship between two top-level objects within the same application:

  1. Select Relationships in the Common Setup pane.

  2. On the Relationships page, click the New icon.

    This is a screenshot of the Relationships page in Application Composer.

  3. Select the source object and target object.

    This is a screenshot of the Create Relationship page in Application Composer.

    A child object cannot be the source object or target object.

    Common components, such as notes, interactions, or tasks, are not available for selection as either source objects or target objects.

    In general, you create a relationship between two objects within the same application. You can, however, select common objects as target objects. Common objects include:

    • Account

    • Address

    • Customer Contact Profile

    • Resource

    Once you create a relationship, you can no longer edit the source and target objects.

    This relationship adds a field to the target object to store the foreign key details. If the source object is ever deleted, the target object records remain in the system.

  4. Enter the relationship name and description.

    Once you create a relationship, you can no longer edit the relationship name.

  5. Optionally add the target object in a subtab to the source object's detail page, or as a tree node.

Note

You can create multiple relationships between the same source and target objects. For example, create both a Primary Contact and Secondary Contact relationship between the contact and opportunity objects.

Adding Subtabs or Tree Nodes

After you create relationships between objects, you can then expose the "many" objects on a subtab or tree node that is displayed on the "one" object's details page or tree.

When adding a subtab or a tree node to an object's details page or object, you select to add a Child or Related Objects subtab from the object's Pages Overview page. Application Composer lets you add a subtab or tree node based on any target object that has a relationship with the current object as the source object. Subtabs and tree nodes are discussed in related topics.

Many-to-Many Relationships

Objects can also have a many-to-many relationship. For example, a service request can have multiple employees working on it. At the same time, a single employee can work on multiple service requests. In this scenario, you would create a many-to-many relationship between the service request and employee objects, where the related records from both objects store their primary identifiers in an intersection table.

To create a many-to-many relationship using Application Composer:

  1. Create a child object of one object, and use this child object to represent the intersection table that stores the record identifiers of both objects.

    For example, create a service request member object as a child of the service request object. The service request member object's table records the service request identifier as a foreign key.

  2. Add a dynamic choice list for the new child object whose related object is the other object in the many-to-many relationship.

    For example, create a dynamic choice list, Support Representative, for the service request member object where the choice list's related object is employee. Application Composer automatically creates the underlying relationship for you, where the employee is the source object and the service request member is the target object. The service request member object's table records the employee identifier as a foreign key.

Now, the service request member object's table records two foreign keys: one for the service request object and the other for the employee object. This enables the many-to-many relationship. You can now do the following:

  • Create a child subtab on a service request's details page. The subtab displays all employees that are working on a specific service request.

  • Create a related object subtab on an employee's details page. The subtab displays all service requests that an employee is working on, since each employee can work on multiple service requests.

Defining Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding new fields to both standard or custom objects. A standard object has a set of standard fields. Standard fields are the fields that are delivered for a standard object in a Sales Cloud application. The fields that you add to an object are custom fields. When creating a custom field, Application Composer provides a set of field types that you can choose from. For example, you can create a check box field, or create a long text field. When you create custom fields for objects and expose the fields on desktop pages, Application Composer automatically creates all the underlying object artifacts for you, and provides full Web service support for those new fields, as well. Application Composer also makes it easy to enable your object model extensions for importing and exporting.

Review these aspects of editing fields in Application Composer before you begin to customize or extend your Sales Cloud application's object model:

  • Adding fields to objects

  • Deleting fields

Adding Fields to Objects

Use the Fields page to review the list of standard and custom fields for an object, and create custom fields. A Sales Cloud object can have a maximum of 625 fields.

To view the Fields page for an object:

  1. Select an application from the Application choice list on the main Overview page.

  2. Select either the Standard Objects or Custom Objects node in the object tree to expand the list of objects.

  3. Select the object itself to further expand the tree hierarchy.

  4. Select the Fields node to navigate to the Fields page.

On the Fields page:

  • Standard Fields

    Review the list of standard fields that are delivered for an object, and optionally modify the display label and help text for a field.

    The list of standard fields includes all the fields that are specific to an object, as well as system fields, which could include:

    • CreatedBy

    • CreationDate

    • Id

    • LastUpdateDate

    • LastUpdatedBy

    • RecordName

    The custom objects that you create also contain these same system fields, among others.

  • Custom Fields

    Review the list of custom fields that were created specifically for your Sales Cloud implementation for either standard or custom objects, and create new custom fields.

    To create a custom field, select the New icon from the custom fields table on the Fields page. Application Composer provides a set of field types that you can choose from when creating new fields:

    • Check box

    • Currency

    • Date

    • Datetime

    • Dynamic choice list

    • Fixed choice list

    • Formula

    • Long text

    • Number

    • Percentage

    • Record Type

    • Text

Deleting Fields

Application Composer does not support the deletion of either standard or custom fields from objects. If you no longer need a field that was already published to the mainline code, optionally enter a note in the field description that the field is no longer used.

Field Types and Field Properties: Explained

When you create a custom field in Application Composer, you select from a set of standard field types. Each field type has a corresponding set of standard properties. Some properties are unique to a specific field type, whereas other properties are common across field types. For example, for all field types, you must specify a display label for the field to indicate how you want the field to appear on a desktop page.

Before you create a new field for a object, you should understand:

  • The set of standard field types available for field creation

  • The common set of field properties that you must specify for a field

  • How field types work with other components

Field Types

When creating a new field for a object, Application Composer provides a set of standard field types that you can choose from.

The types of fields that you can create are listed below.

  • Check box

    Users can select a check box, indicating a true or false attribute of a record.

  • Currency

    Users can enter a currency amount.

  • Date

    Users can enter a date, or select a date from a calendar.

  • Datetime

    Users can enter a date, or select a date from a calendar, and enter a time of day. During field creation, you choose whether to show the date or time, or both.

  • Dynamic choice list

    Users can select from a list of values, populated from another object's set of records.

  • Fixed choice list

    Users can select from a list of static values, populated from an FND lookup type.

  • Formula

    A formula field is a field that is calculated in the run time application using the Groovy-based expression included in the formula field's definition. This is a read-only field that users in the run time application do not update. However, the application logic that you write can update these fields directly.

  • Long text

    Users can enter a combination of letters, numbers, or symbols. This field type supports 32,000 characters.

  • Number

    Users can enter a number in this field.

  • Percentage

    Users can enter a percentage. The system automatically adds the percent sign.

  • Record Type

    Users can select from a list of static values, populated from an FND lookup type. This particular type of field is useful, because you can associate each choice list value with a role or a page layout.

  • Text

    Users can enter a combination of letters, numbers, or symbols. This field type is limited to 254 characters.

Common Field Properties

When you create a custom field, you first select the field type. For example, are you creating a check box field, a formula field, or a long text field? You cannot change the field type after the field is created. The specified field type controls which field properties you must define when creating the field. Some properties are common across field types, whereas other properties are unique to a specific field type.

The common field properties that you can define for a custom field are listed in this table, along with the regions on the field configuration pages where they appear and a list of the applicable field types that you must set these properties for. Use this table to understand the common properties that you must define when creating a new field.


Field Property

Field Property Region

Related Field Types

Label

Specify the display label for the field.

A maximum length of 80 characters is recommended, although no maximum length is actually enforced.

Appearance

These properties control how the field appears to your users in the run time application.

Set this property for all field types.

Help Text

The help text displays when users hover over the field in the run time application.

A maximum length of 80 characters is recommended, although no maximum length is actually enforced.

Appearance

Set this property for all field types.

Display Width

Specify the display width for most field types at run time. The display width is the actual character width for the field on a desktop page.

Note

When setting the display width, consider the resolution in use where this field will be displayed on a desktop page. A display width that is too wide will stretch beyond the resolution of the display and result in scroll bars.

Generally, enter a display width of no more than 20 to 25 characters.

Warning

For fixed choice lists, note that the display width is determined by the length of the longest string in the choice list.

Appearance

Set this property for all field types except for check box, date, and datetime fields.

Name

Enter a unique field name, which is for internal use only.

The field name is automatically populated based on the field label you enter, but without spaces.

Field names can contain only underscores and alphanumeric characters. They must begin with a letter, not include spaces, not end with an underscore, and not contain consecutive underscores. Field names are limited to 28 characters.

You cannot change this property after the field is created.

Tip

It is possible to create custom fields with different names, but the same display label. Avoid this scenario, however, so that you do not see two fields with the same display label when configuring a desktop page.

Note

The API name is also automatically generated for a field, by taking the logical name and appending _c. The API name is used in your Groovy scripts.

Name

Set this property for all field types.

Description

Enter a unique field description, which is for internal use only.

Name

Set this property for all field types.

Required

Indicate if the field is a required field. You can also optionally use the expression builder to write an expression that describes the conditions required for this field to be required.

Important

Default values are not required for required fields. However, you must expose all required fields on the object's creation and details (update/edit) pages wherever those pages appear (such as on the desktop, simplified, mobile, or Outlook UI). This lets your users populate the field at run time. The object's Web services also reflect the required fields when your sandbox is published to the mainline.

Note

If you write an expression to control whether a field is required, then you must also configure the Depends On choice list. This choice list includes fields from the current object, and is used in the evaluation of your expression at run time.

Constraints

Specify constraints, which let you control the run time behavior of the field.

Set this property for all field types except for formula fields.

Updateable

Indicate if the field is an updateable field. You can also optionally use the expression builder to write an expression that describes the conditions required for this field to be updateable. This includes being updateable on a desktop page, via Web services, through the import and export functionality, and by server scripts.

Note

If you write an expression to control whether a field is updateable, then you must also configure the Depends On choice list. This choice list includes fields from the current object, and is used in the evaluation of your expression at run time.

Constraints

Set this property for all field types except for formula fields.

Searchable

Indicate if you want this field to be made available for selection as an additional search criteria from the Add Fields choice list in the Advanced Search mode.

Constraints

Set this property for all field types except for long text and formula fields.

Indexed

Enable faster searching by indexing this column.

Only a limited number of columns are indexed. For standard objects, 2 varchar extension columns and 3 number extension columns are indexed. For custom objects, 10 varchar columns and 10 number columns are indexed.

Accordingly, use this property only on the most frequently searched fields.

You cannot change this property after the field is created.

Constraints

Set this property for text, number, date, datetime, currency, and percentage field types.

You cannot index long text, formula, and check box fields, or fixed and dynamic choice lists.

Fixed Value

Specify a literal default value for the field.

Warning

Do not assign a literal default value to fields that are both required and intended to be unique, as a run time error could occur.

Default Value

Set this property for all field types except for formula fields and dynamic choice lists.

Expression

Use the expression builder to write an expression that dynamically sets the default value for a field at run time.

Default Value

Set this property for all field types except for check box and formula fields, and fixed and dynamic choice lists. To set default values for these types of fields, write server scripts.

How Fields Types Work With Other Components

When you create new fields for objects, Application Composer limits you to a set of standard field types. The field types that you can select from are already integrated with other components of the Oracle Sales Cloud Extensibility Framework to provide you with the most flexibility possible when customizing and extending your Sales Cloud implementation:

  • All field types correspond to API data types; each field type has an API name, such as customfield_c.

    When writing a server script using the expression builder, use this _c field name to reference fields.

  • All field types correspond to your Web service XSD payload.

  • All field types correspond to your import ODI mappings when using Application Composer's import and export feature.

  • Most field types correspond to available fields that you can use to create a custom subject area for reporting. Exceptions include long text, check box, and formula fields.

Check Box Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding fields to both standard or custom objects. One field type that you can add to a custom or standard object is a check box field. A check box field is a field where users in the run time application can select a check box, indicating a true or false attribute of a record.

Check Box Field Properties

Create a check box field by specifying values for the common set of field properties, such as display label and field name.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Searchable

Constraints

Fixed Value

Default Value

Additional Check Box Field Specifications

Additional specifications for this field type include the following details:

  • Data type is VARCHAR2.

  • A object can have a total of 625 fields. Out of those 625 fields, 350 fields are reserved for text and check box fields, and fixed and dynamic choice lists.

Currency Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding new fields to both standard or custom objects. One field type that you can add to a custom or standard object is a currency field. A currency field is a field where users in the run time application can enter a currency amount.

Currency Field Properties

Create a currency field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the currency field type.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Display Width

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Searchable

Constraints

Indexed

Constraints

Fixed Value

Default Value

Expression

Default Value

The following properties are unique to only certain field types, including currency fields:


Field Property

Field Property Region

Minimum Value

Indicate the minimum numerical value that a user can enter into this field.

Constraints

Maximum Value

Indicate the maximum numerical value that a user can enter into this field.

Constraints

Exchange Date

Optionally specify the exchange date to use to calculate the currency conversion rate.

Tip

To use the system date when the record was created as the exchange date, specify the field's creation date as the exchange date.

Exchange Date

Additional Currency Field Specifications

Additional specifications for this field type include the following details:

  • Data type is NUMBER.

  • A object can have a total of 625 fields. Of those 625 fields, 200 fields are reserved for number, currency, and percentage fields.

    Note

    Each currency field uses two number type columns: one column stores the amount itself and the other column stores the currency conversion rate that is calculated from the entered amount's currency code to the corporate currency code.

  • A Sales Cloud object includes the following fields to assist with currency conversion. These fields are automatically added to a Sales Cloud object, provided that the object's application allows the creation of currency fields, and are derived from the application's corporate currency setup.

    • Currency code

      This is the currency code for all currency fields for an object.

    • Corporate currency code

    • Currency conversion rate type

    Currency conversion for a currency field occurs as follows:

    • At run time, the user enters the currency amount.

    • When the user saves the record:

      • The currency amount is stored using the currency code specified for the object.

      • The application calculates the currency conversion rate using the object's currency code, corporate currency code, currency conversion rate type, and the currency field's specified exchange date, if any.

        In addition to the entered amount, only the conversion rate that is calculated from the entered amount's currency code to the corporate currency code is stored.

      • If you later change either the currency code or exchange date, the application recalculates the currency conversion rate for the record.

Date Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding fields to both standard or custom objects. One field type that you can add to a custom or standard object is a date field. A date field is a field where users in the run time application can enter a date, or select a date from a calendar. This type of field has no time component.

Date Field Properties

Create a date field by specifying values for the common set of field properties, such as display label and field name.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Searchable

Constraints

Indexed

Constraints

Fixed Value

Default Value

Expression

Default Value

Additional Date Field Specifications

Additional specifications for this field type include the following details:

  • Data type is TIMESTAMP.

  • A object can have a total of 625 fields. Of those 625 fields, 50 fields are reserved for date and datetime fields.

  • When you create a custom subject area to be used for custom reporting, you can select fields with this type to use for date leveling.

Datetime Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding new fields to both standard or custom objects. One field type that you can add to a custom or standard object is a datetime field. A datetime field is a field where users in the run time application can enter a date, or select a date from a calendar, and enter a time of day. You can show the date or time, or both.

Datetime Field Properties

Create a datetime field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the datetime field type.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Searchable

Constraints

Indexed

Constraints

Fixed Value

Default Value

Note

When you select a literal date for this field's default value, the selected date appears in the international standard notation for date and time of day; however, at run time, the date and time of day are displayed according to the user's preferences.

Expression

Default Value

Additional Datetime Field Specifications

Additional specifications for this field type include the following details:

  • Data type is TIMESTAMP.

  • A object can have a total of 625 fields. Of those 625 fields, 50 fields are reserved for date and datetime fields.

  • When you create a custom subject area to be used for custom reporting, you can select fields with this type to use for date leveling.

  • This field type supports time zone conversion.

Dynamic Choice Lists: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding new fields to both standard or custom objects. One field type that you can add to a custom or standard object is a dynamic choice list. A dynamic choice list is a field that contains a list of values which are populated from the actual data of another object. For example, you might want to expose on a user interface page a dynamic choice list which lets users specify the account that they are logging a help request against. In this example, the Account Name choice list is a field that you are adding to the help request object, but the list of values is populated by actual names from the account object.

When creating dynamic choice lists, note the following:

  • Review the common set of field properties, as well as the dynamic choice list-specific properties, that you must specify.

  • Review the options available in the List Data Source, Additional List Display Values, and Additional List Search Fields regions.

  • Understand how a dynamic choice list results in the implicit creation of a relationship.

Note

  • When you are ready to add this dynamic choice list to a page, note that you cannot add dynamic choice lists to the local search region of a custom work area.

  • You must create a Select and Search picker for a custom object, if you also create a dynamic choice list that is based on the same custom object.

Dynamic Choice List Properties

Create a dynamic choice list by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the dynamic choice list field type.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Display Width

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Searchable

Constraints

The following properties are unique to only certain field types, including dynamic choice lists:


Field Property

Field Property Region

Related Object

List Data Source

List Selection Display Value

List Data Source

Data Filter

List Data Source

Additional List Display Values

Additional List Display Values

Additional List Search Fields

Additional List Search Fields

Using the List Data Source, Additional List Display Values, and Additional List Search Fields Regions

When defining a dynamic choice list, use the following regions to determine what data will display in the list of values at run time.

  • List Data Source region

    This is a screenshot of the List Data Source region, which you set up when you define a dynamic choice list custom field.

    • Related Object

      The values in a dynamic choice list are populated from another object's data. Select the related object first, then use the List Selection Display Value choice list to select the related object's field that you want to expose as a field for your own object. Selecting the related object is possible only during field creation.

      Note

      The set of objects that are available for selection is constrained to top-level objects only. You cannot select a child object as a related object.

      In our example, the related object would be Account.

      Tip

      Once you create a dynamic choice list field, you can easily recognize the choice list's related object from the Fields page. The Fields page displays summaries of both standard and custom fields for the selected object. If a dynamic choice list was created, then the Type column includes the related object. In our example, the field type would be Choice List (Dynamic) <Account>.

    • List Selection Display Value

      The List Selection Display Value choice list is the related object's field that is displayed within the dynamic choice list as the first column at run time. This is the primary field on the related object that your users will use to make the appropriate selection. In our example, the field might be something like Name.

    • Data Filter

      You can further refine the set of data that appears within the dynamic choice list at run time by using data filters.

      In our example, we could filter out any accounts outside a particular region.

  • Additional List Display Values region

    This is a screenshot of the Additional List Display Values region, which you set up when you define a dynamic choice list custom field.

    You can further refine the look and feel of the dynamic choice list by selecting additional fields to display in the choice list.

    Use the Additional List Display Values shuttle to include additional related object fields in the dynamic choice list at run time. These additional fields assist your users in making a selection from the choice list. The shuttle does not include the field that you already selected in the List Selection Display Value choice list.

    There is no limit on the number of additional fields that you can select.

  • Additional List Search Fields region

    This is a screenshot of the Additional List Search Fields region, which you set up when you define a dynamic choice list custom field.

    You can indicate which additional related object fields can be added as search criteria in the dynamic choice list's Search and Select dialog.

    Use the Additional List Search Values shuttle to include additional related object fields in the dynamic choice list's Search and Select dialog, accessed using the Search... link at run time. The shuttle does not include the field that you already selected in the List Selection Display Value choice list.

    There is no limit on the number of additional fields that you can select.

Implicit Relationship Creation

When you create a dynamic choice list for an object based on a related object, you are implicitly creating a one-to-many foreign key relationship where the current object is the "many" object and the related object is the "one" object. This implicit creation of a relationship lets you later add a related object subtab for the "many" object on the "one" object's details page. You can view these implicitly created choice list relationships on the Relationships page.

In the previous example of making a list of accounts available for selection for a help request, an account can be tied to multiple help requests. The relationship that is created is a one-to-many relationship between the account and help request objects, which enables users to store an account identifier in the help request object's table. In this relationship, the account object is the source object and the help request object is the target object. If a source object is ever deleted from the system, then at run time, the dynamic choice list will have no values in it.

Later, you might want to expose a related object subtab on the account details page which shows, for a single account, all the help requests that are related to it. You can create this related object subtab because the relationship was already created when you created the dynamic choice list.

Note

Generally, the dynamic choice list that you create results in the implicit creation of a choice list relationship. The exception is if you create a dynamic choice list between a Sales Cloud object and a common object: resource, customer contact profile, account, address. In such cases, relationships are not implicitly created.

Additional Dynamic Choice List Specifications

Additional specifications for this field type include the following details:

  • Data type is VARCHAR2 (1500).

  • A object can have a total of 625 fields. Out of those 625 fields, 350 fields are reserved for text and check box fields, and fixed and dynamic choice lists.

Fixed Choice Lists: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding new fields to both standard or custom objects. One field type that you can add to a custom or standard object is a fixed choice list. A fixed choice list is a field that contains a list of static values which are populated from FND lookup types. At run time, your users can select one or more values from this field, depending on the field's definition.

Fixed Choice List Properties

Create a fixed choice list by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the fixed choice list field type.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Display Width

Note

The size of the field depends on the longest value of the strings in the choice list.

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Searchable

Constraints

Fixed Value

Note

You cannot set a default value for any fixed choice list that is constrained by another fixed choice list.

Tip

If this choice list allows multiple values, you can still write an expression to preselect multiple values by default. For example, if the field is comprised of three lookup codes with (Code,Label) of (S,Small),(M,Medium),(L,Large),(XL,Extra Large), then to preselect the Small and Extra Large selections by default, set the default value to the literal string (without quotes): S,XL.

Default Value

The following properties are unique to only certain field types, including fixed choice lists:


Field Property

Field Property Region

Display Type

Indicate if your users can select only one value, or multiple values, from the choice list at run time. Selecting the display type is possible only during field creation.

Appearance

Lookup Type

List of Values

Constrain List by Parent Field Value Selection

List of Values

Using the List of Values Region

The values in a fixed choice list are populated from FND lookup types. Select the lookup type whose values you want to display in this choice list. Selecting the lookup type is possible only during field creation.

Or, create a new lookup type and add new values to it. You can also enter a lookup type and select the Edit icon to modify the existing values.

The set of FND lookup types that are available for selection is constrained to those lookup types that are related to this fixed choice list's object (via product code), as well as all custom lookup types that have been created for your Sales Cloud implementation.

This is a screenshot of the List of Values region, which you can configure when defining a fixed choice list.

You can constrain the actual values that display in this fixed choice list at run time by relating this fixed choice list to a parent fixed choice list. The value selected in the parent fixed choice list drives the values that display in this fixed choice list. For example, you might want your users to see two choice lists on a desktop page where they can create a trouble ticket: one choice list for specifying the trouble ticket type and one choice list for specifying the trouble ticket area. If a user selects Hardware from the Type choice list, then the Area choice list should contain a list of only hardware options against which the trouble ticket can be logged.

To do this, select the Constrain List by Parent Field Value Selection check box, select the parent field, and then map the values between the parent lookup type and this field's lookup type.

This is a screenshot of the Edit Value Map window, where you can map the values between the parent lookup type and this field's lookup type.

Note

The Constrain List by Parent Field Value Selection check box is available for selection only during field creation, and only if at least one other fixed choice list, which is a single-select choice list, has been defined.

After field creation, however, you can update the mapping between lookup values.

To implement the previous example:

  1. Define the Type fixed choice list.

  2. Define the Area fixed choice list.

  3. Select the Constrain List by Parent Field Value Selection check box and select the parent field, Type.

  4. Finally, map the values between the Type and Area lookup types.

    For example, map all relevant hardware values in the Area lookup type's set of values, such as desktop and laptop, to the value of Hardware in the Type's lookup type.

    Note

    You cannot set a default value for any fixed choice list that is constrained by another fixed choice list.

Additional Fixed Choice List Specifications

Additional specifications for this field type include the following details:

  • Data type is VARCHAR2 (1500).

  • A object can have a total of 625 fields. Out of those 625 fields, 350 fields are reserved for text and check box fields, and fixed and dynamic choice lists.

Formula Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding fields to both standard or custom objects. One field type that you can add to a custom or standard object is a formula field. A formula field is a field that is calculated in the run time Sales Cloud application using the Groovy-based expression included in the formula field's definition. For example, write an expression to calculate an employee's annual bonus amount.

Formula Field Properties

Create a formula field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the formula field type.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Display Width

Appearance

Name

Name

Description

Name

The following properties are unique to only certain field types, including formula fields:


Field Property

Field Property Region

Formula Type

Specify the field's data type, such as text, number, or date. The type can be specified only during field creation.

Field Value Type

Display Type

If the formula type is Text, then indicate if you want this formula field to render in the run time application as a simple text box. Or, indicate if the field should allow multiple lines where text can wrap.

Appearance

Depends On

Constraints

Using the expression builder and the Depends On Choice List

Use the Depends On choice list to indicate if the field should be automatically recalculated (using the expression you write) if another field's value changes.

This is a screenshot of the Constraints region, which you set up when defining a formula field.

Note

The Depends On choice list includes a list of fields that belong to the same object. If you want this formula field to automatically recalculate if the value of another field on a different object changes, then you must write a server script.

Use the expression builder to write an expression that calculates the field's value at run time.

This is a screenshot of the expression builder.

For example, if your expression calculates the value of an employee's annual bonus amount, then you could set the expression to automatically recalculate that amount if the employee's salary changes. Whenever the salary changes, the bonus field immediately reflects the new bonus amount without your users having to refresh the employee's record.

In another example, if your expression determines the right customer phone number to use for an opportunity, then you could set the expression to automatically reset the phone number if the opportunity's customer account changes. Whenever the customer account changes, the phone number field immediately reflects the new phone number without your users having to refresh the opportunity record.

Additional Formula Field Specifications

Additional specifications for this field type include the following details:

  • Data type is set by the Formula Type property.

  • The formula field type is not supported by custom subject areas. This means that you cannot add formula fields to a custom report.

  • You cannot search on a formula field.

  • A formula field is a computed attribute, and exists only at run time. This is a transient type of attribute which does not persist in the database as a table column. Hence, there is no maximum number of formula fields for an object.

Joins and Join Fields: Explained

A join is a relationship between an object and its related object. Joins let you display a related object's fields on an object's work area. Before you can add related object fields to an object's work area, however, you must register those fields, either custom or standard, by creating join fields. (Join fields are not provided automatically for you.) For example, the Sales Account object and the Household object are related objects by default and are already delivered with a join. You can display Household object fields in the Sales Account user interface, but only if you first register those fields as join fields for the Sales Account object.

Joins

Joins are view links to related top-level objects in Application Composer.

Joins are delivered by default for these objects:

  • Opportunity

  • Partner

  • Product Group

  • Sales Account

  • Sales Lead Contact

To view the joins available for an object, expand an object and click the Joins node. For example, select the Customer Center application, expand the Sales Account object, and click the Joins node.

Tip

  • Click the join name to navigate to the Join Fields page, where you can register join fields.

  • Select the join row and click Edit to navigate to the read-only Join Specification page, where you can review details about the join.

Note

You cannot create joins or edit existing joins.

Join Fields

Joins are delivered without join fields. Before you can add related object fields from a join to an object's work area, you must select the related object fields that you want to display, and then register them as join fields.

Once you have registered a related object field as a join field, you can then show or hide those fields on an object's work area by using the configuration pages available from the object's Pages node.

Note

Join fields are not available for selection in the local search region; however, you can still filter the records that display in an object's summary table by using the Query By Example feature. At run time, click the Query By Example icon on the table's toolbar, and enter a value for the join field column.

Refer to the worked example related topic for a detailed procedure that describes how to register join fields for the Sales Account object and add those fields to the Customer Overview.

Note

Fields configured for an object as a join field do not appear in file-based import and bulk export.

Join fields are computed attributes, and exist only at run time. This is a transient type of attribute which does not persist in the database as a table column. Hence, there is no maximum number of join fields for an object.

Adding Join Fields to the Sales Account Object: Worked Example

In this example scenario, you will add the Group Type field from the Household object to the Sales Account object. Before you can do this, you must first navigate to the join that exists between the Sales Account object and the Household object, and register the Group Type field as a join field.

Adding a Join Field to the Sales Account Object

Before you can add the field to the Sales Account summary table, you must register that field as a join field, even if you create a custom field.

  1. In Application Composer, select the Customer Center application, navigate to the Sales Account object, and then click the Joins node.
  2. On the Joins page, click the join name SalesAccountToGroupJoin. (The Household object was previously known as the Group object.)

    The Join Fields page opens.

  3. On the Join Fields page, click Create.

    The Create Join Fields page opens.

    Sales Account Joins Page

  4. On the Create Join Field page, create a join field called Group Type.

    After you click Save and Close, you return to the Join Fields page.

Adding the Join Field to the Customer Overview Page

After you create a join field, you can add it to the Customer Overview page so your users can see the field at run time.

  1. Navigate to the Sales Account object, and then click the Pages node.
  2. Click the Edit Summary Table link. In the Available Fields list, select Group Type - Join Field and add it to the Selected Fields list.

    Tip

    You can adjust the placement of the new column right or left in the table by moving the join field up or down in the Selected Fields list.

    In the Available Fields list, select Group Type - Join Field and add it to the Selected Fields list.

  3. Click Save and Close.
  4. From the Navigator menu, click Customers.

    The new Group Type column now appears in the Sales Accounts summary table on the Customer Overview page.

    The Group Type column is now in the Sales, Customers, Overview, Sales Accounts, search results table.

Adding the Join Field to the Local Search Region

Next, add your new join field as a column in the local search region of the Customer Overview page, so your users can see the field at run time.

  1. Navigate to the Sales Account object, and then click the Pages node.
  2. Click the Edit Local Search link.
  3. In the Available Fields list, select your new join field and move it to the Selected Fields list.

    The join field appears on the Sales Account user interface.

    Tip

    You can adjust the placement of the new column right or left in the table by moving the join field up or down in the Selected Fields list.

    Move Group Type - Join Field from the Available Fields list to the Selected Fields list.

    The following figure shows the GroupType join field added to the Customer Overview page.

    This figure shows the new join field added to the Customer Overview page.

Long Text Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding fields to both standard or custom objects. One field type that you can add to a custom or standard object is a long text field. A long text field is a field where users in the run time application can enter a combination of letters, numbers, or symbols. This field type supports 32,000 characters.

Long Text Field Properties

Create a long text field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the long text field type.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Display Width

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Fixed Value

Default Value

Expression

Default Value

The following properties are unique to only certain field types, including long text fields:


Field Property

Field Property Region

Display Type

Indicate if you want this text field to render in the run time application as a simple text box. Or, indicate if the field should allow multiple lines where text can wrap, or where the user can enter carriage returns.

Appearance

Additional Long Text Field Specifications

Additional specifications for this field type include the following details:

  • Data type is CLOB.

  • A object can have a total of 625 fields. Of those 625 fields, 25 fields are reserved for long text fields.

  • The long text field type is not supported by custom subject areas. This means that you cannot add long text fields to a custom report.

Number Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding fields to both standard or custom objects. One field type that you can add to a custom or standard object is a number field. A number field is a field where users in the run time application can enter a number.

Number Field Properties

Create a number field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the number field type.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Display Width

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Searchable

Constraints

Indexed

Constraints

Fixed Value

Default Value

Expression

Default Value

The following properties are unique to only certain field types, including number fields:


Field Property

Field Property Region

Decimal Places

Specify how many numbers can be entered and displayed to the right of the decimal point. If at run time, a user enters more numbers after the decimal point, then Application Composer rounds up (using the tie-breaking rule, round half up) to derive the field's value.

For example, if you enter 2 for the number of decimal places, then at run time, an entry of 4.986 is displayed as 4.99.

Constraints

Maximum Length

Specify how many numbers a user can enter in the field. This number should be greater than or equal to one and less than or equal to 38.

During field creation, consider how this property interacts with these other field properties:

  • Display Width

    If you set a maximum length that is longer than the display width, then users have to scroll inside the field at run time to see the number in this field.

  • Decimal Places

    Maximum Length - Decimal Places = the number of digits that can appear to the left of the decimal point.

    Do not set a maximum length that is shorter than the number of decimal places.

Constraints

Minimum Value

Indicate the minimum numerical value that a user can enter into this field.

Constraints

Maximum Value

Indicate the maximum numerical value that a user can enter into this field.

Constraints

Additional Number Field Specifications

Additional specifications for this field type include the following details:

  • Data type is NUMBER.

  • A object can have a total of 625 fields. Of those 625 fields, 200 fields are reserved for number, currency, and percentage fields.

  • Leading zeros are removed.

Percentage Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding fields to both standard or custom objects. One field type that you can add to a custom or standard object is a percentage field. A percentage field is a field where users in the run time application can enter a percentage. Application Composer automatically adds the percent sign to the number.

Percentage Field Properties

Create a percentage field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the percentage field type.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Display Width

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Searchable

Constraints

Indexed

Constraints

Fixed Value

Default Value

Expression

Default Value

The following properties are unique to only certain field types, including percentage fields:


Field Property

Field Property Region

Decimal Places

Specify how many numbers can be entered and displayed to the right of the decimal point. If at run time, a user enters more numbers after the decimal point, then Application Composer rounds up (using the tie-breaking rule, round half up) to derive the field's value.

For example, if you enter 2 for the number of decimal places, then at run time, an entry of 4.986 is displayed as 4.99.

Constraints

Maximum Length

Specify how many numbers a user can enter in the field.

During field creation, consider how this property interacts with these other field properties:

  • Display Width

    If you set a maximum length that is longer than the display width, then users will have to scroll inside the field at run time to see the amount in this field.

  • Decimal Places

    Maximum Length - Decimal Places = the number of digits that can appear to the left of the decimal point.

    Do not set a maximum length that is shorter than the number of decimal places.

Constraints

Additional Percentage Field Specifications

Additional specifications for this field type include the following details:

  • Data type is NUMBER.

  • A object can have a total of 625 fields. Of those 625 fields, 200 fields are reserved for number, currency, and percentage fields.

  • Application Composer automatically adds the percent sign.

Record Type Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding new fields to both standard or custom objects. One field type that you can add to a custom or standard object is a record type field. A record type field is a field that contains a list of static values which are populated from FND lookup types. This particular type of field is useful, because you can associate each choice list value with a role or a page layout.

Why Use a Record Type Field?

Create a record type field, so that you can associate each choice list value with a role or a page layout. This makes a record type field more powerful than a fixed choice list field or a dynamic choice list field.

Note

You can create only one record type field per object.

You can:

  • Associate each choice list value with a role. You do this while you are creating the field.

    At run time, the field's available list of values are constrained according to the user's role.

  • Associate each choice list value with a page layout. You do this by adding the field to a simplified page layout, after you have created the field.

    At run time, the system assesses the record type value selected by your user to determine which layout to display.

Record Type Field Properties

Create a record type field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the record type field type.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Display Width

Note

The size of the field depends on the longest value of the strings in the choice list.

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Searchable

Constraints

Fixed Value

Default Value

The following properties are unique to only certain field types, including record type fields:


Field Property

Field Property Region

Lookup Type

List of Values

Available Record Types

Indicate the record type values that each enterprise duty role has access to.

For example, perhaps the sales representative can see only selected record type values, but the sales manager can see all the record type values.

Roles

Default Record Type

Indicate the record type value that each role will see by default at run time.

Roles

Using the List of Values Region

The values in a record type field are populated from FND lookup types. Select the lookup type whose values you want to display in this choice list. Selecting the lookup type is possible only during field creation.

Or, create a new lookup type and add new values to it. You can also enter a lookup type and select the Edit icon to modify the existing values.

The set of FND lookup types that are available for selection is constrained to those lookup types that are related to this record type field's object (via product code), as well as all custom lookup types that have been created for your Sales Cloud implementation.

Additional Record Type Field Specifications

Additional specifications for this field type include the following details:

  • Data type is VARCHAR2 (1500).

  • One record type field is allowed per object, and it will be one of the 350 fields reserved for text and check box fields, and fixed and dynamic choice lists. A record type field is not required for an object, however.

  • You can create a record type field, only if the object already has a work area. If the object's work area has not yet been created, then you must create the work area first, before you can create the record type field.

Text Fields: Explained

Using Application Composer, you can extend an Oracle Sales Cloud application's object model by adding new fields to both standard or custom objects. One field type that you can add to a custom or standard object is a text field. A text field is a field where users in the run time application can enter a combination of letters, numbers, or symbols.

Text Field Properties

Create a text field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the text field type.

The following properties are common across multiple field types:


Field Property

Field Property Region

Label

Appearance

Help Text

Appearance

Display Width

Appearance

Name

Name

Description

Name

Required

Constraints

Updateable

Constraints

Searchable

Constraints

Indexed

Constraints

Fixed Value

Default Value

Expression

Default Value

The following properties are unique to only certain field types, including text fields:


Field Property

Field Property Region

Display Type

Indicate if you want this text field to render in the run time application as a simple text box. Or, indicate if the field should allow multiple lines where text can wrap, or where the user can enter carriage returns.

Appearance

Maximum Length

Indicate the maximum number of characters that a user can enter in the field. You can set a maximum length of 1500 characters. If the field is a multiline field, then carriage returns are permitted and count as characters against the total.

Constraints

Minimum Length

Indicate the minimum number of characters that a user can enter into the field.

Constraints

Additional Text Field Specifications

Additional specifications for this field type include the following details:

  • Data type is VARCHAR2 (1500 char).

  • A object can have a total of 625 fields. Out of those 625 fields, 350 fields are reserved for text and check box fields, and fixed and dynamic choice lists.

Defining Pages: Explained

After you extend an Oracle Sales Cloud application's object model using Application Composer, your next step is to expose those new objects and fields to users. To expose new objects and fields to users on desktop pages, navigate to the object's Pages node and select the Desktop Pages tab. This tab lets you create new pages and customize existing pages. Customizing and creating Sales Cloud desktop pages is a simplified process because the pages available to display an object and its fields are limited to a set of page types: every top-level Sales Cloud object has an overview page, a creation page, and a details page, collectively known as a work area.

Note

You can also expose new objects and fields in mobile applications using the Mobile Pages tab. And, you can expose new fields in an alternative set of simplified user interface pages, if available for a standard object, using the Simplified Pages tab.

After you create a custom object, you can create its corresponding work area by using the work area wizard, available from the Desktop Pages tab. After a work area is created, the Desktop Pages tab provides links to work area configuration pages, which you can use to add or remove fields for display. This combination of page types, configuration pages, a wizard-driven page creation process, and the ability to add links to the Navigator menu means that you can quickly and easily expose custom object model extensions to your users.

Before you begin to customize or create new pages for a Sales Cloud application, review the following aspects of the Application Composer desktop page creation process:

  • Understanding Page Types

  • Using the Pages Overview Page

  • Defining Pages

  • Creating a Work Area

  • Object Security on Pages

  • Using Page Composer to Customize Pages

Understanding Page Types

Every top-level Sales Cloud object can be displayed on a set of standard page types or in the regional area: the regional search in the regional area, an overview page, a creation page, and a details page.

  • Regional Area

    The regional area is located on the left side of the page and includes a search pane. You can customize the regional search pane by specifying the fields to display.

  • Overview page

    The overview page provides a list of records for an object and is the starting point in a Sales Cloud application for users to view and manage data. This page is where you can search for existing records and create new records. Users access an object's overview page from the Navigator menu at run time.

    Note

    Only top-level objects have an overview page. If an object was created as a child to another object, then the child does not have an overview page.

    The overview page includes two regions, each of which has its own configuration page:

    • Local search region

      The local search region is displayed above the summary table. Users can enter search criteria to refine the list of records in the summary table and then save this list as a saved search in the local search region.

    • Summary table

      The summary table includes a list of the object records. Depending on the security setup, users can create a record, delete a record, or drill down into an existing record.

      Tip

      Optionally, define saved searches that users can select at run time to constrain the list of records displayed in the summary table.

      To create new saved searches for your users, navigate to the run time search page where you want to create your saved search, and access Page Composer using the Administration menu. Then, enter and execute your search, and save it using the Save button under the search criteria in the application. You can also edit the saved searches that were created in Application Composer in earlier releases, by navigating to the Saved Search node for a custom or standard object.

  • Creation page

    The creation page is the page where users can create new records for an object. Depending on the security setup, users access the creation page by clicking the New icon or by selecting the New menu item from the Actions menu on the summary table's toolbar.

  • Details page

    The details page is the page where users can view more details about an object. Depending on the security setup, users access the details page by clicking the Edit icon or by selecting the Edit menu item from the Actions menu on the summary table's toolbar. Users can also access the details page by clicking the object record name itself in the summary table.

    The details page can include both a default summary and a detailed summary. The default summary includes the primary object fields and is always displayed to users. The detailed summary includes additional fields for an object. You cannot add the same field to both the default and detailed summaries.

    The details page can also display information related to the object record in subtabs. For example, the details page for an opportunity could include a subtab that lists customer contacts or previous orders.

Note

Some Sales Cloud objects, known as common objects, do not have a standard work area. These include common components (note, interaction, task) and common objects (resource, customer contact profile, account, address).

Using the Pages Overview Page

The Pages overview page in Application Composer provides an overview of the set of standard pages for an object.

Overview of the set of standard pages for an object

To access the Pages overview page:

  1. Select an application on the main Overview page.

  2. Select a standard or custom object in the object tree.

  3. Select the Pages node.

    The object tree in Application Composer, with the Pages node selected for an object

    Note

    Only top-level objects have pages that you can configure. A child object does not exist outside the context of the parent object, and does not have its own work area.

From the Pages overview page, you can:

  • Create a new set of pages for an object, collectively known as a work area, if no set of pages has been created yet.

  • View the pages where the object is already exposed to users, and further customize those pages by adding or removing fields.

  • Create one or more subtabs to display on the object's Details page.

  • Create mobile application pages in Oracle Fusion Mobile Sales by using a wizard.

    Similar to the work area creation process, the creation process for mobile pages uses a wizard where you can select which custom fields and related objects to add to mobile pages. Select the Mobile Pages tab to access the mobile pages wizard.

  • Expose new fields in an alternative set of simplified user interface pages, if available for a standard object, by selecting the Simplified Pages tab.

    Note that the Simplified Pages tab displays only if a set of simplified pages exists for the standard object.

Defining Pages

Use configuration pages to specify which fields are displayed on the standard application pages for an object. After you create new objects and fields, navigate to the Pages overview page. The Pages overview page contains hyperlinks to the configuration pages for an object's existing work area. Use these configuration pages to customize the object's work area pages, for example add newly created fields to a creation page.

Note

If the Pages overview page does not contain these configuration page hyperlinks, then the object does not yet have a work area, and you must create one if you want the object to be visible to users at run time. If a standard object does not expose the same set of configuration page links that you see for a custom object, it is because the standard object supports additional page types unique to that object.

Use the configuration pages available from the Pages overview page as follows:

  • Navigator Menu

    For custom objects, specify the display label that appears in the Navigator menu at run time. For standard objects, use the Manage Menu Customizations task in the Setup and Maintenance work area to change the display label for standard object work areas.

    This is a screenshot of the Configure Navigator Menu page, one of the work area configuration pages in Application Composer.

  • Regional Pane

    Select which panes to display in the regional area. You can also specify if you want the regional area and individual panes to be expanded (or collapsed) by default.

  • Overview Page

    The overview page includes two regions, the local search and the summary table, and includes configuration pages for each.

    • Edit Local Search

      The following figure show the Edit Local Search region, one of the work area configuration pages in Application Composer.

      This figure show the Edit Local Search fields selection, one of the work area configuration pages in Application Composer.

      1. Select the fields that will be used to search in the local search region.

        Note

        Join fields are not available for selection in the local search region; however, you can still filter the records that display in an object's summary table by using the Query By Example feature. At run time, click the Query By Example icon on the table's toolbar, and enter a value for the join field column.

        The list of fields available for selection is displayed to you in a single column, although the local search is formatted as a region with two columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the first column again, and so on.

        Note

        During field creation, consider indexing any fields that you plan to display as search criteria for your custom objects.

        The following figure shows the Edit Local Search field operators which you can select as part of your configuration of the local search region.

        This figure shows the Edit Local Search field operators which you can select as part of your configuration of the local search region.

      2. For any field, you can select the following options:

        • Required: The user must include this field in a search at run time.

        • At Least One is Required: The user must include at least one of the selected fields in a search at run time.

        • Default Operator: The user can define each search field value by using one of the listed operator options. For example, you can specify that CreationDate is equal to or occurs before or after the date the user enters, or that Sales Name starts with a specific letter.

    • Edit Summary Table

      This is a screenshot of the Edit Summary Table page, one of the work area configuration pages in Application Composer.

      1. Select the fields that you want to display as columns in the summary table.

      2. Add custom actions or links to the summary table, if you previously created them.

  • Creation Page

    This is a screenshot of the Edit Creation Page page, one of the work area configuration pages in Application Composer.

    1. Select the fields that you want to display on the object's creation page.

      The list of fields available for selection is displayed to you in a single column, although the creation page is formatted as a page with three columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the third column, the fourth field you select is displayed in the first column again, and so on.

  • Details Page

    This is a screenshot of the Edit Details Page Summary Form page, one of the work area configuration pages in Application Composer.

    1. Select the fields that you want to display on the object's details page, including both the default summary and detailed summary regions.

      Tip

      Include the primary object fields in the default summary, since the detailed summary could be collapsed when users navigate to this page.

      The list of fields available for selection is displayed to you in a single column, although the details page is formatted as a page with three columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the third column, the fourth field you select is displayed in the first column again, and so on.

    2. Add custom buttons, links, and actions to the details page, if you previously created them.

    3. Select the Allow Attachments check box to enable the attachments feature on the run time details page, in the collapsible detailed summary.

    4. The Pages Overview page also lets you configure subtabs that display on the details page. Subtabs include information that is related to the object record. Adding subtabs to a details page is discussed in a related topic.

      If the object uses a tree rather than subtabs to display related pages, then you can configure tree nodes that you add to the object's tree. The information displayed in both subtabs and trees can be derived from other objects or from a source outside Oracle Sales Cloud. For more information on adding tree nodes to an object's tree, see the related topic on this subject.

  • Reusable Regions

    At run time, users can launch the Select and Add dialog box from a dynamic choice list field to search for and select a value. Users can use the dynamic choice list field at run time, and can launch the picker to limit their choices and more easily find and make the right selection. Use the Create Picker link or Edit Picker link to access the Search and Select picker dialog box for an object, which you can start from any dynamic choice list that is based on that object. In the Search and Select picker dialog box you can specify which fields you want to appear in the search region and in the search results table.

    Note

    If you create a dynamic choice list that is based on a custom object, you must create the picker for the same custom object.

    To create or edit a picker, use the following steps.

    1. Create or edit the dynamic choice list field for which you want to create a picker. In the Related Object field for that dynamic choice list, make sure that you have selected the correct object on which you want to base the dynamic choice list.

    2. On the Pages overview page, click Create Picker or Edit Picker.

      The Edit Picker page opens.

    3. In the Configure Picker Search list, select the fields that you want to appear in the search region.

    4. In the Configure Picker Table list, select the fields that you want to appear in the search results table.

    At run time, the user can select a value from the dynamic choice list field by using the Search and Select picker to find the right value among all the other values.

    1. Navigate to the object's work area for which you created the picker and dynamic choice list.

    2. In the Overview page, click a record to drill down to the details page.

      The following figure shows the details page for a custom object named Primary with a dynamic choice list field named Opportunity List.

      This figure shows the details page for an object named Primary with a dynamic choice list field named Opportunity List.

    3. Click the magnifying glass icon next to the dynamic choice list field to open the Search and Select picker dialog box.

      The following figure shows the Search and Select picker dialog box at run time.

      This figure shows the Search and Select picker dialog box at run time.

    The user can add the selected value in the dynamic choice list field by using the following steps:

    1. In the Search and Select picker dialog box, enter the search criteria for the field.

    2. Click Search.

    3. Select the record.

    4. Click OK.

      The value is populated into the dynamic choice list field.

    • Edit Regional Search

      Select the fields the user can search on using the search pane in the regional area.

      Edit Regional Search Page

      To display the entire regional search pane, check the Enable check box. Otherwise, the regional search shows only the selected fields.

      For any field, you can select the following options:

      • Required: The user must include this field in a search at run time.

      • At Least One is Required: The user must include at least one of the selected fields in a search at run time.

      • Default Operator: The user can define each search field value by using one of the listed operator options. For example, you can specify that Creation Date is equal to or occurs before or after the date the user enters, or that Sales Name starts with a specific letter.

Note

Because some Sales Cloud objects (common components and common objects) do not have a standard work area, the configuration pages available from their Pages overview page are different than described previously. For example, the common address object has configuration pages for customizing the overview page, creation page, and address details form. The common account object has configuration pages for customizing only the details form and create form.

When you customize pages for common objects, the changes you make are reflected across the multiple applications where the object is used, provided that the applications also share the same metadata repository.

Creating a Work Area

When first created, top-level custom objects do not yet have pages in a run time Sales Cloud application where those objects are exposed to users. For each custom object that you create, you must create the set of pages where the records that belong to the object will be exposed to users.

Application Composer uses a wizard to walk you through the creation of these pages, collectively known as a work area. For more information on creating a work area, see the related topic on this subject.

Do not create a work area for child objects.

Object Security on Pages

After you create custom objects and fields, you then expose them on pages for your users. By default, the object and its records are visible and can be edited only by a user who has the Application Composer duty role. Grant additional access manually for either an object or role, using Application Composer's security policy configuration pages.

The security options available to you for restricting access to custom objects, including child objects, are discussed in a related topic.

Using Page Composer to Customize Pages

After you create a set of new pages, or edit preexisting pages delivered by a Sales Cloud application, you cannot use Page Composer to edit those pages again.

Note

The exception is the customer profile in Customer Center. You can create and add new fields to the Sales Account region on the customer profile using Page Composer.

Creating a Work Area: Explained

When first created, custom objects do not yet have pages in a run time Sales Cloud application where those objects are exposed to users. After you create a top-level custom object, you must create a set of desktop pages, also known as a work area, for that object. Every Sales Cloud object can be displayed on a work area, which consists of an overview page, a creation page, and a details page. Application Composer employs a wizard approach to walk you through the creation of that object's work area. After you create the initial work area, you can always navigate to the object's Pages Overview page to continue to customize those desktop pages using work area configuration pages. You do not create a work area for child objects. To create and modify pages displayed on a mobile device, use the separate Mobile Pages wizard which is also available from the object's Pages Overview page.

Review these aspects of the work area creation process in Application Composer before you create a new work area for a custom object:

  • Using the work area wizard

  • Configuring the Navigator menu

  • Configuring the local search region

  • Configuring the overview and creation pages

  • Configuring the details page

Using the Work Area Wizard

Access the wizard on the Pages Overview page using the same navigation path that you use to configure pages in an existing work area. However, if a work area has not yet been created for an object, then hyperlinks to the work area configuration pages are not displayed. Instead, the Pages Overview page displays only a single hyperlink to launch the work area wizard.

This is a screenshot of how you first launch the work area wizard to create a new work area for a custom object

To access the work area wizard:

  1. Select an application on the main Overview page.

  2. Select a standard or custom object in the object tree.

  3. Select the Pages node.

    Note

    Only top-level objects have pages that you can configure. A child object does not exist outside the context of the parent object, and does not have its own work area.

  4. Select the hyperlink to launch the work area wizard.

Note

Use the work area wizard to create a work area.

Use the work area configuration pages to customize existing work area pages.

Configuring the Navigator Menu

As part of the work area creation for a custom object, you must specify the object label that appears in the Navigator menu at run time. The label you specify is what users will select to navigate to this work area.

This is a screenshot of how you configure the Navigator menu to display a custom object's work area.

On this page, you can also do the following:

  • Select a menu category under which the object label appears.

  • Adjust the position of Navigator menu items within the selected menu category.

    For example, move your newly created object label to appear at the top of the list.

After creating the work area for a custom object, the work area label automatically appears in the Navigator menu without your having to reauthenticate.

Note

Changing the object label on the Navigator menu is available in Application Composer only for custom objects. For standard objects, use the Manage Menu Customizations task in the Setup and Maintenance work area to change the display label for standard object work areas.

Extending Regional Search Parameters

Extending the Regional search is part of the first step in creating a work area. By adding custom parameters, you can expand the search parameters in the Regional area for both custom and standard objects in a Sales Cloud application at run time.

Each field can have one of the following properties:

  • Required: Set a field as required on the object search region. This field must be populated.

  • At Least one is required: Set at least one field as a required field or a collection of required fields. You must populate one field from this group.

  • Default Operator: Set an operator field that appears in object search as the default.

Configuring the Local Search Region

The local search region appears above the summary table on an object's overview page. In the configure search step, select the fields that you want to display as search criteria fields in the local search region. Adding fields to this region is optional.

The list of fields available for selection is displayed to you in a single column, although the local search region is formatted as a region with two columns.

Note

You cannot control the order in which the chosen fields are displayed in the local search region.

This is a screenshot of how you configure the local search area for a custom object.

Note

During field creation, consider indexing any fields that you plan to display as search criteria for your custom objects.

Configuring the Overview and Creation Pages

Select the fields that you want to display in the work area's overview page, and in the object's creation page.

This is a screenshot of how you configure the overview page and creation page, which appear in a custom object's work area.

  1. Select the fields that you want to display as columns in the summary table, on the object's overview page.

  2. Select the drilldown column for the summary table.

    The drilldown column is the column in the summary table that users can click to drill down to an object record's details page. You cannot change a summary table's drilldown column after the work area is created.

  3. Add custom actions and links to the summary table, if you previously created them.

  4. Select the fields that you want to display on the object's creation page.

    The fields that you select should include the object's required fields.

    The list of fields available for selection is displayed to you in a single column, although the creation page is formatted as a page with three columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the third column, the fourth field you select is displayed in the first column again, and so on.

Configuring the Details Page

Select the fields that you want to display on the object's details page, also known as the edit page.

Note

A details page can have subtabs, which include information that is related to the object record. For example, the details page for an opportunity could include a subtab that lists customer contacts or previous orders. To add subtabs to a details page, create the work area first, then navigate back to the Pages Overview page. Adding subtabs to a details page is discussed in a related topic.

  1. Select the fields that you want to display on the object's details page, including both the default summary and detailed summary regions.

    Tip

    Include the primary object fields in the default summary, since the detailed summary could be collapsed when users navigate to this page at run time.

    The list of fields available for selection is displayed to you in a single column, although the details page is formatted as a page with three columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the third column, the fourth field you select is displayed in the first column again, and so on.

  2. Add custom buttons, links, and actions to the details page, if you previously created them.

  3. Select the Allow Attachments check box to enable the attachments feature on the run time details page, in the collapsible detailed summary.

Subtabs: Explained

Every top-level Oracle Sales Cloud object has a details page as part of its work area. When configuring the details page, you can optionally display details that are related to the current object but derived from another object, or from another source outside the current Oracle Sales Cloud application altogether. You do this by adding subtabs to the details page, and specifying the source of subtab data. Add subtabs to a standard or custom object's details page from that object's Pages Overview page in Application Composer. This functionality is available for Simplified Pages also.

Review these aspects of the subtab creation process in Application Composer before you begin to add subtabs to an object's details page:

  • Using the Details page

  • Adding subtabs

  • Subtab types:

    • Child or related object subtabs

    • Context link subtabs

    • Common component subtabs

    • Web content subtabs

Note

Subtabs and tree nodes are two master/detail UI patterns which Oracle Sales Cloud applications support.

For custom objects, only subtabs are supported.

For standard objects that are already using tree nodes, such as the Sales Account Profile and Partner objects, additional details adopt the same tree node pattern. In other words, if a standard object uses a tree to display its related pages, then you would expose child or related objects, for example, as tree nodes instead of subtabs on a details page. Adding tree nodes is discussed in a related topic.

Using the Details Page

The details page is the page where users can view more details about an object. Depending on the security setup, users access the details page by clicking the Edit icon or by selecting the Edit menu item from the Actions menu on the summary table's toolbar. Users can also access the details page by clicking the object record name itself in the summary table.

The details page can include both a default summary and a detailed summary. The default summary includes the primary object fields and is always displayed to users. The detailed summary includes additional fields for an object. You cannot add the same field to both the default and detailed summaries.

The details page can also display information related to the object record in subtabs. For example, the details page for an opportunity could include a subtab that lists customer contacts or previous orders.

Adding Subtabs

Add a subtab to an object's details page from that object's Pages Overview page. The details page must exist already; you cannot add subtabs when first creating a work area.

To add a subtab to an existing details page:

  1. Select an application on the main Overview page.

  2. Select a standard or custom object in the object tree.

  3. Select the Pages node.

    Note

    Only top-level objects have pages that you can configure. A child object does not have its own work area.

  4. On the Pages Overview page, click the Create Subtab icon in the Details Page region to create one or more subtabs to display on the object's details page.

  5. Select the type of subtab you want to add.

    This is a screenshot of the Create Subtab page, where you select the type of subtab you want to add to an object's details page.

Tip

To hide subtabs that you previously added using Application Composer, use Page Composer.

Adding Subtabs to Simplified Pages

Add a subtab for a standard object user interface directly from the Simplified Pages tab, Details Page Layout region.

To add a subtab, navigate to the Create Subtab page and enter the details:

  1. Select an application in Application Composer.

  2. Select a standard object in the object tree.

    Note

    You cannot add subtabs to a custom object for Simplified pages.

  3. Select the Pages node.

  4. Click the Simplified Pages tab in the local area.

  5. Click the Edit icon in the Details Page Layout region.

  6. In the Edit Simplified Details page, click the Create icon at the bottom of the vertical tabs tray. The Create Subtab page appears.

    This figure shows the Create Subtab page.

    Create Subtab page.

Child or Related Object Subtabs

A relationship is a foreign key association between two objects. Using Application Composer, you can create a one-to-many relationship between two objects within the same application. Once relationships are created, you can expose the "many" objects on a subtab that is displayed on the "one" object's details page. For example, an account can have multiple service requests associated to it. To expose a list of service requests associated with a specific account as a subtab on the account's details page, you must first create a one-to-many relationship between the account and service request objects. In this example, the account is the source object and the service request is the target object. This relationship adds the account identifier to the service request object's table.

Application Composer lets you add a subtab to an object's details page for either a child object or for three types of related objects. These objects exist in four types of one-to-many relationships:

  • Parent child relationship

    Parent child relationships are implicitly created when a custom object is created as a child of a top-level object.

    For example, to enable the creation of a subaccount subtab on an account's details page, you would create the subaccount object as a child of the account object. This relationship adds the account identifier to the subaccount object's table.

  • Choice list relationship

    Choice list relationships are implicitly created between two objects when you create a dynamic choice list field.

    For example, to enable the creation of a department subtab on an employee's details page, you would create a dynamic choice list, HR Representative, for the department object where the choice list's related object is employee. Application Composer automatically creates the underlying relationship for you, where the employee is the source object and the department is the target object. This relationship adds the employee identifier to the department object's table, thus enabling the creation of a department subtab on an employee's details page. The subtab displays all departments that an HR representative can manage, since each HR representative can be in charge of multiple departments of a company.

  • Reference relationship

    Reference relationships are explicitly created between two top-level objects using the Create Relationships page.

    Using our previous example, perhaps you don't need to display an HR Representative choice list on a department desktop page, but you still want to add a department subtab to an employee's details page. In this case, manually create a reference relationship between the employee and department objects where the employee is the source object and the department is the target object. This enables the creation of the department subtab. Such a reference relationship, however, does not automatically create a corresponding HR Representative choice list for use on the department desktop page. In fact, once you manually create a relationship, you cannot reuse the relationship to create a choice list. This means that you should carefully consider the need for a choice list before you create a reference relationship.

  • Standard relationship

    Standard relationships are relationships that are already created between two standard objects by the Oracle Sales Cloud application.

To add a child or related object subtab to an existing details page:

  1. On the Pages Overview page, click the Create Subtab icon.

  2. Select Child or Related Object.

    This is a screenshot of the Create Subtab page, where you configure a new subtab for a child or related object.

  3. On the Child or Related Object subtab configuration page:

    1. Select the related object from the list of all related objects that is to be exposed on the subtab, and choose the subtab display label.

    2. Optionally hide the New and Delete buttons that appear on the subtab at run time.

      For child object subtabs, you can also optionally hide the Edit button.

    3. Select which fields and links you want to display on the subtab summary table at run time.

      You can configure fields and links for the main summary table which lists the child object records or related object records.

    4. Select which buttons you want to display on the subtab at run time.

      Note

      This region appears only if you previously created buttons for this object.

    5. Select which fields you want to display on the subtab detail form at run time.

      You can configure fields for the detail form that appears under the summary table. If the subtab's object is a child object, then users can enter child object data into this detail form at run time. Always include required fields in this section.

      If the subtab's object is a related object, then users can associate an existing record of the subtab object to the master object of the page. However, to create new related object records, users must do so in the object's own creation page.

Context Link Subtabs

A context link subtab displays a filtered list of records from any top-level object, where the filter is often based on the run time values from the current object. The object does not have to be related to the current object. Context link subtabs are read only.

To add a context link subtab to an existing details page:

  1. On the Pages Overview page, click the Create Subtab icon.

  2. Select Context Link.

    This is a screenshot of the Create Subtab page, where you configure a new context link subtab.

  3. On the Context Link subtab configuration page:

    1. Select the object that is to be exposed on the subtab, and choose the subtab display label.

    2. Optionally constrain the list of records displayed at run time using a set of search criteria for the selected object, whose run time values must match the current object record's run time values.

      Tip

      Values can be literal values, or derived from the run time values in the current object record, or from the run time values in the current object's parent record.

      If your search criteria includes a fixed choice list field, then you must specify the fixed choice list's run time value using the lookup code, not the lookup meaning.

    3. Select which fields you want to display on the subtab's read-only summary table at run time.

      You can configure fields for the main summary table which lists the child object records or related object records.

    4. Select which fields you want to display on the subtab's read-only detail form at run time.

      You can configure fields for the detail form that appears under the summary table.

Common Component Subtabs

A common component subtab adds a Notes, Tasks, Interactions or Appointments subtab to show a list of the selected components related to a custom, top-level object. Each component has a standard user interface (UI) that is shared across all Oracle Sales Cloud applications. To customize such a UI for all common components (other than Appointments), select the appropriate object under the Common application, then select the Pages node on the object's navigation tree to access the work area configuration pages.

At run time, users can access these subtabs and create a common component record that is tied to the object record. For example, a user can record a customer interaction on an service request record.

  • Notes

  • Tasks

  • Interactions

  • Appointments

To add a common component subtab to an existing details page:

  1. On the Pages Overview page, click the Create Subtab icon.

  2. Select Common Component.

    This is a screenshot of the Create Subtab page, where you configure a new common component subtab.

  3. On the Common Component subtab configuration page, select the type of common component you want to add to the details page as a subtab.

Web Content Subtabs

A Web content subtab exposes an external Web site right on an object's details page. The Web content is a result of the expression that you define which builds the intended URL.

For example, on the Contact details page, perhaps you want to add a Google map that shows the location of the contact. The Google Maps API expects the URL to be formatted in a certain manner. In this example, write an expression using the fields: Contact Address, Contact City and Contact State. Then, pass the URL to the Google Maps API.

To add a Web content subtab to an existing details page:

  1. On the Pages Overview page, click the Create Subtab icon to create one or more subtabs to display on the object's details page.

  2. Select Web Content.

    This is a screenshot of the Create Subtab page, where you configure a new Web content subtab.

  3. On the Web Content subab configuration page, enter the display label for the subtab, and then define the URL to retrieve the subtab's Web content.

    Optionally use the expression builder to build the URL expression that you need.

The expression you build should include the following:

  • Use the HTTP protocol.

  • Optionally include field values from the current object as parameters, or user variables.

  • Enclose static strings in double quotation marks.

    For example, "http://www.abc.com/".

For example:

def myURL1 = adf.util.GlobalEncodeField(ContactAddress_c)
def myURL2 = adf.util.GlobalEncodeField(ContactCity_c)
def myURL3 = adf.util.GlobalEncodeField(ContactState_c)
def myfinalURL = "http://maps.google.com/maps?hl=en&q=" + myURL1 + "+" + myURL2 + "+" + myURL3
return(myfinalURL)

Tree Nodes: Explained

Some Oracle Sales Cloud standard objects, such as the Sales Account and Partner objects, use a tree to display its related pages. When configuring an object's work area, you can optionally display details that are related to the current object by adding tree nodes to the object's tree, and specifying the source of tree node data. Tree node data can be derived from another object, or from another source outside the current Sales Cloud application altogether. Add a tree node to a standard object's tree from that object's Pages Overview page in Application Composer.

Review these aspects of the tree node creation process in Application Composer before you begin to add tree nodes to an object's tree:

  • Adding tree nodes

  • Tree node types:

    • Child or related object tree nodes

    • Context link tree nodes

    • Web content tree nodes

Note

Subtabs and tree nodes are two master/detail UI patterns which Oracle Sales Cloud supports.

For custom objects, only subtabs are supported.

For standard objects that are already using tree nodes, such as the Sales Account and Partner objects, additional details adopt the same tree node pattern. In other words, if a standard object uses a tree to display its related pages, then you would expose child or related objects, for example, as tree nodes instead of subtabs on a details page. Adding subtabs is discussed in a related topic.

Adding Tree Nodes

Add a tree node to an object's tree from that object's Pages Overview page.

To add a tree node to an object's tree:

  1. Select an application on the main Overview page.

  2. Select a standard object, either the Sales Account or Partner object, in the object tree.

  3. Select the Pages node.

    Note

    Only the top-level objects, Sales Account and Partner, let you add tree nodes.

  4. On the Pages Overview page, click the Create Tree Node icon to create one or more tree nodes to display on the object's tree.

  5. Select the type of tree node you want to add.

    This is a screenshot of the Create Tree Node page, where you select the type of tree node you want to add to an object's tree.

Child or Related Object Tree Nodes

A relationship is a foreign key association between two objects. Using Application Composer, you can create a one-to-many relationship between two objects within the same application. Once relationships are created, you can expose the "many" objects on a tree node that is displayed on the "one" object's tree. For example, a partner can have multiple contacts associated to it. To expose a list of contacts associated with a specific partner as a tree node on the partner's tree, you must first create a one-to-many relationship between the partner and contact objects. In this example, the partner is the source object and the contact is the target object. This relationship adds the partner identifier to the contact object's table.

Application Composer lets you add a tree node to an object's tree for either a child object or for three types of related objects. These objects exist in four types of one-to-many relationships, which are described in detail in the related topic about object relationships:

  • Parent child relationship

  • Choice list relationship

  • Reference relationship

  • Standard relationship

To add a child or related object tree node to an existing tree:

  1. On the Pages Overview page, click the Create Tree Node icon.

  2. Select Child or Related Object.

    This is a screenshot of the Create Tree Node page, where you configure a new tree node for a child or related object.

  3. On the Child or Related Object tree node configuration page:

    1. Select the tree node category and enter the tree node label.

    2. Select the related object from the list of all related objects that is to be exposed on the tree node page.

    3. Set the position of the new tree node.

    4. Optionally hide the New and Delete buttons that appear on the tree node page at run time.

      For child object tree node pages, you can also optionally hide the Edit button.

    5. Select which fields and links you want to display on the tree node page's summary table at run time.

      You can configure fields and links for the main summary table which lists the child object records or related object records.

    6. Select which buttons you want to display on the tree node page at run time.

      Note

      This region appears only if you previously created buttons for this object.

      You cannot add buttons to a tree node page for the Sales Account object.

    7. Select which fields you want to display on the tree node page's detail form at run time.

      You can configure fields for the detail form that appears under the summary table. If the tree node's object is a child object, then users can enter child object data into this detail form at run time. Always include required fields in this section.

      If the tree node's object is a related object, then users can associate an existing record of the tree node object to the master object of the page. However, to create new related object records, users must do so in the object's own creation page.

Context Link Tree Nodes

A context link tree node page displays a filtered list of records from any top-level object, where the filter is often based on the run time values from the current object. The object does not have to be related to the current object. Context link tree node pages are read only.

To add a context link tree node to an object's tree:

  1. On the Pages Overview page, click the Create Tree Node icon.

  2. Select Context Link.

    This is a screenshot of the Create Tree Node page, where you configure a new context link tree node.

  3. On the Context Link tree node configuration page:

    1. Select the tree node category and enter the tree node label.

    2. Select the object that is to be exposed on the tree node page.

    3. Set the position of the new tree node.

    4. Optionally constrain the list of records displayed at run time using a set of search criteria for the selected object, whose run time values must match the current object record's run time values.

      Tip

      Values can be literal values, or derived from the run time values in the current object record, or from the run time values in the current object's parent record.

      If your search criteria includes a fixed choice list field, then you must specify the fixed choice list's run time value using the lookup code, not the lookup meaning.

    5. Select which fields you want to display on the tree node page's read-only summary table at run time.

      You can configure fields for the main summary table which lists the child object records or related object records.

    6. Select which fields you want to display on the tree node page's read-only detail form at run time.

      You can configure fields for the detail form that appears under the summary table.

Web Content Tree Nodes

A Web content tree node page exposes an external Web site. The Web content is a result of the expression that you define which builds the intended URL.

For example, on the Contact tree node page, perhaps you want to add a Google map that shows the location of the contact. The Google Maps API expects the URL to be formatted in a certain manner. In this example, write an expression using the fields: Contact Address, Contact City and Contact State. Then, pass the URL to the Google Maps API.

To add a Web content tree node to an object's tree:

  1. On the Pages Overview page, click the Create Tree Node icon to create one or more tree nodes to display on the object's tree.

  2. Select Web Content.

    This is a screenshot of the Create Tree Node page, where you configure a new Web content tree node.

  3. On the Web Content tree node configuration page:

    1. Select the tree node category and enter the tree node label.

    2. Set the position of the new tree node.

    3. Define the URL to retrieve the tree node page's Web content.

      Optionally use the expression builder to build the URL expression that you need.

The expression you build should include the following:

  • Use the HTTP protocol.

  • Optionally include field values from the current object as parameters, or user variables.

  • Enclose static strings in double quotation marks.

    For example, "http://www.abc.com/".

For example:

def myURL1 = adf.util.GlobalEncodeField(ContactAddress_c)
def myURL2 = adf.util.GlobalEncodeField(ContactCity_c)
def myURL3 = adf.util.GlobalEncodeField(ContactState_c)
def myfinalURL = "http://maps.google.com/maps?hl=en&q=" + myURL1 + "+" + myURL2 + "+" + myURL3
return(myfinalURL)

Actions and Links: Explained

In Oracle Sales Cloud applications you can add actions, such as scripts, and buttons to detail pages, list pages, and so on. You can also create special fields, rendered as links, that are displayed with other fields throughout the application.

What are Actions and Links?

An action can be based on a script (a Groovy method that is defined on the object) or a URL. After you create an action, it can be exposed as a button or an option on the Actions menu. After you create a link, it can be selected as a field for display at run time.

A button can perform an action or navigate the user to another page in the run time application, or to another Web site. For example, you might want to provide a static link from an overview page to a corporate Web site. Or, you might want to include a button on a summary table, which users can click at run time to create a new type of record from a selected row, such as escalating an existing "trouble ticket" to a more severe "case" that can be managed separately.

Note

Do not create custom buttons to populate the mandatory or required fields on the UI. You must enter the values in the mandatory fields manually.

When configuring the work area for a standard or custom object, you can add custom actions or links to a page-level or task-level Actions menu or as a toolbar button. You can also manage the Actions menu by hiding or showing menu items, rearranging the action groupings or display sequence, and managing the toolbar by hiding or showing icons and buttons. You can also configure the Actions menu and buttons in the Create and Edit subtabs and tree nodes.

Adding Actions or Links

You add actions or links in two steps:

  1. Define an action or link for an object.

  2. Use Application Composer's work area configuration pages to add that action or link to an Overview page or Details page.

The following figure shows a button and a link added to the Sales Opportunities Overview page.

This image shows a button and a link added to the Sales Opportunities Overview page.

To define an action or link for an object:

  1. Select an application on the main Overview page.

  2. Select a standard or custom object in the object tree.

  3. Select the Actions and Links node.

To create a new script or URL:

  1. In the Create Action or Link page, enter a descriptive name in the Display Label field.

  2. For Type, select Action and, for Source, select Script or URL.

  3. In the Script region click the New icon.

The following figure shows the Create Action or Link page showing a static URL enclosed in double quotation marks.

This image shows the Create Action or Link page showing a static URL enclosed in double quotation marks.

If the source is a URL, you can enter a static URL, enclosed in double quotation marks. Or, you can define the URL by using the expression builder, which provides access to this object's fields to assist you in constructing the URL. If this object has a parent or relationship with a source object, then optionally change the context to access another object's fields for URL definition.

Any new functions that you create will be added to the Method Name choice list. If functions were already created for the object, then you can select one of them from the Method Name choice list. Object functions that are created elsewhere through other flows, such as server scripts, can also be used here.

To switch the context to the object's parent or related source object, for access to the object's fields for the URL definition, check the Select alternative context check box.

The following figure shows a script in the URL Definition window.

Shows a Script in the URL Definition window

If the source is a script, you can either select a predefined object function from the Method Name choice list, or create a new object function using the expression builder.

After you save actions or links, you can expose them on UI pages by configuring Application Composer options available in the Edit Summary Table page in the Pages node of an object.

The following figure shows a selected link and fields in the Edit Summary Table page in the Pages node for the Opportunity object.

This screenshot shows a selected button and fields in the Edit Summary Table page in the Pages node for the Opportunity object.

When choosing to display a link, you select it just as you select to display standard or custom fields. This is because, at run time, the UI displays the URL link as if it is a field in a table. Actions can be configured in potentially two places in the UI, on the toolbar as a button and in the Actions menu for a table. Depending on how you configure actions and links, in the run time summary table, you could see both the buttons and actions, or one, or none.

This is a screenshot of the Configure Summary Table: Actions regions, with options checked for the Show Create, Show Edit, and Show Delete options on the Action menu. It also shows a custom button and a custom action.

The figure above shows the Configure Summary Table: Actions region, with options checked for the Show Create, Show Edit, and Show Delete options on the Action menu. It also shows a custom button and a custom action.

After you define an action, you can then expose it as a button or an Actions menu option in a variety of locations:

  • Summary table on the overview page

  • Default summary on the details page

  • Summary table on a details page's subtab

  • Summary table on a tree node page for a child object

  • Revenue table on the details page for the opportunity object

The following figure shows an overview page with exposed Create, Edit, and Delete options and a custom Ask_Assistance option on the Actions menu. It also shows the custom toolbar button Ask_Assistance, and a custom table column.

This figure shows an overview page with exposed Create, Edit, and Delete options and a custom Ask_Assistance option on the Actions menu. It also shows the custom toolbar button Ask_Assistance, and a custom table column.

After you define a link for an object, you can add that link to a variety of locations in that object's work area. You can add a link wherever you can add a field. Possible locations include, but are not limited to:

  • As a column in the summary table on the overview page

  • Default summary on the details page

  • As a column in the summary table on a details page's subtab

  • In the detail form under the summary table on a details page's subtab

  • As a column in the summary table on a tree node page for a child object

  • As a column in the revenue table on the details page for the opportunity object

Saved Searches for Oracle Sales Cloud Objects: Explained

Important

In previous releases, Application Composer provided you with the ability to create and edit saved searches, available to your users at the site level. In the current release, you can only edit existing saved searches, since Page Composer also lets you create and edit saved searches at the site level.

Review these aspects of the saved search definition process in Application Composer before you begin to view or edit saved searches for Sales Cloud objects:

  • Saved searches at run time

  • Editing a saved search

Saved Searches at Run Time

The list of saved searches is available from the Saved Search choice list above the overview page's summary table.

Searches are displayed in alphabetic order, followed by the Personalize option.

The saved searches that you edit for an object are available to all users and roles with functional security access to the object's overview page.

Editing a Saved Search

You edit a saved search for an object on the object's Edit Saved Search page. You can edit saved searches only for top-level objects, because only top-level objects have overview pages in the run time Sales Cloud application. To create a new saved search, use Page Composer.

To edit a saved search for an object:

  1. Select an application on the main Overview page.

  2. Select a standard or custom object in the object tree.

  3. Select the Saved Searches node.

  4. Select the Saved Search that you want to edit from the summary table in the Saved Searches page and select Actions > Edit

  5. On the Edit Saved Search page for the object, you can modify the display label for the saved search.

    The display label is the label that appears in the Saved Search choice list.

  6. You cannot edit the Name field.

    The Name is automatically generated based on the specified display label at the time of creating the saved search. Spaces in the display label are converted to underscores in the Name. For example, if the display label is Top Ten Opportunities, then the Name is automatically generated as Top_Ten_Opportunities at the time of creating the saved search.

  7. Modify the search criteria.

    You can enter up to four search conditions using the following criteria:

    • Specify the matching criteria, All or Any.

      • All appends multiple conditions with an AND.

      • Any appends two conditions with an OR.

        If more than two conditions exist, then you cannot select Any.

    • Field Name

      Specify the object field who value you want to include as a search criterion.

      Long text and formula fields are not available for use in saved searches.

      Tip

      For better performance, the fields you include in a saved search should be indexed. You index a custom field when it's first created.

    • Operator

      Operator values available for selection are dependent upon the type of field selected.

      This table lists, for each field type, the operators that are available for selection, as well as the values that you can enter.


      Field Type

      Available Operators

      Available Values

      • Number

      • Check box

      • Percentage

      • Equal to

      • Greater than

      • Greater than or equal to

      • Is blank

      • Is not blank

      • Less than

      • Less than or equal to

      • Not equal to

      Enter a literal value.

      Note

      For percentage fields, divide the percentage by 100 to calculate the literal value you should enter as a search criterion. For example, to correctly use 150 percent in your saved search, you must enter 1.5.

      • Dynamic choice list

      • Text

      • Fixed choice list

      • Currency

      • Contains

      • Does not contain

      • Ends with

      • Equal to

      • Is blank

      • Is not blank

      • Not equal to

      • Starts with

      Enter a literal value.

      Tip

      For fixed choice list fields, you must enter the lookup code, not the lookup meaning.

      • Date

      • Date time

      • After

      • Before

      • Equal to

      • Is blank

      • Is not blank

      • Not equal to

      • On or after

      • On or before

      Enter:

      • Literal value

      • Date function

        Specify the number of days, months, or years after or before the current date.

    • Value

      The values that you specify are applied as the search criteria against the object records at run time.

      See the previous table.

Making Saved Searches Available to All Users: Procedures

You can use Page Composer to create saved searches that appear to all users at the site layer. In Oracle Sales Cloud simplified pages, saved searches are also known as saved lists.

Note

Create saved searches for all users at the site layer only. Do not use other layers, such as the role layer.

Creating Saved Searches for All Users

To create site-level saved searches:

  1. Navigate to the search component.

  2. Under your Settings and Actions, click Customize <Page Name> Pages to open Page Composer.

  3. Select the Site layer.

  4. In Design view, enter the search criteria.

  5. Click Search.

    Note

    You must perform the search before you save.

  6. Save the search component.

  7. Name your search and optionally select from these options:

    • Set as Default - the search criteria appear when users view the search component.

    • Run Automatically - the search criteria and results appear when users view the search component.

  8. Close the dialog box.

  9. Save and close Page Composer.

  10. Sign out and sign in again to refresh the current list of saved searches.

Editing Saved Searches for All Users

To delete, rename, or change the search options for a site-level saved search, perform the following steps:

  1. Navigate to the search component.

  2. Under your Settings and Actions, click Customize <Page Name> Pages to open Page Composer.

  3. Select the Site layer.

  4. In the Design view, select Personalize from the Saved Search list of values.

  5. Select a saved search, then you can:

    • Delete

    • Rename

    • Change search options

    Note

    You must perform the search before you save.

    Note

    You can't change the search criteria of a saved search in Page Composer. You can delete and then re-create it if you need to change the search criteria.

  6. Save the changes and close Page Composer.

  7. Sign out and sign in again to refresh the current list of saved searches.

Securing Custom Objects: Explained

After you create custom objects and fields, you then expose them on desktop pages for your users. Your next step is to control which users can access that object's data at run time. By default, the object and its records are visible and editable only to a default duty role specified by the application. Grant additional access manually using Application Composer's security policy configuration pages. A security policy specifies which users are authorized to access an object's data, and what type of access they have. For example, does a user have view only access, or can the user create and update an object's record, as well? Define security policies for an object by authorizing the roles whose users can access that object's data. Or, define security policies for a role by specifying access levels across multiple custom objects.

Review these aspects of the custom object security process in Application Composer before you begin to define your security policies:

  • Securing objects

  • Securing roles

  • Enabling function security and data security

  • Application Composer and the Oracle Authorization Policy Manager (APM)

  • Default security settings

Securing Objects

The object-centric Define Policies page displays a list of the enterprise-level duty roles which map to an Oracle Sales Cloud job role. Use this page to manage access to either a top-level or child custom object by specifying a security policy for one or more duty roles. When you do this, users with the corresponding roles can access the custom object and its data, depending on the security policies you define.

To access the object-centric Define Policies page:

  1. Select an application on the main Overview page.

  2. Select a custom object in the object tree.

  3. Select the Security node.

    Or, from the role-centric Define Policies page, select a custom object.

    This is a screenshot of the object-centric Define Policies page, which displays a list of the enterprise-level duty roles which map to a Sales Cloud job role.

From the object-centric Define Policies page, you can:

  • Enable function security for a role.

  • Enable data security for a role.

Securing Roles

The Role Security page displays a list of the enterprise-level duty roles, which map to a Sales Cloud job role. Select a role and click the Define Policies button to navigate to the role-centric Define Policies page, which displays a list of the custom objects for your Sales Cloud implementation. Use this page to manage access for users with the corresponding role by specifying a security policy for one or more top-level or child custom objects. When you do this, users with the corresponding role can access the custom objects and related data, depending on the security policies you define.

To access the role-centric Define Policies page:

  1. Select an application on the main Overview page.

  2. Select the Role Security node from the Common Setup pane.

    Or, select the Role Security hyperlink in the local area of the main Overview page.

    Or, from the object-centric Define Policies page, select a role.

    This is a screenshot of the Role Security page displays a list of the enterprise-level duty roles, which map to a Sales Cloud job role.

  3. Click the Define Policies button.

    This is a screenshot of the role-centric Define Policies page, which displays a list of the custom objects for your CRM implementation.

From the role-centric Define Policies page, you can:

  • Enable function security for a custom object.

  • Enable data security for a custom object.

  • View related roles, if any.

    If a related role is displayed next to an object, then the selected role is inheriting its access to that object from the related role. You can drill down into the related role to view its security policies.

Enabling Function Security and Data Security

A security policy specifies the type of access to an object and its records that users with the corresponding roles have. Access includes both function security as well as data security. Security settings are the same whether you are defining a security policy for an object or a role.

On the Define Policies page, the first four columns in the table manage function security, which applies to the object as a whole:

  • Create

    Users with the corresponding role can create a record of the object.

  • View

    Users with the corresponding role can view the object's work area pages.

  • Update

    Users with the corresponding role can update a record of the object.

  • Delete

    Users with the corresponding role can delete a record of the object.

The next two columns in the table manage data security.

  • View All

    Users with the corresponding role can view the object's records.

  • Update All

    Users with the corresponding role can update the object's records.

Tip

When clicking View All or Update All, the corresponding View and Update function security check boxes are automatically selected.

Wait for the page to refresh to confirm all your selections.

Note

To let users view or update records at run time, you must enable both function security as well as data security for an object. To let users create records, you only have to enable function security.

Application Composer and the Oracle Authorization Policy Manager (APM)

Oracle Authorization Policy Manager (APM) manages the security policies that control access based on roles. However, you define the security policies for custom objects in Application Composer's object-centric and role-centric Define Policies pages. This is outside APM.

Since you define the security policies outside APM, you cannot later modify the security policies within APM. Instead, modify all security policies for custom objects using only Application Composer.

Default Security Settings

By default, top-level custom objects are visible and editable only to users with a default duty role specified by a Sales Cloud application. You must manually grant additional access to other duty roles, if desired. For example, if you create a custom object in the Sales application, then only users with the default duty role specified by Sales are automatically granted access to that object. This lets you first access an object and its pages for testing, before you officially grant access to your customizations to users in a production environment.

This table lists the default duty roles that are provided by Oracle Sales Cloud:


Application

Default Duty Role

Customer Center

Sales Administrator Duty

Marketing Operations Manager Duty

Marketing

Marketing Operations Manager Duty

Sales

Sales Administrator Duty

Child objects do not inherit security settings from parent objects. Rather, if you create a custom child object, then a default set of duty roles are granted access to the child object. In other words, a child object is visible and editable only to users with these default duty roles, as follows:


Application

Child Objects of This Parent Object

Access Granted to These Duty Roles

Customer Center

Sales Account

Sales Administrator Duty

Marketing Operations Manager Duty

Marketing

Sales Lead

Marketing Operations Manager Duty

Sales Administrator Duty

Channel Operations Manager Duty

Marketing

Marketing Campaign

Marketing Response

Marketing List

Marketing Treatment

Marketing Event Activity

Marketing Advertising Activity

Marketing Operations Manager Duty

Marketing

Marketing Budget

Marketing Claim

Marketing Budget Entry

Marketing Budget Fund Request

Marketing Operations Manager Duty

Channel Operations Manager Duty

Sales

Opportunity

Sales Competitor

Sales Administrator Duty

Sales

Partner

Channel Operations Manager Duty

Common

Customer Contact Profile

Resource

Account

Address

Customer Data Steward Duty

Importing and Exporting Custom Objects: Explained

To support the importing and exporting of the custom objects that you created with Application Composer, you must first generate the object artifacts required for both file-based import and bulk export.

Oracle Sales Cloud Import and Export Processes

In Oracle Sales Cloud, two processes exist to enable the importing and exporting of object data: file-based import and bulk export.

File-based import supports the import of data from an external text or xml file to interface tables and then from interface tables to target application tables.

Note

File-based import bypasses any Groovy validation and trigger logic on an object. For example, object workflows are not triggered by an import.

Bulk export lets you extract large volumes of data from Sales Cloud objects, both as extracts of a full set of records for an object as well as incremental extracts. The system creates comma or tab-delimited files with the extracted data, which are available to users as attachments to the batch records that have been executed.

Enabling Import and Export for Custom Objects

The object model extensions that you make using Application Composer do not create the artifacts required by these import and export processes. For example, file-based import leverages Oracle Data Integrator (ODI).

Accordingly, after completing your object model extensions, generate the required artifacts to register your extensions and make them available for importing and exporting.

Note

The creation of import and export artifacts occurs only in the Oracle Metadata Services (MDS) mainline code, and is not supported within the MDS sandbox.

To enable the import and export of custom object data:

  1. Select an application on the main Overview page.

  2. Select the Import and Export link in the Common Setup pane, or in the local area of the main Overview page.

  3. On the Import and Export page, click the Generate button.

After you enable your object model extensions for importing and exporting, you can then schedule your file-based import and bulk export processes using the following tasks, available by selecting Setup and Maintenance from the Tools menu and searching on the task name.

  • To schedule your custom object imports, select the Manage File Import Activities task.

    To initially set up file-based import for importing custom object data, select the Manage File Import Objects and Manage File Import Mappings tasks.

    Note

    Custom child objects are imported as part of the parent object.

  • To schedule your custom object exports, select the Schedule Export Processes task.

    Note

    Both top-level and child custom objects are available as independent exportable objects.

Important

Refer to Oracle Sales Cloud product-specific documentation for additional details on the import and export of custom object data (custom fields) for standard objects.

FAQs for Using Application Composer

What's the difference between fixed choice lists and dynamic choice lists?

A fixed choice list and a dynamic choice list are similar in that the ultimate goal of both types of choice lists is to generate a field with a list of values at run time. However, the list of values for a fixed choice list is derived from an FND lookup type.

The list of values for a dynamic choice list is derived from an existing object's actual data.

What's the difference between Page Composer and Application Composer?

Page Composer is a web-based tool you can use to modify user interface (UI) pages and components for all products designated for use with Page Composer. Page Composer uses two different modes of Design View. The first mode, Design View: Standard mode, is selected by default in all Sales Cloud pages when opening a page with Page Composer with the Design button selected. The second mode, Design View: Direct Selection mode, is activated when you click the Select tab for the UI page you want to customize. In Sales Cloud, Direct Selection mode is available when you customize pages, but not when you personalize a dashboard page. With the Design View: Direct Selection mode, you can select and edit UI elements such as form fields and table columns. In Direct Selection mode, selectable UI components become apparent when you move your cursor over the UI component. Selectable UI components are highlighted and can be edited.

The following table describes how you can use each mode of Page Composer to customize dashboard pages and other select pages (such as the Partner Public Profile page, Partner Landing page, Partner Registration, Customer Snapshot, and Customer Overview - Analysis tab), and customize transactional pages (all other non-dashboard pages).


Use Cases

Design View - Standard mode

Design View - Direct Selection mode

Page Type

Add content (Business Intelligence reports, Sales Cloud portlets such as Calendar)

Yes

No

Dashboard and other select pages

Delete region

Yes

No

Dashboard and other select pages

Move region

Yes

No

Dashboard and other select pages

Change page layout (for example, change a two column layout to three column layout)

Yes

No

Dashboard and other select pages

Default region state (open or close)

Yes

No

Transactional pages (all non-dashboard pages)

Manage save queries (create and edit)

Yes

No

Transactional pages (all non-dashboard pages)

Hide or show field

No

Yes

Transactional pages (all non-dashboard pages)

Change field label

No

Yes

Transactional pages (all non-dashboard pages)

Make field required or not

No

Yes

Transactional pages (all non-dashboard pages)

Make field read-only or updateable

No

Yes

Transactional pages (all non-dashboard pages)

Reorder fields in a Form

No

Yes

Transactional pages (all non-dashboard pages)

Reorder table columns

Yes

Yes

Transactional pages (all non-dashboard pages)

Hide or show table columns

Yes

Yes

Transactional pages (all non-dashboard pages)

Set table column width with the mouse

Yes

No

Transactional pages (all non-dashboard pages)

Set table column width and min width in percent or pixels

No

Yes

Transactional pages (all non-dashboard pages)

Make column sortable or not

No

Yes

Transactional pages (all non-dashboard pages)

Application Composer also lets you make UI changes at run time. However, the types of UI changes that you can make using Application Composer are quite different. Specifically, your primary focus when using Application Composer is to make actual object model changes. For example, you can create a new business object and related fields, and then create new application pages where that object and its fields are exposed to users.

The following table describes some of the primary differences between Page Composer and Application Composer. For example, using Application Composer, you cannot access the Resource Catalog to add new content to a page. With Application Composer, administrators can make customizations at the site level only.


Customization Task

Available in Page Composer (site, job role, external or internal level)?

Available in Application Composer (site level only)?

Make object model extensions and expose your customizations by creating or modifying work area pages

No

Yes

Reorder subtabs

No

Yes

Customize dashboard pages

Yes

No

Add content from the Resource Catalog

Yes

No

Simple field customizations (show, hide, make read only, make required)

Yes (WYSIWYG - what you see is what you get)

Yes (non-WYSIWYG)

Select the MDS layer where you want to author customizations, such as at the site layer or job role layer

Yes

No

View results of customizations immediately

Yes, in the Page Composer design interface

Yes, in the Sales Cloud application that you are customizing