10.4 Security, Access, and Reporting Integrated 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

10.4 Security, Access, and Reporting Integrated Lab

Key Takeaways Explain This Topic AI

Security labs must test object permissions, field-level security, record sharing, app access, report folders, and dashboard visibility together.

Profiles should provide a baseline, while permission sets and permission set groups grant additive access for jobs and exceptions.

Report access is not only about folders; report results also depend on object access, field access, record visibility, filters, and dashboard running user choices.

A strong admin validates access by logging in as users or using permission analysis, then documents expected and unexpected visibility.

Last updated: May 2026

Lab scenario: access without overexposure

A growing company has sales reps, service agents, sales managers, support supervisors, and executives in one Salesforce org. Sales reps should manage their own accounts and opportunities. Service agents should work cases and see related account context, but not edit opportunity amounts. Managers should see team records. Executives should see dashboards, but not necessarily administer Salesforce. The admin must build access that supports work and reporting without granting broad system permissions as a shortcut.

Start with the security model from the outside in. Profiles and permission sets answer whether a user can access an object, field, tab, app, or system capability. Organization-wide defaults, role hierarchy, sharing rules, teams, queues, manual sharing, and restriction rules where used answer which records a user can see. Field-level security controls whether a user can see or edit a field even if the page layout contains it. Reports and dashboards add another layer with folder sharing, source report access, running user behavior, and the viewer's underlying record visibility.

Access question Primary control Setup path Test observation

Can the user open the Sales app? App assignment and tab visibility Setup > App Manager , profiles, permission sets User sees the correct app and tabs

Can the user create cases? Object permissions Setup > Permission Sets or profile New Case action is available and save succeeds

Can the user edit Opportunity Amount? Field-level security and page behavior Object Manager > Opportunity > Fields & Relationships Field is visible or editable only for intended users

Can the manager see team opportunities? Role hierarchy, sharing rules, teams Setup > Sharing Settings , Setup > Roles Manager reports include direct team records

Can executives view dashboards? Folder sharing and dashboard running user Reports and Dashboards folders Executive sees intended components without admin rights

Create a baseline profile strategy. In a modern org, keep profiles lean and use permission sets for job-based access. Build or select a Standard User style profile where appropriate, then create permission sets such as Sales Rep Access, Service Agent Access, Sales Manager Access, Support Supervisor Access, and Executive Dashboard Viewer. Assign only required object permissions and app access. Avoid giving View All Data, Modify All Data, Customize Application, or Manage Users unless the role truly needs administration power.

These permissions are high blast radius and should not be used to fix a missing field or report.

Set object and field access deliberately. A sales rep may need read, create, edit on Leads, Accounts, Contacts, Opportunities, Tasks, Events, and Campaigns depending on the process. A service agent may need read on Accounts and Contacts, read and edit on Cases, and possibly read on Assets or Entitlements. Opportunity Amount might be read-only or hidden for service agents. Test by opening records, editing fields, creating records, and using list views.

Failure mode: page layout hides a field, but field-level security still allows API or report exposure, or field-level security hides a field and users blame the page layout.

Configure record access. If org-wide defaults for Opportunities are Private, sales reps see their own opportunities, managers see subordinate records through the role hierarchy when Grant Access Using Hierarchies applies, and sharing rules or teams can open exceptions. If Cases are Private, queues and assignment define ownership but do not automatically give every supervisor access unless roles, sharing, or permission design supports it. Public Read/Write may be tempting in a lab, but it avoids the administrator judgment the platform expects. Choose a restrictive baseline, then open access based on business need.

Build reports that expose the access model. Create a My Open Opportunities report, Team Pipeline report, Open Cases by Queue report, and Executive Forecast Snapshot report. Store them in folders with clear sharing: Sales Reports for sales users and managers, Service Reports for service staff, Executive Dashboards for executives. Then test as each persona. A sales rep should not see all company opportunities if sharing is private. A manager should see team records. A service agent should not see Opportunity Amount if field-level security hides it.

The executive should see dashboards only if folder and dashboard settings allow it.

Pay special attention to dashboard running user choices. A dashboard running as a named executive or admin can display records the viewer could not otherwise see in source reports, depending on dashboard type and permissions. A dynamic dashboard can show data according to the logged-in user's access. The right choice depends on the purpose. A board-level metric might intentionally use a consistent running user. A manager coaching dashboard might be better as dynamic so each manager sees their own team. Document the intended behavior and test it.

Add a troubleshooting routine. When a user cannot see a field in a report, check object permission, field-level security, report type availability, page layout only if the issue is on the record page, and whether the field is included in the custom report type. When a user cannot see a record in a report, check ownership, OWD, role hierarchy, sharing rules, teams, queues, manual shares, territory or account team behavior if used, and report filters. When a user cannot open a report, check folder sharing and report permissions. Do not fix every issue by making the user a system administrator.

Review prompts before the quiz:

What is the difference between object access and record access in your test org?

How would you prove a hidden field is protected by field-level security and not only page layout removal?

Which reports should run as the viewer, and which need a fixed running user?

What permission would be too broad for a manager who only needs dashboards?

Where would you document expected access by persona?