Tag Archives: salesforce devops

An illustration of a small, medium-sized, and large rocket representing how DevOps can make your release management in Salesforce more scalable

Salesforce ALM Is More Scalable With DevOps

An illustration of a small, medium-sized, and large rocket representing how DevOps can make your release management in Salesforce more scalable

Salesforce application lifecycle management (ALM) is becoming increasingly important to businesses’ agility. In this blog, we explain that you can apply the DevOps fundamentals of automation, version control, CI/CD, and agile to make your Salesforce ALM more scalable.

DevOps Fundamentals for Scalable Salesforce ALM

Your users want changes at the speed of business. Unfortunately, traditional change management practices are often time consuming, labor intensive, and prone to error. This is where DevOps comes in.

By incorporating DevOps fundamentals into the development process, you can ramp up your Salesforce ALM. Let’s take a closer look.


Automation is essential to DevOps. When you automate repetitive, time-consuming tasks, you can free up valuable time and resources to focus on higher-value work. As a result, automation in ALM can help minimize errors, increase consistency, and improve speed. Plus, it reduces the amount of boring busy work you have to do—and that’s always a good thing!

Data deployment automation in Salesforce eliminates the need for manual intervention. This in turn reduces the risk of human error that could cause problems further up the release pipeline. 

At the same time, automated testing catches bugs and issues that could affect end users early in the development process. This improves the quality of your releases. 

It’s also smart to automatically create release notes, alerts, and notifications. This saves a considerable amount of time and effort while ensuring everyone on your team has sufficient information at their fingertips. 

For instance, an automated deployment tool like Prodly DevOps lets you deploy work in 80 percent less time! We’re talking just minutes to promote work to the next stage—not hours!! 

You can also use automated sandbox seeding to quickly push up-to-date production data into a Developer Sandbox or scratch org. This makes your lower-level org just like a segment of production, so you can confidently make changes without worrying about bugs and issues later.

Version Control

Version control for both metadata and configuration data is also a critical component of DevOps. A version control system (VCS) lets you effortlessly keep track of changes, collaborate more effectively with team mates, and manage code conflicts more easily. Plus, it ensures everyone’s working from the same source of truth when you have a large development team. 

In Salesforce DevOps, it’s especially important to have a VCS like Git due to the complexity of the platform. Because a VCS automatically tracks all changes, you can easily roll back changes to a previous version if needed. That’s why a VCS is sometimes also referred to as “the oops button.”

Let’s say you deployed a new configuration to production but it’s preventing a flow from being triggered. All you have to do is roll back the change by reverting to your previous version of the configuration in your VCS. Then you can isolate the code with the bug, fix it, and test it before deploying it again. It’s a good safety net to have.


Continuous integration/continuous delivery (CI/CD) is another important DevOps principle that can improve Salesforce ALM. CI/CD involves automating the build, test, and deployment process and constantly pushing small changes to development. This iterative, incremental approach to change management allows you to release changes quickly and safely.

For example, you’re building a new app that will enable users to integrate their Salesforce org with the latest generative natural language model. You start by building, testing, deploying, and releasing the basic app that lets users leverage AI to write and check code. 

Based on user feedback, you discover that the app is rather slow. So in your next sprint, you refine the configuration to make it faster. Your users like this, but they’ve found another bug. In your next sprint, you fix that. This is what we call iterative development. 

(Did you know you can establish CI/CD in Salesforce without Git? This can be helpful if you want to apply some principles of DevOps, but aren’t ready yet for version control.)

Agile Development Practices

Agile as a methodology predates DevOps. In fact, DevOps complements agile. So by following agile development practices in Salesforce ALM, you can respond quickly and effectively to change requests. This benefits your end users tremendously.

In agile, you prioritize the most important work and use feedback to improve and build upon it. This ensures you’re delivering value to end users as quickly as possible. Agile also promotes communication and collaboration. As a result, you and your team can more successfully perform releases and complete projects. 

Let’s use the same example as above. To establish this iterative development process, you need all team members to work closely together. This includes documenting the changes you make, keeping each other informed about progress, and working together to brainstorm fixes and improvements.

