Companion to 09_Topic09_Admin_Basics.md — open ONLY after you have written your own attempt.

Protocol (file 00, M1→M4): write ≥2 hypotheses + 2 solution attempts before reading. Then compare your attempt against this sheet like an investigator compares a suspect's story to the evidence. The contrast IS the learning. Then REDO from memory, then do the drill.

INCIDENT 1 — THE LAYOUT THAT THOUGHT IT WAS A LOCK

The problem restated

A Record Type + layout hid a sensitive field from one page, but the field leaked via reports/list views/API. What does a Record Type actually control, and what's the real fix?

Model answer (2-min interview version)

• What Record Types control: picklist values, page layout assignment, and business process (Support/Sales/Lead process) per record — nothing about access.
• What they never control: object permissions, FLS, or record-level sharing.
• Why the leak happened: layout hiding is UI-only for one rendered page; every other surface (list views, related lists, Kanban, reports, dashboards, Global Search, Chatter, SOQL, REST/Bulk API, Data Loader exports) reads based on FLS, not layout assignment.
• The real fix: set Field-Level Security on the sensitive field to "None" for every profile except the authorized team's profile/permission set — enforced everywhere. If the whole record (not just the field) needs restriction, that's OWD + sharing rules, not Record Types.
• The one-liner: "Profiles handle permissions, Roles handle record visibility, Record Types handle picklist/layout/process differentiation — not visibility at all."

Self-grade checklist

• Named the 3 things Record Types control (picklist values, layout, business process)
• Stated Record Types never control access
• Explained layout-hiding is UI-only; leaks via reports/list views/API/SOQL
• Named FLS as the fix that hides everywhere
• Named OWD + sharing rules as the fix for whole-record restriction

THE REDO — model answer

Record Type controls: picklist values, layout assignment, business process
Record Type never controls: CRUD, FLS, record sharing
Leak path: layout hides 1 page; reports/list views/API/SOQL ignore layout, read FLS
Fix: FLS = "None" except authorized profile/permission set (field-level)
     OWD + sharing rule (record-level, if the whole record must be restricted)

RETRIEVAL DRILL — model answers

1. Three things Record Types control? → Picklist values, page layout assignment, business process.
2. Do Record Types ever restrict read/write access? → No.
3. Why does layout-hiding fail against reports/list views/API? → Those surfaces render based on FLS, not the record's layout assignment — the layout is bypassed entirely.
4. What hides a field everywhere, not just one layout? → Field-Level Security (FLS).
5. What restricts an entire record, not just a field? → OWD + sharing rules (record-level sharing).

INCIDENT 2 — THE DELETE THAT SLIPPED PAST THE GUARD

The problem restated

A validation rule meant to protect Closed Won Opportunities let 40 records be bulk-deleted with zero errors. Why, and what's the real control?

Model answer (2-min interview version)

• The rule: validation rules fire on create and update only (including the relevant half of upsert) — never on delete or undelete. No configuration changes this; it's a platform behavior.
• Why nobody noticed: the rule correctly blocked field edits on Closed Won records — its actual job — and the team's mental model silently expanded to "protects Closed Won records" instead of the narrower truth ("blocks specific field changes on create/update").
• The real control: an Apex before delete trigger (Trigger.oldMap, .addError()) is the only mechanism that can conditionally intercept a delete — declarative validation rules structurally cannot. Pair with tightening the Delete object permission on the relevant profile (remove it from general sales/ops profiles, grant only via a scoped permission set).
• Defense in depth: Field History Tracking / Shield Event Monitoring on deletes + a scheduled reconciliation report to catch a slip within hours.

Self-grade checklist

• Stated validation rules fire on create/update only, never delete/undelete
• Explained why the team's mental model was wrong (protects edits, not existence)
• Named Apex before delete trigger as the only conditional-block mechanism
• Named object-permission tightening (revoke Delete) as the durable fix
• Mentioned $Profile.Name scoping and/or detection (Field History/Event Monitoring) as bonus

