When it comes to custom Salesforce development, it’s highly recommended that you complete your work in a (newly created or recently refreshed) Salesforce Sandbox environment. After your work is completed and rigorously tested, you can then deploy or “migrate” your customizations to your Salesforce Production environment.
Let’s take a deeper dive into the native deployment tools available within Salesforce.
Wait, pump the brakes. Why create a Salesforce Sandbox in the first place!?
Let’s first understand the difference between a “Production” or “Live” environment and a “Development” or “Test”or “Sandbox” environment.
- Production aka “Live Environment” or “Production Org”
–This is your “live” Salesforce organization. - Sandbox aka “Test Environment” or “Development Environment” or “Development Org”
–This is your “test” Salesforce organization. This is a “copy” of your Production or “live” Salesforce organization.
The Sandbox is an isolated environment for Salesforce developers to build solutions, make changes, and test out ideas. Sandboxes provide a copy of the configuration and code (and in some cases the data) of the Production org.
Development should always begin in the sandbox and be tested rigorously prior to deployment. When our clients request that we build new features in their Production environment, we first spin up a Sandbox to develop and test those new features. Once those new features are built and tested in the Sandbox, we then “deploy” those changes to Production.
Change Sets can only be used to deploy architectural changes from your Sandbox org to your Production org (you can also deploy from one Sandbox to another, but we will cover that elsewhere). This is also referred to as “metadata.” In other words, you can create a custom field in your Sandbox and deploy it to Production, but you cannot deploy the field data itself that was in that custom field from the Sandbox to Production. And data specific updates (for example, changing a Lead Source on a Lead from “Website” to “Inbound”) must be done directly in Production.
Great, good to know…but how do I create a Salesforce Sandbox?
- Go to “Setup” and then enter “Sandbox” in the “Quick Find” search bar.
- Click on “Sandbox” and then click the “New Sandbox” button
- Sandbox Templates – List of objects you want to be copied to the Sandbox. This only applies to the creation of Partial Sandboxes. You can choose to only select specific objects, but to be safe just select the “Select All” option.
- Sandbox History tab – This tab shows a history of sandbox creation and refresh, and who completed these actions.
- Give your Sandbox a name and description
- For a Developer Sandbox, use a standard naming convention such as Dev1, Dev2, Dev3, etc. For the Partial Sandbox just call it “Partial.”
- In the description, put the name or initials of the developer (or team) that will primarily be using the Sandbox so as to differentiate their Sandbox from another developer’s Sandbox. The idea is that each developer or each developer team has their own environment to work from, unpolluted by those other nasty developer teams.
- Create From
- Choose the environment/org you want to copy. This could be Production (as this article lays out) or copied from a different Sandbox.
- When prompted to enter an Apex Class, leave it blank and click “Create”
- This is simply a spot to add a name of an Apex class that you’d like to execute immediately after the sandbox refreshes. This can be handy if you have a class which does initialization tasks, for example, the creation of your own object records that you want to test with in your Sandbox.
While your Sandbox is being created, you can monitor its creation. Timing can vary from within an hour to several days depending on the complexity of the Sandbox. Timing is managed by Salesforce.
Which Sandbox should I choose?
Next, select the type of Salesforce Sandbox you’d like to create.
Developer Sandbox
- This sandbox has no records but copies the “structure” of your production org. By structure I mean the custom fields, workflows, validations, etc. This is mainly for admins and developers to test new features or code.
- 200MB of data storage limit — in the realm of data science, this is a pretty small data storage limit. Developer sandboxes are not meant to contain or handle a ton of data. They are meant to accomplish quick development tasks.
- Can be refreshed once every day.
Partial Copy Sandbox
- In between the Developer and Full Copy sandboxes. Has some of the data from production (you define which), but not all.
- 5GB data storage limit – meant to handle a substantial amount of data and processing.
- Can be refreshed only once every 5 days.
Full Copy Sandbox
- This sandbox is just like your production org – records and all!
- Most accurate Sandbox for testing
- Can be refreshed only once every 29 days
- Typically requires you to pay Salesforce more money and purchase it (see your Salesforce Account Executive for pricing)
My Sandbox is created, what do I do now?
- Once your sandbox is created, go to Production ⇨ Setup ⇨ Deployment Settings ⇨ click on your sandbox ⇨ Check “Allow Inbound Changes”. This allows you to send Change Sets to Production from your Sandbox
- To log into your sandbox:
- Go to test.salesforce.com
- Use your Production username appended with .sandbox name. For example, if my production username is roy.wimer@parquet.dev and I created a sandbox called devsandbox, my Sandbox username would be roy.wimer@parquet.dev.devsandbox
- Use the same password you use when you log into your Production org
Working in the Sandbox (it’s a Sandbox world and we’re all living in it)
The most important feature of a Sandbox is the “Change Set.”
Sandbox Change Sets allow you to bundle all of your newly created work into one “set” in order to deploy it to Production. This prevents you from having to remake everything you made in the Sandbox again in the Production environment.
Change Sets are created from the UI via the Setup pages. You then pick which elements (objects, fields, classes, triggers) etc you want to add to your Change Set. When you are ready you upload your Change Set to Production.
You can also add profiles to the change set, which will pull in only the profile aspects that pertain to the elements in the change set. Let’s say I create a custom field in the Sandbox and I set the visibility of that field to System Admins only. In the Change Set, if I add the System Admin Profile, after I deploy the Change Set, the visibility settings will apply in Production. This resolves the classic problem we hear, “I deployed a custom field but none of my users can see it.” In this case, the Users can’t see the field because you didn’t deploy the User Profile in which you set the field visibility.
Deployment to Production (Now for the fun part. Wait, you are having fun, right…right?)
- Authorizing deployment connections
- In Production, go to Setup ⇨ Deployment Settings ⇨ select your Sandbox and check “Allow Inbound Changes”
- Create an Outbound Change set in sandbox
- In your Sandbox, go to Setup ⇨ Outbound Change Sets ⇨ click New
- Give your change set a name and description
- In the “Change Set Components” section click “Add” to add your different components.
- TIP: A process made in Process Builder is called a “Flow Definition”
- Upload from Sandbox to Production
- Click “Upload” and select “Production”
- Review inbound change and deploy
- Go to your Production org ⇨ Set Up ⇨ Inbound Change Set => click on your newly uploaded change set
- Click “Validate” to preview deployment results without committing any changes.
- Once the change set is validated, click “Quick Deploy” to deploy to Production
The incredible time saver – the “Add Dependencies” button.
Let’s say I create a custom object and one-hundred fields. I create my Change Set and now I need to click on each field I made, one-by-one, and add them to my Change Set? No. Just add the Custom Object to your Change Set and select the “Add Dependencies” button. This will bring up a list of all metadata dependent upon your Custom Object (page layouts, list views, custom fields, etc.), and you can select the specific metadata or “select-all”.
Don’t waste your time. Know that if you create a bunch of fields and different page layouts and list views, you don’t have to add them all individually (one-by-one) to your Change Set. Use the “Add Dependencies” button.
Common errors while you Deploy (The not so fun part)
If you run into errors during the deployment process, you will need to navigate back to your Sandbox org and fix them before repeating the steps listed above.
APEX Code – if you deploy any Change Set with code, the tests have to pass with at least 75% code coverage. If they don’t pass, you can’t deploy. This is Salesforce’s way of protecting itself…from itself. Salesforce will run those tests for you and if they fail, the deployment will fail automatically.
With a zero-code deployment, there are no tests. But you could still get errors. For example, a deployment could fail if you try to deploy a custom field on a custom object but first forget to deploy the custom object.
Routinely Refreshing your Sandboxes
Remember that when you create or refresh a Sandbox, it copies the most up-to-date version of your Production environment.
We recommend refreshing your sandbox when:
- You begin a new project
- After you deploy a major project
- In the absence of major deployments, put it on your calendar to refresh your sandboxes every 30 days.
ALERT! When you refresh a sandbox, any work that you have not deployed out of that Sandbox will be deleted.
———-
Deploying outbound Change Sets can be a bit of a headache, and some Salesforce Admins run into issues they’re not able to resolve on their own. If you need help creating or troubleshooting your Change Sets, reach out and let us know.
