SF-Data-Arch Data Migration Practice Question
A data architect needs to migrate 500,000 Account records from a legacy system into Salesforce. The legacy system uses a 15-digit alphanumeric string as the unique identifier. The architect must ensure that future updates can match existing Accounts without creating duplicates. Which field configuration should be used on the Account object to support this requirement?
⚠ Common exam trap
A common mix-up: candidates confuse the Unique attribute with the External ID attribute; only External ID enables upsert matching.
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
✓
Create a custom Text field of length 15 and make it an External ID.
To support upsert and prevent duplicates, the legacy identifier must be stored in a field marked as an External ID. A custom Text field of sufficient length, designated as External ID, allows the Data Loader or Bulk API to match existing records based on that field. This is the standard pattern for integrating external systems and maintaining data integrity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a custom Text field of length 15 and use it as the Salesforce Record ID.
Why it's wrong here
Salesforce Record IDs are system-generated 15- or 18-character IDs that cannot be manually set or replaced. Using a custom field as a Record ID is not possible. The legacy identifier must be stored in a separate field, preferably an External ID, to enable matching during upsert. This option misunderstands the immutability of the Salesforce Record ID.
- ✓
Create a custom Text field of length 15 and make it an External ID.
Why this is correct
An External ID field is specifically designed to store unique identifiers from external systems and is used by the upsert operation to match records. Making the custom Text field an External ID allows the architect to use upsert with this field as the match key, preventing duplicates during future updates. The length of 15 accommodates the legacy identifier.
- ✗
Use the standard Account Number field and set it as an External ID.
Why it's wrong here
The standard Account Number field has a maximum length of 40 characters, which is sufficient for a 15-digit string, but it is not automatically an External ID. While you can set some standard fields as External IDs, the Account Number field may not be ideal if the legacy identifier is alphanumeric and you need to avoid conflicts with existing data. A custom External ID field provides more control and clarity.
- ✗
Create a custom Text field of length 15 and mark it as Unique.
Why it's wrong here
While a Unique field enforces uniqueness, it does not enable the upsert operation to use it as a matching key. Upsert requires an External ID field to match records. Without the External ID designation, the architect would need to perform separate queries to find existing records, increasing complexity and risk of duplicates. The Unique attribute alone is insufficient for the stated requirement.
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.