Restore Best Practices

GRAX Restore Upgraded

Please refer to the new restore documentation. The new updates introduce amazing new features, drastic speed increase, and much more.

Introduction

Restoring data via GRAX is incredibly easy to do with a few clicks, but your Salesforce administrator and team needs 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 isn't 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 gives an 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 should test and validate to prep any environment where you plan to be restoring data:

Scenario	Details
Triggers	Ensure you have validated all custom Apex code/triggers present on any objects that you plan on restoring. You 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
Permissions	Ensure any user who is 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 won't 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 automation
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 doesn't 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 administrator/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 need to have resources who understand your specific environment to validate the use cases.

Object	Considerations
EmailMessage	- 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, Salesforce 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, Salesforce 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 Salesforce'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
Content	- Salesforce Content-related objects also work in unique ways, with multiple standard objects interacting and being auto-created by Salesforce in various ways - When restoring content, select ContentVersion as the main object and ensure you are toggling option to restore children, as this restores ContentDocument, ContentVersion, and ContentDocumentLink - ContentDocument and ContentVersion objects will always show the GRAX Integration User as the owner of the restored record instead of the original owner, due to access restrictions with private user libraries
Documents	- You may want to first restore Document folders before restoring Documents so they get associated to proper folder
Contracts	- Salesforce dictates that when inserting contracts they must have a status of `Draft` - So to restore, you may need to use custom mapping. You could create a custom field in the destination that houses 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 need to use Data Loader 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
Leads	- Validate use case of restoring converted leads as Salesforce has various fields behind the scenes and standard behavior
AccountTeamMember	- Salesforce only allows creation of AccountTeamMember records that are active users

Third-Party Managed Packages

Third Parties Not Supported

GRAX doesn't 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, you'll need to account for 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 to understand and work with your SME on workarounds. For example, "veevatized" environments (Veeva CRM) have special considerations about inserting data. GRAX Restore leverages a basic insert so you 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 runs as the integration user, so the integration user's permissions/profiles 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:

Specify a set of users that should be exempt from said validations, triggers etc.
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.
Use the GRAX Restore Mapping feature to set a default value for a custom field on each object that you would like to be exempt. Since GRAX then updates 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's 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 often implements 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 think they need to restore 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 Global 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 creates a brand new record (with a new Salesforce ID). Salesforce doesn't have a 'restore' function, GRAX uses the 'create' call, so this makes a new ID.

Read-Only Records

There are certain objects that are "read-only" within Salesforce, such as Report. These objects are unsupported for restores due to this and can not be written via a restore job.

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 restores the most recent version of the record

Validation Recommendations

Always conduct initial validation in a development 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 administrator 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 deployments of GRAX:

Step	Comments
Initial Restore Criteria	Obtain criteria for each object you plan on restoring. Do you also want to 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 helps 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 Salesforce 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 to test out various use cases
Confirm Restores	The GRAX restore process is asynchronous so after clicking restore on one or more records, you should 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.