Claudeforce Explained: What Salesforce and Anthropic Ship, What It Costs, and What It Doesn't Cover Yet
Claudeforce is the Salesforce and Anthropic partnership, and its first product puts Salesforce inside Claude for sellers. Here is what is actually available, what is still marked coming soon, and how to tell whether it covers your org.
Oct 20, 2026
Claudeforce is the Salesforce and Anthropic partnership announced on 26 August 2026. Its first product, Salesforce in Claude, is a plugin with 37 skills for sellers (daily briefings, deal plans, account growth, call prep) that works on live Salesforce data inside Claude, within each user's Salesforce permissions. It started with pilot customers, Salesforce planned an open beta for September 2026, and there is no published price and no general availability date. Sales is covered first; Service, Marketing, Commerce and the other clouds are marked coming soon. Below: what is in it, what it costs as far as anyone can say, and when you would still want a Salesforce MCP server of your own.
What Claudeforce includes
From Salesforce's announcement and the Claudeforce page, Claudeforce is four things under one name:
| Part | What it is | Status |
|---|---|---|
| Salesforce in Claude | A plugin with 37 prebuilt sales skills. Sellers read live pipeline, update records and take "governed actions" from Claude | Pilot customers, open beta planned for September 2026 |
| Claude inside Salesforce | Claude as a reasoning model for Agentforce's Atlas Reasoning Engine, the default for Agentforce Vibes and Agentforce Coworker, and available in Agent Builder, running inside the Salesforce Trust Boundary through Amazon Bedrock | Announced |
| Slack | Claude as the default model for Slackbot and Slack's other AI features | Announced |
| AIforce | The "enterprise harness" that connects Salesforce data and workflows to any agent through MCP servers, APIs and CLI tools | Announced |
When people search for Claudeforce, they almost always mean the first row: Salesforce in Claude.
How Salesforce in Claude reaches your data
Salesforce's FAQ answers this directly: Claude reaches Salesforce through Headless 360, an MCP connection, with no custom integration work. An admin connects it once, and authentication and permissions are managed centrally.
The governance claims are the right ones:
- "Claude sees only what a given user is authorized to see, and can only do what that user is authorized to do."
- Claude can ask for approval before emailing people outside the company.
- When it updates a record, it changes only the fields it names.
- Actions are routed through Salesforce, so your business rules still run.
That is the same architecture we recommend for any assistant touching a CRM: the model never gets more access than the person using it, and writes that matter go past a human first.
What it costs
Nobody can give you a number yet. Salesforce's Claudeforce page lists no price, and the announcement says pricing and packaging are subject to change. Coverage after Dreamforce, such as this analysis by Beri, describes two meters: Salesforce API calls counted against your org's entitlement, and Anthropic usage under your Claude contract.
Before a wide rollout, check both:
- On the Claude side: which plan your sellers need, and whether your Claude contract caps usage.
- On the Salesforce side: your org's daily API call entitlement, and what happens when 50 sellers start their morning briefing at 8:30.
If you are comparing this with Agentforce's published meters, we did that math for a 20-person sales team in Agentforce pricing in 2026.
What it doesn't cover yet
- Clouds other than Sales. Service, Marketing, Commerce, Revenue, Field Service, Tableau, MuleSoft, Data 360 and Industries are all marked "Coming Soon." A support team can't use it today.
- Your customizations. The 37 skills are built around standard sales work. Salesforce doesn't document how they handle custom objects, record types or Flows. Orgs that have been customized for ten years should test with real data during the beta.
- Work that crosses systems. The skills see Salesforce, plus whatever other Claude connectors your sellers have. A workflow that has to reconcile an opportunity with your ERP, a pricing spreadsheet or a WhatsApp conversation needs those systems exposed as tools, with the same permission discipline.
- Assistants other than Claude. If part of your team works in ChatGPT or in your own agents, Salesforce in Claude doesn't reach them.
Claudeforce or your own Salesforce MCP server?
Salesforce in Claude is enough when:
- your users are sellers, and the job is pipeline, deals and accounts;
- your org is close to standard Sales Cloud;
- everyone works in Claude;
- you can wait for the beta to settle and a price to appear.
A Salesforce MCP server of your own fits when:
- the job is outside Sales today: service cases, field work, operations;
- your org runs on custom objects and Flows a generic skill set ignores;
- one assistant has to work across Salesforce and other systems;
- part of the team uses ChatGPT or your own agents;
- you need a production answer now, not a beta.
The two can coexist. Salesforce in Claude for the sellers, a dedicated server for the workflows it doesn't cover.
How we do it ourselves: our CRM, inside Claude
We run our own sales pipeline from Claude every day, through an MCP server on our CRM. It's the same idea as Salesforce in Claude, and we arrived at it from the other direction, so here is what we chose, what we changed along the way, and why.
Why we didn't customize Salesforce
In early 2026 we wanted one tool where most small sales teams juggle three: the sequencing of an outreach platform, the flexibility of a heavily customized Salesforce, and contact enrichment, with several products, each with its own funnel, on one account. Getting there on Salesforce meant licences, a consultant to customize it, and an interface our team didn't want to live in. So in February 2026 we built our own CRM. It's a Go and PostgreSQL application, and it has shipped more than 750 releases since.
That's not a recommendation to leave Salesforce. An org with years of data, process and integrations in it is an asset, and Claudeforce exists for exactly those companies. It's the reason our experience is relevant: we have built and lived with the assistant side of this, on a CRM where we control both ends.
Two places for AI, and where the work went
We built AI into the CRM in two ways at almost the same time. Inside the app: generated messages, a daily coaching tile that reads live pipeline data, an AI recap on the dashboard. And outside it: an MCP server, added two days after the first commit, so Claude could read and write the CRM directly.
Both still exist. But the day-to-day work drifted to the assistant, because that's where we already were. In-app AI is one more screen to open; the CRM in Claude is a question away. Today the CRM exposes 167 tools: search a contact, log an interaction, move a deal, schedule a meeting, plan the day, draft a message. "Who needs a follow-up today, and why?" is a question to Claude, and the answer comes from live data.
What we changed along the way
API keys, then OAuth. At first, connecting an assistant meant pasting an API key. That works for the person who built it and for nobody else. In August 2026 we moved to MCP OAuth: you add the CRM to Claude as a custom connector, log in with your own account, approve a consent screen, and every call runs as you. A "Connected apps" page lists every assistant you have granted access to, and revokes it in one click.
Read and write are separate permissions. A token is granted crm:read, crm:write, or both. The scope a tool needs is derived from the tool's own definition: a tool marked read-only needs read, and anything else, including a tool someone forgot to mark, needs write. We deliberately avoided keeping a second list of which tools write, because the first time someone adds a tool and forgets the list, a read-only token can suddenly change data.
Preview before anything destructive. Tools that update or delete records accept a dry-run that shows what would change, including cascades, before anything happens. Duplicate checks run before creates. Salesforce's own version makes the same choice: Claude asks before emailing anyone outside the company, and changes only the fields it names.
Tenancy is enforced in the server, not the prompt. Every call is scoped to the caller's organization on the server side. A model can be talked into anything; a query filter can't.
The plumbing matters less than it looks. The server runs the official MCP Go SDK, stateless over HTTP, so any replica can answer any request. That part is small. The tools, the permissions and the previews are where the months went.
What this means for Claudeforce
Salesforce has made the same architectural choices we did: an MCP connection, every call as the user, approvals on the actions that matter. That is the strongest argument for trusting it. Where it can't help yet is everything we built after the plumbing: tools shaped around your objects and your process, and workflows that cross into the systems Salesforce doesn't see. That part is always specific to your company, whoever builds it.
What we build
We design, build and run Salesforce MCP servers. Each action, such as finding an account, logging a call or updating an opportunity, becomes a typed tool with validated inputs. Every call runs inside the acting user's Salesforce permissions. Writes to revenue-critical records can require a person to confirm. And the same server composes with your other systems, so one assistant can work across Salesforce and the rest of your stack. Scoping one workflow costs $2,300 to $4,700, and a first workflow in production starts at $17,500, priced here.
What we don't do: we don't implement Claudeforce itself or sell Salesforce or Claude licences. If Salesforce in Claude covers your use case, use it.
Related: Agentforce pricing in 2026, Salesforce MCP server, and From WhatsApp to Salesforce, a reference architecture.
Read next: Claude connectors explained, Why sales reps don't use the CRM.