If you want to optimize your change management process in SFDC, we advise adhering to best practices for Salesforce ALM. These serve as guidelines to help you effectively plan, build, test, release, and monitor your changes and applications.
To achieve ALM Health, we recommend unifying the application lifecycle, as well as promoting collaboration and communication. It’s also advisable to establish a goal state for each change or project, use scratch orgs, and leverage automation. Last, but certainly not least, you should document all changes. Let’s take a closer look at each of these ALM best practices.
Within the Salesforce platform, the application lifecycle should be managed as a single, integrated process, all the way from ideation to deployment to maintenance. Using source control can help with this because it keeps track of all your changes and stores the different versions of your metadata and configurations.
This facilitates CI/CD, which ensures consistency throughout the various dev environments and makes sure they’re in sync. A version control system (VCS) also functions as a safety net in the event a change doesn’t function the way it should when you promote it to production. All you have to do is revert to the previous version of the code that’s stored in the source repository.
Another reason why a VCS is helpful in unifying the application lifecycle is because it serves as a safeguard in the maintenance stage if you have to make further changes over time.
The success of your ALM process hinges on creating an environment where developers and admins can communicate and collaborate effectively. You need to ensure that all stages of the lifecycle are well coordinated and that everyone’s in the loop when updates and changes occur. This is why a work management app and a VCS form integral parts of your ALM.
To work together seamlessly, admins and developers need full visibility of the progress of a project. This is a challenge with Salesforce out of the box, because it doesn’t have work management features built in. That means teams have to keep track of their changes and progress manually. Alternatively, they can toggle back and forth between a tool like Jira and Salesforce to properly document everything.
Fortunately, there are third-party tools like Prodly that provide integrations with Azure Boards and Jira. With Prodly, you can effortlessly link one or more work items to a deployment, and the integration keeps your progress up to date in both apps. As a result, it’s much easier for everyone on the project to work together.
Another way to promote collaboration is by implementing version control. A VCS minimizes the risk of conflicts in the code or configurations that stem from different developers using different data sets in the build stage.
With a VCS, everyone on the team relies on the same source of truth. This results in far fewer discrepancies in the build than there are when you’re working from non-uniform data. And when the development process is smoother, it enhances collaboration.
Before you build any new app or make any change, it’s advisable to establish a goal state so you know what you’re working towards.
In Salesforce ALM, a goal state includes the description of the desired functionality of a build and a definition of the scope of the project. A goal state can refer to a large project like an org merge or a smaller change like automating a workflow.
As a simple example, the goal state of a change could be to automatically update the related Account when the amount of an Opportunity is changed. This automation would make it much easier to keep your data consistent and up to date.
When defining the goal state of this change, you should list the trigger that initiated the automation and the specific steps it involves.
In this example, the trigger is that the amount of an Opportunity is changed. The steps are:
When you define a goal state, it becomes easier to clearly set out the requirements of the project. This in turns allows you to break up the project into smaller milestones where you can test and validate the changes you’ve made before moving on to the next step. As a result, you can identify and address any issues early in the development process instead of later—when they’re much more expensive to fix.
There are several benefits to establishing a goal state:
Salesforce ALM encourages the use of scratch orgs—disposable, temporary environments that are perfect for small builds or minor changes. Remember: It’s never wise to make a change directly in production because you simply don’t know for sure what its impact will be.
When you use a scratch org, you can quickly and easily isolate the code or configuration you need to change. You can do your work without worrying about your changes affecting the data in your production org or stepping on another developer’s toes. Scratch orgs are also a great option when you want to experiment with a new build without any risk to your production org.
The conventional way of setting up a scratch org is by using the Salesforce CLI. But if you want a faster, easier way, you can use Prodly to create a scratch org with exactly the right data and metadata—in just a few clicks.
A robust ALM process is efficient—and that’s where automation comes in. Because automation eliminates repetitive manual tasks, it accelerates the release process and makes it more consistent. With more consistency, you’ll experience fewer errors and bugs, which results in higher-quality changes.
There are two reasons to document all changes—so you have a roadmap to refer to and to safeguard your company against noncompliance.
You make frequent changes and updates to apps and components. On top of that, over time, the makeup of your team changes. Both these factors make it challenging to keep track of why and how a change was made—and what exactly that change entailed. So when a situation arises where something breaks, you need documentation that clearly explains why and how a change was made in the first place.
With Prodly, you can tie documentation in with work management, so every change is both logged and explained. If you need to revert a change, you can refer to the documentation for instructions.
If your company is publicly traded or if you’re planning your IPO, you need to document all changes to be in compliance with SOX regulations. Without having a record of what changed, why, when, and by whom, you’ll have a hard time complying with auditors’ requests for an audit report.
Prodly makes documentation easy by tying work management in with deployments. Because you can link one or more multiple work items to a deployment, you can easily see the history of and business need for each change.
By adopting these ALM best practices, you can establish and maintain a robust application lifecycle management process. You’ll be able to work more efficiently, collaborate more effectively, get higher-quality changes into your end users’ hands faster—and ultimately, help drive more revenue.
What is the difference between a goal state and a release?
A goal state defines how an application should work and what the scope of the project is. A release is a group of changes you make to an application that, after rigorous testing, you deploy to production.
What kinds of automation can I use in Salesforce ALM?
You can use a range of automation tools in Salesforce ALM, including automated work management, org management, version control, testing, deployments, and compliance.
What are some ways to measure the effectiveness of my ALM process?
Common metrics to measure how effective your ALM process is include:
The gold standard for documenting SOX in Salesforce CPQ!