THE REDO — model answer

Validation rules fire on: create, update (incl. upsert's relevant half)
Validation rules never fire on: delete, undelete
Block a conditional delete: Apex before-delete trigger + Trigger.oldMap + addError()
Durable fix: revoke Delete object permission from general profiles; grant via scoped permission set
Detection: Field History Tracking / Shield Event Monitoring + reconciliation report

RETRIEVAL DRILL — model answers

1. Which two DML operations fire validation rules? → Create and update.
2. Do validation rules fire on delete or undelete? → No, neither.
3. How do you conditionally block a delete? → Apex before delete trigger with .addError() — declarative tools can't express delete-time conditions.
4. Global variable to scope a rule by profile? → $Profile.Name (also $Permission).
5. Cheapest durable fix for "too many people can delete"? → Revoke the Delete object permission from the general profile; grant only via a scoped permission set to roles that need it.

INCIDENT 3 — THE SHARING RULE THAT SHARED WITH NO ONE

The problem restated

A queue's own members couldn't see records auto-assigned to their queue because a sharing rule targeted a non-existent/misconfigured public group with the same name. What's the groups-vs-queues fix?

Model answer (2-min interview version)

• The one-liner: "Groups are for sharing, queues are for ownership." A Queue is a valid record owner — its members get access via ownership (subject to OWD), and it also routes/assigns work. A Public Group is purely a sharing target — referenced by sharing rules, manual sharing, report/folder access.
• Why a sharing rule can't target a queue: the "Share with" field only lists Roles, Public Groups, Territories, Roles-and-Subordinates — a Queue is never a valid target because it's a different metadata object entirely.
• Root cause here: a name collision — "VIP Escalations" the queue and "VIP Escalations" the (missing/misconfigured) group are unrelated records; Setup never validates that a typed/selected name maps to the intended entity.
• The fix: (1) verify the OWD-driven access path first — queue ownership under Private/Public-Read-Only OWD should already grant queue members access without a sharing rule; (2) create a real Public Group with actual member list for any visibility needs beyond the queue's own members (managers, other teams, dashboards); (3) never reference a queue name in a sharing rule target.

Self-grade checklist

• Stated the groups-vs-queues one-liner cold
• Confirmed queues are never a valid sharing-rule target
• Explained queue ownership already grants member access (subject to OWD)
• Identified the name-collision root cause
• Gave the corrected design (verify OWD path, real public group, correct target)

THE REDO — model answer

One-liner: groups are for sharing, queues are for ownership
Sharing rule "Share with" targets: Roles, Public Groups, Territories, Roles-and-Subordinates
                                    (never Queues)
Root cause: name collision — queue "VIP Escalations" ≠ group "VIP Escalations" (missing/wrong)
Fix: verify queue-ownership access under current OWD first
     create real Public Group with actual members for non-owner visibility needs
     reference the group, never the queue, in any sharing rule

RETRIEVAL DRILL — model answers

1. Groups vs queues one-liner? → "Groups are for sharing, queues are for ownership."
2. Can a Queue be a sharing rule's "Share with" target? → No — only Roles, Public Groups, Territories, Roles-and-Subordinates.
3. Does queue ownership alone grant access? → Yes, subject to OWD — queue membership is a valid ownership-based access path.
4. Root cause of "VIP team sees nothing"? → A sharing rule pointed at a same-named but nonexistent/misconfigured public group — a name collision, not a functional reference.
5. When do you need a Public Group despite having a Queue? → When someone who is NOT a queue member (manager, other team, dashboard folder) also needs visibility into queue-owned records.

INCIDENT 4 — THE APPROVAL THAT FROZE THE TRIGGER

The problem restated

An approval process's record lock (by design) broke a nightly batch job and made a notification flow appear broken. What does locking actually block, and how do you redesign around it?

Model answer (2-min interview version)

• What locking blocks: most standard write paths (UI, most API/Apex DML, batch updates) to the submitted record — except users with "Modify All Data" or the approval process's own actions (approve/reject/recall field updates).
• Batch job — a real bug: it never accounted for locked records; it should filter them out of its query (Approval_Status__c != 'Pending' proxy or check against process instance state), log skipped Ids, and reconcile after unlock — not attempt-and-fail every night.
• The flow — not actually a bug: IsChanged(Amount) correctly never fires because Amount literally cannot change while locked. The team's real need (visibility into approval progress) is a different requirement, served correctly by email alerts on the approval process's own steps (submission, each approver action, final outcome) — not by a field-change-triggered flow.
• Never fix by granting "Modify All Data" to the batch's running user — that defeats the entire Finance-mandated freeze.

Self-grade checklist

• Named what locking blocks and who's exempt (Modify All Data / the approval process's own actions)
• Diagnosed the batch job as a real bug needing a locked-record filter + reconciliation
• Explained why the flow's silence is correct, not broken
• Redirected the notification need to the approval process's own step-level email alerts
• Rejected "grant Modify All Data" as an anti-pattern fix

