What are Sharing Rules?

Understanding Salesforce Sharing Rules

Sharing Rules in Salesforce are declarative settings that extend record access beyond the baseline defined by the Organization-Wide Defaults (OWD) and Role Hierarchy. They allow administrators to grant additional read or read/write access to groups of users based on ownership or record criteria without writing code.

Why Sharing Rules Matter

Sharing Rules are essential when you need to open access to records for teams, roles, or public groups while keeping overall data security controlled by OWD. They provide a scalable way to share records automatically and help model real-world access requirements like cross-functional collaboration and temporary project visibility.

Types of Sharing Rules

There are two primary types of sharing rules:

  • Owner-Based Sharing Rules — Share records owned by members of a role, role-and-subordinates, or public group with other users, roles, or public groups.
  • Criteria-Based Sharing Rules — Share records that meet specific field criteria (for example, Account.Industry = ‘Finance’) with specified users, roles, or public groups.

How Sharing Rules Work with Other Security Controls

Sharing Rules build on top of these layers:

  • Profiles & Permission Sets — control object- and field-level access.
  • Organization-Wide Defaults (OWD) — set the baseline record access (Private, Read Only, Public Read/Write).
  • Role Hierarchy — automatically grants access up the role chain (if enabled).
  • Sharing Rules — provide lateral access to users who are not above the record owner in the role hierarchy.

Example Scenarios

Common scenarios for using Sharing Rules:

  • Share all opportunities owned by the “West” sales team with a Support public group.
  • Share accounts with AnnualRevenue > 10,000,000 with the “Enterprise Accounts” team (criteria-based).
  • Provide read/write access to partner users for records owned by a Partner Role.

Creating a Sharing Rule (Declarative Steps)

  1. Navigate to Setup → Security → Sharing Settings.
  2. Locate the object (e.g., Account, Opportunity) and click “New” under the Sharing Rules section.
  3. Choose Owner-Based or Criteria-Based rule type.
  4. Define the source (owners or criteria) and the target (roles, groups, or territories).
  5. Choose access level: Read Only or Read/Write.
  6. Save and let Salesforce calculate sharing. For large data sets, initial recalculation can take time.

Important Considerations and Limits

  • Sharing Rules can only grant additional access; they cannot restrict access beyond OWD.
  • Excessive sharing rules and complex criteria can increase sharing recalculation time and impact performance.
  • Sharing rules apply to standard and custom objects (some exceptions apply for certain managed package objects).
  • For very complex scenarios, consider Apex Managed Sharing which gives programmatic control over record sharing.

Relationship to Apex Managed Sharing

Apex Managed Sharing is used when declarative sharing rules are insufficient — for example, when you need row-level access based on complex business logic, or to share records with users determined at runtime. Apex sharing requires the object to have an associated Share object (e.g., AccountShare) and appropriate Apex code to create share records.

Quick Reference: When to Use Which

  • Use Owner-Based Sharing Rules when ownership determines the need to share.
  • Use Criteria-Based Sharing Rules when records meeting particular conditions must be shared.
  • Use Apex Managed Sharing for dynamic or highly complex sharing requirements not supported declaratively.

Sample Criteria-Based Rule (Example)

Share all Accounts where Industry = ‘Technology’ with the “Tech Support” public group as Read Only.


// Declarative setup example — not code, but this represents the logic
// Criteria: Account.Industry = 'Technology'
// Share with: Public Group 'Tech Support'
// Access Level: Read Only

Sharing Rules are a powerful, declarative way to extend record access in Salesforce while keeping security predictable and maintainable. Use them thoughtfully alongside OWD and role hierarchy to model your organization’s access requirements.