How much time do you spend debugging errors in Salesforce production environments? According to Stripe, the average developer spends more than 17 hours a week debugging...that’s almost half a week spent fixing pushed code rather than developing new features.
In fact, upward of $300 billion in global GDP is lost because developers pour time into fixing code.
This is the sort of work Salesforce developers and admins try to avoid by testing in their sandboxes environments. No matter how careful you are, errors will inevitably slip into production if you’re testing with irrelevant, old data.
While sandboxes provide a repository for development and testing, only Full Copy sandboxes provide developers with 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, developers and admins require additional tools to efficiently and consistently populate the environments with data.
Getting relevant, fresh test data for complete testing can be difficult and time consuming.
1) Data Relationship Integrity
Accurate development and testing hinges on seeding sandboxes with production-like datasets. This makes maintaining parent/child relationships critical.
Similar to recovering lost data with the Weekly Export .CSV files, maintaining data relationships when seeding sandboxes can be challenging with Excel and Data Loader. Both require multiple steps.
You 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.
2) Data Relevancy
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’ll need to be able to filter and refine your test data, exclude attachments, and certain sets of data, all while maintaining relationship integrity for the data you’ve selected (see challenge #1).
3) Data Freshness
You’ve seeded your sandbox, but then new requirements are identified. In this situation, 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 are often why your code may work in the Developer sandbox, but once it’s pushed into QA, it breaks.
4) Data Confidentiality
Because sandbox data is a subset of production data, it’s likely to contain confidential information that could be accessed by many people during development, testing, and training. Anonymization applied during the seeding process obfuscates data so that it is unreadable, replaced with mock data, or converted to an empty data set.
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.
Anonymization is more than a good practice. Regulations such as GDPR and CCPA require companies to evaluate their technical and organizational controls to ensure compliance. Industry-specific standards and regulations such as the PCI DSS and the HIPAA also include strict privacy and security requirements.
5) Data Consistency
Having consistent data allows admins and developers to speed up development by preventing errors from slipping into a new environment. It’s best practice to compare origin and destination environments both before and after a release.
If you’re skipping this important step in the testing process, you may be wasting time diagnosing and fixing bugs in your destination environments. However, without a tool to compare data and metadata, the only way you can uncover differences between production and sandbox environments before and after deployment is to download and compare large numbers of .CSV reports or Weekly Export files in Excel using V-Lookup. That’s why most admins and developers don’t even bother.
Solve These 5 Challenges Fast
At this point, you may be trying to invent various DIY seeding tools that solve aspects of these five challenges using time-consuming, manual processes. From my experience, these DIY options are often like putting a bandaid on a cut that needs stitches. It may solve the problem temporarily, but in the end you’ll have to go see the doctor. Without an automated seeding solution, it is difficult to innovate quickly and identify coding errors before code is released. Before you head too far down that road, consider Own Accelerate.
Accelerate is an intuitive and powerful sandbox seeding solution for organizations that want to maximize their Salesforce platform for training, development, or testing. Salesforce administrators and developers can easily seed quality data to any sandbox with desired objects and records while maintaining all relationships and masking all sensitive information.
Here’s how Accelerate solves all five of the challenges mentioned above.
1) Data Relationship Integrity
Simply select one or more root objects and the system instantly displays options for adding related parent or children objects. Any number of relationships can be included up or down the hierarchy, and those relationships remain intact once seeded.
2) Data Relevancy
Real-time counters keep track of the number of records included for each object type selected, and filters provide options to further refine the ideal data set and size. At any point, a single click produces a report to show a sample of records defined by the custom parameters.
3) Data Freshness
With templates, you can create and save reusable rules to specify the precise data to be included in each seeding project. Templates can be used to seed sandboxes over and over. If adjustments need to be made, records can be easily added to update the sandbox with an incremental update.
4) Data Confidentiality
Data can also be anonymized. Custom templates can be applied to mask sensitive information before it is seeded to its destination.
5) Data Consistency
Compare a production backup to a sandbox backup before deployment to avoid failures by identifying if new validation rules or workflows have been added to production. Salesforce automations can also be disabled as needed.
.png)
