4Adding Objects and Fields in Application Composer

This chapter contains the following:

Using Application Composer: Overview

Use Application Composer to create fields, objects, and relationships. Then, modify user interface pages for all users, or only some. Common tasks available in Application Composer are described in this chapter.

This chapter provides a summary of how Application Composer works and explains:

  • How to define custom objects

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

  • How to secure both the actions in an object's work area, as well as the data that users can see

Other chapters in this guide describe additional tasks flows that are available in Application Composer. For example, learn how to create object workflows and custom subject areas, how to write Groovy scripts, and how to import and export your application changes. Refer to the table of contents for these other chapters.

Also refer to the Groovy Scripting Reference guide, available in the documentation library, for specific examples and use cases about changing your implementation.

You can access Application Composer by selecting Application Composer from the Navigator menu, under the Configuration category. To test your changes, use the Navigator to switch to the desired application.

Tip:

Navigate quickly and easily between your application's runtime pages and Application Composer design time pages using the Favorites and Recent Items menu.

Application Composer is a browser-based configuration tool that enables business analysts and administrators, not just application developers, to extend their applications. Make the type of data model changes which, in the past, could only be made by application developers. For example, easily create a new object and related fields, then create new user interface pages where that object and its fields are exposed to users.

Application Composer is a design time at runtime tool, which means that you can navigate to Application Composer directly from any application, make your changes, and see most changes take immediate effect in real time, without having to sign out and sign back in.

Note: To see your changes in real time, always use the Navigator to navigate to the runtime page that you changed. Then navigate back to Application Composer to continue making changes. In other words, when making application changes (and testing them), restrict your usage to a single tab. Don't work across multiple browser tabs, because Application Composer doesn't support this type of usage.

Application Composer is supported for use only in English. Additionally, Application Composer is not supported for use with iPad devices.

Application Changes for Nondevelopers

Application Composer hides the complexity of modifying applications 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.

Using Application Composer, you can make application changes such as:

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

  • Creating foreign key-based relationships between two objects.

  • Modifying user interface pages by exposing your newly created fields for an object, or create an entirely new work area for your custom objects.

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

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

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

  • Enabling objects for custom reporting.

Accessing Application Composer

Access Application Composer from any application at runtime by using the Navigator menu, and selecting Application Composer under the Configuration category. The first view of Application Composer is the main Overview page, which is the entry point into all your task options.

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

Getting Started

From the main Overview page:

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

  • Use the links in main Overview page, also known as the local area, to select a task. Or, use the links in the Common Setup pane.

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

Viewing Application Composer Changes: Explained

Use the Configuration report to view a detailed list of Application Composer changes made by administrators in your environment. Access the report under Metadata Manager in the Common Setup pane in Application Composer. You can generate the report as many times as needed, each time overwriting the previously generated version of the report.

Configuration Report

The Configuration report lists changes in your environment that were created in Application Composer, as described in the following list. You can download the report in HTML, in Microsoft Excel (.xls) format, or in Microsoft Excel Worksheet (.xlsx) format.

The report includes:

Report Item Description

Configuration Summary

Provides a summary of changes such as the number of objects and fields, relationships created, and object validations.

Global functions

Includes a listing of the global functions created.

Relationships

Includes a listing of all the relationships created.

Object summary

Select All modified objects to include all the changes that have been made to any objects.

Select Selected objects to include all the changes for only a subset of objects.

Tip: To include layout details, select up to five objects only.

Fields

Includes custom fields and standard fields that have been modified for the objects that you selected.

Server scripts

Includes object validations, object functions, object triggers, and global functions for the objects that you selected.

Object workflows

Includes object workflows for the objects that you selected.

Page layout summary

Includes a listing of dynamic page layout names and layout conditions for the objects that you selected.

Select Layout details to include a list of all the actions, buttons, subtabs, and field names exposed in each subtab of a dynamic page layout.

To submit the report:

  1. Confirm that you are not in a sandbox session.

  2. In Application Composer, select Metadata Manager in the Common Setup pane.

  3. Click Generate.

  4. In the Generate Configuration Report dialog, indicate the items that you want to include in the Configuration report.

  5. Click Generate.

  6. Download the report by selecting either the HTML or Excel format.

Working with Objects

Using Application Composer, modify an application's object model so that you can track and store any additional data you might need. For example, add new fields to an existing object (standard objects), or create entirely new objects (custom objects). Standard objects are objects that are delivered with an application, and made available to Application Composer for application changes. 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).

Read this topic to learn about these tasks:

  • Browsing the object tree

  • Creating a custom object

  • Using the Object Overview page

  • Editing an object's attributes

  • Selecting the display icon for the object's set of UI pages

  • Viewing child and related objects

  • Deleting a custom object

Using Application Composer's Object Tree

Access Application Composer from the Navigator menu. The first view of Application Composer is the main Overview page, which is the entry point into all your application change 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 Configuration category.

  2. For each object node, whether standard or custom, expand it further to view and edit object details.

    For example, look at object details such as fields and UI pages where the object is exposed.

    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.

    For custom objects, you can also view and edit details to security. For example, you can implement functional and data-level security for an object and its records.

Creating a Custom Object

Create a custom object if you want to track data about an object that's not already delivered with your cloud service. After you create the object, you then add custom fields and design user interface pages where your users can enter object records. There is no fixed limit on the number of custom objects that you can create.

To create a custom object:

  1. On the main Overview page of Application Composer, select the Custom Objects node in the object tree, or click the icon in the local area of the main Overview page.

  2. On the resulting summary table, click the New icon, 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 Label

      Use the Record Name Label field to specify the display label for the object's RecordName attribute. The RecordName attribute stores the user-entered "name" of the record. For example, if you're creating a custom object, Book. In the Record Name Label field for this object, you would enter something like "ISBN Number." At run time, for each new record, your users would use the ISBN Number field to enter the book's International Standard Book Number (ISBN), which uniquely identifies books published internationally.

      Typically, this field is the object's primary user-recognizable identifier that run time users drill down on, from the landing page to the detail page. For example, at run time, your users would click any ISBN to drill down to review details about the book, such as book title and author.

    4. Record Name Data Type

      Select either Text or Automatically Generated Sequence.

      For record names of Text data type, the maximum length that users can enter is 32 characters. For record names of Automatically Generated Sequence data type, the sequence number is based on a display format which is up to 28 characters and has at least one number token: {0}.

    5. Select the Prevent duplicate values? check box to prevent users from entering records with duplicate names.

      1. If the Prevent duplicate values? check box is selected, then the Treat "ABC" and "Abc" as distinct values check box is enabled.

        Select this check box if you want the assessment for duplicate records to be case sensitive.

    6. Object Name

      The object name is the internal name for the object.

      Note: You can use a custom object's internal name only once across the mainline code and all existing sandboxes. If you previously used an object's internal name in a sandbox, you can reuse that same internal name, but you must first you delete all other sandboxes where the internal name was previously used.

      You can use a custom object's display name as many times as you want across sandboxes. The restriction applies only to the internal name.

    7. Description

  4. Click OK.

    Once your custom object is created, you must add fields and then create the UI pages where your users can create actual records. See Defining Fields: Explained" and "Creating a Set of Simplified Pages for Custom Objects: Explained.

Tip: To create a custom child object, click the Create Child Object button from the parent object's Object Overview page. See the next section in this topic.

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. On the main Overview page, select the object in the object tree or select the Standard Objects or Custom Objects node in the object tree, or the icon in the local area of the main Overview page.

  2. Select the object from the resulting summary table, and click the Edit icon.

From the Object Overview page, you can:

  • Edit the object's primary attributes, described in the previous section. For example, change the Display Label or Record Name Label.

  • Change the display icon for the object.

    This process is described as follows:

  • 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. Access the Object Overview page for the object, as described earlier.

  2. On the Object Overview page, click Edit:

    • Change the object's primary attributes, such as 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.

Selecting the Display Icon for Objects

From the Object Overview page, you can select the display icon to use for the object's UI pages. You can select the display icon for custom objects (although a default icon is provided), and you can change the icon for standard objects. The icon you select determines which icon and theme display to your end users in a variety of locations, such as on the Navigator, subtabs, mobile pages, and the springboard strip on simplified pages.

Tip: The icon selected for standard objects is inherited across your applications. For example, if you change the display icon for the Opportunity object, then all UI pages are automatically updated to the new icon. This includes even custom subtabs that you added using Application Composer.

To select the icon:

  1. Click the object's node in the object tree to view the object's Overview page.

  2. On the Overview page, set the icon for the object in the Display Icon region.

    This is a screenshot of the Object Overview page,
where you can select the display icon 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 record, then all its child records 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 metadata, optionally enter a note in the description that the object is no longer used.

Your end users will often need to associate one object's records with the records of another object. To enable this type of association between records, you must first create a relationship between those two objects. For example, maybe your users want to track the opportunities that get created for an account.

In this example, you will create a one-to-many relationship between the account and opportunity objects, and then expose a list of opportunities as a subtab on the account's details page. This lets users search for and add one or more opportunities to a single account record. When creating relationships between objects, there are four types of relationships that you can pick from in Application Composer. Each type of relationship has its characteristics and advantages. In general, they all let you use a subtab to create or assign one or more records from one object to a record from another object.

Review these aspects of using and managing relationships in Application Composer before you begin to create relationships between objects:

  • Relationship types

  • Adding subtabs

Relationship Types

Application Composer lets you create either a one-to-many relationship, or a many-to-many relationship. Across these two categories, there are four types of relationships that you can pick from when creating a relationship.

  • Parent child relationship. A parent child relationship is a one-to-many relationship: one parent record can have many children records. When you create a child object, it's created specifically in the context of its parents. A child object doesn't have its own work area, and the child object's records are deleted if the parent objects is deleted.

  • Dynamic choice list relationship. A dynamic choice list field provides a list of values from a source object, which your users can select and associate with a target object. When you define the dynamic choice list field, Application Composer automatically creates a one-to-many relationship between the source object and target object. This means that not only do you get the ability to associate a source object and target object records that are associated with a single source object record.

  • Reference relationship. You can also manually create a one-to-many relationship, where you can specify a source object and target object. Thus, this type of relationship is similar to a dynamic choice list relationship. The only drawback is that you don't get a dynamic choice list field to add on the target object's work area. A reference relationship only gives you the ability to add a subtab to the source object's details page, showing a list of all the target object records that are associated with a single source object record.

  • Many-to-many relationship. Create a many-to-many relationship where, similar to a one-to-many relationship, you can specify a source object and target object. However, with one-to-many relationships, you can add a subtab only to the source object's details page. This lets your users add one or more records from one object to one or more records from another object.

Adding Subtabs

After you create relationships between objects, you can then expose one object's records on a subtab that is displayed on the other object's details page.

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

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

Parent Child Relationships

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 in the object tree, where child objects appear as sub-nodes beneath their parent objects. 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. A child object can have only one parent object.

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

Dynamic Choice List Relationships

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

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.

When you select an object and create a dynamic choice list field 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.

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

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 displayed 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 are in a global single instance environment and you create a dynamic choice list between a sales and service object and a common object: resource, customer contact profile, account, address. In such cases, relationships are not implicitly created.

Creating Reference Relationships

Create a foreign key-based, one-to-many relationship between two top-level objects explicitly using the Create Relationship page. This type of relationship is called a reference relationship.

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.

  3. Select the source object and target object.

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

    The Note common component is not available for selection as either a source object or target object.

    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.

  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.

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.

Groovy Script Syntax

Once you have created a one-to-many relationship between objects, a foreign key field is created on the child object or on the "many" object. Use the following API names to access those foreign keys in your scripts.

