Why Are the LastModifiedBy and LastModifiedDate Values Wrong on My Restored Record?

Though CopyStorm/Restore can faithfully restore Salesforce audit fields, there are a number of cases where the LastModifiedBy and LastModifiedDate fields cannot be restored. This article explains why.

If both the CreatedBy/CreatedDate and the LastModifiedBy/LastModifiedDate fields are not being restored accurately then the answer is simple. The Salesforce credentials in use are missing the necessary privileges to write to audit fields. See the article on Restoring Audit fields for instructions to enable this Salesforce feature.

If your Salesforce credentials do have the proper permissions, then several other conditions can cause the LastModifiedBy and LastModifiedDate fields to fail to match the values in the CopyStorm database. To understand the condition details, you must first understand what the option Salesforce permits on audit fields means. The permission that allows writing to Salesforce audit fields is called:

  • Set Audit Fields upon Record Creation

The permission means exactly what it says: Audit fields can be set on a record INSERT but NOT on a record UPDATE. This “feature” is at the core of why CopyStorm/Restore cannot always restore the LastModifiedBy/LastModifiedDate fields to match what is in the backup.

The rest of this article describes scenarios where CopyStorm/Restore is forced to UPDATE records and thus change their LastModifiedBy and LastModifiedDate fields.

Case 1: Circular Relationships

Though CopyStorm/Restore will always restore records in the optimal dependency order, circular relationships can make the order ambiguous. Consider the following case we have seen with multiple Salesforce instances.

  • The Account table has a field called PrimaryContactId — a reference to a Contact record.
  • The Contact table has a field called AccountId — a reference to an Account record.

Here is how CopyStorm restores these records.

  1. Restore Account records and keep track of all occurrences of PrimaryContactId that are not yet known (because the Contact table has not yet been processed).
  2. Restore Contact records.
  3. Use the Ids on the restored Contact records to patch the Account.PrimaryContactId fields that were skipped when Accounts were inserted.

It is Step #3 that causes the LastModifiedBy/LastModifiedDate values on Account records to change to the Salesforce credentials running CopyStorm/Restore. Unfortunately there is no other choice since:

  • Salesforce does not permit writing to audit fields on update.
  • The Account records have to be created before the associated Contact records making step #3 required.

Case 2: Salesforce Record Creation by Side Effect

Some Salesforce record types are created as a side effect of creating another record and CopyStorm has no control of over the audit field values for records created by side-effect. Common examples include:

  • ContentDocument records are created as a side effect of inserting a ContentVersion record.
  • OpportunitySplit records can be created as a side effect of inserting an OpportunityTeamMember.
  • ContentFolder records can be created as a side effect of inserting a ContentWorkspace.

Case 3: Salesforce Record State Restrictions

There are a number of record types in Salesforce that do not support an INSERT operation when they are in specific state. In this case CopyStorm/Restore will often:

  1. Create the record in a state that allows INSERT.
  2. Update the record to match the original values in the database record to restore.

Step #2 causes the LastModifiedBy/LastModifiedDate values to be different that those on the original record in the backup. Common examples include Lead and Contract.

Case 4: Side Effects of Triggers or Workflows

It is possible for the side effect of a trigger or workflow to cause an update on a record restored by CopyStorm/Restore. Though CopyStorm/Restore supports disabling of triggers/workflows during a restore, the problem still comes up for several reasons.

  1. The CopyStorm/Restore user “forgets” to disable a trigger/workflow.
  2. The trigger/workflow is part of a managed package and Salesforce does not support their disablement.

My Users Expect 100% Accuracy for Audit Fields. What Should I do?

Users can expect 100% accuracy as much as they want but any application using the current Salesforce API will not be able to deliver this level of performance. The only choice we know of for getting 100% accuracy is to hire Salesforce to perform the restore and then pay many $$$ and wait. Once a 100% person sees the cost and wait time we suspect they will live with a few audit fields being different.