At some point in their career, almost every Salesforce pro looks back and marvels at their early innocence—at a time when they simply made all changes in the production instance.
‍
At even moderate scale, that approach gives way to a regime of safeguards, checks, testing, and change management process. And it must. Because while nobody loves the process, they hate the dangers that result from a lack of process far more. And those dangers are great.
‍
A lack of Salesforce change management can directly curtail revenue—as when finance is unable to send invoices because of a validation error. Or when sales can’t log deals because of a picklist error. Or when a change set breaks something important and the easiest way to revert is to debug by hand … during the end of the sales quarter. Nobody wants to be the one responsible for that.
This guide provides practical wisdom and a step-by-step Salesforce change management approach to help you keep your many users productive and your environment blamelessly free of error.

What is Salesforce change management?

You might hear “change management” so much at work you could be forgiven for thinking it’s a buzzword, but it’s a very real term with a very real definition. Below, we’ve rephrased the Project Management Institute’s definition to be more concrete and specific to Salesforce:
‍

If we deconstruct that term—change management—we find many layers: Yes, to effectively enact change of your own, but also to catch, redirect, and manage the unexpected additional change that your initial changes triggered. Many Salesforce administrators well know the sense of paralysis someone can feel when they’ve inherited a highly customized environment and fear making updates lest something break.
‍
Change management pros prepare for everything—both known unknowns and unknown unknowns—and everything in between. And as business engineers, they take ultimate responsibility for issues, even when those issues are rare and unusual. Because, as the developer adage goes, the question is never, “Why did the user get it wrong?” It’s, “Why did you build a system that was susceptible to user error?”
‍

Benefits of Salesforce change management

Launching and adhering to a change management process works like installing a stoplight. It slows down everyone a little, but it speeds up the organization as a whole. That process prevents someone from simply adding undocumented custom Apex code as a patch (slows the individual), but because of that, nobody will ever have to spend days wondering why something broke after an update (speeds up the organization).
‍
Because of that structure, more people across the organization will be able to understand how your various Salesforce environments are configured. That means more people can troubleshoot, and feel empowered to confidently make changes, if permitted.
‍
Change management makes your organization:

• More agile—and better able to react to change
• Smarter—you can draw from a more diverse range of contributors
• Leaner—with less technical debt (though not all tech debt is bad)
• Less susceptible to impact analysis paralysis
• Less risky—there’s less danger of brain drain when someone leaves the organization
• More compliant—there’s documentation to appease auditors
• Faster—it reduces overall effort
  ‍

The best approach to Salesforce change management

You’ll find lots of generic models for change management out there, but we find that the best ones are specific to Salesforce—like the one below. A CRM has a very specific set of users with revenue-related needs, and implementing changes means knowing what they want and how you might disrupt it.
‍
For example:

• Salespeople are notoriously resistant to change. And the CRM is their virtual office. They expect everything to be just as they left it, and big changes can affect their livelihood. They value consistency, simplicity, and time savings. They’re measured on activities and sales.
• Marketers want cleaner data. They use many marketing tools that all treat the CRM as the source of truth, and small changes can trigger prospect or customer communications. Most struggle to attribute their efforts to outcomes and can never have enough data, or enough data quality. They’re measured on leads, conversions, and possibly revenue.
• Customer success teams crave advance warning. Success teams want to know more about their customer. Many use spreadsheets and outside applications for insight into account health. If an account calls, that account expects the rep to know everything about them. They’re measured on renewals.
• Finance teams want exact data. Discrepancies between Salesforce and the ERP means more work. They’re measured on not making errors and revenue recognized.
• Executives want simple answers to questions. Is a sales region underperforming? Is there enough pipeline to support their growth numbers? Is it time to hire? They’re measured on overall growth.
  

When you manage change, you’re managing changes in which all the aforementioned roles have a stake.

There are four phases to our model of Salesforce change management:

#1. Plan

#2. Organize

#3. Change

#4. Integrate