Relationship Type Foreign Key API Name Pattern Used

Parent/child relationship

If the parent object name is ParentObj_c, then the foreign key API name (added to the child object) is ParentObj_Id_c.

<Name of the parent object>_Id_c

Dynamic choice list relationship

If the dynamic choice list field name is DynChoice1_c, then the foreign key API name is DynChoice1_Id_c.

<Name of the dynamic choice list field>_Id_c

Reference relationship (one-to-many)

If the source object name is SourceObj_c, the target object name is TargetObj_c, and the relationship name is relation_Mto1, then the foreign key API name (added to the target object) is SourceObj_Id_relation_Mto1.

<Name of the source object>_Id_<Name of the relationship>

In addition to one-to-many relationships between objects, objects can also have a many-to-many relationship between each other. 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 Resource objects, where the related records from both objects store their primary identifiers in an intersection object. Many-to-many relationships are not supported in desktop work areas.

Creating Many-to-Many Relationships: Example

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

  1. Select Relationships in the Common Setup pane.

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

  3. Select the source object and target object.

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

    The Note common component is not available for selection as either a source object or target object.

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

    Note: You can create only one many-to-many relationship for a particular set of objects.
  4. Enter the relationship name and description.

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

  5. Indicate the cardinality of the relationship:

    • M:M

      • Many-to-many

  6. Enter the name of the intersection object.

    The intersection object's table records two foreign keys: one for the Service Request object and the other for the Resource object. This enables the many-to-many relationship.

    The intersection object is available as an extensible, top-level object in Application Composer. Optionally extend the intersection object. Custom fields that you add to the intersection object are available for display on the subtabs you create, which is discussed in the section below.

    Intersection objects also have a corresponding web service automatically published.

  7. Optionally specify data filter criteria for both the source and target objects.

    The filter criteria that you specify here controls which records are available for association at run time with a record from the other object in this relationship.

    Read: "Configuring a Search and Select Dialog for Custom Objects".

Adding Subtabs

After you create the many-to-many relationship, you can now add related object subtabs on each object's simplified details page:

Note: You can add subtabs for a many-to-many relationship to simplified details pages only. Many-to-many relationships are not supported in desktop work areas.
  • Create an Employee subtab on the service request's details page.

    The subtab displays all employees that are working on a specific service request. At run time, your end users can add or remove employees who are working on a specific service request.

    When creating the subtab, you can select which Resource fields to display, such as Employee Name and Title. You can also select which intersection object fields to display, such as Primary Service Request Owner.

  • Create a Service Requests 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. At run time, your end users can add or remove service requests that an employee is working on.

    When creating the subtab, you can select which Service Request fields to display, such as Service Request Abstract and Date Logged. You can also select which intersection object fields to display, such as Primary Service Request Owner.

When selecting the fields for display on a related object subtab, join fields are not available for selection if the relationship is a many-to-many relationship.

Configuring a Search and Select Dialog for Custom Objects

A Search and Select dialog lets your end users search for and select object records when assigning one record to another, such as an employee to a service request. These dialog boxes are launched from the related object subtabs that you create, after creating relationships.

Search and Select dialog boxes are automatically provided for standard objects, and are not extensible. However, if you're creating a many-to-many relationship that involves a custom object, then you must configure the Search and Select dialog boxes for those custom objects.

The filter criteria that you specify in the relationship definition applies to the Search and Select dialog, and controls which records are available for association at run time with a record from the other object in this relationship.

For example, you can define filter criteria that lets your end users select only "unassigned" service requests for association with an employee.

Groovy Script Syntax

Once you have created a many-to-many relationship, two foreign key fields (one for each object) are created on the intersection object. Use the following API names to access those foreign keys in your scripts.

Relationship Type Foreign Key API Name Pattern Used

Reference relationship (many-to-many)

If the source object name is SourceObj_c, the target object name is TargetObj_c, and the intersection object is IntersectionObject_c, then the two foreign key API names (added to the intersection object) are TargetObj_Id_Tgt_TargetObj_cToIntersectionObject_c and SourceObj_Id_Src_SourceObj_cToIntersectionObject_c.

<Name of the object>_Id_Tgt_<Name of the object>_cTo<Intersection object name>, <Name of the object>_Id_Src_<Name of the object>_cTo<Intersection object name>

Activating Global Search on Objects You Created or Deactivated: Procedures

Oracle activates global search on all application objects where search is available. Use this procedure to activate search on any objects you deactivated in the past or for objects you created. You can activate search only on the objects you created, not on their child objects.

To make an application object available for global search, you must do the following:

  1. Activate the object.

  2. Specify the frequency with which the object will be indexed.

  3. Optionally, you can modify the list and order of fields indexed in the search and displayed in the search results.

Activating an Object for Search

To activate an object for search, do the following:

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

    • Offering: Sales

    • Functional Area: Sales Foundation

    • Task: Manage Search View Objects

  2. Select the object you want to enable for search.

  3. Click Activate.

    The status for the object changes to Active.

    Tip: Make sure you deactivate any object that is not needed for global search to maximize system resources.

Setting the Indexing Frequency and Schedule

After you have activated the object, you must specify how frequently you want the object records indexed.

Oracle recommends that you index objects daily during off-hours. You should stagger the indexing times for the different objects to minimize performance impacts.

Specifying the fields to be indexed and displayed in the search results is optional because these are already set up for you.

  1. Select the Display Name link of the object.

    The Edit Search View Object page appears.

  2. In the Index Schedule region, select the Frequency Type and enter the number of days between index runs and the time, if appropriate. Oracle recommends staggering the indexing schedule to maximize available system resources.

  3. You can change which fields the application indexes and which fields display in search results as described in the Specifying Which Fields Are Indexed and Displayed in Search Results section.

  4. When you are done, click Save and Close

    The application returns you to the Manage Search View Objects page where you can monitor the status of the index generation for each object.

    The first time your scheduled indexing process runs or any time you modify the list of fields in the object, the application generates a complete index of all the existing records. Subsequently, the process indexes only records that have changed.

    If you end up with many inactive records in your system over time, you can improve the efficiency of your searches by periodically regenerating the full index. This can be accomplished by selecting the object and clicking Full Reindex.

Specifying Which Fields Are Indexed and Displayed in Search Results

In the Edit Search View Object page, you can also change which fields the application indexes and which fields display in search results. You must index the fields you created if you want them to be available for searches.

  • The Title and Fixed Content fields let you specify which fields are displayed in search results and in what order.

    • Title is the linked heading of each search result.

    • Fixed Content is the text which appears under the heading.

    For example, the titles starting with the word Opportunity are links which permit users to drill down to the record. The rest of the fields are the fixed content.

  • The Body field lists the fields that are indexed by the application. The most relevant fields are displayed in the search results, space permitting. While the Body field includes all of the standard fields for indexing, you must add the fields you created to the list if you want them available for searches.

To make changes, click Edit (the pencil icon) and make your changes in the Edit Search View Object window.

Managing Security for Custom Objects

Use Application Composer to create custom objects and fields, as well as the user interface (UI) pages where your users can enter data. By default, a custom object and its records are visible and editable only to users who are provisioned with the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role. You must have this custom objects role assigned to you, before you can view and test custom objects in the sandbox. After creating custom objects, you must indicate which end users can view the pages and enter data. Grant additional access manually in Application Composer using the custom object's Security node, or the Role Security link in the Common Setup pane. Provision data security for custom object records and restrict users who have privileges to view, update, or delete records. You can provision this type of security to all the users, owners of records, owner and management hierarchy, and user-defined roles. The Owner field is available on all pages for custom objects. When you create a record, by default, you are the owner. With this security provisioned, you can filter records owned by you or your subordinates.

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

  • Who can create custom objects?

  • Who can see your custom object?

  • Understanding security policies

  • Custom vs. predefined roles

  • Application Composer and the Security Console

Who Can Create Custom Objects?

Users with any one of the three following job roles can create custom objects and use all other Application Composer functions:

  • Customer Relationship Management Application Administrator.

  • Application Implementation Consultant.

  • Master Data Management Application Administrator.

Oracle recommends provisioning the user with the Customer Relationship Management Application Administrator job role (for performing the application changes) and the Custom Objects Administration job role and Sales Administrator job role (for testing the application changes in the UI).

Managing Who Can See Your Custom Objects?

When you create custom objects, by default their UIs are visible only if you have the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role. The application creates this custom role automatically. The UI pages you create for custom objects are not visible to additional users unless you provide access in Application Composer using the object's Security node. Use the Security node to specify not only which job roles can access the UIs, but the levels of access. Provision data security for custom object records and restrict users who have privileges to view, update, or delete records. You can provision this type of security to all the users, owners of records, owner and management hierarchy, and user-defined roles. For example, you can make it possible for owners to update object records, while managers can only view records.

To manage who can see your custom objects:

  1. Ensure that you have assigned the Custom Objects Administration role to yourself and to other users who make application changes.

    The Custom Objects Administration role is automatically assigned to new custom objects, as well as existing custom objects, if you have upgraded from a previous release.

    See "Enabling the Testing of Custom Objects in the Sandbox: Procedure."

  2. For each custom object, use the Security node to specify which roles can view that object's UI pages, and their level of access: view, update, and delete. This is called a security policy. See the following "What's a Security Policy" section.

    When granting access to custom object UIs, you can select only custom job roles. For example, if you want to create a custom object for sales managers, then a custom sales manager job role must first exist (instead of the predefined Sales Manager job role provided by Oracle), before you can grant access to sales managers. If you want to create a custom job role, then copy the predefined Sales Manager job role in the Security Console as described in the Securing Sales and Service guide.

    Granting access to custom job roles means that your custom object won't be affected by future upgrades. See the "Custom vs. Predefined Roles" section later in this topic.

  3. If you're creating custom objects for a specific job role, then you must also assign yourself that job role to view and test the application changes in a sandbox. For example, if you're creating a custom object for sales managers, then you must assign yourself the sales manager job role to test how that object works for sales managers. If you later create a different object for sales representatives, then you will have to deprovision the sales manager job role and provision yourself with the sales representative job role instead, so that you can accurately test your new object.

    • Setup users, who have the permission to create and update users, can grant themselves the appropriate job roles by editing their user record in the Manage Users work area.

    • Sales administrators, who are resources, can request the job role they need for testing by following the procedure described in "Assigning Yourself an Additional Job Role."

      To make job roles requestable for sales administrators, a setup user must create a special role-provisioning rule, as described in "Creating the Provisioning Rule for the Job Roles Used in Testing."

  4. If you're adding a custom object subtab to a standard object, then you must also assign yourself the job role that can view the standard object's UI.

    For example, if you add a custom object subtab to the Edit Opportunity details page. In this case, you will need the role required to access the Edit Opportunity page, in addition to the role granted to the custom object.

What's a Security Policy?

For each custom object, you will need to update its security policy. A security policy specifies which users are authorized to access an object's data, and what type of access they have. Access includes both function security as well as data security. For example, does a user have view only access, or can the user create and update an object's record, as well?

As previously mentioned, custom objects are automatically assigned the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role and creating a custom object record automatically grants you the owner role. Next, grant additional access to your custom object so that your end users can enter data.

For each custom object, you can grant access to multiple roles for a single object, or you can grant access to multiple objects for a single role.

  • Define security policies for an object.

    Authorize the various custom roles whose users can access that object's data.

    You must define security policies for child objects, as well.

    See "Managing Security by Object: Explained."

  • Or, define security policies for a role.

    Specify the role's access levels across multiple custom objects.

    See "Managing Security by Role: Explained."

