Claudeforce Is the Easy Part. Again.

Salesforce put the CRM in Claude and called the AI the UI. That is Headless 360 doing what Summer '26 already started: collapsing the demo. It does not assign data ownership, approval paths, or what happens when Claude updates the wrong Opportunity.

In June I wrote that Summer '26 made Agentforce easy to deploy and left the workflow design untouched. Two months later, Salesforce has taken the same idea a step further. In May, it cut deployment to six clicks. On Wednesday, it moved the interface into a chat window.

What is Claudeforce?

On August 26, during its Q2 earnings call, Salesforce announced Claudeforce, a partnership with Anthropic. Salesforce shares rose 12% in extended trading. Marc Benioff used the announcement to push back on the "SaaSpocalypse" idea that AI labs will swallow software companies. His argument was simple: frontier models need CRM data; they don't replace the CRM.

The partnership has three parts. Claude becomes a reasoning model inside Agentforce, served through Amazon Bedrock within Salesforce's security boundary. It becomes the default model in Slack. The part I care about here is Salesforce in Claude, a plugin with 37 prebuilt sales skills. Sellers can prepare for meetings, check deal health, review pipeline, update records, and draft emails from account context without opening Salesforce. Pilot customers have access now. An open beta is due in September, with skills for other business functions starting in Q3.

Patrick Stokes, Salesforce's president of applications, described it as "a version of what Claude Code did for developers," built for sellers. The demo showed Claude creating custom dashboards from live Salesforce data. Stokes said users could "vibe code their own CRM."

The connection runs through Headless 360, the initiative Salesforce launched in April to expose its data, workflows, business logic, and actions through APIs and MCP tools. One admin connects the org, and each user's access follows their existing Salesforce permissions. As Stokes put it: "If you don't own that record, if you don't have permission to see that record, the MCP server doesn't either."

This is well designed. Centralized authentication is better than asking every user to manage a connection. Inherited permissions are safer than a shared service account. Keeping data inside the Bedrock trust boundary avoids another trip through an external API. Those details consume months when teams have to solve them one integration at a time, and Salesforce has handled them at the platform level.

They solve the connection problem. They don't decide how the work should be governed.

Does inheriting permissions solve AI governance?

Permissions tell you whether a user can touch a record. They don't tell you whether the user, or an agent acting for them, should make a particular change. That depends on who owns the data, which writes require review, how irreversible actions are approved, and who handles mistakes.

Permission inheritance is a necessary baseline, but it cuts both ways. If Claude cannot use permissions you lack, it can use every permission you have, at conversational speed. In most organizations I've worked with, profiles and permission sets have accumulated exceptions for years. A rep can still edit closed Opportunities because of a 2019 migration. A service user has Modify All on an object nobody remembers granting. That excess access was easier to ignore when using it required someone to find a record and click through a form. A natural-language instruction such as "clean up my pipeline" can exercise it across many records at once.

That old permission audit is now part of the implementation plan.

What happens when Claude updates the wrong Opportunity?

Suppose a rep finishes a call and asks Claude to move the deal to Negotiation and push the close date to Q4. The account has two open Opportunities with nearly identical names: one renewal and one expansion. Claude chooses the renewal. The rep has permission to edit it, so the update passes validation, triggers the expected Flows and Apex code, and rolls into the forecast. Every system involved behaves correctly. The valid update simply lands on the wrong record.

The Salesforce record page used to give the rep one last chance to notice.

The UI did more than collect input. Opening a record exposed its name, amount, stage history, and related activity before the rep clicked Save. That context often caught a mismatch. Salesforce never called it a control, but for plenty of CRM data it was the only review the change received. When the rep stays in Claude, that moment disappears. The convenience in the demo comes from removing the same friction that made someone look at the record.

That doesn't prove the error rate will rise. Claude may resolve an ambiguous name more reliably than a tired rep choosing from a list. But agents will still make some mistakes, and fewer people will see the underlying record when they happen. Every organization using this interface needs a detection path. If the first check is a pipeline review three weeks later, the bad data may already have reached the forecast presented to leadership.

This is the same issue I raised with Summer '26, now at the interface layer. Easier deployment gave teams less reason to settle the workflow before launching an agent. A headless CRM removes some of the informal review that used to catch the resulting errors. Both releases improve the product. They also make missing governance harder to see until something goes wrong.

Who owns the numbers when everyone vibe-codes their dashboard?

The custom dashboards in the demo raise a different problem. Sellers will like being able to ask for a view of live CRM data in the format they want. But a dashboard is not only a chart. It also carries a definition of the metric being shown.

A forecast dashboard can take sales ops two weeks because the team first has to agree on what counts as pipeline, which stages roll up, and which exchange rate applies. The finished dashboard records those decisions. If every seller generates a private view in chat, the source data may be governed while its interpretation is not. Four people can arrive at Monday's forecast call with four defensible answers drawn from the same org.

The answer isn't to block custom dashboards. It is to establish authoritative definitions for important metrics, publish them somewhere Claude can use them, and make clear when a generated view is personal analysis rather than the company number. That work should happen before the beta reaches the whole sales team.

What to do before the September beta

Salesforce has provided enough control to run a sensible pilot.

Start with the MCP server's read-only dispatch mode. Meeting preparation, deal health, pipeline review, and account summaries deliver much of the value without allowing Claude to change the source data.

Before enabling writes, review profiles and permission sets. Pay particular attention to broad object access, old exceptions, and permissions that were acceptable only because people rarely used them.

Then define the write path. Decide which objects Claude may update on its own, which changes require confirmation, and what the confirmation must show. Asking a user to confirm their original instruction is not enough; show the resolved record and the proposed field changes. Assign someone to monitor and correct bad writes, because prevention will never catch all of them. This is workflow design, and the product cannot do it on your behalf.

Salesforce has made the connection and the interface easier. Data ownership, approval paths, and accountability still belong to you.

What is Claudeforce?

Claudeforce is the Salesforce and Anthropic partnership announced on August 26, 2026. It brings Claude into Agentforce through Amazon Bedrock, makes Claude the default model in Slack, and includes Salesforce in Claude, a plugin with 37 prebuilt sales skills for working with live CRM data.

Does Salesforce in Claude respect existing permissions?

Yes. Salesforce in Claude uses Headless 360's hosted MCP server and applies each user's existing Salesforce permissions. Claude cannot read or write a record the user could not access. Existing over-permissioning still carries over, so profiles and permission sets should be reviewed before writes are enabled.

Is Salesforce in Claude safe to pilot?

Yes, but begin in read-only mode. Teams can use live data for meeting preparation, pipeline review, and deal analysis without putting CRM records at risk. Enable writes only after setting object-level boundaries, confirmation steps, monitoring, and ownership for corrections.

Does Claudeforce replace the Salesforce UI?

It can replace the UI for many everyday sales tasks. It also removes the informal check that occurred when someone opened a record before editing it. Teams that allow writes from Claude need to replace that check with deliberate confirmation and monitoring.