⚡ 1-Minute Summary • Instructions resolve top to bottom. Logic lines run. Prompt lines become English. • The model never sees your script. It sees only the finished prompt your logic built. • Shorter reasoning instructions produce more accurate agents. Verbosity is not thoroughness. Module map MODULE 2 root: 'What actually happens in one turn?' ├─ 2.1 Anatomy of one turn ├─ 2.2 How the prompt gets built └─ 2.3 Why shorter instructions win Anatomy of One Turn 💬 In plain words: Every message follows the same seven steps: router, before-reasoning, instructions, model, tools, after-reasoning, reply. Learn this sequence and every design decision in Agentforce explains itself. 📌 Example: A Meridian customer says "is my power back yet?". The router picks the outage subagent. Before-reasoning verifies their meter. Instructions run a status action and branch. The model phrases the answer. After-reasoning logs the contact. Co...
💬 In plain words: Everything else in sharing only ADDS access. Restriction Rules are the one tool that SUBTRACTS. They filter which records a user can see even if sharing granted them. Scoping rules just change the default view, not real access. Implicit sharing is built-in glue (see the Account, see its child Cases).
📌 Example: Contractors log time in Tasks, but must not see employees' tasks. OWD change would hurt everyone — instead one Restriction Rule on the contractor permission set: 'you see only Tasks where OwnerId = you'. Everyone else unchanged.
🎬 Real-Life Example: The Contractor Who Saw Too Much Hub contractors log in to update deliveries for their own hub. But role hierarchy and sharing rules keep granting them a wider view — other hubs, other cities.
The Old/Bad Way: Try to fix it with more sharing configuration. Hours of tweaking, no result. Because sharing can only ADD access. Nothing in OWD, roles, or sharing rules can take access away from someone who already has it.
Why this is bad: You are pushing on a door that only opens outward. The model is additive by design; fighting that with more grants makes the org harder to reason about, not tighter.
The New/Good Way:
1. Create a Restriction Rule on Delivery__c.
2.
User criteria: the contractor permission set.
3. Record criteria: Hub__c equals
the user's hub.
4. For those users, every non-matching record simply disappears
— from lists, reports, lookups, and APIs.
The payoff: Sharing adds. Restriction Rules subtract — the only subtractor in the whole model. Reach for them when the problem is "they see too much", not "too little".
🧠The only subtractor: Everything in sharing ADDS access. Restriction Rules are the one tool that SUBTRACTS. Say that line first.
Concept
Restriction Rules are the platform's only subtractive record-security tool.
• Per object, they filter which records a targeted set of users can SEE at all — in queries, list views, reports and related lists — on top of whatever sharing already granted.
• Scoping Rules look similar, but they are UX, not security.
• They set the default scope a user sees, while the user can still reach everything sharing allows.
• Implicit sharing is built-in parent/child behavior on the CRM core.
• Read access to a child Case, Opportunity or Contact confers read access to the parent Account.
• Account access can confer access to the children, depending on settings.
• You cannot turn it off, and it surprises people in security reviews.
• Restriction Rules connect back to OWD strategy. They let you keep a permissive OWD and still carve out a restricted subset.
🧠360 Card — Restriction, Scoping & Implicit
Rule: sharing adds. Restriction rules subtract. Scoping rules only change the default view.
Gain: a way to give one group less than everyone else, without touching OWD and resharing the whole org.
Price: restriction rules are absolute. They hide records from reports, related lists and even lookups. People report that as data loss.
Limits: two active rules per object in Enterprise and Developer editions. Five in Performance and Unlimited. For any one user, only one restriction or scoping rule per object can be true. They work on custom objects, external objects, contracts, tasks, events, quotes and time sheets. Not on Account, Contact or Opportunity. Filters only, with no AND or OR. Implicit sharing is built in and cannot be switched off. Scoping rules change what is shown, not what is reachable.
Mirror — tightening OWD instead: correct in principle. It also changes access for every user type at once, plus a full recalculation.
Later: document restriction rules next to the OWD settings. Otherwise the next architect debugs them as a bug, not a rule.
At volume: implicit sharing is where surprise access usually comes from. It grows with every child record added under a parent.
⚠ INTERVIEW TRAP: Do not design one restriction rule per team. You get 2 per object in Enterprise and Developer. The rule must be generic and driven by a user field.
Core Q&A
Q: Give a scenario where a Restriction Rule is the right tool rather than tightening OWD, and state its limits.
🎯 Say this first: Use them when one group must see LESS than everyone else. Restriction rules subtract.
A: Take contract staff who must see only their own Tasks, in an org where Task visibility is otherwise broad.
• Flipping OWD would break every other user type and set off a massive resharing job.
• Instead, write one Restriction Rule targeting the users who hold the contractor permission set. Its recordFilter is OwnerId = $User.Id. It subtracts exactly their visibility and touches nobody else.
• State the limits. There is a small per-object cap on active rules — single digits.
• The filter syntax is simple only.
• The supported object list is limited: Tasks, Events, Contracts, custom objects, and a growing set.
• And it affects reports — records vanish from the contractors' report results, which the business has to sign off on.
• Bonus point: restriction rules also apply to users who hold View All on the object. That is exactly why they exist.
Follow-ups (scenario-based)
Q1: A service agent can see an Account they were never shared. Sharing audit shows nothing on AccountShare. Where does the access come from?
A1: This is implicit parent sharing.
• The agent has access to a Case — or an Opportunity, or a Contact — under that Account. That access grants implicit Read on the parent Account.
• These grants do not show up as the rows you would expect in a share-table audit, because the platform maintains them internally.
• The reverse direction exists too. Account team or owner access flows down to the children, depending on the account's settings.
• In a security review you have to document implicit sharing explicitly, because you cannot disable it.
• If the parent truly must be hidden, then the child access itself has to be redesigned.
Q2: Auditors demand that lab technicians see only assessments for their own lab, in an org where assessments are Public Read Only. What is the least-disruptive design?
A2: Put a Restriction Rule on the assessment object, targeting the technician user type.
• Filter on the record's Lab__c matching the technician's lab, which you stamp on a user field.
• OWD stays as it is. Every other user type is untouched.
• No resharing storm, no rule sprawl.
• Two trade-offs to flag to the auditors.
• Technicians' reports and list views now show only their own lab, which is what you wanted.
• And the rule cap means you have just spent one of a very small budget of rules on this object. So the lab-match design has to be generic — one rule, driven by a user field.
• Common mistake: one rule per lab. That is the trap this question fishes for.
Q: Explain implicit sharing and where it bites a design.
🎯 Say this first: Access to an account quietly drags related access with it — in both directions.
A: It runs two ways. Parent implicit sharing: if you can see a contact, case or opportunity, you get read access to its parent account automatically. Child implicit sharing: the account owner gets access to child records, governed by the role’s settings for contacts, cases and opportunities. It is built in and cannot be switched off. So a "Private accounts" design can still leak account names through child records if nobody maps it.
Q: How does this change for Experience Cloud users?
A: External users have no role hierarchy in the internal sense, so implicit sharing plus sharing sets do the work. A sharing set grants a community user access to records related to their own account or contact. For cross-account partner visibility, use share groups and super user access. And set the separate external org-wide defaults to Private first (18.3).
Q: What is the danger with restriction rules?
A: They are absolute. A bad restriction rule hides records from reports, from related lists. And even from lookups. And people debug that as data loss, not as a rule. Keep them few. Test them per persona. And document them next to the OWD settings. So the next architect finds the one tool in the model that subtracts.