Define the security policy for a custom object using the Security node in Application Composer, on the Define Policies page. On this page, you can manage an object's data security, which applies to a record of an object and an object's functional security, which applies to the object as a whole. The page provides options for the following security types:

  • Create

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

  • Read

    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 Read, Update, and Delete security types provide data security options for the following along with the functional security:

  • Owner

  • Owner and Management Chain

  • All

When you select any of the above data security options, the corresponding functional security is automatically selected.

Custom vs. Predefined Roles

The Define Policies page (for both custom objects and roles) displays custom roles. Custom roles are copies of the predefined roles that Oracle provides for all customers. You can't modify predefined roles, so they aren't displayed here. However, you can modify custom roles. Modifying a custom role means adding access to one or more custom objects so that role can view the custom object at runtime.

If you don't see a list of roles on the Define Policies page, then you must first copy the predefined roles that you need using the Security Console:

  1. Use the Security Console to make copies of the predefined roles you need. These copied roles are known as custom roles.

    In the Securing Sales and Service guide, see:

    • Copying Sales Roles: Points to Consider

    • Copying Job or Abstract Roles: Procedure

  2. Navigate back to Application Composer, open the Security node for your custom object, then define the security policy across roles for your custom object.

If you upgraded from a previous release, then you might have made changes to predefined roles in an earlier release. During the upgrade to the current release, Oracle automatically copies those modified predefined roles for you, so they will appear as custom roles on the Define Policies page. See "Custom Roles and the Upgrade Process: Explained" in the Securing Sales and Service guide.

Application Composer and the Security Console

The Security Console 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 the Security Console.

Security policies defined in Application Composer can be modified in Application Composer. Do not use the Security Console to modify these policies.

When you create custom objects, by default their UIs are visible only if you have the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role. The UI pages you create for custom objects are not visible to additional users unless you provide access in Application Composer using the object's Security node. Provide access to a single custom object, across multiple custom roles, using each custom object's Security node. You can specify the job roles that can access the UIs, as well as the levels of access. Use the Security node to provision data security for custom object records and restrict users who have privileges to view, update, or delete records. You can provision this type of security to all the users, owners of records, owner and management hierarchy, and user-defined roles. For example, you can make it possible for owners to update records, while managers can only view records. The Owner field is available on all pages for custom objects. When you create a record, by default, you are the owner. With this security provisioned, you can filter records owned by you or your subordinates.

Alternatively, you can update the security policy for a custom role, across multiple custom objects, using the Role Security link in the Common Setup pane. See "Managing Security by Role: Explained."

Managing Object Security

The object-centric Define Policies page displays a list of the custom roles available for selection. Use this page to manage access to either a top-level or child custom object by specifying a security policy for one or more custom roles. When you do this, users with the corresponding custom 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. Ensure that you're in an active sandbox session.

  2. Navigate to Application Composer and on the main Overview page, select a custom object in the object tree.

  3. Select the Security node. The page that displays is the object-centric Define Policies page.

    This is a screenshot of the object-centric Define Policies
page, which displays a list of the custom roles that you can assign
to the custom object.

From this page, you can enable data security across multiple roles. If data security is selected, the corresponding functional security is automatically selected.

See "Making Custom Object Pages Visible to Users: Explained" to learn about function security and data security.

When you create custom objects, by default their UIs are visible only if you have the Custom Objects Administration (ORA_CRM_EXTN_ROLE) role. The UI pages you create for custom objects are not visible to additional users unless you provide access in Application Composer. Provide access to a single custom role, across multiple custom objects, using the Role Security link in the Common Setup pane. Use this link to specify not only which job roles can access the UIs, but the levels of access. Provision data security for custom object records and restrict users who have privileges to view, update, or delete records. You can provision this type of security to all the users, owners of records, owner and management hierarchy, and user-defined roles. For example, you can make it possible for owners to update records, while managers can only view records. The Owner field is available on all pages for custom objects. When you create a record, by default, you are the owner. With this security provisioned, you can filter records owned by you or your subordinates.

Alternatively, you can update the security policy for a custom object, across multiple custom roles, using each custom object's Security node. See "Managing Security by Object: Explained."

Managing Role Security

The Role Security page displays a list of the custom roles available for selection. Click a custom role name to navigate to the role-centric security policies page, which displays a list of the custom objects for your implementation. Use this page to manage access for users with the corresponding custom role by specifying a security policy for one or more top-level or child custom objects. When you do this, users with the corresponding custom role can access the custom objects and related data, depending on the security policies you define.

To access the role-centric security policies page:

  1. Ensure that you're in an active sandbox session.

  2. Navigate to Application Composer and in the Common Setup pane, select the Role Security node.

    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.

  3. Click a custom role name to navigate to its role-centric security policies page.

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

From the role-centric security policies page, you can enable data security across multiple objects. If data security is selected for a record, the corresponding functional security is automatically selected.

When you create a custom object record, by default, you become the owner. As an owner, you can filter records owned by you and your subordinates using the Record Set filter. See FAQ: What record sets is an owner permitted to search?

When you create a custom object, an Owner field is automatically created. You can access this field in Application Composer under the Custom tab of the Fields page. To access this page click the Fields node of the custom object.

This example illustrates how an owner can define the following security policies for the Trouble Tickets object:

  • All users can create and read the record

  • Only the owner and owner management chain can update the record

  • Only the owner can delete the record

Managing Role Security as an Owner

  1. Ensure that you're in an active sandbox session.

  2. Navigate to Application Composer and on the main Overview page, select a custom object in the object tree.

  3. Select the Security node. The object-centric Define Policies page appears.

  4. Navigate to the row of the role whose levels of access you want to edit.

  5. Select the Create check box.

  6. Click the Read drop-down list, and then select Read All. The Functional Read option gets selected automatically.

  7. Click the Update drop-down list, and then select Owner and Owner Management Chain. The Functional Update option gets selected automatically.

  8. Click the Delete drop-down list, and then select Owner. The Functional Delete option gets selected automatically.

  9. Click Save and Close.

    The security policies for the Trouble Tickets object are now updated to provide create and read access to all users, update access to owner and owner management chain, and delete access to only the owner.

Working with Fields

Using Application Composer, you can extend your applications by adding new fields to both standard or custom objects. 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.

Viewing an Object's Fields

An object can have a maximum of 625 fields. To review the standard and custom fields for an object, and to create custom fields, navigate to the object's Fields page in Application Composer.

  1. Navigate to Application Composer from the Configuration category in the Navigator.

  2. Expand the object that you want to add custom fields to.

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

    Click the Standard Fields or Custom Fields tabs to view the standard or custom fields available for the object.

    • On the Standard Fields tab:

      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 delivered by Oracle for an object, as well as system fields, which could include:

      • CreatedBy

      • CreationDate

      • Id

      • LastUpdateDate

      • LastUpdatedBy

      • RecordName

      Note: The custom objects that you create also contain these same system fields, among others.
    • On the Custom Fields tab:

      Review the list of custom fields that you created specifically for your implementation, and create new custom fields.

Adding Fields to Objects

To create a custom field:

  1. Confirm that you're in a sandbox session, before making any application changes.

  2. In Application Composer, select the object that you want to make changes to, then select the object's Fields node.

  3. On the Custom Fields tab, click New.

    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

  4. Select the type of field you want to create, and then specify the required field attributes to create the custom field.

  5. After you create custom fields, you must expose those fields on the right user interface pages, before your end users can see them. See Defining Pages: Explained.

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.

Deleting Fields

You can't delete either standard or custom fields from objects. If you no longer need a field that was already published to the mainline metadata, optionally enter a note in the field description that the field is no longer used.

Fields can be one of several types, such as a number field or formula field. And, each field type has a set of standard properties. Most properties are common across all types of fields, although some are specific to the type of field you're creating. For example, all field types have a display label, but only some field types have a display width specification. Read this topic to learn about field types and common field properties.

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

  • The field types available for field creation

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

  • How field types work with other components

  • Extensible properties for standard fields

Field Types

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

The types of fields that you can create are:

  • Check box

    Select to indicate a true or false attribute of a record.

  • Currency

    Enter a currency amount.

  • Date

    Enter a date, or select one from a calendar.

  • Datetime

    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.

  • Dynamic choice list

    Select from a list of values populated from another object's set of records.

  • Fixed choice list

    Select from a list of static values populated from an FND lookup type.

  • Formula

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

  • Long text

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

  • Number

    Enter a number in this field.

  • Percentage

    Enter a percentage. The percent sign is automatically added.

  • Record Type

    Select from a list of static values populated from an FND lookup type. You can associate each choice list value with a role or a page layout.

  • Text

    Enter a combination of letters, numbers, or symbols. This field type is limited to 1500 characters.

Common Properties for Custom Fields

When you create a custom field, you first select the field type. 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, while 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.

Tip: Many of these properties are also available for standard fields. See "Common Properties for Standard Fields" in this topic.
Field Property Field Property Region Related Field Types

Label

Specify the display label for the field.

You should limit the label to a maximum length of 80 characters, although no maximum length is enforced.

Appearance

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

Set this property for all field types.

Help Text

Displays when users hover over the field in the runtime application.

You should limit the label to a maximum length of 80 characters, although no maximum length is enforced.

Appearance

Set this property for all field types.

Display Width

Specify for most field types at runtime. The display width is the actual character width for the field on desktop pages only. This attribute doesn't apply to simplified pages.

When setting the display width, consider the resolution in use where this field will appear 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.

Note: 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

A unique field name 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 contain spaces

  • Not end with an underscore

  • Not contain consecutive underscores

  • Not include special characters.

    This might cause issues while generating clients using SOAP web services.

  • Be limited to a maximum of 28 characters if the characters are single byte.

    If the characters are multibyte, such as Japanese or Chinese, then the maximum character limit is 28/number of bytes per multibyte character. For example, if characters are 2 bytes, then the name is limited to a maximum of 14 characters.

    If a mix of characters is used, then 28 is the maximum sum of character bytes that is supported.

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, to avoid seeing two fields with the same display label when configuring a user interface page.

The API name, used in your Groovy scripts, is also automatically generated for a field by taking the logical name and appending _c. Don't use special characters in the API name. Also, the API name must be in English. Otherwise you won't be able to add the field to any page.

Name

Set this property for all field types.

Description

A unique field description for internal use only.

Name

Set this property for all field types.

Required

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

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

Default values are not necessary for required fields. However, you must expose all required fields on the object's creation and details (update and edit) pages wherever those pages appear (such as on the desktop, simplified, mobile, or Outlook UI). Required fields without any default values are automatically added to an object's creation pages. However, required fields with default values must be added manually to creation pages. Also, required fields are not automatically added to details pages; you must add them manually. This lets your users populate the fields at runtime.

The object's web services also reflect the required fields when your sandbox is published to the mainline metadata.

Constraints

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

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

Updatable

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

If you write an expression to control whether a field is updatable, 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 runtime.

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 criterion 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

Index the field to speed up the performance of saved searches in the different object work areas. The global search is not affected.

Use this option only on the most frequently searched custom fields because, to ensure search performance, the number of fields you can index is limited:

  • For standard objects, you can index two text fields and three number fields (shared among number, percentage, and currency fields). Note that you can index up to 8 number fields for the Opportunity object, and up to 16 number fields for the Sales Lead object.

  • For custom parent objects, you can index 10 text fields and 15 number fields (shared among number, percentage, and currency fields). For custom child objects, you can index 10 text fields and 10 number fields.

  • Dynamic choice list fields and relationships automatically use 1 indexed number field. If all indexed number fields are already taken, then Application Composer uses a non-indexed number field. If a tab or BI analysis is based off a dynamic choice list field or other relationship, then create that relationship first to ensure you obtain an indexed number field. This ensures optimal performance for your tab or analysis.

