Restore Record Ownership and Salesforce Audit Fields

Restoring proper record ownership when restoring historical data can be a complex operation for several reasons:

  • By default, Salesforce does not permit an inactive user to be the owner of a record.
  • When migrating data from another Salesforce instance, the record owner probably does not exist in the target Salesforce.

While discussing how to manage these issues, this article will also cover a related problem:

  • How to restore original Salesforce audit fields like CreatedDate and LastModifiedDate.

Problem 1: Make Inactive Users Own Restored Records

By default, not even a Salesforce administrator has the privileges necessary to assign an inactive Salesforce user as the owner of a record. However, any user can be granted this ability by:

  • Creating a Permission Set that includes the Salesforce system permission “Update Records with Inactive Owners”.
  • Associating the new Permission Set with a Salesforce user account.

CopyStorm/Restore will recognize that its connection to Salesforce has this elevated permission and do the right thing. If you need additional help, see the Salesforce release notes that introduced this feature.

Problem 2: Control Record Ownership When Users Do Not Exist in the Target Salesforce

This problem most often occurs during a Salesforce migration project. For example, suppose that the Acme company purchased the Dynamo company and the Salesforce team has been told to migrate all data from Dynamo’s Salesforce into the Acme Salesforce.

  • The CopyStorm backup of the Dynamo database contains a record owner named “josiah@dynamo.com”
  • In the Acme Salesforce, “josiah@dynamo.com” will be replaced by the new Salesforce user “josiah@acme.com”.

During the data migration all records owned by josiah@dynamo.com should be transferred to josiah@acme.com once all Dynamo data has been migrated to the Acme Salesforce.

The best practice to address this issue is to create a migration mapping for Users in the CopyStorm/Restore Migration Setup tab. By using the Record Mapping Rule Editor on this tab you can explicitly tell CopyStorm/Restore how to map users in the Dynamo database to users in the target Acme Salesforce. For details see these articles:

Problem 3: Restore Salesforce Audit Fields

By default, not even a Salesforce administrator can write to the standard Salesforce audit fields, including:

  • CreatedById
  • CreatedDate
  • LastModifiedById
  • LastModifiedDate
If you need to restore these fields:
  • Create a Permission Set including the Salesforce system permission “Set Audit Fields upon Record Creation”.
  • Associate the new Permission Set with a Salesforce user account.

CopyStorm/Restore will recognize that its connection to Salesforce has this elevated permission and do the right thing (e.g. restore audit fields).

Problem 4: Restore Salesforce Audit Fields In Chatter

In addition to the audit fields detailed in #3 above, restoring the “CreatedBy” and “CreatedDate” fields for Chatter Feeds requires an additional permission.

If you need to restore these fields:
  • Create a Permission Set including the Salesforce system permission “Insert System Field Values for Chatter Feeds”.
  • Associate the new Permission Set with a Salesforce user account.

CopyStorm/Restore will recognize that its connection to Salesforce has this elevated permission and do the right thing (e.g. restore audit fields).