Claudeforce Explained: What Salesforce in Claude Actually Ships, and What Your Org Has to Fix First

Your VP of Sales forwards a two-line email on a Thursday afternoon: we are joining the Claudeforce pilot, can you have the org ready by month end. You open Setup, type "Claudeforce" into Quick Find, and get nothing back.

That is the correct result. Claudeforce is not a feature that lands in your org with a toggle next to it. It is three separate pieces of work announced under one brand name on August 26, 2026, and only one of them shows up in Setup at all. Knowing which one is the difference between a two-week readiness exercise and a support case in October.

Claudeforce is three things wearing one name

Salesforce and Anthropic announced the expanded partnership as a single story. Underneath, it splits cleanly into three workstreams that have almost nothing to do with each other operationally.

Claude in Salesforce. Claude runs as the reasoning model behind Atlas, Vibes, Coworker, and [Agent Builder](/terms/agent-builder). This part is the least surprising, because Claude has been powering Agentforce workloads since late 2025. The detail that matters for your security review is delivery: Claude is served through Amazon Bedrock inside the Salesforce trust boundary, so inference does not route out to a public API endpoint. Your existing Einstein Trust Layer posture carries over.

Salesforce in Claude. This is the actual new product. A plugin that ships with 37 prebuilt sales skills, letting a seller read pipeline, review deal health, prep a meeting, draft an email, and write records back, all from inside Claude. No Salesforce tab open. This is the piece that changes where the work happens, and the piece your admin team has to prepare for.

Claude in Slack. Claude becomes the default model behind Slackbot, the Claude tag, and Slack Code. Salesforce disclosed 83% internal adoption of the Claude-powered Slackbot and claimed 8.1 million annualized productivity hours from it. Useful as a signal of internal conviction. Not something you configure.

For the rest of this post, Claudeforce means the middle one. The other two are announcements. This one is a project.

The plugin is a client, not an integration

The instinct when a new AI surface shows up is to ask what data it copies. Wrong question here. Nothing is copied. The plugin is an MCP client talking to a Salesforce-hosted MCP server that sits in front of your org's own APIs.

Salesforce made Hosted MCP Servers generally available in April 2026, and the platform/headless-360 server that carries this traffic has been in beta since July, requiring API v67.0 or later. If you have already read our Salesforce MCP guide, the shape will be familiar. What is new is how narrow the tool surface is.

The server does not hand Claude hundreds of API endpoints. It exposes four tools:

The model searches for a capability, reads its spec, then calls it. Three steps instead of a context window stuffed with an API catalog. This is a genuinely good design choice, and it is also why dispatch_readonly matters so much: it is a single lever that turns the entire surface into a read-only one without you enumerating a single object.

The 37 skills sit on top of that. Salesforce says they were co-engineered with Anthropic against Claude's tool use and generative UI rather than being prompt templates wrapped around REST API calls. The visible consequence is that Claude assembles working dashboards on the fly from live org data, as local HTML with real tool calls behind it, instead of returning a paragraph describing your pipeline.

What the 37 skills actually cover, and the first run that should worry you

Salesforce has named a handful publicly: meeting preparation, deal health review, pipeline analysis. Fill in the rest from the shape of a seller's week and you will not be far off. Account research before a call. Next-step suggestions on a stalled opportunity. Email drafting against real record context. Forecast roll-up questions that today take a report and two filters. Record updates dictated in a sentence instead of clicked through a page layout.

None of that is remarkable on its own. What makes it land differently is that the skills carry the reasoning about which operation to call, so a seller never has to know that "deal health" means three queries and a comparison against closed-won history. They ask, Claude picks, the MCP server enforces.

The behavior to plan for is the first run. When a seller connects, the plugin reads their context across Salesforce, Slack, and whatever other connectors they have enabled, then builds them a tailored command center. That is a genuinely nice onboarding moment and it is also the single widest read your org will serve to this thing. If a pilot user's access is broader than you think it is, the first run is when you find out, and it will happen quietly, inside a chat window, with no admin watching.

Which is the argument for doing the permission audit before the invite goes out rather than after.

The auth model is the whole story

Every governance question about Claudeforce resolves to one thing: who is the request running as.

The hosted MCP path uses OAuth Authorization Code with PKCE, per user. There is no service-account alternative and no static credential shortcut. Each seller authenticates individually through an External Connected App successor, the External Client App, and every call executes as that person. Patrick Stokes put it about as plainly as it can be put: if you do not own that record, if you do not have permission to see that record, the MCP server does not either.

That single sentence is why the readiness work is a permissions exercise and not an integration exercise. Object permissions, field-level security, sharing rules, and record-level access all apply exactly as they do in the UI. Nothing is bypassed.

The scope matters too. Salesforce shipped a dedicated mcp_api scope rather than reusing the general api scope, specifically so that granting MCP access does not hand out full Platform API access to REST, Tooling, and Metadata. Your External Client App for this needs mcp_api plus refresh_token, offline_access, and nothing else. If someone on your team adds full because the connection failed once, that is the finding your next security review should catch.

