Universal Containers (UC) is planning to move away from legacy CRM to Salesforce. As part of one-time data migration, UC will need to keep the original date when a contact was created in the legacy system. How should an Architect design the data migration solution to meet this requirement?
A.
After the data is migrated, perform an update on all records to set the original date in a standard CreatedDate field.
B.
Create a new field on Contact object to capture the Created Date. Hide the standard CreatedDate field using Field -Level Security.
C.
Enable "Set Audit Fields" and assign the permission to the user loading the data for the duration of the migration.
D.
Write an Apex trigger on the Contact object, before insert event to set the original value in a standard CreatedDate field.
C.
Enable "Set Audit Fields" and assign the permission to the user loading the data for the duration of the migration.
Option C ("Enable 'Set Audit Fields' and assign the permission to the user loading the data for the duration of migration") is correct. Salesforce offers the "Set Audit Fields" permission explicitly designed for scenarios like migrations, allowing administrators to preserve original creation and modification timestamps. This is crucial because the standard CreatedDate field is read-only, and Salesforce prevents direct editing or updating through normal methods such as Apex triggers or updates after data creation. Options like hiding the CreatedDate field or using triggers violate Salesforce's inherent data integrity constraints and best practices. Thus, enabling this audit field permission is Salesforce's recommended and only standard-supported method to preserve historical dates during migrations.