3.7 Security and Access Case Lab

Lab Setup Mindset

Use a Trailhead Playground or Developer Edition org for practice. Do not experiment with production security while studying. Create a simple company model with sales reps, sales managers, support agents, support managers, and operations users. Use test users with ordinary profiles and targeted permission sets so you can see the real effect of each setting. If every test user is an admin, the lab will not teach record access.

The case lab has three goals. First, build an access design from requirements. Second, troubleshoot symptoms without overgranting. Third, explain the result in administrator language. For each case, write down expected object access, field access, record access, reporting access, and login behavior before you click Setup. This habit maps directly to scenario questions.

Case 1: Private Opportunities And Deal Desk

Requirement: Sales reps own their opportunities. Managers must see opportunities owned by their teams. Deal Desk must see and edit opportunities when Amount is high and Stage is Negotiation or later. Reps should not see peer opportunities. Margin fields should be hidden from reps but visible to Deal Desk and sales managers.

Design the baseline with Opportunity OWD set to Private. Use the role hierarchy for manager visibility if the hierarchy matches the sales management model. Use a criteria-based sharing rule to share qualifying opportunities with a Deal Desk public group. Give Deal Desk object Read and Edit on Opportunity through a permission set or group. Use FLS to expose Margin fields only to Deal Desk and managers.

Access decision workflow:

1. Set the private baseline in Sharing Settings.
2. Confirm sales reps have Opportunity Read, Create, and Edit for their own work.
3. Confirm manager roles sit above reps in the hierarchy.
4. Create or identify the Deal Desk public group.
5. Create a criteria-based sharing rule for high-value negotiation-stage opportunities.
6. Assign a permission set for Deal Desk object and field access.
7. Test as a rep, manager, and Deal Desk user.
8. Run a report as each user and compare expected rows and margin field visibility.

Exam judgment: Public Read/Write would satisfy broad visibility but violate the requirement that reps not see peer opportunities. Modify All on Opportunity would be too broad for Deal Desk unless the business explicitly wants all Opportunity administration.

Case 2: Support Escalation And Case Teams

Requirement: Support agents own cases in their queue. A specialist should assist on one complex case without seeing all cases in the queue. Support managers need reporting over all cases owned by their teams. A field named Legal Notes must be visible only to managers and legal specialists.

A case team or manual share fits the single-case specialist collaboration requirement. A sharing rule would be appropriate only if specialists need a category of cases, not one case. The role hierarchy can support manager visibility if ownership and roles align. Legal Notes must be protected with FLS, not merely hidden from a page layout.

Troubleshooting sequence for a specialist who cannot help on the case:

1. Confirm the specialist can log in and has Case Read or Edit as required.
2. Confirm Case OWD and the user's normal case visibility.
3. Check whether the specialist is on the case team or has a manual share.
4. Check field-level security for Legal Notes.
5. Check page layout or Dynamic Forms only after FLS is correct.
6. Check validation rules or approval locks if edits fail.
7. Retest with Login-As or a matching test user if policy allows.

Exam judgment: Adding the specialist to the support manager role is a poor fix because it changes visibility for many records. Adding the specialist to the specific case team preserves least privilege for a one-record need.

Case 3: Reporting Mismatch

Requirement: Operations users need a dashboard showing open case volume by region. They may see aggregate totals but should not open restricted legal cases. Support managers need dynamic dashboards that reflect their own teams. Legal case details remain private to legal specialists and approved managers.

First, separate dashboard artifact access from row access. Share the dashboard folder with operations if they need to view the dashboard. Decide whether a fixed running user is appropriate for aggregate operational totals or whether viewer-context dashboards are safer. For managers, a dynamic dashboard can show data through each manager's own access model where supported.

Then test drill-down behavior. Can an operations user see restricted records after clicking a component? If the requirement says no, confirm dashboard, report, and sharing behavior matches. Check report filters and report type design. Check FLS for Legal Notes. If aggregate visibility itself is sensitive, do not use a running user who overexposes totals.

Case 4: Login Issue That Looks Like Data Access

Requirement: A new regional manager says they cannot see team opportunities. Login History shows failed attempts from a blocked IP, then one successful office login. After successful login, the manager sees the Sales app but still no subordinate opportunities.

This has two issues. The blocked IP is an identity or network policy issue. The missing team opportunities after successful login is a record access issue. Do not solve both with one broad permission. First handle the approved network or login policy workflow. Then check role assignment, Opportunity OWD, role hierarchy, ownership, and any sharing rules. If the manager is in the wrong role, fix the role assignment. If reps own records under a different branch, the hierarchy will not grant expected access.

Integrated Access Checklist

Use this final checklist before selecting an exam answer or making a real change:

• Is the issue authentication, authorization, UI presentation, reporting, or business logic?
• Does the user have the correct license, active status, and login path?
• Does object CRUD match the requested verb?
• Does FLS match the sensitive field requirement across all interfaces?
• Does OWD set a conservative baseline?
• Does the role hierarchy solve manager visibility without excess sharing?
• Does a sharing rule match a repeatable group or criteria pattern?
• Does a team or manual share better match one-record collaboration?
• Does analytics access reveal only the intended rows, fields, and aggregates?
• Was the result tested as a non-admin user and documented?

How To Study This Chapter

Build one matrix for each study case. Rows should be users and columns should be login, object permission, field permission, record access, report access, and expected result. Fill the matrix before changing Setup. Then implement one layer at a time and retest. This turns security from memorized terms into predictable behavior.

For exam readiness, practice explaining why wrong answers are wrong. If the symptom is missing field in reports, page layout is not enough. If the symptom is cannot log in due to IP range, sharing is irrelevant. If the requirement is one-record collaboration, a global sharing rule may overgrant. If the requirement is repeatable threshold-based access, manual sharing may not scale. That reasoning is the core admin skill.