What Claudeforce actually is: three ways to connect Claude and Salesforce

Claudeforce is a partnership, not a product

When Salesforce and Anthropic announced Claudeforce in August 2026, most people heard "a product." It isn't one. Claudeforce is the name of the partnership: Claude's reasoning paired with Salesforce data, workflows, and permissions. What you actually install and configure is a set of separate pieces, and they don't do the same thing.

We've been implementing these pieces for clients since they became available. Here's what each one is, in plain terms.

The most common thing we hear from clients is that Claudeforce is a new standalone product Salesforce is rolling out and will charge for, something you buy, install, and turn on. It isn't. There's no single Claudeforce SKU. There are a few different ways to connect Claude and Salesforce, and choosing the right one for each team is the real decision.

1. The Salesforce connector: Claude talks to the Salesforce API

The Salesforce connector is built by Salesforce and runs on Salesforce Hosted MCP, the managed service (part of what Salesforce calls Headless 360) that lets AI tools work with an org through the Model Context Protocol. It's currently a beta service.

It's general-purpose. Rather than offering a fixed list of actions, it gives Claude a small set of tools to discover the Salesforce APIs available in your org, read their descriptions, and call them:

• Read-only tools: Describe API, Discover APIs, and Dispatch read-only API.
• Write/delete tool: Dispatch API, which can create, change, and delete records.
• Display widget: shows Salesforce records visually inside the conversation.

Best for: admins, builders, and power users who want to ask anything of Salesforce, explore data, or configure the org. Watch out for: the write/delete tool. In Claude's settings, each tool can be set to always allow, needs approval, or blocked. We set writes to needs approval at minimum.

Here's what we've seen with edit access: Claude, connected this way, does real Salesforce administrator and developer work. It builds and changes configuration, writes and fixes automation, and works through backlogs that used to take weeks. In practice, one experienced admin can now do the work of five admins, and one experienced developer the work of five developers.

One admin can do the work of five admins. One developer can do the work of five developers. But only if they already know what good looks like.

That's also the warning. Whoever gives Claude edit access to a Salesforce org should have years of hands-on admin or developer experience. Claude will confidently do what it's asked. Someone has to know whether it was the right thing to ask, spot when a change will break a flow, a report, or an integration downstream, and catch it before it reaches production. Without that experience, you don't get five times the output. You get five times the mess, faster.

2. The Sales Cloud plugin: ready-made sales workflows

The Sales Cloud plugin, also built by Salesforce and also in beta, sits on top of the connector. It's a bundle of about 40 skills, each a written workflow for a specific sales job, and it connects Salesforce and Slack, with optional email, calendar, and document connectors.

A rep starts the day with a daily briefing: today's meetings with account context, deals closing soon, stale-activity warnings, and unread customer emails. Before a call, call prep builds a one-page brief. After it, call follow-up turns the transcript into a customer email draft and an internal Slack summary. Sales leaders get team pipeline reviews, deal-slip scenarios, forecast narratives, and coaching questions for each rep. There are skills for lead triage, account plans, stakeholder maps, renewal radar, win-loss reviews, and more.

The design rules are sensible: analysis respects each user's Salesforce permissions, nothing is written to Salesforce without approval, and emails are drafted rather than sent. It works with your schema, field names, and stages, and you can give it your qualification framework, competitors, and writing style through Claude instructions.

Setup: a Salesforce admin enables the MCP service and creates an External Client App, then the app's consumer key is added to the plugin's configuration. Best for: account executives and sales leaders who want results on day one.

3. A custom connector: one you build yourself

The third option isn't something Salesforce ships. It's a connector you build, for when the out-of-the-box connector and plugin don't fit, or don't exist yet for what you need.

We built one for a client in June 2026, before Salesforce's shared connector was available to them. Their team wanted Claude to look up customer data, but the answer couldn't be "give everyone broad API access." The design:

• A Salesforce Connected App created by us in the client's org, which controls exactly what the connection may do.
• A custom connector in Claude, added by the client's Claude admin using the Connected App's consumer key, so the whole team gets the same connector.
• OAuth sign-in per person, so every user connects as themselves and sees only what their own Salesforce permissions allow.
• Read-only scope limited to the objects the team actually needed: Contacts, Leads, and Accounts. Nothing can be created, changed, or deleted.

