One of the major attractions of Salesforce as a CRM is its endless customization and configuration options. Clients have a lot of freedom to change and adapt production orgs to suit their business needs.

But that also entails significant risk in the form of changes in UI, accessibility, field management, and basic processes. The potential for disruption is huge here. This can be a problem, as in any organization, the end-users of business software thrive on stability and familiarity.

Even minor changes to the UX or redesigns of simple software can bring a lot of hand wringing and loss in productivity. And with a complex, feature-rich platform like Salesforce, adapting to new updates can seem overwhelming to teams.

A lot of this can be mitigated with a well-planned Salesforce change management strategy. Yet shockingly, the vast majority of Salesforce teams we talked to don’t have anything remotely close to that in their firms.

In this article, we will explain the main steps to creating an effective Salesforce change management process. 

Step 1: Planning

At this early stage, you will need to focus on the development or customization project you have in mind – the main driver of change on your Salesforce implementation. Look at the current state of your CRM processes – talk to the key stakeholders for inputs, analyze the problem areas that need to be addressed and come up with a plan that covers all the bases.

The next step is to create the design specifications for the new project – it could be objects/workflows/apps/UI changes processes/software updates/apps or more – there are plenty of ways to customize or configure Salesforce. Once your product manager or tech architect has created the specifications, have your dev team implement those changes.

Step 2: Developing

The second stage involves developing the work project per the design specifications set in step one. The best place to do this is in a Salesforce Developer sandbox. It allows you to work with the production org’s metadata without worrying about affecting the actual production data. This way, you can safeguard your existing Salesforce system from any adverse impacts.

Salesforce has a rich set of automations, components, APIs, layouts, and third-party integration options on its Lightning app development platform. Leverage this architecture to optimize your development – use a mix of declarative tools (Process Builder, the Custom Object wizard, and others in the UI) along with programming tools like the Dev Console, Source Code Editor, or the Visual Studio Code Editor.

Step 3: Testing

In tandem with your development process, you also need to run regular testing of each new update or change. This is software development 101 – always check new updates to ensure that they are working as intended. Do this before integrating changes into dev work done by other individuals or teams.

The focus here is on individual change management – where you test all the minor updates and changes. You can look at the big picture – how it all fits into the larger release version of the app – later, in the post-integration stage. It is best to do the testing in the same/similar environment as the development platform.

Ensure that these do not overlap – keep all testing environments in a separate, sandbox away from the actual development platform. A scratch org is the ideal platform for this kind of version-based, exploratory testing. Unlike a dev sandbox, you can create and delete new scratch orgs on demand.

Step 4: Build Release

This is the stage where you finally create a single coherent release of your development build. It contains all the components, features, functions, and assets that were created, modified, and tested during the previous stage. This is the set that you would ideally want to deploy for production, after a final round of testing.

This is a critical stage in the development process where attention to detail is everything. Build release management in Salesforce is incredibly nuanced, with various deployment/release options – Changesets, org development (via Salesforce CLI), unmanaged packages, or managed packages (1GP or 2GP) if you have independent software vendor partners.

You will usually have a highly qualified professional to oversee this critical stage – it could be a PDII certified advanced developer, or senior business analyst with a deep command over the technical aspect of Salesforce customizations. From this stage onwards, the focus is on the final release build, and not the minor changes or mods from individual devs.

Step 5: Test Release

If step three was all about micromanaging the smaller changes, this step is looking at the big picture – testing the full package/app in its deployment stage. As always, a safe and contained staging environment is the best place for this kind of testing. For best results, it should mimic the targeted Salesforce production environment as much as possible.

This can be achieved using a Salesforce Full or Partial Copy sandbox. The difference between the two largely boils down to storage size and data replication. In a full copy sandbox, the entire production data is copied. But this comes at the cost of refresh rate – a full copy sandbox can only be refreshed once every 29 days.

With a partial copy, you only get a small (5GB) sample of data, but it can be refreshed every 5 days. Partial copies are recommended for build and QA testing, while full copies are ideal for staging and key performance/load testing. Both are viable options for integration tests, User Acceptance Testing, and user training.

Regardless of the type of testing sandbox, usage of realistic production data is essential for maximum accuracy at this stage of the implementation process. Ensure that the data is representative of the final use cases and that the test environment is connected to relevant external systems to mimic a production system’s integration points.

Step 6: Release

This is the final stage where you deploy the changes to production. Success here hinges on your ability to familiarize the end-users with the new build. A lot depends on the size and scale of your new changes. If the customizations are large-scale and complex, you should allocate some time for user training in a Full Copy Build sandbox before release.

But for smaller, incremental changes and updates, user training can take place on the fly after release. Another thing that often gets ignored is live testing – this should be a priority after release. While the sandbox orgs try to replicate the production environment to a great degree, small differences still exist – often related to permissions.


Always keep in mind the potential user impact of a new customization or configuration project in Salesforce. Test release and final release are the two stages where you can fully sort out potential pain points. With a highly systematic approach, you can implement an effective change management process using the steps described above.

We cannot emphasize enough the need for an effective communication plan. The changes should be in sync with the needs expressed by the key stakeholders during the planning process. And later, the last two stages of the plan should allocate enough time for familiarizing users with the interface and process changes.

Chargent has robust customization options for users, including changes to the Payment Console, customized fields, custom email notifications and receipts, adding new functionality to workflows using the process builder, and a robust set of integration options – Developer API, gateway connectors, and more.

You can track and test each change safely using the Salesforce sandbox while using Chargent. It is fully optimized for the execution of a planned Salesforce change management strategy. With Chargent, you can evolve your Salesforce recurring billing on-demand with an effective change management process.