Claude Code MCP Salesforce Setup
Server options, OAuth, integration user, and the failure modes that hit teams shipping to a real org.
Why Wire Claude Code to Salesforce
Salesforce runs the CRM for most mid-market and enterprise B2B teams. The moment Claude Code can read and write to that CRM, agent workflows shift from interesting demos to actual pipeline tools. Account research that updates the account record. Pre-call briefs that pull the opportunity history. Lead routing that fires on inbound. Field hygiene that catches dirty data before it ships to a report.
The wiring is different from HubSpot in two ways. Salesforce hasn't shipped a first-party MCP server yet, so you'll either use a community server or wrap the REST API yourself. And Salesforce's permissions model is more granular: profiles, permission sets, field-level security, and Connected App restrictions all stack. That granularity is a feature when you want a tight integration and friction when you want to ship fast.
This guide covers both server paths, the OAuth setup, the integration user pattern most enterprise teams use, and the SOQL workflows that show up first in real builds.
Step 1: Pick a Server Path
Two clean options.
Community MCP server. Several open-source Salesforce MCP servers exist (search GitHub for "mcp-server-salesforce"). They expose SOQL queries and SObject CRUD through the standard MCP interface. Install one with claude mcp add --transport stdio salesforce -- npx -y mcp-server-salesforce and configure credentials through environment variables. Pros: fast start, no custom code. Cons: you inherit whatever the maintainer built, you don't control the surface, and a change upstream can break your workflow.
Custom wrapper. Write a small stdio MCP server using Anthropic's SDK template. It's about 80 lines of Python for a basic implementation. The server exposes whatever Salesforce operations you want and nothing else. Pros: you control the surface, the dependency, and the failure modes. Cons: you maintain it. For a real production integration, custom usually wins. For a quick prototype, the community server is fine.
If you go custom, the Salesforce REST API is the foundation. The REST API docs cover SObject operations, SOQL, and bulk endpoints.
Step 2: Set Up the Connected App
Every Salesforce integration runs through a Connected App. In Salesforce Setup, navigate to App Manager and create a new Connected App. Three settings matter.
OAuth scopes. Grant only what the agent needs. For read-only research: api. For writes: api plus the standard read/write permissions. For long-running headless agents: api, refresh_token, offline_access.
Callback URL. For interactive OAuth through Claude Code, this is typically http://localhost:8080/callback or whatever your MCP server expects.
IP ranges. Restrict the Connected App to your dev machines or your agent host. An unrestricted Connected App is a credential a phished employee can use from anywhere.
Two security flags that help. Set "Permitted Users" to "Admin approved users are pre-authorized" and assign a permission set to the integration user that includes the app. This blocks any random user from authorizing the app, even if they have valid credentials.
Step 3: Create an Integration User
The enterprise pattern. Don't authenticate the agent as a real person. Create a dedicated "Integration: Claude Code" user with a Salesforce license, a generated password stored in your secret manager, and a permission set that grants only the object and field permissions the workflow needs.
Three benefits. The audit log shows agent actions distinctly from human actions. The integration user can be deactivated independently if something goes wrong, without locking out a real person. Field-level security on the integration user limits the blast radius of a bad prompt.
For workflows that touch Accounts, Contacts, and Opportunities, the integration user typically needs: Read on Account, Contact, Opportunity, and any custom objects you reference. Edit on the specific fields the agent will write. Run Reports if you're using report data in research. Nothing else.
Step 4: Wire the SOQL Query Pattern
Most Salesforce agent workflows are SOQL-heavy. The agent pulls a result set with a query, iterates over it, and writes back. Three SOQL patterns show up first.
Stale account refresh. "SELECT Id, Name, Industry, NumberOfEmployees FROM Account WHERE LastModifiedDate < LAST_N_DAYS:90 AND OwnerId = :integration_user_id LIMIT 200". The agent reads the result set, runs research on each account, writes the enriched data back, and updates LastModifiedDate naturally.
Open opportunity preparation. "SELECT Id, Name, Account.Name, StageName, CloseDate, Amount FROM Opportunity WHERE StageName NOT IN ('Closed Won', 'Closed Lost') AND CloseDate > TODAY". The agent pulls open deals, reads recent activity, writes a brief to a custom field or a Chatter post.
Lead routing on inbound. "SELECT Id, Email, Company, LeadSource FROM Lead WHERE CreatedDate > :one_hour_ago AND Status = 'New'". The agent reads new leads, enriches and scores, writes the score to a custom field, and either converts or routes based on the rule set.
Keep the SOQL itself in CLAUDE.md or a query file, not in the runtime prompt. That way the queries get reviewed and version-controlled separately from the workflow logic.
Step 5: Add the Guardrails
Salesforce's permissions model gives you stronger native guardrails than most CRMs, but you still need application-layer checks.
Sandbox first. Every workflow gets tested against a Full or Partial Sandbox before production. The Connected App in the sandbox uses different credentials, which prevents accidental cross-org writes.
Field allow list. A PreToolUse hook that rejects writes to any field not on your explicit list. The integration user's field-level security is the first wall. The hook is the second.
Bulk operation thresholds. Salesforce has hard governor limits on API calls per 24 hours. A bug that retries 100 times on 500 records can burn your daily quota by lunch. Cap batch size at 100 to 200 records per run. Track API usage per run and alert when daily usage crosses 70%.
Provenance fields. When the agent writes a field, also write a sibling timestamp and source field. "AI_Account_Summary__c" gets "AI_Account_Summary_Updated_At__c" and "AI_Account_Summary_Source__c" set to "claude-code". This is how you debug a weird value three months later.
Step 6: Test on a Sandbox, Then Ship
Run the workflow against a sandbox on 20 records. Open each one in the Salesforce UI by hand. Verify the field writes. Verify the LastModifiedBy is the integration user. Verify no extra fields got touched. Verify the API call count for the run matches what you expected.
When you find a miss, fix the prompt, the SOQL, or the hook. Don't hand-patch the sandbox record. The bug needs to die at the source. Rerun, recheck, repeat until clean.
Once a sandbox run is consistently right, promote to production. Use the same Connected App pattern in production but with production credentials. Keep the field allow list and the batch caps. Run the first production batch on 20 records and verify the output before scaling to 200 or 500.
What Breaks in Production
Three failures show up repeatedly. Token expiry on long runs. Salesforce access tokens expire on a fixed schedule. A long batch without refresh handling will fail mid-run. The MCP server should refresh automatically using the refresh_token grant. Verify this works before you schedule the headless run.
Governor limits. The 24-hour API call limit varies by org type and license tier but typically lands in the 15,000 to 100,000 range for mid-market editions. Track daily call count per run. The Salesforce API limits documentation covers the exact thresholds.
Validation rule failures. A field write that violates a validation rule throws a clear error from the API. A field write that violates a workflow rule or a trigger gets a less clear error and may partially succeed. Test against the sandbox with all production rules and triggers enabled.
For the HubSpot equivalent setup, see Claude Code MCP HubSpot. For the broader sales agent build pattern, see the Claude Code sales agent guide. For the enrichment workflow that runs on top of either CRM, see the enrichment workflow guide.
Authoritative References
For MCP server setup and transports, see Anthropic's Claude Code MCP documentation. For Salesforce Connected Apps, OAuth flows, and the REST API, see the Salesforce REST API documentation.
Frequently Asked Questions
Is there an official Salesforce MCP server for Claude Code?
Salesforce hasn't published a first-party MCP server as of mid-2026. The cleanest paths are a community server like mcp-server-salesforce (open source, supports SOQL and SObject CRUD), or wrap the Salesforce REST API in a small stdio MCP server using the Anthropic SDK template. Both work. The community server gives you a faster start. The custom wrapper gives you exact control over which objects and operations the agent can call.
What OAuth flow should I use for Claude Code on Salesforce?
The Connected App with OAuth 2.0 Web Server Flow is the standard pattern. You create a Connected App in Salesforce Setup, grant it the OAuth scopes the agent needs (api, refresh_token, offline_access typically), and the MCP server handles the token exchange. JWT Bearer Flow works for headless server-to-server but is more complex to set up. For an interactive Claude Code workflow, Web Server Flow is the right starting point.
What Salesforce OAuth scopes does Claude Code need for GTM workflows?
For read access to standard objects: api (the broad read scope). For writes, add the scopes that match the specific objects you're updating (Accounts, Contacts, Opportunities, Leads). For long-running agents that survive token expiry: refresh_token and offline_access. Always grant the smallest scope set that does the job. Restrict the Connected App's IP ranges to your dev machines or your agent host.
Can Claude Code run SOQL queries through the MCP server?
Yes. Most Salesforce MCP servers expose a query tool that takes SOQL and returns the result set. The agent can run SELECT statements to pull lists of accounts, opportunities, or contacts that match a filter, then iterate over the result set in the prompt. For writes, the server typically exposes create, update, and upsert operations on specific SObject types. Bulk API operations require a separate setup if you're pushing large batches.
What's the biggest risk wiring Claude Code to a production Salesforce org?
An agent with broad write access plus a vague prompt can update fields on the wrong records. Salesforce's permissions model is more granular than HubSpot's, which helps: scope the Connected App to specific OAuth permissions, and create a dedicated integration user with only the object and field-level permissions the workflow needs. A PreToolUse hook in Claude Code that blocks writes to a closed list of fields adds a deterministic layer. Never run an untested agent against a production org. Use a sandbox first.
Source: State of GTM Engineering Report 2026 (n=228). Salary data combines survey responses from 228 GTM Engineers across 32 countries with analysis of 3,342 job postings.