Hierarchical relationships

Hierarchical relationships are an exclusive property of the User object, and they are used to relate users to each other, following a hierarchy.

When creating a custom field on the User object, no other relationship is available other than the hierarchical relationship:

Hierarchical Relationship field type on the User object

This special kind of lookup is used to select only users above a hierarchical level—that is, users who do not directly or indirectly refer to themselves (so my parent user must not be a parent user for one of my child users). The following relation between users is therefore not allowed because Gustav is the manager of Giuseppe, who is himself the manager of Gustav:

A misconfiguration of a hierarchical lookup setup between users

Formula fields and relations

We can define formula fields that reference related objects (from child to parent only, not vice versa). They are called cross-object formulas.

The following is an example of a custom formula field that shows the case’s subject on the case detail record:

Case__r.Subject + ‘(‘ + Case__r.RecordType.Name +’)’

This formula field will display the parent case’s Subject field and the case record type’s name:

Cross-object formula example

We can reach a grandparent object that is 10 levels away from the current object.

Think about the account’s Parent field. You can create a hierarchy of accounts and you can reach into a custom formula from a child Account to the fields of a parent Account that is the fourth parent.

We can create up to 10 unique relations between a child object and related objects.

This means that if you have 15 different lookups on a given record, you can reference at most 10 different object types in the child object formulas. This limit applies to formula fields, but also formulas on rules (such as workflow rules or validation rules) and lookup filters.

External relationships

We’re not covering external data sources and external objects in this book, but it is useful to know the concept of external and indirect lookups.

External data sources are a way to define a connection between Salesforce and a legacy system where business data is stored, but it has been decided not to migrate that data inside Salesforce. The reasons behind this choice are that external data may only be historical data that service agents only need to read when necessary (thereby not counting vis-ˆ-vis overall storage limits) or frequently changing data that does not interfere with CRM data, but that is necessary to access when dealing with your customers.

External data sources rely on a technical connection between Salesforce and the legacy system (usually, we talk about the OData protocol) and this is setup to allow Salesforce to access external databases defining external objects, which are a Salesforce representation of those tables within Salesforce (again, data is not stored in Salesforce but using those technical protocol records, which may be accessed in the same way as a normal Salesforce object).

External lookups are then used to link a standard or custom Salesforce object to an external object: this is usually done using an external ID field on the Salesforce object that matches a corresponding field on the external object dataset.

Indirect lookups are lookups defined from an external object that points to a standard or custom Salesforce object, using an external ID/unique field on the parent object to match the link.

For more details about external data sources and external objects, refer to Salesforce Help at https://help.salesforce.com/articleView?id=external_data_sources.htm&type=5.