It's All About the Platform.

How To Create Handy Reference Data Sections On Object Pages

Richard Bingham
Senior Development Manager

Customizations are rarely standalone features which operate in isolation to the rest of the application, they usually need to include contextual information for users to be able to take accurate decisions. In fact many customizations are simply additions and enhancements to the core features, and having access to related data is essential. So let's consider some options to support this using customizations done in Oracle Sales Cloud, using Application Composer.

Something seen in the Opportunities and Accounts standard pages is the use of Sub Tabs. As below there are different types you can add to your custom layouts.

The first, the "Related Object" option, uses existing relationships between the object-in-focus and other objects in the system. This, however, does not allow you to reuse the relationships created using Dynamic Choice List fields. To use the Related Object option you must create an explicit (new) Relationship. Once created your users then have to explicitly associate records inside the sub-tab itself - meaning it does not provide an option for displaying context data for records which may be already associated.

Another option is to use the "Context Link" subtab type. Here at design-time you specify the criteria to use to query the data for display. We looked at this feature in detail in this article. This can work in some cases, however the query does not work on a Primary Key - Foreign Key relationship and as such you end up querying records based on Strings (such as names), which may be duplicated or slightly mismatched. As such this also may not always be suited for displaying extra contextual information.

The final option - and the focus of this article - is not to use a sub-tab at all, but to have a Field Group on the layout which contains Formula fields. Each of the field use an implicit relationship created by a Dynamic Choice List as part of the object. Let's illustrate this using an example; a Specialist (custom object) is a record which identifies a person (Resource) who works closely with a particular customer (Account). The specialist record has a few fields of its own as supplemental data, however is essentially holding the relationship between Account and Resource standard objects. When users view the Specialist records, they want to also see the contact data from the associated Account record. This allows them to have all the people involved on one screen, for use in setting up meetings and sales calls. The following shows the fields which make up the Specialist custom object.

Notice that each of the Contact XXXX fields are Formulas. These simply leverage the Dynamic Choice List (which I unimaginatively called 'Account') which lists values from the Account object (OrganizationProfile). The Formula fields pull data from the Primary Contact and Preferred Contact fields on the Account object. The expression used for the formulas are like this:

 return nvl(ObjectB_Obj_c?.myField_c,'No data');

As you can see the "_Obj_c" extension represents the relationship between the primary object and the secondary object as defined by the Dynamic Choice List. Read more on relationships here. As you can see using nvl() function prevents empty spaces on the resulting form (and potential NullPointerExceptions raised when the value is used in further calculation). Here is a real example taken from the Specialist object.

Two items of note here:

  • Don't forget to set the Depends On list of values to the Dynamic Choice List value that controls the relationship. This ensures it updates the fields if it should get altered on the page.
  • Ensure the Formula Type (Text, Number, Date) matches the source field your are using (e.g. PreferredContactEmailAddress above), else you'll get format problems and errors.

Finally rather than displaying these contextual fields inline with the other object fields, it makes sense to put these together in a Field Group. As shown below this is easily done within the sub tab configuration page. Here can also also define collapse the group by default, meaning users only expand the group to see the fields if needed - a good space saving option.

The resulting page looks like this, where the header has the core data and contextual data is in the expandable field group. Obviously going beyond just displaying existing values, you could use the formula fields to perform calculations on the referenced values, such as displaying specialist 'fees' that are reduced using the discount rates currently setup for that specified account.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.