Understanding Salesforce audit fields for data migration

Posted by Vinay Vernekar 27th September 2025

Ever wondered why you can’t just change a record’s creation date? We’re talking about Salesforce audit fields, those system-managed timestamps that tell the story of every record in your org. If you’ve ever done a data migration, you know exactly how frustrating it is when your legacy data suddenly looks like it was all created “today” by “Admin User.”

What exactly are Salesforce audit fields?

Think of these fields as the black box of a record. They track the “who” and the “when” for every single insert or update. By default, they’re strictly read-only because Salesforce uses them for data integrity and compliance. You’ll see them on almost every object, and they usually include:

  • CreatedById: The user who first hit save.
  • CreatedDate: The exact moment the record was born.
  • LastModifiedById: The person who last tweaked the data.
  • LastModifiedDate: When that last change happened.
  • SystemModstamp: This one is purely for the system – it’s used for things like search indexing and replication.

Now, here’s the thing. While you can see these fields in a report or on a page layout, you can’t touch them through a standard edit. But what happens when you’re moving five years of history from an old SQL database into a fresh org? You don’t want every record to show today’s date. That’s where things get interesting.

How to enable Salesforce audit fields for migrations

If you’re planning a big move, you’ll need to bypass the standard read-only rules. In the past, you had to open a support case and practically beg for permission. Thankfully, Salesforce made it easier. You can now enable a setting called “Set Audit Fields upon Record Creation” directly in your User Management Settings.

Once you flip that switch, you can assign the “Set Audit Fields” permission to your migration user via a permission set. But don’t just leave this on for everyone. I’ve seen teams leave this enabled for regular users, and it’s a recipe for data chaos. Keep it locked down to your service account or migration lead.

The catch with inactive owners

One thing that trips people up during migrations is trying to map records to users who no longer work at the company. If you try to set a CreatedById to an inactive user, the system will throw an error. You’ll actually need to enable another setting called “Update Records with Inactive Owners” to make this work. I’ve written a more detailed guide on assigning records to inactive users if you’re stuck on that specific hurdle.

Practical tips for your data migration

When you’re ready to start pushing data, you’ll need to use the API. Tools like Data Loader, Workbench, or the Bulk API are your best friends here. Here is a quick example of what a REST API payload looks like when you’re targeting Salesforce audit fields:


POST /services/data/v60.0/sobjects/Account/
{
  "Name": "Legacy Client Corp",
  "CreatedDate": "2018-05-20T09:00:00.000Z",
  "CreatedById": "005XXXXXXXXXXXXXXX"
}

But wait – there’s a limit to what you can do. Even with the special permissions, you can’t update these fields on existing records. This only works during the initial insert. If you’ve already loaded 50,000 records and forgot to set the dates, you’re looking at a delete-and-reload scenario. Trust me, I’ve been there, and it isn’t fun.

Pro Tip: Always run a small test batch of 10 records in a sandbox first. Check the timestamps in a SOQL query to make sure the time zones didn’t get mangled during the CSV export.

Best practices for data integrity

So why does this matter? Well, if you’re in a regulated industry like finance or healthcare, your auditors will care deeply about these dates. If you’re also dealing with heavy automation, you might want to check out how Salesforce Flow handles data integrity to make sure your migrations don’t trigger a bunch of unwanted emails or tasks.

  • Use a dedicated migration user: Don’t use your own admin account. It makes it way easier to identify which records were part of the import later on.
  • Watch your time zones: Salesforce stores everything in UTC. If your source data is in EST, you’ll need to do the math before you upload.
  • Document the “Why”: If an auditor asks why a record says it was created in 2015 but the org didn’t exist until 2024, you’ll want a paper trail.

Key Takeaways

  • Salesforce audit fields are system-managed and read-only by default to ensure compliance.
  • You can enable the ability to set these fields for migrations through User Management Settings.
  • You can only set audit fields during record creation, not on updates.
  • Always use a sandbox to test your CSV headers and date formats before hitting production.

At the end of the day, Salesforce audit fields are there to protect the truth of your data. Use the “Set Audit Fields” feature when you absolutely have to for a migration, but treat it like a power tool – use it carefully and put it away when you’re done. If you can’t enable it for some reason, your fallback is creating custom “Legacy Created Date” fields, but that usually just clutters up your schema. Do it the right way if you can.

Tags: