Restore Options

GRAX provides a variety of different options when restoring a record back into Salesforce, so please review all considerations here in order to understand the implications of data creation/updates with GRAX.

Introduction

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.

Defaults

When you first click Restore Options, you will see that the default toggles switched on are the following:

Based on the default settings of all the toggles, it should cover most scenarios and is the safest option, as this will always query against the Salesforce environment to check for the existence of records before re-creating.Based on the default settings of all the toggles, it should cover most scenarios and is the safest option, as this will always query against the Salesforce environment to check for the existence of records before re-creating.

Based on the default settings of all the toggles, it should cover most scenarios and is the safest option, as this will always query against the Salesforce environment to check for the existence of records before re-creating.

📘

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 Mapping section on the other hand does have a Save button and will be remembered across all restores).

Restore Parents vs. Children

Toggle Off (Default): Restore Parent Record Only

By default, this is the state of this toggle. GRAX will only restore the parent/selected record and will not restore any children.

Toggle On: Restore Child Records

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.

📘

Restoring Lookups

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.

In this example where we select a Case to restore, green indicates all objects that would be restored when restoring children.  You can see any lookup fields (parents) would be restored, but the children to those restored parents (e.g. Opportunity) would NOT be restored.In this example where we select a Case to restore, green indicates all objects that would be restored when restoring children.  You can see any lookup fields (parents) would be restored, but the children to those restored parents (e.g. Opportunity) would NOT be restored.

In this example where we select a Case to restore, green indicates all objects that would be restored when restoring children. You can see any lookup fields (parents) would be restored, but the children to those restored parents (e.g. Opportunity) would NOT be restored.

Query Storage vs. Salesforce

Toggle Off: Query Storage Facility

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.

Toggle On (Default): Query Salesforce

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:

User
RecordType
Profile
Product
Pricebook

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.

📘

API Calls

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)

Query History and Salesforce

Toggle On (Default): Query SFDC to confirm record exists

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.

Toggle Off: Query only GRAX History

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.

Insert vs. Update

Toggle Off (Default): Only Insert Records

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.

Toggle On: Update Records if Exists

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).

Assign Record Owners

Toggle Off: Assign Records Only to Active Users

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

Toggle On (Default): Assign records to Active or Inactive Users

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 Owner then 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.