You cannot change this property after the field is created.

Constraints

Set this property for the following field types:

  • Text

  • Number

  • Date

  • Datetime

  • Currency

  • Percentage

You cannot index the following field types:

  • Long Text

  • Formula

  • Check Box

  • Fixed Choice List

  • Dynamic Choice List

Include in Service Payload

Specify whether the field value can be included in a web service request or response.

Constraints

Set this property for all field types.

Fixed Value

Specify a literal default value for the field.

Do not assign a literal default value to fields that are both required and intended to be unique, as a runtime error can 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 runtime.

Default Value

Set this property for all field types except:

  • Check Box

  • Formula

  • Fixed Choice List

  • Dynamic Choice List

For these field types, write server scripts.

How Field 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 Extensibility Framework to provide you with the maximum flexibility when extending your 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 and formula fields.

Extensible Properties for Standard Fields

The extensible field properties that are available for a standard field are listed in this table.

Field Property Field Property Region

Required

Indicate if the field is required. You can also optionally use the expression builder to write an expression that specifies the conditions that must apply for this field to be required. If a standard field is already set to required by Oracle, however, then you can't change the field to be not required.

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

Default values are not necessary for required fields. However, you must expose all required fields on the object's creation and details (update and edit) pages wherever those pages appear (such as on the desktop, simplified, mobile, or Outlook UI). Required fields without any default values are automatically added to an object's creation pages. However, required fields with default values must be added manually to creation pages. Also, required fields are not automatically added to details pages; you must add them manually. This lets your users populate the fields at runtime.

The object's web services also reflect the required fields when your sandbox is published to the mainline metadata.

Constraints

Updatable

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

If you write an expression to control whether a field is updatable, 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 runtime.

Constraints

Defining User Interface Properties of Fields

Use Application Composer to define a field as Required, Updatable, or Hidden at the layout level. Setting these user interface (UI) field properties helps reduce the number of layouts. You can also use expressions (rules) to mark a field conditionally required, conditionally updatable, or conditionally hidden. Fields without conditional hide and show capabilities may result in a large number of layouts. You can change the field properties for individual layouts or perform a mass update of the field properties across multiple layouts.

The following scenarios explain the different UI properties you can define for a field:

  • Required: When a contact is created for a field sales representative, a phone number or an email is required. However, if the contact is created by a web service or imported from an external system, such enforcement may or may not be in place. You cannot make the Email field a required field at the model layer, but you can choose to enforce it in the layout by setting the Required property.

    See Setting the Required Field Property: Worked Example for an example on how to define the Required property.

  • Updatable: You can make certain fields read-only for partner users by having separate layouts for partner and internal users, with the Updatable property defined differently for each layout.

    See Setting the Updatable Field Property: Worked Example for an example on how to define the Updatable property.

  • Hidden: Consider a field named Shipping Method with values: Air, Land, and Sea. When the Shipping Method field is set to Land, a Land Transportation field appears with values: Train or Truck. The Land Transportation field does not appear if the Shipping Method field is not set to Land. You can add the fields to all layouts and make the Land Transportation field conditionally hidden or shown using the Hidden property. This way you can avoid creating multiple layouts.

    See Setting the Hidden Field Property: Worked Example for an example on how to define the Hidden property.

To edit the user interface (UI) properties of a field:

  1. Navigate to Application Composer.

  2. Expand the object whose page layout you want to make changes to.

  3. Click the Pages node.

  4. In the Details Page Layouts section, select the page layout that you want to update.

  5. Click the field whose properties you want to set or edit.

    Note: Fields that already have property settings configured display an icon next to them.

    The Edit UI Properties page appears with the current properties of the field listed in the Field Definition section.

  6. In the Layout Properties section, specify or edit the Required, Updatable, and Hidden properties as required for the current layout.

    Values available for the properties are listed below:

    Property Values

    Required

    • Yes

    • No

    • Expression

    Updatable

    • Yes

    • No

    • Expression

    Hidden

    • No

    • Expression

  7. To set a a rule for a property using an expression:

    1. Select Expression as the value.

      An expression builder icon appears next to the property.

    2. Click the Expression Builder icon to open the Advanced Expression dialog and enter the expression.

    3. Click OK.

      The expression you enter appears as read-only text next to the property on the Edit UI Properties page. If you select expression and do not enter any expression, an error message appears.

  8. Click Save and Close.

  9. Click Done on the Details Layout page.

The edited field is updated for the current layout.

To perform a mass update of the UI properties of a field across multiple layouts:

  1. Navigate to Application Composer.

  2. Expand the object whose page layouts you want to make changes to.

  3. Click the Pages node.

  4. On the Simplified Pages tab, click Actions from one of the page layout sections, and then select Edit UI Properties from the drop-down list.

    The Edit UI Properties page appears.

  5. Select the field whose properties you want to change.

    The Field Definition section displays the current properties of the field at the model level.

  6. The Layout Properties section displays all the active layouts for the field, where you can select multiple layouts on which the field properties can be edited. Select the layouts that you want to update.

  7. Click Update.

    The Update Layouts page appears.

  8. In the Layout Properties section, specify or edit the Required, Updatable, and Hidden properties as required for the selected layouts.

  9. Click Submit.

    The Edit UI Properties page appears.

  10. Click Done.

The field is updated across the selected layouts.

For a worked example on how to edit field properties across layouts, see Editing Field Properties across Multiple Layouts: Worked Example.

This example demonstrates how to make a field conditionally required using the Required property. For example, consider a custom object named Deal Registration that contains a Partner Justification field. Your requirement is that the Partner Justification field always appears as a mandatory field, but only for partner users.

The following example illustrates how to set the Partner Justification custom field as conditionally required for partner users.

Making a Field Conditionally Required
  1. Navigate to the Details Page Layouts section of the Deal Registration object.

  2. Select Default Custom Layout.

    The Details Layout page appears.

  3. Click the Partner Justification field.

    The Edit UI Properties page appears.

  4. In the Layout Properties section, select Expression from the drop-down list of the Required property.

    The Expression Builder icon appears next to the property.

  5. Click the Expression Builder icon.

    The Advanced Expression page appears.

  6. Enter the following expression in the Edit Script section:

    def secCtx = adf.context.getSecurityContext()
    if (secCtx.isUserInRole('ORA_ZPM_PARTNER_SALES_REPRESENTATIVE_JOB'))
    return true
    else
    return false

  7. Click OK.

    The Edit UI Properties page appears with the expression next to the Required property.

  8. Click Save and Close.

  9. On the Details Layout page, click Done.

    The Partner Justification field now appears as a required field in the edited layout for partner users.

The following example explains how you can set fields of a layout to be read-only or updatable. For example, consider a custom layout created for the Ticket object, named Closed Ticket, which only applies when the status of the ticket is closed. Here, Ticket is a custom object that can be created. To implement this worked example, use a custom object created in your own environment.

The following steps define how to set the Ticket Name, Priority, and Status fields of the custom layout as read-only and to set the Close Comments field to updatable.

Note: By default, the fields are updatable
Defining Fields as Read-Only
To change the status of the Ticket Name, Priority, and Status fields to Read-Only:
  1. Navigate to the Details Page Layouts section of the Ticket object.

  2. Select Closed Ticket Layout.

    The Details Layout page appears.

  3. Click the Ticket Name field.

    The Edit UI Properties page appears.

  4. In the Layout Properties section, select No from the drop-down list of the Updatable property.

  5. Click Save and Close.

  6. Repeat for Priority and Status fields.

  7. Click Done on the Details Layout page.

    The Ticket Name, Priority, and Status fields are now read-only for the edited layout and the Close Comments field is updatable by default.

Consider a new custom layout created for the Opportunity object with an Opportunity Type custom field. The Opportunity Type field is a fixed choice list with values: Purchase, Lease, and Trade in. When the Opportunity Type is Trade in, a Trade in value is required. So, the Trade in Value field should appear only when the Opportunity Type field is set to Trade in. You can do so by defining the Hidden property.

Making a Field Conditionally Hidden

To set the Hidden property for the Trade in Value field:

  1. Navigate to the Details Page Layouts section of the Opportunity object.

  2. Select New Custom Layout.

    The Details Layout page appears.

  3. Click the Trade in Value field.

  4. In the Layout Properties section, select Expression from the drop-down list of the Hidden property.

    An Expression Builder icon appears next to the property.

  5. Click the Expression Builder icon.

    The Advanced Expression page appears.

  6. From the Depends On field drop-down list, select Opportunity Type.

  7. Enter the following expression in the Edit Script section:

    if (OpportunityType_c == 'TRA') return false;
    else
    return true;

  8. Click Ok.

    The Edit UI Properties page appears with the expression next to the Hidden property.

  9. Click Save and Close.

  10. Click Done on the Details Layout page.

    The Trade in Value field now appears only when the Opportunity Type field is set to Trade in for the current layout.

Consider a custom object named Ticket for which you want your users to always enter an account while creating a ticket, but not when they are importing a ticket from an external source. To do this, you can set the Account field as required across all the creation page layouts. Here, Ticket is a custom object that can be created. To implement this worked example, use a custom object created in your own environment.

This example illustrates how to perform a mass update of the UI properties of the Account field across the creation page layouts.

Performing a Mass Update of the UI Properties of a Field
  1. Navigate to the Creation Page Layouts section of the Ticket object.

  2. Click Actions and select Edit UI Properties from the drop-down list.

    The Edit UI Properties page appears.

  3. Select the Account field from the drop-down list.

    The Field Definition section displays the current properties of the field at the model level. Note that the Required property is set to No.

    The Layout Properties section displays all the active layouts for the field.

  4. In the Layout Properties section, select all the layouts.

  5. Click Update.

    The Update Layouts page appears.

  6. In the Layout Properties section, set the Required property to Yes.

  7. Click Submit.

    The Edit UI Properties page appears.

  8. Click Done.

    The Account field is now updated as a required field across the selected layouts.

To view all the various settings defined for a field:

  1. Navigate to Application Composer.

  2. Expand the object whose field settings you want to view.

  3. Click the Pages node.

  4. On the Simplified Pages tab, click Actions from one of the page layout sections, and then select Edit UI Properties from the drop-down list.

    The Edit UI Properties page appears.

  5. Select the field whose settings you want to view.

The Field Definition section displays the current properties of the field at the model level. The Layout Properties section displays all the active layouts for the field.

Here you can edit the field properties across multiple layouts. See Editing User Interface Properties of a Field across Multiple Layouts: Procedure.

Check Box Fields: Explained

Using Application Composer, you can extend your application's object model by adding fields to both standard or custom objects. One such field is a check box: users in the run time application can select it to indicate a record's true or false attribute.

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 table shows properties that are common across multiple field types:

Field Property Field Property Region

Label

Appearance

Help Text

Appearance

Name

Name

Description

Name

Required

Constraints

Updatable

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.

  • An object can have a total of 625 fields. Of these, 350 are reserved for text and check box fields, and fixed and dynamic choice lists.

Currency Fields: Explained

Using Application Composer, you can extend an application's object model by adding new fields to both standard or custom objects. One such field is a currency 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 table shows properties that 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

Updatable

Constraints

Searchable

Constraints

Indexed

Constraints

Fixed Value

Default Value

Expression

Default Value

The following table shows properties that are unique to certain field types, including currency fields:

Field Property Field Property Region

Maximum Length

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

