Every serious enterprise Claude deployment eventually asks the same question: where does it get its facts from? A model that reasons brilliantly over whatever gets pasted into it is still reasoning about a snapshot, usually a stale one, assembled by hand. The organisations that get past this are the ones that connect Claude to the system where their operational truth actually lives. For a very large number of enterprises, in the Netherlands and across Europe, that system is Salesforce.
This is the architecture of that connection: what it looks like done properly, and why doing it properly is a different exercise from doing it quickly.
Two teams, two systems, no bridge
The pattern we see most often is not a failure of ambition. An innovation team runs genuinely impressive Claude experiments, on exported reports, pasted case notes, screenshots of dashboards. Meanwhile the operations team runs the actual business on Salesforce: the accounts, the cases, the entitlements, the pipeline. Between the two sits copy-paste, and copy-paste is not an integration.
The consequences are specific and predictable. The experiments answer confidently about last month's reality rather than this morning's. Nothing produced in the experiment lands back in the record where the work of the business actually happens, so the value evaporates at the end of every session. And because there is no connection to the platform's permission model, nobody with a security remit is prepared to let it anywhere near production. The fix is not a cleverer prompt. It is a governed bridge, built to the standard the platform, and your compliance function, already expect.
What MCP actually gives you
The Model Context Protocol is the standard that lets Claude read from and act on external systems in a structured, permissioned way, rather than through improvised scripts and manual exports. An MCP server for Salesforce is the thing that turns "Claude, based on this pasted text" into "Claude, working from the live record, under the same rights the requesting user already has."
Built properly, this means several things simultaneously, and all of them matter:
Least-privilege access. The server exposes only the objects, fields and actions the use case genuinely needs, not a blanket connection to the org. A tool built for case triage does not also carry write access to opportunity records, regardless of how convenient that might seem during development.
Permission-respecting by design. Claude sees exactly what the requesting user is entitled to see under your existing sharing rules and permission sets. This is not a nice-to-have bolted on for compliance; it is the difference between an integration your security team can approve and one they cannot, and it should be the first design decision, not a later patch.
Full auditability. Every read and every action is logged and attributable, to the record it touched and the user on whose behalf it happened. When your compliance function asks what an agent did last Tuesday, the honest answer should already exist, not need to be reconstructed.
Built to be operated, not just demonstrated. Authentication that survives a credential rotation, rate limits that survive a traffic spike, versioning that survives a Salesforce release. The gap between a working demo and production infrastructure is almost entirely in this category of unglamorous engineering, and it is where most homegrown attempts run out of runway.
We cover the engineering of this in more depth in our piece on MCP server development; the rest of this article focuses on what the connection unlocks specifically when the platform on the other end is Salesforce.
Where Agentforce and Claude reasoning meet
Salesforce's own Agentforce provides native orchestration, channels and monitoring inside the platform. Claude provides the reasoning layer: understanding an unstructured request, planning a multi-step response, applying judgement to ambiguous cases. These are not competing choices. The question worth asking is not "Agentforce or Claude" but which combination of the two your use case actually needs, and that answer changes case by case.
Some organisations need Claude's reasoning connected directly through MCP, operating outside Agentforce entirely, typically where the use case sits partly or wholly outside Salesforce. Others get more value from Agentforce's native rails carrying the operational plumbing, with Claude's reasoning doing the judgement-heavy work inside that structure. Both are legitimate architectures. What we do not recommend is choosing based on which vendor relationship is more comfortable rather than which shape actually fits the use case; that decision deserves the same rigour as any other architectural choice.
Use cases where this connection concentrates value
A few patterns recur across the organisations we speak with, described here in general terms rather than as specific engagements:
Case and dispute handling with full commercial context. An agent that can see the complete relationship, not just the ticket in front of it, resolves more cases without escalation and does so with reasoning grounded in the actual record rather than a summary of it.
Candidate and customer engagement grounded in the live record. Personalisation and follow-up that reflects what is actually true right now in the platform, not a stale export from a marketing tool that has drifted out of sync.
Service and account work that sees the whole relationship. An agent reasoning across the full account history, not the last ticket in isolation, routes and resolves more accurately, and knows what it does not know well enough to escalate cleanly.
The thread through all three: the value was always available in the record. It stayed locked there until reasoning could reach it safely.
The governance layer, specific to this connection
Everything in our security and governance service applies here, with one addition specific to Salesforce: the permission model already exists in your org, built over years, encoding decisions about who can see and touch what. A well-built integration inherits that model rather than replacing it. This is both the safest architecture and, in practice, the fastest one to get approved, because you are not asking a security reviewer to trust something new. You are asking them to confirm that something new respects a boundary they already trust.
Where to start
If Salesforce is where your record of truth lives, this is usually the fastest path we know from a stalled Claude pilot to something a security review will actually approve. Bring your platform, your use case and your questions.