Scale Your Salesforce ALM With DevOps

Keep these fundamental DevOps principles in mind to minimize bugs, eliminate repetitive manual work, and prevent bottlenecks in the release pipeline. You’ll soon see your release management process skyrocket!

You can do far more with fewer resources, and you can do it much faster than with traditional release methods. This means you can complete more change requests and better support your end users, which ultimately benefits your entire organization. It also means you don’t have to work late or on weekends anymore—and that’s awesome for your Salesforce work-life balance! You’ll have way more free time!

This blog was first published on www.salesforcedevops101.com on February 23, 2023.


What does Salesforce application lifecycle management (ALM) involve?

Salesforce ALM comprises the planning, building, testing, deployment, and monitoring of changes to your production instance. The DevOps steps—build, test, and deploy—require seamless communication and collaboration between the development team and the operations team. Learn more about Salesforce application lifecycle management.

Why do I need automation in Salesforce ALM?

Automation allows you to plan, coordinate, and deploy changes into production with a minimum of manual work. It minimizes the time and effort you spend on repetitive tasks, improves accuracy, and speeds up the change management process significantly.

Salesforce DevOps tools for CPQ

CPQ With Salesforce DevOps Tools vs. Without

The Benefits of Using a DevOps Tool for Salesforce Revenue Cloud

Salesforce CPQ (or Revenue Cloud) is a highly useful tool to streamline the configure, price, quote process in Salesforce. But did you know you can enhance that process even further with Salesforce DevOps tools like the Prodly DevOps platform?

Salesforce CPQ With a DevOps Tool

Salesforce DevOps tools for CPQ

DevOps involves several key principles, including the automation of as many processes in the development lifecycle as possible. A comprehensive Salesforce DevOps tool automates many of the tasks involved with the change management process in Salesforce CPQ, including:

  • Sandbox seeding: Avoid conflicts with instant, on-demand, data-rich development environments for each individual team member.
  • Sandbox management: Easily spin up, sync, and refresh new sandboxes. Use data replication tools to make them look like production—and save money you’d otherwise spend on a Full Copy.
  • Version control: Quickly roll back changes with easy access to previous iterations of every configuration.
  • Regression testing: Avoid costly downtime by testing work earlier in the process—and prevent bugs from making it into production.
  • Salesforce CPQ data model deployment: Deploy complex relational CPQ schema in minutes, not days, with pre-built automation templates.
  • Audit trail: Ensure SOX compliance with a detailed audit log of every change at your fingertips.

On top of that, a DevOps tool ensures continuous integration and delivery of changes in Salesforce CPQ. This empowers your sales team, enables you to respond to market demands faster, and helps skyrocket your revenue!

CPQ Without Salesforce DevOps Tools

In contrast, without Salesforce DevOps tools that automate many stages of the change management process, you have to do everything manually. That involves hours of tedious, manual labor and unnecessary busy work. It also results in elevated risk due to the increased chance of bugs and issues that can cause downtime. This in turn can cause revenue loss.

Salesforce DevOps Tools Help Maximize CPQ ROI

Clearly, using DevOps tools for CPQ is a good way to maximize your ROI. You have the safety net of source control, the accuracy of deployment automation templates, and automatic SOX compliance. This greatly reduces the risk to the business.

At the same time, you empower your sales team, and you make your business more agile and responsive. As a result, it’s easier and faster to drive up revenue with your investment.


What is Salesforce sandbox seeding?

Salesforce sandbox seeding or data seeding consists of two parts: data replication to obtain test data and data migration. When you create a new environment or refresh an existing one, you can use sandbox seeding to move data replicated from production into the sandbox. This effectively makes your dev environments look like mini versions of production. Learn more about sandbox seeding.


Why do I need source control for Salesforce CPQ? 

Source control for CPQ offers several advantages. You can easily roll the configuration back to earlier states if needed. It provides an automatic audit log. In addition, it lets you collaborate more effectively. Learn more about the benefits of version control for Salesforce CPQ.

A vector illustration with white ones and zeros and the word "rollback" in red signifying a rollback strategy in Salesforce

Salesforce Rollback Strategy: A Primer

