You connect Claude to Salesforce through an MCP server — either Salesforce’s own official hosted server for standard objects and fields, or a custom-built one mapped to your org’s specific objects, Flows, Apex, and sharing rules when your setup goes beyond the standard object model.
Two ways to connect Claude to Salesforce
Salesforce ships its own official hosted MCP server, built to work with standard objects and common configurations out of the box. For a lot of teams running Salesforce close to default, that’s genuinely enough — connect it from Claude’s settings and start asking questions. The gap shows up once an org has grown its own shape: custom objects, Apex-driven automation, Flows nobody outside the admin team fully remembers, and a sharing model built over years. That’s where a custom Salesforce MCP server earns its keep.
Salesforce’s official hosted MCP server
If your org runs mostly standard objects — Accounts, Contacts, Opportunities, Cases — with light customization, Salesforce’s hosted MCP server can expose those directly to an assistant like Claude with comparatively little setup. It’s a reasonable starting point, and for some teams it’s the whole solution.
A custom Salesforce MCP server built for your org
Once your org has meaningful custom fields, Apex classes doing real business logic, or a sharing model with role hierarchies and manual sharing rules layered on top of the defaults, a generic server tends to either miss what matters or expose more than it should. A custom-built MCP server is mapped directly to your actual object model — the fields your team relies on, the Flows that encode real process, and the access rules that already govern who sees what.
What a Salesforce MCP server actually exposes
Reading and querying records
Questions like “what’s the status of the Acme opportunity” or “which cases are still open for this account” get answered from live Salesforce data through scoped tools, instead of someone opening the org and running a report.
Custom objects, Flows, and Apex
A custom build can expose the objects unique to your business — a custom Project or Warranty object, say — as named tools the assistant understands, and can respect logic already encoded in Apex or Flows rather than bypassing it.
Respecting your existing sharing model
The server can be built to honor the same role hierarchy and sharing rules Salesforce already enforces, so a rep sees their own accounts through the assistant and nothing more, the same as they would inside Salesforce itself.
Want Claude working safely against your actual Salesforce org?
We’ll scope exactly which objects and fields get exposed, read-only or read-write, and set it up securely.
Talk to a Salesforce MCP SpecialistSetting it up: what the process actually involves
Step one: map what’s actually custom about your org
Before any building starts, the useful exercise is identifying which objects, fields, and automations are genuinely specific to your business versus standard Salesforce behavior the official server already covers reasonably well.
Step two: decide what’s read vs. write, object by object
Most teams start read-only across the board: the assistant can look up records but can’t change anything. Write access — updating a Case status, logging an activity, creating a Lead — gets turned on deliberately, one object at a time.
Step three: test against real org data
The server gets tested against your actual production or full sandbox data, not a clean demo org, including messy edge cases like a Contact with no Account or an Opportunity missing a close date, before anyone relies on it for real work.
Security: why scoping matters more with a CRM than most systems
Per-object, per-field access
A properly scoped Salesforce MCP server doesn’t hand over your entire org — it exposes the specific objects and fields you’ve approved, so the assistant can answer a pipeline question without ever coming near a compensation field or an HR-adjacent custom object.
Every tool call logged
Whether the assistant looked up an Opportunity or updated a Case, that action should be logged and reviewable, giving your team a clear record of what touched Salesforce and when.
On-premise deployment for sensitive CRM data
For orgs under strict data-residency requirements, or where CRM data is simply too sensitive to route through a third-party cloud model, the MCP server can be paired with a model running entirely on infrastructure you control. Our guide to on-premise AI covers how that trade-off works in practice.
What this looks like day to day
A sales manager asks which deals are stalled in the pipeline this month. A support lead asks how many cases are still open past SLA. An account exec asks for a quick summary of an account’s history before a call. In each case, Claude is calling a scoped Salesforce tool and answering from live data — not a stale export or a guess.
Where a human still has to open Salesforce
Complex configuration changes, multi-step approval processes, and anything touching a custom Apex trigger built specifically for your business still belong inside Salesforce itself. A well-scoped setup makes that line clear rather than blurry.
Does everyone see the same Salesforce data through Claude?
Not necessarily, and it shouldn’t. A custom Salesforce MCP server can be built to respect the same role hierarchy and sharing rules Salesforce already enforces — a rep sees their own book of business, a regional manager sees a wider slice, and neither automatically inherits the other’s view just because both are asking the same assistant. Skipping this and giving every user identical access undoes sharing-model work that often took years to get right, so it’s worth confirming explicitly during scoping.
A realistic first-week rollout
Most teams don’t connect every object in one go. A typical first week looks like: pick one area with obvious daily value — pipeline lookups are common — expose three or four read-only tools, and let the team ask real questions for a few days before expanding.
What tends to surface in that first week
Teams usually find two things: a set of questions the assistant answers well right away, and a few gaps where a custom field wasn’t exposed or a related object wasn’t linked cleanly. Both are normal, and both are far cheaper to fix now than after write access is live across several objects.
Questions to ask before you build one
Ask specifically how access control is enforced at the tool level, not just at the Salesforce sharing-rule level — confirm the two actually line up rather than assuming they do. Ask whether tool calls are logged somewhere your team can review. And ask how the server behaves when a record is incomplete or a Flow throws an error, since how it fails matters as much as how it succeeds.
Common mistakes connecting AI to Salesforce
The most frequent one is assuming the official hosted server will cover a heavily customized org without checking first, then discovering gaps mid-rollout. The second is exposing too many objects at once instead of proving a narrow, read-only setup. Both are avoidable by scoping honestly before committing to either path.
Inwizards builds custom MCP servers for Salesforce orgs with the customization official servers weren’t built to handle, with teams in the US, UAE, and India since 2009. If MCP is new to you, our broader explainer on what an MCP server is covers the concept from the ground up, and our guide to connecting Claude to Odoo walks through the same approach for a different ERP.