The Salesforce Credentials page allows fast and easy registration of Username/Password Salesforce Credential(s) associated with Org(s) to be backed up or to upload records from Snowflake. Salesforce credentials are stored securely in the Snowflake Secrets Library.

To add new Salesforce credentials, click the Add Credentials button in the top right corner of the page. This will open a small panel that allows input for a Salesforce user’s instance type (Sandbox or Production), username, password, and optional security token. It is recommended to use the Test Connection button to validate the credentials against Salesforce before saving the credentials.

To edit any previously saved credentials, click the icon in-row for the credentials to update. All information must be re-input for updating the credential information.

The Configuration List View page of the application allows a user to view all previously created Salesforce replication configurations, create new configurations, and update previously created setups.

NOTE: Once a configuration is saved, it cannot be deleted.

To create a new Salesforce replication configuration, click the New Configuration button in the top right of the page. This will navigate to the page, allowing input for Salesforce credential information, selection of objects to replicate, and other configuration options.

After a Salesforce replication configuration is successfully saved, it will appear in the table on this page. If modifications need to be made to the existing configuration, click the Edit button in-line with the configuration to edit. This will navigate to the page with the previous information populated on the page.

Release Date: 05-Feb-2026

This is a standard GA release of the Snowflake CapStorm Salesforce Connector containing changes for performing record uploads from Snowflake to Salesforce, bug fixes, and improvements to the application.

Snowflake CapStorm Salesforce Connector Updates

Major Changes

• The CapStorm/Container now comes with a data recovery feature that can be used to upload record data from Snowflake to Salesforce.

• Provided the ability to input additional Salesforce username/password credentials for use with data recovery to Salesforce.

Improvements

• Resolved issue preventing the application warehouse from auto-suspending between jobs.

• Resolved issue preventing auto-resume of scheduled tasks when Snowflake moves the application between hosts.

• Resolved issues preventing Salesforce replication in AWS Gov Regions.

• Resolved issue preventing data copy to non-default databases.

• CapStorm/Container: 5.0

• CopyStorm: 10.64.3

• CopyStorm/Medic: 10.64.3

• CopyStorm/Restore: 10.64.4

The job viewer page allows a user to see more information about a selected job from the Jobs table on the Home page. The Job Viewer contains two sections: Job Tasks and Job History.

The Job Tasks section of the Job Viewer page displays information about the tasks that run under the selected job including the task type as well as the configuration profile used for the task. As well, the next run time and the schedule for the task are displayed. It is important to note that the schedules displayed are in UTC, while the next run times are displayed in the local time.

The Job History section of the Job Viewer page displays information about previous runs of tasks in the selected job. By default, task executions going one week in the past are displayed, but more (or less) information can be displayed using the History From and History Through options.

The Restore tab allows viewing, creating, modifying, and running Salesforce record restorations from a target Snowflake database previously used to back up Salesforce data.

Release Date: 05.Aug.2025

This is a standard GA release of the Snowflake CapStorm Salesforce Connector containing changes for the backing storage of application metadata, bug fixes, and improvements to the application.

The version 2.0 CapStorm Salesforce Connector does not auto-update to 3.0. To upgrade from a previous version, please contact support@capstorm.com.

Snowflake CapStorm Salesforce Connector Updates

Major Changes

• The application now allows for multiple configurations to replicate data from multiple Salesforce organizations.

• Application configuration and scheduling data are stored in the Snowflake schema DIRECTOR. Previous releases stored this data in a separate PostgreSQL container – with this release, application configuration and scheduling data is directly exposed in Snowflake.

• The Snowflake CapStorm Salesforce Connector now leverages the Snowflake Secrets Library to store Salesforce credentials.

• Added new 5 minute option for job scheduling.

• Improved help text for notification integrations to include example SQL to enable email notifications.

• Added a list view to support replication of multiple Salesforce organizations.

• Updated the configuration UI with a comma separated input for mass-selection of objects to replicate.

• Resolved a performance issue when using the object filter on the configuration page.

• Fixed an issue preventing the “Test Email Deliverability” feature from successfully sending test email messages.

• CopyStorm: 10.64.1

• CopyStorm/Medic: 10.64.2

• CopyStorm/Director: 2.64.1

Release Date: 15.Apr.2025

This is a standard GA release of the Snowflake CapStorm Salesforce Connector containing bug fixes and improvements to the application. As always, Snowflake CapStorm Salesforce Connector installations are backwards compatible.

