3.7 Security and Access Case Lab

Salesforce Admin Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Platform Administrator Orientation and Official Source Control

1.1 Credential Name, Current Outline, and Search Language 1.2 Exam Format, Fee, Score, and Reference Rules 1.3 Trailhead, Trailhead Academy, and Pearson VUE Delivery Workflow 1.4 Domain Weights, Agentforce, and Study Prioritization 1.5 Maintenance Modules, Credential Ethics, and Exam Security 1.6 Developer Edition, Trailhead Playground, and Practice Bank Workflow

2 Chapter 2: Configuration, Setup, User Management, and Org Controls

2.1 Company Information, Fiscal Year, Business Hours, and Locale 2.2 User Records, Licenses, Profiles, Permission Sets, and Login Access 2.3 Login Security, Session Settings, and Identity Basics 2.4 Setup Navigation, Release Readiness, and Change Control 2.5 UI Settings, Home Pages, Apps, and Navigation 2.6 Configuration and Setup Case Lab

3 Chapter 3: Security, Access, Identity, and Sharing Model

3.1 Org-Wide Defaults, Roles, Sharing Rules, and Teams 3.2 Profiles, Permission Sets, Permission Set Groups, and Muting 3.3 Field-Level Security, Page Layouts, and Dynamic Forms 3.4 Record Access Troubleshooting and Login-As Workflow 3.5 Identity, Login History, MFA, and Session Risk 3.6 Data Visibility, Reporting, and Analytics Security 3.7 Security and Access Case Lab

4 Chapter 4: Object Manager, Lightning App Builder, and Data Modeling

4.1 Standard Objects, Custom Objects, and Schema Fit 4.2 Fields, Formulas, Rollups, Validation, and Requiredness 4.3 Lookup, Master-Detail, and Junction Relationships 4.4 Record Types, Business Processes, Page Layouts, and Lightning Pages 4.5 Dynamic Forms, Dynamic Actions, and User Experience 4.6 Schema Change Risk, Data Quality, and Deployment Readiness 4.7 Object Modeling Case Lab

5 Chapter 5: Sales, Marketing, Service, and Support Applications

5.1 Lead, Campaign, Account, Contact, and Opportunity Flow 5.2 Sales Processes, Path, Products, Price Books, and Forecasting 5.3 Case Management, Queues, Assignment, Auto-Response, and Escalation 5.4 Knowledge, Entitlements, Service Console, and Support Productivity 5.5 Sales-Service Data Quality and Automation Boundaries 5.6 Application Configuration Troubleshooting 5.7 Sales and Service Applications Case Lab

6 Chapter 6: Data and Analytics Management

6.1 Data Import Wizard, Data Loader, Export, and Backup 6.2 Duplicate Management, Validation, and Data Quality Controls 6.3 Data Transfer, Ownership, Mass Update, and Mass Delete 6.4 Report Types, Filters, Summary Formulas, and Buckets 6.5 Dashboards, Components, Subscriptions, and Sharing Impact 6.6 Analytics Security, Visibility, and Executive Reporting 6.7 Data and Analytics Case Lab

7 Chapter 7: Automation, Flow, Approval, and Operational Processes

7.1 Automation Tool Selection and Order of Execution 7.2 Flow Builder: Screen, Record-Triggered, Scheduled, and Autolaunched Flows 7.3 Approval Processes, Email Alerts, and Notification Patterns 7.4 Validation Rules, Assignment Rules, and Escalation Rules 7.5 Automation Testing, Debugging, and Governance 7.6 Automation Performance, Recursion, and Maintainability 7.7 Automation Case Lab

8 Chapter 8: Productivity, Collaboration, Mobile, and AppExchange

8.1 Activities, Tasks, Events, Calendar, and Email Productivity 8.2 Chatter, Feeds, Groups, Notifications, and Collaboration Governance 8.3 Salesforce Mobile Navigation, Actions, and Page Design 8.4 List Views, Kanban, Path, and User Adoption Tools 8.5 AppExchange Evaluation, Installation, Permissions, and Risk 8.6 Productivity and Collaboration Case Lab

9 Chapter 9: Agentforce for Platform Administrators

9.1 Agentforce Use Cases, Admin Boundaries, and Fit 9.2 Trusted AI, Security, Data Access, and Permission Implications 9.3 Agent Builder, Prompt Builder, and Grounding Concepts 9.4 Testing, Deployment, Monitoring, and Feedback Workflows 9.5 Agentforce Service, Sales, and Internal Productivity Scenarios 9.6 Agentforce Risk, Troubleshooting, and Governance 9.7 Agentforce Case Lab

10 Chapter 10: Integrated Salesforce Admin Scenario Labs

10.1 New Sales Org Setup Integrated Lab 10.2 Service Team Case Management Integrated Lab 10.3 Data Quality and Analytics Integrated Lab 10.4 Security, Access, and Reporting Integrated Lab 10.5 Flow Automation and Change Control Integrated Lab 10.6 Agentforce and Adoption Integrated Lab 10.7 Full Admin Simulation Strategy

11 Chapter 11: Final Review, Maintenance, and Test-Day Strategy

11.1 Final 30-Day Salesforce Admin Review Plan 11.2 Trailhead Playground Hands-On Drill Plan 11.3 105-Minute Exam Timing, Flagging, and Review Workflow 11.4 Test-Day Checklist: Online or Test Center 11.5 Post-Exam Maintenance Modules and Next Certifications 11.6 Salesforce Admin Final Mixed Review

3.7 Security and Access Case Lab

Key Takeaways Explain This Topic AI

Integrated access cases require admins to combine identity, object permission, field security, OWD, roles, sharing rules, teams, reporting, and support evidence.

Least privilege means choosing the narrowest durable mechanism that matches the business pattern, not the fastest broad permission.

A good lab workflow uses test users, documented expected access, controlled configuration changes, and retesting from the affected user's perspective.

The same access model should be evaluated for Salesforce UI, reports, dashboards, integrations, and admin-support workflows.

Last updated: May 2026

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 layer Design question Evidence to collect

Identity Can the user log in from the right place with required assurance? User record, Login History, profile login policy, MFA or SSO status.

Object permission Can the user perform the object action? Profile, permission sets, permission set groups.

Field security Can the user see or edit sensitive fields? FLS on profile and permission assignments.

Record access Which specific records should be visible or editable? OWD, role hierarchy, sharing rules, teams, ownership.

Analytics Should reports show the same rows and fields? Folder access, report type, filters, dashboard running user.

Support workflow Can the admin reproduce and document the symptom? Login-As policy, test notes, before-and-after checks.

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:

Set the private baseline in Sharing Settings.

Confirm sales reps have Opportunity Read, Create, and Edit for their own work.

Confirm manager roles sit above reps in the hierarchy.

Create or identify the Deal Desk public group.

Create a criteria-based sharing rule for high-value negotiation-stage opportunities.

Assign a permission set for Deal Desk object and field access.

Test as a rep, manager, and Deal Desk user.

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:

Confirm the specialist can log in and has Case Read or Edit as required.

Confirm Case OWD and the user's normal case visibility.

Check whether the specialist is on the case team or has a manual share.

Check field-level security for Legal Notes.

Check page layout or Dynamic Forms only after FLS is correct.

Check validation rules or approval locks if edits fail.

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.