Restore Best Practices

Let's take a look at recommendations, best practices, and necessary preparation that will be required before kicking off a GRAX restore


Restoring data via GRAX is incredibly easy to do with a few clicks, but your Salesforce Admin and team will need to prepare the environment and ensure all considerations are taken into account. Unlike backing up data, restore involve modifying data in your Salesforce org (inserts/updates) which can have unintended consequences if the necessary preparation and validation is not done. GRAX simply leverages standard Salesforce inserts and updates, but depending on the way your schema is constructed, there are several rules and cascading impacts that can affect your data. This article will give you a good idea of what to expect and best practices we have seen with customers that are successful with restoring across large amounts of data and with complex logic.

General Restore Considerations

Let's take a look at some of the more common scenarios that you will want to test and validate to prep any environment where you will be restoring data:




Ensure you have validated all custom apex code/triggers present on any objects that you will be restoring. You will need to determine how you want to handle these scenarios. For example, triggers could be preventing inserts of certain records, or kicking off updates across other related records etc.

Validation Rules

One of the most common scenarios is restoring a record that may have met all validations previously, but no longer meets and is blocked from insert/update


Ensure any user who will be restoring data has the correct permissions to do so. If a user tries to restore a custom object for which they have no access to create via their Salesforce permissions, this will not be allowed. Or if a user tries to restore and set a record type which they don't have access to, for example. Outlining your business use cases for restore and ensuring proper compliance with existing Salesforce architecture is critical.

Workflow / Process Builders

Understand implications of restoring data and firing relevant rules and automations

Lookup Filters

Another common area where restores are blocked due to restored records not matching required lookup filter criteria. Easiest way to avoid this is to make lookup filters optional.

Restricted Picklist Values

Review picklist fields that might be set as restricted and thus block incoming values via a restore

Required Fields

Any changes to required fields could cause issues if incoming restored data does not meet criteria

Duplicate / Matching Rules

Incoming restored records may be blocked by duplicate rules set up, which may be intended and desired behavior depending on use case.

Set Inactive Owners

As described in the GRAX Restore options article, be sure this user permission is enabled for the restoring user if you are trying to restore records and set inactive users as record owners.

Example Object Considerations