THE REDO — model answer

Lock blocks: UI, most API/Apex DML, batch — except Modify All Data or approval's own actions
Batch fix: filter query to exclude locked/pending-approval records; log skipped; reconcile post-unlock
Flow: correctly silent — Amount can't change while locked; not a bug
Notification fix: approval process's own step-level email alerts (submit/approve/reject)
Anti-pattern: do NOT grant Modify All Data to bypass the lock

RETRIEVAL DRILL — model answers

1. What write paths does approval locking block? → UI, most API/Apex DML, batch updates.
2. Who/what is exempt? → Users with "Modify All Data"; the approval process's own field-update actions.
3. Why was the flow's silence correct? → The watched field (Amount) structurally cannot change while locked — nothing to detect, not a broken flow.
4. How should the batch job be redesigned? → Filter locked/pending-approval records out of its query, log skipped records, reconcile after unlock.
5. Where should approval-progress notifications live? → In the approval process's own step-level email alerts, not a field-change-triggered flow.

INCIDENT 5 — THE FEATURE FLAG THAT COULDN'T DEPLOY

The problem restated

A Custom-Setting-based feature flag worked in sandbox but reverted to false in production because the toggle's data value didn't travel with the deploy. What's the correct tool and why?

Model answer (2-min interview version)

• What travels in a deploy: the Custom Setting's schema (object/fields) — metadata. What doesn't travel: the actual data value an admin set through Setup — that's org-specific runtime data, not metadata.
• Why Custom Metadata Types fix this: a CMT record IS metadata itself (defined as deployable XML components, like a Flow or Custom Label) — it deploys/packages/version-controls exactly like code, so the flag's intended value ships as part of the reviewed release, not a manual post-deploy step someone can forget.
• Bonus CMT capabilities Custom Settings lack: relationship fields to other objects, platform-level caching with a lower access cost than a live query, and packagability into managed/unlocked packages.
• The one-liner: "Custom Metadata Types = deployable, packageable, cached, relationship fields — the feature-flag tool. Custom Settings = runtime, per-org/profile/user override an admin sets live in each environment, not a deployment artifact."
• When Custom Settings are still right: genuine per-environment runtime tuning (a rate-limit override) that an admin is expected to set live, not something that should travel with a release.

Self-grade checklist

• Explained schema deploys but data value doesn't, for Custom Settings
• Named CMT records as metadata themselves — deployable like code
• Named at least one CMT-only capability (relationships, caching, packaging)
• Gave the corrected design with the getInstance()-style Apex reference pattern
• Named a legitimate remaining use case for Custom Settings

THE REDO — model answer

Custom Setting deploy: schema moves, DATA VALUE does not (org-specific runtime data)
Custom Metadata Type: records ARE metadata — deploy/package/version-control like code
Fix: Pricing_Config__mdt.Enable_New_Pricing__c, value baked into the deployed metadata
Apex: Pricing_Config__mdt.getInstance('Default').Enable_New_Pricing__c
Custom Setting still right for: genuine live per-org/profile/user runtime overrides

