FormulaShare always runs with sharing and fully respects the running user's record-level access. This is a Salesforce security requirement and ensures FormulaShare cannot share records a user wouldn't otherwise be able to see.
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:
- 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.
FormulaShare queries fields on shared objects in system mode during batch processing, so the batch running user does not need explicit field-level security access to the fields referenced in your rules.
Permissions for Real Time Sharing
When using triggers or flows to apply real time sharing, FormulaShare queries the fields referenced in your rules in system mode, so the running user does not need field-level security access to those fields. The running user does need 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) and the running user is missing any sharing access, FormulaShare will simply not identify the additional sharing which would otherwise be applied, 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.