Sandbox management
April 26, 2024
How to choose the right Salesforce sandbox for the job
When to use what type of org
.jpeg){kind=avatar}
Getting everything that you need in your Salesforce production environment 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 don’t even have a Full Salesforce sandbox 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’s the best environment for getting this done most effectively?” or, “Why haven’t we refreshed this Partial sandbox in two years?” aren’t 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.
First, let’s talk about the different types of Salesforce environments 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 instances, you’ll likely be running syncs and integrations between some of them to roll up overall 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 isn’t the place to try out new things.
Full Copy sandboxes don’t come cheap! Most businesses have one or two per production environment. They’re there for when you need to understand the impacts of changes on production 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 to 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 should always keep Full Copies in sync with production to achieve optimal results for testing and training. This means Full Copies are the most valuable when they’re refreshed as often as possible up to the limit of every 29 days. Far too often, companies find their Full Copy’s the toughest to refresh because it’s 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 isn’t as valuable as it should be.
How often can you refresh a Full Copy sandbox? Every 29 days
What is the storage limit for a Full Copy? Full sandboxes have the same storage limit as your production instance.
“Partial Copy” isn’t 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 there’s usually not enough space to copy everything, so you have to 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 typically maintain sandbox templates for a select number of broad use cases. Sales Cloud, Service Cloud, CPQ, FS, or other custom apps may be some of the types of Partial orgs that people create. If a company has a small Salesforce team, they often 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 Copies is to test new functionality built for different project purposes. Because they’re cheaper and easier than Full Copies to create as needed, Partial sandboxes are better suited to longer testing cycles like UAT, where you might 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’s easy to set them up via templates to get what you need—without tying up the use of a Full Copy.
How often can you refresh a Partial Copy sandbox? Every 5 days.
What is the storage limit for a Partial Copy? They have the same file storage limit as your production instance and 5 GB of data storage.
Developer Pro sandboxes are just Partial Copy sandboxes with no record data sent to them from prod. You get the metadata from production—objects, fields, Apex code, managed packages, etc.—as a starting point, but no records.
They’re more plentiful than Partial Copies, and often companies will have many of these per Partial Sandbox. DevPro orgs are the best place to start development projects as again, they’re the cheapest and most disposable or replaceable orgs. It’s easy to let multiple devs and admins do their own work, undisturbed by worries of overwriting a co-workers changes, in these orgs. DevPro sandboxes are the best places to try out new ideas and solve problems.
One of the difficulties of working in DevPro sandboxes is the lack of data in the org. In order to test their work, developers and admins 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 folks 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 DevPro orgs (and all other orgs), as well as helping get valuable configuration data out of these orgs—with the click of a button.
How often can you refresh a DevPro sandbox? Once per day.
What is the storage limit for a DevPro sandbox? 1 GB for files and 1 GB for data.
For the true trailblazing admin or 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 aren’t connected to production orgs, so they can’t be refreshed or receive metadata or data from one. However, Prodly can connect a Dev org to production. 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 aren’t connected to production, so they can’t be refreshed.
What’s the storage limit for a Dev sandbox? 200 MB for files and 200 MB for data.
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.
Scratch orgs allow devs and admins to quickly create an environment 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.
Now you know the best ways to use your different Salesforce environments as part of an overall org strategy, it’s helpful to understand how these orgs are 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’ll 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 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 reduces 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.
You might also like: Salesforce sandbox seeding basics
For metadata, migration between Salesforce orgs is pretty well understood. This is the function of change sets, which allow changes in metadata to be promoted from one org to another.
As more and more low-code/no-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, giving admins an easy point-and-click way to configure how the app works. This is especially true in apps like FS, CPQ, Conga, and FinancialForce. As the popularity of low-code apps continues to grow, so too 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 record as “Account A” in your Full sandbox (or dozens of other sandbox environments related to that same production org). 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.
You might also like: When do Salesforce record IDs change?
While it’s 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. Get a demo today!
Maximize your Salesforce orgs with sandbox management
The frequency of refreshes depends on your development cycle and your organization’s specific needs. We recommend refreshing sandboxes after major releases or when you’ve made significant changes to production. This way, you can keep your testing environments up to date.
Best practices include maintaining a clear sandbox strategy, regularly refreshing sandbox data, restricting sandbox access to necessary personnel, and testing thoroughly before pushing changes to production.
Getting everything that you need in your Salesforce production environment 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 don’t even have a Full Salesforce sandbox 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’s the best environment for getting this done most effectively?” or, “Why haven’t we refreshed this Partial sandbox in two years?” aren’t 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.
First, let’s talk about the different types of Salesforce environments 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 instances, you’ll likely be running syncs and integrations between some of them to roll up overall 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 isn’t the place to try out new things.
Full Copy sandboxes don’t come cheap! Most businesses have one or two per production environment. They’re there for when you need to understand the impacts of changes on production 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 to 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 should always keep Full Copies in sync with production to achieve optimal results for testing and training. This means Full Copies are the most valuable when they’re refreshed as often as possible up to the limit of every 29 days. Far too often, companies find their Full Copy’s the toughest to refresh because it’s 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 isn’t as valuable as it should be.
How often can you refresh a Full Copy sandbox? Every 29 days
What is the storage limit for a Full Copy? Full sandboxes have the same storage limit as your production instance.
“Partial Copy” isn’t 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 there’s usually not enough space to copy everything, so you have to 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 typically maintain sandbox templates for a select number of broad use cases. Sales Cloud, Service Cloud, CPQ, FS, or other custom apps may be some of the types of Partial orgs that people create. If a company has a small Salesforce team, they often 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 Copies is to test new functionality built for different project purposes. Because they’re cheaper and easier than Full Copies to create as needed, Partial sandboxes are better suited to longer testing cycles like UAT, where you might 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’s easy to set them up via templates to get what you need—without tying up the use of a Full Copy.
How often can you refresh a Partial Copy sandbox? Every 5 days.
What is the storage limit for a Partial Copy? They have the same file storage limit as your production instance and 5 GB of data storage.
Developer Pro sandboxes are just Partial Copy sandboxes with no record data sent to them from prod. You get the metadata from production—objects, fields, Apex code, managed packages, etc.—as a starting point, but no records.
They’re more plentiful than Partial Copies, and often companies will have many of these per Partial Sandbox. DevPro orgs are the best place to start development projects as again, they’re the cheapest and most disposable or replaceable orgs. It’s easy to let multiple devs and admins do their own work, undisturbed by worries of overwriting a co-workers changes, in these orgs. DevPro sandboxes are the best places to try out new ideas and solve problems.
One of the difficulties of working in DevPro sandboxes is the lack of data in the org. In order to test their work, developers and admins 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 folks 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 DevPro orgs (and all other orgs), as well as helping get valuable configuration data out of these orgs—with the click of a button.
How often can you refresh a DevPro sandbox? Once per day.
What is the storage limit for a DevPro sandbox? 1 GB for files and 1 GB for data.
For the true trailblazing admin or 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 aren’t connected to production orgs, so they can’t be refreshed or receive metadata or data from one. However, Prodly can connect a Dev org to production. 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 aren’t connected to production, so they can’t be refreshed.
What’s the storage limit for a Dev sandbox? 200 MB for files and 200 MB for data.
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.
Scratch orgs allow devs and admins to quickly create an environment 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.
Now you know the best ways to use your different Salesforce environments as part of an overall org strategy, it’s helpful to understand how these orgs are 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’ll 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 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 reduces 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.
You might also like: Salesforce sandbox seeding basics
For metadata, migration between Salesforce orgs is pretty well understood. This is the function of change sets, which allow changes in metadata to be promoted from one org to another.
As more and more low-code/no-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, giving admins an easy point-and-click way to configure how the app works. This is especially true in apps like FS, CPQ, Conga, and FinancialForce. As the popularity of low-code apps continues to grow, so too 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 record as “Account A” in your Full sandbox (or dozens of other sandbox environments related to that same production org). 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.
You might also like: When do Salesforce record IDs change?
While it’s 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. Get a demo today!
Maximize your Salesforce orgs with sandbox management
The frequency of refreshes depends on your development cycle and your organization’s specific needs. We recommend refreshing sandboxes after major releases or when you’ve made significant changes to production. This way, you can keep your testing environments up to date.
Best practices include maintaining a clear sandbox strategy, regularly refreshing sandbox data, restricting sandbox access to necessary personnel, and testing thoroughly before pushing changes to production.
.png)