FormulaShare always runs with sharing and fully respects the running user’s permissions. This is a Salesforce security requirement and ensures FormulaShare cannot expose data a user wouldn’t otherwise be able to access.
Accordingly, there are some considerations around permissions required by the users carrying out FormulaShare batch and real time operations.
Permissions for Batch Jobs
The full and targeted calcuation jobs must run as a user with the following:
- Read access to all objects and fields referenced explictly in your FormulaShare rules
- Sharing access to any records relevant to the assessment
- Modify All access to the shared objects being processed
The final requirement is necessary because "full access" is required to make changes to a record's underlying sharing table.
Permissions for Real Time Sharing
When using triggers or flows to apply real time sharing, for changes to be made the running user needs to have:
- Read access to the objects and fields referenced in the FormulaShare rules which involve the created or updated record
- Sharing access to any other records relevant to the assessment (e.g. read access to parent records if your rule shares based on parent fields)
When running in a Transaction Safe context (the default mode for triggers and flows), there are no absolute permission requirements. If the running user is missing any permissions, FormulaShare will simply not identify the sharing changes which would require this particular permission, and the expectation would be that this sharing is applied at a later point by a batch process.
When triggering Full Assessment for specific records using apex or flow, these permission requirements may be more important. If standard objects configured as Fully Managed in Object Settings, FormulaShare will remove existing sharing which doesn't match sharing of records which can be queried by the running user. For this reason, if requesting full assessment in this way it's important to ensure appropriate permissions and sharing are in place for the users which will trigger these operations, otherwise valid sharing could be incorrectly removed because the running user couldn’t query all the necessary records.
Inserting and deleting record shares
When called from apex or flow FormulaShare returns the records that should be inserted or deleted, it does not insert or delete them directly. For this reason record share insertions and deletions should always be performed in a “without sharing” context.
- Record-triggered flows and apex triggers run in this mode by default
- If you’re calling FormulaShare from custom apex or custom flows, ensure they’re explicitly configured to run without sharing
Platform Event Workaround for Real Time Scenarios
If limited permissions prevent FormulaShare from detecting sharing changes needed in a real time context, a useful workaround is to utilise a platform event to force the transaction to run in system mode.
Take the following steps to configure this if required:
- Define a custom platform event with a field which can be populated with a record ID (or a delimited list of record IDs).
- Configure a record-triggered flow or apex trigger logic which publishes platform events containing the record IDs for FormulaShare to assess.
- Create an apex event trigger or an event-triggered flow to query for the records, call FormulaShare and insert and delete sharing in response to platform events being raised.
That works because FormulaShare then runs as the Automated Process system user, which has the necessary elevated access. This isn't generally needed for transaction safe contexts because on the whole we're typically checking fields and the running user would have access to anyway.