6.7 Data and Analytics 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

6.7 Data and Analytics Case Lab

Key Takeaways Explain This Topic AI

Integrated data scenarios require sequencing: backup, clean, import, validate, deduplicate, transfer, report, dashboard, and secure.

A good admin creates evidence at each step, including exports, mappings, error files, rule decisions, test personas, and dashboard definitions.

The same source data can affect imports, duplicate rules, validation rules, ownership, reports, dashboards, subscriptions, and Agentforce grounding.

Hands-on practice in a Trailhead Playground or Developer Edition org is essential because small metadata choices change scenario outcomes.

Last updated: May 2026

Case scenario: North Trail Outfitters data reset

North Trail Outfitters has three connected problems. First, marketing imported trade show leads from several spreadsheets, and many leads overlap with existing contacts and accounts. Second, a sales reorganization moved several enterprise accounts from West region owners to a new Strategic Accounts team. Third, the executive team wants a dashboard showing clean pipeline, top customer risk, and data quality exceptions before the next operating review. The admin must design the work without overwriting valid user changes or exposing sensitive data.

The current Trailhead outline gives Data and Analytics Management a large share of the Platform Administrator credential, and this case shows why. One decision affects another. A duplicate rule that blocks lead creation may interrupt marketing operations. A validation rule that requires industry may break the lead import if the source files are incomplete. An account owner transfer may change pipeline visibility. A dashboard running as the chief revenue officer may show managers more aggregate data than expected. An Agentforce summary grounded in the same reports may repeat any bad assumptions.

Project intake questions:

Question Why it matters

Which objects are in scope: leads, accounts, contacts, opportunities, cases, or custom objects? Tool choice and relationship impact depend on object scope.

What source system keys exist? External IDs reduce duplicate and update risk.

Which records are bad, stale, or newly imported? Cleanup requires precise filters, not guesses.

Which automations and rules run on these objects? Imports and owner changes can trigger validation, flows, assignment, and notifications.

Who should see the final dashboard? Folder access, running user, and dynamic dashboard choices depend on audience.

What is the rollback plan? Exports and success files are needed before bulk updates.

The admin starts with discovery, not data loading. They export current leads, accounts, contacts, opportunities, and open cases that may be affected. The export includes record IDs, owner IDs, external IDs, email, account name, website, region, created date, last modified date, status, and fields that reports depend on. They save the source spreadsheets unchanged, then create a cleaned working copy with normalized picklists and a separate review column for ambiguous rows. They do not delete anything yet.

Next, the admin reviews duplicate management. For leads, a same-email match may be useful but not perfect because shared inboxes exist. For accounts, website and external customer number are stronger. The admin configures a duplicate rule that warns and reports possible lead duplicates during the campaign import, while blocking account records that match a unique external customer number. That balances speed and trust. A data steward owns the duplicate record set after the import.

Lab workflow and decision log

The import is tested in a sandbox or Trailhead Playground. The admin loads ten rows that represent clean leads, existing contacts, shared emails, bad picklists, missing company names, and duplicate account IDs. They review Data Loader success and error files, duplicate record reports, validation messages, and any flows that update lead score or owner.

The test shows that one validation rule requires Industry on converted leads but the trade show list does not include Industry. The admin does not disable the rule globally. Instead, they add a controlled process: marketing must provide a default segment for the import, and the data steward reviews Unknown values after the load.

Decision log:

Use Data Loader for the import because the data volume and upsert behavior require external IDs.

Use External ID fields for account customer number and campaign source row ID.

Warn on probable lead duplicates; block account duplicates on unique external customer number.

Preserve open opportunity ownership unless the account is in the approved Strategic Accounts transfer list.

Transfer only current strategic accounts and open related opportunities after export and count reconciliation.

Use bucket fields temporarily for pipeline size bands, then plan a stored Segment field cleanup.

Build dashboards from governed source reports in shared executive and manager folders.

Test dashboard visibility as CRO, regional manager, strategic account rep, and support manager.

For the reorganization, the admin creates a report of accounts approved for Strategic Accounts transfer. The business expects 480 accounts; the report returns 482. The admin stops and investigates. Two accounts have the right region but the wrong segment because of old picklist values. After business confirmation, one is included and one is excluded. The final CSV contains account IDs, old owner IDs, new owner IDs, and notes. Related open opportunities transfer only when the business wants the new team accountable. Closed opportunities remain historically owned by the original reps.

Reporting comes last because reports depend on cleaned data and correct ownership. The admin creates source reports for pipeline by owner, accounts missing strategic fields, open cases for strategic accounts, duplicate lead review, and import error trends. Custom report types are created only where standard report types cannot answer the question, such as accounts with or without open cases. Bucket fields group opportunity amounts into Small, Growth, and Strategic for the dashboard, but the admin documents that this is a reporting aid until the segment cleanup is complete.

Dashboard security is tested deliberately. The CRO dashboard runs as the CRO and lives in an executive folder. A manager dashboard is dynamic so each manager sees their accessible team data. A data quality dashboard is shared with data stewards and operations managers, not every sales rep. Subscriptions run after the nightly integration and after the weekly import window, so recipients do not receive stale numbers. Source reports are stored in folders with matching governance.

Agentforce is considered for a future enhancement: a manager could ask for a summary of visible pipeline changes and data quality blockers before a forecast call. The admin records boundaries first. The agent must use approved reports or data sources, respect the user's access, be tested with manager and rep personas, avoid making commitments or forecasts without human review, and be monitored after deployment. If duplicate data remains unresolved, the agent should flag uncertainty rather than present a confident but unsupported answer.

Hands-on practice version:

In a Trailhead Playground, create a small CSV for leads with duplicate emails and inconsistent picklist values.

Add or inspect a validation rule that blocks a stage change when a required business field is blank.

Create a simple duplicate rule that alerts rather than blocks for one scenario.

Export a set of records before updating owners.

Build a report that finds records missing a required analytics field.

Add a dashboard component from that report and test folder sharing with another user where possible.

This lab is intentionally integrated. If you can explain why each control appears in the sequence, you are studying the domain at the right depth. Tool names matter, but admin judgment matters more: protect existing data, make precise changes, explain visibility, and turn cleaned records into trusted analytics.