Business cases for OwnBackup Seeding functionality

Let’s start with what OwnBackup Seeding is…

OwnBackup Seeding functionality allows you to copy all or some of the data between environments, filter, and anonymize your data regardless of your Salesforce licenses and regardless which types of Sandbox environments you have.

Seeding enables you to modify data to preserve data privacy, for example, change names, SSN, phone numbers, etc. OwnBackup Seeding functionality available as an addon or a separate product and requires additional licensing.

How it is done without OwnBackup

Here is how most of the developers updating their Test environments: They refresh Full Sandboxes copying everything from Production Org and then manually modifying sensitive data. Often they are updating Test with Prod data each time they are rolling a new release (about from a couple of months to half a year, or even a year). Then they (hopefully) anonymize data by obscuring it as follows: Once data is downloaded into the CSV table from Salesforce, they shift first & the last name columns on one or two rows and uploading it back to a Sandbox. Some developers are securing Sandbox data with Salesforce Data Mask. All described functionality & tasks your Salesforce team doing either manually or with a few separate tools while with OwnBackup Seeding everything build-in in one console.

Business Cases for Test & Development

Here is a few scenarios where OwnBackup Seeding functionality might be beneficial that I can identify:

1. The seeding process is faster with OwnBackup in comparison to downloading on a computer, modifying & uploading to a sandbox. OwnBackup allows us to disable triggers, workflows, and Rules while Seeding data. That would make the process easier and faster.
2. More secure: it does not require downloading all the data to a personal computer of a Salesforce admin or a developer to modify it before placing it to a Sandbox.
3. OwnBackup has more advanced data anonymization.
4. We can seed data from Prod to Test more often: Usually the data in the Test environment has a significant lag with Prod. With Seeding, we can transfer some or all the data from Prod to Test in order to troubleshoot issues in Test Sandbox first rather than doing it in Prod and hoping it will work out.
5. We can test data before it was modified if OwnBakup captured it in a backup. Also, often we cannot reproduce a situation and cannot figure out the cause of the problem since the data was changed right after the issue appeared because the business does not allow us to keep a logical data error in Prod for a long time. And a developer cannot take a look at the data as it was before. Or, in some cases, once some process initiated, it is impossible to rollback to see and test data as it was previously. With Seeding from a backup, it will be possible in some scenarios to restore data to a sandbox as it was before the modification.
6. Seed full, partial, developer pro, and even just developer sandboxes with some or all (if space is available) of the data from Prod for testing & development processes. That allows us to have more Sandboxes, not necessarily more expensive full sandboxes but cheaper partial, developer pro, or just developer sandboxes.
7. Compare Data/Metadata Across Environments functionality can potentially reduce errors during the deployment process from Dev environment to Prod and better monitor components that need to be deployed.

In the case of partial data copying, it is important to note that

OwnBackup Seeding does not blindly copies records with broken relationships but records along with its parent & children, thus preserving relationships, allowing better test your code even with a small dataset,

which is quite usefull for non-full Sandbox environments.

Set Your Expectations

Note, though some of the items above might sound cool on paper, it will not always be easy or even feasible to use OwnBackup’s functionality all the time.

I love to repeat: there is no magic, this is technology.

For example, regarding item #5, if we back up data once a day at noon and a record was modified at 12:01 PM, it will not be captured into the most recent backup until the next backup process. But the data can be changed before the next backup multiple times, and thus we will not be able to recover data at its state at the time of the error. Or in some cases, looking into a backup to find a required record might take more time than to find & fix a small issue in the system; therefore, such an approach will not always be rational.

Regarding speed and making processes faster. In general, most of the features will make development faster and smoother, but we cannot forecast precisely how much faster, thus how much value you will get out of it unless you will start working with it. And even once you start working with it, probably you will not be able to provide exact numbers how much time you have saved comparing spent time before to time with OwnBackup Seeding. Thus, it will be hard to calculate ROI (Return of Investment) for the Seeding functionality.

Summary

Remember that there will be some limitations, but it is better to have an additional tool and options in your sleeve than not.

OwnBackup has rich functionality for many business cases.

All the functionality should be especially useful, from DevOps’s perspective of view, since it can be done through one OwnBackup tool rather than manually and many tools, it is faster and more advanced. Though you should test it to figure how on practice it really works, and how easy to perform your day-to-day tasks and apply available functionality.