RETRIEVAL DRILL — model answers

1. What deploys for a Custom Setting, what doesn't? → Schema (object/fields) deploys; the data value an admin entered does not.
2. Why is a CMT record considered "metadata"? → It's defined as an XML metadata component, like a Flow or Custom Label, so it travels with any standard metadata deployment.
3. Two CMT capabilities Custom Settings lack? → Relationship fields to other objects; platform-level caching / packagability into managed/unlocked packages.
4. When is a Custom Setting still correct? → Genuine runtime, per-org/profile/user values an admin tunes live in each environment (not release-gating config).
5. Apex access pattern for a CMT value? → MyType__mdt.getInstance('DeveloperName').Field__c (or getAll()).

INCIDENT 6 — THE IMPORT WIZARD THAT CHOKED AT MIDNIGHT

The problem restated

A 380,000-row Lead load via the Data Import Wizard failed operationally (slow, no error detail, no resume) before an 8 AM deadline. What's the right tool matrix and approach?

Model answer (2-min interview version)

• Why the Wizard was wrong: designed for simple, point-and-click, low-volume (a few thousand rows) one-off imports — no CLI, no scheduling, and critically no exportable per-row error detail, only a coarse success/fail count.
• The four tools: Data Import Wizard (small/simple/no-code); Data Loader (up to 5,000,000 records, CLI-scriptable/scheduled, produces detailed success AND error CSV logs per run — the production choice); Workbench (browser-based ad hoc SOQL/DML/API exploration and diagnostics, not a bulk-load tool); Salesforce Inspector (browser extension for fast inline record inspection/edit/export, not for large loads).
• Tonight's fix: switch to Data Loader (CLI, unattended overnight run), capture the success/error log files, triage the error file for patterns, fix and re-submit just the failed rows, verify final counts before 8 AM.
• The deeper lesson: tool choice for data volume/deadline/auditability is a design decision a developer should weigh in on, not something to leave entirely to an admin's habit.

Self-grade checklist

• Named why the Wizard fails operationally at this volume (no CLI, no scheduling, no per-row error log)
• Named all four tools and their real use cases
• Gave Data Loader's exact volume ceiling (5,000,000)
• Named the two log files Data Loader produces (success + error)
• Gave the corrected tonight's-approach (Data Loader, triage error file, re-run failures)

THE REDO — model answer

Import Wizard: small/simple/no-code, no CLI, no scheduling, coarse count only
Data Loader: up to 5,000,000 records, CLI/scheduled, success.csv + error.csv per run
Workbench: ad hoc SOQL/DML/API diagnostics, not a bulk-load tool
Inspector: browser extension, quick inline inspect/edit/export, not for large loads
Tonight: Data Loader CLI overnight → triage error.csv → fix + re-run failed rows → verify counts

RETRIEVAL DRILL — model answers

1. Practical ceiling where the Wizard stops being right? → A few thousand records — beyond that, no error logging or scheduling makes it operationally unsafe.
2. Data Loader's stated maximum? → Up to 5,000,000 records.
3. Two log files Data Loader produces? → A success CSV (with new Ids) and an error CSV (with per-row error messages).
4. Workbench's real job / not-job? → Ad hoc SOQL/DML/API exploration and diagnostics; not built for large production loads.
5. Salesforce Inspector — what and when? → A browser extension for fast inline record inspection/edit/export directly on any Salesforce page; for quick spot-checks, not bulk loads.

INCIDENT 7 — THE DASHBOARD THE VP WANTED AT 8 AM SHARP

The problem restated

A dynamic dashboard (run-as-logged-in-user, for legitimate per-region security) had no "Schedule Refresh" option at all. Why, and how do you meet both the deadline and the security requirement?

Model answer (2-min interview version)