Salesforce has various behind-the-scenes restrictions and rules on many standard objects. Please be sure your Admin/SI has verified restore of all scenarios and relevant objects in your sandbox, as very often this could uncover a Salesforce standard rule and/or a custom rule put in place that blocks the restore. The GRAX tool has features such as custom mappings that can aid in getting the data restored successfully, but you will need to have resources who understand your specific environment to validate the use cases.




  • ValidatedFromAddress is a restricted "behind the scenes" populated from org wide addresses.
  • Can use GRAX restore mapping to map ValidatedFromAddress to an org wide address if needed
  • ValidedFromAddress must match FromAddress
  • With enhanced email enabled, SFDC auto-generated a task record "behind the scenes" upon creation of EmailMessage record. If you restore a task first, and then later restore the EmailMessage record, SFDC would auto-create another task and there may appear to be duplicates in related lists. We recommend validating and restoring only emailMessage record and accounting for SFDC's auto-creation of task.
  • May also get insufficient access rights errors on certain private emails that don't have RelatedToID if you don't have access


  • SFDC Content-related objects also work in unique ways, with multiple standard objects interacting and being auto-created by SFDC in various ways
  • When restoring content, select ContentDocument as the main object and ensure you are toggling option to restore children, as this will restore ContentDocument, ContentVersion, and ContentDocumentLink


  • You may want to first restore Document folders before restoring Documents so they get associated to proper folder


  • SFDC dictates that when inserting contracts they must have a status of Draft
  • So in order to restore, you may need to use the custom mapping functionality. You could create a custom field in the destination that will house the true contract status
  • Map contract standard Status field to the new custom field (let's call it Original Contract Status)
  • Default the standard Status field to Draft.
  • After restoring everything you will need to use dataloader to do an update and set the standard Status field back to it's true status using the value that was stored in the custom Original Contract Status
  • Also, once a contract has an activated status category, you can edit every field EXCEPT you cannot change the status back to Draft or you can't change the Account


  • Validate use case of restoring converted leads as SFDC has various fields behind the scenes and standard behavior


  • SFDC only allows creation of AccountTeamMember records that are active users

Third-Party Managed Packages



GRAX does not support restoring data for third party package customizations/objects such as FinancialForce, Veeva etc. You do so at your own risk, given the various customizations these third party packages can include that may prevent and have unintended consequences on DML operations.

As you saw with archive considerations, you will need to account for similar potential customizations when restoring data. There can often be triggers and managed package code either preventing inserts or validating data upon insert. Test the use case in a sandbox in order to understand and work with your SME on workarounds. For example, "veevatized" environments (Veeva CRM) will have special considerations around inserting data. GRAX Restore leverages a basic insert so you will need to understand those implications for the specific objects you choose to restore.

Exceptions to Allow Restore

As mentioned in the general considerations above, the GRAX restore will run as the integration user, so the integration user's permissions/profiles will apply. So just like any other record creation in Salesforce, this user needs the correct permissions. If there are validations/triggers, for example, blocking the insert of a new record, you can either address the root cause (bad data, for instance), or you can create exceptions within the triggers/validation rules to allow for records to be restored. There are a few of ways to do this, including but not limited to:

  1. Specify a set of users that should be exempt from said validations, triggers etc.

  2. For some customers, not all users should be able to restore data. Often there are change management procedures put in place that funnel restore requests to a single point of contact. If this is the case, you can use the designated 'integration' user for all restores and thus more easily exempt this user from relevant triggers and validations.

  3. Use the GRAX Restore Mapping to set a default value for a custom field on each object that you would like to be exempt. Since GRAX will then update this 'flag' field upon restore, you can use this field for exemptions within the validation rule, for instance.

Change Management

As a best practice, many Salesforce customers implement an internal change management process to ensure any configuration changes are sent through the proper approval flow, tested, and deployed. It is important to ensure GRAX is integrated into your existing change management process. For example, submitting a request for a new validation rule on the Case object could impact users who typically restore cases via GRAX. This should go through a layer of additional validation based on objects that are involved in GRAX processes.

Customers also will often implement an approval process for restores where there is one superuser designated for restoring records and other users must submit request for restore with reasoning. Oftentimes, business users will think they need to restore a data but really they just need to view certain information about the archived record. We always recommend first seeing if the restore use case can be solved with GRAX search and visualization options , before confirming if you actually do want to insert new records into your environment.

Other Considerations


Restoring Archived Records

When you restore an archived record, this will create a brand new record (with a new Salesforce ID). Salesforce does not have a 'restore' function, GRAX uses the 'create' call, so this will be a new ID.


Audit Fields

If you would like certain audit fields restored, please ensure you have the correct permissions set up to open these fields up, and review all Salesforce considerations for audit fields. For instance, these can only get set upon record creation.


Mass Restore

When selecting and restoring multiple records at a time, GRAX will restore the most recent version of the record

Validation Recommendations

Always conduct initial validation in a dev environment, and then follow that up by validating fully in a staging/full sandbox. Expect to run into a few of the 'gotchas' outlined in this article. While GRAX facilitates the restore process, each org is different and you must rely on your Admin and/or SI to conduct the proper testing and validation.

In larger, more complex Salesforce environments, GRAX recommends setting up policies and procedures specifically for the restore process. Given that the restore process is essentially equivalent to inserting records (potentially multiple records and relationships) a careful analysis of potential impacts is necessary. This article provides several considerations to work into your validation and go live process, but in general we have found that following these high level steps result in successful implementations of GRAX:



Initial Restore Criteria

Obtain criteria for each object you plan on restoring. Will you also restore children with the parent?

Technical Checklist

For each restore use case/criteria, have someone familiar with all customizations within the environment go through each object that may be restored. Use the 'gotchas' in this article as a starting point for listing out configurations in your environment that may block or interfere with inserts/restores

Business Checklist

For each restore use case/criteria, have someone familiar with all customizations within the environment's business process go through objects and provide feedback on how business process could be affected if certain objects (and their relationships to other objects) are recreated or inserted again. For example, would this fire off an undesired workflow email alert?

Review Checklists with GRAX Sponsors

Before running any restores even in sandboxes, ensure the initial technical and business checklists are reviewed with the GRAX sponsors as this exercise will help various teams be on the same page regarding a specific org's restore needs. Very often we find that a use case for restore is really just a use case for visualizing the archive data rather than an actual need to recreate the data back into Salesforce and impact SFDC data storage limits.

Archive Relevant Records

To set up the restore of records, first archive some small datasets so that you can subsequently restore/recreate

Test Restore Use Cases

Now use the GRAX restore functionality to test out various use cases

Confirm Restores

The GRAX restore process is asynchronous so after clicking restore on one or more records, you will want to navigate to the Logs tab and view restore logs to see which records were created or may have failed due to a validation rule for example. Also be sure to do click-testing to ensure the records were created successfully and were not impacted by any other business processes.

Address Findings

Once you have conducted enough testing, you should have a list of findings. For instance you could have a handful of validation rules and triggers that you need to address. Depending on the individual restore use case for specific objects, you may want to create exceptions (described more in this article)

Final Validations

If you do edit any existing metadata, be sure to re-test the restore use cases before going to Production

Ongoing Change Management

Even after you are restoring records in Production, we recommend putting a process in place within the change management practices within your company. For instance, if new triggers/validations are built, they should be analyzed with respect to potential impacts on existing restore use cases, before deployments.