How do I change how a field is displayed on a List page for Oracle Sales?

You can configure how a field is displayed on an Oracle Sales list page by applying a custom field template. A field template defines the properties and styling details for the contents of the field. For example, you can create a field template for displaying the Rank of a Lead in different colors based on its value such as red for Hot, orange for Warm and blue for Cold.

Custom field templates provide the following source-supported benefits:

• Faster visual scanning and decision-making by helping users recognize status, priority, or category without reading all field text.
• Better usability for high-density lists because icons and color signals can communicate information efficiently.
• Easier navigation by allowing links to third-party applications or web pages.

Note: The implementation path differs slightly for standard objects and custom objects.

• Standard objects
  1. Enable templates for the list page
  2. Create a field template in the object layout
  3. add a field template map to associate an Adaptive Search REST field with the template.
• Custom objects
  1. Create or use the custom Adaptive Search service connection
  2. Enable templates for the list page
  3. Create a layout and field template
  4. Create a Dynamic Table rule set
  5. Map Adaptive Search REST fields to templates.

Configure a Custom Field Template for a Standard Object

Use this procedure to configure a field template for a standard object in Visual Builder Studio.

1. Enable field templates for the page:
   1. Open Visual Builder Studio.
   2. Navigate to the list page on which you want to enable the custom field template. The source uses the accounts-list page as an example.
   3. Open the Variables tab.
   4. Locate the advancedConfiguration constant.
   5. Change enableTemplates from false to true.

      {
       "enableTemplates": true
      }

2. Create a field template:
   1. Open the Layouts tab and search for the object name. The source uses Account as an example.
   2. Locate the plural and singular object nodes, and open the singular node. For the example, open Account.
   3. Open the Templates subtab.
   4. Select Create Template.
   5. Enter a name and ID, and select Create.
   6. Switch to Code mode and define the template for the required behavior.

   The source provides the following example for displaying a field in red text:

   <template id="redTemplate">
   <div styles"color:red;">
   <oj-bind-text value="[[ $value |]"></oj-bind-text></div>
   </template>

3. Add a field template map:
   1. Open the Rule Sets subtab.
   2. Locate the existing Dynamic Table entry named Adaptive List. For Accounts, the source identifies it as Accounts Adaptive List.
   3. Duplicate the existing layout and edit the duplicated entry.
   4. Open the JSON subtab.
   5. Locate the layout entry under AdaptiveListLayout.
   6. Add the fieldTemplateMap property within layout.
   7. Associate the field with the template. Use the Adaptive Search REST field name as the field name.

   "fieldTemplateMap": {
   "AccountName": "redTemplate"
   }

Configure a Custom Field Template for a Custom Object

For custom objects, the source adds service connection, layout, and rule set configuration before the field template map is applied.

Use this procedure to configure a field template for a standard object in Visual Builder Studio.

1. Get the service connection:
   1. Open CX Extension Generator and create a new extension.
   2. Include the custom object for which you want to enable custom field templates. The source uses ZEM_Auto2 as an example.
   3. Open Visual Builder Studio and import the new extension file.

   The source states that this creates a service connection named cx_custom_adaptive_search if it doesn't already exist.

2. Enable field templates for the page:
   1. Navigate to the list page on which you want to enable the custom field template. The source uses zem_auto2_c-list as an example.
   2. Open the Variables tab.
   3. Locate the advancedConfiguration constant.
   4. Change enableTemplates from false to true.

      {
       "enableTemplates": true
      "layoutId": "AdaptiveListLayout",
      "serviceConnectionId": "site_cxsales_Extension:cx_custom_adaptive_search"
      }

3. Create a layout:
   1. Open the Layouts tab.
   2. Select the + icon to create a layout.
   3. Under Services, expand the cx_custom_adaptive_search node.
   4. Locate the /data/object entry. The source example is /data/ZEM_Auto2_c.
   5. Select the entry, and select Create.
4. Create a field template:
   1. In the new layout, open the Templates subtab.
   2. Select Create Template.
   3. Enter a name and ID, and select Create.
   4. Switch to Code mode and define the template for the required behavior.

   The source provides the following example for displaying a field in blue text:

   <template id="myRecordNameTemplate">
   <span style="color:blue">
   <oj-input-text value="{{ $value }}" label-hint="[[ $label-hint ]]" valid="{{ $fieldValid }}"></oj-input-text>
   </span>
   </template>

5. Create a rule set:
   1. In the new layout, open the Rule Sets tab.
   2. Select Create Rule Set.
   3. Select Dynamic Table as the component.
   4. Enter AdaptiveListLayout as the ID.
