One of Salesforce’s major attractions as a CRM is its endless customization and configuration options and widespread adoption within an organization. Clients have a lot of freedom to change and adapt production orgs to suit their business needs.
However, that also entails significant risk in the form of changes in accessibility, management, and basic processes. The potential for disruption is huge here. This can be a problem for many organizations because the end-users of business software thrive on stability and familiarity.
Luckily, you can mitigate disruption caused by Salesforce adoption with a well-planned Salesforce change management strategy. Yet shockingly, the vast majority of Salesforce admins we talked to don’t have that formalized in their company.
This article will outline the main steps to creating an effective Salesforce change management process and how to ensure success when implementing or updating Salesforce.
What is Salesforce Change Management?
Before we outline the six steps to achieving an effective change management Salesforce process, let’s first define the phrase “Salesforce change management process.”
First, change management refers to the process of dealing with transformation in an organization’s processes and technologies. It helps minimize resistance and disruptions that occur after implementing changes to what your organization’s stakeholders consider “normal operations.”
From that definition, understanding what Salesforce change management is becomes easy.
Salesforce change management refers to the practices that organizations use to effect technological changes related to Salesforce.
These changes can include:
- Initially adopting Salesforce
- Upgrading to new or additional Salesforce features or products
- Restructuring business processes to better leverage Salesforce capabilities
Whatever the case, change management is essential to ensure you successfully implement these updates.
Step 1: Planning
Creating a plan for your Salesforce change management approach is important because it acts as a guide for how you will implement modifications to increase the chances of success. A plan is vital to help you identify all the areas that need change and execute effectively.
In this step, you can follow these milestones to make your plan effective:
- Look at the current state of your CRM processes: This is essential to identify the problem areas that need to be addressed and develop a plan that covers all the bases. To do so, you should talk to the key stakeholders for input.
- Create the design specifications for the new project: Based on your findings, you can now design the plan for how you will adopt or modify Salesforce. This plan should cover objects, workflows, processes, software updates, apps, and more – there are plenty of ways to customize or configure Salesforce.
Step 2: Developing
The second stage in the change management Salesforce process 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 using a mix of declarative and programming tools.
Declarative tools may include:
- Process Builder
- Custom Object Wizard
- Others in the UI
Programming tools may include:
- Dev Console
- Source Code Editor
- 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 they work as intended. Do this before integrating changes into dev work done by other individuals or teams.
Unit Testing
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, including:
- Changesets
- Org development (via Salesforce CLI)
- Unmanaged packages
- Managed packages (1GP or 2GP) if you have independent software vendor partners
You will usually have a highly qualified professional overseeing 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 onward, 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.
To do this, you can conduct several several tests, including:
- Integration tests: This tests how different units of change work together when combined with the larger applications and systems.
- Functional testing: This verifies things work as they are supposed to.
- Security testing: After implementing changes on Salesforce, you must test to confirm that the security of your system remains intact and isn’t compromised.
- Load testing: This measures the scalability of the system under different loads.
Salesforce allows you to conduct these tests using its 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. However, 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. The two main activities under this step are user training and live testing.
User Training
If the customizations are large-scale and complex, you should allocate some time for user training in a Full Copy Build sandbox before release. However, for smaller, incremental changes and updates, user training can take place on the fly after release.
There are several ways you can conduct user training, including:
- Live training through webinars
- Sharing user manuals or online learning materials
- Providing ongoing live support
Live Testing
Another thing that is often overlooked is live testing. This should be a priority after release. Also known as beta testing, this testing evaluates the software’s usability under real-world conditions. While the sandbox orgs try to replicate the production environment to a great degree, small differences still exist — often related to permissions.
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.
To do this, you can conduct several several tests, including:
- Integration tests: This tests how different units of change work together when combined with the larger applications and systems.
- Functional testing: This verifies things work as they are supposed to.
- Security testing: After implementing changes on Salesforce, you must test to confirm that the security of your system remains intact and isn’t compromised.
- Load testing: This measures the scalability of the system under different loads.
Salesforce allows you to conduct these tests using its 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. However, 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. The two main activities under this step are user training and live testing.
User Training
If the customizations are large-scale and complex, you should allocate some time for user training in a Full Copy Build sandbox before release. However, for smaller, incremental changes and updates, user training can take place on the fly after release.
There are several ways you can conduct user training, including:
- Live training through webinars
- Sharing user manuals or online learning materials
- Providing ongoing live support
Live Testing
Another thing that is often overlooked is live testing. This should be a priority after release. Also known as beta testing, this testing evaluates the software’s usability under real-world conditions. While the sandbox orgs try to replicate the production environment to a great degree, small differences still exist — often related to permissions.
Best Practices for Salesforce Change Management
While the steps outlined above can help you create a strong Salesforce change management tactic, these additional practices can ensure that the process is successful:
Get Executive Buy-In
With Salesforce change management, you first and foremost want to be certain that you get support from top management — essentially the decision makers — in your organization. When these leaders fully support your cause for implementing Salesforce, it gives your efforts credibility.
For one, it sends a strong message to the rest of the employees and the organization as a whole that leveraging Salesforce isn’t just a passing fad. Rather, it is a strategic move aimed at improving company processes and achieving growth goals. This makes it less likely to get resistance from employees.
Moreover, executive support means that you have a likelihood of getting more of the resources you require to implement all the changes your organization may require, whether it’s funding, personnel, or time.
Set Up a Change Management Team
Once you have support from top management, you’re well on your way to adopting Salesforce into your organization’s processes. One of the most important aspects you should channel your resources toward is creating a dedicated team to handle all the related tasks.
To do this, you can either hire an external change management team or create one internally, depending on your budget. This team will be fully dedicated to fostering maximum adoption throughout the organization. For instance, your change management teams may include roles such as:
- Project manager: This is the “leader” who oversees the change management process. They come up with the change management strategy and verify that team members carry out their roles as required.
- Change champions: These are individuals who advocate and facilitate the Salesforce change management process. They are usually the first point of contact for advice or questions concerning change.
- Communication specialists: These team members ascertain that there is sufficient communication within the change management team and with the rest of the organization. They act as facilitators and organizers of change management meetings and keep everyone up to date with progress to facilitate communication.
- Training specialists: They develop comprehensive training programs for employees and stakeholders to confirm all users know how to use Salesforce and any changes involved.
Conduct a Change Readiness Assessment
It’s also important to make sure that your organization and everyone involved are ready and receptive. This is essential because if your organization isn’t ready, then the changes you wish to implement won’t be well received or have the desired outcome.
To gauge your organization’s readiness, ask the following questions:
- Do employees understand why the change is necessary and what it entails?
- Do they understand what the end goal is?
- What is the culture within the organization in regard to change management? Is it open to change and innovation, or is there resistance to new technologies and processes?
- Do the leaders, decision-makers, and top management support the change initiatives?
- Does the organization have the necessary resources, both in terms of budget and staff, to support the Salesforce implementation?
Leverage Tools that Make the Transition Easier
Adopting Salesforce for the first time or upgrading to new features can be a lot to take in for employees in your organization. Take advantage of tools that seamlessly integrate Salesforce with your workflows and reduce the impact of disruptions in your processes.
For instance, if your organization wants to start processing payments through Salesforce, leveraging Chargent can help. Chargent is a native payment processing app that seamlessly integrates with Salesforce, making the process of adopting Salesforce easier. Moreover, Chargent has a support team that is always ready to help if your team experiences challenges.
Track All Changes
Another Salesforce change management best practice is to thoroughly document all your changes from beginning to end. Documentation acts as a point of reference for all involved stakeholders and future employees in case they need clarification on new features and how to use them.
Monitor, Evaluate, and Optimize
The work isn’t done after you implement the changes in Salesforce. You must monitor your systems to verify that everything works as intended. Even with vigorous live testing, new issues in the real world may affect performance.
Additionally, you must evaluate the effectiveness of your changes on the overall business. Did the changes effectively solve the issues you were trying to fix? If not, what can you do to further improve?
Conclusion
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 enjoy an effective Salesforce implementation change management process using the steps described above.
An effective communication plan is non-negotiable. The changes should be in sync with the needs expressed by the key stakeholders during the planning process. Later, the last two stages of the plan should allocate enough time to familiarize users with the interface and process changes.
Streamline Your Salesforce Change Management
Chargent is a Salesforce payment processing tool that can help streamline your adoption of Salesforce. With Chargent, you gain access to a suite of customization options designed to streamline your payment processes and enhance your Salesforce experience.
Chargent also offers a comprehensive set of integration options to seamlessly connect your Salesforce environment with external systems. Whether you’re using the Developer API to build custom integrations or leveraging Chargent ‘out of the box’, Chargent allows you to capture more return on your Salesforce investment.