Salesforce in Claude: How to Set Up the Claudeforce Plugin (Open Beta)

Before You Start: What You Need

This is an open beta, but open does not mean ungated. Set expectations before you promise it to a sales team.

• Salesforce beta approval. Your org has to be approved by Salesforce through the beta sign-up, and it needs the latest Sales Cloud Enterprise edition.
• A Claude organization on a paid plan. Enablement is org-level, so you need admin access to a Claude organization (the Primary Owner or an Owner), not just an individual seat. Salesforce names Team and Enterprise plans in its data terms.
• A Salesforce admin. Setup touches Salesforce Setup (the MCP server and a connected app) and Claude's organization settings, so plan for an admin on both sides, or one person with both.

Because it is still beta, treat it as a pilot with a defined group of sellers rather than a company-wide switch. The steps below are the one-time admin setup, then the per-seller sign-in.

Step 1: Request Access Through AgentExchange

The plugin is distributed and enabled through AgentExchange, Salesforce's marketplace for agents, skills, and connectors. Your Salesforce admin finds the Salesforce in Claude listing and requests access through the form.

Approval comes back as an acceptance email with a link to the Salesforce setup instructions. This is the gate: nothing else works until the request is approved, so start here early.

Step 2: Turn On the MCP Server in Salesforce

In Salesforce Setup, the admin enables the MCP server and creates an External Client App for the connection. That app produces two credentials you will need in a moment: a consumer key and a consumer secret.

Treat those two values like passwords. They authorize Claude to reach your org, scoped to each user's own permissions, so they belong in your admin's hands only.

Step 3: Connect Salesforce in Your Claude Organization

Now move to Claude. This step needs the Primary Owner or an Owner of the Claude organization. Open Organization settings, go to Connectors, and select Salesforce (Beta).

Paste the consumer key into the OAuth client ID field and the consumer secret into the OAuth client secret field, then save. That links your Salesforce org to your Claude organization once, for everyone.

Step 4: Decide Who Gets the Plugin

Still in Claude's Organization settings, open Plugins, find the Salesforce entry in the marketplace, and set how it rolls out. You can make it installed by default, available for sellers to install themselves, or required, and you can scope that to specific groups.

For a pilot, the clean choice is to make it available to a named group of sellers first, watch how they use it, then widen access. That keeps the beta contained and gives you real feedback before a broad rollout.

Step 5: Each Seller Signs In

The rest is per seller, and it is deliberately light. The first time a seller uses the plugin, they sign in with their own Salesforce account through Settings and Plugins. That personal sign-in is what scopes Claude to their permissions, not the org's.

On first open, a setup skill runs on its own. It learns the seller's role and book of business and tunes the plugin's skills to them, with no manual configuration. From there they ask Claude about their accounts and pipeline in plain language.

How Permissions and Write-Backs Actually Work

This is the part a sales leader and a security reviewer will both ask about, and the answer is the reason the design holds up. Salesforce stays the system of record. Because each seller signs in with their own credentials, Claude reads only what that seller is allowed to see. If they cannot open a record in Salesforce, Claude cannot read or write it either.

Writes are approved by the seller, by default. When Claude proposes a change, updating a stage, logging call notes, editing a field, it shows the change and asks before writing it, with Allow once, Always allow, and Deny options. So a seller can let routine updates through and still keep a hand on anything sensitive.

The practical read: this respects your existing Salesforce sharing and permissions rather than bolting on a new access model. Your sharing rules are the guardrail, which is another reason the org's permission hygiene matters before you roll this out.

What the 37 Skills Cover

The plugin ships with 37 prebuilt skills for the work account executives do every day. Salesforce and Anthropic name examples like account research, call prep, pipeline review, deal health review, meeting prep, renewal prep, QBR deck generation, and logging updates back to the CRM.

You do not wire these up. The setup skill personalizes them to each seller when they first sign in. The point is that a seller asks for the outcome, prep me for this call, update the stage on this deal, and Claude runs the matching skill against live CRM data.

Governance and Data, Kept Straight

Two governance facts matter for a rollout. First, on Team and Enterprise plans, Anthropic does not train its models on your data by default. Second, the permission scoping and the default approval on writes, both covered above, are the real day-to-day controls.

One distinction is worth stating because it is easy to mix up. The trust-boundary and Amazon Bedrock language you may have read about Claudeforce belongs to the other direction, Claude running inside Salesforce, which we cover in Claude on Amazon Bedrock for Salesforce. For the plugin, the controls that apply are per-user permissions, approval on writes, and the plan-level training terms.

The CRM Hygiene That Decides Whether It Helps

A plain warning: Salesforce in Claude is only as good as the CRM it reads. If your stages are inconsistent, your fields are half-filled, or your sharing rules are a mess, Claude will faithfully reflect that back. The tool does not fix a messy org, it exposes one.

So the highest-value prep is not the plugin setup, it is the readiness work underneath it: clean stages, the fields that matter actually populated, and sharing rules you trust to be the guardrail. We walk through that readiness in Getting Started with Claudeforce, and it is the same groundwork that makes Agentforce and every AI surface pay off.

Where to Start

If you want Salesforce in Claude in front of a sales team, the sequence is: get the Salesforce beta approval and the AgentExchange request moving early, do the one-time admin connection, roll it out to a pilot group, and use the pilot to tighten your permissions and CRM hygiene before you widen it.

That is exactly the kind of pilot we run. Cloudsheer is a verified Salesforce Consulting Partner and an Anthropic Claude Partner, so the same team owns the CRM readiness, the setup, and the governance. Bring your org and your first pilot team to a scoping call and we will map the fastest safe path. You can also read the full background in Claudeforce, explained or explore our Claudeforce practice.