Sharing Rule
A Sharing Rule in Salesforce is an org-wide configuration that grants record access to a set of users based on either record ownership or record criteria.
Definition
A Sharing Rule in Salesforce is an org-wide configuration that grants record access to a set of users based on either record ownership or record criteria. The rule sits inside the broader Salesforce sharing model, layered between Organization-Wide Defaults (the base access level) and Manual Sharing (record-by-record grants). Sharing Rules grant access; they cannot restrict it. Once a Sharing Rule fires, the users it targets get access at the level the rule specifies, regardless of role-hierarchy position or other sharing mechanisms.
Sharing Rules exist because Organization-Wide Defaults are intentionally restrictive in most Salesforce orgs. Setting Account or Opportunity to Private OWD locks every record to its owner; only Role Hierarchy access and Sharing Rules open that lockdown back up. Without Sharing Rules, every cross-team visibility need (a manager seeing a peer-team's deals, a service rep seeing a sales rep's Account, a finance user seeing every renewal Opportunity) requires either Role Hierarchy gymnastics or hundreds of manual Share clicks. Sharing Rules are the structured layer that makes those access patterns repeatable.
How Sharing Rules fit into the Salesforce sharing model
Owner-based sharing rules
The most common type of Sharing Rule. Records owned by users in Group X share automatically with users in Group Y. Both X and Y can be Public Groups, Roles, or Roles and Subordinates. The pattern fits situations like "deals owned by the EMEA Sales team should be visible to the EMEA Finance team for revenue recognition." Owner-based rules are fast to evaluate, because the platform only needs to check who owns the record. Most enterprise Salesforce orgs have between five and twenty owner-based sharing rules per high-traffic object (Account, Opportunity, Case), each modeling a specific cross-team visibility pattern.
Criteria-based sharing rules
The other type, evaluated against record-field criteria rather than ownership. A criteria-based rule reads like "any Account where Industry = Healthcare shares with the Healthcare Vertical Team." Criteria-based rules cover access patterns that owner-based rules cannot model, but they come with constraints. The platform limits criteria-based rules to 100 per object, and recalculations are slow because the platform has to evaluate every record against the criteria when the rule changes or when a criterion field updates on a large dataset. Use criteria-based rules when ownership does not align with access need; rely on owner-based rules when it does.
Sharing rule recalculation
Sharing Rule changes trigger recalculation across every record on the affected object. The recalculation is asynchronous and can run for hours in large orgs with millions of records. Triggers that change criterion fields (Industry, Region, Tier) also fire recalculations. Setup > Sharing Settings > Recalculate Sharing Rules lets you manually trigger the job, useful after a bulk data load that may have skipped sharing-rule evaluation. Monitor recalculation through the Setup audit log; for orgs with very large datasets, plan rule changes for off-hours so the recalculation queue does not back up live transactions.
Limits and performance impact
Salesforce caps Sharing Rules at 300 per object (combined owner-based and criteria-based, with criteria-based capped at 100). Each rule creates rows in the ObjectShare table (AccountShare, OpportunityShare, CaseShare, custom ObjectShare tables), so the data layer underneath sharing grows quickly. Heavy sharing-rule orgs see slower record saves and slower Role Hierarchy changes because every save and every Role update triggers some amount of sharing re-evaluation. Audit your sharing rules quarterly and remove the ones that are no longer relevant; orgs that accumulated rules over five years rarely have all of them still doing useful work.
Manual Sharing and Team-based sharing
Sharing Rules sit alongside two record-level sharing mechanisms. Manual Sharing is the per-record Share button on any record, used for one-off grants ("share this Opportunity with the Solution Engineer who is helping out for this deal only"). Manual Sharing breaks when the record's Owner changes, which makes it brittle for any long-term access pattern. Account Teams and Opportunity Teams are the structured per-record alternative: a defined membership list per record with role-based access levels, surviving Owner changes. Use Sharing Rules for org-wide patterns, Account/Opportunity Teams for per-deal teams, and Manual Sharing only for truly one-off exceptions. Mixing all three on the same record creates an audit trail that nobody can untangle six months later.
Apex Managed Sharing
When declarative Sharing Rules cannot model the access pattern, Apex Managed Sharing through the Share object lets you write custom sharing logic in code. The pattern is common for territory-management implementations, matrix-organization access rules, and complex cross-object inheritance ("this Contact should share if and only if its parent Account is in a specific Tier and the User has a specific Custom Permission"). Apex Sharing requires careful design because incorrect logic creates either over-sharing (security incident) or under-sharing (users cannot do their job). Document Apex Sharing logic explicitly, include it in the org's data-security review, and prefer declarative Sharing Rules whenever they cover the requirement.
Interaction with Role Hierarchy and OWD
The Salesforce sharing model layers are evaluated in a specific order. Organization-Wide Defaults set the base access level for an object (Private, Public Read Only, Public Read/Write). Role Hierarchy grants additional upward visibility based on the parent-Role relationship. Sharing Rules grant sideways or diagonal visibility based on ownership or criteria. Manual Sharing and Apex Sharing fill in record-by-record cases. None of these layers can restrict what a more-permissive layer grants; you can only build up from the OWD floor. If OWD is Public Read/Write, Sharing Rules are unnecessary because every user already sees every record. If OWD is Private, every cross-team visibility requires either Role Hierarchy access, a Sharing Rule, or a Manual Share.
How to create a Sharing Rule
Creating a Sharing Rule is one of the standard cross-team-access configurations a Salesforce admin handles regularly. The configuration is straightforward, but the testing and validation matter more than the click path because incorrect sharing leads to either security gaps or usability complaints.
- Open Setup and navigate to Sharing Settings
Setup > Security > Sharing Settings. The page shows Organization-Wide Defaults at the top and Sharing Rules grouped by object below.
- Pick the object and click New
Scroll to the object whose Sharing Rule you want to create (Account, Opportunity, Case, custom object). Click New under the appropriate sharing rule section.
- Choose owner-based or criteria-based
Owner-based rules are faster to evaluate and easier to maintain; criteria-based rules cover access patterns that ownership cannot describe. Pick the type that matches the requirement.
- Configure the source and target
For owner-based rules, pick the source group (whose records get shared) and the target group (who gets access). For criteria-based rules, define the criteria (Industry = X, Region = Y, custom field = Z) and pick the target group.
- Set the access level
Read Only or Read/Write. Read Only suffices for most visibility-only rules; Read/Write is needed when the target team also needs to edit records.
- Save and wait for recalculation
Click Save. The platform queues a recalculation; on small orgs this completes in seconds, on large orgs it can take hours. Monitor through the Setup audit log.
- Test with representative users
After recalculation completes, log in as a target-group user (or use Login As) and confirm they see the records they should and do not see records they should not.
- Sharing Rules grant access only; they cannot restrict access granted elsewhere. If OWD is Public Read/Write, Sharing Rules do nothing.
- Criteria-based sharing rules cap at 100 per object. Plan your access model so the most common patterns use owner-based rules.
- Recalculation is asynchronous and can run for hours on large datasets. Plan rule changes for off-hours.
- Apex Managed Sharing is needed for access patterns declarative rules cannot model. Document the logic explicitly so future admins can debug sharing complaints.
Trust & references
Cross-checked against the following references.
- Sharing RulesSalesforce Help
- Control Who Sees WhatSalesforce Help
Straight from the source - Salesforce's reference material on Sharing Rule.
- Sharing RulesSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Why is understanding Sharing Rule important for Salesforce admins?
Q2. In which area of Salesforce would you typically find Sharing Rule?
Q3. Can a Salesforce admin configure Sharing Rule without writing code?
Discussion
Loading discussion…