Hierarchical – Understanding Salesforce sharing and security – Salesforce Data Architect Theory – Salesforce Certified Data Architect Study Guide

Hierarchical

Only available on the user object, a hierarchical relationship is a special type of lookup to associate one user to another (where the record does not directly or indirectly refer to itself). Storing a users manager as a lookup to another user record is a common use-case for this functionality.

Now we know the different ways in which we can relate objects and their data to each other, let’s look at what happens when performance is affected by relating too many records to a single ancestor record or user.

Custom hierarchy (parent/child) relationships

It is possible to create custom parent/child hierarchies by utilizing a custom Sub object that does a double lookup (of type lookup relationship) on the object you wish to create the parent/child relationship for. One lookup has a name format of Parent, the other Sub. For example, to create a parent/child opportunity relationship, create a custom object called SubOpportunity with a lookup called ParentOpportunity and another SubOpportunity that both look up to the opportunity object. This is explained in more detail athttps://help.salesforce.com/s/ articleView?id=000326493&type=1.

Overcoming data skew

Automatic scaling is an expected feature of the Salesforce platform, particularly as the count of records for a particular object increases. Customers will demand a consistent level of performance when tens of thousands of records of the same type are present within the system. There are a couple of performance degradations that happen in a couple of select use cases. These are as follows:

• A user owns more than 10,000 records of the same type (such as a user owning over 10,000 account records). This isknown as ownership skew.

• A single account record has a large number of child records, such as 10,000 or more contact records with the same account as their AccountId lookup. This is known asaccount skew.

• Similar to account skew, when a large number of child records (10,000+) are associated with the same parent there can be performance problems. This is known aslookup skew.

We’ll look at the causes for each of these and how they can be mitigated.

Ownership skew

When a single user or queue is the owner for more than 10,000 records of a particular type (such as contact), then performance issues due to ownership skew may arise. In Salesforce instances, it is very common to have a default user or queue that owns all otherwise unassigned or unused records. Changes to sharing settings or other sharing-related operations affect performance because re-calculating sharing based on a change of role for the owning user or another sharing- related calculation will result in a long-running Salesforce operation, locking the records while this operation takes place.

Ownership skew mitigation

To mitigate ownership skew, consider the following:

• Based on the data projections for large amounts of records that will result in a single owner (such as a default owner for lead records), consider having multiple owners for such ownership scenarios. Assignment rules are available for leads and cases (standard objects that tend to have high volumes), but other automation techniques are available to assign records based on the criteria of the record to an appropriate owner.

• If one user must be used, performance impacts can be reduced by not assigning the user to a role. This removes any role-based impacts from sharing calculations.

• If the owning user must have a role, then that role should exist at the top of the role hierarchy. The user therefore will not need to be moved around the hierarchy, reducing the impact of sharing calculations being a long-running process.

• Ensure any owning user is not a member of a public group that is used in the criteria for any sharing rules. If this is the case, changes to the record owner will trigger re-calculations of those sharing rules also, further slowing things down.