Imagine you’re a software company that just sent out a series of promotional emails about a new product to an important enterprise client. Seems pretty harmless, right? Except, what if it was a web developer who was responsible for hitting send, and those emails went out before the new product actually launched?
Of the over 180,000 businesses who rely on Salesforce to build deeper connections with their customers, many customize their environments and build applications to fit their unique business needs. Whether basic or complex, the goal of these projects is to turn ideas into valuable apps, processes, and workflows as quickly as possible. Still, organizations must balance the desire to release new features with the negative impacts of preventable errors making it into production.
In the example above, the developer was running an integration in a production environment that triggered emails to be sent to clients inadvertently. In a staging environment, those emails wouldn’t have been live. But since the developer made the changes in production, the process to send the emails was triggered, and the developer learned a tough lesson.
This helps demonstrate why sandboxes are so valuable.
How Sandboxes Streamline the Development Process
Collectively, companies lose upward of $300 billion because developers pour time into fixing bad software. To minimize these risks and streamline the path to real business value, many companies require staging environments, or sandboxes, to develop and test customizations and apps.
Just like an actual sandbox where kids can play and use their imagination to continually build and rebuild, developer sandboxes are like a playground to create and refine enhancements without corrupting live production data, exposing confidential data, or impacting users’ day-to-day activity.
By reflecting either a partial snapshot or full copy of the production environment, sandboxes allow organizations to:
- Collaborate on development efforts using multiple orgs.
- Isolate customization and development work until they are ready to be deployed.
- Test changes against configurations and data that mimic production.
- Perform user acceptance testing (UAT).
- Train users on new features.
- Coordinate individual changes and updates into one deployment.
The Four Types of Salesforce Sandboxes
To help developers and administrators enhance their org, Salesforce makes available four different types of sandboxes: Developer, Developer Pro, Partial Copy and Full.
Most organizations rely on Developer or Developer Pro for building and testing code. These sandboxes provide an environment in which changes under active development can be isolated until they are ready to be shared. Developer sandboxes copy all of the production organization’s metadata, but no data is contained.
Partial Copy sandboxes are commonly used for quality assurance, user acceptance testing, training, and integration testing. This environment includes a copy of the production org’s configuration (metadata) and a random sample of the production org’s data.
A Full sandbox is intended to be used as a testing environment. Full Copy sandboxes can be expensive (~25% to 30% of total license per org) because they are complete replicas of the production org, and are reserved for performance testing, load testing, and staging.
While all sandboxes provide a repository for development and testing, only Full Copy sandboxes provide an exact replica of complete production metadata and data. And because most development and testing work is done in Developer, Developer Plus, and Partial Copy sandboxes, organizations require tools to efficiently and consistently populate the environments with data. This process is commonly known as sandbox seeding.
Sandbox Seeding Challenges
For all of the reasons we’ve outlined, working in sandbox environments can add significant value for developers and admins alike. Unfortunately, getting relevant, fresh test data as often you need to for complete testing can be difficult and time consuming, typically due to the following challenges:
- Data Integrity: Accurate development and testing hinges on seeding sandboxes with production-like datasets. The most difficult barrier is maintaining parent/child relationships.
- Data Relevancy: Seeding a sandbox requires the ability to reduce large amounts of production data to isolate the specific relevant data needed for testing within the size limitations of the target sandbox. This requires the ability to easily filter and refine test data, as well as exclude attachments and irrelevant sets of data.
- Data Freshness: Once a sandbox is seeded, and new requirements are identified, the development cycle outpaces the ability to refresh the sandbox to get the latest copy of the metadata. The code works in the dev sandbox, but once it’s pushed into QA, it breaks.
- Data Confidentiality: Because sandbox data is a subset of production data, it’s likely to contain personally identifiable information (PII) that could be accessed by many people during development, testing, and training. Anonymization must be applied during the seeding process so that it is unreadable, replaced with mock data or converted to an empty data set. This is also critical for regulatory compliance with GDPR, CCPA, HIPAA, and SEC 17a-4.
Introducing Sandbox Seeding by Own
Sandbox Seeding addresses these four sandbox seeding challenges by enabling users to:
- Maintain Data Integrity: Maintain parent/child relationships to ensure sandbox records precisely mirror defined subsets of data from production orgs or other sandboxes.
- Seed with Precision: Create the ideal development and testing environment with subsets of data from production orgs or other sandboxes.
- Continuously Update: Update template filters in seconds to add or remove data based on new requirements, then reseed to update the destination’s records.
- Anonymize Data: Apply custom templates to mask sensitive information before it is seeded to its destination.
For organizations that develop on the Salesforce platform, Own Sandbox Seeding enables them to effortlessly define, fine-tune, and automate the replication of precise subsets of data schemes from production environments or other sandboxes, then quickly seed them to Developer, Developer Pro, or Partial Sandboxes with identical metadata.