Salesforce Sandbox 101
If you’re tech-savvy or familiar with software, it’s likely you’ve used or even spun up a sandbox before. But if you’re new to Salesforce or the tech industry, you may be asking yourself…
What is a Sandbox?
Remember when you were a kid, during recess time, you and a bunch of your classmates would run over to the playground when the bell rang? Some kids went straight for the swings, some climbed the jungle gym, some went for the slide and a few others ran around playing tag. For the remaining ones, we jumped into the sandbox. The sandbox was enclosed and separated from the other parts of the playground. It allowed us to build creations out of sand, stone and stick with our imaginations while using tools like shovels, buckets and rakes.
A Salesforce sandbox is basically the same. Okay, there’s a few differences.
Remember when you became an adult, during work time, you and a bunch of your coworkers would log into your Salesforce org after you’d gotten some coffee? Some adults went straight for their reports, some followed up with their leads, some updated their contacts and a couple tinkered with the setup menu. For the remaining ones, we jumped into a sandbox. Sandboxes were their own environment, separate from the production org. They allowed us to build, customize and test data, metadata, configurations and automations.
Purpose of a Sandbox
For many users and companies, they find the idea of a sandbox cumbersome. They see it as extra steps to doing extra unnecessary work. After all, a sandbox is just a clone of the production environment. Why should you build things in a sandbox, only to replicate it again in production? Why should you do testing in a sandbox, only to do the same testing again in production? To ensure a smooth go-live release.
Just the same as how athletes practice before a real match, we want to make sure if we make any errors, we don’t make them in production. Errors in production can cause system breaks, disruptions and data issues. This can affect not only a single record or user, but the whole system and everyone who’s logged in trying to get their work done. Thus leading to lack of productivity, extra resources and time spent on fixing the issue(s) and potential loss of revenue.
Spending that time to carefully plan and test in the sandbox minimizes the chances of a disaster during production deployment.
Types of Sandboxes
Salesforce provides 4 types of sandboxes:
Developer
Developer Pro
Partial Copy
Full
Each sandbox has it’s own unique properties and limitations.
Developer Sandbox
Great for development and testing, the Developer sandbox replicates your production org’s configurations, metadata and users. They can be refreshed once per day and have a 200mb limit for data and file storage. The good news is most Salesforce editions include Developer sandboxes for you to use.
Developer Pro Sandbox
Similar to the Developer sandbox but with more storage. The Developer Pro sandbox comes with 1GB capacity. This allows for expanded capabilities such as integrations, testing small data sets, training and etc. However, Salesforce only includes this type of sandbox for Unlimited and Performance editions. All other edition types require an additional purchase.
Partial Copy Sandbox
Partial Copy sandbox allows for even more storage with a 5GB limit. It also copies a sample of data from your production org using a Sandbox Template, making it suitable for functional testing, user acceptance testing (UAT), user training and etc. This sandbox can be refreshed once every 5 days. Salesforce includes this sandbox with Unlimited, Enterprise and Performance editions. All other edition types require an additional purchase.
Full Sandbox
The Full sandbox is an exact duplicate of your production org. It has the same storage capacity and comes with all the data as well. Thus, making this even more ideal for UAT, load testing, user training and staging. The downside is that it can only be refreshed once every 29 days. Salesforce includes a Full sandbox with Unlimited and Performance editions. All other edition types require an additional purchase.
Creating a Sandbox
To create any sandbox, you will need to be in your production org. Note: you cannot create a sandbox while logged into another sandbox.
Go to Setup by clicking on the gear icon on the top right of the screen.
In the Quick Find box, search for “Sandboxes” and then select Sandboxes in the result.
Click on “New Sandbox”.
Enter a Name and Description for your sandbox. Be sure to make it descriptive so that you and other users know the purpose this particular sandbox is used for.
In the Create From pick list field, you will want to select Production.
Select the type of sandbox you want to create by clicking the Next button.
Click the Create button.
The sandbox creation process can take a few minutes to a few days depending on the type of sandbox you chose. The more data it needs to replicate, the longer it takes. You can view the progress by refreshing the page or you can wait to be notified when it’s complete.
Logging into Your Sandbox
There are 2 ways to log in to your sandbox.
Via Production
Log into your production org.
Go to Setup by clicking on the gear icon on the top right of the screen.
In the Quick Find box, search for “Sandboxes” and then select Sandboxes in the result.
From the list of Sandbox, select Login to the one you have created.
Via Login Page
Navigate to https://test.salesforce.com
To login, type the username of your production org and append a period and the name of your sandbox at the end.
Production username: myron@salesforce.com
Sandbox name: helloworld
Sandbox username: myron@salesforce.com.helloworld
Use the same password you use for your production org.
Learn More
There you have it - Sandbox 101. If you want to learn more about Salesforce Sandboxes and can’t wait for Sandbox 102, book a free consultation here https://calendly.com/nimbuscrmsolutions or send us an email at myron@nimbuscrmsolutions.com. Cheers!