A robust rollback strategy in Salesforce safeguards your change management process against bugs and errors in releases. In this blog, we discuss exactly what a rollback plan is, when you should use one, and how to implement it.

What Is a Rollback Strategy in Salesforce?

A vector illustration with white ones and zeros and the word "rollback" in red signifying a rollback strategy in Salesforce

A high-level definition of a Salesforce roll back strategy is a set of procedures you put in place to revert changes to your production environment. These procedures restore your Salesforce org to the stable state it was in before your previous deployment.

What Is the Purpose of Rollback?

The purpose of rollback is to minimize the impact of any bugs or issues that arise after deploying new changes to production. Because it acts as a kind of safety net, developers often call it the “oops button.”

Why Is a Rollback Strategy Important?

When you include a rollback strategy in your deployment process as a matter of course, you ensure you can quickly and easily deal with any issues without your end users being affected.

What Should Be in a Rollback Plan?

Your rollback strategy should encompass a carefully constructed, written, and tested plan that outlines all the steps you need to perform to revert production to a stable state. It should also define the part each team member plays in the process. In addition, it should include the checks you have to run and how to respond in the event of a failure situation.

When Should Rollback Be Used?

Use a roll back to restore stability to production when serious issues occur during a deployment, such as bugs or errors you can’t resolve in a short amount of time. 

You should also use one when new changes are causing complications that have a negative impact on your Salesforce instance’s performance. By performing a rollback to restore your production org to the state it was in before the changes, you can restore stability for your end users. They can go about their daily business, while you can work on a fix for the issue in an isolated environment.

How Do You Perform a Rollback Operation in Salesforce?

Now you know what a rollback plan is and when you need one, you’re probably wondering, “How do I rollback changes in Salesforce?” 

You can roll back changes using Salesforce tools, but this is quite complicated, as you can see from the steps below. You can also use Prodly to quickly and easily rollback a deployment.

How to Rollback a Deployment in Salesforce

To rollback a deployment in Salesforce, perform the following steps.

Stop the Deployment

If any issues arise during the deployment of a change, stop it immediately to prevent further damage to your Salesforce instance.

Inform Stakeholders About the Rollback

Communicate to everyone on your team, as well as all users and other stakeholders, that you’ve decided to perform a rollback and why.

Define the Scope of the Rollback

Determine which components have been affected by the deployment and need to be rolled back. Use this analysis to plan the steps you need to take to restore your production org to its previous state.

How to Rollback a Metadata Deployment

First, we’re going to look at how to rollback metadata changes. Let’s say you have three versions of a Flow, and the most recent version, version 3, is causing problems. You can deactivate version 3, reactivate the previous version (version 2), and deploy version 3 to a sandbox so you can fix it. You’ll have to perform a similar step for each metadata component that’s affected.

An image of deactivating a Flow in Salesforce to illustrate a rollback of metadata in Salesforce
How to Rollback a Config Data Deployment

Performing a rollback of config data (for example, if you’ve made changes to Salesforce CPQ) is more complex. First, check that you made a backup before you deployed the record updates. Then use Data Loader to revert the updates with that backup. If you inserted new records, identify them using a query or a Salesforce report, and delete them from production.

Check and Test

After you’ve restored your production org to the stable version, ensure that it’s fully functional. This might involve reconfiguring settings, reimporting data, or updating configurations.

Test thoroughly to make sure all components are working as expected and that there are no unexpected problems.

Communicate With Stakeholders

Inform your team, as well as all users and other stakeholders, that the rollback has been successful. You should also make them aware of any changes to production that will impact their workflows.

Roll Back a Salesforce Deployment in 5 Steps With Prodly DevOps

Prodly DevOps integrates with various version control systems, including GitHub. Because of this, it lets you easily perform a rollback in five simple steps:

  1. Navigate to the appropriate repository in GitHub and select the branch you deployed the changes from.
  2. Click on “Commit History” and select the pull request you want to roll back in the commits list.
  3. Click “Revert” at the bottom of the pull request and select the revert branch GitHub creates.
  4. Merge the new pull request GitHub creates into the branch you originally deployed the changes from.
  5. Deploy the restored changes from your branch to your Salesforce org.

