6.2 Duplicate Management, Validation, and Data Quality Controls

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.2 Duplicate Management, Validation, and Data Quality Controls

Key Takeaways Explain This Topic AI

Matching rules define how potential duplicates are identified, while duplicate rules define what happens when a match is found.

Validation rules enforce business requirements at save time and affect imports, integrations, quick actions, APIs, and user edits.

Data quality controls should combine prevention, detection, stewardship queues, reporting, and exception handling.

The best rule is not always the strictest rule; admins must balance clean data with legitimate business exceptions.

Last updated: May 2026

Prevention versus correction

Data quality is a lifecycle discipline. Salesforce gives administrators several control points, but each one solves a different problem. Duplicate management helps identify records that appear to represent the same person or company. Validation rules stop a record from saving when it violates a defined business condition. Picklists reduce free-text variation. Required fields force capture of critical values. Reports, dashboards, list views, and exception queues help data stewards find and fix problems that prevention controls cannot handle safely.

Matching rules and duplicate rules are related but not interchangeable. A matching rule defines the comparison logic, such as exact match on email or fuzzy match on account name and billing address. A duplicate rule uses one or more matching rules and decides the behavior, such as alerting the user, blocking the save, or allowing the save while reporting the duplicate. Standard rules exist for common objects, and custom rules can be tailored when the business has a defensible matching strategy.

Control Best use Common trap

Matching rule Identify likely duplicate records Treating fuzzy matches as perfect proof.

Duplicate rule Alert, block, or report when matches occur Blocking legitimate branch offices or household members.

Validation rule Enforce record-level business logic Forgetting imports and integrations must also pass the rule.

Required field Make a field mandatory in the data model or page flow Using page layout requiredness when API enforcement is needed.

Picklist Standardize values for reporting and automation Leaving old free-text values unmapped during migration.

Exception report Find records needing cleanup Treating reports as prevention when bad data must be blocked.

Scenario judgment matters. A nonprofit may want to warn on contacts with the same email because spouses sometimes share an address. A B2B company may want to block duplicate accounts when the same tax ID already exists. A call center may need to create a lead quickly during a phone call, then route possible duplicates to a steward for review. The strongest answer is the one that fits the cost of duplicates, the likelihood of false positives, and the user workflow.

Setup paths are practical anchors. Duplicate rules and matching rules live in Setup > Duplicate Management . Validation rules are managed from Object Manager > Object > Validation Rules . Field requiredness can be configured at field definition, page layout, dynamic forms, flow screens, and validation rules, but these choices do not behave identically. If the value must be required regardless of entry point, a field-level required setting or validation rule is stronger than a page layout-only setting.

Designing rules that users can live with

Validation rules should be written as business policy, not as punishment. A good rule has a clear condition, a user-readable error message, and a predictable exception path. For example, an opportunity moving to Closed Won might require Contract Signed Date , Primary Contact , and Close Reason . The admin should confirm that renewals, amendments, partner deals, and integration-created opportunities have a valid way to satisfy the rule. Otherwise users will find workarounds that reduce data quality more than the rule improves it.

A strong validation design checklist:

Define the business event that should trigger the rule, such as status change, stage change, record type, or ownership change.

Confirm the rule applies to the right users, profiles, permission sets, record types, and automation contexts.

Test creates and edits, not only the happy path.

Include API, Data Loader, Flow, and integration scenarios in testing.

Write an error message that tells the user what to fix and where possible which field needs attention.

Document any bypass, such as a custom permission for a controlled integration user.

Duplicate rules need similar care. Blocking duplicates may be correct for a unique external ID or a regulated identifier, but warnings are often better when data is messy or partial. If the sales team imports conference leads, blocking every similar name may stop legitimate prospects. A duplicate rule that allows the record but reports it can create a review queue for a data steward. The steward can merge records where appropriate, keep legitimate separate records, and tune the matching rule when false positives become obvious.

Merging is not always neutral. Merging accounts, contacts, or leads can change activity history, campaign influence, account hierarchy, ownership, sharing, related lists, and reports. The admin should train stewards to pick the master record deliberately and review field values before merge. In regulated or integrated environments, merging may also affect downstream systems, so ownership of the cleanup process should be clear.

Data quality also depends on metadata choices. Restricted picklists prevent unexpected values through the UI and API. State and country picklists improve address consistency. External IDs prevent repeated fuzzy matching. Help text and field descriptions reduce ambiguity. Formula fields can expose quality flags, such as missing industry on strategic accounts. Reports can group exceptions by owner or region so managers can correct data as part of normal operations.

Study trap: do not solve every data problem with a validation rule. If users need coaching but should not be blocked, use guidance, path fields, screen flow prompts, duplicate warnings, or exception reports. If the data must never be saved incorrectly, use a hard control. If the source is an integration, make sure the integration user has exactly the bypass or error handling the business approved. A serious admin explains the tradeoff instead of simply making the rule stricter.