Sistava

How to Connect Salesforce to AI Without Breaking It

How-to — — by Mahmoud Zalt

Connect Salesforce to an AI assistant with hosted MCP servers. The Setup path, the OAuth scopes, what it can write, and the guardrails that matter.

Salesforce is usually the system a company least wants an experiment pointed at. It holds the forecast, the commission numbers and years of history, and every admin has a story about a well-meaning integration that filled a field with nonsense across forty thousand records.

The good news is that the modern path is far less frightening than the old one. You are no longer wiring an integration user with a permanent token and hoping for the best. The connection runs as the person using it, with the permissions they already had.

What is the supported way to connect Salesforce to AI?

Salesforce Hosted MCP Servers. Salesforce announced general availability in April 2026, describing them as available across every Enterprise Edition org and above. They are Salesforce-managed endpoints that expose your org to any AI client that speaks the Model Context Protocol, with Salesforce handling hosting, authentication and permission enforcement.

The important line in that announcement is about permissions: your existing controls automatically apply, including CRUD, field-level security and sharing rules, and every transaction runs as the authenticated user. An AI client cannot read a field the signed-in person could not read, which is a much better default than the shared integration account most teams used to wire up.

Salesforce has tested this with Claude, which has native connector support, with ChatGPT through developer mode and connectors, with Cursor, and with Postman, which it recommends as the starting point for testing. Other clients that support OAuth 2.0 authorization code with PKCE should also work.

How do you actually set it up?

Two pieces: turn on a server, then create an External Client App that your AI client authenticates through. Salesforce describes the shortest path as enabling a server in Setup, then API Catalog, then MCP Servers, and creating an External Client App with the mcp_api and refresh_token scopes.

Connecting an AI client to Salesforce

  1. Enable a read-only server first — In Setup, open API Catalog, then MCP Servers, and enable a reads-only server such as platform sobject-reads. Salesforce notes it can take up to two minutes to become active.
  2. Create the External Client App — In Setup, search External Client, choose External Client App Manager, then New External Client App. Fill in the basic information.
  3. Enable OAuth and set the callback URL — Expand API (Enable OAuth Settings) and enable OAuth. The callback URL depends on the client. Salesforce documents https://claude.ai/api/mcp/auth_callback for Claude and https://oauth.pstmn.io/v1/callback for Postman, and says to copy ChatGPT's from its Advanced settings.
  4. Add exactly two scopes — Access MCP servers (mcp_api) and Perform requests at any time (refresh_token). Salesforce notes the MCP scope grants access to hosted MCP servers, not to the existing REST APIs, so this does not quietly widen anything else.
  5. Tighten the security settings — Select the option to issue JSON Web Token based access tokens for named users, and keep the authorization code flow with PKCE as the only active flow.
  6. Wait, then collect the consumer key — Salesforce says to allow up to thirty minutes for activation, then open Settings, then Consumer Key and Secret under OAuth Settings.
  7. Connect the client and test on known answers — Add the connector in your AI client, sign in, and ask questions you can already verify by hand. Disagreements now are cheap. Disagreements after you enable writes are not.

Salesforce also ships servers beyond record access, including ones that let a client inspect your org's API shape, objects, fields and relationships, plus prebuilt options across its own products and custom servers that expose flows, Apex actions and Named Query APIs. Enable only what the job needs. Every server you switch on is another surface a confused instruction can reach.

What can the AI actually change, and what stops it?

With the record-access server enabled, an AI client can read, create, update and delete Salesforce records, with tools that respect field-level security. That is real power and it deserves a real boundary. The boundary is not a setting you tick once, it is the combination of which server you enabled, which profile the person is on, and which fields their permission set actually allows.

