Cross-Object Rules

Cross-object rules are rules where the field which determines sharing is on an object related to the one which is shared:

The rule above is quite simple - Programmes will be shared to entities specified on child Donation records - however cross-object rules can be much more complex, traversing multiple lookups in either direction.

FormulaShare will allow for up to 5 levels of consecutive parent or child relationships, and these can be followed by up to 5 relationships in the opposite direction meaning the controlling record can be up to 10 relationships away.

Assessment of Sharing

The full recalculation batch and Targeted Calculation Jobs will always apply the latest sharing to all processed records for these rules, however FormulaShare will only attempt to assess sharing changes in real time when triggers run in certain situations.

When it comes to trigger processing, above all else FormulaShare will try to ensure there is little or no risk of affecting other automation on the object or the ability to save a record. As with standard rules, the principle applied is that FormulaShare will only try to recalculate sharing in circumstances where there is no likelihood of querying large numbers of child records.

To understand circumstances where FormulaShare will and won't process records in real time, consider the rules below:

These rules relate to the standard data model (with a custom text fields) below:

To help illustrate all considerations around removing sharing, we'll assume that all shared objects have a Removal Strategy of "Fully Managed" configured in Object Settings.

Let's look at each of these rules in turn to consider which trigger operations will lead to sharing changes.
 

Share Child Based on Parent Value
Example: Share Opportunities to Campaign's Marketing Team

Consider the scenarios below:

Sharing will be applied as below (note this assumes trigger code is configured on the child object, Opportunity in this example):

1. Creating a new child record: Sharing will be applied to the parent right away - Summer Prospects will be shared to Ada Atkins
2. Updating the sharing field in a child record: The parent will be shared with the new entity (Cherry Cole in this example), however sharing won't be revoked from the entity which was previously on this record (Billy Brown in example above)
3. Moving a child from one parent to another: Sharing will be granted for the new parent right away, however sharing won't be revoked from the old parent, so both campaigns will be shared with Dale Dawkins in the example
4. Deleting a child record: Sharing won't be revoked from record which was previously the parent of this record, so the Summer Prospects campaign will still be shared with Ellie Evelyn in the example above

For simplicity, an example with a single child to parent relationship is shown, however the principles are the same when parent and child are linked by intermediary objects (i.e. sharing is based on records which are grandchildren, great-grandchildren etc). In these scenarios, changes to intermediary objects will result in real time changes to parent sharing, even if triggers are set up on the intermediary objects.

Any sharing changes which weren't carried out in real time will be assessed and applied the next time the full batch or a targeted calculation job runs.

Share Parent Based on Child Value
Example: Share Campaigns to Opportunity Owners

Sharing will be applied as below (note this assumes trigger code is configured on the child object, Opportunity in this example):

1. Creating a new child record: Sharing will be applied to the child right away - the opportunity will be shared to the Social marketing team
2. Updating the sharing field in a parent record: Sharing on child records won't be updated (even if a trigger is set up on Campaign)
3. Moving a child from one parent to another: Sharing will be granted for the new entity and revoked from the previous entity right away, so in the example opportunity access will be added for Video and removed for Social marketing teams
4. Deleting a parent record: Sharing on child records won't be updated (even if a trigger is set up on Campaign)

If there are intermediary objects between the shared and controlling object (so children are shared to the grandparent, great-grandparent etc), then changes to the intermediary objects will not result in real time changes to the child object sharing, even if triggers are set up on the intermediary objects.

Any sharing changes which weren't carried out in real time will be assessed and applied the next time the full batch or a targeted calculation job runs.

Share Based on a Common Parent or Common Child
Example: Share Accounts to Product Specialists

For rules involving a change of direction in a sequence of lookups (i.e. where objects are related by a mixture of parent-to-child and child to parent relationships), no sharing will be applied in real time by triggers. In our examples, this applies to the rule which shares Accounts to the related Product Specialist on Product:

The reason for this limitation is that in all circumstances FormulaShare would need to query one or more child relationships to determine the correct sharing, and when large numbers of child records are related to parent objects this could impact trigger performance or breach Salesforce SOQL limits.

Near real-time sharing for rules of this kind is possible in FormulaShare Enterprise and Unlimited by configuring Targeted Calculation Jobs.

In some circumstances it's possible to partially mitigate this by using formula fields to simplify the relationship in the rule. In the example above, a formula for Product Specialist could be created on the Opportunity Line Item, and trigger code added to this object to enable real time sharing in the scenarios described above (Share Parent Based on Child Value).

Custom Metadata Rules

Note that custom metadata rules, whilst technically cross-object rules, will not be subject to any query limitations for the final custom metadata relationship. This means, for example, that a rule where the shared object is related to the custom metadata type through a field on the object itself, assessment in triggers and flows following changes to the shared object will always be assessed as per standard rules.

Any changes to values in custom metadata records which include the users, roles or groups to receive access are not assessed in real time, but will be applied as part of the next full or targeted batch run.