Record Access, Sharing & Security Architecture

Your Salesforce sharing model is an access graph—not an org chart

JSBC Labs6 November 20268 min read

The role hierarchy is only one edge

A regional manager can see an Opportunity even though no sharing rule appears to target them. A service analyst cannot see a Case that a public group supposedly grants. An integration returns records that the user interface hides. Teams often respond by adding another role, rule or permission until the immediate complaint disappears. The result works today but nobody can explain the effective access path.

The JSBC Labs position is that Salesforce record access is a graph. Users and groups are principals; records and owners are resources; hierarchy inheritance, rules, teams, manual shares, Apex shares and broad permissions create edges. Restriction rules can remove results after access is granted. The organisation chart may inform that graph, but it does not describe it. Secure design starts by making every intended access edge explicit.

Separate permission from visibility

Object permissions answer whether a user can read, create, edit or delete that type of data. Field-level security answers which fields are available. Record sharing answers which individual records are visible. A user needs the necessary permission and an applicable record-access path. Salesforce also documents View All Records and Modify All Records as permissions that bypass sharing for a specific object, while View All Data and Modify All Data are broader still.

Do not use a sharing rule to compensate for missing object permission, or a broad permission to avoid designing record access. Write access requirements in layers: the persona can read Opportunities, can see these fields, and can access records owned by these populations under these conditions. This prevents administrators from solving a visibility problem with Modify All and accidentally granting transfer, delete or approval capabilities that the business never requested.

Start closed, then add named access paths

Salesforce recommends using organisation-wide defaults as the baseline and opening access selectively. Private or Public Read Only defaults make the intended grants visible through ownership, hierarchy, sharing rules, teams or code. Public Read/Write can be valid for genuinely collaborative data, but it removes the platform's ability to distinguish many access populations. Choose the baseline from data sensitivity and collaboration needs, not configuration convenience.

Treat each sharing rule as a policy statement with an owner, rationale and expiry condition. Name the source population, target principal, access level and business reason. Prefer stable public groups or well-defined role branches over repeating near-identical rules for individual users. Restriction rules are different: Salesforce applies them after access mechanisms to filter the records a user can work with. Document subtraction separately so reviewers do not assume every grant produces visibility.

Model ownership as operational responsibility

Ownership is not merely a required lookup. It provides a primary access path and often drives hierarchy inheritance, sharing rules, queues, assignment and reporting. Decide whether the owner represents accountability, active workload, commercial responsibility or simply a technical holding state. If one field is expected to mean all four, teams will move ownership for operational reasons and unknowingly change security.

Use queues where work is genuinely pooled and define how members claim or retain records. Avoid parking large populations under one dummy user. Salesforce identifies ownership data skew when a single user owns more than 10,000 records and warns that hierarchy or group changes affecting that owner can require extensive sharing maintenance. Distribute ownership where practical, and design inactive-user, territory-change and bulk-transfer procedures before they become urgent production events.

Choose durable grants over convenient exceptions

Manual sharing is useful for exceptional collaboration, but it is poor policy infrastructure. It depends on individual action, is difficult to review at scale and can be removed when ownership changes. Teams are stronger when the collaboration relationship is part of the record's operating model. Criteria-based or owner-based sharing rules are stronger when a stable population and recipient group can express the requirement.

Use Apex managed sharing only when declarative features cannot represent a dynamic business relationship. Salesforce share objects record the recipient, access level and RowCause. For custom objects, Apex sharing reasons let code preserve why a grant exists and maintain it across owner changes; a default manual RowCause does not provide the same durability. Make grant creation idempotent, remove access when the qualifying relationship ends and provide a governed recalculation path.

Make code honour the same security contract

A correctly configured sharing model can still be bypassed by server-side code. Salesforce's Apex guidance distinguishes with sharing, without sharing and inherited sharing, and recommends explicit declarations for classes that query or change data. Sharing declarations govern record-level access; they do not by themselves establish object and field permission enforcement. Current platform guidance also provides explicit user and system modes for database operations.

Default application services to user-respecting behaviour. Isolate any privileged operation behind a narrow method with a documented reason, validated inputs, controlled outputs and tests proving that hidden records do not leak. Never return a broad system-mode query to a Lightning component and assume the interface will filter it. Entry points, asynchronous work, triggers and integration users need deliberate execution context because their access graphs can differ materially from the person who initiated the business action.

Treat sharing changes as production migrations

Changing organisation-wide defaults, moving large role branches, modifying major public groups or introducing several sharing rules can trigger recalculation across many records and users. Salesforce recommends testing substantial changes in a full data sandbox and planning maintenance during low activity. The risk is not only runtime. A broader default can expose data immediately, while later recalculation removes redundant share rows and changes the evidence available for troubleshooting.

Estimate affected records, owners, groups and share rows before deployment. Rehearse with production-shaped volume, concurrent integrations and ownership transfers. Sequence data loads so ownership and parent relationships do not create avoidable recalculation and locking pressure. Monitor background sharing work and Apex recalculation jobs where used. Have a recovery plan that restores the prior policy without relying on share rows the platform may have removed as redundant.

Test effective access, not configuration screenshots

Build an access matrix using representative users and records: own record, subordinate record, peer branch, queue record, criteria-shared record, manually shared exception, restricted record and a record exposed through a broad permission. Test read, edit, transfer and delete separately. Include external users where applicable because high-volume Experience Cloud users use sharing sets and share groups rather than the full role-based sharing model.

For diagnosis, Salesforce provides UserRecordAccess to report whether a user has read, edit, delete or transfer access, and share objects expose grant reasons. Those tools help explain access but do not replace end-to-end testing; UserRecordAccess does not account for restriction rules. Review unexpected access as seriously as missing access, recertify groups and broad permissions, and measure recalculation incidents. A trustworthy sharing model is one the team can predict, prove and safely change—not one that merely stops producing support tickets.