Then all you have to do is log into Salesforce and confirm that your changes are successfully rolled back.


To ensure the continuity of your Salesforce instance, it’s critical to have a well-defined rollback strategy. By consistently making sure you have one for every significant deployment, you can minimize the impact of issues on your production environment and maintain the trust of your users.


What’s the difference between a rollback and a roll forward deployment?

When you perform a rollback, you revert your production environment to a previous state of stability—but then it doesn’t have the new features. With a roll forward deployment, you add additional changes that fix the issue while at the same time keeping the new features live. 

How often should I make a rollback strategy?

It’s advisable to have a tested rollback strategy in place for every significant deployment you make.

Diverse Salesforce team learning how to do CI/CD without version control

How to Do CI/CD Without Version Control

You Don’t Always Need Git for Salesforce DevOps!

If you aren’t yet ready for source-driven development in Salesforce, it’s possible to do continuous integration and continuous delivery, or CI/CD, without version control. We’ll discuss how to do this and why you might want to. We’ll also explain that you can also find your own balance between no automation and source-driven development.

How to Do CI/CD Without a VCS in Salesforce

Diverse Salesforce team learning how to do CI/CD without version control

Although many developer-centric Salesforce teams are accustomed to using a version control system (VCS) for CI/CD, it’s not an absolute must-have. You can still achieve the benefits of CI/CD in Salesforce without Git.

Continuous Integration With Sandbox Management

To establish continuous integration in Salesforce without version control, start with a best-in-class sandbox management strategy to keep your orgs clean. Then, during the development process, you continually sync configuration changes that have passed integration testing into your developer environments. You do this by pinpointing the changes within the configurations in your integration environment and pushing them back to your Developer sandboxes and scratch orgs. 

This ensures your lower-level dev environments are always up to date, which in turn minimizes the chances of bugs and release delays. 

With a solution like Prodly Sandbox Management, you can easily manage data and metadata across every environment in your release path without using a Git repository. This is especially helpful for admins and other low-code/no-code users.

Continuous Delivery With Automated Deployments

Now you have up-to-date developer orgs, it’s time to automate deployments to ensure continuous delivery. The benefits of automating deployments include speed, accuracy, a reduced workload, and a whole lot less frustration.  

Using Prodly DevOps, you can bypass data loaders and change sets, and instead, deploy your changes automatically. Prodly DevOps provides easy diff-viewing and pre-built automations for a large number of Salesforce apps, including Salesforce CPQ, Conga Composer, FinancialForce, and more. 

What’s more: You can even schedule deployments so they occur after hours, when they won’t disrupt your business users.

Why Do CI/CD Without Source Control?

One reason to do CI/CD without Git in Salesforce DevOps is that a source-driven development process takes time and effort to set up. You’ll also have to organize training and enablement on a completely new process for your team. Additionally, you have to use the exact same release path every time, which can compromise your agility, especially when it comes to small fixes.

The initial overhead of implementing source-driven development combined with the loss of flexibility often outweighs the benefits gained. Because of this, smaller teams rarely find the upfront investment of setting up a version control system for Salesforce DevOps worth the return.

Find the Right Balance Between No Automation and Source-Driven Development

When it comes to deciding between no automation for release management and source-driven development, it’s important to realize that the Goldilocks principle applies. This means that there’s no predetermined “right” or “wrong” balance between the two. What works for your Salesforce instance might be completely different from what works for another company. 

For example, let’s say you can achieve 90 percent of the efficiency gains of CI/CD with automated deployments. If you add version control, it might give you the other 10 percent—but it would likely require an inordinate amount of effort to set it up. In other words, it’s important to weigh the pros and cons of using a VCS and decide on a course of action that will yield the greatest ROI for your specific company.

CI/CD With Prodly DevOps

Although source-driven development offers additional automation for Salesforce DevOps, you can achieve comparable results using Prodly DevOps.

Interested in learning more? Request a demo today!


What is a VCS?

A version control system or VCS is a tool that makes tracking and managing changes to code and configuration easier. By using a VCS, you can ensure you’re always working on the latest version of the configuration. Learn more about version control for Salesforce. 