The maximum length is the total number of digits that the currency field can have. Decimal places are validated against what is configured for the currency code in Setup and Maintenance. Refer to the following section for setup instructions.

Constraints

Minimum Value

The minimum numeric value that a user can enter into this field.

Constraints

Maximum Value

The maximum numeric value that a user can enter into this field.

Constraints

Additional Currency Field Specifications

Additional specifications for this field type include the following details:

  • Data type is NUMBER.

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

    Note: Each currency field uses two number type columns: one stores the amount itself, and the other stores the currency conversion rate that is calculated from the entered amount's currency code to the corporate currency code.
  • An object includes the following fields to assist with currency conversion. These fields are automatically added to an object if the object's application allows the creation of currency fields. They are derived from the application's corporate currency setup.

    • Currency code

      The currency code for all of an object's currency fields.

    • Corporate currency code

    • The 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. Note, however, that the currency amount displayed on the application page will not change.

    Note: When you run a report based on a custom subject area that uses a currency field, the report does display your preferred currency based on the current exchange rate. Again, this is different from how currency amounts are displayed at run time on application pages, because currency fields only ever display in the entered amount, even if the currency conversion rate for the record changes.
  • Precision, or the number of decimal points, for a currency field is derived from the currency code itself. To set the precision for a currency code:

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

      • Offering: Sales

      • Functional Area: Sales Foundation

      • Task: Manage Currencies (under All Tasks)

        The Manage Currencies page appears.

    2. In the Currency Code field, enter a currency code, such as JPY.

    3. In the Search Results region, expand the currency code and enter a number into the Precision field.

      For example, to display two decimal places for currency fields based on JPY, enter 2 in the Precision field for the JPY currency code.

Date Fields: Explained

Using Application Composer, you can extend an application's object model by adding fields to both standard or custom objects. One such field type is a date field, where users in the run time application can enter a date or select one 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 table shows properties that are common across multiple field types:

Field Property Field Property Region

Label

Appearance

Help Text

Appearance

Name

Name

Description

Name

Required

Constraints

Updatable

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.

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

  • When you create a custom subject area 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 application's object model by adding new fields to both standard or custom objects. One such field type is datetime, where users in the run time application can enter a date or select one from a calendar, and enter a time of day.

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 table shows properties that are common across multiple field types:

Field Property Field Property Region

Label

Appearance

Help Text

Appearance

Name

Name

Description

Name

Required

Constraints

Updatable

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 these, 50 are reserved for date and datetime fields.

  • When you create a custom subject area 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

Dynamic Choice Lists: Explained

Using Application Composer, you can extend an 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: You must create a Select and Search dialog box 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 table shows properties that 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

Updatable

Constraints

Searchable

Note: If you plan to expose this dynamic choice list as a subtab on the related object's details page, then you must make this field searchable.

Constraints

The following table shows properties that 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 runtime.

Note: Although you can configure what data will display in the list of values at runtime, you cannot control the sequence of where those values display in the list.
  • 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 field that you want to display within the dynamic choice list as the first column at runtime. 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

      From the List Selection Display Value choice list, select the related object's field that you want to display within the dynamic choice list as the first column at runtime. 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.

      Note: The fields available for selection include only the related object's required fields.
    • Data Filter

      You can further refine the set of data that appears within the dynamic choice list at runtime by using data filters. You can set up a simple filter to show only a subset of records in the list of values at runtime. Or, you can set up a more complex expression that dynamically filters the subset of records based on the object context. You can also use an existing filter that is predefined for some standard objects.

      Ideally, set data filters on a dynamic choice list during the initial configuration of the field.

      For example, use a simple filter to hide any accounts outside a particular region. Or, hide account records that are inactive. At runtime, only active accounts would appear in the dynamic choice list field.

      Tip: To optimize performance, refine the list of values displayed in this field at runtime by including one or more filters based on indexed fields.

      To learn more about data filters, see "Understanding Data Filters for Dynamic Choice Lists: Explained."

  • 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 region to include additional related object fields in the dynamic choice list at runtime. These additional fields assist your users in making a selection from the choice list. The region 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 region to include additional related object fields in the dynamic choice list's Search and Select dialog, accessed using the Search link at runtime. The region 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, then at runtime, then 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 are in a global single instance environment and you create a dynamic choice list between a sales and service object and a common object: resource, customer contact profile, account, address. In such cases, relationships are not implicitly created.
Groovy Script Syntax

Once a one-to-many relationship is created between objects using a dynamic choice list field, a foreign key field is created on the "many" object. Use the API names listed in the following table to access those foreign keys in your scripts.

Relationship Type Foreign Key API Name Pattern Used

Dynamic choice list relationship

If the dynamic choice list field name is DynChoice1_c, then the foreign key API name is DynChoice1_Id_c.

<Name of the dynamic choice list field>_Id_c

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.

  • Dynamic choice list fields and relationships automatically use 1 indexed number field. If all indexed number fields are already taken, then Application Composer uses a non-indexed number field.

    If a subtab or BI analysis is based off a dynamic choice list field or other relationship, then create that relationship first to ensure you obtain an indexed number field. This ensures optimal performance for your subtab or analysis.

Understanding Data Filters for Dynamic Choice Lists: Explained

Using Application Composer, you can add a dynamic choice list field to a custom or standard object. A dynamic choice list is a field that contains a list of values which are populated from the actual data of another object. You can set up a simple filter on the field to show only a subset of records in the list of values at runtime. Or, you can set up a more complex expression that dynamically filters the subset of records based on the object context. You can also use an existing view criteria filter that is predefined for some standard objects. This topic explains how to use data filters with dynamic choice list fields.

Understanding Data Filters

When you first define a dynamic choice list, you indicate which related object's records populate the custom field's list of values. You can further refine the set of data that appears within the dynamic choice list at runtime by using data filters. Application Composer lets you define either a simple filter or an advanced filter. Or, use an existing view criteria filter that is predefined for some standard objects. Ideally, set data filters on a dynamic choice list during the initial configuration of the field.

To refine the set of data that appears within the dynamic choice list, you can select from one of three options:

  • Simple mode

  • Advanced mode

  • Existing filter

Tip: When defining a simple or advanced filter, use indexed fields to optimize performance.
Defining Simple Data Filters

A simple data filter uses static values that you provide as search criteria to refine the list of values at runtime. For example, when editing an opportunity, the list of accounts that display in the Account dynamic choice list can be filtered to show only active accounts.

To define a simple data filter:

  1. In Application Composer, create a custom dynamic choice list field.

  2. After you select the related object and the object's field that you want to display in the list of values, navigate to the Data Filter region.

  3. In the Data Filter region, click Add Search Field.

  4. Select the field that you want to use as the simple filter, then specify the criteria to apply at runtime.

    For example, if you select City, then specify a city name, such as New York.

    You can select more than one field.

  5. Complete the rest of the field's configuration, then click Submit.

The filter's static value is applied to the set of records in the dynamic choice list at runtime to refine the list of values.

Defining Advanced Data Filters

An advanced data filter uses dynamic criteria based on the object context to refine the list of values at runtime. As part of the advanced data filter, you can write Groovy expressions and accept bind variables.

To define an advanced data filter:

  1. In Application Composer, create a custom dynamic choice list field.

  2. After you select the related object and the object's field that you want to display in the list of values, navigate to the Data Filter region.

  3. In the Data Filter region, click the Advanced Mode link that displays in the instructions.

  4. Enter a search expression to refine the records that appear in the list of values. As you write your script:

    • Click Add Search Field to select appropriate fields.

    • Click Add Bind Variable to pass the target object context to the filtering expression.

      For example, when editing an opportunity, the list of contacts that display in the Contact dynamic choice list can be filtered by adding bind variables that pass context from the opportunity record to the Contact dynamic choice list.

  5. Check the When filtering data, ignore expressions involving null bind variable values check box.

    This check box defines the behavior of the expression when a bind variable evaluates to null. If this box is checked, then any atomic expression ("FieldName Operator Operand") whose bind variable evaluates to null is ignored. The other atomic expressions that are part of the filter remain.

    For example, when editing an opportunity, the list of contacts that display in the Contact dynamic choice list should display only the contacts of the opportunity record's specified account. However, if there is no account specified in the Account field, then all contacts should be displayed in the list of values. To achieve this, check the When filtering data, ignore expressions involving null bind variable values check box. If the box is not checked and no account is specified, then the Contact dynamic choice list will be empty.

  6. Complete the rest of the field's configuration, then click Submit.

Using Existing View Criteria Filters

When defining a data filter for a dynamic choice list, you can select from a predefined list of existing view criteria filters. These existing filters are the named view criteria that are already provided for some standard objects. Some standard objects may predefine named view criteria which you can use to simplify common searches.

To select an existing view criteria filter:

  1. In Application Composer, create a custom dynamic choice list field.

  2. After you select the related object and the object's field that you want to display in the list of values, navigate to the Data Filter region.

  3. In the Data Filter region, click the Existing Filter link that displays in the instructions.

  4. Select the desired filter.

  5. Complete the rest of the field's configuration, then click Submit.

Fixed Choice Lists: Explained

Using Application Composer, you can extend an application's object model by adding new fields to both standard or custom objects. One such field type is a fixed choice list, a field that contains a list of static values populated from FND lookup types. At runtime, 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 table shows properties that are common across multiple field types:

Field Property Field Property Region

Label

Appearance

Help Text

Appearance

Display Width

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

Appearance

Name

Name

Description

Name

Required

Constraints

Updatable

Constraints

Searchable

Constraints

Fixed Value

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

If the choice list allows multiple values, you can still write an expression to preselect multiple values by default.

For example, if the field includes three lookup codes with (Code,Label) of (S,Small),(M,Medium),(L,Large), and (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.

The data for the multi-select pick list is stored in comma-separated format; in the previous example, "S,XL" will be stored in the database.

Default Value

The following table shows properties that are unique to certain field types, including fixed choice lists:

Field Property Field Property Region

Display Type

Indicate if users can select a single value or multiple values from the choice list at runtime. You can only select the display type during field creation.

Note: If you create a multiple-select fixed choice list, then do not use commas in the lookup codes that populate this field.

Appearance

Lookup Type

You cannot create a Lookup Type with a name ending in "LOOKUPTYPE". If you do, you won't be able to see this extension in BI Answers and reporting.

List of Values

Constrain List by Parent Field Value Selection

List of Values

Selecting the List of Values for the Fixed Choice List

The values in a fixed choice list are populated from FND lookup types. Select the lookup type with values you want to display in this choice list. You can only select the lookup type during field creation. A fixed choice list can have a maximum of 1,000 values.

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

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

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

Mapping List Values to Parent Values

You can constrain the actual values that display in the fixed choice list at runtime by relating the 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 for specifying the trouble ticket type and one for specifying the trouble ticket area. If a user selects Hardware from the Type choice list, then the Area choice list should contain only hardware options that the trouble ticket can be logged against, such as Desktop or Laptop.

To do this, while creating the Area fixed choice list, select the Constrain List by Parent Field Value Selection check box, select the Type 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.

To implement the previous example:

  1. Define the Type fixed choice list.

  2. Define the Area fixed choice list.

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

      You can select the Constrain List by Parent Field Value Selection check box only during field creation, and only if at least one other single-select fixed choice list has been defined. After field creation, however, you can update the mapping between lookup values.

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

      After your users start using these fields to enter data, don't change a lookup type's lookup code values. For example, don't change LAPTOP_CODE to LAPTOP_CODE1. If you change a lookup type's lookup code values, then you will need to manually re-map all records that already reference the original code, as well as re-map the values between lookup types in the child fixed choice list.

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

  • An object can have a total of 625 fields. Of these, 350 are reserved for text and check box fields, and fixed and dynamic choice lists.

Formula Fields: Explained

Using Application Composer, you can extend an application's object model by adding fields to both standard or custom objects. One such field is a formula field, which is calculated in the runtime application using the Groovy-based expression included in the field's definition.

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 table shows properties that 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 table shows properties that are unique to 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. You can specify the type 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 runtime application as a simple text box, or 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 runtime.

This is a screenshot of the expression builder.

This list provides several examples on when to use the expression builder:

  • If your expression calculates the value of an employee's annual bonus amount, set the expression to automatically recalculate that amount if the employee's salary changes.

  • If your expression determines the correct customer phone number to use for an opportunity, set the expression to automatically reset the phone number if the opportunity's customer account changes.

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. 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 runtime. This is a transient type of attribute that does not persist in the database as a table column. Hence, no maximum number of formula fields exists for an object.

  • A formula field's Groovy script is evaluated every time the field's value is requested by any layer. You must not use a formula field to set other fields' values because, due to the order of rendering, the order in which the fields are processed is not guaranteed. If you want to write code that derives other field values when the value of some other field is changed, use the After Field Changed trigger documented in the Groovy Scripting Reference guide.

A join is a predefined association between an object and its related object. Joins use underlying, preexisting relationships already delivered with your cloud service. You use joins to add related object fields to an object's work area. Before you can do that, however, you must register those fields, either custom or standard, by creating join fields. (Join fields aren't provided automatically for you.)

