Salesforce Headless 360 doesn't fix broken workflows, it exposes them.

Elisa Mustonen · 15 July 2026 · 7 min read

Salesforce Headless 360 makes everything on the platform callable, so agents and external systems can trigger work without a UI. That's a real shift in how work starts. It doesn't change how work is controlled once it starts. The hard part was never calling something; it's what happens after the call, across steps, systems, and edge cases. Headless 360 exposes that gap. Orchestration is what closes it.

Salesforce just made a bold claim. Everything on the platform — data, workflows, and business logic — is now accessible as an API, an MCP tool, or a command that an agent can invoke. In practical terms, that means agents can operate across your systems without relying on a traditional UI. Work can now be triggered from anywhere — Slack, external systems, or by agents themselves.

From a distance, this looks like a fundamental shift.

There’s a lot of discussion about the emergence of this new agentic infrastructure and the future breakdown of traditional UIs and seat-based licensing.

What’s also clear is that this isn’t just a technical update (like calling things has been in the past), but more of a directional go-to-market push on the customers.

Salesforce is not only exposing these capabilities to technical early adopters, but it’s actively guiding the mass of customers toward an agent-driven, API-first way of operating.

From up close, the movement exposes something much more uncomfortable:

The ability to call anything was never the problem.
The problem is what happens after that call is made.

The real problem with Salesforce workflows isn’t access, it’s execution

Most enterprise Salesforce environments already have what they need to automate work. They have routing rules, flows, integrations, and APIs. Many organizations have spent years refining these layers.

And yet, workflows still break down in practice: cases sit in queues, leads get reassigned, and teams step in manually to keep things moving.

This is not a limitation of access or capability. It is a limitation of execution. There is no single place that defines and controls how work is handled from start to finish, so even well-designed components fail to produce consistent outcomes. 

What actually happens after a case or lead is created

On paper, workflows begin when a case or lead is created.

In reality, they begin earlier , and in a much less controlled way.

Most work enters the system as unstructured input: an email, a form submission, a message, or a request that does not perfectly match the process behind it. Information is often incomplete, ambiguous, or inconsistent.

Before anything can be routed or automated, that input has to be interpreted. Someone, or something, decides what the request actually is, how urgent it is, and which process it belongs to.

This step is rarely standardized and often depends on partial logic or human judgment.

The workflow problem starts before the record even exists.

By the time the work becomes a structured record in Salesforce, key decisions have already been made. If those decisions are wrong or incomplete, everything that follows is affected.

Why routing and automation don’t fix the workflow problems

Most teams focus on improving routing and adding automation. It makes sense, these are the tools available to shape how work moves.

Routing determines who should handle the work next. Automation handles specific steps along the way. Both can be well-designed, well-configured, and continuously improved.

And yet, the same issues persist.

Work gets reassigned. Cases bounce between teams. SLAs are missed. Not because routing is broken, but because it’s answering a narrower question than the one that actually matters.

Routing is not the entire workflow. It’s just one decision step inside it.

Routing decides where work goes. Automation handles parts of the process. But neither defines what should happen from start to finish.

So when something doesn’t behave as expected, teams fix it where they see it. A routing rule is adjusted. A flow is updated. Another condition is added to handle an edge case. Each change makes sense in isolation.

Over time, logic spreads across flows, rules, integrations, and different parts of the system. Changes in one place create unintended effects in another. The system still runs, but it becomes harder to follow, and outcomes become less consistent.

Automation scales both the workflows and the problems in them.

A surface level fix creates more complexity.

What changes with Agentforce and Salesforce Headless 360

Salesforce is clearly moving in a new direction.

With Headless 360 and Agentforce, Salesforce is enabling agents to interact with the platform in a new way. Agents can now invoke actions, trigger workflows, and operate across systems without requiring a user interface.

This represents a meaningful shift in how work can be executed. However, it does not address the underlying issue. Essentially this changes how work and workflows start, but not how they are controlled end to end.

All of the existing layers are still there. Flows, routing rules, integrations, and data dependencies…

Now, agents operate on top of them. If those systems are already hard to understand, inconsistent, or loosely connected, agents don’t simplify that.

Data is another matter. Agents can only act on what they can access. In many environments, that access is still shaped by platform boundaries, API limitations, or design decisions around how data is exposed.

Opening execution doesn’t automatically mean opening context.

Agents also remove the human safety net. Where people previously identified and corrected issues during execution, agents will continue operating based on the likely unreliable system.

What’s actually new, and what isn’t

There is real progress in the current Salesforce direction:

• APIs are more accessible.
• Agents can operate across systems.
• Execution is no longer tied to a UI.

At the same time, the underlying architectural patterns are not new. Salesforce has supported API-first integrations, event-driven workflows, and automation for years. Many complex enterprise environments have long relied on these capabilities.

This is why some of this feels familiar to more technical teams.

What’s new is the addition of standardized layers like MCP, which make it easier for agents to interact with those capabilities in a more structured way.

But fundamentally, the core model hasn’t changed as much as it seems.

What has changed is how these capabilities are packaged and marketed into the mainstream, and where they are invoked from. Salesforce is moving from being a system that users interact with directly to one that agents operate on.

That is a shift in interface and invocation, but not really in workflow execution and control.

Why this makes the execution problem more critical

Until now, people have been compensating for gaps in the system:

• They catch issues.
• They reassign work.
• They correct mistakes.

That safety net is disappearing fast. And nothing is really replacing it, is it?

Agents don’t question assumptions or fix inconsistencies, they execute what’s defined at scale.

If the underlying workflow is fragmented or unclear, that doesn’t get corrected, but executed wrong consistently and way faster than by the human teams.

Calling an API is easy. Getting the outcome right is not.

The industry, and the Salesforce ecosystem, is moving toward a world where everything is callable.

A very important step and something that Ortoo has been enabling for a while… but it does not solve the core problem.

You also need to ensure that the workflow leads to the correct outcome consistently, across systems, inputs, and edge cases.

That is where most Salesforce workflows still fail. And as more of that execution is handed over to agents, the cost of “getting it wrong” only increases.

Faster execution doesn’t fix broken workflows. Outcomes do become more consistent, though, whether they’re right or wrong.

Evaluate where your Salesforce workflows could be more controlled

Frequently asked questions

What is Salesforce Headless 360?

Salesforce Headless 360 is Salesforce's move to make its data, workflows, and business logic callable as APIs, MCP tools, and agent actions, so work can be triggered without the traditional UI, from Slack, external systems, or agents. It changes how work is invoked, not how it is controlled once it runs.

Does Salesforce Headless 360 fix broken workflows?

No. Headless 360 makes existing capability easier to call, but the Flows, routing rules, and integrations underneath are unchanged. If execution was fragmented before, exposing it to agents scales the same inconsistencies faster. What fixes broken workflows is control over how work executes end to end, which is orchestration.

What's the difference between making everything callable and controlling execution?

Making everything callable means any step can be triggered from anywhere. Controlling execution means defining what runs, in what order, under what conditions, and with what governance, so the whole workflow produces the right outcome consistently. Headless 360 delivers the first; orchestration delivers the second.

Is Agentforce enough to run workflows on Headless 360?

Agents can invoke actions and reason across steps, but they don't define or govern the workflow around them. Without a control layer, an agent acts on fragmented logic and produces inconsistent results at scale. Orchestration provides the sequence, conditions, and controls that let agents run operational work reliably.

---