Sharing Architecture & Performance

Your sharing model is also a performance model

JSBC Labs29 September 20268 min read

Access decisions have a processing cost

Salesforce sharing is usually discussed as a security configuration: set organisation-wide defaults, create roles and add sharing rules until the right people can see the right records. That description is correct but incomplete. The platform must also maintain ownership, group membership and share relationships as records, users and organisational structures change.

A model can be logically correct and still be operationally expensive. Deep hierarchies, overlapping rules, catch-all owners and heavily nested groups increase the work required to calculate and maintain access. The practical design question is therefore not only ‘Who should see this record?’ It is also ‘How many access paths must Salesforce maintain, how often will they change, and what happens at production volume?’

Choose the baseline deliberately

Organisation-wide defaults establish the baseline record access for each object. Sharing features then open access beyond that baseline; they do not make a broadly visible object more restrictive for selected users. A Private default can protect sensitive records but may require many additional access grants. Public Read Only or Public Read/Write can simplify collaboration but may expose more data than policy permits.

Do not default every object to Private because it sounds safest, or make everything public because it performs simply. Classify the data, identify the owner, model legitimate collaboration and quantify the exception population. Use the least restrictive baseline that still satisfies the security requirement. Every exception above that baseline becomes part of the sharing workload and the organisation’s explanation of access.

The role hierarchy is a data-access structure

A Salesforce role is not a job title. It represents a level of record visibility. Mirroring every title, grade and reporting nuance from the HR organisation chart creates unnecessary levels and churn. Salesforce guidance recommends consolidating titles into one role when access is the same and minimising hierarchy depth for easier maintenance and better performance.

Model stable visibility boundaries: who needs access to records owned by people below them, and where should that inheritance stop? Review reorganisations as data-access changes, not clerical user maintenance. Moving a user who owns many records, or changing a role used by sharing rules and groups, can initiate substantial access recalculation. The design should tolerate ordinary organisational change without becoming a platform event.

Sharing rules should describe durable exceptions

Sharing rules extend access based on ownership or record criteria. They work well when a clear population of records must be visible to a stable population of users. Problems appear when rules accumulate as tactical fixes: two rules grant the same access through different groups, a rule duplicates the hierarchy, or criteria depend on volatile data that changes constantly.

Maintain a catalogue of each rule’s business purpose, source population, target population, expected volume and owner. Remove redundant paths and consolidate target groups where the access outcome is identical. Use public groups for reusable access populations, but avoid unnecessary nesting and frequent membership changes. A smaller number of explainable paths is easier to troubleshoot and cheaper to recalculate.

Ownership is part of scale architecture

Record ownership drives access, hierarchy inheritance and many sharing rules. Assigning millions of records to a generic Integration User, Migration User or Unassigned queue may simplify a data load, but it concentrates future work. Salesforce identifies ownership data skew when a single user or queue owns more than 10,000 records of an object and warns that role or group changes involving that owner can cause performance issues.

Use real operational ownership where it is meaningful. If records cannot belong to individual users, design a distribution strategy across stable owners or queues and understand how each owner participates in the hierarchy. Where a highly skewed owner is unavoidable, Salesforce recommends isolating it from volatile hierarchy and group structures. A placeholder owner is an architectural decision, not harmless housekeeping.

Parent-child shape changes access work

Skew also appears when many child records point to one parent. Salesforce guidance calls out configurations with 10,000 or more children under one parent as a common source of slow updates, uploads and lock contention. The platform may need to protect the parent and evaluate access while child ownership or relationships change.

Review data shape alongside sharing design before large imports and integrations go live. Watch high-volume accounts, shared reference records and synthetic catch-all parents. If the relationship exists only to simplify reporting or integration, consider whether a different model can avoid the hotspot. When concentration is required, partition work, schedule it away from peak activity and test with production-shaped distributions.

Bulk data changes are sharing changes

A bulk operation does more than write fields. Inserts, ownership transfers, reparenting and group membership changes can create or remove access. A load test that measures only API throughput misses the time spent on sharing calculations, hierarchy effects, locks and downstream visibility. Successful submission is not proof that the org has reached a stable access state.

Include sharing in migration and integration plans. Sequence reference data, owners, users, roles and groups before business records depend on them. Measure lock errors, recalculation duration and the delay before representative users receive expected access. Salesforce provides deferred sharing calculation capabilities for eligible high-volume maintenance, but deferral creates a controlled inconsistency that must be resumed and fully recalculated promptly.

Treat sharing changes as releases

Changing an organisation-wide default or sharing rule can trigger asynchronous recalculation. Salesforce notes that some related sharing settings cannot be changed while recalculation is in progress. A seemingly small configuration update can therefore create a long-running background operation, delay later changes and alter what users can see across a large dataset.

Plan the change with impact estimates, a low-activity window, validation users and stop conditions. Capture baseline access for representative personas and sensitive records, then test during and after recalculation. Communicate expected visibility changes to operations and support. A green deployment status means the metadata was accepted; it does not mean every resulting share has been calculated or every user experience verified.

Custom sharing is not a shortcut around the model

Manual sharing and Apex managed sharing are appropriate for record-specific access that standard rules cannot express. They also create share rows that need ownership, lifecycle and reconciliation. Code that inserts shares without a stable reason, removes them incorrectly or recreates access already granted elsewhere produces both security ambiguity and operational noise.

Define the share reason, authoritative source and revocation event. Make the operation bulk-safe and idempotent, and reconcile expected shares against actual access. Test what happens when ownership changes, users are deactivated or the organisation-wide default changes. Salesforce can remove sharing that becomes redundant after a broader default is introduced, so custom access logic must be designed around platform recalculation rather than assuming rows are permanent.

Test the model at organisational scale

Security tests should prove that allowed users can access records and forbidden users cannot. Performance tests should add the dimensions administrators change in real life: large owners, nested groups, role moves, acquisitions, territory adjustments, partner populations and bulk reassignments. Measure both steady-state interactions and the cost of change.

The JSBC Labs view is that a sharing model is healthy when access is correct, explainable and resilient to growth. Start with a justified baseline, keep hierarchies and rules simple, avoid ownership and relationship skew, and operate recalculations as controlled releases. Record security is not separate from performance engineering; the access graph is part of the workload the platform must execute every day.