A sharing rule is an automated mechanism in Salesforce that grants record-level access to specified groups of users beyond the Organization-Wide Default (OWD) baseline. Sharing rules can only open access — they never restrict — and they’re the standard way to give one team visibility into another team’s records when the OWD is Private or Public Read Only.
The two types of sharing rules
| Type | Trigger | Use case |
|---|---|---|
| Owner-based sharing rule | Records owned by users in a specific group, role, or territory are shared with another group, role, or territory. | ”Share all opportunities owned by EMEA Sales with the EMEA Support team.” |
| Criteria-based sharing rule | Records matching specific field criteria are shared regardless of owner. | ”Share all High Priority cases with the Tier 2 Escalation group.” |
Both types result in the same outcome — a row in the appropriate *__Share table — and both can grant either Read Only or Read/Write access.
Who can be the recipient
The “shared with” target of a sharing rule can be:
- Public Groups (the most flexible — can include users, roles, roles+subordinates, other public groups)
- Roles
- Roles and Subordinates (a role plus everyone below in the hierarchy)
- Roles, Internal Subordinates (excludes external community users)
- Territories (when Enterprise Territory Management is enabled)
- Portal/Community roles (for external sharing)
You cannot share directly to a list of individual users via a sharing rule — for one-off shares to a specific user, use manual sharing instead.
When sharing rules are even necessary
Sharing rules are pointless if the OWD is already Public Read/Write — everyone can already see and edit. They’re only meaningful when:
- OWD is Private — sharing rules grant Read or Read/Write.
- OWD is Public Read Only — sharing rules can upgrade specific recipients to Read/Write.
If you’re seeing a sharing rule on an object with Public Read/Write OWD, it’s leftover from a prior configuration and you can safely remove it.
Real scenario
“OWD for Opportunity is Private. Reps see only their own. The CFO team needs read-only visibility into every opportunity over $1M. How do you set this up?”
The clean answer is a criteria-based sharing rule:
- Create a public group named “CFO Office” containing the CFO and their direct team.
- Setup → Sharing Settings → Opportunity Sharing Rules → New.
- Rule type: Based on criteria.
- Criteria:
Amount >= 1000000. - Share with: public group “CFO Office”.
- Access level: Read Only.
Every opportunity that meets the criteria — current and future — is automatically shared. If an opportunity drops below $1M, the rule revokes the share on the next recalculation.
Limits to know for interviews
These are the kind of specifics interviewers ask about to gauge depth:
- Per-object limits: 300 sharing rules per object, of which 50 can be criteria-based (older limits were lower; the current published cap is 300/50 per object).
- Up to 500 sharing rules per object can be granted via support exception in some cases — but standard org limits are 300/50.
- Sharing rule changes trigger sharing recalculation in the background, which can take significant time on large orgs.
- Criteria-based rules can use up to 10 criteria conditions combined with AND/OR.
These numbers do shift between releases, so the safe interview answer is: “There are per-object caps — 300 total and 50 criteria-based — and changes trigger recalculation, which on large orgs runs asynchronously.”
Sharing rule vs the other sharing mechanisms
| Mechanism | Scope | Reversible | Triggered by |
|---|---|---|---|
| OWD | Object-wide baseline | Yes (change setting) | Org configuration |
| Role hierarchy | Records owned by direct/indirect reports | Yes (re-parent user) | Hierarchy structure |
| Sharing rule | Groups of records to groups of users | Yes (delete rule) | Owner change or criteria match |
| Manual sharing | One record to one user/group | Yes (remove share) | Owner clicks “Share” on a record |
| Apex sharing | Custom programmatic shares | Yes (delete via Apex) | Trigger or batch logic |
| Team sharing | Account, Opportunity, Case teams | Yes (remove team member) | Team membership |
Verified against: Salesforce Help — Sharing Rules and the Sharing & Visibility Architect resources. Last reviewed 2026-05-17.