What are the most popular version control systems for Salesforce DevOps?

The most popular version control systems for Salesforce DevOps include GitHub, Bitbucket, Azure, and GitLab.


What is continuous integration for Salesforce?

Continuous integration for Salesforce is the practice of keeping Salesforce development environments in sync with production. It also involves syncing in-flight development work to identify and fix integration issues as early as possible in the development cycle. 

In a best-in-class Salesforce development process, changes to data and metadata are continuously integrated across parallel development paths. This way, everyone’s working against the most current configuration of Salesforce.


What is continuous delivery for Salesforce?

Continuous delivery for Salesforce is the practice of automating the delivery of changes to end users in production. A best-in-class Salesforce development process involves making and testing changes in a development environment, i.e. a Developer sandbox or scratch org.

After you’ve approved the changes, you use automation to deploy them through a release path of increasingly production-like orgs. These can include integration, UAT, and staging phases. The ultimate goal is to deliver thoroughly tested work to end-users. 

By using automation, continuous delivery for Salesforce accelerates the release cycle and reduces the risk of deployment errors.

An photo of a train in scenic surroundings as a metaphor for the automated Kaptio deployments of Prodly DevOps

How to Run a Kaptio Deployment

In this blog, we teach you how to run a Kaptio deployment using Prodly’s automation templates or data sets. This process is much more accurate than manually deploying config data with a Salesforce data loader. Automation takes 80 percent less time, which boosts your productivity significantly!

Automate Kaptio Deployments

Prodly DevOps provides automated deployment templates for the entire Kaptio data model. That means you can now perform accurate and successful Kaptio deployments in minutes instead of days! 

Here’s how to run a Kaptio deployment in three steps with Prodly DevOps:

  1. Select the source and destination environments.
  2. Select the template you want to use to deploy your Kaptio object, i.e. Business Unit, Package, Agreement, Itinerary Data, etc.
  3. Deploy.

Check out how quick and easy it is in this video:


What is Kaptio?

Kaptio Travel Platform is an end-to-end enterprise travel CRM built on the Salesforce platform. It allows travel providers to handle reservations, contracts, operations, and their distribution management system all from a single pane of glass.

Why are Kaptio deployments with Data Loader so difficult?

Kaptio deployments are so difficult because the Kaptio data model consists of complex configuration data, like Salesforce CPQ. As such, there are many object relationships that need to be taken into account in every deployment. When you use Data Loader, you have to map all these relationships out manually, one-by-one, to make sure the deployment is successful. This is tedious and time-consuming work that’s prone to error and often results in hours of rework.

A large see-saw with a plus on one side and a minus on the other representing the pros and cons of Salesforce DevOps

Pros and Cons of Salesforce DevOps

It’s critical to understand the pros and cons of Salesforce DevOps before implementing it in your organization. In this blog, we’ll take a closer look at the development philosophy’s advantages, including improved collaboration and creativity, faster delivery of changes, reduced risk, and increased ROI.

We’ll also examine the disadvantages, such as the time and cost investment, added complexity, and potential disruptions and delays during the transition.

Advantages of Salesforce DevOps

A large see-saw with a plus on one side and a minus on the other representing the pros and cons of Salesforce DevOps

There’s one overarching benefit of Salesforce DevOps. It enables you to deliver higher-quality changes and applications much faster than you could using traditional release methods like change sets and Data Loader. Let’s take a closer look at these key advantages.

Improved Collaboration and Creativity

Implementing Salesforce DevOps eliminates silos and improves collaboration between development and operations teams. Salesforce admins, developers and business operation teams must work together to deliver process optimization for the business. This improved collaboration between the teams can lead to greater creativity and innovation.

Faster Delivery of Changes

Salesforce DevOps involves delivering incremental changes on a continuous basis. You can get updates and new apps to your sales team much faster than with traditional models. This in turn empowers them to do their job better.

Reduced Risk

Salesforce DevOps reduces risk because it allows you to be agile and respond immediately to the demands of the market. In the worst-case scenario, with conventional big bang releases, an app can be obsolete by the time it’s market ready. With Salesforce DevOps, you can prioritize bug fixes and change direction without too much disruption because you deliver work iteratively.