• Report-type rule: only Summary and Matrix reports reliably feed dashboard components — Tabular reports lack the grouping structure most components need; Joined reports carry their own restrictions.
• Why dynamic dashboards can't be scheduled — the reasoning, not just the rule: a dynamic dashboard has no single Running User by design (each viewer sees it run as themselves — exactly the per-region security feature the VP wanted). A scheduled refresh is an unattended job that must execute the underlying reports as someone at a fixed time; with no fixed identity to run as, the platform has no way to execute the job — so "Schedule Refresh" is structurally absent, not a bug or a missing permission.
• The redesign options: (a) split into per-region static dashboards, each with an appropriate Running User/folder scoping — each one is now schedulable; (b) keep one dynamic dashboard, accept on-open refresh, and pair it with a scheduled Summary/Matrix report emailed at 7 AM as the time-certain artifact.
• The lesson: "scheduled" and "dynamic" are mutually exclusive by platform design — set that expectation explicitly rather than chasing a nonexistent permissions bug.

Self-grade checklist

• Named Summary + Matrix as the report types that feed dashboards (Tabular does not)
• Explained the no-fixed-Running-User reasoning for why dynamic dashboards can't be scheduled
• Rejected "it's a permissions bug" framing
• Gave both redesign options (per-region static dashboards / dynamic + scheduled report-email)
• Stated the "scheduled + dynamic are mutually exclusive" lesson

THE REDO — model answer

Feeds dashboards reliably: Summary, Matrix. Tabular: no. Joined: limited.
Dynamic dashboard: no single Running User (per-viewer security) → no identity for a
                    scheduled job to execute as → "Schedule Refresh" structurally absent
Not a bug, not a permission gap — a platform design rule
Fix A: per-region static dashboards (each schedulable)
Fix B: keep dynamic + on-open refresh + scheduled report-email as the 7 AM guaranteed artifact

RETRIEVAL DRILL — model answers

1. Two report formats that reliably power dashboards? → Summary and Matrix.
2. Can Tabular feed a dashboard component directly? → No — it lacks the grouping structure most components need.
3. Why can't dynamic dashboards be scheduled? → No single Running User identity exists for a scheduled job to execute the refresh as.
4. Two redesign options? → Per-region static dashboards (schedulable) OR keep dynamic + pair with a scheduled report-email.
5. Bug, permission gap, or design rule? → A deliberate platform design rule.

INCIDENT 8 — THE ESCALATION RULE THAT ESCALATED NOTHING

The problem restated

An Escalation Rule existed and was Active, but a Business Hours mismatch and a wrong notification target let dozens of SLA breaches through undetected. What's the fix, and how do Assignment and Escalation Rules relate?

Model answer (2-min interview version)

• Failure #1 — Business Hours mismatch: Escalation Rules measure "age" against a Business Hours record (deliberately, so off-hours don't falsely count) — but the org's default was 24/7 while support actually worked Mon–Fri 9–5, so the rule's clock and the real clock disagreed, especially across weekend boundaries (Friday-afternoon cases were the exposing edge case).
• Failure #2 — notification target: the escalation action notified the Case Owner — the same person who already had 4 hours and didn't act. Escalation must reach someone new: a manager or a Tier-2 group who can actually intervene.
• Assignment Rules vs Escalation Rules: sequential and complementary, not competing. Assignment Rules route a new/qualifying record to the correct initial owner/queue; Escalation Rules act afterward, on a business-hours timer, as the safety net if the case stalls. A broken escalation rule doesn't affect initial routing — it just means the safety net has a hole.
• The fix: align the Business Hours record with actual coverage and test across a weekend boundary; change the notify target to the manager/Tier-2 group; add a scheduled reconciliation report as a second, independent detection layer — the same "don't trust the green light alone" discipline used for any declarative automation.

Self-grade checklist