Contrast this with the other pattern in the same family. Some Salesforce-to-AI connections, including the Claude tag's org connection, use OAuth client credentials bound to a single integration user. Every request from every person runs as that one identity. Both patterns are legitimate. They have completely different blast radii, and they will both be live in your tenant at the same time, which is exactly how a governance model gets confused.

Five things to fix before the beta opens

Salesforce in Claude is with select pilot customers now, with open beta expected in September 2026 and additional skills for service, marketing, and commerce later in the year. That gives you weeks, not quarters. Here is the work in the order I would do it.

1. Audit the profiles you are about to point an agent at. Over-provisioned access has always been a latent risk. A seller with View All on Account rarely exercises it through the UI, because the UI does not invite you to ask for everything at once. A reasoning model does. Run the permission audit before the pilot, not after the first surprising answer. Start with any profile that carries View All Data, Modify All Data, or object-wide View All, and confirm every pilot user's effective access is what you would sign off on in writing.

2. Turn on read-only first. Restrict the pilot cohort to dispatch_readonly. Sellers get the analysis, the meeting prep, and the pipeline reasoning, and nothing can write. You learn what people actually ask for before you accept the risk of what they can change. Move to write access per skill once you have a week of logs.

3. Remember that writes fire everything. A record update from Claude is a DML operation like any other. Validation rules run. Record-triggered flows run. Triggers run. Governor limits apply. If a seller asks Claude to update forty opportunities and your Opportunity trigger is not bulk-safe, you will find out in a way that has nothing to do with AI. Test the write path against your automation in a sandbox before it meets a quota-carrying human.

4. Tighten the connection itself. MCP servers default to inactive, so activate only the ones you need. Pre-authorize the External Client App to a specific permission set rather than to all users. Enforce trusted IP ranges through Network Access. Cut the refresh token lifetime down from its one-year default, because a stolen refresh token on a per-user OAuth connection is a stolen seller session.

5. Wire up monitoring on day one. MCP traffic is visible through Event Monitoring. Pull the API Total Usage event type from the Event Log File Browser and filter the API_CLIENT_CATEGORY column on SALESFORCE_HOSTED_MCP. Do this during the pilot while volumes are small and the data is legible. Standing up monitoring after an incident is how you learn that you cannot answer the only question anyone will ask.

The billing answer nobody has yet

Two meters, two contracts. Salesforce charges the Salesforce side through headless consumption pricing, metered on API calls and varying by user license edition. Anthropic charges you separately for Claude inference. As Stokes said, you cannot buy this on one piece of paper at the moment.

That is a procurement problem before it is a technical one, and it is the reason your pilot needs instrumentation more than it needs enthusiasm. Salesforce's own guidance on expected consumption is directional at best: the comparison offered was that this sits nowhere close to the token volume of a coding agent. Probably true. Not a number you can put in a budget.

So get one. Run the pilot with a defined cohort, count MCP calls per seller per week from the Event Monitoring data, and multiply. A ten-person pilot that produces a defensible cost-per-seller figure is worth more than a hundred-person rollout that produces a surprise invoice. This is the same discipline the Headless 360 rollout needed, and the same one most orgs skipped.

The Winter '27 collision is real

Open beta lands in September. Winter '27 upgrades production instances across three weekends: September 4, October 2, and October 9, 2026, assigned by instance. Check the Salesforce Trust maintenance calendar for yours.

Do not run both at once. If a skill misbehaves the week your instance takes a major release, you get to spend two days proving which change caused it, and you will be doing that with a sales leader asking for hourly updates. Pick an order. Either finish the release regression first and start the pilot after, or start the pilot deliberately early and freeze changes across your upgrade weekend. Either sequence is fine. Overlapping them is not.

The part worth being uncomfortable about

I like the design. Per-user OAuth with a narrow scope and four tools is a better security story than most AI integrations shipping this year, and it is meaningfully better than a shared integration user with a permission set nobody has reviewed since March.

The strategic shape deserves a harder look. Salesforce has made one vendor's model the default reasoning layer across its AI surfaces while simultaneously becoming a plugin inside that vendor's product. Benioff's framing was that the UI is the AI. Read that as an architect rather than as a shareholder and it says the interface you spent a decade customizing is no longer where the work happens. Page layouts, Lightning pages, and the Salesforce Trust Layer masking you tuned for the UI all assume a browser session on the other end.

Keep model optionality in your architecture on purpose. Anything you build on top of this should be able to survive the model underneath changing, because over a five-year horizon it will. That is not a prediction about this partnership. It is what every default in this ecosystem has eventually done.

Also: both the MCP server and the plugin are beta. Keep them off the critical path for anything that has to close a quarter.

What to do this week

Open Setup, go to External Client Apps, and create one for this with exactly two scopes: mcp_api and refresh_token, offline_access. Then pre-authorize it to a new permission set holding your five pilot sellers, and confirm those five users' effective object and field access in the Permission Set Overview before anyone connects. That is one afternoon of work, it is reversible, and it is the piece that determines what the pilot can reach on day one.

The rest can wait for the beta. The permission audit cannot, because the first time a reasoning model asks your org for everything it is allowed to see, you want to already know the answer.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.