Back to the blog

salesforce-sandbox-testing-challenges.jpeg

Top companies using Salesforce are actively releasing new features and updates. In fact, according to the State of Salesforce Report put out this year, 52 percent are releasing changes monthly or more frequently. This is definitely keeping Salesforce developers and admins busy.

debugging-app-errors-sandbox.png

Errors happen in production…no matter how awesome you are. According to a study by ClusterHQ, 43 percent of app developers spend between 10 and 25 percent of their time debugging application errors discovered in production. That means almost half of the developers out there are wasting a significant amount of time fixing pushed code rather than developing new features. This is the sort of work Salesforce developers and admins are trying to avoid when testing in their sandboxes environments.

Unfortunately, getting relevant, fresh test data as often you need to for complete testing can be very difficult and time consuming due to the following five challenges.

1. Maintaining multiple Salesforce sandboxes is expensive. The costs of multiple sandboxes can really add up, especially if you’re supporting multiple FULL sandboxes. Just one full sandbox can add up to 20 to 30 percent of the total cost of your production instance.

2. Developers cannot fully test when limited to irrelevant data. Seeding your sandboxes, or moving relevant, sized to fit test data into a sandbox, can be like using a funnel to filter sand from a dump truck. You end up buried in tons of irrelevant data. Testing with irrelevant data causes bugs and errors to slip into production, even if you thought you had fully tested in your sandbox.


salesforce-sandbox-seeding-buried.png

The reason it is so difficult for many developers and admins to get relevant, sized-to-fit data is that they’re testing in smaller sandboxes that can only fit part of the data from production. To seed relevant data into these smaller sandboxes, you need to be able to filter and refine your test data, exclude attachments, and certain sets of data, all while maintaining integrity of the relationships for the data you’ve selected.

5. Protecting confidential data can be difficult. Providing unauthorized access to personal confidential information can be a huge liability for a company. It can happen easily when testing with real data. Are you currently anonymizing sensitive data before sending it over to your sandboxes? It’s definitely something you should be considering.


4. Slow and inefficient development cycles can lead to delayed release deadlines and less time to test.
Development cycles can be slowed and made really inefficient by:

  • Having to wait for slow Salesforce sandbox refreshes. Sandbox refreshes can complete in hours, days, or even more than a week, according to the Salesforce help center.
  • Manual processes to move data between Orgs using the data loader tool can be quite time consuming, especially if you’re not using a Full Sandbox.
  • Automatic workflows, rules, and triggers firing from your sandbox when you’re simply trying to load data can also cause big problems.


When development cycles are bogged down by slow and inefficient processes, release deadlines get missed and corners get cut in the testing process.

5. Cross-org comparisons are complex and time-consuming.
salesforce-org-compare-environments-sandbox.png

Managing data and metadata across your environment Orgs can be a significant challenge. Without a tool to compare data and metadata, the only way you can uncover differences between production and sandbox environments before and after deployment would be to download and compare tons of .CSV reports or Weekly Export files in Excel using V-Lookup. That’s why most admins and developers don’t even bother. You shouldn’t skip this important step in the testing process because comparing Org and sandbox data and metadata helps you identify or even prevent things from going wrong after a release.


It’s clear that sandbox seeding and testing can be challenging, but there’s a better way..

OwnBackup is redefining the requirements when it comes to working with sandboxes. It should be easy to populate a Salesforce sandbox with your perfect, anonymized test data set in minutes. This means you’ll have shorter development and QA cycles, with sized-to-fit, more-relevant data. The OwnBackup Sandbox Seeding solution sets a new standard for Salesforce Developers and Admins.