• Named Business Hours as the age-calculation mechanism and identified the mismatch
• Named the notification-target flaw (Case Owner, not a manager/Tier-2 group)
• Explained Assignment Rules vs Escalation Rules as sequential/complementary, not competing
• Gave the corrected 3-part design (fix Business Hours, fix notify target, add reconciliation)
• Rejected "Active = working" as sufficient evidence

THE REDO — model answer

Escalation age measured against: Business Hours record (not wall-clock)
Mismatch: org default 24/7 vs actual Mon-Fri 9-5 → Friday-afternoon cases exposed it
Notify flaw: notified Case Owner (already failed) instead of manager/Tier-2 group
Assignment Rules (initial routing) → Escalation Rules (timer-based safety net) — sequential
Fix: correct Business Hours + test weekend boundary; notify manager/Tier-2 group;
     add scheduled reconciliation report as independent detection layer

RETRIEVAL DRILL — model answers

1. What do Escalation Rules measure age against? → A Business Hours record, so off-hours don't falsely trigger/fail to trigger.
2. What was wrong with notifying the Case Owner? → It re-notifies the person who already missed the SLA window instead of someone who can actually intervene.
3. Are Assignment and Escalation Rules alternatives or complements? → Complements — sequential: assignment routes initially, escalation is the later safety net.
4. Which edge case exposed the mismatch? → Friday-afternoon cases aging across the weekend.
5. Independent second detection layer? → A scheduled reconciliation report counting SLA-breaching cases.

🏆 CAPSTONE — THE ORG WHERE ADMIN AND DEV NEVER TALKED (model report)

1. Ticket-by-ticket mapping:
   • A → Incident 1: Record Type/layout hiding mistaken for security; FLS never set. Fix: FLS = None except authorized profile.
   • B → Incident 2: validation rule doesn't fire on delete; Apex before delete trigger + revoked Delete permission is the real control.
   • C → Incident 3: sharing rule pointed at a nonexistent/misconfigured public group with the queue's name; groups are for sharing, queues are for ownership.
   • D → Incident 4: approval-process record lock correctly blocking a batch job that never accounted for it; fix the batch's query filter, not the lock.
   • E → Incident 5: Custom Setting data value doesn't travel with a deploy; needs to be a Custom Metadata Type instead.
   • F → Incident 6: Data Import Wizard used far outside its design envelope (250K rows); needed Data Loader's CLI + logging.
   • G → Incident 7: dynamic dashboard structurally cannot be scheduled (no fixed Running User); needs per-region static dashboards or a scheduled report-email companion.
   • H → Incident 8: Business Hours mismatch + wrong notification target on the escalation rule; needs corrected Business Hours + manager/Tier-2 notification + reconciliation report.
2. Priorities:
   • Tonight: stop active data-integrity bleeding — Ticket B's delete-permission exposure (lock down Delete access now) and Ticket A's field exposure (set FLS to None immediately); these are live compliance/financial risks.
   • This week: Ticket C (sharing rule target fix — a routing team currently blind to its own work), Ticket D (batch job filter + spam-filter fix so failures are visible again), Ticket H (Business Hours + notification target — active SLA exposure).
   • This quarter: Ticket E (CMT migration for the feature flag), Ticket F (standardize on Data Loader for volume loads, document the tool matrix), Ticket G (decide per-region static dashboards vs. dynamic + scheduled report-email, with leadership sign-off on the tradeoff).