Increased ROI

Arguably the most important benefit of Salesforce DevOps is that it delivers an increased ROI. Automation—a key aspect of Salesforce DevOps—and risk reduction contribute significantly to keeping costs low and maximizing returns.

Disadvantages of Salesforce DevOps

While these advantages are significant, there are potential drawbacks, as well.

Time and Cost Investment

Implementing DevOps in Salesforce may require a certain financial investment if you need to purchase new automation tools and work management apps. At the same time, moving from a traditional development model to DevOps doesn’t happen overnight. You’ll need to dedicate time and resources to getting the framework and processes set up—all while ensuring business continuity.

Added Complexity

To make DevOps work in Salesforce, your teams need to communicate, collaborate, and adopt new processes and tools. Depending on the flexibility of your team, this can be easy or challenging. In some cases, already established processes are so ingrained that they’re almost impossible to overcome.

Potential Disruptions and Delays During the Transition

Salesforce DevOps involves a different way of working. No matter how enthusiastic the team is, this can potentially have an impact on change management during the transition period. It’s advisable to delay any major updates or deliveries until everyone is comfortable with the new development philosophy.

Measure the Potential of Salesforce DevOps for Your Business

Salesforce DevOps can provide efficiency gains and deliver a significant ROI for your business. However, there are many ways to implement DevOps best practices within Salesforce, and you don’t have to implement every best practice to start seeing results. 

When you’ve decided on one or more best practices to implement, conduct a proof of concept trial on a smaller project, and use metrics to evaluate the results. This will allow you to make a data-driven decision as to whether Salesforce DevOps is right for your business or not.


What are the four most important DevOps principles?

To implement DevOps, you need to incorporate the following four principles into your development process: automation, iteration, continuous monitoring and improvement, and collaboration. Learn more about DevOps principles.

How can Salesforce DevOps help my organization be more innovative?

Implementing DevOps principles in Salesforce involves fostering communication and collaboration between development and operations teams. The resulting combination of different points of view can lead to heightened creativity that you can then harness for innovation.

This post is republished with permission from Salesforce DevOps HQ.

A female employee speaking to her CFO about Salesforce automation.

How to Talk to Your CFO About Salesforce Automation

In this blog, I outline a strategy for talking to your CFO about investing in Salesforce automation. This involves researching what your CEO’s objectives are and suggesting a solution that’s proven to deliver the desired ROI.

Research Your CEO’s Goals

A female employee speaking to her CFO about Salesforce automation.

Before suggesting a new Salesforce automation to your CFO, you need to have a good overview of the factors they’ll consider before investing in one. 

The role of the CFO involves supporting the objectives of the CEO. They do this by driving top-line growth and shrinking bottom-line expenses. At the same time, they have to protect your company by ensuring it adheres to all the compliance regulations of your industry. 

So if you can attach the automation solution you’re interested in to one of the CEO’s goals, it will likely be accomplished.

How to Find Out What the CEO’s Goals Are

So how can you find out what the CEO’s objectives are?

It’s much easier than you might think. If your company is public, you can research the most recent quarterly earnings statement or earnings transcript and pinpoint what challenges the CEO wants to address. 

If your company isn’t public, research documents such as an OKR, V2MOM, or other company-wide goal-setting framework. Check the company’s press releases or internal newsletters, and pay attention during all-hands meetings.

Attach a Salesforce Automation Solution to a CEO Objective

Here’s an example of attaching a Salesforce automation tool to your CEO’s main objective.

Despite challenging market conditions including market volatility, fluctuating exchange rates, and skyrocketing inflation, your CEO’s main goal remains to increase profit. So whatever automation your CFO invests in has to move the needle towards that objective.

One way your CFO can support the CEO’s goal is to ensure you’re making the necessary price adjustments internally. You need to get the right price points to the sales team so the company doesn’t lose revenue. This has to be accomplished with as few resources as possible while adhering to all applicable compliance regulations.

