Owner-Based and Criteria-Based Sharing Rules

Why This Topic Is Important
Sharing rules sit at the heart of the Salesforce security model. Once Organization-Wide Defaults (OWD) restrict a record, administrators need a predictable, automated way to open access back up for the right people. Sharing rules are that mechanism. On the Advanced Administrator exam, the Advanced Security and Access domain regularly presents scenario questions where you must pick the correct sharing tool, and distinguishing owner-based from criteria-based rules is one of the most frequently tested distinctions. Misunderstanding this area leads to over-sharing (compliance risk) or under-sharing (users blocked from their work), so it matters both in the exam and in real orgs.

What Sharing Rules Are
A sharing rule is a declarative, automatic exception to the OWD that extends record access to a group of users. Key characteristics:
• They can only grant access, never restrict it. If OWD is already Public Read/Write, a sharing rule adds nothing.
• They are only relevant when the OWD for an object is Private or Public Read Only (or Controlled by Parent for some objects via the parent).
• Access is shared with public groups, roles, roles and subordinates, roles and internal subordinates, territories, or territories and subordinates. You cannot share with an individual user directly through a sharing rule (use a public group containing that user instead).
• The access level granted can be Read Only or Read/Write. For Accounts, you also specify access to related Contacts, Opportunities, and Cases.
• Sharing rules bypass the role hierarchy direction; they can share sideways or downward.
• Limits: up to 300 sharing rules per object, of which up to 50 can be criteria-based (these counts include ownership-based and guest-user rules; check current documentation as limits evolve).

Owner-Based Sharing Rules
An owner-based (ownership-based) sharing rule shares records based on who owns them. The logic is: "Records owned by users in Group/Role A are shared with users in Group/Role B at access level X."
Example: Records owned by the EMEA Sales role and subordinates are shared Read/Write with the EMEA Sales Support public group.
Use cases:
• Teams that need to see each other's records regardless of field values.
• Sharing across branches of the role hierarchy (e.g., Sales owners share with a Service team).
• Sharing records owned by queues: owner-based rules can specify a queue as the source of ownership.
Behavior notes:
• Recalculation occurs when ownership changes or when group/role membership changes.
• Works with records owned by users, queues, or (for some objects) portal/community roles.

Criteria-Based Sharing Rules
A criteria-based sharing rule shares records based on field values on the record itself, regardless of who owns them. The logic is: "Records where Field = Value are shared with Group/Role B at access level X."
Example: Cases where Priority = High and Type = Escalation are shared Read/Write with the Escalation Managers public group.
Rules and constraints:
• Supported field types for criteria include text, number, currency, date, date/time, checkbox, picklist, lookup (to user, record ID), auto number, email, phone, URL, and formula fields that return a supported type. You cannot use long text area, multi-select picklist, or formula fields that reference other objects, roll-up summaries, or currently running user context.
• Record type can be used as a criterion.
• Criteria evaluation is case-sensitive for text in some contexts; be precise when designing.
• Criteria-based sharing rules are available on accounts, opportunities, cases, contacts, leads, campaigns, custom objects, and several others, but not on every object (e.g., not on Users via standard sharing rules; user sharing uses its own criteria-based mechanism).
• Recalculation occurs when a record is created or edited so that it meets or no longer meets the criteria.
• Criteria-based rules do not consider the owner at all; a record can be shared to its own owner redundantly without issue.

How Sharing Rules Fit With Other Tools
• OWD sets the baseline; sharing rules open it up.
• Role hierarchy grants vertical (upward) access automatically if "Grant Access Using Hierarchies" is enabled (always on for standard objects).
• Manual sharing is a one-off, user-driven exception for a single record and single user/group; it is lost on owner change.
• Apex managed sharing handles logic too complex for declarative rules (e.g., sharing based on related records or dynamic calculations).
• Teams (Account, Opportunity, Case Teams) share individual records with ad hoc members.
• Territory management adds territory-based sharing for accounts and related records.
• Restriction rules and scoping rules narrow visibility; sharing rules never do.