For people working in Claude Desktop, the same pattern can run through a small local MCP server that signs in through the Connected App and calls the Salesforce REST API.

The technical build took days, not months. Governance took longer: the person who owns API access in the org had to review and approve the scope first, and that's how it should work.

So did adoption. We sent every pilot user a user guide, gave the client's admins a developer guide, and asked each person to confirm their connection worked before rolling it out further. Some connected the same day. Others took longer to get to it. Building the connector is the easy part. Getting people to use it is onboarding and enablement work.

The trade-off is control. Salesforce's out-of-the-box connector and Sales Cloud plugin are built by Salesforce for everyone, so they're designed around common needs, not your business. A custom connector is designed by your admin for your use case. The admin decides which objects, fields, and actions are available, who can connect, and how. And because it runs on a Connected App you already know how to set up in Salesforce, it's often the quickest, simplest way to get users connected to Salesforce from Claude.

Best for: a quick, easy way to get users connected through a Connected App; admins who want full control over every connection; and businesses whose needs don't fit what Salesforce built for everyone.

Side by side

What has to be true before any of it works

All three options answer from your records and respect your permissions. That's good governance, and it's also why an org with messy data gets messy answers delivered with confidence. Before connecting anything, we check:

• Data quality: duplicates, stale opportunities, and empty required fields, because Claude will repeat them.
• Permissions: profiles, permission sets, and field-level security, so Claude sees exactly what each person should and nothing more.
• Process: stages with clear exit criteria and a written sales process, so skills like pipeline review measure against something real.
• Tool settings: which tools are always allowed, which need approval, and which are blocked, per team.

The problem we find most often is permissions. Almost every org we open for a Claude rollout is overprovisioned: profiles and permission sets that grant far more than the job needs, users with access to installed apps, objects, and fields they shouldn't see, and sensitive data visible to people who have no reason to see it. Nobody notices when a person never goes looking. Claude will look. It inherits every permission the connected user has, so overprovisioned access stops being a quiet risk and becomes something Claude can surface in an answer.

That's why nearly every Claudeforce project we run starts with a permissions and security audit and cleanup: right-sizing profiles and permission sets, removing access to apps and objects people don't use, locking down sensitive fields, and documenting who should see what. It isn't glamorous, but it's the step that makes connecting AI to your CRM safe.

The second big problem is data hygiene. The work Claude does is only as good as the data it can see. Ask it which deals will close this quarter, and it reads your opportunities: stale close dates, duplicate accounts, contacts who left two years ago, empty fields, and amounts nobody updated. Then it gives you a clear, confident answer built on all of that. Bad data used to produce a bad report someone might question. Now it produces a well-written recommendation people are inclined to trust.

So the cleanup comes first: deduplicating accounts and contacts, closing out dead opportunities, filling the fields that matter, standardizing picklists and naming, and putting validation rules and ownership in place so the data stays clean after we leave. Permissions decide what Claude can see. Data hygiene decides whether what it sees is true.

The good news: Claude can help clean it up. The same connection that exposes messy data can fix it. Claude can find likely duplicate accounts and contacts, flag opportunities with close dates long past, spot empty or inconsistent fields, suggest standard picklist values, and draft the updates. Work that used to take an admin weeks of exports and spreadsheets can move in days. The same rule applies as everywhere else: an experienced admin reviews and approves the changes before they're written, so the cleanup doesn't create a new mess of its own.

Which should you start with?

For most companies we recommend a staged rollout: start a small group of reps on the Sales Cloud plugin with writes requiring approval, give finance and ops a read-only connection for their recurring questions (Salesforce's own read-only endpoint or a custom connector), and keep the full Salesforce connector with admins and builders. Expand once the data holds up and people trust the answers.

That's the difference between AI hype and AI reality here. The connection takes an afternoon. Making the answers right takes operations work.

If you want that groundwork done first, our AI Readiness Audit covers the permissions cleanup, the data hygiene, and the connection plan in one fixed-scope engagement.