Let’s Put an End to Salesforce Change Paralysis – InApps Technology 2025

In their current iterations, business applications like Salesforce or NetSuite are fragile systems.

Part of the reason is that they are, by and large, built by product designers with go-to-market concerns. They want to make the interface as simple as possible to acquire more users. As my co-founder Gil Hoffer has explored, that’s been great — now everybody is actually using them. But all that interface simplicity has come at the cost of manageability.

Virtually all business applications lack the enterprise risk-mitigation features you’d expect from systems that can accidentally overwrite customer records, trigger invoices, email prospects and cause major revenue-interrupting events. That risk plus somewhat limiting no-code controls means administrative teams have to move very slowly because nobody knows what might break.

I’ve seen firsthand how that can paralyze a revenue operation. Requests get backed up and, in sum, it makes the organization far less competitive.

As I’ll explore, there are a few specific reasons this happens — and a few specific fixes. It all begins with thinking about all your business applications as one unified “product” — not as standalone systems — and being able to analyze impact across all. Throughout, I’ll use Salesforce as an excellent example of a well-built business application that nevertheless can benefit from this approach.

Salesforce — Important and Fragile

Let’s talk about Salesforce. Changes in Salesforce are naturally destructive. That is, if someone updates a field or alters a workflow and that deletes data or metadata, there’s no simple “undo” button, much less a selective “undo” button. These systems are largely built for users to work quickly, not administrators to work carefully.

Or consider the task of rolling back a larger update. Your team can use a backup system — and go through the painful process of recovering to a version from a well-known time — but this is complex, and it’s all or nothing. You can’t roll back just some of the changes. Thus, it’s far from streamlined. And even if you do successfully revert, you still have to puzzle out what was wrong about the change. There’s a reason software developers have different tools for holding source repositories and backing up/reverting.

All of this leaves business application teams hesitant to make changes unless absolutely necessary, hence the paralysis.

Recently, business application vendors have tried to address these shortcomings by launching enhanced developer modes. Third-party “DevOps for BizOps” tools have also arisen to address some of these needs. DevOps is certainly the right direction, and these tools help. But they don’t alleviate paralysis.

That’s because each of these dev modes or tools are application-specific, whereas the average enterprise has 800+ business applications, many of which have read-write permissions to Salesforce. If you want to “DevOps your BizOps” and strengthen your Salesforce configuration management, you have to address that entire go-to-market application cluster.

Otherwise, you still can’t know whether a change in Salesforce will break something somewhere else. Could it irreversibly overwrite customer records in the ERP and disrupt those billing cycles? Could it invalidate a “throttling” rule in the marketing automation system and email customers? Could it alter a picklist that causes all leads to go misrouted for months? And what about all those applications that can read and write metadata in Salesforce?

That’s why to end Salesforce change paralysis, you can’t just address Salesforce — you have to address the ecosystem. Hence the need for cross-application DevOps.

Cross-Application DevOps Requires a Universal Configuration Language

Today, every business application is a schematic island. You can’t copy patterns or processes across them, which creates silos and prevents you from practicing true DevOps. A pattern for one Salesforce environment stays in that one environment. That’s why systems administrators need a universal language for business applications.

If we had a universal language, business systems like Salesforce and NetSuite would be mutually intelligible. We could have an application-agnostic view that allows us to scan both, compare environments, track changes, and truly foresee impact.

With an application-agnostic view, you could draw configurations and metadata from multiple business applications into one place. There, you could version, collaborate on changes, debug, document, test, push changes into production — aka true DevOps — and make Salesforce less fragile.

Now, it’s difficult to understand any one software application vendor building this solution. It’ll have to come from a third party. And it’ll have to build upon or replace existing configuration schemes like XML, which for all its faults is a start in the right direction. Because only when the entire business applications cluster uses the same syntax can we finally alleviate Salesforce impact analysis paralysis.

Making Salesforce (and Others) Less Fragile

Far too many Salesforce administrators today are hesitant to make changes. They can have a dozen years of experience and still not know what impact a change will have because the tools to tell them don’t natively exist in Salesforce. These systems are somewhat fragile, in that way.

But the answer isn’t just applying DevOps — it’s applying it across your entire business applications stack. I believe that requires a universal business applications language. I’d love to hear your thoughts.

Feature image via Pixabay.