Overview
Audit fields in Salesforce are special system-managed fields that track who created or modified a record and when those changes occurred. They are critical for data lineage, compliance, forensic analysis, and migrations. By default these fields are read-only and automatically maintained by the Salesforce platform.
Common Audit Fields
The most commonly used audit fields are:
- CreatedById — User who created the record
- CreatedDate — Date and time when the record was created
- LastModifiedById — User who last modified the record
- LastModifiedDate — Date and time of the last modification
- SystemModstamp — System modification timestamp (used internally for replication and caching)
Default Behavior & Limitations
By default:
- Audit fields are read-only in the UI and when using Apex DML.
- They are automatically populated and maintained by Salesforce.
- SystemModstamp is entirely system-controlled and cannot be set by users.
When You Need to Set Audit Fields
Setting audit fields manually is a common requirement during data migration or consolidation (for example, when moving legacy data into Salesforce). To preserve original creation timestamps and creators, you may need to set CreatedDate and CreatedById (and sometimes LastModifiedDate/LastModifiedById) to reflect historical values.
How to Enable Setting Audit Fields
Salesforce restricts setting audit fields for data integrity. To allow setting certain audit fields during data loads:
- Open a Salesforce Support case requesting enablement of the feature “Set Audit Fields upon Record Creation” and, if needed, “Update Records with Inactive Owners”.
- Once enabled for an org, you can set specific audit fields during record creation through supported APIs and tools (Data Loader, Bulk API, REST API, SOAP API, Workbench).
What You Can and Cannot Set
After the feature is enabled, you can typically set:
- CreatedById
- CreatedDate
- LastModifiedById (in some scenarios)
- LastModifiedDate (in some scenarios)
SystemModstamp and certain platform-controlled audit values remain non-settable by users. Exact behavior may vary slightly by API and Salesforce release, so always test in a sandbox.
Example: Setting CreatedDate via REST API
After enablement, you can include audit fields in your API payload when creating a record. Example (REST API):
POST /services/data/v56.0/sobjects/Account/
{
"Name": "Legacy Acme",
"CreatedDate": "2020-01-15T10:30:00.000Z",
"CreatedById": "0051x00000123ABC"
}
Best Practices
- Request the audit-fields feature only for trusted orgs and for planned migrations (it should not be enabled for general ongoing use).
- Use a separate migration process & service account to set audit fields (avoid using regular user credentials).
- Validate results in a sandbox before running on production and keep a rollback/export backup.
- Document the migration and reasons for setting historical timestamps for compliance audits.
Alternatives & Complementary Tools
If you cannot set audit fields, consider:
- Adding custom fields to store legacy creation/modified timestamps and actors (e.g., Legacy_Created_Date__c).
- Using Salesforce Setup Audit Trail and Field History Tracking for ongoing change tracking.
- Using Event Monitoring to capture detailed user activity where needed (requires add-on).
Summary
Audit fields in Salesforce provide authoritative metadata about record creation and changes. They are read-only by default to protect data integrity, but Salesforce support can enable controlled setting of certain audit fields for migration scenarios. Always follow best practices, test thoroughly in non-production, and document any changes.