Salesforce Sharing Rules Explained Clearly

Salesforce data access follows a layered model. Organization-Wide Defaults (OWD) set a baseline (Private or Public Read Only) for each object. Role hierarchies then extend access up the chain. Salesforce Sharing Rules come next: they open up record access beyond these defaults. In other words, sharing rules make automatic exceptions to the OWD, granting selected users more access (but they never restrict access). For example, if Accounts are private, an owner-based sharing rule can share accounts owned by the Sales team with members of the Customer Success group. Likewise, a criteria-based sharing rule can share all cases where Type = “Complaint” with a support queue. These rules are used when you need lateral access (across teams or roles) without changing your hierarchy or OWD.

Salesforce sharing rules apply only to objects whose OWD is Private or Public Read Only. In practice, a Salesforce consulting partner will verify OWD first. In Setup → Security Controls → Sharing Settings, you must confirm the object’s OWD is not set to “Public Read/Write”, or the sharing rules would be redundant. Once OWD is Private or Read Only, you can define sharing rules to grant either Read-Only or Read/Write grant permissions to designated user groups. Sharing rules extend access. For example, “share this set of records with these users” but they cannot impose any additional restrictions beyond your OWD. In summary, Salesforce sharing rules give particular users greater access to records automatically, based on ownership or record criteria.

Salesforce Sharing Rules: Types and Scenarios

Sharing rules are generally divided into two categories:

Owner-Based Sharing Rules  

This rule type distributes record visibility according to record ownership. For example, you might share all Opportunity records owned by Role:North America Sales with Role:Finance. The criteria is the owner’s role, group, or public group membership. If User A owns a record and a sharing rule names User A’s role (or a public group containing that role) as the source, then the record is shared with the specified target users. This is useful when teams (roles or groups) need access to each other’s records. (For instance, East and West regional sales teams might share accounts with each other via owner-based rules.)

Criteria-Based Sharing Rules 

These share records based on field values instead of the owner. For example, configure a rule so that any Case record with the field Type set to Escalation becomes visible to the Escalations support group. You select a field (or fields) and value criteria; any record meeting that criteria is shared. These rules automatically update as data changes (if a Case’s Type field changes to “Escalation”, it starts being shared). Criteria-based rules are more flexible for sharing by record attribute rather than by who owns it.

Both types of sharing rules appear on the object’s Sharing Settings page. You create them by choosing New under the Sharing Rules section for the object. 

When defining an owner-based rule, you specify “Owned by members of [Role or Group X]” and share with [Role or Group Y]. For criteria-based, you specify “[Object].Field __ [equals/contains] __ Value” and share with users. In either case, you also choose the access level (Read Only or Read/Write).

Key configuration points:

– You can share with Public Groups, Roles, Roles & Subordinates, or Territories. (Public Groups are often used to simplify multiple sharing rules.)
– If you share with a Public Group, create that group first (Users → Public Groups).
– The Level of Access is chosen when building the rule: granting Read Only or Read/Write. (Note: granting Read/Write in a rule still requires the user’s profile to allow editing the object, sharing rules do not override object-level permissions.)
– After saving a rule, Salesforce recalculates access in the background (it may take minutes depending on data size).

Senior Salesforce administrators know to keep sharing simple. For predictable groups of users, sharing rules are ideal. If a sharing rule is configured so that records owned by users in Role X and everyone beneath that role in the hierarchy are shared with Role Y, then any record owned within that branch becomes eligible for access by Role Y. If the group of target users is dynamic or hard to predict (e.g. future hiring managers), manual sharing or a custom solution might be needed instead. Overall, sharing rules should cover “lateral” or non-hierarchical access needs.

Salesforce Sharing Rules and Role Hierarchy

Salesforce role hierarchy and sharing rules both grant additional access, but in different ways. By default, users higher in the role hierarchy automatically inherit access to records owned by users below them. In contrast, sharing rules allow users across roles or teams to see records they don’t normally inherit. In the layered model, sharing rules are applied after the role hierarchy grants its access.

For example, imagine two parallel sales roles (East and West) that do not report to each other. Neither VP can see the other region’s data just by hierarchy. A sharing rule lets the East VP see West Region accounts by explicitly sharing those records. In effect, sharing rules “break out” of the strict hierarchy, enabling cross-team visibility.

Note that granting access via roles and subordinates is itself a form of owner-based sharing rule. For instance, if a rule says “Owned by Role X and Internal Subordinates, share with Role Y”, then all members of Role X and their subordinates are sources of sharing. Conversely, you can “share with roles and subordinates” so all users in a branch receive access. The rules engine handles both: the owner side and share side each can include “and subordinates” if desired.

Also, person accounts and portal (Experience Cloud) users have special considerations with hierarchies: person accounts have their own internal sharing settings, and community/portal users with no role must use criteria-based or guest sharing rules instead of owner-based ones. In summary, think of role hierarchy as vertical sharing and sharing rules as horizontal/extensions. Together, they determine full access.

