Whether projects are simple or complex, Salesforce sandboxes provide a safe place to create and refine enhancements without corrupting live production data, exposing confidential data, or impacting the day-to-day activities of users.
As valuable as these sandboxes are though, accurate development and testing still hinges on seeding them with production-like datasets. This is a key reason why Partial Copy Sandboxes are so appealing to developers. They use a copy of live data, which has more realistic qualities than the data most developers and testers use, for just a fraction of the cost of Full Sandboxes. For quality assurance tasks such as user acceptance testing, integration testing, and training, Partial Copy sandboxes are ideal.
Partial Copy sandboxes only allow a subset of data to be copied to the sandbox from production. Let’s take a look at some of the other limitations of Partial Copy Sandboxes, and how you can overcome them.
You can refresh a Partial Copy sandbox five days after you created or last refreshed it. If you delete a Partial Copy sandbox within those five days, you need to wait until after the 5-day period, from the date of last refresh or creation, to replace it.
Because of this waiting period, the development cycle often outpaces the ability to refresh the sandbox to get the latest copy of the metadata that fits those new requirements. The discrepancies here explain why your code may work in the Developer sandbox, but once it’s pushed into QA, it breaks.
While Full sandboxes have the same storage limits as your production organization, Partial Copy sandboxes allow for only 5 GB of storage space and a 10,000 record maximum per selected object.
So if you have objects with more than 10,000 records, in order to maintain the 5 GB limit, the number of records copied per object could be less than 10,000.
Since testing in smaller sandboxes can only fit part of the data from production, it’s difficult for many developers and admins to get relevant, sized-to-fit data in their Salesforce sandboxes. And testing with irrelevant data causes bugs and errors to slip into production, even if you thought you had fully tested in your sandbox.
Partial copy sandboxes include a random sample of the production org’s data, which means you can’t control which records are included. Unless the objects are related by a master-detail relationship or required lookup, the sampling application does not pick up related records, which can lead to broken data relationships.
For example, let’s say you have four objects: Accounts, Contacts, Leads, and Opportunities. If Accounts and Contacts have master-detail relationships, Accounts, and Leads have required lookup relationships, and Opportunities has just lookup, the sampling application would pick 10,000 of related Account, Contact and Lead records. However, the 10,000 records from Opportunities might not have the Account, Contact, and Lead values populated as they are randomized.
Why is this so important? Accurate development and testing hinges on seeding sandboxes with production-like datasets, which means maintaining parent/child relationships is critical.
According to Stripe, the average developer spends more than 17 hours a week debugging. Without an automated seeding solution, it is difficult to innovate quickly and identify coding errors before code is released.
If you’re developing and testing in Partial Copy sandboxes (or any type of sandbox for that matter), you should consider OwnBackup’s Enhanced Sandbox Seeding. It addresses the top challenges of Partial Copy sandboxes by enabling users to:
Keep Data Fresh
Instead of waiting five days to refresh, you can update template filters in seconds to add or remove data based on new requirements, then reseed to move new records that were created in the source.
Manage Data Set Size
Enhanced Sandbox Seeding enables you seed with precision so you know exactly how much data you are seeding. You can control what data is seeded for initial and subsequent projects with options to add all records, delete existing records, and replace with new, or only update incremental changes since previous seed.
Maintain Data Integrity
Maintain parent/child relationships to ensure sandbox records precisely mirror defined subsets of data from production orgs or other sandboxes. You can also configure re-usable templates and built-in filters to isolate perfect data sets to repeatedly seed to any sandbox with an identical data structure.