For example, let’s say your company has business operations across the globe. In Salesforce CPQ, it can take between six and 12 weeks to manually make price adjustments resulting from fluctuating exchange rates. In other words, it would take that long before your sales team can sell at the accurate price point. And that equates to a substantial amount of lost revenue. 

Prodly DevOps for Salesforce CPQ provides automation that lets you accomplish the same volume of price adjustments in two to three days—instead of two to three months. You need fewer people for the project, so you can reallocate team members to other high-priority projects. What’s more: Prodly DevOps automatically creates an audit trail—so you don’t have to worry about being in compliance. 

In short, recommending the cost benefits of Prodly DevOps for moving your Salesforce CPQ changes to your CFO would be a strategic move.

Prove Your Solution Will Deliver the Desired ROI

Of course, your CFO will require proof that any automation they invest in will deliver the desired ROI. So how can you get that?

Many software vendors provide metrics to show how their automation positively impacts their customers’ top or bottom line. You can typically find this type of information in case studies and white papers on their website. If you can’t find the information, ask for it when you get a demo. 

Sometimes, Salesforce features interesting customer stories that illustrate how a specific AppExchange app helped a customer solve a business challenge and what the outcome was.

Prepare a Business Case for Salesforce Automation

Best-in-class software vendors partner with you to make a compelling business case that shows how your profitability can grow as a result of the application.

Business Value Calculator

At Prodly, we use a business value calculator to show our customers how the benefits of Prodly DevOps translate into financial impact for their specific company. 

Our business value calculator considers the cost of investing in our solution and balances it against five quantifiable outcomes:

  1. Deployment maturity: The percentage of efficiency teams obtain by using Prodly
  2. Risk savings: How much revenue could be lost due to downtime without using Prodly
  3. Agility: The percentage of increase in development capacity gained by using Prodly
  4. Pricing change increased revenue: How much revenue is lost while waiting on price changes without using Prodly
  5. Compliance: How much productivity could be consumed preparing for and undergoing external audits without Prodly

Equipped with the numbers of how much your business can profit from investing in a Salesforce automation like Prodly, you can confidently approach your CFO.

Keep It Short and to the Point

As you can see, talking to your CFO about Salesforce automation doesn’t have to be intimidating. Just do your research ahead of time to verify the automation aligns with the CEO’s goals and delivers the desired ROI. 

Pitch your proposal succinctly. Ask for five minutes of the CFO’s time, and give them the most impactful metrics. Then be prepared to follow up with more information if they’re interested.

Follow Up With Metrics to Show ROI

Let’s say the CFO decides to invest in the Salesforce automation you recommended. Then it’s best practice  to demonstrate the ROI after three to six months. This not only proves the business case—it also builds trust with your CFO for your next initiative. 

At Prodly, our Customer Success team is happy to help you determine the financial impact of our products. Then you can take the numbers to your CFO to validate your actions—which in turn can help advance your career. 

Do you want to find out how Prodly DevOps can boost your profits? Schedule a demo, and we’ll show you the business value calculation for your specific company!


Why do I need Salesforce automation?

You need automation in Salesforce so you can implement DevOps best practices. These will enable you to deliver more high-quality changes faster than you could manually.

How do I quickly run a Salesforce CPQ deployment?

Prodly offers automation templates that are built for the entire Salesforce CPQ schema. Using them, you can run deployments in 80 percent less time than using Data loader.

The enter key on a computer keyboard with the word oops on it representing version control for Salesforce CPQ configuration.

Benefits of Version Control for Salesforce CPQ

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.

The enter key on a computer keyboard with the word oops on it representing version control for Salesforce CPQ configuration.

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:

  1. They must maintain a complete audit trail of changes to all financial data, including pricing and products.
  2. 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. 

An illustration depicting the different stages in the DevOps lifecycle for Salesforce admins.

DevOps: What Salesforce Admins Need to Know

DevOps is rapidly gaining traction as a way to better manage releases and drive faster innovation in Salesforce. In this blog, we examine how the Salesforce admin can leverage DevOps to better support their team, as well as improve how they manage risk. 

How DevOps Helps You Better Support Your Team

When properly implemented, DevOps is not just a category of interest for developers. It’s rapidly becoming a method that empowers Salesforce admins and other “clicks, not code” developers to effectively manage change in their Salesforce instances. Watch this video to learn more about how it can help you better support your team.