6. Update display properties and add a field template map:
   1. Open the JSON subtab.
   2. Locate the layout entry under AdaptiveListLayout, and locate displayProperties.
   3. Set displayProperties to the following value.

      "displayProperties": "{{ $componentContext.dynamicFields }}"

      The source states that this gets metadata from saved searches and displays it in the table at runtime.

   4. Within layout, after displayProperties, add the fieldTemplateMap property.
   5. Associate the field with the template. Use the Adaptive Search REST field name as the field name.

      "fieldTemplateMap": {
      "RecordName": "myRecordNameTemplate"
      }

Overview of Predefined Field Templates

There are 3 predefined field templates as follows:

• adaptiveTemplate
• actionMenuTemplate
• hyperlinkTemplate

For standard objects, predefined templates are available for DCL, FCL, drill down, and actions fields. For custom objects, specify templates for fields that need behavior beyond plain text.

The following outlines a brief description of what each field template provides:

Name	Description
adaptiveTemplate	Use to display FCL fields correctly. The source identifies these behaviors: Single-select FCL fields show meanings instead of codes. Multi-select FCL fields show multiple values separated by semicolons. Record Type fields show the meaning of record type values, such as Primary Industry on Account.
actionMenuTemplate	Add an Actions Column Add an Actions column to a field as follows: Add an entry for the actions menu template in fieldTemplateMap. "fieldTemplateMap": { "actionsMenu": "actionMenuTemplate" } Add the following entry to the Fields JSON. Provide the primary key field, Id in the source example, in value and referencedFields. { "addField": { "actionsMenu": { "type": "string", "labelHint": "Actions", "readonly": true, "value": "[[ $fields.Id.value ]]", "referencedFields": [ "Id" ] } } }
hyperlinkTemplate	Add a Drill Down Link To add a drill down link to a field: Add an entry in fieldTemplateMap for the display attribute field of the same object or the target object of the DCL. "fieldTemplateMap": { "RecordName": "hyperlinkTemplate", "PrimaryAccount.PartyUniqueName" : "hyperlinkTemplate" } RecordName is the display attribute of the same object. PrimaryAccount.PartyUniqueName is the display attribute of Account, which is the target object of a DCL field.
	Configure a Link that Drills Down to the Same Object To configure a link that drills down to the same object, specify dependentFields in the Fields JSON: Open the Fields tab of the custom object. Select the RecordName field in design mode and make a small change that can be undone later. The source example is to set the Required flag to true. This generates boilerplate code in the JSON file. Switch to the JSON tab. In the replaceMetadata block, add the following metadata for Record Name. "replaceMetadata": { "RecordName": { "dependentFields" : ["Id"] } } Return to design view and clear the Required flag if it's not needed.
	Configure a Link that Drills Down to a Different Object To configure a DCL link that drills down to a different object, specify dependentFields and x-target-resource in the Fields JSON. The field must be the display attribute of the target object as defined in Adaptive Search. For a custom object, the source identifies this as Record Name. For a standard object, the source states that you can get the display attribute from the entities REST call by locating displayAttribute for the object. dependentFields takes an array containing the ID and PUID fields of the reference object. x-target-resource takes the following parameters: name — REST resource name of the reference object. sourceFKField — field that stores the ID field of the reference object. sourcePuidfield — field that stores the PUID of the reference object. Open the Fields tab of the custom object. Select the DCL field in design mode and make a small change that can be undone later. The source example is to set the Required flag to true. Switch to the JSON tab. Add the required replaceMetadata entry. For a DCL to another custom object such as ZPSObject, see this example: "replaceMetadata": { "ZPSObject_Id_c.RecordName": { "dependentFields": ["ZPSObject_Id_c.Id", "ZPSObject_Id_c.RecordNumber"], "x-target-resource": { "name": "ZPS_Auto2_c", "sourceFKField": "ZPSObject_Id_c.Id", "sourcePuidField": "ZPSObject_Id_c.RecordNumber" } } } For a DCL to a standard object such as Account, see this example: "replaceMetadata": { "Account_Id_c.PartyUniqueName": { "dependentFields": ["Account_Id_c.PartyId", "Account_Id_c.PartyNumber"], "x-target-resource": { "name": "accounts", "sourceFKField": "Account_Id_c.PartyId", "sourcePuidfield": "Account_Id_c.PartyNumber" } } } Return to design view and clear the Required flag if it's not needed.