Each rep's own Salesforce access, in ChatGPT

How should Salesforce access in ChatGPT work for a sales team?

Per rep. Each rep connects Salesforce under their own login, so every call the model makes runs on that rep's connection. Salesforce's own sharing rules then decide which accounts it can read. Elaichi takes away the tools a sales team should not have, such as the record deletes, the account merge, and the catch-all tools that can reassign any record.

The failure this prevents is easy to picture. A rep opens ChatGPT and asks it to tidy the close dates on every deal slipping this quarter. The model finds a tool that updates one opportunity. It also finds create_a_salesforce_composite, which runs "a series of Salesforce REST API requests in a single POST call", and salesforce_accounts_batch_delete, which deletes many accounts in one request. Nothing in the prompt asked for either. The question for IT is what the endpoint would have allowed if the model had reached for one.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves Salesforce from a 650+ catalog through one organization endpoint. The Salesforce connector page lists every Salesforce tool, and the CRM connectors sit beside it. Any AI write to a CRM rests on three separate questions, and each fails in its own way:

Layer	Who decides it	In a sales rollout
Reach: which records the model can read	Salesforce, through the rep's own connection	The sharing rules and permissions your Salesforce admin already set
Operation: which tools the rep's ChatGPT is offered	Elaichi, with block rules on the sales role	Deletes, merges, catch-alls and admin tools never reach the model
Argument: which values a kept tool may take	Elaichi frozen arguments, on a shared toolbox	Not the right control here, because each rep reaches their own connection unfrozen

Can sales reps use ChatGPT on Salesforce data without admin access?

Yes. Each rep connects Salesforce under their own login, so ChatGPT reaches only the records that rep can already see in Salesforce, and nobody shares an admin key. Every call runs on the connection it was made through, so Salesforce's own sharing rules decide what comes back.

Keeping write tools off is a separate decision, and it belongs to a role restriction in Elaichi rather than to anyone's Salesforce profile. Write block rules on the sales role for the record deletes, the account merge and the catch-all tools, and those tools are restricted. A restricted tool is left out of the tools Elaichi offers a client and cannot be called. Search still names it, flagged restricted, with no schema. The rule binds the role, so it covers every rep who holds it without touching their own Salesforce access.

Does each rep see only their own accounts?

Only if each rep connects their own Salesforce account. Every call runs on the connection it was made through, not on the identity of the person making it, so a rep's own Salesforce permissions apply to their own connection. The rows the model can read are the rows that Salesforce user can read.

One Salesforce connection shared with the team runs every rep's call as its single owner, in that owner's Salesforce account. That is sometimes what you want, and it is never per-rep access.

Be clear about the boundary inside your company. Elaichi's grants decide who can invoke a connection. A member sees what they own and what was explicitly shared with them, and no organization-level permission widens that list, owners and admins included. Elaichi does not filter Salesforce records by owner. Salesforce does. Mixing the two up is the difference between a control you can defend in an audit and one you only assumed existed.

When a sales engineer needs an account executive's reach, share the connection rather than the credential. Sharing grants use on the connection, and the credential never moves. A separate credential service holds per-account secrets, encrypted at rest. Reading back a connection's configuration returns secret_paths, the list of encrypted fields, with none of their values. Calls through the shared connection run as the executive in Salesforce, so share it with the one person who needs that reach, not with the team.

To set every rep up the same way, a sales manager shares a template at use. A template stores no connection, so sharing it hands out no access to anyone's Salesforce account. Each rep then stamps the template into their own toolbox and picks their own connection for Salesforce. The stamper is recorded as the delegator on each entry they pin, so the toolbox runs on the account that rep chose.

Over MCP, each rep connects ChatGPT once and approves their own grant on Elaichi's consent screen. Every call made with that grant acts as the person who approved it, in the organization they picked. When a member is removed or suspended, their grants are revoked and their client fails on the next call.

Which Salesforce tools should a sales team not have?

The deletes, the merge, the catch-alls and the admin tools. Write them as block rules on the sales role:

Kind	Catalog tools	Why a rep's ChatGPT should not have it
Deletes	delete_a_salesforce_account_by_id, delete_a_salesforce_opportunity_by_id, salesforce_accounts_batch_delete, delete_a_salesforce_record_by_id	The batch tool deletes many accounts in one request, and the record tool deletes any object by name
Account merge	salesforce_accounts_merge	It sends a raw SOAP envelope, and a merge folds duplicate accounts into one
Catch-alls	create_a_salesforce_composite, update_a_salesforce_record_by_id	One runs a series of REST requests in a single call, and the other updates any object by name, owner field included
Admin	create_a_salesforce_permission_set_assignment, update_a_salesforce_user_by_id	Assigning permission sets and editing users is an admin's job