How to Share Person Accounts Using Sharing Rules

Person Accounts in Salesforce are a special type of Account with an associated Contact. To share personal account information, you treat them like any Account. In practice, this means setting the Account OWD to private/public-read, then creating a sharing rule on the Account object. For example:

Owner-Based: Share all Person Accounts owned by Sales Reps in Role X with Role Y.

Criteria-Based: If you have a custom field or record type marking certain person accounts, you could share where IsPersonAccount = True and CustomField = Value with specific groups.

Because a Person Account is technically an Account record, sharing the Account grants access to the full person’s record. Remember that Account sharing may also share related Contact info, based on the setting “Grant Access Using Hierarchies”. There is no separate “Contact” sharing for person accounts, you share the Account and the person data comes with it.

One additional tip: ensure the Grant Access Using Hierarchies for Accounts is enabled (it is by default for standard object records). Also, if your org uses contact OWD and person account roles, verify that the Contact: Account Sharing setting is configured so the person contact is shared when the account is shared. In short, treat person accounts as accounts for sharing rules. As with any sharing rule, changes take a few minutes to recalc, and you may want to document that person accounts are included in these rules.

How to Create Sharing Rules in Salesforce

Creating a sharing rule involves a few administrative steps in Setup. As a senior developer or consultant might advise, always plan your rule before building it:

Verify OWD

Go to Setup → Security Controls → Sharing Settings. Ensure the object’s OWD is Private or Public Read Only. If it’s Public Read/Write, change it back to a more restrictive setting, because sharing rules only have effect when OWD is limited.

Identify the Object

On the same Sharing Settings page, find the object (e.g. Account, Opportunity, Case) under “Sharing Rules” and click New.

Label and Description

Give the rule a clear Label (and API name). Use a concise description like “Share X records with Y users” so it’s obvious in the future.

Choose Rule Type

Select Owner-Based or Criteria-Based. Owner-Based is “Based on record owner” and Criteria-Based is “Based on criteria”.

Define Source (Who to Share)

• Owner-Based: Specify which owners’ records to share (e.g. “Owned by members of Role A or Public Group B”).
• Criteria-Based: Define the field criteria (e.g. “Case: Type equals High” or “Account: Region equals East”). Only select fields from the record; note that formula fields and certain other field types cannot be used in criteria.

Define Target (With Whom)

Choose who should get access: a Public Group, a Role (and subordinates), Roles & Subordinates, or Territories. For example, “Share with Role:East VP and Subordinates”. If using a Public Group, create that group first via Users → Public Groups.

Set Access Level

Decide Read Only or Read/Write for the share. Remember, Read/Write still requires the user’s profile to allow edits.

Save and Recalculate

When saved, Salesforce will recalc access for all affected records. Larger data volumes can take longer; Salesforce will email when it’s done.

Below is an example label: “Share Eastern Region Accounts with Western VP”. This would be an owner-based rule on Account, owned by Role=East Sales, sharing with Role=West VP. Once active, any new account owned by an East rep is automatically shared with the West VP’s team.

Portal/Experience Users: If you share data with external users (Community or site guest users), note: high-volume portal users typically do not have roles. Therefore you cannot use an owner-based sharing rule for them. Instead use criteria-based rules or Guest user sharing rules specifically. For example, to share records with a site guest user, you might make a “Guest user access, based on criteria” rule.

Sharing Rules in Marketing Automation Architectures

When implementing Marketo Salesforce integration, sharing rules directly influence lead and contact visibility across sales teams. If Salesforce OWD is private and sharing rules distribute ownership by region or business unit, those same boundaries must be respected when marketing-qualified leads sync into CRM. Without alignment between sharing rules and marketing automation logic, records may be enriched or reassigned in ways that unintentionally expand visibility. Security architecture must therefore be validated before enabling bi-directional sync between systems.

Sharing Rules in Work Management Synchronization 

In a monday.com Salesforce integration, Opportunity or Account data is frequently pushed into external project boards. The integration user typically operates with a defined role and sharing access. If Salesforce sharing rules grant broader access than intended, the integration layer may transmit records beyond the scope of a single department. Reviewing owner-based and criteria-based sharing logic before exposing CRM data to operational tools prevents unnecessary cross-functional data exposure.

Sharing Rules and Document Security Alignment 

Within a SharePoint Salesforce integration, document libraries often reflect Account or Case visibility from Salesforce. However, Salesforce sharing rules and SharePoint permission models operate independently. If CRM sharing rules grant access to a record but document permissions are not synchronized accordingly, inconsistencies arise. In regulated environments, misalignment between record-level sharing and document access can create audit risks. Integration design must reconcile both security models to maintain consistent visibility controls.

Sharing Rules in Data Enrichment and Outbound Platforms