Understanding Joins

Joins are view links between an object and another top-level object, which are already related through an existing many-to-one or one-to-one relationship. Joins let you display a related object's fields on an object's work area.

Note: You can't create joins or edit existing joins.

Why Use Joins?

Joins use preexisting relationships between an object and its related object. Joins give you more flexibility than relationships provide. With relationships, you can only add child or related object subtabs to an object's details page. Joins, on the other hand, let you add related object fields to any page of an object's work area, not just the details page.

For example, the Account object and the Opportunity object are related objects by default and are already delivered with a join. If you register the Account's Primary Phone field as a join field for the Opportunity object. You can now display that field anywhere on the Opportunity work area, such as on the Create Opportunity page or Opportunity landing page.

Tip: The other benefit of joins and join fields is that, at runtime, when your end users enter data into the Account Primary Phone field, the data is actually written to the underlying Account object.

Choosing a Join

To view the joins available for an object, expand the object and click the Joins node. For example, expand the Opportunity object, and click the Joins node. Select the desired join row and click Edit to navigate to the read-only Join Specification page, where you can review details about the join.

Joins are delivered by default for some objects. (Not every object has a Joins node.) For example, these objects are delivered with one or more joins:

  • Customer Contact Profile

  • Forecast Item

  • Opportunity

  • Partner

  • Product Group

  • Program Enrollments

  • Sales Account

    Note: The Sales Account object is available for change only to existing users from prior releases. If the Sales Account object is read only for you in Application Composer, then this means that you cannot extend the Sales Account object. Instead, use the Account object only.
  • Sales Lead Contact

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

To register a join field:

  1. Expand an object and click the Joins node.

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

Working with 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. There are some caveats about working with join fields, listed below.

  • Join fields that are based on a dynamic choice list field aren't exposed as searchable fields in Application Composer. This means that when you configure the local search, regional search, Search and Select dialog, or a context link subtab, join fields based on dynamic choice list fields aren't available for selection.

    However, you can still filter the records that display in an object's summary table by using the Query By Example feature. At runtime, click the Query By Example icon on the table's toolbar, and enter a value for the join field column.

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

Long Text Fields: Explained

Using Application Composer, you can extend an application's object model by adding fields to both standard or custom objects. One such field type a long text field, where users in the runtime 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 table shows properties that 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

Updatable

Constraints

Fixed Value

Default Value

Expression

Default Value

The following table shows properties that are unique to certain field types, including long text fields:

Field Property Field Property Region

Display Type

Indicate how you want this text field to render in the runtime application:

  • As a simple text box.

  • Allowing 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 these, 25 are reserved for long text fields.

  • The long text field type is unavailable for use with custom subject areas and Oracle Social Network:

    • Long text fields are not available for inclusion in custom reports.

    • Long text fields are not available for sharing in OSN conversations.

Number Fields: Explained

Using Application Composer, you can extend an application's object model by adding fields to both standard or custom objects. One such field is a number field, where users in the runtime 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 table shows properties that 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

Updatable

Constraints

Searchable

Constraints

Indexed

Constraints

Fixed Value

Default Value

Expression

Default Value

The following table shows properties that are unique to certain field types, including number fields:

Field Property Field Property Region

Decimal Places

The number of digits that can be entered and displayed to the right of the decimal point. If at runtime, a user enters more digits 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 runtime, an entry of 4.986 is displayed as 4.99.

Constraints

Maximum Length

The number of digits a user can enter in the field. This number should be greater than or equal to 1 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 must scroll inside the field at runtime 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

The minimum numeric value that a user can enter into this field.

Constraints

Maximum Value

The maximum numeric 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.

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

    Note: Of the 200 fields reserved for number, currency, and percentage fields, 15 fields are reserved for indexed number fields in a custom parent object (10 fields for custom child objects). This means you can create a total of 185 non-indexed fields.

    For standard objects, you can index two text fields and three number fields (shared among number, percentage, and currency fields). Note that you can index up to 8 number fields for the Opportunity object, and up to 16 number fields for the Sales Lead object.

  • Leading zeros are removed.

Percentage Fields: Explained

Using Application Composer, you can extend an application's object model by adding fields to both standard or custom objects. One such field type is a percentage field, where users in the runtime 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

Updatable

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

The number of digits that can be entered and displayed to the right of the decimal point. If at runtime, a user enters more digits 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 runtime, an entry of 4.986 is displayed as 4.99.

Constraints

Maximum Length

The maximum digits 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 must scroll inside the field at runtime 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 these, 200 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 your applications by adding new fields to both standard or custom objects. One type of field that you can add 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 type of field is useful, because 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.

Using Record Type Fields

Create a record type field, so that you can associate each choice list value with a role or a page layout.

You can:

  • Associate each choice list value with a role.

    1. You do this while you are creating the field.

    2. At runtime, when an end user views the list of values in the field, the available choices are constrained according to the user's role.

    Custom roles, which are copies of the predefined roles that Oracle provides for all customers, are displayed by default. However, you can optionally choose to display predefined roles, as well.

  • Associate each choice list value with a page layout.

    1. You do this by adding the field to a simplified page layout, after you have created the field.

    2. You must then assign a choice list value to the page layout.

    3. At runtime, when an end user selects a value from the field, the page display changes to match the simplified page layout that you associated with the choice list value.

Note: You can create only one record type field per object, and only once the object has a work area.

If the object's work area hasn't been created yet, then you must create the work area first, before creating the record type field.

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

Updatable

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

Selecting the lookup type is possible only during field creation.

List of Values

Available Record Types

Indicate the choice list values that each role has access to.

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

Roles

Default Record Type

Indicate the choice list value that each role will see by default at runtime.

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.

You can also select a lookup type and select the Edit icon to modify the existing values.

Note: The lookup types available for selection are limited to:
  1. Standard lookup types that are related to this record type field's object (by product code).

  2. All custom lookup types that have been created for your implementation.

Or, create a new lookup type and add new values to it.

Additional Record Type Field Specifications

Additional specifications for this field type include the following details:

  • Data type is VARCHAR2 (1500).

  • A record type field is optional, and is not required for an object.

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

Text Fields: Explained

Using Application Composer, you can extend an application's object model by adding new fields to both standard or custom objects. One such field type is a text field, where users in the runtime 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

Updatable

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

The way you want this text field to render in the runtime application:

  • As a simple text box.

  • Allowing multiple lines where text can wrap or where the user can enter carriage returns.

Appearance

Maximum Length

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 part of the total.

Note: The 1500-character limit applies if the characters are single byte. If the characters are multibyte, such as Japanese or Chinese, then the maximum character limit is 1500 characters divided by the number of bytes per multibyte character. For example, if characters are 2 bytes, then the name is limited to a maximum of 750 characters. If a mix of characters is used, then 1500 is the maximum sum of character bytes that is supported.

Constraints

Minimum Length

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. Of these, 350 are reserved for text and check box fields, and fixed and dynamic choice lists.

Enable Service Request Tagging

The Tag field is not displayed automatically on Service Request (SR) pages. The Tag field is predefined, but it's not added to any of the predefined standard layouts. If you want the Tag field to be available to all users, you must add it to your administrator-defined layout and publish it.

If tags are enabled and exposed, end users can create their own tags. Tags aren't striped by business unit. Therefore, all tags are visible to all users.

To enable tags so that the Tag field is displayed when creating or editing SRs:

  1. Modify the corresponding page layout in Application Composer by adding the Tag field to the Service Request Summary page.

    For more information about modifying the page layout in Application Composer, see the information about extending simplified pages in the Oracle Engagement Cloud Extending Sales and Service guide.

  2. Publish the sandbox.

Tags are now enabled and the Tag field is available. Anyone who has the Edit Service Request privilege can add a tag.

Create Predefined Tags for Service Requests

As an administrator, you have the option to create predefined tags that are visible to the end users. End users can also create tags at runtime to suit their needs.

Based on common requirements, you can create tags such as performance and setup. You can then send a notification to the agents suggesting that they use these predefined tags. For example, for service requests related to performance, use the performance tag.

To create an administrator-defined tag:

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

    • Offering: Service

    • Functional Area: Productivity and Tools

    • Task: Manage Tags

    The Manage Tags page is displayed, and it shows the list of existing administrator-defined tags and user-defined tags.

  2. Click Create.

  3. In the Create Tag dialog box, specify a tag name in the Tag field.

  4. Click Save and Close.

The new tag appears on the Manage Tags page.

Import and Export Tags

You can export the administrator-defined tags from your test environment to your production environment by using the import-export feature in Functional Setup Manager. User-defined tags can't be imported and exported. Many tags may be created for testing in the test environment, but it's not required to migrate all the tags to production.

For more information about importing and exporting setup data, see the Oracle Applications Cloud Using Functional Setup Manager guide.

If you export your setup data by using an Implementation Project, then the administrator-defined tags are exported with the rest of the tasks in the Implementation Project in the following cases:

  • Your Implementation Project includes the Productivity Tools Functional Area.

  • You explicitly include the Manage Tags task.

Delete Tags

You can delete tags that are no longer required. For example, tags with typos. When you delete a tag, it's removed from all the associated service requests and is then deleted.

To delete a tag:

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

    • Offering: Service

    • Functional Area: Productivity Tools

    • Task: Manage Tags

    The Manage Tags page is displayed, and it shows the list of existing administrator-defined tags and user-defined tags.

  2. Select the row with the tag that you want to delete.

  3. Click Delete.

    A message is displayed, stating that all the references to the tag will be removed.

  4. Click Delete to delete the tag.

You can add actions, such as buttons and menu items, 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.

Actions and Links

You can base an action on a script (a Groovy method that is defined on the object) or on a URL defined by a script. After you create an action, it can be exposed as a button or an option on the Actions menu. A button can perform an action or navigate the user to another page in the runtime application, or to another Web site. For example, you might want to include a button on a summary table, which users can click at runtime 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.

After you create a link, it can be selected as a field for display at runtime. For example, you might want to provide a static link from an overview page to a corporate Web site.

Adding Actions or Links: Overview

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 a user interface page, such as a list page or details page.

    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 Create and Edit subtabs.

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.