Salesforce Governance Strategy

To implement DevOps, start by defining a Salesforce governance strategy regarding how everyone on your team participates in the flow of change. When you define a strategy for making changes using Salesforce DevOps tools, you can dramatically increase who gets to participate in the ideation process of change management.

For many teams, the process of adoption of these new methodologies causes some anxiety. But without a tool supporting your change management processes, over time, you’re likely to develop a risk-averse, siloed attitude towards Salesforce release management. DevOps aims to break down silos and encourage more people to participate in the management of Salesforce.

Salesforce DevOps Encourages Innovation

DevOps is centered around helping you build and adopt a culture, mentality, and processes that encourage innovation. Because you’re in the driver’s seat, you’re able to introduce ideas that help you sustain your workflows more effectively.

Plus, every member of your team can ideate within a trusted process with the appropriate safeguards. This results in a more robust flow of solutions and opportunities for consistent growth and collaboration.

You’re also able to test those solutions without worrying it will drain your team’s time and resources. As a result, you’ll see a positive impact on your team’s bottom line!

Salesforce Admins Can Better Manage Risk

DevOps has the power to transform your company’s perspective on risk aversion. It makes risk aversion a priority starting in the strategy development phase.

When everyone on the team is engaged in spotting and managing risks, the chances of bottlenecks are significantly reduced. Moreover, the changes that are promoted to production are more thoroughly tested. 

Prodly for Salesforce Admins

Prodly DevOps was designed with the understanding that not just developers, but also Salesforce admins want to accelerate the pace of innovation without sacrificing trust. It enables Salesforce teams to:

  • Foster greater collaboration
  • Create more opportunities for inclusion
  • Develop goals that focus on empowerment
  • Maximize overall growth
  • Clear backlogged projects faster
  • Change your risk stance from risk averse to willing to experiment

To learn more about how Prodly can support you as an admin and help accelerate your change management, contact us.


Can Salesforce admins apply DevOps—or is it just for low-code developers?

Yes, Salesforce admins and other low-code/no-code programmers can apply DevOps processes and leverage DevOps automation tools to optimize their change management process. Learn more about why implementing Salesforce is a good idea for admins. 

Why is it important to implement DevOps in Salesforce?

To remain competitive, companies have to innovate how they market and sell things at a rapid pace. DevOps allows businesses to implement streamlined, transparent processes and automate repetitive, error-prone tasks. As a result, businesses can accelerate their change management process, be more innovative, and improve the top line. Learn more about innovation for sales.

A computer keyboard with a blue return key that says "One Click."

How to Create a Scratch Org With One Click

Using Prodly, you can quickly and easily create a scratch org with one click, as you can see in the video below.

How to Create a Scratch Org With Clicks, Not Code

To do this yourself, follow these steps:

  1. In Prodly, navigate to the AppOps Release tab and select “Create Scratch.”
  2. Add a name, username, source, and duration.
  3. (Optional) To add a package, activate the “Installed Packages” toggle and select the packages you want to install.
  4. (Optional) To add metadata, activate the “Metadata” toggle and select a comparison view.
  5. (Optional) To add data, activate the “Data” toggle, and select a data set or deployment plan.
  6. Click “Create Scratch Org.”

There you have it! Your scratch org is now created, along with all the metadata, data, and complex relational record data you need. All you have to do is log in and get to work!


What is a scratch org?

A scratch org is a temporary environment in Salesforce that you can use to complete small tasks for projects you’re running on an agile methodology. Learn more about scratch orgs.

Why do I need a scratch org?

A scratch org makes your development and release management process faster and more agile. All you have to do is seed it with only the packages, data, and metadata you care about. Then you can use it for up to 30 days, complete and promote your work, and move on. Read more about when to use a scratch org. 

Can I use scratch orgs with Salesforce DevOps Center?

Yes, you can. In fact, with the release of DevOps Center, Salesforce makes it easier for you to use them and adhere to DevOps best practices. Get our FREE Ultimate Guide to Salesforce DevOps Center to learn more!