Snowflake CapStorm Salesforce Connector Updates

Improvements

• Add support for the OAuth Client Credentials flow for Salesforce authentication in the Setup page.

• Made Security Tokens optional in the Setup page for sites that do not require Security Tokens.

Bug Fixes

• Fixed issue where the provided schedule on the job viewer page could show an error message when providing ranges for day(s) of week (i.e. “Mon-Fri” or “2-6”).

• CopyStorm: 10.62.2

• CopyStorm/Medic: 10.62.2

• CopyStorm/Director: 2.62.2

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.

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.

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

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

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

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

• Restores only the top-level object records selected.

• Fastest and least intrusive option.

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

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

• • Lets you define a custom depth and/or relationship selection rules (implementation-specific).

• Use when:

The numbered depth options are either too shallow or too broad

Controls whether Salesforce automation is disabled during the restore.

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

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

• • Lets the disablement a specific subset of automation (implementation-specific).

• Use when:

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

Click Save Changes after completing required settings.

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

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

The Summary step of the Restore Wizard provides a high-level report of the restore job: what ran, where it restored to, how many records were restored/skipped/marked error, and an activity log that can be used for auditing and troubleshooting.

Details Section

The Details panel summarizes the restore job configuration that was ran:

• Name – the restore job name entered in Configuration.

• Parent Object – the top-level object restored (example shown: Account).

• Source Connection – the backup database/source used for the restore (example shown: PostgreSQL).

• Type – restore type used (example shown: Insert And Update).

• Target Connection – the Salesforce org connection restored into (example shown: Sandbox).

Use this section as your “receipt” to confirm:

• Restored the right object(s),

• From the right backup source,

• Into the right Salesforce org,

• Using the intended restore mode.

This panel gives an at-a-glance breakdown of restore outcomes using a pie chart and counts.

There’s a dropdown above the chart (example shown: All Objects) that allows switching between:

• A combined view across everything restored (All Objects), or

• A specific object view (useful if one object had lots of skips/errors).

The results are grouped into three buckets:

• Restored – records successfully written to Salesforce (inserted and/or updated).

• Skipped – records not written due to restore rules or conditions.

• Errors – records that failed due to Salesforce/API/validation/permission issues.

Next to Skipped and Errors, see Click to view links. Use these to jump directly into the underlying details (to see which records were skipped/errored and why).

• A lot of Skipped can be normal depending on restore type (Insert Only / Update Only) and the state of the target org.

• Any meaningful Errors should be reviewed-errors mean Salesforce rejected changes or the restore couldn’t complete operations as planned.

The Activity Log is a timeline-style log of what happened during the restore (status updates, steps, notable events).

Filter the log by time window:

• All Time

• Last Year

• Last Month

• Last Week

Use this when:

• Running multiple restores and want to isolate the relevant one,

• Comparing outcomes across runs,

• Troubleshooting something that happened recently.

Entries are grouped (example shown: Today) and show how many log entries exist for that period.

Before clicking Finish:

1. Check the Details panel to confirm you restored into the correct target org.

2. Review the Records Restored breakdown.

3. Click into Errors (and Skipped, if unexpected) to confirm you understand the outcomes.

4. Use the Activity Log time filter if you need to capture troubleshooting notes for support/audit.

The ‘Configuration Setup’ page in the application allows a user to input their Salesforce credentials, select and schedule objects, and configure other information for the replication of Salesforce data.

Configuration Name

The Configuration Name is a unique and required input to name the configuration. This value is the identifier used to find the configuration in the Configuration List View. Once the Salesforce credentials section has been filled out and the credentials successfully tested, this field becomes immutable.

Salesforce Login Section

Username and Password Authentication

The following parameters are used when authenticating username and password credentials with Salesforce:

• Instance Type: The type of Salesforce instance being replicated:

  • Production

  • Sandbox

  • Custom Domain

    • If your Salesforce instance requires a specific domain for login, use the “Custom Domain” instance type and enter your domain in the “Custom Domain” section provided.

• Username: A Salesforce user. This user must have API privileges. All data visible to this user will be replicated to the CapStorm database.

• Password: The password for the Salesforce user.

• Security Token (Optional): The Salesforce security token associated with the username provided. For more information regarding finding this token, seeing the .

The following parameters are used when authenticating OAuth 2.0 client credentials with Salesforce:

• Org Domain: The domain name that is used on the login page to the target Salesforce instance.

• Client ID: The client ID generated when creating an external application in Salesforce.

