Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionarySSharing Rule
AdministrationIntermediate

Sharing Rule

A Sharing Rule in Salesforce grants additional record access to specific groups of users beyond what is defined by the org-wide default sharing settings and the role hierarchy.

§ 01

Definition

A Sharing Rule in Salesforce grants additional record access to specific groups of users beyond what is defined by the org-wide default sharing settings and the role hierarchy. Sharing Rules can be criteria-based (sharing records that match specific field values) or owner-based (sharing records owned by certain users or roles).

§ 02

In plain English

👋 Study buddy

Here's a simple way to think about it: Sharing Rules are the safety valve when the role hierarchy doesn't fit. Grants additional access to specific groups (criteria-based or owner-based) without restructuring the hierarchy itself.

§ 03

Worked example

scenario · real-world use

At Horizon Pharma, the org-wide default for the Account object is Private, so reps can only see their own Accounts. The admin creates a criteria-based Sharing Rule that shares all Accounts with Industry = "Healthcare" with the Compliance team's public group, giving them read-only access. This allows compliance officers to review healthcare accounts without opening up all Account data to the entire company.

§ 04

Why Sharing Rules are the safety valve when the role hierarchy doesn't fit

Salesforce's standard sharing model assumes a clean hierarchy - Account Executives roll up to Sales Managers, who roll up to VPs. The role hierarchy implies access; OWD restricts to private; everyone fits. Real businesses are messier than that. A regional team that needs visibility across regions, a partner channel that's organizationally separate but operationally adjacent, a special-projects unit that needs a slice of everything - none of these fit the hierarchy cleanly. Sharing Rule is what fits them.

A Sharing Rule grants access to specific groups (criteria-based on field values, or owner-based on role/group) without restructuring the hierarchy itself. Used carefully, they're indispensable; used carelessly, they accumulate into a sharing model nobody understands. Build them with documented intent, audit them when org structure changes, and prefer fewer, broader rules over many narrow ones - sharing performance scales poorly with rule count.

§ 05

How to set up Sharing Rule

Sharing Rules open up record access on top of the Org-Wide Default — they let you say "users in Role A also see records owned by Role B." They only ADD access; you can't restrict with sharing rules. The OWD must be Private (or Public Read Only) for sharing rules to be meaningful at all.

  1. Open Setup → Sharing Settings

    Setup gear → Quick Find: Sharing Settings → Sharing Settings.

  2. Verify the Org-Wide Default for the object

    Scroll to Organization-Wide Defaults. If the OWD for this object is Public Read/Write, sharing rules don't matter — everyone sees everything already.

  3. Scroll to the object's Sharing Rules section → New

    Each object has its own Sharing Rules section. Click New.

  4. Name the rule

    Label and Name. Conventions: "<from> shares with <to> at <level>" e.g. "Sales Reps share Accounts with Marketing".

  5. Pick Rule Type: Owner-based or Criteria-based

    Owner-based: "records OWNED by group X are shared with group Y." Criteria-based: "records WHERE Field = X are shared with group Y." Criteria-based is more powerful but evaluates more often.

  6. Configure source and target

    Source: who owns the records (Roles, Roles and Subordinates, Public Groups). Target: who gets access (same options). For criteria-based, Source is the filter.

  7. Pick Access Level

    Read Only or Read/Write. Save.

Key options
Rule Typeremember

Owner-Based, Criteria-Based, or Guest User Based. Criteria-based requires the Sharing By Criteria feature to be enabled per object.

Sourceremember

Who owns / matches the records. Roles, Roles + Subordinates, Public Groups, Territories.

Targetremember

Who gets the access. Same options as Source.

Access Levelremember

Read Only or Read/Write. Cannot grant Full Access via sharing rule.

Gotchas
  • Sharing rules only OPEN access — they cannot restrict it. To restrict, change the Org-Wide Default or use Apex Managed Sharing.
  • Criteria-based sharing rules recalculate on every record save that matches or stops matching. On large data volumes this can be expensive — Salesforce caps you at 50 criteria-based rules per object.
  • Sharing recalculation runs in the background. Big changes (mass Owner reassignment) can take hours to settle visibility — don't panic if a user can't see records immediately after a bulk update.
§ 06

How organizations use Sharing Rule

Cascade Industries

Sharing rule grants partner-channel team visibility into specific Account regions without making them full role-hierarchy members.

Vanguard Solutions

Special-projects unit gets a slice of Opportunities through criteria-based sharing rule; the hierarchy stays clean.

BlueRiver Health

Care coordination team accesses cross-departmental records via sharing rule; the role hierarchy didn't need to model collaboration.

§

Trust & references

Official documentation

Straight from the source - Salesforce's reference material on Sharing Rule.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.
§

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…

Loading discussion…