Salesforce sharing rules are automatic exceptions to your organization-wide defaults (OWD): they give groups of users access to records they don't own, either because of who owns the records or because the records match criteria. Sharing rules only open access, never restrict it. They sit in a layered model with OWD, the role hierarchy, manual sharing and Apex managed sharing.
This guide was first published in 2020. It has been rewritten for 2026 and now also covers organization-wide defaults and Apex managed sharing, which had their own posts before.
How does record sharing work in Salesforce?
Record sharing starts from organization-wide defaults and opens up through the role hierarchy, sharing rules and manual sharing. Trailhead's data security module describes four layers. You start locked down and open access layer by layer:
- Organization-wide defaults set the baseline access users have to records they don't own.
- Role hierarchies make sure managers can access the same records as their subordinates.
- Sharing rules are automatic exceptions to OWD for particular groups of users.
- Manual sharing lets record owners, or users with enough permissions, give read and edit access to individual records.
Two things sit outside this ladder. Object and field access comes from profiles and permission sets: sharing decides which records a user sees, but only if they can access the object at all. And Apex managed sharing lets code grant access where declarative rules can't. Finally, Trailhead's object access unit notes that the View All Data and Modify All Data permissions override all sharing settings, so keep them to system administrators.
What are organization-wide defaults (OWD)?
Organization-wide defaults set the baseline access every user has to records they don't own, per object: Private, Public Read Only, Public Read/Write or Controlled by Parent.
| OWD setting | Who can see and edit records they don't own | Typical use |
|---|---|---|
| Private | Only the owner and users above them in the role hierarchy | Accounts and opportunities in competitive sales teams |
| Public Read Only | Everyone can view and report; only the owner (and those above) can edit | Products, reference data |
| Public Read/Write | Everyone can view, edit and report on all records | Small teams with nothing to hide |
| Controlled by Parent | Access follows the parent record in a master-detail relationship | Line items, child records |
Settings as described in Trailhead. Set OWD to the most restrictive level any user needs, then open up. For custom objects you can also clear Grant Access Using Hierarchies, so that only owners and users given access through sharing see the records, not their managers. Salesforce's sharing architecture guide warns that changing OWD triggers a sharing recalculation, which can take a long time on large data volumes.
Owner-based vs criteria-based sharing rules
Owner-based rules share records by who owns them; criteria-based rules share records by their field values.
| Owner-based | Criteria-based | |
|---|---|---|
| Shares records | Owned by a set of users (a role, group or territory) | Whose field values match conditions |
| Example | Opportunities owned by the West sales role, shared with the West support team | Accounts where Industry is Healthcare, shared with the healthcare specialists group |
| Changes when | Ownership changes | Field values change |
| Default limit per object | Counts toward 300 rules in total | Up to 50 (with guest user rules), within the 300 total |
Both types can share with public groups (which can hold users, roles, roles and subordinates, territories or other groups) and with roles and subordinates, at Read Only or Read/Write, according to Trailhead's sharing rules unit. A sharing rule can never be stricter than OWD. A third kind, guest user sharing rules, is a criteria-based rule that gives unauthenticated visitors to an Experience Cloud site access to matching records; use it only for data that is safe to publish, and note that it counts toward the 50 criteria-based rules. Limits are from the sharing architecture guide.
How to create a sharing rule in Salesforce
Go to Setup, Sharing Settings, pick the object, click New under Sharing Rules, then choose the records, the recipients and the access level.
- If you are sharing with a custom set of people, create a public group first: Setup → Public Groups → New, then add members.
- Go to Setup → Sharing Settings and check the object's default access. If it is Public Read/Write, a sharing rule adds nothing.
- Under the object's Sharing Rules list, click New.
- Give the rule a label and choose the type: based on record owner or based on criteria.
- Select which records to share: owned by members of a group or role, or matching your field criteria.
- Select who to share with: a public group, role, or role and subordinates.
- Choose the access level, Read Only or Read/Write, and save. Salesforce recalculates access in the background.
Test by logging in as a user in the target group (or using the sharing button on a record) to confirm they see what you expect, and no more. A quick report run as that user is an easy check, because reports respect sharing.
To move sharing rules from a sandbox to production, deploy them as metadata: sharing rules are a metadata type (SharingRules), so they travel with the Salesforce CLI, a DevOps pipeline or a change set like other configuration. Deploy the public groups and roles they refer to first, and expect a sharing recalculation after deployment. Our Salesforce DevOps guide covers the pipeline options.
What is Apex managed sharing?
Apex managed sharing is sharing granted by code, used when access depends on logic that sharing rules can't express. When access depends on logic that rules can't express, for example "share each project with the users listed on its team members", developers grant access in code. Per the Apex Developer Guide on Apex managed sharing:
- Each object with sharing has a share object. For custom objects it is named after the object, such as
Project__Share. - Code inserts share records with the record ID, the user or group ID, the access level and a
RowCause. - The RowCause should be a custom Apex sharing reason you define on the object. Shares with the Manual reason are deleted when the owner changes; shares with a custom reason are kept.
- Only users with the Modify All Data permission can add or change Apex managed shares.
Until recently, custom reasons existed only on custom objects, so code sharing standard objects such as Case or Account had to use the Manual reason and lost those shares on ownership transfer. The Salesforce Developers blog on custom row causes on standard objects (October 2026) explains that custom row causes now come to standard objects, rolling out through the Metadata API to all orgs by the end of October 2026 with management from Setup following in November, and that a separate setting, Keep Manual Shares on Record Transfer, covers users' manual shares. If your code shares standard-object records, it is worth moving it to a custom row cause.
A typical share in Apex looks like this: create a Project__Share with ParentId set to the project, UserOrGroupId set to the team member, AccessLevel set to 'Edit', and RowCause set to Schema.Project__Share.RowCause.Team_Member__c, then insert the list in bulk, ideally from a trigger handler or a queueable job that also removes shares no longer needed.
Other sharing tools to know
Implicit sharing, restriction rules, teams and territories also shape who sees what.
- Implicit sharing. Automatic and not configurable: if a user can see a contact, opportunity, case or order, they implicitly see its parent account. It does not apply to custom objects.
- Restriction rules. The opposite of sharing rules: they filter which records users can see. As of November 2026 the architecture guide lists up to two active restriction rules per object in Enterprise and Developer editions, and up to five in Performance and Unlimited.
- Teams. Account, opportunity and case teams share individual records with named colleagues.
- Territory management. Shares accounts and opportunities by territory rather than by role.
Sharing model mistakes to avoid
Start restrictive, keep roles about data access, consolidate rules with groups and give Apex shares a custom reason.
- Starting with Public Read/Write. Moving to Private later is a big change for users and triggers recalculation. Start restrictive.
- A role hierarchy that mirrors the org chart. Roles should reflect who needs to see whose data, not reporting lines for HR.
- Hundreds of near-identical rules. Use public groups to consolidate; rule counts and recalculation time grow together.
- Apex shares with the Manual reason. They disappear on owner change; use a custom sharing reason.
- Forgetting AI and integrations. Agents and integration users work within the access you grant, so review their permissions like any user's. See our Salesforce security checklist.
Getting help
Techila is a Salesforce Summit Partner. Our Salesforce consulting team designs and audits sharing models, from OWD and role hierarchies to Apex managed sharing, so people see what they need and nothing more. Talk to us if your sharing model has grown hard to explain.
Frequently asked questions
What are sharing rules in Salesforce?
Sharing rules are automatic exceptions to your organization-wide defaults. They give groups of users, such as public groups or roles, Read Only or Read/Write access to records they don't own, based on who owns the records or on field values. They can only open access, never restrict it.
What is OWD in Salesforce?
OWD stands for organization-wide defaults: the baseline access users have to records they don't own, set per object. The settings are Private, Public Read Only, Public Read/Write, and Controlled by Parent for detail records in a master-detail relationship.
What is the difference between owner-based and criteria-based sharing rules?
Owner-based rules share records owned by a set of users, such as everyone in a role. Criteria-based rules share records whose field values match conditions, such as all accounts where Region equals EMEA, whoever owns them.
How many sharing rules can an object have?
Salesforce's sharing architecture guide gives a limit of 300 sharing rules per object in total, of which up to 50 can be criteria-based or guest user sharing rules. Too many rules also slow sharing recalculation, so consolidate where you can.
What is Apex managed sharing?
It is sharing created in Apex code by inserting share records, such as MyObject__Share, with a custom Apex sharing reason in the RowCause field. Only users with Modify All Data can add or change these shares, and shares with a custom reason are kept when the record owner changes, unlike Manual shares.