Defining Actions or Links

To define an action or link for an object:

  1. On the main Overview page in Application composer, select a standard or custom object in the object tree.

  2. Select the Actions and Links node.

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

  4. In the Type field, select either Action or Link.

  5. In the Source field, select either Script or URL.

  6. In the Script region click the New icon to build your script.

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

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

      When creating custom actions based on a script for top-level custom objects, you can specify how you would like the action to conclude at runtime, after the script completes:

      • Save the record and return to the previous page (save and close)

      • Save and continue editing the record (save and continue)

      • Perform the action but don't save the record (run the script only)

Points to consider when defining actions:

  • If you define a custom action and expose it on a list, ensure that you include a check for active record row, and that the UI supports users selecting any record as the active row before invoking the custom action.

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

Exposing Actions or Links on Pages

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.

When displaying a link, you select it just as you select to display standard or custom fields. This is because, at runtime, the UI displays the URL link as if it is a field in a table.

For example, the following figure shows a link and other fields that are already selected for display 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.

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.

The figure below shows the Configure Summary Table: Actions region, with options checked for the Show Create, Show Edit, and Show Delete options on the Action menu. You can also display the action, Ask_Assistance, as either a button or action menu item.

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 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 with a custom link.

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.
Tip: To support functions that don't need to be displayed prominently on the page, add actions as options on the Actions menu. To support key functions that are frequently executed by your users, add actions as buttons.

When displaying actions as buttons, be sure to test your page at runtime (in all supported languages) to confirm that the presentation of buttons is as expected. Button display could be unexpected due to the available space on the page at runtime, the number of buttons on the page, and button width (which depends on label length). If you add more buttons than the toolbar has space, then at runtime the buttons are stacked and made available using a drop-down button.

Overflow buttons available through a drop-down
button

You can display actions as either buttons or Actions menu items in a variety of locations:

  • Simplified pages

  • Summary table on the overview page

  • Default summary on the details page

  • Summary table on a details page's subtab

  • Revenue table on the details page for the opportunity object

Note: If you create a custom button on a table that appears on a simplified UI page, and that table has no rows, then the button is automatically disabled.

You can display links for an object in 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

Deleting Unpublished Actions and Links

You can use Application Composer to delete any unpublished actions and links. Any exposure of the actions (as UI buttons or action menus) and links (as fields) in the same object's extensible pages or as a detailed subtab under another object's page are also automatically deleted.

To delete unpublished actions or links for an object:

  1. On the main Overview page in Application Composer, expand the standard or custom object whose actions or links you want to delete.

  2. Select the Actions and Links node.

    Application Composer lists all the actions and links defined for the selected object.

  3. Select the action or link that you want to delete and click the delete icon.

  4. Click OK on the confirmation dialog.

  5. To verify that the deleted actions and links no longer appear in the object's pages, click the Pages node and review the page layouts.

Direct Page Links: Explained

Direct page links are links that point to a specific page. In any e-mail, report, or user interface page, you can add a link that opens an account, contact, household, opportunity, lead, activity, or top-level custom object record. When linking to a simplified page, the link opens a specific tab at the top level of an object's simplified set of pages.

This topic covers:

  • List of objects that support direct page linking to both desktop and simplified pages.

  • URL pattern to use for direct page linking.

    The URL pattern is translated by the Direct Page Link servlet in the middle tier which reads the incoming request parameters, generates a new URL, and redirects the request to the target page.

  • Where can you use these links?

  • How user authentication provides secured access to the target page.

Objects That Support Direct Page Linking

The objects that support direct page linking differ depending on whether you link to simplified or desktop pages.

You can link to the simplified pages for the following objects. The link that you build opens a tab at the top level of an object's simplified set of pages. Some objects support linking directly to a subtab.

  • Account

  • Activity

  • Contact

  • Household

  • Lead

  • Opportunity

  • Custom object

  • Partner

  • Deal registration

  • Fund request

  • Claim

Note: You can also link directly to the simplified UI dashboard and to the Analytics landing page.

You can link to the desktop details pages for the objects listed below. The details page is part of an object's work area where you view the details about a record.

  • Contact

  • Customer

  • Lead

  • Opportunity

URL Pattern to Use for Direct Page Links to Simplified Pages

The direct page link URL uses a simple pattern which points to a default tab at the top level of an object's simplified set of pages. Some objects support linking directly to a subtab.

Depending on the object you are linking to, use the following syntax to create a direct page link:

https://<hostname>:<port>/<application>/faces/FuseOverview?fndGlobalItemNodeId=<CARDCODE>&fndTaskItemNodeId=<TABCODE>&fnd=%3B<TaskFlowParamName1>%253D<TaskFlowParamValue1>%253B<TaskFlowParamName2>%253D<TaskFlowParamValue2>%253B<TaskFlowParamName3>%253D<TaskFlowParamValue3>%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

Tip: Copy the first part of the URL, https://<hostname>:<port>/<application>/faces/FuseOverview?, from the customer instance's actual home page.

The taskFlowParamName and taskFlowParamValue pairs are optional and are typically used for record identifiers.

In some cases, an additional parameter, subTabName, is also included in the URL. Where supported, this additional parameter allows direct links to the specified subtab.

Tip: Direct page links created in a release prior to Release 10 used a different link pattern. However, those direct page links created prior to Release 10 will continue to work in Release 10 and later.

