Skip to main content

Configuring & running your first Sandbox seeding job

Our dedicated sandbox seeding tool allows you to seed realistic data from one Salesforce org (Prod/Sandbox) into any of its other sandboxes

Nathan Anderson avatar
Written by Nathan Anderson
Updated over a month ago

Sandbox seeding is the deployment of production data to a sandbox for use in testing. Gearset allows you to seed data from one Salesforce org (source) into another (target) filtering, relationship-aware logic, and data masking.


Prerequisites

Before you can run Sandbox seeding, a Team owner from your Gearset team must first manually enable Gearset's data loader on Data management page in our app.

For guidance we recommend reading through enabling data deployments in Gearset. Once this is done, you are ready to seed test data.


Configuring the job

Using the menu in the left side of the app, navigate to the Configure and deploy page by clicking Data deployments and then Configure and deploy.

  • Click on the Configure sandbox seeding button in the top right of the menu to open the the tool.


Selecting the source and target orgs

In the Configure sandbox seeding window:

  1. Select your Source org - this is where Gearset will pull the data from.

  2. Then select your Target org - this is the sandbox the data will be deployed to

  3. Click Configure seeding.

Note: The target org options will only include sandboxes created from the same production org as the source. ⚠️ You won’t be able to select sandboxes from different orgs or unrelated environments ⚠️

Not seeing the desired sandbox in the list of available org connections

  • ⚠️ Team-shared connections are not currently supported, so each user configuring or running deployments will need to use their personal sandbox connections.

  • Sandbox connections can fail to appear if access has changed or the authorization has expired. Reauthorizing ensures Gearset can correctly access the sandbox before you configuring the job. Steps to reauthorize a connection are covered here: How to re-authorize an org connection in Gearset



Select the objects to be seeded/filtering

Once you’ve selected the two orgs, you’ll be taken to the configuration page. All objects in the source org are displayed in the left-hand menu and you must begin by selecting your starting object.

All other objects you are seeding must be related to this starting object. It’s best to choose the object for which you have the highest number of filtering criteria.

You can easily identify your starting object, as it will always have a star to the right of its name.


Once the starting object is selected on the left hand side, Gearset lists the objects related to your selected object. These are separated into children and parents.



​Click on objects or drag them onto the canvas to add them to the job. Once added, you’ll see the object and its relationships visually mapped on the canvas, with the number of records to be seeded displayed beneath each object name.

To add objects not related to the start object, click on an object in the canvas then select parents and children from the left side panel.




Click the filter icon to configure filters on the starting object. Filtering is applied only at the start object level.

Child or related objects cannot be filtered directly and will be included automatically based on the relationships required to maintain data integrity.


When all the objects required have been included on the canvas, click on Configure masking in the bottom right.

Select data masking options

  • Choose whether you want to mask any fields to obfuscate their values. If a field is masked, Gearset will deploy fake values instead of the real values for that field, concealing sensitive customer information. Learn more about data masking.

  • Once you've chosen which fields to mask, click PRE-DEPLOYMENT SUMMARY to review the data to be deployed. Gearset will create and list out the steps we’re about to take in your data deployment.

Disable Validation rules, Triggers, and Flows

Before deploying, Gearset gives you the option to temporarily disable automations that could interfere with the deployment such as flows, triggers and validation rules.

This can help prevent unwanted side effects like blocked inserts, failed logic, or test automation being triggered.

If needed, select the items you'd like to disable and click Start deactivation deployment.

Once you've finished your data deployment, you can re-enable the rules, triggers and flows - for full details on how this work, check our documentation on disabling validation and duplicate rules, triggers, and flows.

Deploy the data records

  • You'll be able to see the object records to be deployed, the actions Gearset will take to retrieve the records, such as fetching, including, creating and upserting, as well as the field count and any applied filters.


  • Click on DEPLOY DATA to deploy the selected data to the target org. When the deployment is running, each stage will mark as completed and show you how many records have been processed in each step.

  • Once complete, you'll have your subset of data available for any testing and debugging you'd like to perform on the target org.

  • The deployment will be stored in your Data deployments > Data deployment history in the app. From here, you can view previous data deployments, their status, and view the details of which records were moved. Learn more about data deployment history here.

Limitations

Sandbox seeding has been designed for seeding test data to development sandboxes. Each seeding is limited by some simple rules:

  • Only related objects can be included, i.e. no isolated objects can be added except as the start object.

  • Children can only be added as descendants of the start object.

  • Each object can only be added once to prevent circular references.

Related objects

In sandbox seeding, Gearset attempts to deploy only the objects that have been specified by the user. The only exception is for parent objects, where the relationship is master-detail or the lookup field is required. In this case, we include the parent to prevent errors. For all other lookup relationships, we will update the links based on your deployment history.

Updating vs creating records

For all records deployed, we will try to upsert the data in the target org. If a record has been deployed to the target before, we will try to update it in the target. If a record has not been deployed to the target before, we will create a copy in the target.

Audit data

Audit data, such as created date, will be included in the deployment if the user has the correct permissions for the target.

Did this answer your question?