• Password: The client password generated when creating a connected application in Salesforce.

The following parameters are used when authenticating OAuth 2.0 JWT credentials with Salesforce:

• Org Domain: The domain name that is used on the login page to the target Salesforce instance.

• OAuth Client ID: The client ID generated when creating an external application in Salesforce.

• Username: The username of the Salesforce user to authenticate with.

Assuming the external application has been configured in the target Salesforce instance, the final step to complete that process is providing a .pem file used for the authentication. This is done through the Generate PEM File button seen below. Note that the Org Domain, OAuth Client ID, and Username are not required to generate the .pem file.

When the generation button is clicked, the .pem file will be automatically downloaded and can be uploaded to the Salesforce external application. After the file is uploaded to Salesforce, the Org Domain, OAuth Client ID, and Username should be provided.

Once all information for the selected Login Type is provided, the “Test Salesforce Credentials” button becomes selectable. Click this button to validate the provided credentials. Once successfully validated, the “Object Selection” table will be populated with all objects in the Salesforce instance that are visible to the user.

The Database Connection section is an optional section used to input a target Snowflake database and schema name to store Salesforce data for the target Salesforce instance. The provided database and schema name must exist in the same Snowflake instance where the application is installed. If these fields are left blank, the SALESFORCE schema in the application database will be used by default. For more information regarding configuring a new database for replication, see .

The Settings section provides controls that will work across all created CopyStorm tasks. These options include the following:

• API Threshold: Blocks Salesforce API usage if API usage exceeds the selected percentage before beginning job(s). For example, if 75% of available calls is selected, any CopyStorm or CopyStorm/Medic jobs will not execute if the current Salesforce API utilization is above 75% at the time of launch.

• Refresh Formulas: Sets how often formulas are refreshed for all objects. When a formula definition changes in Salesforce, CopyStorm will not pick up the new definition because the timestamps stay the same. This tool will scan tables and update the associated formula columns in CopyStorm. For more information regarding this subject, see the documentation.

• Retention Lock: Sets how many days records deleted in Salesforce are kept in the CapStorm database. By default, deleted records are not kept in the database but by changing this selection a user can choose to keep deleted records for the selected amount of time, including forever.

This is an optional section that allows users to input email addresses to receive email notifications after jobs with errors finish, or after every job finishes.

To successfully send emails out of the Snowflake environment, a Snowflake Notification Integration must be created in the Snowflake instance. By clicking the question mark icon next to the Integration Name label, an example SQL is displayed that can be used to create this Notification Integration. If an integration name or email addresses are already input, those values will be used inside of the example SQL. Otherwise, example values are used. It is important to note that only email addresses in the Notification Integration will be able to receive emails originating from Snowflake. For more information, see .

The Object Selection section of the Setup page provides the ability to pick the objects to replicate as well as their cadence of replication. Different objects can be replicated in groups at the below schedules:

• Every 5 Minutes: Runs every hour at the 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55 minute marks

• Every 15 Minutes: Runs every hour at the 0, 15, 30, and 45 minute marks

• Every Hour: Runs every hour at the 0 minute mark

• Every Four Hours: Runs at hours 0, 4, 8, 12, 16, and 20 at the 0 minute mark

It is important to note that these schedules are UTC based. This means that if a user is based in the U.S. eastern time zone (EST), selecting the “Every Day” schedule will run at midnight UTC, but 7:00PM EST.

The Filter input can be used to search for objects in the current list of objects displayed in the table. As well, the dropdown to the right of the Filter can be used to show objects based on their category (e.g. All, Standard, Custom, etc.).

The Modify Selected Schedules button allows a user to quickly update for all of the objects currently in the table that are active.

The Select Objects from List button can be used to mass-select objects for replication rather than individually clicking the toggle for each object. When clicking this button, a pop-up appears allowing for comma separated input of all objects to select. Any objects already selected in the Object Selection section that are provided in this list will stay selected, but their schedule will be updated to the value selected in the pop up.

Once all inputs and selections have been made, the Save button at the bottom of the page can be clicked to either save an initial configuration, or update a current configuration. In the case of updating a current configuration, any objects that have been newly selected, removed, or have an updated schedule will be automatically updated to the aligned task and will be replicated at the selected schedule.

The Run Now toggle can be used to immediately start replication of the selected objects. If multiple schedules have been selected, each CopyStorm task will execute one at a time until all are completed, then the tasks will run on their selected schedules. If the Run Now toggle is not selected, the CopyStorm tasks will run at the next time associated with the selected schedule for each task.