3. The shared disease: "Every ticket is the same disease: someone treated a declarative Setup configuration as if it were self-evidently correct and self-evidently secure/complete, without verifying it against the platform's actual mechanics — what a Record Type controls, when a validation rule fires, what a queue vs a group actually is, what a lock blocks, what travels in a deploy, what a tool's volume ceiling is, why a dynamic dashboard can't be scheduled, and what clock an escalation rule uses. Admin clicks were never treated as production code requiring the same rigor as Apex — no review, no test plan, no verification of the actual mechanism."
4. The verification checklist (say it like a release gate):
   • Every field marked "sensitive" has FLS set to None/Read-appropriately on every profile — not just removed from a layout — verified via a test report and list view, not just the record detail page.
   • Every delete-sensitive object has its Delete permission reviewed per profile, and any conditional delete-blocking logic lives in an Apex before delete trigger, not a validation rule.
   • Every sharing rule's target is verified to be a real, populated Public Group (or Role) — not a name that merely looks like the intended queue/team.
   • Every scheduled/batch job that touches records is checked against every active Approval Process for lock conflicts, with a filter + reconciliation pattern in place.
   • Every feature flag or release-gating configuration lives in a Custom Metadata Type, not a Custom Setting, unless it is a genuine live per-environment runtime override.
   • Every planned data load is sized against the correct tool (Data Loader above a few thousand rows) with a documented success/error log review step.
   • Every "must refresh by a specific time" dashboard requirement is checked against the dynamic-dashboard scheduling restriction before it's promised to a stakeholder.
   • Every escalation/SLA rule's Business Hours assignment is tested against a weekend/off-hours boundary case, and its notification target reaches someone new, not the party who already missed the deadline.
5. The 2-minute answer (say out loud): "Every one of these eight tickets is a different symptom of the same disease: admin configuration treated as if clicking 'Save' in Setup makes something correct and complete, with no review discipline and no verification against how the platform actually behaves — what Record Types really control, when validation rules really fire, what a queue really is versus a group, what a lock really blocks, what a deploy really carries, what a tool's volume ceiling really is, why a dynamic dashboard structurally can't be scheduled, and what clock an escalation rule really runs on. Tonight I lock down the field exposure and the delete-permission gap because those are active compliance and financial risk. This week I fix the sharing-rule target, the batch's lock-awareness, and the SLA rule's Business Hours and notification target. This quarter I move the feature flag to Custom Metadata, standardize the data-load tooling, and get leadership sign-off on the dashboard tradeoff. Before we 3x headcount, every one of these gets a release-gate checklist item — because at 3x the users, every one of these gaps gets 3x louder."

KNOWLEDGE SPINE — rapid-fire (model answers)

1. What does a Record Type control? → Picklist values, page layout assignment, business process.
2. Does a Record Type control access? → No.
3. Do validation rules fire on delete? → No — create/update only.
4. How do you conditionally block a delete? → Apex before delete trigger with .addError().
5. Groups vs queues one-liner? → Groups are for sharing, queues are for ownership.
6. Can a sharing rule target a queue? → No — only Roles, Public Groups, Territories, Roles-and-Subordinates.
7. Does queue ownership grant member access on its own? → Yes, subject to OWD.
8. What does approval-process record locking block? → Most standard write paths (UI, most API/Apex DML, batch) except Modify All Data or the approval's own actions.
9. Custom Metadata Type vs Custom Setting — which deploys? → CMT (it IS metadata); Custom Setting's data value does not.
10. When is a Custom Setting still correct? → Genuine live per-org/profile/user runtime tuning, not release-gating config.
11. Data Loader's max record volume? → Up to 5,000,000.
12. Which two data tools give detailed per-row error logs? → Data Loader (success + error CSV); the Import Wizard does not.
13. Which report types feed dashboards? → Summary and Matrix (not Tabular; Joined is limited).
14. Can a dynamic dashboard be scheduled? → No — no single Running User identity for the platform to execute the job as.
15. What do Escalation Rules measure age against? → A Business Hours record.
16. Assignment Rules vs Escalation Rules? → Sequential/complementary — assignment routes initially, escalation is the later timer-based safety net.
17. What's the FLS-vs-layout-hiding rule? → Layout hiding is UI-only for one page; FLS hides a field everywhere (reports, list views, API, search).
18. What's the escalation-notification mistake to avoid? → Notifying the same Case Owner who already missed the SLA, instead of a manager/Tier-2 group.
19. Profile vs Permission Set? → Profile = mandatory one-per-user baseline; Permission Set = additive, multiple per user.
20. The one shared discipline across this whole module? → Treat every Setup/config change as production code — verify the actual platform mechanism, don't assume the click did what it looks like it did.

