Salesforce Basics: Sharing Rules (Owner-Based vs Criteria-Based)

💬 In plain words: Sharing rules are standing "open the door" instructions: owner-based ('records owned by Team A → visible to Team B') or criteria-based ('all records where Region = North → visible to North group'). They only widen access, never narrow it.

📌 Example: 'Records owned by Delhi Sales team → share read-only with Delhi Support team' = owner-based rule. 'All Accounts where Region = North → visible to North group' = criteria-based. Both only ADD access.

Concept

Sharing rules open access sideways, where the role hierarchy cannot reach.

• An owner-based rule shares records owned by one group or role with another group or role.
• A criteria-based rule shares records that match specific field values, no matter who owns them.
• Three core constraints: They can only widen access, never restrict it (restriction is handled by Restriction Rules). They share to public groups, roles, and territories — never to individual users. Their recalculation runs asynchronously whenever rules or memberships change.
• Limits matter in design: Each object gets a bounded number of rules, with a smaller sub-cap for criteria-based ones. Criteria-based rules do not scale infinitely as an access-control language.

🧠 Groups, never people: Sharing rules share TO groups/roles, never to individual users. Criteria-based re-evaluates on edit → avoid volatile fields.

🧭 360 Card — Sharing Rules

Rule: Owner-based when access follows ownership. Criteria-based when a field decides visibility.

Gain: Standing, declarative access. It maintains itself automatically as records and owners change.

Reach for: An owner-based rule first, when access follows record ownership. A criteria-based rule when a FIELD decides visibility instead. Reach for Apex managed sharing only when the grant is calculated per record. Remember that only 50 criteria-based rules are allowed per object.

Price: Rules share to groups and roles, never to an individual user. A criteria-based rule re-evaluates on every edit of its criteria field.

Limits: Approximately 300 sharing rules per object, but only 50 of those may be criteria-based. Hitting the ceiling is an architectural design smell, not a reason to call Support.

Mirror — Apex managed sharing: Expresses per-record, calculated access that no standard rule can state. The cost is code maintenance that you now own.

Later: Your public group design determines how far sharing rules can stretch. Smart group design collapses dozens of near-identical rules into a few.

At volume: Editing a sharing rule triggers an org-wide recalculation that locks group membership and share tables. Never edit rules during a major data load.

Core Q&A

Q: When do you choose a criteria-based sharing rule vs owner-based, and when do you reject sharing rules entirely?

🎯 Say this first: Owner-based when teams are defined by ownership. Criteria-based when a field defines visibility. When access follows per-record choices, rules cannot help — that is Apex managed sharing.

A: Use owner-based when access follows organizational ownership — e.g., "EMEA sales records visible to EMEA service".

• Use criteria-based when access follows the data itself — "all records where Region = APAC visible to APAC ops" — and only when the criteria fields are stable.
• Criteria-based rules re-evaluate whenever a record is edited, so a volatile field causes constant background recalculation.
• Reject sharing rules in two key cases:
• First, when the logic is per-record and dynamic: "share with the approvers named on this specific record". That requires Apex managed sharing.
• Second, when you are about to create dozens of criteria rules to emulate an attribute matrix. You will hit rule limits, and nobody will be able to audit it properly.
• At that point, redesign using Public Groups fed by an automated background job, or leverage Territory Management.
• Meta-answer: Sharing rules are declarative configuration meant for coarse, stable access patterns.

Follow-ups (Scenario-Based)

Q1: You kick off a 5M-record data load and admins simultaneously edit sharing rules; loads start failing with lock errors. What is happening and what is the operational fix?

A1: A sharing rule change triggers an org-wide sharing recalculation, locking group-membership and share tables while the data load writes row-level sharing simultaneously. The two operations collide, causing UNABLE_TO_LOCK_ROW errors.

• Fix 1: Freeze sharing, role, and group changes during data load windows.
• Fix 2: Enable Defer Sharing Calculations: suspend calculations, load the data, resume, and recalculate once at the end.
• Fix 3: Load in PK-chunked batches with parallelism reduced on skewed data, and use Bulk API Serial Mode for lock-prone objects.
• Architect Note: This scenario connects sharing architecture directly to cutover planning and deployment operations.

Q2: A bi-directional ERP integration processes 10,000+ records daily under an integration user. How does that interact with the sharing model?

A2: There are two core architectural decisions to make:

• Records created or updated by the integration user must land with the correct business owner immediately (assigned via payload or assignment logic). Do not let records pile up under the integration user.
• Piling up records under one user creates ownership skew and a visibility gap that standard sharing rules cannot easily fix.
• The integration user itself needs access through a dedicated profile and permission set model. Where required, add an owner-based rule sharing integration-owned staging records with the operational group monitoring for failures.
• Re-owning records intentionally to prevent ownership skew demonstrates real-world enterprise operations experience.

Q: You are running out of sharing rules on an object. What now?

🎯 Say this first: A sharing-rule ceiling is a design smell. Re-group before you raise limits.

A: System limits default to roughly 300 total sharing rules per object, with a strict cap of 50 criteria-based rules.

• Before contacting Salesforce Support to request higher limits, audit the design pattern driving rule sprawl.
• Dozens of rules differing only by region can usually be consolidated into a few rules using well-structured Public Groups or the Role Hierarchy.
• If access is genuinely per-record and rule-shaped logic cannot express it, transition to Apex managed sharing where code programmatically writes share rows directly from data values.

Q (compare): When is Apex managed sharing the right call rather than a workaround?

A: When access is calculated dynamically rather than being static. For example, "the assigned auditor and their reviewer see this record" is driven by record fields rather than static user groups. Code inserts share rows using a custom Apex Sharing Reason, keeping the access intent named, auditable, and durable across owner changes on custom objects.