Director of Customer Success
Getting everything that you need in your Salesforce Production org can be a challenge. At Prodly, we work hand-in-hand with our customers to make the most out of their Salesforce organization landscape. From small companies that do not even have full-sandboxes to large enterprises that are managing multiple production orgs with dozens of full copy sandboxes and hundreds of developer orgs, we often find that projects and results are prioritized over org strategy.
So questions like “What is the best org for getting this done most effectively?”, or “Why haven’t we refreshed this partial sandbox in 2 years?” are not discussed in depth. However, solving your strategy problems is key to making the most of your investment in costly sandboxes. In fact, with the right Salesforce sandbox strategy, you can even minimize your need to purchase Full Copy, Partial Copy, and Dev Pro sandboxes.
Here’s a quick recap of all the types of orgs that are available for use, and a brief overview of the best reasons to use them for your business:
Before we jump into the best ways to use your different Salesforce environments as part of an overall org strategy, it’s helpful to understand how they’re created and populated.
Full, Partial, and DevPro Sandboxes are copies created from production and may be regularly refreshed. Salesforce has different limits for how frequently each type of sandbox can be refreshed, but ideally you should refresh sandboxes as often as possible. The further sandboxes stray from production, the less valuable they become for testing and troubleshooting. You don’t want sandbox orgs to stray too far from the state of production because it makes testing and troubleshooting less accurate and valuable. The more out of sync your sandboxes get with production, the more bugs you will see from deploying work from them.
Commonly called sandbox seeding, data seeding is the practice of sending data to an org after it is created (or refreshed). This needs to be done to effectively test changes inside of an org that impact record data (which is pretty much every change). Moving data between Salesforce orgs is typically arduous, especially if using data with a lot of relationships (which is pretty much all Salesforce data). So, despite seeding being considered a best practice in an overall governance strategy, companies often skip it or perform it poorly, resulting in a whole host of problems further down the pipeline.
Although it may sound counterintuitive, data seeding is a crucial step for business agility because it accelerates development cycles and allows development in a true-to-production environment. When done right, sandbox seeding allows for a uniform development and administration experience across the dozens or even hundreds of orgs maintained by a large organization. This will reduce time on resolving bugs at every step of the development process across every org, so tools that help seed sandbox data faster are often solid investments.
For metadata, migration between Salesforce orgs is pretty well understood. This is the function of Change Sets, which allow for changes in metadata to be promoted from one org to another. As more and more “clicks, not code” packages are developed, the need to migrate record data has become as important as metadata. In these low-code managed packages, record data acts as configuration data, allowing administrators an easy, point-and-click way to configure how the app works. This is especially true in apps like FSL, CPQ, Conga, and FinancialForce, and as the popularity of low-code apps continues to grow so will the importance of managing changes to configuration data.
This is where it gets tricky. Records in different Salesforce orgs have different record IDs (unique identifiers used by Salesforce servers), so when you migrate record data, it’s hard to maintain relationships. It quickly becomes difficult or nearly impossible to know that “Account A” in your production org is the same “Account A” in your Full Sandbox (or dozens of other sandbox environments related to that same production org) are the same record. Even more difficult is understanding that “Jessica Collins” is a Contact related to “Account A” in all of those orgs. As you know, these relations can go many layers deep and wide.
While it is possible—with extreme diligence and many hours spent with CSV data loads—to migrate data, we recommend using our tools. Prodly can move an entire relational data set from one org to another (even multiple orgs) in minutes. Think of it as reusable change sets for data that can also interface with version control systems to allow for tracking, deploying, and reverting changes.
Now that we understand refreshes, data seeding and data migration, let’s talk more specifically about the different types of Salesforce orgs and best practices for organization and usage.
You definitely have one of these. You could possibly even have a whole bunch of production orgs. These should be your beautiful, fully-formed children that enable marketing, sales, service, support, and everything else at your company to produce results. If you’re maintaining multiple prod orgs, you’ll likely be running syncs and integrations between some of them to roll-up over-all performance of your company as a whole. You may even be planning how to merge a few of them together to make that experience easier. Production orgs need to be up and running and as bug free as possible, so this is not the place to try out new things.
Your Full Copy sandboxes are not cheap! Most businesses will have 1 or 2 per production org they maintain. They are there for when you need to understand the impacts of changes on your prod org holistically. Full Copy sandboxes give you the possibility to test and train on a replica of prod, without creating or modifying actual business critical data. This is key for being able to troubleshoot production issues, validate new functionality before moving it to prod, and getting feedback from end users during pre-go-live tests.
You will always want to keep Full Copy orgs in sync with production to achieve optimal results for these testing and training. This means Full Copy orgs are most valuable when they are refreshed as often as possible up to the limit of every 29 days. Far too often, companies find their Full Copy is the toughest to refresh because they are currently in use for active project work. This creates a catch 22 where Full Copies become a bottleneck to delivering enhancements to users.
Resist the urge (or pressure) to allow development work in your Full Copy sandbox. Instead, invest in a data migration tool like Prodly to make lower level orgs more palatable for development. Remember, to get the most out of your investment in expensive Full Copies you need to get data and changes in and out of them as quickly and effectively as possible. Do you have a Full Copy sandbox that hasn’t been refreshed for months? Years? If so, you’re spending a lot of money on something that is not as valuable as it should be.
Partial Copy is not just a clever name! It’s a sandbox that allows you to partially copy over records from a subset of objects in a Production org (up to 5GB). That’s a lot of records! But it’s usually not enough space to copy everything, so you must pick and choose what you want with templates. The records copied when you refresh a Partial Copy sandbox may not be everything you want or need to recreate the user experience in production. Most companies have 2-5 Partial Copies per Full Copy, with varying use of templates across the Partial Copy boxes.
Companies will typically maintain sandbox templates for a select number of broad use cases. Sales Cloud, Service Cloud, CPQ, FSL, or other custom apps may be some of the types of Partial orgs that people create. If a company has a small Salesforce dev/admin team, they may use Partial Copies to start dev projects or cycles. This would be considered a luxury for larger teams, where Partial Copies are reserved for merging in changes that have been made in DevPro sandboxes.
In general, the best use of Partial Copy orgs is to test new functionality built for different project purposes. Because they are cheaper, and easier to create as needed, Partial sandboxes are better suited then Full Copy sandboxes for longer testing cycles like UAT, where you may be making changes immediately to resolve bugs and user stories. If you need to do routine training, Partial orgs may be the way to go as well, since it is easy to set them up via templates to get what you need, without tying up the use of a Full Copy.
Developer Pro sandboxes are just Partial Copy sandboxes with no record data sent to them from Prod. You will get the metadata from Production (objects, fields, Apex code, managed packages, etc.) as a starting point, but no records. These are more plentiful than Partial Copies, and often companies will have many of these per Partial Sandbox. Dev Pro orgs are the best place to start development projects, as again, they are the cheapest and most disposable/replaceable orgs. It’s easy to let multiple devs/admins do their own work, undisturbed by worries of overwriting a co-workers changes, in these orgs. Dev Pro sandboxes are the best places to try out new ideas and solve problems needed for projects.
One of the difficulties of working in Dev Pro sandboxes is the lack of data in the org. In order to test their work, developers/administrators will need to seed data in the org or create records manually. Seeding sandboxes is a boring, annoying, time consuming, and frustrating process. Rather than waste their time with tedious data migration processes that introduce potential security risks for their data, some developers/admins will adopt the practice of starting dev work in Partial or Full Copy orgs. Don’t let your org strategy fall victim to this trap! The practice of developing in Partial and Full Copies holds up valuable resources and gets in the way of other people’s work. Prodly exists because we solve these governance pain points by making data readily available for Dev Pro orgs (and all other orgs), as well as helping get valuable configuration data out of these orgs, with the click of a button.
These are the future! Think of scratch orgs as faster, better, and easier to use versions of Developer Pro orgs powered by Developer Hub and Salesforce DX. The intent of scratch orgs is to allow devs/admins to quickly create an org to complete small tasks for projects that are being run on agile-like methodologies. The concept is that you make an org to use for a few days or a week, complete your work, promote it, and move on. With DX, you can craft a framework for what needs to be available in these orgs (metadata, managed packages, data), more readily connect to version control systems, and promote changes to Partial, Full Copy, or Production orgs.
Companies utilizing scratch orgs are often moving fast and keeping up with the dynamic challenges presented by their customers and competitors. Prodly has a DX plugin to aid in creating scratch orgs, so the setup for data seeding can be done without digging into complex configuration or code.
How often can you refresh a scratch org? Scratch orgs are disposable orgs, so you can create a new one whenever you need one.
What is the storage limit for a scratch org? 50 MB for files and 200 MB for data.
For the true trailblazing admin/dev, having a half-dozen or so Developer Orgs is a prerequisite. Dev orgs are where a lot of proof-of-concept, learning, or experimental work may be tried out before it’s anywhere close to being ready for prime time. Want to enable a new feature for the first time in an org to see what happens to everything else? You best be doing that in your own Developer Org.
These are not connected to production orgs, so they cannot be refreshed or sent metadata or data from one. However, Prodly can connect a dev org to production (or any other org) in your release path. This is particularly powerful if you have a unique data structure in a Developer org. Prodly can help you import or extract the data schema to any other org that you have a password to.
How often can you refresh a Dev sandbox? Developer orgs are not connected to Production so they cannot be refreshed.
What is the storage limit for a Dev sandbox? 200 MB for files and 200 MB for data.