Oracle® Fusion Applications CRM Extensibility Guide 11g Release 7 (11.1.7) Part Number E20388-06 |
Home |
Contents |
Book List |
Contact Us |
Previous |
Next |
This chapter contains the following:
Using Application Composer : Overview
Extending CRM Applications : How It Works
Customizing CRM Applications Across Application Boundaries : Explained
Customizing CRM Applications Using the Application Composer : Explained
Object Relationships : Explained
Joins and Join Fields: Explained
Field Types and Field Properties : Explained
Fixed Choice Lists : Explained
Dynamic Choice Lists : Explained
Creating a Work Area: Explained
Saved Searches for CRM Objects : Explained
Creating Saved Searches Using Page Composer : Highlights
Securing Custom Objects : Explained
Importing and Exporting Custom Objects : Explained
FAQs for Using Application Composer
How Application Composer works, at a summary level
The concept of Web applications, and how you can complete some customization tasks across Web application boundaries in selected CRM applications
How to define a custom object
How to define custom fields for either a custom object, or a standard object
How to create, or modify, the user interface pages to display your custom object and custom fields
How to edit saved searches that were created using Application Composer
How to secure custom objects, both in terms of what users can do on the object's work area, as well as the data that users can see
Other chapters in this guide also describe additional tasks flows that are available in Application Composer, such as creating object workflows and custom subject areas, writing Groovy scripts, and importing and exporting your customizations. Refer to the table of contents for these other chapters.
To navigate to Application Composer to make your application changes, select Application Composer from the Navigator, under the Tools category. Remember to always select the desired application from the Application choice list first, before making any changes. To test your changes in the actual application, use the Navigator to switch to the desired application to view your changes at run time.
The Application Composer hides the complexity of customization from business analysts by leveraging a set of standard design patterns and wizards. You focus on the application changes that your business requires (object model extensions and layout changes, for example), and the Application Composer creates the underlying object artifacts for you.
Access the Application Composer from any CRM application at run time by using the Navigator menu, and selecting Application Composer under the Tools category. The first view of the Application Composer is the main Overview page, which is the entry point into all your customization options.
From the Application Composer's Overview page, you can make application changes such as:
Customize objects by adding new fields, or create entirely new objects.
Create foreign key-based relationships between two objects.
Customize desktop pages by exposing your newly created fields for an object, or create an entirely new work area for your newly created objects.
Expose object relationships on desktop pages in the form of subtabs or tree nodes.
Write application logic, such as triggers, validation rules, and workflows, for an object or for use across multiple objects.
Implement functional and data-level security for custom objects.
Enable objects for custom reporting.
To access the Application Composer, log in with the Customer Relationship Management Administrator job role. Then, select Application Composer under the Tools category in the Navigator menu to navigate to the main Overview page.
From the main Overview page, select the application you want to customize using the Application choice list. Then:
Use the object tree to select the object you want to customize, or click the New icon to create a new object.
Use the links in main Overview page, also known as the local area, to select a customization task.
Or, use the links in the Common Setup pane.
Change the selected application in the Application choice list at any time to customize another CRM application.
The Application Composer is but one tool that lets you customize and extend your Oracle Fusion CRM applications. To learn more about extensibility options that are available to you across all Oracle Fusion applications, see the Oracle Fusion Applications Extensibility Guide for Business Analysts.
This topic introduces you to the concept of Web applications, and also describes the customization tasks that cross Web application boundaries which you can complete only in selected CRM applications:
Oracle Fusion Customer Center
Oracle Fusion Marketing
Oracle Fusion Sales
To complete a customization task, such as create a new custom object, you first select an application (such as Sales or Marketing) on the main Overview page of the Oracle Fusion CRM Application Composer. The new custom object will belong only to the application that you select.
Tip
When you first open the Application Composer, the default application is always Common. If you previously made customizations in another application, such as Sales, then you must manually change the application using the Application choice list to Sales, before you can review and update those customizations.
Web applications are also referred to as application containers.
What is a cross-application customization task? This refers to any customization task that you can do to an object in one Web application by accessing an object in another Web application. For example, you might want to add a subtab to an opportunity's page (Oracle Fusion Sales) that displays marketing campaign records (Oracle Fusion Marketing).
In general, customization tasks that are available in the Application Composer can be categorized into three areas:
Object model customizations
For example, add a new field to an object, or create a new object entirely.
User interface customizations
For example, show or hide a field. Or create a work area for a new top-level object.
Tip
A top-level object is an object that does not have a parent as part of its definition. In other words, it is not a child object. Top-level objects have their own work areas (a set of user interface pages such as an overview page and details page). A child object does not have its own work area, and appears instead as a subtab or tree node within the work area of its parent.
Scripting customizations
For example, make a field conditionally required based upon a value in another field.
You can make object model, user interface, or scripting changes that cross Web application boundaries, provided that the object you are customizing exists in one of three CRM applications:
Oracle Fusion Customer Center
Oracle Fusion Marketing
Oracle Fusion Sales
Additionally, when customizing an object in Customer Center, Marketing, or Sales, your customizations can include the following types of objects:
Custom top-level objects
When customizing an object in Customer Center, Marketing, or Sales, your customizations can include any custom top-level object that was created in Customer Center, Marketing, or Sales.
Standard top-level objects
When customizing an object in Customer Center, Marketing, or Sales, your customizations can include any standard top-level object that exists in any Oracle Fusion CRM Web application.
When customizing an object's model in Customer Center, Marketing, or Sales, you can include objects from other Web applications. The types of changes you can make include:
Dynamic choice lists
A dynamic choice list is a field that contains a list of values which are populated from the actual data of another object.
From a cross-application perspective, you can create a dynamic choice list field for an object in one Web application that is populated by the records from an object in another Web application.
For example, create a dynamic choice list field for the opportunity object (Oracle Fusion Sales) which is populated with sales lead records (Oracle Fusion Marketing).
Or, create a dynamic choice list field for the sales account object (Oracle Fusion Customer Center) which is populated with competitor records (Oracle Fusion Sales).
Relationships
A relationship is a foreign key association between two objects, and indicates a connection between two objects' data. (You create a relationship between two objects, so that you can later expose this connection on user interface pages through the use of child or related object subtabs or tree nodes.)
From a cross-application perspective, you can create a relationship between two objects from different Web applications.
For example, create a relationship where the opportunity object is the source and the sales lead object is the target.
This enables the creation of the sales lead object subtab on the opportunity object's details page. See the "User Interface Customizations" section in this topic.
Or, create a relationship where the sales account object is the source and the competitor object is the target.
This enables the creation of the competitor object tree node on the Customer 360 tree. See the "User Interface Customizations" section in this topic.
Note
Relationships enable not only user interface changes, such as subtabs and tree nodes. In addition:
Each object in the relationship becomes available for scripting against the other object. See the "Scripting Customizations" section in this topic.
Objects in a relationship are available to be selected as child objects, when defining a custom subject area.
Tip
Object model customizations include the creation of custom objects, as well. When creating a new object, consider whether you eventually plan to share that object between Customer Center, Marketing, and Sales. If so, create that object as a top-level custom object in Customer Center. On the other hand, if you need to share that object with any objects in Oracle Fusion Common CRM, then create that object as a top-level custom object in the Common Web application.
When customizing an object's user interface in Customer Center, Marketing, or Sales, you can include objects from other Web applications. The types of changes you can make include:
Subtabs and tree nodes
You can display details that are related to the current object but derived from another object. You do this by adding subtabs to an object's details page, and specifying the source of subtab data, or by adding tree nodes to the object's tree, and specifying the source of tree node data.
From a cross-application perspective, the source of subtab or tree node data can come from an object in a different Web application.
For example, add a Sales Leads subtab to the Opportunity details page.
Or, add a Competitor tree node to the Customer 360 tree.
Note that a relationship must first exist between the two objects, prior to adding subtabs or tree nodes.
When writing groovy scripts as part of customizations to an object in Customer Center, Marketing, or Sales, you can include objects from other Web applications in your scripts. The types of changes you can make include:
When writing a script, access data from any standard object in any CRM Web application, as well as from any custom top-level object created in Customer Center, Marketing, or Sales, using the newView() built-in function. The newView() built-in function is described in "Accessing the View Object for Programmatic Access to Business Objects" in Oracle Fusion CRM Application Composer Scripting Guide (ID 1354807.1) on My Oracle Support.
Note that a relationship must first exist before you can script against other objects.
For example, write a script in a "before update" trigger on the opportunity object that counts the number of leads that involve this opportunity. At run time, when a user saves an opportunity record, the trigger populates a custom field on the opportunity with the number of related leads.
Or, write a script in a "before insert" trigger on the sales account object that retrieves information about the opportunity associated with the organization that the sales account is tied to.
Objects available in the Common Web application include CRM common components such as tasks, interactions, and notes, as well as Master Data Management (MDM) and Common Party User Interface (CPUI) objects. These Common objects are available to you when customizing an object in Customer Center, Marketing, or Sales.
When customizing Common objects themselves, however, the object model and user interface cross-application customization tasks described above are not available. Scripting customizations are available, although you should proceed carefully when writing scripts for Common objects that access objects outside the Common Web application. Your scripts will work only when triggered within the context of the other Web application.
For example, when creating a note, you can write a script to insert details about an opportunity into a custom field on the note. This script will work only if a user creates the note from within Sales. If, however, the user creates the note from within Marketing, then the script will not work.
Different sets of customization task flows are available to you, depending on the CRM application that you are customizing. See Customizing Oracle Fusion CRM Applications Using Oracle Fusion CRM Application Composer (Doc ID 1516151.1) on My Oracle Support at https://support.oracle.com. This document provides a list of which task flows are available for use in these CRM applications:
Oracle Fusion Common CRM
This includes Master Data Management (MDM) and Common Party User Interface (CPUI) objects.
Oracle Fusion Customer Center
Oracle Fusion Marketing
Oracle Fusion Sales
Oracle Fusion Sales Catalog
You can also refer to the product-specific implementation guides to learn more about how a particular application works with the Application Composer.
Review these aspects of the object model extension process in the Application Composer before you begin to customize or extend your CRM application's object model:
Browsing the object tree
Creating a custom object
Using the Object Overview page
Editing an object's attributes
Viewing child and related objects
Deleting a custom object
Access the Application Composer from a CRM application at run time by using the Navigator menu. The first view of the Application Composer is the main Overview page, which is the entry point into all your customization options.
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:
Select Application Composer from the Navigator menu, under the Tools category.
On the main Overview page, select an application from the Application choice list.
For each object node, whether standard or custom, expand it further to view and edit object details, such as an object's fields and desktop 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.
Buttons and links
Add buttons or links to desktop pages.
Server scripts
Write application logic that controls the behavior of an object's records.
Saved searches
Edit saved searches for an object.
For custom objects, you can also view and edit details for:
Security
Implement functional and data-level security for an object and its records.
To create a new custom object, you first select an application on the main Overview page of the Application Composer. The new custom object will belong to the application that you select. After you select the application:
Select the Custom Objects node or link in either the object tree or local area of the main Overview page.
On the resulting summary table, click the New icon.
Or, at the top of the object tree, click the New icon
Complete the primary identifying attributes for a custom object:
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.
Plural Label
The plural label is used as the title of the object's work area.
Record Name
Use the Record Name field to specify the display label for the object's RecordName field. The RecordName field stores the "name" of the record. For example, for an opportunity object, this RecordName field stores the opportunity's name. Accordingly, if you were creating this object as a custom object, then you would set the Record Name field to Opportunity Name.
Typically, this field is the object's primary user-recognizable identifier for the object, and as such, is usually the identifier that run time users drill down on, from the overview page to the detail page.
Object Name
The object name is the internal name for the object.
Description
Tip
To create a custom child object, click the Create Child Object button in the standard or custom objects summary table, or from an object's Object Overview page.
Once created, a child object cannot be changed to a parent object. Similarly, a parent object cannot be changed to a child object.
Child objects are discussed below.
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.
To access the Object Overview page:
Select an application on the main Overview page.
Select a standard or custom object in the object tree.
Or, select the Standard Objects or Custom Objects node or link in either the object tree or local area of the main Overview page, choose an object from the resulting summary table, and select the Edit icon.
From the Object Overview page, you can:
Edit the object's primary attributes, described in the previous section.
View the parent child relationships that were created for this object.
You can also create new child objects from this page, which implicitly creates a new parent child relationship.
View the non-parent child relationships that were created for this object.
After an object has been created, you can edit its attributes from its Object Overview page.
To edit an object's attributes:
Select an application on the main Overview page.
Select the Standard Objects or Custom Objects node or link in either the object tree or local area of the main Overview page.
From the resulting summary table, select an object and then select the Edit icon to navigate to its Object Overview page.
On the Object Overview page, click Edit:
Change the object's display label, description, and record name at any time.
You cannot change the Object Name and API Name after the object has been created.
A custom object's API name for an object is automatically derived using the logical name followed by _c. You use the API name in Groovy expressions that you build with the expression editor, when writing business logic for the object.
The Object Overview page displays a list of child objects and related objects, if any, that have been created for an object. You can also create new child objects from this page.
A child object is an object with a cascade delete relationship to a parent object. This means that if you delete the parent object, then all its children are automatically deleted. A child object does not exist outside the context of the parent object, and does not have its own work area. You cannot change a child object to a parent object after the child object has been created.
Related objects can exist independently of each other, even if one object is deleted. Related objects are connected in a foreign key-based relationship between two top-level objects, not as parent and child. These types of relationships include reference relationships and dynamic choice list relationships.
Related objects can have either a one-to-many or a many-to-one relationship with the current object. Note that an object can be related to itself to model a hierarchy of the object. In this case, the object itself is displayed on its Object Overview page as a related object. For example, the Department and Sub-department objects would be displayed in this way.
Note
You do not create these types of relationships from this page. Instead, manage relationships from the Relationships page, which you can access from the 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:
Navigate to an object's Object Overview page.
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.
The Application Composer does not support the deletion of either standard or custom objects. If you no longer need an object, optionally enter a note in the description that the object is no longer used.
Review these aspects of the relationship creation process in the Application Composer before you begin to create relationships between objects:
Relationship types
Creating reference relationships
Adding subtabs or tree nodes
Many-to-many relationships
Four types of one-to-many relationships exist:
Parent child relationship
Parent child relationships are implicitly created when a custom object is created as a child of a top-level object.
When a child object is created, it is created specifically in the context of its parent. A child object does not have its own work area, and the child object is deleted if the parent object is deleted.
View parent child relationships on the parent object's Object Overview page. If a parent child relationship exists, then the child object is listed on the parent's Object Overview page in the Child Objects region. A top-level object can have many child objects.
You can also view the parent child relationship from the child object's Object overview page. If a parent child relationship exists, then the parent object is listed on the child's Object Overview page in the Object Information region. A child object can have only one parent object.
Relationships that are implicitly created from parent child relationships are also viewable on the Relationships page. The relationship name is automatically generated for you.
Choice list relationship
Choice list relationships are implicitly created between two objects when you create a dynamic choice list field.
View choice list relationships on an object's Object Overview page. If a choice list relationship exists, then the related object is listed on the object's Object Overview page in the Related Objects region.
A dynamic choice list is a field that contains a list of values which are populated from the actual data of another object. For example, you might want to expose on a desktop page a dynamic choice list which lets users specify the HR representative of a given department. The HR Representative choice list is a field that you are adding to the department object, but the list of values is populated by actual employees from the employee object.
In the previous example of making a list of accounts available for selection for a help request, an account can be tied to multiple help requests. The relationship that is created is a one-to-many relationship between the account and help request objects, which enables users to store an account identifier in the help request object's table. In this relationship, the account object is the source object and the help request object is the target object. If a source object is ever deleted from the system, then at run time, the dynamic choice list will have no values in it.
Later, you might want to expose a related object subtab on the account details page which shows, for a single account, all the help requests that are related to it. You can create this related object subtab because the relationship was already created when you created the dynamic choice list.
These objects are related objects, not parent child objects; related objects are not deleted if the current object is deleted.
Relationships that are implicitly created from dynamic choice list relationships are also viewable on the Relationships page. The relationship name is automatically generated for you.
Note
Generally, the dynamic choice list that you create results in the implicit creation of a choice list relationship. The exception is if you create a dynamic choice list between a CRM object and a common object: resource, organization contact, organization profile, address. In such cases, relationships are not implicitly created.
Reference relationship
Instead of using a dynamic choice list to implicitly create a relationship between two objects, you can also manually create this relationship as a reference relationship.
Reference relationships are explicitly created between two top-level objects using the Create Relationships page.
View reference relationships on an object's Object Overview page. If a reference relationship exists, then the related object is listed on the object's Object Overview page in the Related Objects region.
Using our previous example, perhaps you don't need to display an HR Representative choice list on a department desktop page, but you still want to add a department subtab to an employee's details page. In this case, manually create a reference relationship between the employee and department objects where the employee is the source object and the department is the target object. This enables the creation of the department subtab. Such a reference relationship, however, does not automatically create a corresponding HR Representative choice list for use on the department desktop page. In fact, once you manually create a relationship, you cannot reuse the relationship to create a choice list. This means that you should carefully consider the need for a choice list before you create a reference relationship.
Standard relationship
Standard relationships are relationships that are already created between two standard objects by the Oracle Fusion CRM application.
You can also view standard relationships on an object's Object Overview page. If a standard relationship exists, then the related object is listed on the object's Object Overview page in the Related Objects region.
Create a foreign key-based, one-to-many relationship between two top-level objects explicitly using the Create Relationship page. Explicitly created relationships are also known as reference relationships.
You can also create a foreign key-based, one-to-many relationship by creating child objects and dynamic choice lists. These implicit relationships are discussed in related topics.
To explicitly create a relationship between two top-level objects within the same application:
Select Relationships in the Common Setup pane.
On the Relationships page, click the New icon.
Select the source object and target object.
A child object cannot be the source object or target object.
Common components, such as notes, interactions, or tasks, are not available for selection as either source objects or target objects.
In general, you create a relationship between two objects within the same application. You can, however, select common objects as target objects. Common objects include:
Trading Community Resource
Trading Community Organization Contact
Trading Community Organization Profile
Trading Community Address
Once you create a relationship, you can no longer edit the source and target objects.
This relationship adds a field to the target object to store the foreign key details. If the source object is ever deleted, the target object records remain in the system.
Enter the relationship name and description.
Once you create a relationship, you can no longer edit the relationship name.
Optionally add the target object in a subtab to the source object's detail page, or as a tree node.
Note
You can create multiple relationships between the same source and target objects. For example, create both a Primary Contact and Secondary Contact relationship between the contact and opportunity objects.
After you create relationships between objects, you can then expose the "many" objects on a subtab or tree node that is displayed on the "one" object's details page or tree.
When adding a subtab or a tree node to an object's details page or object, you select to add a Child or Related Objects subtab from the object's Pages Overview page. The Application Composer lets you add a subtab or tree node based on any target object that has a relationship with the current object as the source object. Subtabs and tree nodes are discussed in related topics.
Objects can also have a many-to-many relationship. For example, a service request can have multiple employees working on it. At the same time, a single employee can work on multiple service requests. In this scenario, you would create a many-to-many relationship between the service request and employee objects, where the related records from both objects store their primary identifiers in an intersection table.
To create a many-to-many relationship using the Application Composer:
Create a child object of one object, and use this child object to represent the intersection table that stores the record identifiers of both objects.
For example, create a service request member object as a child of the service request object. The service request member object's table records the service request identifier as a foreign key.
Add a dynamic choice list for the new child object whose related object is the other object in the many-to-many relationship.
For example, create a dynamic choice list, Support Representative, for the service request member object where the choice list's related object is employee. The Application Composer automatically creates the underlying relationship for you, where the employee is the source object and the service request member is the target object. The service request member object's table records the employee identifier as a foreign key.
Now, the service request member object's table records two foreign keys: one for the service request object and the other for the employee object. This enables the many-to-many relationship. You can now do the following:
Create a child subtab on a service request's details page. The subtab displays all employees that are working on a specific service request.
Create a related object subtab on an employee's details page. The subtab displays all service requests that an employee is working on, since each employee can work on multiple service requests.
Review these aspects of editing fields in the Application Composer before you begin to customize or extend your CRM application's object model:
Adding fields to objects
Deleting fields
Use the Fields page to review the list of standard and custom fields for an object, and create custom fields. A CRM object can have a maximum of 625 fields.
To view the Fields page for an object:
Select an application from the Application choice list on the main Overview page.
Select either the Standard Objects or Custom Objects node in the object tree to expand the list of objects.
Select the object itself to further expand the tree hierarchy.
Select the Fields node to navigate to the Fields page.
On the Fields page:
Standard Fields
Review the list of standard fields that are delivered for an object, and optionally modify the display label and help text for a field.
The list of standard fields includes all the fields that are specific to an object, as well as system fields, which could include:
CreatedBy
CreationDate
Id
LastUpdateDate
LastUpdatedBy
RecordName
The custom objects that you create also contain these same system fields, among others.
Custom Fields
Review the list of custom fields that were created specifically for your CRM implementation for either standard or custom objects, and create new custom fields.
To create a custom field, select the New icon from the custom fields table on the Fields page. The Application Composer provides a set of field types that you can choose from when creating new fields:
Text
Long text
Number
Date
Datetime
Check box
Percentage
Currency
Formula
Fixed choice list
Dynamic choice list
The Application Composer does not support the deletion of either standard or custom fields from objects. If you no longer need a field, optionally enter a note in the field description that the field is no longer used.
Joins are delivered by default for the Sales Account object for these Oracle Fusion Common CRM objects:
Trading Community Group Profile
Trading Community Organization Profile
Trading Community Person Profile
To view the joins available for an object, expand an object and click the Joins node. For example, select the Customer Center application, expand the Sales Account object, and click the Joins node.
Tip
Click the join name to navigate to the Join Fields page, where you can register join fields.
Select the join row and click Edit to navigate to the read-only Join Specification page, where you can review details about the join.
Note
You cannot create joins or edit existing joins.
Joins are delivered without join fields. Before you can add related object fields from a join to an object's work area, you must select the related object fields that you want to display, and then register them as join fields.
Once you have registered a related object field as a join field, you can then show or hide those fields on an object's work area by using the configuration pages available from the object's Pages node.
Refer to the worked example related topic for a detailed procedure that describes how to register join fields for the Sales Account object and add those fields to the Customer Overview.
Note
Fields configured for an object as a join field do not appear in file-based import and bulk export.
Before you create a new field for a object, you should understand:
The set of standard field types available for field creation
The common set of field properties that you must specify for a field
How field types work with other components
When creating a new field for a object, the Oracle Fusion CRM Application Composer provides a set of standard field types that you can choose from.
The types of fields that you can create are listed below.
Text
Users can enter a combination of letters, numbers, or symbols. This field type is limited to 254 characters.
Long text
Users can enter a combination of letters, numbers, or symbols. This field type supports 32,000 characters.
Number
Users can enter a number in this field.
Date
Users can enter a date, or select a date from a calendar.
Datetime
Users can enter a date, or select a date from a calendar, and enter a time of day. During field creation, you choose whether to show the date or time, or both.
Check box
Users can select a check box, indicating a true or false attribute of a record.
Percentage
Users can enter a percentage. The system automatically adds the percent sign.
Currency
Users can enter a currency amount.
Fixed choice list
Users can select from a list of static values, populated from an FND lookup type.
Dynamic choice list
Users can select from a list of values, populated from another object's set of records.
Formula
A formula field is a field that is calculated in the run time CRM application using the Groovy-based expression included in the formula field's definition. This is a read-only field that users in the run time application do not update. However, the application logic that you write can update these fields directly.
When you create a custom field, you first select the field type. For example, are you creating a check box field, a formula field, or a long text field? You cannot change the field type after the field is created. The specified field type controls which field properties you must define when creating the field. Some properties are common across field types, whereas other properties are unique to a specific field type.
The common field properties that you can define for a custom field are listed in this table, along with the regions on the field configuration pages where they appear and a list of the applicable field types that you must set these properties for. Use this table to understand the common properties that you must define when creating a new field.
Field Property |
Field Property Region |
Related Field Types |
---|---|---|
Label Specify the display label for the field. A maximum length of 80 characters is recommended, although no maximum length is actually enforced. |
Appearance These properties control how the field appears to your users in the run time application. |
Set this property for all field types. |
Help Text The help text displays when users hover over the field in the run time application. A maximum length of 80 characters is recommended, although no maximum length is actually enforced. |
Appearance |
Set this property for all field types. |
Display Width Specify the display width for most field types at run time. The display width is the actual character width for the field on a desktop page. Note When setting the display width, consider the resolution in use where this field will be displayed on a desktop page. A display width that is too wide will stretch beyond the resolution of the display and result in scroll bars. Generally, enter a display width of no more than 20 to 25 characters. Warning For fixed choice lists, note that the display width is determined by the length of the longest string in the choice list. |
Appearance |
Set this property for all field types except for check box, date, and datetime fields. |
Name Enter a unique field name, which is for internal use only. The field name is automatically populated based on the field label you enter, but without spaces. Field names can contain only underscores and alphanumeric characters. They must begin with a letter, not include spaces, not end with an underscore, and not contain consecutive underscores. Field names are limited to 28 characters. You cannot change this property after the field is created. Tip It is possible to create custom fields with different names, but the same display label. Avoid this scenario, however, so that you do not see two fields with the same display label when configuring a desktop page. Note The API name is also automatically generated for a field, by taking the logical name and appending _c. The API name is used in your Groovy scripts. |
Name |
Set this property for all field types. |
Description Enter a unique field description, which is for internal use only. |
Name |
Set this property for all field types. |
Required Indicate if the field is a required field. You can also optionally use the expression editor to write an expression that describes the conditions required for this field to be required. Note If you write an expression to control whether a field is required, then you must also configure the Depends On choice list. This choice list includes fields from the current object, and is used in the evaluation of your expression at run time. |
Constraints Specify constraints, which let you control the run time behavior of the field. |
Set this property for all field types except for formula fields. |
Updateable Indicate if the field is an updateable field. You can also optionally use the expression editor to write an expression that describes the conditions required for this field to be updateable. This includes being updateable on a desktop page, via Web services, through the import and export functionality, and by server scripts. Note If you write an expression to control whether a field is updateable, then you must also configure the Depends On choice list. This choice list includes fields from the current object, and is used in the evaluation of your expression at run time. |
Constraints |
Set this property for all field types except for formula fields. |
Searchable Indicate if you want this field to be made available for selection as an additional search criteria from the Add Fields choice list in the Advanced Search mode. |
Constraints |
Set this property for all field types except for long text and formula fields. |
Indexed Enable faster searching by indexing this column. Only a limited number of columns are indexed. Accordingly, use this property only on the most frequently searched fields. You cannot change this property after the field is created. |
Constraints |
Set this property for text, number, date, datetime, currency, and percentage field types. You cannot index long text, formula, and check box fields, or fixed and dynamic choice lists. Note You cannot index long text fields. Instead, your users can use the Oracle Fusion Applications search capability to search these field types. |
Fixed Value Specify a literal default value for the field. Warning Do not assign a literal default value to fields that are both required and intended to be unique, as a run time error could occur. |
Default Value |
Set this property for all field types except for formula fields and dynamic choice lists. |
Expression Use the expression editor to write an expression that dynamically sets the default value for a field at run time. |
Default Value |
Set this property for all field types except for check box and formula fields, and fixed and dynamic choice lists. To set default values for these types of fields, write server scripts. |
When you create new fields for objects, the 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 CRM Extensibility Framework to provide you with the most flexibility possible when customizing and extending your CRM 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 editor, 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 the Application Composer's import and export feature.
Most field types correspond to available fields that you can use to create a custom subject area for reporting. Exceptions include long text, check box, and formula fields.
Create a text field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the text field type.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Display Width |
Appearance |
Name |
Name |
Description |
Name |
Required |
Constraints |
Updateable |
Constraints |
Searchable |
Constraints |
Indexed |
Constraints |
Fixed Value |
Default Value |
Expression |
Default Value |
The following properties are unique to only certain field types, including text fields:
Field Property |
Field Property Region |
---|---|
Display Type Indicate if you want this text field to render in the run time application as a simple text box. Or, indicate if the field should allow multiple lines where text can wrap, or where the user can enter carriage returns. |
Appearance |
Maximum Length Indicate the maximum number of characters that a user can enter in the field. You can set a maximum length of 254 characters. If the field is a multiline field, then carriage returns are permitted and count as characters against the total. |
Constraints |
Minimum Length Indicate the minimum number of characters that a user can enter into the field. |
Constraints |
Additional specifications for this field type include the following details:
Data type is VARCHAR2 (254 char).
A object can have a total of 625 fields. Of those 625 fields, 350 fields are reserved for text and check box fields, and fixed and dynamic choice lists.
Create a long text field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the long text field type.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Display Width |
Appearance |
Name |
Name |
Description |
Name |
Required |
Constraints |
Updateable |
Constraints |
Fixed Value |
Default Value |
Expression |
Default Value |
The following properties are unique to only certain field types, including long text fields:
Field Property |
Field Property Region |
---|---|
Display Type Indicate if you want this text field to render in the run time application as a simple text box. Or, indicate if the field should allow multiple lines where text can wrap, or where the user can enter carriage returns. |
Appearance |
Additional specifications for this field type include the following details:
Data type is CLOB.
A object can have a total of 625 fields. Of those 625 fields, 25 fields are reserved for long text fields.
The long text field type is not supported by custom subject areas. This means that you cannot add long text fields to a custom report.
Create a number field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the number field type.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Display Width |
Appearance |
Name |
Name |
Description |
Name |
Required |
Constraints |
Updateable |
Constraints |
Searchable |
Constraints |
Indexed |
Constraints |
Fixed Value |
Default Value |
Expression |
Default Value |
The following properties are unique to only certain field types, including number fields:
Field Property |
Field Property Region |
---|---|
Decimal Places Specify how many numbers can be entered and displayed to the right of the decimal point. If at run time, a user enters more numbers after the decimal point, then the Application Composer rounds up (using the tie-breaking rule, round half up) to derive the field's value. For example, if you enter 2 for the number of decimal places, then at run time, an entry of 4.986 is displayed as 4.99. |
Constraints |
Maximum Length Specify how many numbers a user can enter in the field. This number should be greater than or equal to one and less than or equal to 38. During field creation, consider how this property interacts with these other field properties:
|
Constraints |
Minimum Value Indicate the minimum numerical value that a user can enter into this field. |
Constraints |
Maximum Value Indicate the maximum numerical value that a user can enter into this field. |
Constraints |
Additional specifications for this field type include the following details:
Data type is NUMBER.
A object can have a total of 625 fields. Of those 625 fields, 200 fields are reserved for number, currency, and percentage fields.
Leading zeros are removed.
Create a date field by specifying values for the common set of field properties, such as display label and field name.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Name |
Name |
Description |
Name |
Required |
Constraints |
Updateable |
Constraints |
Searchable |
Constraints |
Indexed |
Constraints |
Fixed Value |
Default Value |
Expression |
Default Value |
Additional specifications for this field type include the following details:
Data type is TIMESTAMP.
A object can have a total of 625 fields. Of those 625 fields, 50 fields are reserved for date and datetime fields.
When you create a custom subject area to be used for custom reporting, you can select fields with this type to use for date leveling.
Create a datetime field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the datetime field type.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Name |
Name |
Description |
Name |
Required |
Constraints |
Updateable |
Constraints |
Searchable |
Constraints |
Indexed |
Constraints |
Fixed Value |
Default Value |
Expression |
Default Value |
The following property is unique to only certain field types, including datetime fields:
Field Property |
Field Property Region |
---|---|
Display Type Indicate if you want this datetime field to show the date or time, or both. |
Appearance |
Additional specifications for this field type include the following details:
Data type is TIMESTAMP.
A object can have a total of 625 fields. Of those 625 fields, 50 fields are reserved for date and datetime fields.
When you create a custom subject area to be used for custom reporting, you can select fields with this type to use for date leveling.
This field type supports time zone conversion.
Create a check box field by specifying values for the common set of field properties, such as display label and field name.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Name |
Name |
Description |
Name |
Required |
Constraints |
Updateable |
Constraints |
Searchable |
Constraints |
Fixed Value |
Default Value |
Additional specifications for this field type include the following details:
Data type is VARCHAR2.
A object can have a total of 625 fields. Of those 625 fields, 350 fields are reserved for text and check box fields, and fixed and dynamic choice lists.
The check box field type is not supported by custom subject areas. This means that you cannot add check box fields to a custom report.
Create a percentage field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the percentage field type.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Display Width |
Appearance |
Name |
Name |
Description |
Name |
Required |
Constraints |
Updateable |
Constraints |
Searchable |
Constraints |
Indexed |
Constraints |
Fixed Value |
Default Value |
Expression |
Default Value |
The following properties are unique to only certain field types, including percentage fields:
Field Property |
Field Property Region |
---|---|
Decimal Places Specify how many numbers can be entered and displayed to the right of the decimal point. If at run time, a user enters more numbers after the decimal point, then the Application Composer rounds up (using the tie-breaking rule, round half up) to derive the field's value. For example, if you enter 2 for the number of decimal places, then at run time, an entry of 4.986 is displayed as 4.99. |
Constraints |
Maximum Length Specify how many numbers a user can enter in the field. During field creation, consider how this property interacts with these other field properties:
|
Constraints |
Additional specifications for this field type include the following details:
Data type is NUMBER.
A object can have a total of 625 fields. Of those 625 fields, 200 fields are reserved for number, currency, and percentage fields.
The Application Composer automatically adds the percent sign.
Create a currency field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the currency field type.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Display Width |
Appearance |
Name |
Name |
Description |
Name |
Required |
Constraints |
Updateable |
Constraints |
Searchable |
Constraints |
Indexed |
Constraints |
Fixed Value |
Default Value |
Expression |
Default Value |
The following properties are unique to only certain field types, including currency fields:
Field Property |
Field Property Region |
---|---|
Minimum Value Indicate the minimum numerical value that a user can enter into this field. |
Constraints |
Maximum Value Indicate the maximum numerical value that a user can enter into this field. |
Constraints |
Exchange Date Optionally specify the exchange date to use to calculate the currency conversion rate. Tip To use the system date when the record was created as the exchange date, specify the field's creation date as the exchange date. |
Exchange Date |
Additional specifications for this field type include the following details:
Data type is NUMBER.
A object can have a total of 625 fields. Of those 625 fields, 200 fields are reserved for number, currency, and percentage fields.
Note
Each currency field uses two number type columns: one column stores the amount itself and the other column stores the currency conversion rate that is calculated from the entered amount's currency code to the corporate currency code.
A CRM object includes the following fields to assist with currency conversion. These fields are automatically added to a CRM object, provided that the object's CRM application allows the creation of currency fields, and are derived from the CRM application's corporate currency setup.
Currency code
This is the currency code for all currency fields for an object.
Corporate currency code
Currency conversion rate type
Currency conversion for a currency field occurs as follows:
At run time, the user enters the currency amount.
When the user saves the record:
The currency amount is stored using the currency code specified for the object.
The CRM 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 CRM application recalculates the currency conversion rate for the record.
Create a fixed choice list by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the fixed choice list field type.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Display Width Note The size of the field depends on the longest value of the strings in the choice list. |
Appearance |
Name |
Name |
Description |
Name |
Required |
Constraints |
Updateable |
Constraints |
Searchable |
Constraints |
Fixed Value Tip If this choice list allows multiple values, you can still write an expression to preselect multiple values by default. For example, if the field is comprised of three lookup codes with (Code,Label) of (S,Small),(M,Medium),(L,Large),(XL,Extra Large), then to preselect the Small and Extra Large selections by default, set the default value to the literal string (without quotes): S,XL. |
Default Value |
The following properties are unique to only certain field types, including fixed choice lists:
Field Property |
Field Property Region |
---|---|
Display Type Indicate if your users can select only one value, or multiple values, from the choice list at run time. Selecting the display type is possible only during field creation. |
Appearance |
Lookup Type |
List of Values |
Constrain List by Parent Field Value Selection |
List of Values |
The values in a fixed choice list are populated from FND lookup types. Select the lookup type whose values you want to display in this choice list. Selecting the lookup type is possible only during field creation.
Or, create a new lookup type and add new values to it. You can also enter a lookup type and select the Edit icon to modify the existing values.
The set of FND lookup types that are available for selection is constrained to those lookup types that are related to this fixed choice list's object (via product code), as well as all custom lookup types that have been created for your CRM implementation.
You can constrain the actual values that display in this fixed choice list at run time by relating this fixed choice list to a parent fixed choice list. The value selected in the parent fixed choice list drives the values that display in this fixed choice list. For example, you might want your users to see two choice lists on a desktop page where they can create a trouble ticket: one choice list for specifying the trouble ticket type and one choice list for specifying the trouble ticket area. If a user selects Hardware from the Type choice list, then the Area choice list should contain a list of only hardware options against which the trouble ticket can be logged.
To do this, select the Constrain List by Parent Field Value Selection check box, select the parent field, and then map the values between the parent lookup type and this field's lookup type.
Note
The Constrain List by Parent Field Value Selection check box is available for selection only during field creation, and only if at least one other fixed choice list, which is a single-select choice list, has been defined.
After field creation, however, you can update the mapping between lookup values.
To implement the previous example:
Define the Type fixed choice list.
Define the Area fixed choice list.
Select the Constrain List by Parent Field Value Selection check box and select the parent field, Type.
Finally, map the values between the Type and Area lookup types.
For example, map all relevant hardware values in the Area lookup type's set of values, such as desktop and laptop, to the value of Hardware in the Type's lookup type.
Additional specifications for this field type include the following details:
Data type is VARCHAR2 (1500).
When creating dynamic choice lists, note the following:
Review the common set of field properties, as well as the dynamic choice list-specific properties, that you must specify.
Review the options available in the List Data Source, Additional List Display Values, and Additional List Search Fields regions.
Understand how a dynamic choice list results in the implicit creation of a relationship.
Note
When you are ready to add this dynamic choice list to a page, note that you cannot add dynamic choice lists to the local search region of a custom work area.
You must create a Select and Search picker for a custom object, if you also create a dynamic choice list that is based on the same custom object.
Create a dynamic choice list by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the dynamic choice list field type.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Display Width |
Appearance |
Name |
Name |
Description |
Name |
Required |
Constraints |
Updateable |
Constraints |
Searchable |
Constraints |
The following properties are unique to only certain field types, including dynamic choice lists:
Field Property |
Field Property Region |
---|---|
Related Object |
List Data Source |
List Selection Display Value |
List Data Source |
Data Filter |
List Data Source |
Additional List Display Values |
Additional List Display Values |
Additional List Search Fields |
Additional List Search Fields |
When defining a dynamic choice list, use the following regions to determine what data will display in the list of values at run time.
List Data Source region
Related Object
The values in a dynamic choice list are populated from another object's data. Select the related object first, then use the List Selection Display Value choice list to select the related object's field that you want to expose as a field for your own object. Selecting the related object is possible only during field creation.
Note
The set of objects that are available for selection is constrained to top-level objects only. You cannot select a child object as a related object.
In our example, the related object would be Account.
Tip
Once you create a dynamic choice list, you can easily recognize the choice list's related object from the Fields page. The Fields page displays summaries of both standard and custom fields for the selected object. If a dynamic choice list was created, then the Type column includes the related object. In our example, the field type would be Choice List (Dynamic) <Account>.
List Selection Display Value
The List Selection Display Value choice list is the related object's field that is displayed within the dynamic choice list as the first column at 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.
Data Filter
You can further refine the set of data that appears within the dynamic choice list at run time by using data filters.
In our example, we could filter out any accounts outside a particular region.
Additional List Display Values region
You can further refine the look and feel of the dynamic choice list by selecting additional fields to display in the choice list.
Use the Additional List Display Values shuttle to include additional related object fields in the dynamic choice list at run time. These additional fields assist your users in making a selection from the choice list. The shuttle does not include the field that you already selected in the List Selection Display Value choice list.
There is no limit on the number of additional fields that you can select.
Additional List Search Fields region
You can indicate which additional related object fields can be added as search criteria in the dynamic choice list's Search and Select dialog.
Use the Additional List Search Values shuttle to include additional related object fields in the dynamic choice list's Search and Select dialog, accessed using the Search... link at run time. The shuttle does not include the field that you already selected in the List Selection Display Value choice list.
There is no limit on the number of additional fields that you can select.
When you create a dynamic choice list for an object based on a related object, you are implicitly creating a one-to-many foreign key relationship where the current object is the "many" object and the related object is the "one" object. This implicit creation of a relationship lets you later add a related object subtab for the "many" object on the "one" object's details page. You can view these implicitly created choice list relationships on the Relationships page.
In the previous example of making a list of accounts available for selection for a help request, an account can be tied to multiple help requests. The relationship that is created is a one-to-many relationship between the account and help request objects, which enables users to store an account identifier in the help request object's table. In this relationship, the account object is the source object and the help request object is the target object. If a source object is ever deleted from the system, then at run time, the dynamic choice list will have no values in it.
Later, you might want to expose a related object subtab on the account details page which shows, for a single account, all the help requests that are related to it. You can create this related object subtab because the relationship was already created when you created the dynamic choice list.
Note
Generally, the dynamic choice list that you create results in the implicit creation of a choice list relationship. The exception is if you create a dynamic choice list between a CRM object and a common object: resource, organization contact, organization profile, address. In such cases, relationships are not implicitly created.
Additional specifications for this field type include the following details:
Data type is VARCHAR2 (1500).
Create a formula field by specifying values for the common set of field properties, such as display label and field name. You also set properties for this field that are specific to the formula field type.
The following properties are common across multiple field types:
Field Property |
Field Property Region |
---|---|
Label |
Appearance |
Help Text |
Appearance |
Display Width |
Appearance |
Name |
Name |
Description |
Name |
The following properties are unique to only certain field types, including formula fields:
Field Property |
Field Property Region |
---|---|
Formula Type Specify the field's data type, such as text, number, or date. The type can be specified only during field creation. |
Field Value Type |
Display Type If the formula type is Text, then indicate if you want this formula field to render in the run time application as a simple text box. Or, indicate if the field should allow multiple lines where text can wrap. |
Appearance |
Depends On |
Constraints |
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.
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 editor to write an expression that calculates the field's value at run time.
For example, if your expression calculates the value of an employee's annual bonus amount, then you could set the expression to automatically recalculate that amount if the employee's salary changes. Whenever the salary changes, the bonus field immediately reflects the new bonus amount without your users having to refresh the employee's record.
In another example, if your expression determines the right customer phone number to use for an opportunity, then you could set the expression to automatically reset the phone number if the opportunity's customer account changes. Whenever the customer account changes, the phone number field immediately reflects the new phone number without your users having to refresh the opportunity record.
Additional specifications for this field type include the following details:
Data type is set by the Formula Type property.
The formula field type is not supported by custom subject areas. This means that you cannot add formula fields to a custom report.
You cannot search on a formula field.
Note
You can also expose new objects and fields in mobile applications using the Mobile Pages tab. And, you can expose new fields in an alternative set of simplified user interface pages, if available for a standard object, using the Simplified Pages tab.
After you create a custom object, you can create its corresponding work area by using the work area wizard, available from the Enterprise Pages tab. After a work area is created, the desktop pages tab provides links to work area configuration pages, which you can use to add or remove fields for display. This combination of page types, configuration pages, a wizard-driven page creation process, and the ability to add links to the Navigator menu means that you can quickly and easily expose custom object model extensions to your users.
Before you begin to customize or create new pages for a Fusion CRM application, review the following aspects of the Application Composer desktop page creation process:
Understanding Page Types
Using the Pages Overview Page
Defining Pages
Creating a Work Area
Object Security on Pages
Using Page Composer to Customize Pages
Every top-level CRM object can be displayed on a set of standard page types or in the regional area: the regional search in the regional area, an overview page, a creation page, and a details page.
Regional Area
The regional area is located on the left side of the page and includes a search pane. You can customize the regional search pane by specifying the fields to display.
Overview page
The overview page provides a list of records for an object and is the starting point in a CRM application for users to view and manage data. This page is where you can search for existing records and create new records. Users access an object's overview page from the Navigator menu at run time.
Note
Only top-level objects have an overview page. If an object was created as a child to another object, then the child does not have an overview page.
The overview page includes two regions, each of which has its own configuration page:
Local search region
The local search region is displayed above the summary table. Users can enter search criteria to refine the list of records in the summary table and then save this list as a saved search in the local search region.
Summary table
The summary table includes a list of the object records. Depending on the security setup, users can create a record, delete a record, or drill down into an existing record.
Tip
Optionally, define saved searches that users can select at run time to constrain the list of records displayed in the summary table.
To create new saved searches for your users, navigate to the search page where you want to create your saved search, and access Page Composer using the Administration menu. Then, enter and execute your search, and save it using the Save button under the search criteria in the application. You can also edit the saved searches that were created in Application Composer in earlier releases, by navigating to the Saved Search node for a custom or standard object.
Creation page
The creation page is the desktop page where users can create new records for an object. Depending on the security setup, users access the creation page by clicking the New icon or by selecting the New menu item from the Actions menu on the summary table's toolbar.
Details page
The details page is the desktop page where users can view more details about an object. Depending on the security setup, users access the details page by clicking the Edit icon or by selecting the Edit menu item from the Actions menu on the summary table's toolbar. Users can also access the details page by clicking the object record name itself in the summary table.
The details page can include both a default summary and a detailed summary. The default summary includes the primary object fields and is always displayed to users. The detailed summary includes additional fields for an object. You cannot add the same field to both the default and detailed summaries.
The details page can also display information related to the object record in subtabs. For example, the details page for an opportunity could include a subtab that lists customer contacts or previous orders.
Note
Some CRM objects, also known as common objects, do not have a standard work area. These include common components (note, interaction, task) and common objects (resource, organization contact, organization profile, address).
The Pages overview page in Application Composer provides an overview of the set of standard desktop pages for an object.
To access the Pages overview page:
Select an application on the main Overview page.
Select a standard or custom object in the object tree.
Select the Pages node.
Note
Only top-level objects have pages that you can configure. A child object does not exist outside the context of the parent object, and does not have its own work area.
From the Pages overview page, you can:
Create a new set of pages for an object, collectively known as a work area, if no set of pages has been created yet.
View the pages where the object is already exposed to users, and further customize those pages by adding or removing fields.
Create one or more subtabs to display on the object's Details page.
Create mobile application pages in Oracle Fusion Mobile Sales by using a wizard.
Similar to the work area creation process, the creation process for mobile pages uses a wizard where you can select which custom fields and related objects to add to mobile pages. Select the Mobile Pages tab to access the mobile pages wizard.
Expose new fields in an alternative set of simplified user interface pages, if available for a standard object, by selecting the Simplified Pages tab.
Note that the Simplified Pages tab displays only if a set of simplified pages exists for the standard object.
Use configuration pages to specify which fields are displayed on the standard application pages for an object. After you create new objects and fields, navigate to the Pages overview page. The Pages overview page contains hyperlinks to the configuration pages for an object's existing work area. Use these configuration pages to customize the object's work area pages, for example add newly created fields to a creation page.
Note
If the Pages overview page does not contain these configuration page hyperlinks, then the object does not yet have a work area, and you must create one if you want the object to be visible to users at run time. If a standard object does not expose the same set of configuration page links that you see for a custom object, it is because the standard object supports additional page types unique to that object.
Use the configuration pages available from the Pages overview page as follows:
Navigator Menu
For custom objects, specify the display label that appears in the Navigator menu at run time. For standard objects, use the Manage Menu Customizations task in the Setup and Maintenance work area to change the display label for standard object work areas.
Regional Pane
Select which panes to display in the regional area. You can also specify if you want the regional area and individual panes to be expanded (or collapsed) by default.
Overview Page
The overview page includes two regions, the local search and the summary table, and includes configuration pages for each.
Edit Local Search
The following figure show the Edit Local Search fields selection, one of the work area configuration pages in the Application Composer.
Select the fields that will be used to search in the local search region.
The list of fields available for selection is displayed to you in a single column, although the local search is formatted as a region with two columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the first column again, and so on.
Note
During field creation, consider indexing any fields that you plan to display as search criteria for your custom objects.
The following figure shows the Edit Local Search fields operators, one of the work area configuration pages in the Application Composer.
For any field, you can select the following options:
Required: The user must include this field in a search at run time.
At Least One is Required: The user must include at least one of the selected fields in a search at run time.
Edit Summary Table
Select the fields that you want to display as columns in the summary table.
Add custom buttons to the summary table, if you previously created them.
Creation Page
Select the fields that you want to display on the object's creation page.
The list of fields available for selection is displayed to you in a single column, although the creation page is formatted as a page with three columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the third column, the fourth field you select is displayed in the first column again, and so on.
Details Page
Select the fields that you want to display on the object's details page, including both the default summary and detailed summary regions.
Tip
Include the primary object fields in the default summary, since the detailed summary could be collapsed when users navigate to this page.
The list of fields available for selection is displayed to you in a single column, although the details page is formatted as a page with three columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the third column, the fourth field you select is displayed in the first column again, and so on.
Add custom buttons, links, and actions to the details page, if you previously created them.
Select the Allow Attachments check box to enable the attachments feature on the run time details page, in the collapsible detailed summary.
The Pages Overview page also lets you configure subtabs that display on the details page. Subtabs include information that is related to the object record. Adding subtabs to a details page is discussed in a related topic.
If the object uses a tree rather than subtabs to display related pages, then you can configure tree nodes that you add to the object's tree. The information displayed in both subtabs and trees can be derived from other objects or from a source outside Oracle Fusion CRM Applications. For more information on adding tree nodes to an object's tree, see the related topic on this subject.
Reusable Regions
At run time, users can launch the Select and Add dialog box from a dynamic choice list field to search for and select a value. Users can use the dynamic choice list field at run time, and can launch the picker to limit their choices and more easily find and make the right selection. Use the Create Picker link or Edit Picker link to access the Search and Select picker dialog box for an object, which you can start from any dynamic choice list that is based on that object. In the Search and Select picker dialog box you can specify which fields you want to appear in the search region and in the search results table.
Note
If you create a dynamic choice list that is based on a custom object, you must create the picker for the same custom object.
To create or edit a picker, use the following steps.
Create or edit the dynamic choice list field for which you want to create a picker. In the Related Object field for that dynamic choice list, make sure that you have selected the correct object on which you want to base the dynamic choice list.
In the Pages page, click Create Picker or Edit Picker.
The Edit Picker page opens.
In the Configure Picker Search list, select the fields that you want to appear in the search region.
In the Configure Picker Table list, select the fields that you want to appear in the search results table.
At run time, the user can select a value from the dynamic choice list field by using the Search and Select picker to find the right value among all the other values.
Navigate to the object's work area for which you created the picker and dynamic choice list.
In the Overview page, click the object name.
The following figure shows the Summary page for a custom object named Primary with a dynamic choice list field named Opportunity List.
In the Edit object page, click the magnifying glass icon next to the dynamic choice list field to open the Search and Select picker dialog box.
The following figure shows the Search and Select picker dialog box at run time.
The user can add the selected value in the dynamic choice list field by using the following steps:
In the Search and Select picker dialog box, enter the search criteria for the field.
Click Search.
Select the record.
Click OK.
The value is populated into the dynamic choice list field.
Edit Regional Search
Select the fields the user can search on using the search pane in the regional area.
To display the entire regional search pane, check the Enable check box. Otherwise, the regional search shows only the selected fields.
For any field, you can select the following options:
Required: The user must include this field in a search at run time.
At Least One is Required: The user must include at least one of the selected fields in a search at run time.
Default Operator: The user can define each search field value by using one of the listed operator options. For example, you can specify that CreationDate is equal to or occurs before or after the date the user enters, or that Sales Name starts with a specific letter.
Note
Because some CRM objects (common components and common objects) do not have a standard work area, the configuration pages available from their Pages overview page are different than described previously. For example, the Trading Community address object has configuration pages for customizing the overview page, creation page, and address details form. The Trading Community organization profile has configuration pages for customizing only the details form and create form.
When you customize pages for common objects, the changes you make are reflected across the multiple applications where the object is used, provided that the applications also share the same metadata repository.
When first created, top-level custom objects do not yet have pages in a run time CRM application where those objects are exposed to users. For each custom object that you create, you must create the set of pages where the records that belong to the object will be exposed to users.
The Application Composer uses a wizard to walk you through the creation of these pages, collectively known as a work area. For more information on creating a work area, see the related topic on this subject.
Do not create a work area for child objects.
After you create custom objects and fields, you then expose them on desktop pages for your users. By default, the object and its records are visible and can be edited only by a user who has the Application Composer duty role. Grant additional access manually for either an object or role, using the Application Composer's security policy configuration pages.
The security options available to you for restricting access to custom objects, including child objects, are discussed in a related topic.
After you create a set of new pages, or edit preexisting pages delivered by a CRM application, you cannot use Page Composer to edit those pages again.
Note
The exception is the customer profile in Oracle Fusion Customer Center. You can create and add new fields to the Sales Account region on the customer profile using Page Composer.
Review these aspects of the work area creation process in the Application Composer before you create a new work area for a custom object:
Using the work area wizard
Configuring the Navigator menu
Configuring the local search region
Configuring the overview and creation pages
Configuring the details page
Access the wizard on the Pages Overview page using the same navigation path that you use to configure pages in an existing work area. However, if a work area has not yet been created for an object, then hyperlinks to the work area configuration pages are not displayed. Instead, the Pages Overview page displays only a single hyperlink to launch the work area wizard.
To access the work area wizard:
Select an application on the main Overview page.
Select a standard or custom object in the object tree.
Select the Pages node.
Note
Only top-level objects have pages that you can configure. A child object does not exist outside the context of the parent object, and does not have its own work area.
Select the hyperlink to launch the work area wizard.
Note
Use the work area wizard to create a work area.
Use the work area configuration pages to customize existing work area pages.
As part of the work area creation for a custom object, you must specify the object label that appears in the Navigator menu at run time. The label you specify is what users will select to navigate to this work area.
On this page, you can also do the following:
Select a menu category under which the object label appears.
Adjust the position of Navigator menu items within the selected menu category.
For example, move your newly created object label to appear at the top of the list.
After creating the work area for a custom object, the work area label automatically appears in the Navigator menu without your having to reauthenticate.
Note
Changing the object label on the Navigator menu is available in the Application Composer only for custom objects. For standard objects, use the Manage Menu Customizations task in the Setup and Maintenance work area to change the display label for standard object work areas.
Extending the Regional search is part of the first step in creating a work area. By adding custom parameters, you can expand the search parameters of the Regional area for both custom and out-of-the-box objects in a Fusion application at run time.
Each field can have one of the following properties:
Required: Set a field as required on the object search region. This field must be populated.
At Least one is required: Set at least one field as a required field or a collection of required fields. You must populate one field from this group.
Default Operator: Set an operator field that appears in object search as the default.
Select the fields that you want to display as search criteria in the local search region. The local search region appears above the summary table on an object's overview page. Adding fields to this region is optional.
Select the fields that you want to display as search criteria fields in the local search region.
The list of fields available for selection is displayed to you in a single column, although the local search region is formatted as a region with two columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the first column again, and so on.
Note
During field creation, consider indexing any fields that you plan to display as search criteria for your custom objects.
Select the fields that you want to display in the work area's overview page, and in the object's creation page.
Select the fields that you want to display as columns in the summary table, on the object's overview page.
Select the drilldown column for the summary table.
The drilldown column is the column in the summary table that users can click to drill down to an object record's details page. You cannot change a summary table's drilldown column after the work area is created.
Select the Allow Access Grant check box if you want users to be able to grant access to a record in the summary table to another user, at run time.
Add custom buttons to the summary table, if you previously created them.
Select the fields that you want to display on the object's creation page.
The fields that you select should include the object's required fields.
The list of fields available for selection is displayed to you in a single column, although the creation page is formatted as a page with three columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the third column, the fourth field you select is displayed in the first column again, and so on.
Select the fields that you want to display on the object's details page.
Note
A details page can have subtabs, which include information that is related to the object record. For example, the details page for an opportunity could include a subtab that lists customer contacts or previous orders. To add subtabs to a details page, create the work area first, then navigate back to the Pages Overview page. Adding subtabs to a details page is discussed in a related topic.
Select the fields that you want to display on the object's details page, including both the default summary and detailed summary regions.
Tip
Include the primary object fields in the default summary, since the detailed summary could be collapsed when users navigate to this page.
The list of fields available for selection is displayed to you in a single column, although the details page is formatted as a page with three columns. The first field you select is displayed in the first column, the second field you select is displayed in the second column, the third field you select is displayed in the third column, the fourth field you select is displayed in the first column again, and so on.
Add custom buttons, links, and actions to the details page, if you previously created them.
Select the Allow Attachments check box to enable the attachments feature on the run time details page, in the collapsible detailed summary.
Review these aspects of the subtab creation process in Application Composer before you begin to add subtabs to an object's details page:
Using the Details page
Adding subtabs
Subtab types:
Child or related object subtabs
Context link subtabs
Common component subtabs
Web content subtabs
Note
Subtabs and tree nodes are two master/detail UI patterns which Oracle Fusion CRM applications support.
For custom objects, only subtabs are supported.
For standard objects that are already using tree nodes, such as the Sales Account Profile and Partner objects, additional details adopt the same tree node pattern. In other words, if a standard object uses a tree to display its related pages, then you would expose child or related objects, for example, as tree nodes instead of subtabs on a details page. Adding tree nodes is discussed in a related topic.
The details page is the desktop page where users can view more details about an object. Depending on the security setup, users access the details page by clicking the Edit icon or by selecting the Edit menu item from the Actions menu on the summary table's toolbar. Users can also access the details page by clicking the object record name itself in the summary table.
The details page can include both a default summary and a detailed summary. The default summary includes the primary object fields and is always displayed to users. The detailed summary includes additional fields for an object. You cannot add the same field to both the default and detailed summaries.
The details page can also display information related to the object record in subtabs. For example, the details page for an opportunity could include a subtab that lists customer contacts or previous orders.
Add a subtab to an object's details page from that object's Pages Overview page. The details page must exist already; you cannot add subtabs when first creating a work area.
To add a subtab to an existing details page:
Select an application on the main Overview page.
Select a standard or custom object in the object tree.
Select the Pages node.
Note
Only top-level objects have pages that you can configure. A child object does not have its own work area.
On the Pages Overview page, click the Create Subtab icon in the Details Page region to create one or more subtabs to display on the object's details page.
Select the type of subtab you want to add.
Tip
To hide subtabs that you previously added using Application Composer, use Page Composer.
A relationship is a foreign key association between two objects. Using Application Composer, you can create a one-to-many relationship between two objects within the same application. Once relationships are created, you can expose the "many" objects on a subtab that is displayed on the "one" object's details page. For example, an account can have multiple service requests associated to it. To expose a list of service requests associated with a specific account as a subtab on the account's details page, you must first create a one-to-many relationship between the account and service request objects. In this example, the account is the source object and the service request is the target object. This relationship adds the account identifier to the service request object's table.
Application Composer lets you add a subtab to an object's details page for either a child object or for three types of related objects. These objects exist in four types of one-to-many relationships:
Parent child relationship
Parent child relationships are implicitly created when a custom object is created as a child of a top-level object.
For example, to enable the creation of a subaccount subtab on an account's details page, you would create the subaccount object as a child of the account object. This relationship adds the account identifier to the subaccount object's table.
Choice list relationship
Choice list relationships are implicitly created between two objects when you create a dynamic choice list field.
For example, to enable the creation of a department subtab on an employee's details page, you would create a dynamic choice list, HR Representative, for the department object where the choice list's related object is employee. Application Composer automatically creates the underlying relationship for you, where the employee is the source object and the department is the target object. This relationship adds the employee identifier to the department object's table, thus enabling the creation of a department subtab on an employee's details page. The subtab displays all departments that an HR representative can manage, since each HR representative can be in charge of multiple departments of a company.
Reference relationship
Reference relationships are explicitly created between two top-level objects using the Create Relationships page.
Using our previous example, perhaps you don't need to display an HR Representative choice list on a department desktop page, but you still want to add a department subtab to an employee's details page. In this case, manually create a reference relationship between the employee and department objects where the employee is the source object and the department is the target object. This enables the creation of the department subtab. Such a reference relationship, however, does not automatically create a corresponding HR Representative choice list for use on the department desktop page. In fact, once you manually create a relationship, you cannot reuse the relationship to create a choice list. This means that you should carefully consider the need for a choice list before you create a reference relationship.
Standard relationship
Standard relationships are relationships that are already created between two standard objects by the Oracle Fusion CRM application.
To add a child or related object subtab to an existing details page:
On the Pages Overview page, click the Create Subtab icon.
Select Child or Related Object.
On the Child or Related Object subtab configuration page:
Select the related object from the list of all related objects that is to be exposed on the subtab, and choose the subtab display label.
Optionally hide the New and Delete buttons that appear on the subtab at run time.
For child object subtabs, you can also optionally hide the Edit button.
For child object subtabs only, specify if you want to display the Manage Permission button on the subtab at run time.
At run time, users can select an object record and click that button to specify the level of access another user should have to the selected record.
Select which fields and links you want to display on the subtab summary table at run time.
You can configure fields and links for the main summary table which lists the child object records or related object records.
Select which buttons you want to display on the subtab at run time.
Note
This region appears only if you previously created buttons for this object.
Select which fields you want to display on the subtab detail form at run time.
You can configure fields for the detail form that appears under the summary table. If the subtab's object is a child object, then users can enter child object data into this detail form at run time. Always include required fields in this section.
If the subtab's object is a related object, then users can associate an existing record of the subtab object to the master object of the page. However, to create new related object records, users must do so in the object's own creation page.
A context link subtab displays a filtered list of records from any top-level object, where the filter is often based on the run time values from the current object. The object does not have to be related to the current object. Context link subtabs are read only.
To add a context link subtab to an existing details page:
On the Pages Overview page, click the Create Subtab icon.
Select Context Link.
On the Context Link subtab configuration page:
Select the object that is to be exposed on the subtab, and choose the subtab display label.
Optionally constrain the list of records displayed at run time using a set of search criteria for the selected object, whose run time values must match the current object record's run time values.
Tip
Values can be literal values, or derived from the run time values in the current object record, or from the run time values in the current object's parent record.
If your search criteria includes a fixed choice list field, then you must specify the fixed choice list's run time value using the lookup code, not the lookup meaning.
Select which fields you want to display on the subtab's read-only summary table at run time.
You can configure fields for the main summary table which lists the child object records or related object records.
Select which fields you want to display on the subtab's read-only detail form at run time.
You can configure fields for the detail form that appears under the summary table.
A common component subtab adds a Notes, Tasks, Interactions or Appointments subtab to show a list of the selected components related to a custom, top-level object. Each component has a standard user interface (UI) that is shared across all Oracle Fusion CRM applications. To customize such a UI for all common components (other than Appointments), select the appropriate object under the Common application, then select the Pages node on the object's navigation tree to access the work area configuration pages.
At run time, users can access these subtabs and create a common component record that is tied to the object record. For example, a user can record a customer interaction on an service request record.
Notes
Tasks
Interactions
Appointments
To add a common component subtab to an existing details page:
On the Pages Overview page, click the Create Subtab icon.
Select Common Component.
On the Common Component subtab configuration page, select the type of common component you want to add to the details page as a subtab.
A Web content subtab exposes an external Web site right on an object's details page. The Web content is a result of the expression that you define which builds the intended URL.
For example, on the Contact details page, perhaps you want to add a Google map that shows the location of the contact. The Google Maps API expects the URL to be formatted in a certain manner. In this example, write an expression using the fields: Contact Address, Contact City and Contact State. Then, pass the URL to the Google Maps API.
To add a Web content subtab to an existing details page:
On the Pages Overview page, click the Create Subtab icon to create one or more subtabs to display on the object's details page.
Select Web Content.
On the Web Content subab configuration page, enter the display label for the subtab, and then define the URL to retrieve the subtab's Web content.
Optionally use the expression editor to build the URL expression that you need.
The expression you build should include the following:
Use the HTTP protocol.
Optionally include field values from the current object as parameters, or user variables.
Enclose static strings in double quotation marks.
For example, "http://www.abc.com/".
For example:
def myURL1 = adf.util.GlobalEncodeField(ContactAddress_c)
def myURL2 = adf.util.GlobalEncodeField(ContactCity_c)
def myURL3 = adf.util.GlobalEncodeField(ContactState_c)
def myfinalURL = "http://maps.google.com/maps?hl=en&q=" + myURL1 + "+" + myURL2 + "+" + myURL3
return(myfinalURL)
Review these aspects of the tree node creation process in the Application Composer before you begin to add tree nodes to an object's tree:
Adding tree nodes
Tree node types:
Child or related object tree nodes
Context link tree nodes
Web content tree nodes
Note
Subtabs and tree nodes are two master/detail UI patterns which Oracle Fusion CRM applications support.
For custom objects, only subtabs are supported.
For standard objects that are already using tree nodes, such as the Sales Account Profile and Partner objects, additional details adopt the same tree node pattern. In other words, if a standard object uses a tree to display its related pages, then you would expose child or related objects, for example, as tree nodes instead of subtabs on a details page. Adding subtabs is discussed in a related topic.
Add a tree node to an object's tree from that object's Pages Overview page.
To add a tree node to an object's tree:
Select an application on the main Overview page.
Select a standard object, either the Sales Account Profile or Partner object, in the object tree.
Select the Pages node.
Note
Only the top-level objects, Sales Account Profile and Partner, let you add tree nodes.
On the Pages Overview page, click the Create Tree Node icon to create one or more tree nodes to display on the object's tree.
Select the type of tree node you want to add.
A relationship is a foreign key association between two objects. Using the Application Composer, you can create a one-to-many relationship between two objects within the same application. Once relationships are created, you can expose the "many" objects on a tree node that is displayed on the "one" object's tree. For example, a partner can have multiple contacts associated to it. To expose a list of contacts associated with a specific partner as a tree node on the partner's tree, you must first create a one-to-many relationship between the partner and contact objects. In this example, the partner is the source object and the contact is the target object. This relationship adds the partner identifier to the contact object's table.
The Application Composer lets you add a tree node to an object's tree for either a child object or for three types of related objects. These objects exist in four types of one-to-many relationships, which are described in detail in the related topic about object relationships:
Parent child relationship
Choice list relationship
Reference relationship
Standard relationship
To add a child or related object tree node to an existing tree:
On the Pages Overview page, click the Create Tree Node icon.
Select Child or Related Object.
On the Child or Related Object tree node configuration page:
Select the tree node category and enter the tree node label.
Select the related object from the list of all related objects that is to be exposed on the tree node page.
Set the position of the new tree node.
Optionally hide the New and Delete buttons that appear on the tree node page at run time.
For child object tree node pages, you can also optionally hide the Edit button.
For child object tree node pages only, specify if you want to display the Manage Permission button on the tree node page's summary table at run time.
At run time, users can select an object record and click that button to specify the level of access another user should have to the selected record.
Select which fields and links you want to display on the tree node page's summary table at run time.
You can configure fields and links for the main summary table which lists the child object records or related object records.
Select which buttons you want to display on the tree node page at run time.
Note
This region appears only if you previously created buttons for this object.
You cannot add buttons to a tree node page for the Sales Account Profile object.
Select which fields you want to display on the tree node page's detail form at run time.
You can configure fields for the detail form that appears under the summary table. If the tree node's object is a child object, then users can enter child object data into this detail form at run time. Always include required fields in this section.
If the tree node's object is a related object, then users can associate an existing record of the tree node object to the master object of the page. However, to create new related object records, users must do so in the object's own creation page.
A context link tree node page displays a filtered list of records from any top-level object, where the filter is often based on the run time values from the current object. The object does not have to be related to the current object. Context link tree node pages are read only.
To add a context link tree node to an object's tree:
On the Pages Overview page, click the Create Tree Node icon.
Select Context Link.
On the Context Link tree node configuration page:
Select the tree node category and enter the tree node label.
Enter the name of the tree node filter.
Select the object that is to be exposed on the tree node page.
Set the position of the new tree node.
Optionally constrain the list of records displayed at run time using a set of search criteria for the selected object, whose run time values must match the current object record's run time values.
Tip
Values can be literal values, or derived from the run time values in the current object record, or from the run time values in the current object's parent record.
If your search criteria includes a fixed choice list field, then you must specify the fixed choice list's run time value using the lookup code, not the lookup meaning.
Select which fields you want to display on the tree node page's read-only summary table at run time.
You can configure fields for the main summary table which lists the child object records or related object records.
Select which fields you want to display on the tree node page's read-only detail form at run time.
You can configure fields for the detail form that appears under the summary table.
A Web content tree node page exposes an external Web site on desktop page. The Web content is a result of the expression that you define which builds the intended URL.
For example, on the Contact tree node page, perhaps you want to add a Google map that shows the location of the contact. The Google Maps API expects the URL to be formatted in a certain manner. In this example, write an expression using the fields: Contact Address, Contact City and Contact State. Then, pass the URL to the Google Maps API.
To add a Web content tree node to object's tree:
On the Pages Overview page, click the Create Tree Node icon to create one or more tree nodes to display on the object's tree.
Select Web Content.
On the Web Content tree node configuration page:
Select the tree node category and enter the tree node label.
Set the position of the new tree node.
Define the URL to retrieve the tree node page's Web content.
Optionally use the expression editor to build the URL expression that you need.
The expression you build should include the following:
Use the HTTP protocol.
Optionally include field values from the current object as parameters, or user variables.
Enclose static strings in double quotation marks.
For example, "http://www.abc.com/".
For example:
def myURL1 = adf.util.GlobalEncodeField(ContactAddress_c)
def myURL2 = adf.util.GlobalEncodeField(ContactCity_c)
def myURL3 = adf.util.GlobalEncodeField(ContactState_c)
def myfinalURL = "http://maps.google.com/maps?hl=en&q=" + myURL1 + "+" + myURL2 + "+" + myURL3
return(myfinalURL)
An action can be based on a script (a Groovy method that is defined on the object) or a URL. When configuring the work area for a standard or custom object, you can add custom links or actions to a page-level or task-level Actions menu or as a toolbar button. You can also manage the Actions menu by hiding or showing menu items, rearranging the action groupings or display sequence, and managing the toolbar by hiding or showing icons and buttons. You can also configure the Actions menu and buttons in the Create and Edit subtabs and tree nodes. 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 provide a static link from an overview page to a corporate web site. Or, you might want to include a button on a summary table, which users can click at 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 an action, it can be exposed as a button or an option on the Action menu. After you create a link, it can be selected as a field.
You add actions or links in two steps:
Define an action or link for an object.
Use the Oracle Fusion CRM Application Composer's work area configuration pages to add that action or link to an Overview page or Details page.
The following figure shows a button and a link added to the Sales Opportunities Overview page.
To define an action or link for an object:
Select an application on the main Overview page.
Select a standard or custom object in the object tree.
Select the Actions and Links node.
To create a new script or URL:
In the Create Action or Link page, enter a descriptive name in the Display Label field.
For Type, select Action and, for Source, select Script or URL.
In the Script region click the New icon.
The following figure shows the Create Action or Link page showing a static URL enclosed in double quotation marks..
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 editor, 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 content check box.
The following figure shows a script in the URL Definition window.
If the source is a script, you can either select a predefined object function from the Method Name choice list, or create a new object function using the expression editor.
After you save actions or links, you can expose them on UI pages by configuring the Applications Composer options available in the Edit Summary Table page in the Pages node of an object.
The following figure shows a selected button and fields in the Edit Summary Table page in the Pages node of Applications Composer.
For example, the Edit Summary Table could have links in the fields selector with standard or custom fields because at runtime the UI displays the URL link as if it is a field in a table. Actions can be configured in potentially two places in the UI, on the toolbar as a button and in the Actions menu for a table. Depending on how you configure the actions and links, in the Edit Summary Table you could see both the available and selected buttons and actions, or one, or none.
The figure above shows the Configure Summary Table: Actions with options checked for the Show Create, Show Edit, and Show Delete options on the Action menu. It also shows a custom button and a custom action.
After you define an action, you can then expose it as a button or an Action menu option in a variety of locations:
Summary table on the overview page
Default summary on the details page
Summary table on a details page's subtab
Summary table on a tree node page for a child object
Revenue table on the details page for the opportunity object
The following figure shows an overview page with exposed Create, Edit, and Delete options and a custom Ask_Assistance option on the Actions menu. It also shows the custom toolbar button Ask_Assistance, and a custom table column.
The figure above shows the exposed Create, Edit, and Delete options and a custom Ask_Assistance option on the Actions menu. It also shows the custom toolbar button Ask_Assistance, and a custom table column.
After you define a link for an object, you can add that link to a variety of locations in that object's work area. You can add a link wherever you can add a field. Possible locations include, but are not limited to:
As a column in the summary table on the overview page
Default summary on the details page
As a column in the summary table on a details page's subtab
In the detail form under the summary table on a details page's subtab
As a column in the summary table on a tree node page for a child object
As a column in the revenue table on the details page for the opportunity object
Important
In previous releases, Oracle Fusion CRM Application Composer provided you with the ability to create and edit saved searches, available to your users at the site level. In the current release, you can only edit existing saved searches, since Page Composer also lets you create and edit saved searches at the site level.
Review these aspects of the saved search definition process in the Oracle Fusion CRM Application Composer before you begin to view or edit saved searches for CRM objects:
Saved searches at run time
Editing a saved search
The list of saved searches is available from the Saved Search choice list above the overview page's summary table.
Searches are displayed in alphabetic order, followed by the Personalize option.
The saved searches that you edit for an object are available to all users and roles with functional security access to the object's overview page.
You edit a saved search for an object on the object's Edit Saved Search page. You can edit saved searches only for top-level objects, because only top-level objects have overview pages in the run time CRM application. To create a new saved search, use Page Composer.
To edit a saved search for an object:
Select an application on the main Overview page.
Select a standard or custom object in the object tree.
Select the Saved Searches node.
Select the Saved Search that you want to edit from the summary table in the Saved Searches page and select Actions > Edit
On the Edit Saved Search page for the object, you can modify the display label for the saved search.
The display label is the label that appears in the Saved Search choice list.
You cannot edit the Name field.
The Name is automatically generated based on the specified display label at the time of creating the saved search. Spaces in the display label are converted to underscores in the Name. For example, if the display label is Top Ten Opportunities, then the Name is automatically generated as Top_Ten_Opportunities at the time of creating the saved search.
Modify the search criteria.
You can enter up to four search conditions using the following criteria:
Specify the matching criteria, All or Any.
All appends multiple conditions with an AND
.
Any appends two conditions with an OR
.
If more than two conditions exist, then you cannot select Any.
Field Name
Specify the object field who value you want to include as a search criterion.
Long text and formula fields are not available for use in saved searches.
Tip
For better performance, the fields you include in a saved search should be indexed. You index a field when it's first created.
Operator
Operator values available for selection are dependent upon the type of field selected.
This table lists, for each field type, the operators that are available for selection, as well as the values that you can enter.
Field Type |
Available Operators |
Available Values |
---|---|---|
|
|
Enter a literal value. Note For percentage fields, divide the percentage by 100 to calculate the literal value you should enter as a search criterion. For example, to correctly use 150percent in your saved search, you must enter 1.5. |
|
|
Enter a literal value. Tip For fixed choice list fields, you must enter the lookup code, not the lookup meaning. |
|
|
Enter:
|
Value
The values that you specify are applied as the search criteria against the object records at run time.
See the previous table.
Review these aspects of the custom object security process in the Application Composer before you begin to define your security policies:
Securing objects
Securing roles
Enabling function security and data security
Application Composer and the Oracle Authorization Policy Manager (APM)
Default security settings
The object-centric Define Policies page displays a list of the enterprise-level duty roles which map to a CRM job role. Use this page to manage access to either a top-level or child custom object by specifying a security policy for one or more duty roles. When you do this, users with the corresponding roles can access the custom object and its data, depending on the security policies you define.
To access the object-centric Define Policies page:
Select an application on the main Overview page.
Select a custom object in the object tree.
Select the Security node.
Or, from the role-centric Define Policies page, select a custom object.
From the object-centric Define Policies page, you can:
Enable function security for a role.
Enable data security for a role.
Allow users to grant access to a specific record at run time, to users with a given role.
The Role Security page displays a list of the enterprise-level duty roles, which map to a CRM job role. Select a role and click the Define Policies button to navigate to the role-centric Define Policies page, which displays a list of the custom objects for your CRM implementation. Use this page to manage access for users with the corresponding role by specifying a security policy for one or more top-level or child custom objects. When you do this, users with the corresponding role can access the custom objects and related data, depending on the security policies you define.
To access the role-centric Define Policies page:
Select an application on the main Overview page.
Select the Role Security node from the Common Setup pane.
Or, select the Role Security hyperlink in the local area of the main Overview page.
Or, from the object-centric Define Policies page, select a role.
Click the Define Policies button.
From the role-centric Define Policies page, you can:
Enable function security for a custom object.
Enable data security for a custom object.
Allow users to grant access to a specific record at run time, to users with a given role.
View related roles, if any.
If a related role is displayed next to an object, then the selected role is inheriting its access to that object from the related role. You can drill down into the related role to view its security policies.
A security policy specifies the type of access to an object and its records that users with the corresponding roles have. Access includes both function security as well as data security. Security settings are the same whether you are defining a security policy for an object or a role.
On the Define Policies page, the first four columns in the table manage function security, which applies to the object as a whole:
Create
Users with the corresponding role can create a record of the object.
View
Users with the corresponding role can view the object's work area pages.
Update
Users with the corresponding role can update a record of the object.
Delete
Users with the corresponding role can delete a record of the object.
The next two columns in the table manage data security.
View All
Users with the corresponding role can view the object's records.
Update All
Users with the corresponding role can update the object's records.
Tip
When clicking View All or Update All, the corresponding View and Update function security check boxes are automatically selected.
Wait for the page to refresh to confirm all your selections.
The last column contains the Grant Access check box. Selecting this check box controls the display of the Manage Permission button on the object's summary table at run time. At run time, users with the corresponding role (or an administrative role) can select an object record and click that button to specify the level of access another user should have to the selected record.
Note
To let users view or update records at run time, you must enable both function security as well as data security for an object. To let users create records, you only have to enable function security. To let users delete records, you must grant users instance-level delete privileges using the Grant Access check box and the run time Manage Permission button.
Across Oracle Fusion applications, Oracle Authorization Policy Manager (APM) manages the security policies that control access based on roles. However, you define the security policies for custom objects in the Application Composer's object-centric and role-centric Define Policies pages. This is outside APM.
Since you define the security policies outside APM, you cannot later modify the security policies within APM. Instead, modify all security policies for custom objects using only the Application Composer.
By default, top-level custom objects are visible and editable only to users with a default duty role specified by a CRM application. You must manually grant additional access to other duty roles, if desired. For example, if you create a custom object in Oracle Fusion Sales, then only users with the default duty role specified by Sales are automatically granted access to that object. This lets you first access an object and its pages for testing, before you officially grant access to your customizations to users in a production environment.
This table lists the default duty roles that are provided by CRM applications:
Application |
Default Duty Role |
---|---|
Oracle Fusion Customer Center |
Sales Administrator Duty Marketing Operations Manager Duty |
Oracle Fusion Marketing |
Marketing Operations Manager Duty |
Oracle Fusion Sales |
Sales Administrator Duty |
Child objects do not inherit security settings from parent objects. Rather, if you create a custom child object, then a default set of duty roles are granted access to the child object. In other words, a child object is visible and editable only to users with these default duty roles, as follows:
Application |
Child Objects of This Parent Object |
Access Granted to These Duty Roles |
---|---|---|
Oracle Fusion Customer Center |
Sales Account Profile |
Sales Administrator Duty Marketing Operations Manager Duty |
Oracle Fusion Marketing |
Sales Lead |
Marketing Operations Manager Duty Sales Administrator Duty Channel Operations Manager Duty |
Oracle Fusion Marketing |
Marketing Campaign Marketing Response Marketing List Marketing Treatment Marketing Event Activity Marketing Advertising Activity |
Marketing Operations Manager Duty |
Oracle Fusion Marketing |
Marketing Budget Marketing Claim Marketing Budget Entry Marketing Budget Fund Request |
Marketing Operations Manager Duty Channel Operations Manager Duty |
Oracle Fusion Sales |
Opportunity Sales Competitor |
Sales Administrator Duty |
Oracle Fusion Sales |
Partner |
Channel Operations Manager Duty |
Oracle Fusion Common CRM |
Trading Community Org Contact Trading Community Resource Profile Trading Community Organization Profile Trading Community Address |
Customer Data Steward Duty |
In Oracle Fusion, two processes exist to enable the importing and exporting of object data: file-based import and bulk export.
File-based import supports the import of data from an external text or xml file to interface tables and then from interface tables to target application tables.
Note
File-based import bypasses any Groovy validation and trigger logic on an object. For example, object workflows are not triggered by an import.
Bulk export lets you extract large volumes of data from CRM objects, both as extracts of a full set of records for an object as well as incremental extracts. The system creates comma or tab-delimited files with the extracted data, which are available to users as attachments to the batch records that have been executed.
The object model extensions that you make using the Application Composer do not create the artifacts required by these import and export processes. For example, file-based import leverages Oracle Data Integrator (ODI).
Accordingly, after completing your object model extensions, generate the required artifacts to register your extensions and make them available for importing and exporting.
Note
The creation of import and export artifacts occurs only in the Oracle Metadata Services (MDS) mainline, and is not supported within the MDS sandbox.
To enable the import and export of custom object data:
Select an application on the main Overview page.
Select the Import and Export link in the Common Setup pane, or in the local area of the main Overview page.
On the Import and Export page, click the Generate button.
After you enable your object model extensions for importing and exporting, you can then schedule your file-based import and bulk export processes using the following tasks, available by selecting Setup and Maintenance from the Tools menu and searching on the task name.
To schedule your custom object imports, select the Manage File Import Activities task.
To initially set up file-based import for importing custom object data, select the Manage File Import Objects and Manage File Import Mappings tasks.
Note
Custom child objects are imported as part of the parent object.
To schedule your custom object exports, select the Schedule Export Processes task.
Note
Both top-level and child custom objects are available as independent exportable objects.
Important
Refer to Oracle Fusion CRM product-specific documentation for additional details on how Oracle Fusion CRM products enable the import and export of custom object data (custom fields) for standard objects.
The following table describes how you can use each mode of Page Composer to customize dashboard pages and other select pages (such as the Partner Public Profile page, Partner Landing page, Partner Registration, Customer Snapshot, and Customer Overview - Analysis tab), and customize transactional pages (all other non-dashboard pages).
Use Cases |
Design View - Standard mode |
Design View - Direct Selection mode |
Page Type |
---|---|---|---|
Add content (Business Intelligence reports, CRM portlets such as Calendar) |
Yes |
No |
Dashboard and other select pages |
Delete region |
Yes |
No |
Dashboard and other select pages |
Move region |
Yes |
No |
Dashboard and other select pages |
Change page layout (for example, change a two column layout to three column layout) |
Yes |
No |
Dashboard and other select pages |
Default region state (open or close) |
Yes |
No |
Transactional pages (all non-dashboard pages) |
Manage save queries (create and edit) |
Yes |
No |
Transactional pages (all non-dashboard pages) |
Hide or show field |
No |
Yes |
Transactional pages (all non-dashboard pages) |
Change field label |
No |
Yes |
Transactional pages (all non-dashboard pages) |
Make field required or not |
No |
Yes |
Transactional pages (all non-dashboard pages) |
Make field read-only or updateable |
No |
Yes |
Transactional pages (all non-dashboard pages) |
Reorder fields in a Form |
No |
Yes |
Transactional pages (all non-dashboard pages) |
Reorder table columns |
Yes |
Yes |
Transactional pages (all non-dashboard pages) |
Hide or show table columns |
Yes |
Yes |
Transactional pages (all non-dashboard pages) |
Set table column width with the mouse |
Yes |
No |
Transactional pages (all non-dashboard pages) |
Set table column width and min width in percent or pixels |
No |
Yes |
Transactional pages (all non-dashboard pages) |
Make column sortable or not |
No |
Yes |
Transactional pages (all non-dashboard pages) |
The following table describes some of the primary differences between Page Composer and the Application Composer.
Customization Task |
Available in Page Composer (site, job role, external or internal level)? |
Available in Application Composer (site level only)? |
---|---|---|
Make object model extensions and expose your customizations by creating or modifying work area pages |
No |
Yes |
Reorder subtabs |
No |
Yes |
Customize dashboard pages |
Yes |
No |
Add content from the Resource Catalog |
Yes |
No |
Simple field customizations (show, hide, make read only, make required) |
Yes (WYSIWYG - what you see is what you get) |
Yes (non-WYSIWYG) |
Select the MDS layer where you want to author customizations, such as at the site layer or job role layer |
Yes |
No |
View results of customizations immediately |
Yes, in the Page Composer design interface |
Yes, in the CRM application that you are customizing |