The opening page on the Restore tab provides the ability to create a new restore, view and edit previously saved restores, and see history of previously in progress or completed restoration processes.

Use the New Restorebutton in the top-right of the page to create a new Salesforce record restore.

The list view on the Restore tab shows all in progress or completed restore configurations. Click on a row in the Configurations table to view, edit, or continue and restore processes.

The History view within this page shows all candidate scans and restorations that have occurred for the selected configuration. Information including tables scanned/restored, exceptions, system resources, and timing can be found here.

The Snowflake CapStorm Salesforce Connector has the ability to send email messages on completion or failure of CopyStorm replication jobs. To securely enable this capability, a Notification Integration must be created and access must to the Notification Integration must be granted to the application. This page explains why this is necessary and provides the required steps for successful configuration.

Snowflake enforces a security-first model for external communications. If an application needs to send notifications (e.g. through SYSTEM$SEND_EMAIL), Snowflake requires:

• Explicit declaration of the allowed external notification service.

• Controlled permissions for which applications can use the integration.

The Upload Data stage of the Restore Wizard is where the restore job performs the record upload into the target Salesforce, showing live progress while running. Here a user can monitor overall progress, object-by-object outcomes, attachment handling, and basic container performance.

Understanding the Dashboard Panels

Total Progress

This is the “big picture” progress for the restore job.

What is seen:

• A step indicator like “Step X of Y: …” (example shown: “Step 40 of 40: Restoring Attachment”)

• A status message like Restore Completed

How to use it:

• If progress is moving, the job is actively processing.

• If it’s stuck on the same step for a long time, check Live Performance and the Completed Objects chart for heavy errors or bottlenecks.

Tracks attachment/file-type items separately from the main object record restore.

What you’ll see:

• Counts like Uploaded and Skipped

• Show Details link (bottom-right of the panel)

How to use it:

• If expecting files/attachments to restore and see lots of Skipped, click Show Details and later review View Results to understand what was skipped and why.

• It’s normal for attachments to be processed in their own phase (they’re often heavier and have different constraints than normal records).

A simple throughput graph showing how fast records are being uploaded over time.

How to use it:

• Helpful for sanity-checking performance: if the rate drops to zero while the job isn’t complete, something may be blocked (errors, throttling, connectivity, etc.).

• Small fluctuations are normal; huge flatlines usually mean the job isn’t currently uploading.

Quick view of container resource usage during the restore.

What is seen:

• RAM Free (MB)

• CPU Load (%)

• Memory Usage (%)

How to use it:

• If Memory Usage is very high and stays high, restores can slow down or become unstable.

• High CPU during restore is expected; sustained maxed-out CPU + no upload progress is a red flag.

(This panel doesn’t fix anything by itself – it’s the “is my container dying?” gauge.)

This is the most useful panel for understanding what happened per object.

Legend:

• Restored (blue)

• Skipped (yellow)

• Errors (red)

What it means:

• Restored: records successfully written to Salesforce for that object.

• Skipped: records intentionally not written (common causes: restore type settings, record already exists / doesn’t exist depending on insert vs update behavior, missing prerequisites, or other rules).

• Errors: Salesforce rejected the operation or the restore job couldn’t complete it (permissions, validation rules, required fields, referential integrity, etc.).

Red bars = you need to investigate. Move to View Results after the job finishes to see the error details and which records failed.

Skipped usually means the job decided not to write that record based on rules/settings. The two biggest drivers are:

• Restore Type

  • Insert Only will skip anything it considers “already exists”

  • Update Only will skip anything it considers “does not exist”

• Relationship/order constraints (child record can’t restore cleanly without its parent/state in the target org)

Use View Results for the exact per-record reason.

Attachments/files often have extra constraints (size, permissions, object support, target org state). Use Show Details in Attachment Progress, then View Results for specifics.

Finish the run (or stop if it’s exploding), then go to View Results and resolve based on the reported Salesforce errors (permissions, validations, missing required fields, etc.). After fixing the root cause, re-run a restore or adjust configuration and Re-Scan Candidates.

The Setup tab allows viewing, creating, and modifying Salesforce replication configurations.

The Snowflake CapStorm Salesforce Connector is a Snowflake-native application allowing users to replicates Salesforce data into a relational database in the Snowflake environment. This application can be installed into a Snowflake environment straight from the Snowflake marketplace. Simple controls are provided for object selection and replication schedules to easily configure the replication process as well as features to view the status and history of executed tasks.

