Claudeforce: what's new, what isn't, and what it doesn't answer

Elisa Mustonen · 10 September 2026 · 9 min read

Claudeforce has been all over the social media feeds recently. Usually as some version of the same question: what is it, and does it change what we're building?

Short answer: the new Claude plugin is real, but much of the wider Claudeforce story was already in motion. The more important shift is Salesforce making its data, business logic and actions available to AI interfaces through a governed platform layer.

The more durable distinction is between giving AI access to enterprise actions and controlling how operational work is handled once those actions are available. Claudeforce improves access to governed actions. The harder question is how those actions become a controlled operational process. Access belongs at the system boundary, where permissions and governed actions are exposed. Execution belongs in the operational layer, where ownership, sequence, approvals, exceptions and SLAs are controlled.

What Salesforce shipped 

Four things, announced on 26 August.

Salesforce in Claude. A plugin with 37 prebuilt sales skills: meeting prep, deal health, pipeline review. It reads and updates live CRM data, and actions route back through Salesforce so permissions and business rules still apply. Select pilot now, open beta expected this month.

Claude inside Salesforce. Claude as a reasoning model in Agentforce, and available in the Salesforce Trust Boundary through Amazon Bedrock for regulated customers.

Claude in Slack. Default model across Slackbot and the rest of Slack.

Mutual adoption. Each company becomes a large customer of the other.

Claudeforce: new, already running, or a new name

Pull those apart and the planning implication becomes clearer: one item is genuinely new, several were already available, and the most important architectural change predates the Claudeforce announcement.

Genuinely new: the plugin. Thirty-seven packaged sales skills running inside Claude's own interface, with governed read and write access to Salesforce. That didn't exist before. It's also sales-first, and Salesforce has said service, marketing and commerce come later.

Already announced. Claude in Agentforce, Claude in the Trust Boundary via Bedrock, and the Slack work. All from October 2025. All live, all real, just not news from August.

Already running, and the part I'd plan around. Headless 360, introduced in April, and hosted MCP servers, GA on 29 April. That's what makes Salesforce data, flows and Apex callable by whichever AI interface a customer picks. Claudeforce is one expression of a direction Salesforce set five months earlier.

And one new name. AIforce brands the agent-facing plumbing: MCP servers, APIs, tooling. The name's new. Most of what sits under it has been shipping since spring.

None of that makes the announcement small. The important shift is that Salesforce is separating the AI interface from the governed capabilities underneath it. Claude is one client of that layer today, but the architecture is designed to support others too.

Why the direction is right

Two parts of the architecture matter in particular.

First, reasoning is getting connected to governed enterprise action, with permissions and business rules enforced on the Salesforce side instead of rebuilt somewhere else. That's the right place to enforce them, because permissions and business rules should stay with the system of record rather than being recreated inside every AI interface that connects to it.

Second: Salesforce's own architect guidance now says if a decision can be expressed as logic, write it as logic, and use a model only where judgment is needed. It goes further and calls using an agent to run a fully specifiable deterministic path an anti-pattern, because every unnecessary model call adds latency, cost and variability.

We've built around that separation for years. The important point is that agents should not replace deterministic automation simply because they can. Use a model where interpretation or judgement is required, and use explicit logic where the business can define the outcome in advance.

What Claudeforce doesn't answer

Connecting Claude to governed Salesforce data and actions solves a meaningful problem: how an external AI interface can act without bypassing Salesforce permissions and business controls.

The announcement answers how Claude gets governed access to Salesforce. It doesn't answer how an enterprise coordinates ownership, SLAs, approvals, fallbacks and cross-system execution once the work starts.

That is where the problem changes from access to operational control. Which specialist should own this case, given who's available and what they're already carrying. What happens when it needs an approval. What happens when the SLA is at risk. What happens when the same request arrives twice, or comes back four days later, or arrives in a language nobody on the team reads. What happens when finishing it means calling a system that isn't Salesforce at all.

A better interface does not decide ownership, capacity, approval policy, escalation timing, fallback behaviour or cross-system recovery. If anything it makes them more visible, because work that used to sit quietly in a queue now sits in front of something that's ready to act on it.

What orchestration looks like on one Salesforce case

Those questions are the decisions Ortoo Orchestrator coordinates. It controls how a case is handled from arrival to resolution, including ownership, sequence, approvals, fallbacks, SLAs and the actions taken across Salesforce and external systems.

Here's one case, from the kind of compliance and service operation we run it in: six-figure record volumes, several languages. Nothing in the case itself is unusual.

An email arrives. It's in German, there's a PDF attached, and it's a billing dispute that was already raised once in July.

A good model handles the reading. It works out this is billing and not support, pulls the account reference out of the attachment, spots that it relates to the earlier case, and drafts a summary for whoever picks it up. Claudeforce makes that kind of reasoning available over governed Salesforce data, which is genuinely useful.

