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, i.e. when record triggered flows or triggers run, in certain situations.

When it comes to real time 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 Parent Based on Child Value
Example: Share Campaigns to Opportunity Owners 

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 not 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 Child Based on Parent Value
Example: Share Opportunities to Campaign's Marketing Team

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 Child
Example: Share Accounts to Product Specialists

For rules where the record to be shared is related to the record with the sharing field via a common child record related via a series of lookups, the real time scenarios which are covered by transaction safe trigger or flow automation are equivalent to those described in the "Share Parent Based on Child Value" section above.

In our examples, this applies to the rule which shares Accounts to the related Product Specialist on Product:

Application of sharing will only be carried out in response to insert or update of Opportunity Line Item records - new sharing would be created on the grandparent Account record when an Opportunity Line Item is inserted, or after it is updated to relate to a new Opportunity or Product.

All other sharing changes required in response to other record changes would be implemented asynchronously by either a full or targeted batch. In this example this would include updates to the Opportunity lookup, or updates to the Product Specialist field on Product.
 

Share Based on a Common Parent

Where sharing of a record is based on a relationship where the record to be shared and the record with the sharing field are related through a common parent record, sharing will not be applied in real time using transaction safe triggers or flows.

The reason for this 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.
 

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.