To get started with the Snowflake CapStorm Salesforce Connector, click on the link in the left-hand navigation bar.

The Snowflake CapStorm Salesforce Connector has the ability to back up multiple Salesforce organizations into one Snowflake instance by utilizing different databases and schemas as the backing storage for the data. When installing the application, a default SALESFORCE schema is created and accessible by the application to store Salesforce records. This schema however can only be utilized to store one Salesforce organization’s data. This page provides details on the required steps to successfully connect the Snowflake CapStorm Salesforce Connector to Snowflake databases and/or schemas.

Granting Access for the Database and Schema to the Application

Due to the nature of Snowflake permission restrictions, an application cannot grant itself access to databases and schemas that it does not own. Explicit grants must be provided to the application to allow it access to databases and schemas that were not created directly by the application. The following SQL commands must be ran to grant access to the target database and schema for the Snowflake CapStorm Salesforce Connector. Note that the following values must be updated to the correct identifiers:

• <>: The name of the target database.

• <>: The name of the target schema within the target database.

• <>: The name of the application to grant access.

The following command can be executed within Snowflake to provide a list of applications available in the logged in Snowflake instance. The name field is the target name of the application that should be utilized in the following grants.

Once all grants have been provided to the application for the target database and schema, the database name and the schema name can be provided via the for replication configuration.

Release Date: 28-Apr-2026

This is a standard GA release of the Snowflake CapStorm Salesforce Connector containing bug fixes and improvements to the application.

Important: Salesforce Username/Password Login Deprecated

Salesforce API version 65 deprecates the SOAP username/password login endpoint. Customers should migrate to an external client application configured with OAuth. CopyStorm, CopyStorm/Medic, and CopyStorm/Restore jobs using a login type that does not support API 65 will automatically fall back to API 64, and an exception will be logged at the start of each job as a reminder to migrate.

This exception can not be eliminated until OAuth authentication is used.

Salesforce API Version Fallback for Username/Password Logins

The "Fallback API Detected" error does not stop jobs from running - it is informational, and indicates that CopyStorm is not able to use the most recent Salesforce API features. The error will be resolved when updating to JWT (or other OAuth) authentication.

Please reference Salesforce OAuth Login Types.

Snowflake CapStorm Salesforce Connector Updates

Major Changes

• Updated CopyStorm, CopyStorm/Medic, and CopyStorm/Restore to use Salesforce API version 65.

• Added OAuth JWT Salesforce login support.

Improvements

• Updated the Restore wizard to bypass engine saves where not necessary to improve performance.

• General quality of life and performance enhancements for the Restore wizard.

• Utilized Hybrid Tables for Tracker Database schemas to decrease time during the record restoration process.

• Bypass reading credentials from the Snowflake Secret Store if already read to decrease load times.

Bug Fixes

• Fixed issue where scheduled jobs where not being recognized as completed when the underlying process was finished.

• Resolved issue where long runtimes of bootstrapping scheduled jobs would result in duplicate job executions.

• Fixed issues for CSV exports in CopyStorm, CopyStorm/Medic, and CopyStorm/Restore would result in an error without any file exported.

• Resolved problem in the Restore wizard View Results page where the

• CapStorm/Container: 5.4

• CopyStorm: 10.65.1

• CopyStorm/Medic: 10.65.1

• CopyStorm/Restore: 10.65.1

The Developer page allows users access to the underlying applications that are used to perform Salesforce object replication, maintenance, and job creation, scheduling, and execution. It is important to note that these applications should be used with caution. Execution of jobs within these applications while scheduled jobs are running could lead to duplicate records, or errors in either of the job executions.

Related Articles

• CopyStorm — Salesforce backup to a relational database.

• CopyStorm/Medic — validation, maintenance, and repair of CopyStorm databases.

• — scheduling and orchestration for CopyStorm jobs.

This article explains how the Snowflake CapStorm Salesforce Connector backing database storage is designed.

The Snowflake CapStorm Salesforce Connector uses a Snowflake database that is built out during application installation to store internal configuration information, application metadata, and a default schema to store Salesforce data. These three schemas can be found below:

• **DIRECTOR:**Stores application metadata including job and task information.

• **SALESFORCE:**The default schema to store Salesforce data.

The Scan Records step of the Restore Wizard is a sanity check and planning stage. The wizard scans for what was configured included candidate top-level records, related child objects, and field settings. This process builds the full list of record candidates to insert and/or update in the target Salesforce org. Once the scan finishes, click the Restore button to begin the record upload process.