Step-by-Step: How They Work in Practice
1. Set the object's OWD to Private or Public Read Only.
2. Navigate to Setup > Sharing Settings, scroll to the object's Sharing Rules section, click New.
3. Choose rule type: Based on record owner or Based on criteria.
4. For owner-based: pick the owning group/role/queue. For criteria-based: define field, operator, value (up to a set number of criteria lines with optional filter logic).
5. Select the users to share with (public group, role, role and subordinates, territory).
6. Choose access level (Read Only or Read/Write; Accounts also require related object access choices).
7. Save; Salesforce recalculates sharing. Large orgs may defer sharing calculations and recalculate later.

Exam Tips: Answering Questions on Owner-Based and Criteria-Based Sharing Rules
• Read for the trigger. If the scenario says "records owned by the X team should be visible to Y," think owner-based. If it says "records with Region = West" or "high-priority cases," think criteria-based.
• Check the OWD first. If the OWD is already Public Read/Write, the answer is never "create a sharing rule" to grant access. If the question asks how to restrict access, sharing rules are wrong; look for OWD, restriction rules, or permission adjustments.
• Individual users are a trap. Sharing rules cannot target a single user. If the correct design shares with one person, either create a public group or use manual sharing.
• Field type eliminations. If the criterion depends on a multi-select picklist, long text area, roll-up summary, or a field on a related object, criteria-based sharing is not possible; the answer is usually Apex managed sharing or a formula/workflow-populated helper field.
• Related-object logic signals Apex. Sharing a Contact based on a value on its Account, or an Opportunity based on the owner's manager, generally exceeds declarative rules.
• Queue ownership. When records are owned by a queue and other users need access, owner-based sharing from the queue is a valid declarative answer.
• Access levels. Remember sharing rules offer Read Only or Read/Write, never Full Access, Transfer, or Delete rights. If a scenario needs delete capability, the answer involves ownership, profile/permission set "Modify All," or role hierarchy above the owner.
• Limits matter. If a question mentions needing more than 50 criteria-based rules on one object, the intended answer is to consolidate criteria, use public groups, or move to Apex sharing.
• Recalculation and performance. Questions about slow saves or needing to defer calculations point to the Defer Sharing Calculations feature in large orgs.
• Role hierarchy interplay. Users above the owner in the hierarchy already see records (for standard objects). Don't choose a sharing rule to give a manager access to subordinates' records; it's already there. For custom objects, check whether Grant Access Using Hierarchies is enabled.
• Manual sharing vs. sharing rules. Manual sharing is one record at a time and removed on owner change; sharing rules are automatic and persist. Scenario words like "ongoing," "automatically," or "all records" favor sharing rules; "this one deal" favors manual sharing or teams.
• Eliminate distractors systematically. Typically one option over-shares (changing OWD to Public), one under-delivers (manual sharing for many records), one is technically impossible (sharing to a single user, unsupported field), and one is correct. Test each option against the facts in the scenario.

Quick Comparison
• Trigger: Owner-based = who owns the record; Criteria-based = field values on the record.
• Source: Owner-based = groups, roles, roles and subordinates, queues, territories; Criteria-based = filter criteria on supported fields.
• Target: Both = public groups, roles, roles and subordinates, territories.
• Access: Both = Read Only or Read/Write (plus related object access for Accounts).
• Recalculation: Owner-based on owner/membership change; Criteria-based on field value change.
• Limits: Up to 300 total per object, up to 50 criteria-based.

Summary
Owner-based and criteria-based sharing rules are declarative ways to widen record access beyond the OWD. Owner-based rules key off record ownership; criteria-based rules key off field values. Neither can restrict access, neither can target a single user, and both are limited to Read Only or Read/Write. On the exam, identify the trigger (owner vs. field), confirm the OWD actually restricts access, check for unsupported fields or related-object logic, and rule out options that over- or under-share. Master these distinctions and you will handle the majority of sharing-rule scenarios with confidence.