Sandbox seeding, or data seeding, is the practice of populating a Salesforce org with record data after it is created or refreshed. While colloquially referred to as sandbox seeding, it’s important to note data seeding also applies to other types or Salesforce orgs as data can be populated or moved into Developer orgs, scratch orgs and even production.

Common use cases for sandbox seeding

A sandbox is merely a Salesforce environment that you can use for making changes to Salesforce, testing those changes, and training users on changes before making the changes available in production. So sandbox seeding is valuable at various stages of Salesforce development and enables admins/devs to complete projects faster, identify issues early (when they’re easier and cheaper to fix), and reduce the amount of time spent resolving bugs at every stage of development.

For example when starting a new Salesforce project, an admin will ideally start work in their own environment, perhaps a Developer or Developer Pro org. Individual Developer sandboxes provide quicker outcomes while virtually eliminating the chance of accidentally deploying unfinished work into Production or overwriting another teammate’s work. This also lessens the risk of exposing confidential data or impacting the daily tasks of your end users. Most Salesforce enhancements impact record data in one way or another, so it’s helpful to have real business data in your environment. While it is true you can use “dummy data”, substantial, real data is always best. Errors and issues are easier to spot when you’re working with real data, and you can compare against production to see exactly how changes would impact production data and user workflows.

Once the admin is confident their new solution is working the way they want, the next step is to make sure it plays nice with the changes other teammate’s have been making and, of course, production. For this you’ll want to have each individual promote their changes to a shared sandbox for testing. Frequently, admins/devs will want to seed data into the testing environment to achieve a production-like environment with current, clean data for testing so they be confident their changes will work in production.

While the majority of Salesforce changes should follow a release path where work starts in an individual Dev org and gets promoted up to testing sandboxes and ultimately pushed into production, there is also a solid argument to have an exception process for quick changes or hotfixes. Due to the urgent nature of hotfixes, companies often make changes in a dedicated sandbox and push them into production. This enables admins to keep production running smoothly, but can cause the orgs in the standard release path to become out of sync with production. After hotfixes, it is important to seed the testing and training sandboxes to ensure regular development projects have the latest configurations and data.

Finally one of the other benefits of seeding sandboxes with actual production data is that you will now be able to create a training environment for new end users and even new hires. How can you expect a new user to learn and understand how to use Salesforce if they don’t have real life scenarios and data for practice? Dummy data can inhibit the learning process because it doesn’t provide necessary business context for users. Keeping your training org current makes the transition to production easier for users.

Challenges to seeding sandboxes

Seeding sandbox testing should be a best practice for any Development/QA team, however manually having to seed data is very time-consuming and can lead to unnecessary added expenses and project delays. Data security concerns can also hinder data seeding effort, as selecting the correct subset of data and scrambling sensitive data all while maintaining the child-parent relationships that exist in production adds additional steps and complexity.

Prodly Sandbox Management automates sandbox seeding to move entire relational data schemas at once with granular control over which records will be seeded and obfuscation options for protecting sensitive data. If you’re interested in reducing your admin’s workload and speeding up your Development/QA sprint cycles by automating sandbox seeding, give us a call.