What reps keep is most of the catalog. Reads such as list_all_salesforce_opportunities and get_single_salesforce_account_by_id stay, and so does the SOQL tool, list_all_salesforce_query, whose catalog description says it runs a query "to retrieve matching records". Activity writes stay too: create_a_salesforce_task, create_a_salesforce_event and create_a_salesforce_note log work without touching anyone's pipeline. The opportunity update stays for close dates and stages. A RevOps lead facing the same decision can read how to keep writes per rep while deletes stay blocked.

A rep's own Salesforce permissions may already refuse most of the restricted tools. Block them anyway. A restricted tool is left out of the tools Elaichi offers a client and cannot be called. Search still names it, flagged restricted, with no schema. The block also holds on the day a rep's Salesforce permissions turn out wider than anyone meant.

Blocks combine with other blocks and always beat allow rules, so adding one never widens anything. A block matches the tool's name or the operation Elaichi pinned when the rule was saved, so a renamed tool in a forked connector is still caught. Why blocks and allows match differently has the reasoning. Write blocks rather than a short allowlist, too. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.

A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. A one-off exception for a sales manager is not a user rule. The manager files an access request, and an admin with member:manage approves it in the console. Approval lifts exactly the approved tool out of that manager's role rules, and every other role block keeps applying.

Can a rep write to Salesforce only after someone approves it?

Not from ChatGPT. Over MCP there is no per-call approval step in Elaichi: the OAuth grant a rep approves on the consent screen is the approval, and every call its scopes cover runs. A confirmation a rep sees in ChatGPT is ChatGPT's own prompt, not Elaichi's.

If a write genuinely needs a person to sign off first, that belongs in an Elaichi workflow, which comes with the Black plan. A workflow holds an approve step: the step asks named people or teams, plus the workflow's owner unless the step leaves the owner out, and the request reaches approvers in the console's Approvals page, in Slack and by email. Only a person can answer. No AI client, and not the Elaichi Agent, can approve a step. A rejection ends the run, and a request not answered within 72 hours by default expires.

So a sales rollout has two shapes, and they do not mix:

• Reps in ChatGPT. The block rules on the sales role decide what runs, and they run with no prompt from Elaichi. Keep the risky tools off the role.
• A reviewed write. A workflow does the write, with an approve step before the risky part. The workflow runs as its owner, with that owner's connections and access, and the organization's restrictions on the owner apply while the run goes.

The Elaichi Agent in the console behaves differently again: there, a connected write stops at an approval card unless the person chose Always allow. That is the Agent, which also comes with Black, not the MCP endpoint ChatGPT uses.

Can Elaichi stop ChatGPT from reassigning a rep's accounts?

With a block rule, yes. With a freeze, no. No catalog tool is called reassign. In Salesforce the owner is a field on the record, so any update tool that writes the record can write the owner. Elaichi decides per tool, not per field, so the way to take reassignment away is to block the tools that can do it.

Start with the catch-alls, create_a_salesforce_composite and update_a_salesforce_record_by_id, which can reassign any object. If reps never edit account records from ChatGPT, block update_a_salesforce_account_by_id as well, and account reassignment is off the table. Keep update_a_salesforce_opportunity_by_id, which reps need for close dates and stages. It can still write an opportunity's owner. There, Salesforce's own rules on who may change a record's owner decide (Salesforce Help), because the call runs as the rep.

A freeze is the wrong tool when each person brings their own connection. In Elaichi, a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. A rep reaches their own Salesforce connection directly, under "Everything I can use", where every connection a member holds use on appears unfrozen. A frozen owner field would also set the owner on every call through its entry rather than protect it. Freezes suit a connection one owner pins into a toolbox for a team, and locking a tool argument shows that pattern.

Why not use Salesforce's own hosted MCP server?

For an Enterprise Edition org or above that needs only Salesforce in ChatGPT, Salesforce's own server is the better choice. Salesforce made its hosted MCP servers generally available in April 2026, "for every Enterprise Edition org and above" (Salesforce Developers blog, checked October 2026). Existing permissions "automatically apply", the post says, naming CRUD, FLS and sharing rules. "Every transaction runs as the authenticated user", and "OAuth and PKCE control access". When the agent updates a record, "that person's name appears in the audit trail". Prebuilt standard servers come with it, plus custom servers for flows and Apex. That is the same per-rep model, delivered by Salesforce itself with no second vendor.

Elaichi adds what reaches past Salesforce:

• One address across several apps. Reps reach Salesforce and every other connected app through one organization endpoint, in ChatGPT, Claude and Cursor alike.
• Restrictions written once per role. The sales role's blocks cover Salesforce and every other app the role reaches, in one rule set.
• Frozen arguments. On a toolbox an owner shares, a pinned value is one the model cannot change.
• One audit trail across apps. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), whichever app the call went to.
• One place to cut access. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. When a rep is removed, Elaichi refuses their next call to any connected app. Their Salesforce user stays until you deactivate it in Salesforce or through your identity provider.

Salesforce's post does not describe rules that span other vendors' apps, nor does it need to: it serves Salesforce's data.

