Salesforce Sharing Rules Explained Clearly

Salesforce sharing rules automatically give defined groups access to records they would not otherwise receive from organization-wide defaults (OWD) or the role hierarchy. They are built for repeatable exceptions. They add access; they never take it away.

• Use a sharing rule when the same identifiable group needs ongoing access to a predictable set of records.
• Do not use one when you need to hide records, share one record once, or calculate recipients with complex logic.
• Check first: the object OWD, the recipient’s object permissions, and whether a simpler access mechanism already solves the requirement.

Where Salesforce Sharing Rules Fit

Salesforce separates what a user can do from which records the user can do it to. This layered model prevents a record-level exception from silently granting object or field capabilities. Design this access layer as part of the broader Salesforce implementation security model

Control	Question it answers	Effect on access	Practical point
Profile, permission sets, and permission set groups	Can the user read or edit this object and field?	Sets object- and field-level capability	A sharing rule cannot compensate for missing Read or Edit permission.
Organization-wide defaults (OWD)	What is the default access to records the user does not own?	Sets the record-access baseline	Choose the access needed by the most restricted user.
Role hierarchy	Which access should flow upward?	Opens record access vertically	For custom objects, Grant Access Using Hierarchies can be disabled.
Sharing rules	Which predictable exception should apply automatically?	Opens record access across groups, roles, or territories	Best for repeatable, group-based access.
Restriction rules	Which records should remain visible after access was granted?	Filters read access on supported objects	Use when the requirement is to narrow, not widen, visibility.

Effective access is a three-part test: the user needs the necessary object permission, field permission, and record access. If several record-sharing mechanisms apply, the most permissive record-level grant wins; object and field permissions still cap the action.

Why keep these controls separate? RBAC describes permissions as “administratively associated with roles” while users are assigned to appropriate roles. Salesforce divides this administrative job across permissions, roles, and record-sharing tools. Creating near-duplicate roles for every cross-team exception leads to what access-control research calls “role explosion”. Public groups and sharing rules usually express those exceptions more cleanly.

The security objective is balance. Access-control policies must avoid both under-privilege and over-privilege: too little access blocks work; too much access exposes data. A restrictive OWD plus deliberate sharing rules gives admins a reviewable way to manage that balance.

Types of Salesforce Sharing Rules

Owner-based and criteria-based sharing rules are the two main types. Guest user sharing rules are a special criteria-based option for unauthenticated users.

Type	Selects records by	Best fit	Example
Owner-based	The record owner’s role, public group, territory, or another supported ownership category	Visibility should follow ownership	Accounts owned by EMEA Sales are shared Read Only with the Customer Success public group.
Criteria-based	Field values on the record, regardless of owner	Visibility should follow a stable business attribute	Cases where Priority = Critical are shared Read/Write with the Escalations public group.
Guest user (special criteria-based rule)	Record criteria	A public site must expose a narrowly defined set of records without login	Grant Read Only access only after reviewing the data-exposure risk.

The Three Parts of Every Sharing Rule

• Records: Which records qualify, by owner or by field criteria?
• Recipients: Which public group, role, role and subordinates, territory, or other supported category receives access?
• Access level: Should recipients get Read Only or Read/Write? Some objects expose additional related-record settings.

A precise requirement can be written in one line: Share [records] with [audience] at [access level] because [business reason]. If that sentence is unclear, the rule is not ready to build.

When to Use a Sharing Rule, and When to Use Something Else

Choose among Salesforce’s record-access mechanisms according to whether access is inherited, repeatable, record-specific, relationship-based, restrictive, or driven by custom sharing logic.

Requirement	Best-fit control	Why
Managers inherit access from people below them	Role hierarchy	It is designed for vertical access inheritance.
A known group repeatedly needs access to a predictable record set	Sharing rule	It applies automatically to current and future matching records.
One named user needs one record as an exception	Manual sharing	It is record-specific; a public group is better if the exception will recur.
A changing set of collaborators works on one Account, Opportunity, or Case	Record team	Teams model per-record collaboration and responsibilities.
Account coverage follows geography or market segments	Enterprise Territory Management	Territories model account access independently of the management hierarchy.
High-volume Experience Cloud users need records related to their Account or Contact	Sharing set	Sharing sets map external users to related records without roles. They are not ordinary sharing rules.
Recipients must be calculated dynamically or declarative rules cannot express the logic	Apex managed sharing	Code can create and maintain custom-object share records with explicit sharing reasons.
Users already have access, but a supported user group must see only matching records	Restriction rule	It filters records after sharing mechanisms have granted read access.

How to Create a Sharing Rule in Salesforce

1. Write the requirement. Identify the object, qualifying records, recipient group, access level, and business reason.
2. Check prerequisites. Confirm the recipient has the needed object permission. The object’s OWD must be Private or Public Read Only for the rule to add access.
3. Prepare the audience. Create a public group first if several users, roles, or groups should be managed as one target.
4. Open the object settings. With Manage Sharing permission, open Setup, search Sharing Settings, select the object, and choose New under Sharing Rules.
5. Choose the rule type. Select Based on record owner or Based on criteria, then define the source owners or field conditions.
6. Choose recipients and access. Select the target group, role, role and subordinates, territory, or other available category. Grant the minimum access needed.
7. Save, recalculate, and test. Wait for sharing calculation to complete, then test both a user who should gain access and a similar user who should not.

Worked example: Finance reviews closed-won opportunities

Requirement: Finance must review every Closed Won opportunity, but it must not browse the rest of the pipeline.

Setting	Configuration
Object and OWD	Opportunity; Private
Rule type	Criteria-based
Criteria	Stage equals Closed Won
Share with	Finance Reviewers public group
Access	Read Only
Expected result	Finance can view matching opportunities. It cannot edit them through this rule, and nonmatching opportunities remain unavailable unless another access source grants visibility.

