The widely-accepted bottleneck between business teams and Salesforce DevOps

Adding new products into Salesforce should be simple. But for many organisations, it remains a slow, manual, multi-team process that can take days or even weeks. What should be a straightforward update instead becomes a long chain of handoffs between business teams, product managers, and Salesforce DevOps teams.

While this can look like inefficiency from the outside, there are real reasons it exists, rooted in governance, risk control, and data integrity. Changes to Salesforce and CPQ data are often treated as high-risk because they can directly impact pricing, quoting, contracts, and ultimately revenue. As a result, companies introduce multiple layers of oversight to maintain compliance and protect critical business systems.

Over time processes like this become normalized. When something is critical enough, inefficiency is often accepted as the cost of safety, and organizations compensate by adding more people and coordination layers rather than rethinking the workflow itself.

When we looked more closely at this space, it became clear that this problem extends far beyond just adding products. Any updates to configuration data in Salesforce CPQ or Agentforce Revenue Management can be time-consuming and complex. Even seemingly simple changes like updates to price books often require significant coordination across teams.

But the biggest source of friction isn’t technical complexity. It comes from disconnected workflows across business, product, and engineering teams.

The current workflow (what actually happens)

In most orgs we’ve looked at, the flow looks something like this:

1. Business users submit a form with details of new products they want added

2. A product manager reviews the request and translates it into a work item

3. Requirements are often written manually or clarified over back-and-forth messages

4. Data is exported into spreadsheets for structuring and review

5. Dev teams interpret the spreadsheet and implement changes in a sandbox

6. Changes are tested, reviewed, and eventually pushed into production

On paper, this looks structured, and it is, but in practice, it’s slow, repetitive, and full of translation steps.

Where the friction actually is

The biggest delays don’t come from building in Salesforce. They come from:

• translating business intent into structured requirements

• cleaning and interpreting spreadsheet data

• clarifying missing or ambiguous fields after the fact

• reformatting data to fit CPQ or Salesforce constraints

• waiting on back-and-forth approvals across teams

• rework when assumptions don’t match reality

Each step introduces delay and potential misalignment.

Why spreadsheets aren’t ideal in CPQ workflows

Spreadsheets feel like a simple bridge between business and engineering, but in CPQ-heavy workflows they can create real problems:

• No enforced structure at the point of entry means inconsistent formatting and missing fields

• Multiple copies can be circulating across teams

• Manual mapping to system objects means there’s a high risk of errors during deployment

• No validation rules can lead to incorrect pricing, product relationships, or dependencies slipping through

• It’s unclear what changed, when, and why

• Not connected to the live system state means data becomes outdated quickly

• For developers, interpreting intent from raw tables rather than structured input isn’t straightforward

The real cost is time

What sounds like a simple product update often becomes multiple handoffs across teams, repeated clarification cycles, manual data cleanup and re-implementation in sandbox environments — stretching a change request across days or weeks.

Even small changes can take far longer than expected because the system is optimized for governance, not flow.

What solutions are available today?

There are already a number of tools aimed at improving Salesforce change management and DevOps, as well as Salesforce’s own DevOps Center and change set functionality. These tools are largely focused on making deployments safer and more structured, helping teams move changes from sandbox to production, maintain audit trails, and manage approvals.

Alongside these, general work management systems like Jira or Azure DevOps are often used to track requests and coordinate work across teams.

However, while these solutions improve the release and deployment side of the process, they don’t address the earlier and more fundamental challenge: how business intent gets translated into structured, implementation-ready work.

As a result, teams still rely heavily on forms, spreadsheets, and manual interpretation between business users and Salesforce engineers, which creates delays, rework, and a significant hidden coordination burden.

What we’re exploring

We’re currently exploring ways to reduce this friction by improving how configuration data and other change requests move between business users and Salesforce DevOps teams.

Our goals are simple:

• reduce translation overhead

• remove spreadsheet-driven bottlenecks

• and make product updates flow more directly from intent to implementation

We’re validating this with teams currently dealing with this workflow.

We’re looking to speak with teams who:

• manage product data in Salesforce CPQ or Agentforce Revenue Management (ARM)

• rely on spreadsheets to coordinate changes

• experience delays between business requests and implementation

• feel that “this should be faster than it is”

If that’s you, we’d love to understand how your process works today. Contact us to get a first look at our solution to this problem.