What if you could speed up your sandbox refresh process by reducing the number of refreshes you need to do in the first place?
Nothing causes heartburn among Salesforce developers and admins quite like a sandbox refresh. Our potential customers report this as costing them more productive time than almost any other activity. For many teams, it can take up to five days to complete all the manual steps associated with refreshing a sandbox. For many that we speak to on a weekly basis, this is the number one thing they are looking to improve about their DevOps process for Salesforce.
Most teams start their process of improving their refresh workflow by turning to automating their data deployments. Painstakingly recreating test data by hand can take days of tedious work.
Dataloader.io is a (mostly) free tool provided by Mulesoft that allows you to import and export data from one Salesforce environment to another. Its simple, clean interface makes it popular among Salesforce admins who are transferring data between CRMs or sandboxes. Many developers and admins are also turning to dataloader.io as a low friction and simple tool for re-populating test data in their sandboxes.
Dataloader.io is easy. You simply login with OAuth without having to deal with complicated security tokens which makes authentication simple. You can then create reusable "Tasks" that can be used to import data by mapping datasets via field and object look up in a click-based tool. There are even keyboard shortcuts that make it pretty slick for power users. It also keeps a history of all tasks that have been executed.
The best things about dataloader.io is that it's simple and it's free (up to 100,000 records a month). However, it still requires a number of manual steps and there is no concept of data masking so you need to leverage it with a dummy data set. Though dataloader.io saves a lot of time, it still isn't quite suited to a real DevOps workflow because it cannot be scripted easily or plugin to a CI process.
A better solution for the DevOps context is Prodly. Prodly made a name for themselves by helping Salesforce teams configure and deploy CPQ data records seamlessly and are trying to create a space they call "AppOps". Their data deployer can also be used for sandbox seeding. It's a best in breed solution that allows you to move data directly between Salesforce environments (without resorting to spreadsheets) and contains all the bells and whistles you would want such as data masking and creating missing fields and picklist values.
But what if you could do fewer sandbox refreshes in the first place? What if you could simplify your workflow and keep your branches in better sync with production without having to update data and perform manual steps? Because even with better tooling, refreshing a sandbox still takes time and requires you to perform manual steps.
By leveraging Git to keep your sandboxes in sync, you can do frequent, atomic and automated mini-refreshes that will keep your focus on building features. With Git branches you can drastically reduce the number of refreshes you have to do while still getting the benefit of working on up-to-date environments. This benefits you by:
How it works
By running your Salesforce deployments via pull request, you can also leverage downstream pull requests to your sandboxes to keep your environments in sync.
Throughout a given sprint, developers will be creating pull requests. Each request is later bundled in a Bulk Releases in Blue Canvas and staged to be pushed into production. When the deployment lead initiates the Bulk Release, Blue Canvas will automatically kick off validation and any quality gates that have been setup for the target environment. If everything passes and the Release is approved and deployed. Your team now has a successful Release that is ready to be cloned to your downstream environments.
The release manager simply clicks "Clone to Multiple":
Then, they can select the target environments downstream including UAT, integration and all developer sandboxes.
This will automatically create pull requests down to each target environment that you selected. Each developer will see that there is a pending pull request containing the changes of the latest release for their personal environment. They will see its validation status and whether there are any dependency issues to be aware of. An admin or developer can accept the pull request to fully sync the changes of the release into their sandbox. Or they can cherrypick specific files to exclude. They can even merge part of a file. For example, if they only want to merge 2 new methods of an Apex class but not yet sync a few others they can do that like so:
Once the downstream pull request is approved, Blue Canvas will merge and deploy the changes from the production release into the target sandbox. Now the sandbox is up-to-date with production and contains the latests changes. However, there is no need to reload data or reconfigure the sandbox from scratch. This allows true continuous integration where changes between environments are synced frequently.
This workflow can be further enhanced by using scratch orgs by using scratch orgs as atomic "feature branches". (We also have high hopes for Lightning Developer Pro Sandboxes though we have not seen them widely in use.)
Using this method, our customers are now able to reduce the number of actual Salesforce refreshes that they do. Many went from doing refreshes monthly to now doing it only quarterly. It's much simpler than worrying about configuring data loading into your DevOps pipeline. Just another way that with Blue Canvas, less can be more with Salesforce DevOps.
.png)