When clicking Scan Records, the Restore Wizard:

• Evaluates the selected top-level object records (from Step 1)

• Applies the Step 2 settings (Restore Type, Object Settings, Related List Depth, Automation)

The Home Page provides a simple way to look at all jobs that have been created, the status of the jobs, as well as the ability to see more information about the job including the tasks and task history by clicking the job in the table.

After the initial configuration and save of the Setup page, the job created when saving will appear in the table as seen in the image below. There is currently no last run time or status due to the job being configured, but not having any task run yet.

When a task under a job is running, a Cancel button will appear at the end of the Jobs table. Clicking this button will stop the execution of the running task. It is important to note that by clicking the Cancel button, the executing task will have a non-successful status. This feature can come in handy when the configuration set on the Setup page is not desired, and a task has already begun running.

The Database Management page allows for creating new schemas within the default database associated with the application, or connecting to previously created Snowflake CapStorm databases (a Snowflake CapStorm database is a database/schema that was built out using a CopyStorm record backup). New schemas can be created for record backup, or for the restoration process as a tracker database. As a safeguard, these created databases can enabled “Prevent Deletion” to ensure that they cannot be deleted through the application. This does not remove the ability to drop databases using a database admin tool. By default when the application is installed, a SALESFORCE and DEFAULT_TRACKER schema are created to hold Salesforce record backups and record restoration details respectively.

Creating a New Schema

To create a new schema within the application database, click the Create Schema button in the top right of the page. By default, a user can input a name for a new schema to be created as well as a usage. The Prevent Deletion checkbox at the bottom of the form when checked ensures that the schema cannot be dropped from Snowflake from within the application. Click Confirm to save and create the new schema.

Connecting an Existing Database

For any users that have used the CopyStorm desktop application to backup Salesforce records from Snowflake, the Custom Database checkbox can be used to register that Snowflake database with the application. To do so, check the Custom Database checkbox in the form and input the name of the database and schema. If the database field is left blank, the default application database is assumed. Note for any external databases to be used within the application, they must be granted access using the steps provided .

To edit an existing database, click the icon in the Actions column of the table. This allows for the input database and schema to be updated in the backing store. Note that for any custom database information that is changed, access must be explicitly granted if changing to a new database/schema pair.

The View Results stage is where a user can review exactly what happened during the restore, broken down by Salesforce object and record. Use it to confirm success, investigate errors, and understand why any records were skipped.

Select the object to analyze (Account, Contact, etc.). This page shows results one object at a time.

Use this to control which columns appear in the grid.

• Keep it small when you’re troubleshooting (ID + name + status + a couple key fields).

• Add more fields when needing to verify that specific values restored correctly.

The Select Records stage of the Restore Wizard allows for the selection of the target database to restore records from as well as the top level object to start the restoration. Filters can be applied to the object to scope down the records to the target candidates for restoration as well as using the Run Search button to view the top level objects before beginning the process.

Before Starting

To successfully select records and complete the Restore Wizard, the following is required:

• A database containing a CopyStorm backup

  • This can be from either a backup created from the Setup page, a backup created manually through the application, or a connected database that was created from the CopyStorm desktop application in Snowflake.

• Valid Salesforce credentials for the target to restore

In the Database dropdown, select the database that contains your CopyStorm backup data.

• If there are multiple backup databases, pick the one that corresponds to the org/data intended to restore.

In the Object dropdown, choose the top-level Salesforce object to start from (for example: Account, Contact, Case).

• This object becomes the basis for the search + preview results.

Use the Show Fields tab to control which fields/columns appear in the preview results grid.

• This helps confirm the selection is targeting the correct records before moving forward.

• If not sure what to include, start with obvious identifiers (Name, Email, etc.) and expand as needed.

Switch to the Filters tab to define criteria for the records you want restored.

• Keep filters tight when possible-especially in large orgs-to reduce scanning and make validation easier.

• Example filters (conceptually): Name equals “Acme” or LastModifiedDate greater than .

Click Run Search.

• Matching records will populate in the right-side results grid.

• If nothing appears, loosen your filters (or verify you selected the intended snapshot/object).

Once the preview looks correct, click Next Step (bottom-right) to advance to Configuration.

• “No Records to Show” after Run Search

  • The filter may be too restrictive, or the selected snapshot doesn’t contain the records expected.

• Database/snapshot not available

  • Confirm the database exists/was created for CopyStorm backups in