Sharing Rules in Salesforce: When and How to Use Them

Sharing Rules in Salesforce let you give users access to records they don’t have access to by default. In this guide, you’ll learn what they are, when to use them and to set them up step by step.  

What Are Sharing Rules in Salesforce?

Sharing Rules let you give users extra access to records beyond the default Org-Wide Defaults (OWD). They’re used to help teams work together without the need to change record ownership or roles. 

Importantly, Sharing Rules always extend access; they cannot restrict it. This functionality supports Salesforce’s comprehensive security model while encouraging seamless teamwork across different roles and departments.

Types of Sharing Rules

• Criteria-Based Sharing Rules: extend access to records that match specific field conditions (e.g., Stage, Amount, Status), regardless of who owns them, and share those records with a chosen group.
• Owner-Based Sharing Rules: extend access to all records owned by a specified role, queue, territory, or public group and share them with another group you define.
• Guest User Sharing Rules: a criteria-based subset that grants read-only access to the unauthenticated guest user of an Experience Cloud site, intended only for public, non-sensitive data.

When Should You Use Sharing Rules?

Here are some of the most common use cases:

1. High-value client visibility (Criteria-Based): Some financial accounts may require peer review or co-management due to their size or strategic importance. A criteria-based sharing rule can automatically share accounts over a certain value (e.g., $1,000,000) with a group of senior advisors, allowing qualified peers to assist with planning, oversight, or compliance.
2. Project coordination (Owner-Based): Project Managers typically own the Contact records for client stakeholders involved in active projects. An owner-based sharing rule can automatically share every Contact owned by users in the Project Managers” role (or public group) with a group called “Implementation Team.” This ensures that delivery staff have the access they need to view or update client Contacts, even if they don’t own the records, helping the team stay aligned without changes to ownership or the role hierarchy. 
3.  Volunteer opportunities (Guest User): Non-profits often publish open volunteer shifts on a public Experience Cloud site so anyone can browse opportunities. A guest-user sharing rule can grant the site’s unauthenticated guest user read-only access to shift records that meet a filter (e.g., Status = “Open”). This lets the public view available shifts while keeping all other data secure.

These are common cases where giving extra visibility helps teams work better together. For further details on data security and how it complements Sharing Rules, check our Data Security article. 

How to Create a Sharing Rule

Prerequisite: Create a Public Group (if needed)

• In setup search for “Public Groups”

• Select “New”
• Enter a Label / Rule Name and (optional) description
• From the Search dropdown, choose Users, Roles, Roles and Subordinates or Public Groups
• Select the members on the left, click “Add” to move them to Selected Members
• Click “Save”

Step 1: Open Sharing Settings

In setup search for Sharing Settings

Step 2: Choose Object

In “Manage sharing settings”, select the object in the drop down.

Step 3: Create new Sharing Rule

Click “New” in Sharing Rules section

Step 4: Define Sharing Rule

Enter a clear Label / Rule Name and description (optional).

Select a Rule Type: Owner-Based, Criteria-Based, or Guest User (a criteria variant).

Owner-Based specifics:

• Which records: choose the owning Role, Role & Subordinates, Queue, Territory, or Public Group.

• Share with: pick the target Role, Territory, or Public Group.

• Access: Read Only or Read/Write.

Criteria-Based specifics:

• Which records: build field filters (Field + Operator + Value); add multiple criteria and filter logic if needed.

• Access: Read Only or Read/Write.

Click “Save” and confirm the recalculation prompt; Salesforce updates permissions and emails you when finished.

Common Mistakes to Avoid

Using Sharing Rules to restrict access

Sharing Rules only grant additional visibility meaning they cannot restrict existing access. Attempting to use Sharing Rules as a workaround for restricting access leads to mistakenly believing data is protected when it remains accessible, creating risks of unintended data exposure and confusion. For properly restricting access, use OWD/Role Hierarchy/Restriction Rules (record-level), Profiles & Permission Sets (object-level) and Field-Level Security (fields).

Ignoring updates to Public Groups

Failing to keep Public Groups up to date can cause serious issues in record access. Users who no longer need access may still see sensitive data, while new team members might be blocked from the records they need. This can lead to confusion, stalled processes, or even compliance risks. Regularly reviewing and updating group memberships helps ensure that access stays aligned with current roles and responsibilities.

Creating too many Sharing Rules

Too many specific Sharing Rules can slow down your org down. Each rule adds sharing calculations, which hurts performance as your data grows. Additionally, Salesforce has a limit on the number of rules per object, so a common recommendation is to combine similar rules. This also helps keep your setup efficient and manageable.

Carelessly granting Guest User access

Guest User Sharing Rules grant record access to unauthenticated users who visit your Experience Cloud Site. If not handled carefully, this can lead to public exposure of internal data. These rules should only be used for non-sensitive objects and limited-use cases. Regular checks help make sure guest users only see what they should.

Best Practices

• Use Public Groups: They’re easier to manage than individual users, especially when teams change or people move roles. 
• Maintain Documentation: Record every Sharing Rule clearly in an admin wiki or document repository for easy auditing and troubleshooting. Good documentation saves time and helps your admin team stay on the same page.
• Enter a clear Label / Rule Name. Avoid vague or overly generic names.
  Not OK: Rule1 or Test123 – unclear and hard to maintain later.
  OK: Share_High_Value_Opportunities – clearly describes what the rule does.

• Regular Reviews: Audit and update rules quarterly to keep your sharing model efficient and aligned with organizational changes. Audits help identify outdated rules and ensure rules remain aligned with current business practices.
• Audit Access with XL-Connector: Tools like XL-Connector by Xappex allow quick audits of record access. Export data directly to Excel for easy analysis and visibility checks, helping you quickly identify and resolve potential security issues.

Conclusion

Sharing Rules in Salesforce effectively extend record access beyond your default settings, promoting better collaboration without compromising security. Always carefully select between owner-based and criteria-based rules, maintain clear documentation, and perform regular audits. Tools like XL-Connector significantly make it easier to audit and manage sharing, keeping your salesforce setup simple and secure. 

FAQ

Where to find Sharing Rules in Salesforce?

Go to Setup → Sharing Settings. Open the Org-Wide Default table, use Manage sharing settings dropdown to select specific objects and keep the interface manageable or scroll down to the Sharing Rule section.

How to check Sharing Rules in Salesforce?

Correction: Go to Sharing Settings in Setup, then click “Edit” next to the rule you want to review. You can manage all existing sharing rules for each object from this section.

How to query Sharing Rules in Salesforce?

Retrieve the definitions of Sharing Rules with the Metadata API/SFDX and analyze their effects with SOQL queries on share object.

How to deploy Sharing Rules in Salesforce?

Use a Change Set, or the Metadata API / Salesforce CLI (SFDX) to move files in the sharingRules folder. For large deployments, ask Salesforce Support to defer sharing recalculation to minimize performance impact.