On the GRAX
Search tab, you will see a button named
Restore Options. The toggle switches available via this button allow you to customize options that are relevant when you restore/recreate a record in Salesforce. There are a variety of different scenarios and use cases depending on where/how you backed up your data and where/how you are restoring. This article will describe in detail the various options and considerations.
When you first click
Restore Options, you will see that the default toggles switched on are the following:
You do not need to explicitly save the page when setting any of the toggles or the restore hierarchy; GRAX is only using these options for the particular session and not saving for all time (the
Restore Mappingsection on the other hand does have a Save button and will be remembered across all restores).
By default, this is the state of this toggle. GRAX will only restore the parent/selected record and will not restore any children.
This toggle setting will restore the parent and all children. GRAX will restore all the way down the tree i.e it will restore all children of the selected element, as well as children of the children etc. GRAX will also restore 'up the chain' in the sense that it will populate any lookup fields it can find. A rule of thumb is that a lookup field is like any other field so if we are restoring a record, we will try to populate all lookup fields. However, it won't restore children of any of these lookup records that it finds as it goes up the chain; only the children of the selected element/record on the restore page will be restored.
Although GRAX will try to find related parents and children, where it looks for those parents (Salesforce vs. GRAX Data Lake) is determined by some of the other toggle switch settings that we will describe here.
This means that GRAX will only query the data lake when trying to restore records, populate lookups etc. It will not query this Salesforce environment at all.
For example, let's see you are restoring a Case record and expect the Case's
Contact lookup field to be populated upon restore. With this setting enabled, that Contact record MUST exist in your datalake already or else GRAX will not be able to find it and populate the lookup.
Example Use Case
Let's say you have backed up all records from a Source Salesforce environment and want to restore into an empty Destination Salesforce environment. You are already 100% sure all the records exist in the GRAX Data Lake, and thus you do not need to additionally query Salesforce (which uses API calls) in addition to the Data Lake, so this toggle setting makes sense.
If we have this toggle switch enabled, in addition to querying the Data Lake, now we can also query Salesforce (only specific core "non-data" objects). With this setting enabled, we will query Salesforce, but only the following objects:
The reason enabling this toggle only queries across these 'special' objects is that we will assume these objects exists in the Salesforce environment you are restoring into. For example, when you create/refresh a sandbox, these core "non-data" object types will exist.
In order to query all Salesforce data/objects besides the above, you will need to further set the next toggle that we will describe below.
Any time you are querying Salesforce across any of these options, it will consume API calls (1 API credit per lookup, so this can escalate exponentially if you have lots of lookups on a record and it restores up and down the chain)
By default, this setting will query both the GRAX History Table as well as SFDC. We always query the GRAX History Table regardless of this toggle being on or off, so you are essentially deciding if you also want to query Salesforce. This toggle switch will only be relevant if you enabled
Query SFDC in the above toggle. It means that all Salesforce data objects are queried, whereas the above toggle only queries the core non-data objects as described above.
For example, if the record was found in the history table but not in Salesforce, it would be recreated. If the record was found in the history table and in Salesforce, it would be updated (if the update toggle is enabled).
Example Use Case
This should be enabled if restoring into a Full Copy Sandbox since the record was NOT restored with GRAX, but the record would exist in the full copy sandbox likely with the same ID, so you would want to prevent duplicate from being created. Additionally, if a record has been restored and then later deleted, you would want to be sure you're querying Salesforce to check for its existence.
The GRAX History system table keeps track of every record restored. Selecting this option means you will query only the GRAX History Table and will not query Salesforce data.
Example Use Case
If you were restoring into a blank environment, you would probably not want to query Salesforce and waste API calls.
By default the restore will insert records only. The other toggles discussed here will determine if the record already exists in Salesforce, and thus whether we want to insert it.
This will allow the update of records if they are found (based on the other toggles discussed here that determine how/where to query to determine if record exists).
Restore Does Not Overwrite With Null Value
If your Salesforce records has data in certain fields, the GRAX restore will never overwrite that data with a null. GRAX will only restore/update the fields that were populated from the most recent version of data, in order to ensure data integrity for potential updates to a record since it was backed up.
If you are interested in restoring to a specific point-in-time, you can use time machine (which has the option to overwrite with blanks).
Will query Salesforce (API usage) and assign record ownership based on the following:
- If owner is active user in Salesforce environment, then will assign ownership to this user
- If owner is inactive user in Salesforce environment, then will assign ownership to running user
With this toggle setting enabled, GRAX does not query to see whether the record owner is active or inactive; instead GRAX will assume the running/restoring user has the permission enabled and thus will be able to assign record owner whether that user is active or inactive.
If the running/restoring user does not have the necessary Salesforce permission to
Update Records with Inactive Ownerthen restore of records that have inactive owners will fail.
Restore options are set back to the defaults each time you view the Search tab. Be sure to confirm your setting before restoring records.
Updated over 1 year ago