Joins and Join Fields

A join is a predefined association between an object and its related object. Joins use underlying, preexisting relationships already delivered with your cloud service. You use joins to add related object fields to an object's work area.

Before you can do that, however, you must register those fields, either custom or standard, by creating join fields. (Join fields aren't provided automatically for you.)

Understanding Joins

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

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

Why Use Joins?

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

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

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

Choosing a Join

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

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

Customer Contact Profile
Forecast Item
Opportunity
Partner
Product Group
Program Enrollments
Sales Account

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

Registering Join Fields

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

To register a join field:

Expand an object and click the Joins node.
Click the join name to navigate to the Join Fields page, where you can register join fields.

Working with Join Fields

Once you have registered a related object field as a join field, you can then show or hide those fields on an object's work area by using the configuration pages available from the object's Pages node. There are some caveats about working with join fields, listed below.

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

However, you can still filter the records that display in an object's summary table by using the Query By Example feature. At runtime, click the Query By Example icon on the table's toolbar, and enter a value for the join field column.
Fields configured for an object as a join field don't appear in file-based import and bulk export.
Join fields are computed attributes, and exist only at runtime. This is a transient type of attribute which doesn't persist in the database as a table column. Hence, there is no maximum number of join fields for an object.
Generally, a join field on a record is automatically updated when a user updates that field elsewhere on the record. For optimal performance, however, this automatic update doesn't happen on Opportunity and Lead pages.

For example, let's say a user adds a new contact to an opportunity and saves the opportunity. Then, still on the Contacts subtab, the user adds a primary phone number. After saving the record, the Primary Phone field (the join field) on the opportunity's Summary tab doesn't automatically update. To see the new telephone number on the Summary tab, the user must requery the opportunity.