INTERLEAVED PRACTICE SET — model answers

1. Trap hunt: (a) Module 9 Incident 1 — Record Type/layout mistaken for security; (b) Module 9 Incident 3 — public group vs queue name collision; (c) Module 9 Incident 2 — validation rule doesn't fire on delete; (d) Module 9 Incident 5 — Custom Setting data doesn't deploy; (e) Module 9 Incident 7 — dynamic dashboard can't be scheduled.
2. Design (2 min): A feature flag that must ship identically across every sandbox and production on release day, reviewed in the same PR as the code that depends on it → Custom Metadata Type (Feature_Flags__mdt), value baked into the deployed metadata, read via getInstance()/getAll(), zero manual post-deploy step, zero SOQL-style cost.
3. Module-4 bridge: the "green run ≠ convergence" discipline (fault paths + reconciliation, Module 4 Incident 6) maps directly onto Module 9 Incident 8 — "Active = working" is not evidence an escalation rule is actually catching SLA breaches; a reconciliation report is the same evidence-gate pattern applied to a declarative admin tool instead of a Flow.
4. Module-5 bridge: the FLS-vs-layout-hiding distinction (Module 9 Incident 1) is the exact production form of the Module 5 Security & Sharing trap: "layout hiding still exposes in reports/search/API; FLS hides everywhere" — same mechanism, cited word-for-word in the master knowledge spine.
5. One-card answer (5 bullets + incident map): (1) Access vs presentation vs ownership vs visibility are four different systems — never conflate Profiles/Permission Sets, Record Types, Queues, and Role Hierarchy/Sharing (I1, I3); (2) automation fires exactly when the platform says it does, not when you assume — validation rules never fire on delete, approval locks block writes except specific exemptions (I2, I4); (3) deployability and volume have real tool ceilings — Custom Metadata vs Custom Settings, Data Loader vs Import Wizard (I5, I6); (4) declarative reporting/scheduling has structural limits exactly like governor limits — Summary/Matrix-only dashboards, no scheduling on dynamic dashboards (I7); (5) every unattended/timer-based control needs a second, independent verification layer — reconciliation reports, not just "it's Active" (I8).

THE ONE-CARD ANSWER KEY (carry this)

"What does a developer need to know about Admin config?" — 5 lines:

1. Four different systems, never conflate them: Profiles/Permission Sets (access baseline + additive), Role Hierarchy + Sharing Rules (record visibility), Queues (ownership/routing) vs Public Groups (sharing targets only), Record Types (picklists/layout/process — never access).
2. Automation fires exactly when the platform says, not when you assume: validation rules = create/update only, never delete; approval-process locks block most writes except Modify All Data or the process's own actions.
3. Deployability has a real boundary: Custom Metadata Types are metadata (deploy/package/cache/relate); Custom Settings are runtime, per-environment, not a deployment artifact — pick CMT for feature flags.
4. Tool choice is a design decision: Data Import Wizard (small/simple) vs Data Loader (up to 5M, CLI/scheduled, logged) vs Workbench (diagnostics) vs Inspector (quick inline edits) — match the tool to the volume and the deadline.
5. Declarative reporting/scheduling has structural limits: only Summary/Matrix reports feed dashboards; dynamic dashboards cannot be scheduled (no fixed Running User); escalation rules run on a Business Hours clock that must match reality, and every unattended control needs an independent reconciliation check.

Facts to say cold: Record Type = picklists/layout/process only · validation rules never fire on delete · approval lock exempts Modify All Data + the process's own actions · CMT deploys, Custom Setting data doesn't · Data Loader = up to 5,000,000 records · Summary + Matrix feed dashboards, Tabular doesn't · dynamic dashboards can't be scheduled (no fixed Running User) · escalation rules measure age against Business Hours · "groups are for sharing, queues are for ownership."