Pushing Changes Properly

Quick Note: I have another post which goes into how to create a sandbox and use a changeset to deploy from a sandbox environment to production. 

Introduction: Types of Salesforce Orgs

It’s important to begin by noting which types of “orgs” – organizations for short – are available. Remember, org types are not license types (Professional, Enterprise, Unlimited), nor are they Salesforce Products or Apps (Sales Cloud, Service Cloud, etc.)

Three Flavors


Production orgs are where the vast majority of Salesforce users spend their time. They are instances of Salesforce that are live.

This definition alone doesn’t make a lot of sense, but if you read on and understand what Sandboxes and Developer orgs are used for, this will make a lot more sense 🙂


A sandbox is a copy of a Production org. There are a couple types of Sandboxes, but for us right now it’s not important to touch on those. It’s only important to mention that a sandbox is connected to a production org, and will have the same settings and components as a production org, but without any data or with only a small subset of that org’s data.


A developer org is a free org that anyone can sign up for to either test out Salesforce or to build on the platform. Salesforce Developers might use a developer org (yup) to build an app that they later list on the AppExchange for others to install and utilize. Or, if they’re like me, they might just use a developer org to test out ideas and projects, design tutorials, or store some basic functionalities they want to reference later.

More on Sandboxes

Because they’re really important.

To expand on the definition given above, a Sandbox a copy of your Salesforce instance (your “production org”) that developers or administrators use to test changes before putting them in the hands of end users. The process of Salesforce development relies heavily on Sandboxes. Nonetheless, it’s actually pretty simple, and usually goes something like this:

1. Requirements are gathered

2. A solution is designed and discussed

3. An Admin or Developer (or a team of admins or developers) builds the solution within a Sandbox

4. The solution is tested to ensure it’s functioning properly

5. If all is well, the solution is “deployed,” or “pushed” into the production org

For Example…

A Salesforce Administrator is working for a very large organization – hundreds or thousands of active Salesforce users are creating and editing records each day. He’s been asked to write a trigger that performs some custom logic each time an Opportunity is created or updated.

You’ll notice we’ve jumped past steps one and two – these are steps where people have meetings and talk. No explanation necessary 🙂

If the administrator had the ability to start developing this trigger in the current, active Salesforce org, there’s a chance that during the course of development, the unfinished trigger will be active and could be making changes to new and existing records.

This is a nightmare scenario for a number of reasons – the biggest of which is that you may have potentially diminished the integrity of the data within the production organization – data that is used by users and leaderships to make decisions. Yikes. Similarly grave, you may have accidentally made a bunch of changes, additions, or deletions that you now need to clean up. Instead of spending time building things, your friendly Salesforce admin is running queries trying to figure out what changed and what he or she can salvage.

Enter the friendly Sandbox.

Instead of building in production, our admin goes to his setup panel and creates a new Sandbox. He logs into the new Sandbox and starts writing his code. Along the way, he creates and edits some records to test his solution. When he’s satisfied it’s working, he’ll write some test coverage (more on this in another post), execute those tests, and if it all goes according to plan, he’ll package the trigger and the test class into a changeset, and load it into the production org.

Then he’ll log into the production org, find the loaded changeset, validate it, and implement it. Validate and implement are complicated words, they’re really just the name of two buttons he’ll have to press if he’s done the development properly within the Sandbox. Once the code is implemented, it’ll be alive and working within the production org as designed – with much less risk of causing harm.

Of course, it’s very difficult to be 100% certain that changes won’t cause something to break unexpectedly. But by using a sandbox, we’re at least able to have a safe environment to work until we’re ready to deploy.

Final Thoughts (TL;DR)

One thing which always intimidated me was the process of deployment – the one explained above. I actually had a lot of fun learning to write Apex code and build Visualforce pages, even to build apps and workflows and load data in and out of orgs, but I never wanted to touch changesets and write test coverage.

Most of my fear was just misunderstanding. I thought the process would be tedious and awful – it’s slow at times, and frustrating, but it is worth it to save the headache of breaking something important in an org that is being actively used.

Final thoughts: use a Sandbox. Because what happens in Sandbox, stays in Sandbox. You can break things and sleep easy.

Hope this helps.

Add comment

Recent Posts