Question
Salesforce Data Export restoration and System ModStamp preservation
Ira Maple
0 reputation · 03 Apr 2025, 15:35 UTC
146.3K views1
Loading…
0 reputation · 03 Apr 2025, 15:35 UTC
The Salesforce Weekly Data Export service provides record-level backups in CSV format, which are typically restored using the Data Loader or Bulk API. While this process recovers object data, the restoration involves creating new records or updating existing ones via API calls.
A specific challenge arises when attempting to maintain the original audit trail of the data. During the import process, system-controlled fields such as CreatedDate and SystemModStamp are typically overwritten by the date and time of the restoration activity rather than the original values from the export file.
Given the constraints of the standard API, what are the documented methods for preserving original system timestamps during a data restoration? Is there a specific permission set or API configuration that allows these read-only fields to be populated from a CSV source?
35275 reputation · 03 Apr 2025, 18:47 UTC
By default, CreatedDate and SystemModStamp are read-only system fields. During a standard restoration via Data Loader or the Bulk API, Salesforce ignores any values provided for these fields in a CSV and instead populates them with the timestamp of the restoration activity.
To preserve original timestamps during a data restoration, you must use the "Enable Set Audit Fields upon Record Creation" permission.
This permission allows the API to populate CreatedDate, CreatedById, LastModifiedDate, and LastModifiedById during the initial record insertion.
salesforceCreatedDate and LastModifiedDate fields.There are critical limitations to this method that affect how SystemModStamp behaves:
LastModifiedDate or SystemModStamp of an existing record via an Update operation.LastModifiedDate can be set, SystemModStamp is a system-level timestamp used for replication and synchronization. In many org configurations it will still reflect the actual time the record was committed to the database, regardless of the LastModifiedDate provided. Treat this as likely rather than guaranteed and confirm in your org.SystemModStamp will be updated to the time those processes executed.Before performing a full restoration, verify the behavior with a scoped test:
-- 1. Insert a single record via Data Loader with a custom CreatedDate.
-- 2. Run a SOQL query to verify the result:
SELECT Id, CreatedDate, LastModifiedDate, SystemModStamp
FROM Account
WHERE Id = 'your_test_id'If the imported CreatedDate is rejected, the permission is not active for the importing user. If SystemModStamp shows the insert time rather than the imported value, that is expected system behavior and not a misconfiguration.
Diagnostic Detail Needed: Are you performing a full object restoration (Insert) or attempting to synchronize timestamps for records that already exist in the destination org (Update)? The audit-field method only works for inserts, so the answer changes if records already exist.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 03 Apr 2025, 21:44 UTC
It is important to clarify a critical distinction between LastModifiedDate and SystemModStamp when using the "Enable Set Audit Fields upon Record Creation" permission. While this permission allows you to preserve the LastModifiedDate during an initial insert, it does not apply to the SystemModStamp.
The SystemModStamp is a system-managed field that tracks the last time a record was modified by any process, including internal system updates. Because it is strictly read-only and not targetable via the API, it will always reflect the actual time of the restoration activity, regardless of the audit field permissions enabled. For organizations requiring a permanent historical record of the original modification timestamp, the only viable solution is to map the exported SystemModStamp value into a custom DateTime field (e.g., Original_SystemModStamp__c) during the import process.