Understanding the case is only the first part. The next decisions are operational.

Which of the four German-speaking billing specialists gets it, given one is at capacity and one is on a late shift. Whether the July case makes this an escalation. Whether the refund crosses the threshold that needs a manager. What happens at hour 6 if nobody's touched it. Where it goes if the specialist declines it. How you show an auditor, 6 months later, why it went where it went.

And the refund itself happens in the billing system, not in Salesforce. Something has to call it, wait for it to answer, write the answer back, and know what to do when it doesn't answer at all.

None of those should be improvised by a model each time. They depend on business rules, workload, availability, ownership history and SLA state, and should be handled predictably, consistently and with a traceable reason for each decision.

How one case is handled, from interpretation to controlled execution.

Ortoo Orchestrator is built around that separation: AI for judgement, deterministic logic for decisions that can be specified, and orchestration to coordinate the full process.

A model handles judgment, where judgment is genuinely required: reading the email, classifying it, pulling the reference out of the attachment. Deterministic logic handles the decisions that can be specified: who owns it, what order the steps run in, what the escalation path is, what happens when a step fails. Ortoo Orchestrator runs that sequence natively in Salesforce, and keeps track of where each case has got to while it runs, whether the work arrives through Claude, through Agentforce, through email or through a form. Each step calls whatever it needs, from a Salesforce action to a Flow, an ISV app or an external API, and every action is traceable.

A note on cost

Understand what's being metered before you design the workflow. If every step is billed per model call, the cost curve doesn't care whether a model was the right tool for that step. If it's priced per work item completed, the architecture question and the cost question point the same way, because rules-based steps don't need a model at all.

Right now Claudeforce needs two commercial relationships: Anthropic for Claude inference, Salesforce for headless consumption. Salesforce has been open about that, and it's normal at pilot stage. Packaging usually simplifies as products mature, so treat that detail as current rather than permanent.

The commercial packaging may change. The architectural question will not: whether you pay for model activity or completed work can materially influence how you design the process.

Questions worth asking

Useful whoever you're evaluating. Us included.

• Which of my workflows does this handle today, rather than on a roadmap?

• Once an agent can act, what decides who owns the work, and in what order it's handled?

• What happens when a step fails, an approval is needed, or an SLA is at risk?

• Can the person who owns the process change the logic, or does every change need an architect?

• Can I forecast what a workflow costs to run before it goes into production?

What happens next

Dreamforce runs 15 to 17 September and Salesforce has invited customers to see Claudeforce there. I'd expect more on governance, the experience layer and packaging. I'll write again once it lands.

Salesforce is making two useful architectural choices explicit: keep enterprise actions governed at the Salesforce layer, and use AI only where judgement adds value. Agentic interfaces and governed enterprise data belong together, and AI belongs where interpretation helps rather than everywhere.

What remains is the execution question: once an agent can act, who controls ownership, sequence, approvals, exceptions and the path to completion?

Salesforce is making more capabilities callable. Orchestration is what coordinates those capabilities, rules, people and systems into one controlled process.

Sources

• Salesforce and Anthropic Announce Claudeforce · Salesforce Newsroom, 26 August 2026. The 37 skills, the four components, the pilot and open beta status.

• Claudeforce product page · Salesforce. Sales listed as the first use case, with service, marketing and commerce marked as coming.

• Salesforce just put its entire CRM inside Claude · VentureBeat, 26 August 2026. Where the two-contract detail comes from, including Patrick Stokes saying you can't buy it on one piece of paper yet.

• Anthropic and Salesforce Expand Strategic Partnership to Deliver Trusted AI for Regulated Industries · Salesforce Newsroom, 14 October 2025. Claude in Agentforce, and in the Trust Boundary via Bedrock, announced ten months before Claudeforce.

• Salesforce Headless 360 and Agentforce Vibes 2.0 Revealed at TDX 2026 · Salesforce Ben, 15 April 2026. The April launch date, which a lot of coverage gets wrong.

• Salesforce Hosted MCP Servers Are Now Generally Available · Salesforce Developers Blog, 29 April 2026. Your org's data, flows and Apex actions exposed to any AI client that speaks MCP.

• Expanding Headless 360: Enterprise Capabilities · Salesforce Newsroom, 19 August 2026. The expansion a week before Claudeforce, not the launch.

• Determining Agentic and Traditional Workflow Automation · Salesforce Architects. Worth reading in full if you read only one of these. It says to use traditional automation "for rule-based deterministic work, where the outcome can be entirely scoped and defined by a set of rules", and calls using an agentic solution to run a deterministic path "an anti-pattern" that leads to agent sprawl and agent slop.

Sources last checked 11 September 2026.