With Apollo Salesforce integration, enriched leads and Accounts may be inserted or reassigned automatically. When ownership changes occur through automation, Salesforce sharing rules immediately recalculate access based on the new role placement. If the ownership model is not carefully designed, enriched records can become visible to unintended teams. Reviewing sharing rules before enabling automated reassignment flows ensures that enrichment logic does not override established visibility boundaries.

Sharing Settings and Additional Considerations

Salesforce Sharing Settings offer more than just sharing rules. Key points:

Activities (Tasks/Events) Sharing

By default, Activities use “Controlled by Parent” sharing. This means a Task inherits access from its related record (if any). Importantly, you cannot create sharing rules for Tasks or Events. There is no separate View All for Tasks, and no sharing rule component on Activities. The workaround is to ensure tasks are linked to records that the user can see, or use manual/Apex sharing. In short, only Accounts, Cases, etc. support sharing rules (Tasks do not) because tasks are always tied to a parent record’s sharing.

Formula Fields

As mentioned, you cannot use formula fields in the criteria for a sharing rule. The UI will not let you pick them. If you need to share based on a calculated condition, one approach is to create a standard field (Text or Picklist) and copy the formula’s output into it (via Workflow, Process Builder or Flow). Then use that standard field in your sharing rule criteria.

Sharing Rules Limits

Salesforce enforces limits on sharing rules per object. By default you can create up to 300 total sharing rules per object, and up to 50 criteria-based sharing rules per object. (The other rules would be owner-based.) These limits can be increased by contacting Salesforce support (up to 500 total rules and 200 criteria rules), but complex sharing can hurt performance. Salesforce recommends keeping sharing rule counts well below the limits (e.g. under ~100 rules) for optimal performance.

Related Records Exposure

Be aware that sharing one record can inadvertently share related records. For example, sharing an Opportunity might also share its parent Account if the user didn’t already have account access. Similarly, sharing a Case or Contact can open access to the associated Account. This can be useful or surprising, so verify related sharing (see ‘Related Record Access’ settings and documentation).

Company Note

In complex integration and transformation programs, data access architecture must be treated as a first-class design component rather than a downstream configuration task. Any mature Salesforce integration service engagement should explicitly evaluate how sharing rules, role hierarchy, and public group structures will translate across environments. When synchronizing data between multiple orgs or external systems, the destination security model must replicate or intentionally redesign existing sharing logic to avoid unintended access gaps or overexposure. Integration teams frequently need to reconcile differences in role structures and group definitions while preserving compliance and audit integrity. Clear documentation of each sharing rule and its functional intent is essential for long-term governance and operational stability.

Metadata Deployment

Sharing rules can be deployed via the Metadata API. In the object’s metadata, you’ll find <sharingRules> entries (OwnerBasedSharingRule and CriteriaBasedSharingRule elements). This is useful for moving rules between sandbox and production. The XML allows you to script or version-control sharing rules if needed.

Best Practices and Troubleshooting

A senior Salesforce developer keeps the sharing model maintainable:

• Use Public Groups: Instead of writing a separate rule for every role, put users into public groups and share with the group. This reduces rule count and makes future changes easier.
• Watch “Modify All” and “View All”: Some profiles have View All or Modify All on objects. Those permissions override sharing rules (they ignore sharing), so only use them when appropriate.
• Review Rule Prioritization: If multiple rules grant different access levels, the most permissive wins (Read/Write > Read Only).
• Document Your Model: Include role hierarchies, OWD settings, and all sharing rules in your system documentation. This helps anyone (admins, auditors, developers) understand who should see what.
• Monitor Performance: Too many sharing rules can slow data operations. If you notice insert/update delays, check the sharing recalculation queue and consider simplifying.

If a sharing rule isn’t working as expected: – Verify the user isn’t already restricted by profile/permission sets. – Check that the user is actually in the target group (role or public group). – Remember to wait for the recalculation to finish. For large orgs, changes can take a few minutes to an hour.

If tasks or activities aren’t visible as expected, recall that Activities don’t use sharing rules, they rely on the parent record’s access or owner.

Final Thoughts

In summary, Salesforce Sharing Rules are a powerful, declarative way to open up record access in your org based on ownership or record criteria. When OWDs are private or read-only, sharing rules let you grant read or write permissions to groups of users without altering the role hierarchy. As a senior Salesforce developer, you’ll implement owner-based or criteria-based rules to cover common use cases (regional data sharing, customer support teams, community users, etc.). Keep in mind the limits (300 rules per object, 50 criteria rules) and the restrictions (no formula fields, no task rules). Done properly, sharing rules, along with OWD, roles, and profiles, form a clear, scalable security model that keeps data secure yet accessible. Salesforce Sharing Rules enable fine-grained collaboration by automatically sharing records with the right people, bridging gaps in the role hierarchy while maintaining the baseline access model.