SF-Data-Arch Master Data Management Practice Question
A Salesforce data architect is asked to recommend a native capability for detecting and merging duplicate person accounts created by multiple intake channels. Which Salesforce feature should the architect recommend as the primary tool?
⚠ Common exam trap
The trap here is reaching for custom Apex or validation rules when the platform already ships declarative duplicate detection and merge capabilities designed for exactly this use case.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Duplicate Rules combined with Matching Rules and the built-in merge interface.
Salesforce provides declarative Matching Rules and Duplicate Rules that evaluate candidate records on create and edit, plus a standard merge interface for consolidation. Together these cover both prevention and remediation natively. Validation rules, activity capture, and custom Apex each address something adjacent but not the core duplicate detection and merge requirement, so they cannot be the primary recommendation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Einstein Activity Capture to reconcile duplicate activities across person accounts.
Why it's wrong here
Einstein Activity Capture synchronizes email and calendar events to records; it does not compare account or contact attributes to detect duplication. Recommending it here confuses activity data with identity data. It would not prevent duplicates at intake and provides no merge functionality, so it cannot serve as the primary MDM tool for this requirement.
- ✗
Validation Rules that block record creation when the last name matches an existing contact.
Why it's wrong here
Validation rules are deterministic and single-record scoped; they cannot query across the full object to evaluate fuzzy similarity or to surface a set of candidate matches. Blocking creation outright on any last-name match would also generate excessive false positives for common surnames. They offer no merge path, so duplicates already in the system would remain unresolved.
- ✓
Duplicate Rules combined with Matching Rules and the built-in merge interface.
Why this is correct
Duplicate Rules and Matching Rules are the native Salesforce mechanism for identifying potential duplicates at the point of creation or edit, while the merge interface consolidates surviving records. Together they provide both prevention and remediation for person account duplication without external tooling, which directly addresses the intake-channel scenario and keeps the MDM workflow inside the platform.
- ✗
A scheduled Apex batch job that compares Account.Name values using SOQL LIKE queries.
Why it's wrong here
A custom batch job is technically possible, but it is not the native, supported capability the architect was asked to recommend, and it reimplements logic that Salesforce already exposes declaratively. SOQL LIKE comparisons are limited in fuzzy tolerance and would need substantial custom scoring. It also bypasses the standard merge interface, making stewardship and audit harder than using platform features.
About these practice questions
One of 222 original SF-Data-Arch practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Salesforce exam blueprint
This SF-Data-Arch practice question is part of Courseiva's free Salesforce certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SF-Data-Arch exam.