# Step 2: Configuration

## Step 2: Configuration

The *Configuration* stage defines the high-level restore job configuration: what the job is called, which Salesforce org is being restoring into, how the restore behaves (restore type), and a few “be careful with this” options like field selection/masking, related record depth, and Salesforce automation behavior.

![](/files/ow8dq27aIarYmuOj01hj)

## Job Details

### **Name**

Give the restore job a clear name (example: Restore Accounts – Sandbox QA – 2025-12-16).

### **Description**

Optional, but useful for notes like *why* performing the restore or what filters were used.

### **Restore Type**

Controls **how the restore writes records into Salesforce.**

#### **Insert and Update**

* Inserts records that **don’t exist** in the target org.
* Updates records that **already exist** in the target org.
* Best choice for “bring my data back” restores when not 100% sure what already exists.

#### **Insert Only**

* Only inserts **new** records.
* Does **not** modify existing records.
* Use when loading data into an org and want to avoid overwriting anything already there (common for seeding sandboxes / partial restores).

**Gotcha:** If records already exist (based on whatever matching/key logic is used later in the wizard), they’ll be skipped rather than updated.

#### **Update Only**

* Only updates records that **already exist** in the target org.
* Does **not** create new records.
* Use when you’re correcting or reverting fields on records you know are already present.

**Gotcha:** If a record doesn’t exist in the target org, it will not be created-so you can end up with a partial restore if assumptions are wrong.

## Salesforce Org

Select the **target Salesforce org** where data will be restored.

* This list is populated from entries you’ve configured under **Salesforce Credentials.**
* If this dropdown is empty, go set up credentials first.

## Related List Depth

Related List Depth

Controls how far the restore should go **down the relationship tree** from the selected top-level object (related lists / child records).

### None

* Restores only the top-level object records selected.
* Fastest and least intrusive option.

### **1 Level / 2 Levels / 3 Levels**

* Restores the top-level records plus related records **up to that depth.**
* Use when need a predictable amount of related data.

**Practical example**

* Restoring Accounts:
  * **1 Level** might include direct children like Contacts (depending on your schema)
  * **2+ Levels** starts pulling in grandchildren (e.g., Contact → Cases, etc.)

### **All**

* Restores the full related hierarchy (as far as the restore tool can traverse).
* Use when need completeness and are okay with a bigger restore job.

**Gotcha:** “All” can balloon the record count fast in complex orgs.

### **Custom**

* * Lets you define a **custom depth and/or relationship selection rules** (implementation-specific).
* **Use when:**
* * You need deep restore for *one* relationship branch, but not others

The numbered depth options are either too shallow or too broad

## Automation

Controls whether Salesforce automation is disabled during the restore.

### **Do Not Disable Automation**

* Leaves automation on (Flows, Workflows, Process Builder legacy stuff, Triggers, etc.).
* Use when automation is part of the intended behavior and want restored data to be processed normally.

**Gotcha:** Automation can modify restored values immediately, create additional records, or block changes with validations-so “restored” state might not match the backup perfectly.

### **Disable All Automation**

* Attempts to disable Salesforce automation before restore and re-enable it after.
* Use when want the restore to be as “pure” as possible and avoid side effects.

**Gotcha:** Disabling automation can have org-wide impact while the job runs. Use with care, and ideally in lower environments unless having a clear operational plan.

### **Custom**

* * Lets the disablement a **specific subset** of automation (implementation-specific).
* **Use when:**
* * Knowing exactly which triggers/flows/validations are the problem

The desire is to minimize blast radius compared to “Disable All”

## Save and Move Forward

### **Save Changes**

Click Save Changes after completing required settings.

### **Next Step**

**Next Step** stays disabled until required fields are filled (Name, Restore Type, and Salesforce Org at minimum). Once saved, proceed to **Scan Records.**

### **Previous Step**

Go back if needed to change the selected record set before committing configuration.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://learn.capstorm.com/snowflake-salesforce-connector/reference/restore/step-2-configuration.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.