Any Salesforce change should flow through the four phases depicted. While you can always step backward in the process, as in the case where you've realized you’d scoped things poorly and return to the planning phase, you can never jump ahead.
‍
Together, the four phases constitute a process that helps you solve problems without creating bigger ones.

1. Plan

Always document your change rationale, and that rationale should always be rooted in an observed phenomenon. What can seem like busywork is in fact an agreement tool: Very often, the business will request things they themselves have not fully thought through. Or, just as common, they’ll propose a change that doesn’t really address the root cause. For instance, when a marketing team requests adding a checkbox field rather than updating the picklist.
‍
By forcing every request through a battery of questions, you make the fittest ones the best version of themselves, and relegate the least fit ideas to the backlog or the trash bin.
‍
Specifically:

• Maintain a request backlog—with a form for the business to submit structured requests
• A functional requirements doc—aka a brief for requesters to fill out
• Meet as a team to rank and prioritize worthy ideas
• Promote worthy ideas to the production calendar
  

2. Organize

Once you select an idea for implementation, analyze the impact of that change. What might break in finance if you adjust the opportunity object? What implications could a custom object have on marketing attribution? What workflows or other systems rely on expected values for that field?

Depending on the size of the change, you may want to conduct user acceptance testing (UAT).
‍
Specifically:

• Establish roles and responsibilities
• Use a project management tool—this provides a Gannt chart where you can document dependencies between tasks and track progress
• Allow users to submit requests
• Conduct impact analysis on proposed ideas to rate them by difficulty
  
• Assign an owner
  

In our experience, you want to allow users enough freedom to fully explain their needs and rationale, but also provide a framework for thinking it through.
Avoid creating too rigid of a template, with many required fields. This will only encourage users not to submit changes—or worse, to enter dummy data to get their request submitted.
‍
A simple template like the following could be a good starting point:
‍
Submitter: [Name]
‍
‍Requested Change: [Explanation of what needs to be changed]
‍
‍Business Impact: [The “why.” E.g. What is the impact of not making this change? How much time is being wasted?]
‍
‍Priority: [Nice to have, Should have, Must have]

This should provide enough information for you to prioritize it in your request backlog and investigate it further.

3. Change

Thoroughly peer review any change set before it’s implemented. The best practice for that is to maintain, at minimum, four environments:

• Full sandbox—a complete replica of your production environment including metadata, data, and third-party applications
• Partial sandbox—all your production metadata but only a subset of the data
• Developer sandboxes—all your production metadata but no data
• Production—the actual production instance
  

As you work on change sets, run them through a progression of increasingly realistic tests to ensure those changes will have the intended effect. Once you’re thoroughly convinced, push to production.
‍
If you make the change and something unexpected breaks, you’ll want the ability to undo the change—which requires you maintain a prior version of your configurations and metadata. Salesforce won’t do this for you, so you’ll either need to export an image of your instance weekly, and right before each change set, or use what’s known as a versioning tool.

4. Integrate

Document everything that occurred—the change, the rationale, the effects, and the lessons learned. As you can’t document things at this level of specificity in Salesforce, you’ll need third-party Salesforce change management tools. That includes, at minimum, a ticketing software such as Jira or ServiceNow, where you can add Salesforce change numbers to tickets.
‍
Documenting your changes is how you’ll grow your team. It’s the only way newcomers will have sufficient context to quickly be productive. But it’s also a minimum requirement for some U.S. regulations such as SOX.
‍
Specifically:

• Create documentation as a byproduct of doing work
  
• Add a contingency plan to your change management process

The key to Salesforce change management

Publishing a Salesforce change management process is one thing. Getting others to adhere to it is another. But that’s all part of the job of a business engineer—you take responsibility not for simply constructing a system, but constructing a system that helps you and the entire company achieve a desired state in Salesforce consistently—with the least pain possible.
‍
And to that end, the best Salesforce change management process is the one you have and stick with. In your own journey, don’t let “perfect” become the enemy of “good.” Start with what you have, where you are, and the Salesforce change management tools at your disposal, and build to solve problems one at a time.