Watch the API allowance too. Salesforce documents 15,000 calls per 24 hours for Developer Edition, and for Enterprise and Professional editions with API access, 100,000 calls plus 1,000 per licence. Unlimited and Performance editions get 100,000 plus 5,000 per licence. There are also concurrency limits on requests running twenty seconds or longer: five for Developer Edition and trial orgs, twenty-five for production orgs and sandboxes. Cross those and you get a REQUEST_LIMIT_EXCEEDED error, usually at the worst moment.

Test in a sandbox before production, and not just out of habit. A Full sandbox carries its own API allowance of 5,000,000 calls per 24 hours, so you can be genuinely rough with it. Production is where your forecast lives, and it is the wrong place to discover that the assistant interprets Closed Lost as an invitation to tidy up.

Access was never the hard part

Every one of these steps solves the same problem: getting an AI to the data. None of them solve the problem that actually costs you money, which is that the data was already wrong. Half-filled records, three versions of the same account, stages that mean whatever the rep decided that quarter.

An assistant reading that will answer with total confidence and be wrong in ways that are hard to spot, because the formatting is perfect. An assistant writing into it will make the mess larger and faster. Connection is a five-minute job. Hygiene is the actual work.

That is the difference we care about at Sistava. You are not connecting a chat window to a database, you are hiring an AI Employee that owns a defined job, works to the fields you allowed, and asks before it does anything outside them. The boundary is part of the hire, not an afterthought in a settings screen.

Whatever tool you pick, keep the sequence honest. Read-only access, one week of watching, then one narrow write job on a named field list. Only widen after the narrow job has been boring for long enough that you stopped checking it every morning.

What this will not do for you

It will not clean your org. If accounts are duplicated and required fields are empty, connecting an AI makes that visible, not better. Deduplicate and agree what each stage means before you give anything write access.

It will not enforce your business process. Validation rules, approval processes and flows are still yours to design. An AI writing through an API path is subject to whatever the platform enforces on that path, and you should test exactly which of your rules fire rather than assume all of them do.

And it will not work on its own schedule. A connector answers when asked. If you want the pipeline kept current whether or not anyone opens a chat window, you need something that runs on its own, which is a different kind of tool with a different cost model. Be clear about which of the two problems you are solving before you buy either.

A closing note for admins who are being pushed to enable this quickly. You are allowed to enable the read server this week and nothing else. That single move gives most of the value people are asking for, costs almost nothing to reverse, and buys you the evidence you will need when someone inevitably asks for write access to a field you would rather protect.

Frequently asked questions

FAQ

Which Salesforce editions support hosted MCP servers?

Salesforce's general availability announcement in April 2026 describes hosted MCP servers as available across every Enterprise Edition org and above. If you are on a lower edition, the alternative is the older route of building an app against the platform APIs, which carries more setup and more responsibility for you.

Can the AI delete Salesforce records?

Salesforce documents that record tools can read, create, update and delete records, respecting field-level security. Because everything runs as the authenticated user, the practical control is the permission set of the account that connected. If that account cannot delete, neither can the assistant.

Do I need a separate connected app for each AI client?

The callback URL is client-specific, so Salesforce documents different values for Claude, Postman and Cursor, and says to copy ChatGPT's from its Advanced settings. That means a separate External Client App per client is the straightforward path, and it also gives you a cleaner way to switch one off without affecting the others.

Does the MCP scope give access to my other Salesforce APIs?

No. Salesforce states that the new OAuth scope provides access to MCP but not to its existing REST APIs. That separation is deliberate and worth keeping, so resist the temptation to attach extra scopes to the same app because it seemed convenient at the time.

Should I test this in a sandbox first?

Yes. A sandbox lets you watch what the assistant does to records before anything touches your forecast, and a Full sandbox carries its own allowance of 5,000,000 API calls per 24 hours, so you can test properly rather than sparingly.

Is Agentforce the same thing as connecting an outside AI?

No. Agentforce is Salesforce's own agent platform, built and run inside Salesforce. Hosted MCP servers are the doorway that lets an outside AI client, such as Claude or ChatGPT, reach your org under your existing permissions. Some teams use both, for different jobs.

Sources