Study guide

10.3 Data Quality and Analytics 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.3 Data Quality and Analytics Integrated Lab

Key Takeaways Explain This Topic AI

Data quality and analytics should be designed together because reports are only as trustworthy as the fields, rules, ownership, and imports behind them.

Use validation rules, duplicate rules, picklists, required fields, reports, and stewardship workflows as a layered control model.

An analytics lab should test report type choice, filters, dashboard running user, folder sharing, and how record sharing affects visible results.

Admins need rollback and evidence habits for data changes, including exports, success files, error files, and documented cleanup decisions.

Last updated: May 2026

Lab scenario: clean data before executive reporting

An executive team wants a weekly revenue dashboard, but the current org has duplicate accounts, inconsistent industry values, missing opportunity next steps, and stale close dates. Sales managers do not trust the numbers. The admin must create a cleanup plan, apply data controls, import corrected values, and build reports that expose both pipeline and data quality exceptions. This lab is about judgment: sometimes the right admin answer is to delay a dashboard until the source data is fit for purpose.

Start by profiling the data. Use reports, list views, and exports to identify missing values, duplicate patterns, inactive owners, invalid picklist values, and records outside expected date ranges. Create reports such as Opportunities with Close Date in the Past and Not Closed, Accounts Missing Industry, Opportunities Missing Next Step, Contacts Without Email, and Accounts Created This Month by Source if fields allow. Export samples for offline review only when the data handling location is approved. Expected observation: you can describe the data quality problem with counts, owners, and business impact.

Failure mode: users argue from anecdotes because no one quantified the issue.

Quality issue Detection method Prevention or correction option Reporting impact

Duplicate accounts Duplicate rules, duplicate jobs where available, exception reports Matching rules, duplicate rules, merge process, steward review Pipeline may split across duplicate account records

Missing industry Report filter on blank Industry Required field, validation rule, guided flow, import cleanup Segmentation reports undercount industries

Stale close dates Opportunity report where Close Date is before today and Stage is open Manager review, validation on stage changes, list view coaching Forecast and pipeline aging become misleading

Invalid picklist values Export or report by field value Restricted picklists and mapped imports Dashboard groups become fragmented

Inactive record owners Report grouped by owner active flag where available or export review Ownership transfer and deactivation process Work may disappear from active team views

Design controls in layers. Use Setup > Duplicate Management for matching rules and duplicate rules when the problem is likely duplicate records. Use Object Manager > Object > Validation Rules when the organization has a hard business rule at save time. Use required fields when the value is always mandatory for the object, and Dynamic Forms or page layout requiredness when the requirement is more about a specific user interface. Use picklists, restricted values, and dependent picklists when consistency matters. Use reports and dashboards when the right answer is monitoring, not blocking.

Build a duplicate rule lab using accounts. Create a matching rule that compares Account Name and Billing Postal Code, then a duplicate rule that warns or blocks depending on risk. In a practice org, create two similar accounts and observe whether the warning appears. Then test a legitimate exception, such as two branches with similar names but different postal codes. Expected observation: the rule catches likely duplicates without blocking obvious legitimate records. Failure mode: fuzzy matching is treated as proof, and users cannot create valid records.

Build validation rules sparingly. For example, require Next Step when an opportunity is open and Amount is above a threshold, or require Loss Reason when Stage is Closed Lost. Test with a sales rep, a manager, an import update, and an automation path if one exists. Good error messages tell users what to fix. Weak messages say only invalid value or contact your admin. Keep a register of active validation rules, the business owner, the exception path, and the last reviewed date. This matters when integrations or new processes arrive later.

Plan the cleanup import. Before changing data, export the affected records with IDs and current field values. Create a corrected CSV with only fields that should change. Use a small test update in a sandbox or Trailhead Playground if possible. For production-like work, use Data Loader when record IDs, external IDs, larger volumes, or repeatable mappings are needed. Save success and error files. Expected observations include changed records, rejected bad rows, and no unexpected automation side effects.

Failure modes include overwriting fields with blanks, changing the wrong records because of name matching, and triggering email alerts or flows unintentionally.

Build analytics after controls and cleanup are understood. Choose the right report type first. Standard opportunity reports may be enough for pipeline, while account with opportunities or custom report types are needed when the question spans parent and child records. Apply filters intentionally: open pipeline, close date range, owner role, stage, record type, and amount thresholds. Group rows by Stage and Owner, summarize Amount, and add conditional highlighting where useful. Create a data quality dashboard alongside the executive revenue dashboard so managers see the work needed to keep numbers reliable.

Test sharing. Put reports in a folder shared to sales managers and executives. Decide whether dashboards should run as a specific user or as the logged-in user, depending on whether leaders need a common executive view or each viewer should see only their own accessible records. Then compare dashboard totals with a known export or source report. If numbers do not match, investigate report type, filters, row limits, dashboard component settings, folder access, running user, role hierarchy, sharing rules, and whether records are owned by inactive users.

Review prompts before the quiz:

Which data issues should be blocked at save time and which should be reported for cleanup?

What export would you keep before a bulk update, and why?

Which dashboard components are vulnerable to record sharing differences?

How do duplicate rules and validation rules solve different problems?

How would you explain to executives that a dashboard is not ready until source data is corrected?