This design is safer than moving Finance into the sales role hierarchy or granting View All Records, because the exception is limited to a defined record set and a named group.

Limitations and Considerations

Constraint	What it means	Admin response
Rules only add access	They cannot make access more restrictive than OWD or remove access granted elsewhere.	Tighten OWD or use a supported restriction rule when access must be narrowed.
Permissions remain a ceiling	Read/Write sharing does not grant object Edit or field editability.	Check the user’s combined profile, permission sets, permission set groups, and field-level security.
Access is additive	If multiple rules or sharing mechanisms apply, the most permissive record access wins.	Trace every access source before changing a rule.
Rule limits	An object can have up to 300 total sharing rules, including up to 50 criteria-based and guest user rules combined.	Consolidate audiences with public groups and simplify the model before approaching the limit.
Criteria field limits	Lookup, encrypted, formula, and other derived fields cannot be used as criteria.	Use a stored field maintained by Flow when the business condition is calculated.
Related access	Sharing an Opportunity, Contact, or Case can also grant access to its parent Account.	Test related-record visibility, not only the record named in the rule.
Rule edits are limited	The Share with target cannot simply be changed; other editable fields depend on rule type.	Plan the target carefully. Delete and recreate the rule when required.
External-user limits	High-volume site users do not have roles and cannot be in public groups, so owner-based rules do not fit them.	Use sharing sets, share groups, or an eligible criteria-based pattern according to the license and relationship.
Availability and recalculation	Supported objects, rule types, and editions vary. Large changes can take time to recalculate.	Confirm options in the org, test in a sandbox, and schedule major changes deliberately.

Verify current sharing-rule limits and available options against your own Salesforce edition and enabled features before implementation.

How to Test and Troubleshoot Sharing Rules

Test the intended outcome and the boundary around it. A rule is not validated merely because one user can open one record.

• Positive test: A representative recipient can access a matching record at the intended level.
• Negative user test: A similar user outside the target group cannot access the same record.
• Negative record test: A target-group member cannot access a nonmatching record unless another approved mechanism grants it.
• Change test: Update the owner or criteria so the record enters and leaves the rule, then confirm access recalculates correctly.
• Related-record test: Check the Account and relevant child records for unintended visibility.

Symptom	Check in this order
The user cannot see the record	Object Read permission; OWD; source owner or criteria; target group membership; recalculation status; external-user license constraints; restriction rules.
The user can view but cannot edit	The rule’s access level; object Edit permission; field-level security; validation rules or required fields.
The user sees more records than expected	OWD; role hierarchy; View All Records or Modify All Records; other sharing rules; teams; territories; manual or Apex shares; related-record implicit access.
Only some records behave correctly	Owner changes; blank or unsupported criteria fields; queue ownership; record type labels; automation that updates the criteria field.

Use Salesforce’s access evidence instead of guessing. From a supported record’s action menu in Lightning, open Sharing Hierarchy and select View beside a user to see why access exists. For technical checks, query UserRecordAccess for the user and record, or inspect the object’s share table and RowCause.

Governance Checklist

• Start with the most restrictive workable OWD, then open only the access the business can justify.
• Use public groups as stable audiences instead of scattering the same roles across many rules.
• Name rules consistently: [Object] | [Source or Criteria] -> [Target] | [Access].
• Document the owner, business reason, source, target, access level, dependencies, and test users for every rule.
• Review stale group membership and overlapping access grants after reorganizations, integrations, and ownership changes.
• Test in a sandbox before changing OWD or high-volume rules in production.

For adjacent controls, see DGT27’s guides to Salesforce role hierarchy and permission set governance.

Frequently asked questions

What is the difference between OWD and sharing rules?

OWD sets the default record access for users who do not own a record. Sharing rules create automatic exceptions that add access for defined groups when the baseline is Private or Public Read Only.

Can a sharing rule grant access to one user?

Not directly as a named individual target. Add the user to a public group when the rule should apply repeatedly, or use manual sharing when one user needs one record as an exception.

What happens when several sharing rules apply?

Salesforce combines the grants and gives the user the most permissive record access available. A Read Only rule cannot reduce Read/Write access granted by another rule or mechanism.

Can sharing rules override profiles or permission sets?

No. Sharing rules decide record visibility. The user’s combined object and field permissions still decide whether the record or field can be read or edited.

What is the difference between sharing sets and sharing rules?

Sharing rules grant access to roles, groups, territories, and other supported categories. Sharing sets are designed for high-volume Experience Cloud users and grant access through a relationship between the user’s Account or Contact and the target record.

Can formula fields be used in criteria-based sharing rules?

No. Salesforce excludes formula, lookup, encrypted, and other derived fields from criteria. Store the evaluated result in a supported field, often maintained by Flow, and base the rule on that field.

Can sharing rules control Tasks and Events?

Tasks and Events use the Activity sharing model rather than ordinary object sharing rules. Access can depend on the Activity OWD, ownership, role hierarchy, and access to the related Name and Related To records. Restriction rules can further filter Tasks and Events on supported editions.

How are Person Accounts shared?

Treat a Person Account as an Account for record sharing. Before changing rules, confirm the org uses a supported Person Account sharing configuration: Contacts set to Controlled by Parent, or both Accounts and Contacts set to Private.

Bottom line

A well-designed Salesforce sharing rule answers four questions without ambiguity: which records, which recipients, which access level, and why. Keep OWD restrictive, keep object and field permissions separate, use public groups for maintainable audiences, and prove the rule with both positive and negative tests.

If unexpected access has spread across roles, groups, rules, and permission assignments, dgt27’s Salesforce admin support team can audit the effective model and document a safer correction path before production changes are made.