In this blog, we discuss the benefits of version control for Salesforce CPQ configuration, such as the fact that it lets you roll back to prior states with laser precision. In addition, it helps you meet SOX requirements, collaborate more effectively, and implement an agile release management process.
Easily Roll Back to Prior States With Laser Precision
With a version control system (or “oops button,” as we like to call it), you can quickly and easily roll back a specific change or many changes to a mission-critical system like Salesforce CPQ.
Let’s say you’re having issues with a Price Rule. Your production org may have dozens or even hundreds of Price Rules, so figuring out which one contains the bug will take time. Do you really want to do that in production… while the downtime prevents sales reps from closing opportunities?
With a version control system (VCS), you have a running log of every change to your Salesforce CPQ configuration. This log is the source of truth for your CPQ implementation, which is why it’s called source code. In the case of CPQ, this includes configuration data.
So if there’s an issue, you simply hit the “oops button” and roll back the change to the previous version of the code. Now you’ve restored the system for users, you can do your debugging in a sandbox where you can’t do any damage.
Meet SOX Compliance Requirements
The Sarbanes-Oxley Act of 2002 is designed to help protect investors from fraudulent financial reporting by public corporations. For companies using Salesforce CPQ, this means they have to comply with two main requirements:
- They must maintain a complete audit trail of changes to all financial data, including pricing and products.
- They must maintain separation of duties.
Failing to meet SOX regulations can result in steep financial penalties, as well as prison sentences. For example, accountants and auditors who are not in compliance can face up to a decade behind bars.
Recently, auditors have started to catch on that record data falls within the scope of compliance requirements. Record data provides configuration for Salesforce CPQ.
Version control for Salesforce CPQ provides an immutable record of what changes were made, by whom, and who checked them in. And you need a version control system. Why? Because even if you haven’t heard anything from the auditors, you’re breaking the law if you’re not SOX compliant. That’s why it’s advisable to get ahead of the situation and implement version control (VC) as soon as possible.
Collaborate More Effectively With Version Control for Salesforce CPQ
A version control tool for Salesforce CPQ lets you collaborate more efficiently and effectively with your team. Everybody should configure their specific changes in their own environments. Once they’re done, they should check in their work to the source. As a result, every team member can work on their part of the project without fear of wiping out each other’s work.
In addition, with a version control system (VCS) for Salesforce CPQ, you can thoroughly review all proposed changes before deploying them. This gives you the opportunity to identify conflicts and errors. If there are any, you can resolve them before they go into production.
Implement an Agile Release Management Process
Clearly, Salesforce CPQ version control effectively facilitates an agile release management process. It helps you reduce development time and time spent troubleshooting. As a result, you can deploy successful changes faster.
What is version control?
Version control is a data management practice that’s also referred to as source control or revision control. It’s a critical tool for tracking changes to your Salesforce CPQ configuration data or record data as you move it through the release pipeline. This is especially true in an agile environment where you make changes quickly and dynamically. Learn more about version control.
What is a VCS and how does it work?
VCS stands for version control system. When you integrate Salesforce CPQ with a version control system, you can record and manage the changes you make to your configuration data.
You check a file out of the VCS, update it with the changes you’ve made, and check it back in. If any of the changes you made don’t work during testing, you can refer back to the source configuration file to revert the configuration back to the earlier version. Learn more about version control systems.