💬 In plain words: A user needs two separate grants before an agent is useful to them. One lets them use the agent at all. The other lets the agent reach data. They fail in completely different ways. 📌 Example: A Meridian rep is granted every object the agent touches, but not Agent Access. The agent simply does not appear for them. Nothing is wrong with the data model. 🎬 Real-Life Example: The Agent Nobody Could Find The Old/Bad Way: An admin built an agent, activated it, tested it in preview, and told the team it was live. Nobody could see it — including the admin, outside preview. Why this fails: Agent Access is a separate grant inside a permission set. Building an agent does not grant you the right to use it. Preview bypasses this, which is exactly why the gap goes unnoticed. The New/Good Way: 1. In the permission set, find the Agent Access section. 2. Add the specific agent to the enabled list. 3. As...
💬 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 hierarchy cannot reach.
• An owner-based rule shares records owned by one group or role with another group.
• A criteria-based rule shares records that match field values, no matter who owns them.
• Three constraints define them. They can only widen access, never restrict it — restriction is what Restriction Rules do, covered in 3.4. They share to public groups, roles and territories, never to individual users. And their recalculation runs asynchronously whenever the rules or the memberships change.
• Limits matter in design. Each object gets a bounded number of rules, with a smaller sub-cap for criteria-based ones. So criteria-based rules do not scale as an access-control language.
.png "Sharing Rules (Owner-Based vs Criteria-Based)")
🧠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 as records and owners change.
Reach for: an owner-based rule first, when access follows who owns the record. A criteria-based rule when a FIELD decides visibility instead. Reach for Apex managed sharing only when the grant is calculated per record. And remember only fifty criteria-based rules are allowed per object.
Price: rules share to groups and roles, never to one user. And a criteria-based rule re-evaluates on every edit of its criteria field.
Limits: about 300 sharing rules per object. Only fifty of those may be criteria-based. Hitting the ceiling is a design smell, not a reason to call Support.
Mirror — Apex managed sharing: expresses per-record, calculated access that no rule can state. The cost is code you now own.
Later: your public group design decides how far rules can stretch. Smart groups collapse dozens of near-identical rules into a few.
At volume: editing a sharing rule starts an org-wide recalculation that locks the group and share tables. Never do it during a big 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 — '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 recalculation.
• Reject sharing rules in two cases.
• First, when the logic is per-record and dynamic: 'share with the approvers named on this record'. That is Apex managed sharing.
• Second, when you are about to create dozens of criteria rules to emulate an attribute matrix.
• You will hit the rule limits, and nobody will be able to audit it.
• At that point, redesign with public groups fed by a nightly job, or with territories.
• The meta-answer: sharing rules are configuration 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 recalculation. That recalculation locks the group-membership and share tables.
• Meanwhile the load itself is writing row-level sharing.
• The two collide, and you get UNABLE_TO_LOCK_ROW.
• Four fixes. Freeze sharing, role and group changes during the load window.
• Enable Defer Sharing Calculations: suspend, load, resume, and recalculate once.
• Load in PK-chunked batches, with parallelism turned down on skewed data. And use the Bulk API's serial mode for the lock-prone objects.
• This scenario is a favorite in architect rounds, because it joins Module 3 to the cutover planning in Module 11.
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 decisions here.
• First, records the integration user creates or updates must land with the correct business owner straight away.
• Assign the Owner in the payload, or through assignment logic.
• Do not let records pile up under the integration user.
• If you do, you get ownership skew AND a visibility gap that no sharing rule reaches.
• Second, the integration user itself needs access, through a dedicated profile and permission-set model.
• Where it is needed, add an owner-based rule that shares integration-owned staging records with the ops group that watches for failures.
• Saying that you re-own records on purpose, to avoid skew, shows you have operated an integration at 10k a day — not just designed one.
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: The defaults are about 300 sharing rules per object, and only fifty of those may be criteria-based.
• Before you call Support to raise the ceiling, look for the pattern behind the sprawl.
• Dozens of rules that differ only by region usually collapse into a few rules over smarter public groups, or into the role structure itself.
• If access is genuinely per record. And rule-shaped logic cannot express it, move to Apex managed sharing, where code writes the share rows from the data.
Q (compare): When is Apex managed sharing the right call rather than a workaround?
A: When access is calculated, not stable. "The assigned auditor and their reviewer see this record" is driven by fields, not by groups. Code inserts share rows with a custom Apex sharing reason. So the intent is named and auditable. And on custom objects those rows survive an owner change — unlike manual shares.