What does ChatGPT need before reps can update Salesforce?

A plan that allows writes, and an admin who publishes the app. OpenAI says full MCP support is available on ChatGPT Business, Enterprise and Edu plans (OpenAI help center, checked October 2026). Only admins and owners publish an app there, and Pro users can connect custom MCP servers with read/fetch permissions only. A rep on Pro can read pipeline but cannot update a close date through it. Connecting Elaichi to ChatGPT walks through the setup.

For a write, the same page says ChatGPT "may ask for confirmation based on app permissions and the action's context". Treat that as a courtesy to the rep, not a control. Whether a prompt appears is ChatGPT's decision, while a block rule holds on every call whatever the client shows.

Two gates sit above the restrictions. The tool:execute permission gates the whole endpoint, and Guest, Auditor and Billing Admin lack it, so those roles cannot call tools at all. OAuth scopes work separately: a connected tool whose method is a delete runs under mcp:tools, since mcp:destructive covers only Elaichi's own deletes, and a tool classified forbidden is reachable under no scope. Through Elaichi, connected tools are never listed one by one, however few there are, so ChatGPT finds a Salesforce tool by searching for it (why the tool list stays short).

The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What holds instead is the block list: a hostile instruction in a Salesforce note cannot steer the model into a tool it cannot call.

How do you prove the restrictions work?

Test them once as a rep, then read the trail every month. A restriction nobody has tested is a belief, not a control.

Start with a search. Signed in as a test member of the sales role, ask ChatGPT for a restricted tool by name, such as salesforce_accounts_batch_delete. A restricted tool is left out of the tools Elaichi offers a client and cannot be called. Search still names it, flagged restricted, with no schema. Search should show exactly that.

Then read the trail each month. Filter it by actor for each rep and by the Assistant category, over the last 30 days. Connected-tool calls sit in that category, ChatGPT's included. Read the entries on the mcp surface. ChatGPT's calls are recorded under the rep who signed in, with ChatGPT named as the client and marked verified. Open a row to see its detail panel, which names the connector and the connection the call ran on. Each entry logs the one path argument that names the object, as the target id, and nothing else about the arguments, so the trail shows which object an update acted on, not what was written to it. What an AI agent audit log must capture covers the rest of each entry.

Read the result two ways:

• A refused call to a restricted tool is rare in the trail. It appears only when a restriction changed after the tool was listed. Keep the rule, and treat the entry as evidence the risk was real.
• No such entries in a month is the normal case. A call a restriction refuses before execution writes no row. Read the writes instead, and check that each landed in the account you expected.

Give the reviewer who reads the trail an Auditor seat. It is read-only, cannot call tools and is not billable, so oversight costs no license. Beyond the in-app trail, export to your own Datadog comes with the Black plan.

What happens to a rep's access when they leave?

It ends with their membership. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The rep's next call through Elaichi is refused. In Elaichi, revoking a share or disconnecting an account takes effect on the caller's next call. Their Salesforce user is a separate step, in Salesforce or your identity provider.

A SCIM deprovision suspends the rep and never removes them. Suspension revokes every live grant, and removal stays a separate step an admin takes in Elaichi. Removal runs a preflight that lists every Salesforce connection the rep owns, private and shared alike. A private connection that a shared toolbox depends on blocks the removal until an admin transfers it to a member. In Elaichi, a private connection that nothing beyond the member depends on cannot be transferred and is deleted with them. A shared connection can go to another active member, never to the admin running the removal, and a transfer leaves every grant on it as it was. It is deleted only if the admin asks for that.

A new block is slower than any of these: it takes about two minutes to reach every surface. The two speeds of an access change explains why, and gives the order to follow on a rep's last day.

When does a sales team not need any of this?

When Salesforce already says no. If your reps hold a read-only Salesforce profile and no write permission exists for them in Salesforce itself, a restriction layer on top adds paperwork without adding safety. Fix the Salesforce profile instead, since that is the real point of enforcement. If one person is trying Salesforce in Cursor on their own account, that is a conversation with that person, not a case for a control plane. And if Salesforce is the only app in question on an Enterprise Edition org, its own hosted server covers the per-rep model.

Governance earns its cost at a specific point. More than one AI client reaches more than one app, and nobody can say from memory where a given write landed. It usually shows up as an audit question. Someone asks what the assistant changed last Tuesday, and the honest answer is that nobody can reconstruct it.

Sales is one of twelve teams on the use cases page, and the HubSpot playbook for marketing runs the same shape on the other CRM. For the wider setup across a CRM and the apps around it, see connecting AI to your CRM. Pricing has the current price for your region, and every workspace starts with a 14-day Black trial, no credit card to start. Buying Gold or Black during the trial keeps its remaining days rather than granting a fresh 14, so it is one continuous trial, and the seats are first charged when it ends. A workspace that buys nothing moves to the free Personal plan. The security overview covers data residency and the offboarding preflight.