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.
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.
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
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
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.
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.
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.
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:
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 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.
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.
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.
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.
When selecting and restoring multiple records at a time, GRAX will restore the most recent version of the record
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?
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
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
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.
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)
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.
Updated 9 months ago