Assess From Apex Triggers

Trigger code for real time rules

To set up real time assessment, the following code should be called during processing of the shared object’s after trigger (either directly or from a class called by the trigger):

    sdfs.FormulaShareHelper helper = new sdfs.FormulaShareHelper();
    insert helper.getSharesToInsert();
    delete helper.getSharesToDelete();

The first line initiates assessment of sharing changes. The insert and delete statements make the actual updates to share records of this object and any parent object affected by the change.

 

A simple example

In the code snippet below, the simple apex trigger calls FormulaShare, and adds or removes sharing where necessary each time donations are created, updated or removed:

    trigger DonationTrigger on Donation__c (after insert, after update, after delete, after undelete) {
        sdfs.FormulaShareHelper helper = new sdfs.FormulaShareHelper();
        insert helper.getSharesToInsert();
        delete helper.getSharesToDelete();
    }

This kind of trigger is usually fine provided there's no other triggers or complex automation on this object. If you're an admin working with developers in the same org it's recommended to check that this approach is consistent with other code in the org.

If implementing a trigger in this way, a corresponding test class like the one below is needed to give full code coverage:

    @IsTest public class DonationTriggerTest {
        @IsTest
        public static void testInsert() {
            Donation__c d = new Donation__c();
            insert d;
            System.assert(d.Id != null);
        }
    }

Note that this will work only if the shared object does not have any mandatory fields - additional lines may be needed depending on the object you're working with.

 

Working with existing code

The above is an illustration of a simple implementation where no other trigger code exists, no trigger helper (or handler) is used.

If trigger helper classes or a trigger framework is used in your org, code to call FormulaShare methods can be added to an appropriate place in the methods managing record inserts or updates. As Salesforce requires Modify All access to change records in the underlying share objects, the lines of code insert helper.getSharesToInsert(); and delete helper.getSharesToDelete(); should run without sharing unless you're sure that users making changes already have this level of access.

Note that FormulaShare will assess whether changes to sharing are required based on the values of fields at that point in time, and will only proceed to add or remove sharing when necessary. This means it’s not necessary to check for specific field changes in your own code before calling FormulaShare.

 

Technical overview

For developers wanting to know a bit more about the actions taken during trigger processing, an summary of what happens during the call to the constructor FormulaShareHelper() is below:

  • FormulaShare checks that it's being called in a trigger's After context, and only proceeds if so
  • Trigger context variables are checked to identify the object being created, updated or deleted
  • The FormulaShare Rules custom metadata is checked for any valid active rules involving the object in scope
  • The old and new versions of the record from trigger context variables are checked to identify whether anything has changed which might impact sharing:
    • For new records, fields involved in rules are checked and if any are populated, assessment will continue
    • For updated records, fields which might impact sharing (either fields involved in rules, or the record owner) will be checked to see whether they've changed
    • For deleted records, fields which might impact sharing of the parent record for related object rules will be checked
  • Any records identified as possibly needing sharing updates will be collected for processing
  • Queries will be made for all existing sharing on these records
  • Depending on the rule type, queries may also be needed to retrieve ids of the roles or groups needing access
  • Comparisons will be made of any existing sharing with sharing which is now required, and lists are populated of all sharing which needs to be created or removed. These are the lists returned in the getSharesToInsert() and getSharesToDelete() methods
  • Platform events are fired with details of the sharing which is expected to be inserted or deleted. These events are detected by a trigger internal to FormulaShare which carries on the creation of log records in a separate transaction context

Since FormulaShare is an approved managed package, it's given its own governor limits so won't contribute to most transaction limits which apply to your own code (number of SOQL queries, number of DML statements etc).

Details around which changes can and can't be identified through real time processing are explained in the rule types and application section.