Audit Fields and Your Salesforce Data Migration

From time to time, it is necessary to migrate your Salesforce database -- in part or in whole -- between two instances of Salesforce.  Why might you do this? Your firm may have been purchased by another, and you need to merge your Salesforce orgs. Sometimes the opposite happens, and firms split up, splitting up their Salesforce instances as well.  One situation we see often at Arkus is a total re-think of an instance’s data model in an effort to make it more efficient or effective. In these cases, a migration of the old data to a new org can make it easier to monitor progress, onboard new users, and maintain data integrity to build user trust in the new system.

One of the major drawbacks of a data migration is that you can lose a lot of the “audit field” data in the process.  In some cases, this data is valuable in painting a picture of your org’s creation and usage over time, and you may not want to lose it.  So what is audit field data, why should you care, and how can you preserve it?

What Are Audit Fields and Why Do They Matter?

Audit Fields in Salesforce are special fields that track information about your records that can be valuable for audit purposes.  Typically these fields include:

• CreatedByID
• CreatedDate
• LastModifiedbyID
• LastModifiedDate

On the lead object, you have a few other fields that capture important audit data about your lead and its conversion, but we’ll mostly be talking about these four.  These fields tell you important things ABOUT your data: who created this record in the system and when? Who modified last? When did that modification take place?

In some cases, this data may not be that useful to you.  It may not matter terribly when a customer or a donor’s record was created in Salesforce because you originally imported it from some other legacy system anyway.  But sometimes audit data provides critical insights into how your instance has changed over time, or even more importantly, how effective your organization is at whatever it’s trying to accomplish.  

In the traditional sales model of a for-profit firm, this can look like when opportunities or cases are created over time, especially relative to their close date.  In this use case, preserving the CreatedDate or the LastModifiedBy can give you insights into your sales cycle, the effectiveness of your up-sell or cross-sell strategies, and the speed and efficiency of your customer support efforts.  

For the nonprofit, the value goes beyond just capturing donor giving patterns.  For nonprofits using Salesforce to track program data like key client interactions, achievements, or other events, audit field data can give you longitudinal insight that can validate your theory of change model.  Take this use case for example: a nonprofit gives clients tutoring to pass their GED, and tracks these tutoring events, GED pre-assessments, and GED test attempts.  Preserving the CreatedDate helps you understand how much and for how long different kinds of students need tutoring before they can successfully pass the GED.  

How Audit Fields Work

Now that we know what audit fields are, and we know they can be incredibly useful, how do they work?  These fields are set through the API (application program interface) only; this means that you cannot click on the field in the user interface and change them.  Rather, they can only be changed by the system itself. They are populated automatically by Salesforce whenever a record is created or edited.  

Thankfully, back in the Winter ‘16 release, Salesforce gave us access to these fields through tools that can make API changes, like Salesforce Data Loader.  It’s worth mentioning that there are advanced admin tools out there to help the experienced admin navigate this process; the Force.com IDE and the Jitterbit Cloud Data Loader for Salesforce both deserve a shout-out here.  There’s tons of great content available on how to use these tools effectively, but for the beginner admin they can be a bit intimidating.  Never fear! You CAN preserve audit field data with good old Data Loader, and this post will show you how.  

Setting Up the Permissions

Before you can update your audit fields, you need permissions to do this in the system.  Step 1 is to enable the organization-wide setting.

To access this, the click path in Lightning is: Setup -> User Interface -> User Interface.  

In Classic, it’s:  Setup-> Customize-> User Interface.  

On this panel, check the “Enable ‘Set Audit Fields upon Record Creation’ and ‘Update Records with Inactive Owners’ User Permissions.”

Step 2 is to ensure that whomever you plan to give this permission to also has “Modify All Data” permission.  The system administrator profile has this enabled by default, and this makes sense because typically this sort of function is something only a system administrator would likely be doing anyway.

Step 3 is to add this permission either to a Profile or to a Permission Set.  It’s commonly added to a profile, but I’m going to advocate for using a Permission Set here.  Because of the valuable nature of audit fields, this isn’t a permission you want to leave activated perpetually; it’s best to have it active during a migration and then deactivate it when you’re done to avoid accidentally adding records later with the wrong audit field data.  Further, if you have multiple administrators working together, you may not want all of them to have this ability. Creating it as a permission set is a quick and easy way to extend and withdraw the permission as appropriate.  

Whether it’s from the profile or from the permission set, the setting lives in the System section of the profile/permission set… conveniently the same place “Modify All Data” lives.  The click path in Lightning is: 

Setup-> Users-> Profile or Permission Set -> the actual Profile or Permission set you want to use -> System Permissions -> Set Audit Fields upon Record Creation.  

In Classic it’s:

Setup-> Manage Users, and then the same after that.  

Setting Your Audit Fields

Once your permissions are configured, you’re ready to go.  You need only format your .csv import file as you normally would, but keep your old audit fields.  When you match your fields in Salesforce to the columns in your .csv file, simply map your own audit field, like “CreatedDate,” to the new and now available to choose from “CreatedDate” audit field in Salesforce.  Import your data as you normally would, and Salesforce will overwrite the CreatedDate with the value in your .csv file, which originated in your old org. Ta-Dah! Now your new org shows these records as created and/or last modified on their original date, even though your spiffy new org didn’t even exist at that time.  Your longitudinal data is preserved!

If you wish to preserve “CreatedBy” and “ModifiedBy” data there is an extra step because UserIDs are unique to each instance.  In other words, the user record ID for a given user in your old instance will be different than their user record ID in the new instance.  In this case, if you want to preserve their identity as the creator or modifier of data, you will need to replace their old ID with the new one in your .csv file before you perform the import.  

There are some limitations of this feature.  For starters, it probably won’t surprise you to know that you can’t update the audit fields on every object in Salesforce, though the list comes close.  There’s a list in the relevant Knowledge Article in the Trailblazer Community, but it’s most of the major objects and all custom objects.  Second, you cannot change the audit fields using the Update or Upsert functions; only Insert.  This feature is limited to record creation, not editing. Finally, if you have triggers in your org that update a record in any way at creation, they will run AFTER your import, overwriting the old org LastModifiedDate and LastModifiedBy fields you so carefully tried to preserve.  To prevent this from happening, you will need to disable these triggers first.  

With a little care and a few extra steps, you can make sure your cross-org data migration retains as much data as possible, including the rich and meaningful audit field data!  As with all data migrations, the key is thinking through the project and making a solid plan beforehand. The planning will pay off in a more robust and detailed data set.  

Ever migrated your Audit Field data?  Need help with your data migration? Tell me all about it in the Salesforce Trailblazer Community or tweet directly at me on Twitter @hayleytuller.