SF-Data-Arch Data Migration Practice Question
A data architect is migrating 8 million Contact records from a legacy CRM into Salesforce Sales Cloud. The legacy system stores phone numbers as free-text strings in multiple formats (e.g., '(415) 555-1212', '415.555.1212', '4155551212'). After migration, users must be able to search for Contacts by phone number and have the numbers display consistently. Which approach should the architect use to ensure phone numbers are searchable and standardized?
⚠ Common exam trap
The trap here is assuming the standard Phone field automatically normalizes or reformats inconsistent free-text values during import.
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
✓
Pre-process the legacy data in the ETL layer to normalize all phone numbers to a single format, then load them into the standard Phone field.
Normalizing phone numbers during the ETL process before loading them into the standard Phone field ensures that all values conform to one format. This makes the standard field's search indexing effective and provides consistent display without custom code. The other options either leave inconsistent data at rest or rely on features that do not automatically normalize free-text input.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store the original free-text phone numbers in a Text field and create a formula field that formats the number for display.
Why it's wrong here
A formula field can reformat display but cannot reliably parse inconsistent free-text input, and formula fields are not indexed for search. Users searching by a normalized number would not find records because the underlying stored value remains inconsistent. This approach also fails to enforce a single canonical format at rest, leaving data quality issues unresolved.
- ✗
Store phone numbers in the standard Phone field and rely on Salesforce's automatic normalization and search indexing.
Why it's wrong here
The standard Phone field does not automatically normalize or reformat arbitrary free-text values during import. Salesforce search does index phone fields, but inconsistent formatting means a search for '4155551212' may not match '(415) 555-1212'. Without pre-processing, the data remains inconsistent and search results are unreliable.
- ✗
Create a custom Text field with a validation rule that enforces a specific phone number format, and load the raw values.
Why it's wrong here
A validation rule would reject the inconsistent legacy values during load, causing many records to fail. Even if the rule were lenient, the raw values would still be stored inconsistently, defeating the search requirement. Custom text fields also lack the built-in phone indexing and formatting behavior of the standard Phone field.
- ✓
Pre-process the legacy data in the ETL layer to normalize all phone numbers to a single format, then load them into the standard Phone field.
Why this is correct
Normalizing phone numbers in the ETL layer before loading ensures a consistent canonical format at rest, which makes the standard Phone field searchable and displayable uniformly. This approach leverages the built-in indexing of the Phone field and avoids the need for custom parsing logic in Salesforce, meeting both search and consistency requirements.
About these practice questions
Courseiva writes every SF-Data-Arch question from scratch — 222 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.