Use the patterns specified as follows to link to the simplified pages for these objects:

  • Account.

    For this object, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fndGlobalItemNodeId=ZCM_CUSTOMERCTRINFRA360_CUSTOMERS_CRM_CARD&fndTaskItemNodeId=ZCM_CUSTOMERCTRINFRA360_CUSTOMERS_CRM&fnd=%3BsubTabName%253DOverview%253BAccountPartyId%253D<recordID,such as 123456>%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

    This direct page link opens the Overview subtab on the Edit Account simplified page.

    To link to other Edit Account subtabs, change the value for the parameter subTabName to one of the following values for each subtab, such as &fnd=%3BsubTabName%253DProfile.

    • Overview

    • Profile

    • SalesAccountTeam

    • Contacts

    • Assets

    • Opportunities

    • Quotes

    • Leads

    • Relationships

    • Recommendations

    • Notes

    • Activities

    • Conversations

  • Activity.

    For this object, use this direct page link URL pattern to open a list of all activities:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fndGlobalItemNodeId=ZMM_ACTIVITIES_CRM_CARD&fndTaskItemNodeId=ZMM_ACTIVITIES_ACTIVITIES_CRM%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

    To link to a specific activity (appointment or task), append the record's primary key as follows: https://<hostname>:<port>/<application>/faces/FuseOverview?fndGlobalItemNodeId=ZMM_ACTIVITIES_CRM_CARD&fndTaskItemNodeId=ZMM_ACTIVITIES_ACTIVITIES_CRM&fnd=%3BFunctionCode%253DTASK%253BActivityId%253D<recordID,such as 123456>%253B%3B%3B%3Bfalse%3B256%3B%3B%3B.

    You can also link directly to specific types of activities by changing the value for the parameter &fndTaskItemNodeId to one of the following values:

    • Link to a list of all tasks:

      Use pattern: &fndTaskItemNodeId=ZMM_ACTIVITIES_TASKS_CRM

    • Link to appointments (calendar view):

      Use pattern: &fndTaskItemNodeId=ZMM_ACTIVITIES_APPOINTMENTS_CRM

  • Contact.

    For this object, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fndGlobalItemNodeId=HZ_FOUNDATIONPARTIES_CONTACTS_CRM_CARD&fndTaskItemNodeId=HZ_FOUNDATIONPARTIES_CONTACTS_CRM&fnd=%3BsubTabName%253DOverview%253BContactPartyId%253D<recordID,such as 123456>%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

    This direct page link opens the Overview subtab on the Edit Contact simplified page.

    To link to other Edit Contact subtabs, change the value for the parameter subTabName to one of the following values for each subtab, such as &fnd=%3BsubTabName%253DProfile.

    • Overview

    • Profile

    • Team

    • Opportunities

    • Leads

    • Assets

    • Relationships

    • Recommendations

    • Notes

    • Activities

    • Conversations

  • Household.

    For this object, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fndGlobalItemNodeId=ZCM_CUSTOMERCTRINFRA360_GROUPS_CRM_CARD&fndTaskItemNodeId=ZCM_CUSTOMERCTRINFRA360_GROUPS_CRM&fnd=%3BsubTabName%253DOverview%253BHouseholdPartyId%253D<recordID,such as 123456>%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

    This direct page link opens the Overview subtab on the Edit Household simplified page.

    To link to other Edit Household subtabs, change the value for the parameter subTabName to one of the following values for each subtab, such as &fnd=%3BsubTabName%253DProfile.

    • Overview

    • Profile

    • SalesAccountTeam

    • Contacts

    • Opportunities

    • Assets

    • Leads

    • Relationships

    • Notes

    • Activities

    • Conversations

  • Lead.

    For this object, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fndGlobalItemNodeId=MKL_LEADS_CARD&fndTaskItemNodeId=MKL_LEADS&fnd=%3BsubTabName%253DSUMMARY%253BLeadId%253D<recordID,such as recordID, such as 123456>%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

    This direct page link opens the Summary subtab on the Edit Lead simplified page.

    To link to other Edit Lead subtabs, change the value for the parameter subTabName to one of the following values for each subtab, such as &fnd=%3BsubTabName%253DNOTES.

    • SUMMARY

    • CONTACTS

    • QUALIFICATIONS

    • SALESTEAM

    • ACTIVITIES

    • RESPONSES

    • NOTES

    • OPPORTUNITIES

    • CONVERSATIONS

    • Analytics_1

    • Analytics_2

    • Analytics_3

  • Opportunity.

    For this object, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fndTaskItemNodeId=MOO_OPPTYMGMTOPPORTUNITIES_CRM&fndGlobalItemNodeId=MOO_OPPTYMGMTOPPORTUNITIES_CRM_CARD&fnd=%3BsubTabName%253DQuotes%253BskipToEditOptyId%253D<recordID,such as 123456>%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

    This direct page link opens the Quotes subtab on the Edit Opportunity simplified page.

    To link to other Edit Opportunity subtabs, change the value for the parameter subTabName to one of the following values for each subtab, such as &fnd=%3BsubTabName%253DNotes.

    • Summary

    • Quotes

    • Contact

    • OpptyTeam

    • OpptyPartner

    • Activities

    • Notes

    • Assessments

    • Leads

    • Conversations

    You can also link directly to Analytics tabs off the Opportunities landing page, by replacing the fndTaskItemNodeId value with these values:

    • MOO_OPPTY_ANALYTICS1_CRM

    • MOO_OPPTY_ANALYTICS2_CRM

    • MOO_OPPTY_ANALYTICS3_CRM

  • Custom object.

    • To create a direct link to the default summary tab for a custom object, use this direct page link URL pattern:

      https://<hostname>:<port>/<application>/faces/FuseOverview?fndGlobalItemNodeId=CRM_CUSTOM_CARD_<XXXX>&fndTaskItemNodeId=CRM_CUSTOM_TAB_<XXXX>&fnd=%3BsubTabName%253DSUMMARY%253BObjectId%253D<YYYY>%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

      • Copy the first part of the URL, https://<hostname>:<port>/<application>/faces/FuseOverview?, from the customer instance's actual home page.

      • Replace XXXX with the custom object's API name using all upper case letters including _C. For example, TROUBLETICKET_C. Obtain the API name from the object's overview page (click the object's node in the Custom Objects tree in Application Composer).

      • Replace YYYY with the custom object's primary key in the database.

    • To create a direct link to a different subtab, replace "SUMMARY" with the subtab's Component ID. This is an automatically generated ID which you can find by viewing the details page layout where the custom subtab exists.

      This is a screenshot of the location where you can find
the subtab's Component ID.
  • Partner

    For this page, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?ZPM_PARTNERS_CARD&findTaskItemNodeId=ZPM_PARTNERS&find=%3BpartyId%253D100000151014782%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

  • Simplified UI dashboard.

    For this page, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fndGlobalItemNodeId=CRM_FUSE_DASHBOARD_CARD&fndTaskItemNodeId=CRM_DASHBOARD%253D123456%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

  • Analytics.

    For this page, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fndGlobalItemNodeId=CRM_FUSE_ANALYTICS_CARD&fndTaskItemNodeId=CRM_ANALYTICS%253D123456%253B%3B%3B%3Bfalse%3B256%3B%3B%3B

  • Deal registration

    For this page, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fnd=%3BDealId%253D300100072550501%253BsubTabName%253DSUMMARY%3B%3B%3Bfalse%3B256%3B%3B%3B&fndGlobalItemNodeId=MKL_DEALREGS_CARD&fndTaskItemNodeId=DEALREGS

  • Fund request

    For this page, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fnd=%3BFundRequestId%253D300100089921736%253BsubTabName%253DSUMMARY%3B%3B%3Bfalse%3B256%3B%3B%3B&fndGlobalItemNodeId=itemNode_partner_management_mdf&fndTaskItemNodeId=MKT_MDF_FUNDS_CRM&_afrLoop=169172444586792&_afrWindowMode=0&_afrWindowId=null&_adf.ctrlstate=15rswocd3x_105&_afrFS=16&_afrMT=screen&_afrMFW=1600&_afrMFH=799&_afrMFDW=1600&_afrMFDH=900&_afrMFC=8&_afrMFCI=0&_afrMFM=0&_afrMFR=96&_afrMFG=0&_afrMFS=0&_afrMFO=0

  • Claim

    For this page, use this direct page link URL pattern:

    https://<hostname>:<port>/<application>/faces/FuseOverview?fnd=%3BClaimId%253D300100089921747%253BsubTabName%253DSUMMARY%3B%3B%3Bfalse%3B256%3B%3B%3B&fndGlobalItemNodeId=itemNode_partner_management_mdf&fndTaskItemNodeId=MKT_MDF_CLAIMS_CRM&_afrLoop=170080752950792&_afrWindowMode=0&_afrWindowId=null&_adf.ctrlstate=15rswocd3x_390&_afrFS=16&_afrMT=screen&amp;_afrMFW=1600&_afrMFH=799&_afrMFDW=1600&_afrMFDH=900&_afrMFC=8&_afrMFCI=0&_afrMFM=0&_afrMFR=96&_afrMFG=0&_afrMFS=0&_afrMFO=0

URL Pattern to Use for Direct Page Links to Desktop Details Pages

The direct page link URL uses a simple pattern which points to a particular details page.

Depending on the object whose details page you are linking to, use the following syntax to create a direct page link:

http://<hostname>:<port>/crmCommon/faces/deeplink?ObjType=<object_name>&ObjId=<123456>

In this URL, replace ObjType with one of the following supported objects:

  • Contact.

    For this object, use this direct page link URL pattern:

    http://<hostname>:<port>/crmCommon/faces/deeplink?ObjType=Contact&ObjId=10000001619.

  • Customer.

    For this object, use this direct page link URL pattern:

    http://<hostname>:<port>/crmCommon/faces/deeplink?ObjType=Customer&ObjId=10000001502.

  • Lead.

    For this object, use this direct page link URL pattern:

    http://<hostname>:<port>/crmCommon/faces/deeplink?ObjType=Lead&ObjId=99999700000

  • Opportunity.

    For this object, use this direct page link URL pattern:

    http://<hostname>:<port>/crmCommon/faces/deeplink?ObjType=Opty&ObjId=99123456

Assigning These Links

First, you should know which page you want to link to, and where you want that link to appear. You can add direct page links to:

  • Reports

    Use BI Composer or BI Answers to add direct page links to your reports.

  • User interface pages

    Create a direct page link using an object's Actions and Links node, then add the link to the object's user interface pages.

  • External third-party applications

    Create a direct page link to link directly to a page in your application.

User Authentication for Secured Access

The direct page link servlet requires authentication. If you have not been previously authenticated, you must sign in to gain access to the target page. After signing in, you are redirected to the target page. If you have already been authenticated at the time of clicking the direct page link, the target page is immediately displayed (without asking you to sign in).

Create Deep Links for Service Requests: Explained

Deep links are links that point to another page. You can link to a page where users can create a new service request, or edit an existing service request. Read this topic to learn how to construct these links. Once you have a link, you can then send it to someone else, or you can manually add the link to any page, such as to a report or user interface page.

This topic covers:

  • Deep linking methods

  • Get Link method

  • Manual URL method

  • Where can you use these links?

  • How user authentication provides secured access to the target page.

Deep Linking Methods

To create deep links to service request pages, you can use one of two methods.

  • Get Link method

    Use this method to easily "get a link" to the details page (edit page) of any service request.

  • Manual URL method

    Use this method to link to any service request page. Link to where users can create a new CRM or HR Help Desk service request, or link to the details page of an existing service request.

    This method is useful because you have the flexibility to specify parameters in the URL itself, so that you can link to exactly the page you want. For example, link to a page where the user can create a service request for a particular account and product group.

Get Link Method

The Get Link method is the simplest method to obtain a deep link, but it works only for service request details pages (edit pages). To obtain an automatically generated deep link:

  1. Navigate to the details page (edit page) of the service request that you want to link to.

  2. Click Actions > Get Link.

  3. Copy the link by clicking Control + C.

  4. Share that link.

Manual URL Method

To link to a service request create page, you must use the manual URL method. You can also use this method to link to a details page, although the Get Link method is simpler. To use the manual URL method, choose from four URL patterns to build your deep link. In each pattern, you can specify a variety of parameter values to satisfy the particular needs of your "create service request" business case. Depending on the link that you build, your users can navigate to the create page for the service request, or to a specific record.

To link to a page where your users can create new CRM service requests, use the following syntax:

  • https://<hostname>:<port>/fndSetup/faces/deeplink?objType=SVC_SERVICE_REQUEST&action=CREATE_IN_TAB

To link to a page where your users can create new HCM service requests, use the following syntax:

  • https://<hostname>:<port>/fndSetup/faces/deeplink?objType=SVC_SERVICE_REQUEST_HCM&action=CREATE_IN_TAB

To link to an existing CRM service request, use the following syntax:

  • https://<hostname>:<port>/fndSetup/faces/deeplink?objType=SVC_SERVICE_REQUEST&objKey=srNumber%3DSR0000033095&action=EDIT_IN_TAB

To link to an existing HCM service request, use the following syntax:

  • https://<hostname>:<port>/fndSetup/faces/deeplink?objType=SVC_SERVICE_REQUEST_HCM&objKey=srNumber%3DSR0000033095&action=EDIT_IN_TAB

Tip: Copy the first part of the URL, https://<hostname>:<port>/, from the customer instance's actual home page.

This table lists of the components of the service request deep link pattern.

Parameter Value Description

objType

SVC_SERVICE_REQUEST

SVC_SERVICE_REQUEST_HCM

Use SVC_SERVICE_REQUEST to link to CRM service requests.

Use SVC_SERVICE_REQUEST_HCM to link to HCM service requests.

objKey

The objKey parameter is optional and is typically used for record identifiers.

When linking to the create page, you can add multiple fields for the objKey parameter to prepopulate values onto the create page. For example, in a single URL, you could specify both a product ID as well as a primary contact ID to prepopulate onto the create service request page.

Here's a list of the available fields (attributes) for the objKey parameter which you might typically want to use.

When linking to the create page, you can pass any and all of the fields listed below. Additionally, you can use all fields, including custom fields, that are exposed for the service request object.

When linking to the edit page, pass only the srNumber parameter.

  • srNumber

  • srID

  • accountid (or accountPartyId)

  • primarycontactid (or primaryContactId)

  • productgroupid (or productGroupId)

  • productid (or inventoryItemId)

  • partneraccountid (or PartnerAccountPartyId)

  • assetid (or assetId)

The objKey takes key value pairs. Specify both the field and the field's value.

When linking to the create page, you can specify more than one pair for the objKey parameter by using the & symbol.

For example:objKey=accountPartyId%3D456&productGroupId%3D789

action

CREATE_IN_TAB

EDIT_IN_TAB

Open the Create Service Request page in dynamic tab mode.

Edit an existing service request in dynamic tab mode.

Assigning These Links

You can add deep links to:

  • Reports

    Use BI Composer or BI Answers to add deep links to your reports.

  • User interface pages

    Navigate to the service request object's Actions and Links node in Application Composer, and create an action or link using the deep link that you want. Then, use Application Composer to add the action or link to the object's user interface pages.

  • External third-party applications

    Create a deep link to link directly to a service request page.

User Authentication for Secured Access

The deep link servlet requires authentication. If you have not been previously authenticated, you must sign in to gain access to the target page. After signing in, you are redirected to the target page. If you have already been authenticated at the time of clicking the deep link, the target page is immediately displayed (without asking you to sign in).

Before you can import and export data for custom objects created with Application Composer, you must first generate the object artifacts required for both file-based import and bulk export.

Import and Export Data

You can import and export data using two processes: 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 aren't triggered by an import.

Use bulk export to extract large volumes of data from objects, both as extracts of a full set of records for an object as well as incremental extracts. Comma or tab-delimited files are created 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 changes you make using Application Composer don't create the artifacts required by these import and export processes.

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 mainline metadata and isn't supported within a sandbox.

To enable the import and export of custom object data:

  1. Confirm that you're not in a sandbox.

  2. On the main Overview page in Application Composer, 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. For instructions and examples, see the chapter about importing and exporting custom objects in the file-based data import documentation for your cloud service.

FAQs for Using Application Composer

What job role must I have to create my own objects in Application Composer?

Users with any one of the three following job roles can create their own objects and use all other Application Composer functions:

  • Customer Relationship Management Application Administrator.

  • Application Implementation Consultant.

  • Master Data Management Application Administrator.

Oracle recommends provisioning the user with the Customer Relationship Management Application Administrator job role (for performing the configurations) and the Custom Objects Administration job role and Sales Administrator job role (for testing the configurations).

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 the 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 modify. Direct Selection mode is available when you modify 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, the UI components that you can select become apparent when you move your cursor over them. The UI components that you can select are highlighted and can be edited.

The following table describes how you can use each mode of Page Composer to modify 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 modify 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, 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 updatable

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 minimum width in percent or pixels

No

Yes

Transactional pages (all non-dashboard pages)

Sort column 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.

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 changes by creating or modifying work area pages

No

Yes

Reorder subtabs

No

Yes

Modify dashboard pages

Yes

No

Add content from the Resource Catalog

Yes

No

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

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

Yes (non-WYSIWYG)

View results of changes immediately

Yes, in the Page Composer design interface

Yes, in the application that you are making changes to

What record sets is an owner permitted to search?

As an owner you can use the Record Set filter to search for different record sets that list all of the records that you and your subordinates own.

The following table lists and describes the record sets that you are permitted to search as an owner.

Record Set Name Description

Records I own

Records you own. You become the record owner when you create it or if ownership is assigned to you.

My subordinates own

Records owned by you and your subordinates.

All records I can see

Records that you can view based on your position in the owner management chain and security permissions.