Independent readiness resource · Official sources only

Salesforce in Claude Readiness Checklist: Data, Permissions and Governed AI Actions

Score the operating foundations an AI action would inherit before connecting sensitive CRM data or enabling writes. Review data quality, user access, workflow ownership, approvals, acceptance evidence and recovery—not just the connector.

Start the five-point scorecard Request a Free CRM Workflow Assessment

Reviewed September 6, 2026 · Salesforce describes selected pilot access and a planned September 2026 open beta · Product details may change

Direct answer

What makes a Salesforce org ready for governed AI actions?

Salesforce in Claude readiness starts with the operating controls Claude will inherit: trustworthy CRM data, least-privilege user access, named workflow owners, defined write boundaries, sandbox tests and an audit path. Review those foundations before enabling actions because Salesforce MCP access runs in the authenticated user's context and applies existing permissions and business rules.

Salesforce documents the underlying permission model in its Headless 360 MCP reference and security best practices.

Original five-point scorecard

Score the operating system before the AI action

Score each area from 0 to 2 and retain the evidence. A high score is not proof of product access or implementation readiness; it is a structured signal for the next review.

Control area	0 — Stop	1 — Partial	2 — Evidenced	Evidence to retain
Data trust	Critical objects, fields, stages or record owners are unclear.	Definitions exist, but duplicates, stale values or incomplete records remain material.	The intended use case has defined fields, owners, validation and a verified sample.	Field and object inventory, duplicate sample, stage definitions, required-field completion and data owner.
Permission trust	Shared access, broad admin rights or unknown effective permissions.	Named users exist, but profile, permission-set, sharing or field-access review is incomplete.	Named pilot users have least-privilege access verified against the intended actions.	Pilot-user list, effective CRUD/FLS, sharing rules, profiles, permission sets and client restrictions.
Workflow ownership	No one owns the process or its exceptions.	The normal path is known, but exceptions, handoffs or failure ownership are informal.	A named owner has documented the normal path, exceptions, handoff, acceptance and failure response.	Workflow map, named business owner, exception path, service expectation and escalation route.
Governed actions	Read, write, external and destructive actions are not separated.	Some controls exist, but approval or field/action boundaries are incomplete.	Every enabled action has a risk class, explicit boundary and human-approval rule.	Action inventory, read/write classification, allowed fields, approval table and rollback rule.
Audit and recovery	Actions cannot be attributed, reconciled or reversed.	Logs exist, but review ownership, alerts or rollback evidence is incomplete.	Named reviewers can attribute actions, reconcile results and execute a tested rollback path.	API log owner, review cadence, alert rules, before/after evidence, incident route and rollback test.

0–3/10

Stop and repair the foundation.

4–6/10

Consider only a narrow read-only discovery pilot.

7–8/10

Prepare a bounded pilot and close every partial control.

9–10/10

Proceed only after product terms, access and acceptance gates are confirmed.

If data trust is the blocker, use the Salesforce cleanup before automation guide before expanding access or workflow scope.

Read/write permission matrix

Inherited permission is a technical boundary, not a business approval

Salesforce says hosted MCP calls run as the authenticated user. If that user is over-permissioned, the agent inherits a wider technical boundary. Separate what the user can do from what the workflow is approved to do.

Action	Class	Permission reality	Initial control
Query or summarize approved records	Read	Authenticated user CRUD/FLS, sharing and profile/permission-set access still apply.	Begin with a read-only server or read-only dispatch and a narrow object set.
Draft an account note, plan or email	Draft only	The model can use readable context; no Salesforce or external write is required.	Require a person to review the draft before it is copied, saved or sent.
Update one approved field	Bounded write	The user must be allowed to edit the object, field and record.	Require explicit confirmation, field allowlisting, before/after evidence and rollback.
Create a task, campaign or record	Write	Create access, required fields, validation rules and sharing outcomes apply.	Use approved templates and test normal, duplicate and validation-failure paths.
Send an external message or trigger a workflow	External / multi-step	The initiating user and downstream automation permissions and rules apply.	Separate approval before the external action and monitor every downstream effect.
Manage users or assign permission sets	Administrative	The authenticated user must already hold the relevant administrative capability.	Keep disabled in an initial pilot; use specialist approval and sandbox evidence.
Deploy Apex, configuration or credentials	Administrative / development	Wide developer or admin permissions can expose high-impact operations.	Keep disabled by default; require controlled change management and non-production testing.
Delete data, deactivate a user or make an irreversible change	Destructive	The user must be authorized, but inherited authorization alone is not a business approval.	Keep disabled unless a separately approved, tested and recoverable use case exists.

First-party basis: Headless 360 MCP Server, Security Best Practices, and General Best Practices.

Human-approval table

Put approval immediately before the risk changes

Action	Approval rule	Required evidence
Read a defined object or report	Use-case approval before pilot; not necessarily per query	Named user, narrow object set, read-only path and sample validation.
Generate a draft or recommendation	Human review before operational use	No record change or external send until a person accepts the output.
Update one field on one record type	Explicit confirmation for each bounded write during pilot	Approved field list, before/after value, audit receipt and rollback.
Create records or trigger a workflow	Explicit confirmation plus workflow-owner approval	Duplicate handling, required fields, downstream effects and exception queue tested.
Send email or act outside Salesforce	Explicit confirmation immediately before the action	Recipient, content, purpose and downstream logging visible to the reviewer.
Change ownership, permissions, users or configuration	Specialist admin/security approval	Change ticket, sandbox evidence, access boundary, monitoring and rollback.
Delete or irreversibly alter data	Keep disabled by default; two-step approval if ever enabled	Verified backup/recovery, exact target list and independent final review.

Acceptance evidence

Ten tests before a bounded production action

Run these in a sandbox or Developer org with approved test data. A passing happy path is not enough; denied access, dirty data, failure and rollback also need evidence.

1
Denied user test
A user without access to the object or operation receives no data and cannot execute the action.
2
Field-level security test
A restricted field is neither returned nor modified for a user who lacks field access.
3
Record-sharing test
The pilot user sees only records allowed by current sharing rules.
4
Read accuracy test
A defined sample agrees with a trusted Salesforce report or direct record review.
5
Dirty-data test
Duplicates, blanks and stale values do not silently become a confident operational recommendation.
6
Draft-only test
A draft request creates no record change, message, campaign or downstream workflow.
7
Bounded-write test
A confirmed write changes only the stated field on the stated record and preserves the prior value for rollback.
8
External-action approval test
An email, campaign or other external action cannot execute without the required human confirmation.
9
Failure and partial-write test
Validation errors, timeouts and downstream failures produce a clear failure receipt and no hidden partial success.
10
Audit, reconciliation and rollback test
The named user/action is visible in logs, the result reconciles to the request, and the tested rollback restores the approved prior state.

Operational recovery

Failure, audit, reconciliation and rollback checklist

Failure

Stop repeated execution and preserve the error receipt.
Record time, named user, client, tool/action, prompt purpose and affected record IDs.
Identify whether anything wrote before the failure and isolate downstream automation.
Route the incident to the workflow owner and Salesforce admin/security owner.

Audit

Review Salesforce API logs and named-user attribution.
Filter Salesforce Hosted MCP traffic using the documented API client category where available.
Compare approved actions with actual object, field, record and timestamp access.
Retain the approval, execution and failure evidence under the agreed retention policy.

Reconciliation

Compare requested outcomes with Salesforce records and downstream systems.
Confirm external messages, tasks, campaigns and automation effects independently.
Classify every intended item as completed, failed, duplicated, skipped or unresolved.
Do not call the run successful until counts and exceptions reconcile.

Rollback

Restore captured prior values or use the approved recovery method.
Disable the affected server, client or tool when the boundary is uncertain.
Revoke access or tokens if identity/client security may be involved.
Retest in sandbox, document the correction and require approval before resuming.

For a cleanup-first example of how ownership, permissions, reporting and Flow readiness fit together, see the representative Salesforce cleanup implementation pattern. It is not a Claudeforce case study.

Current official status

What is documented—and what still needs confirmation

Documented

Salesforce in Claude is described as a 37-skill sales plugin.
Selected pilot availability and a planned September 2026 open beta.
The Claude connector directory lists a Salesforce beta connector with read/write capability.
Hosted MCP calls inherit named-user Salesforce access and are attributable in audit logs.

Confirm before purchase or production

Exact licensing, packaging and regional availability.
Product-specific legal, security, data-location and retention terms.
Complete skill inventory, limits and supported production configurations.
The distinction between the current connector beta and the announced Salesforce in Claude open beta.
General-availability timing and support commitments.

Salesforce in Claude readiness questions

What permissions does Salesforce in Claude use?

Salesforce says answers and actions run through existing Salesforce permissions and business rules. The underlying hosted MCP documentation says object permissions, field-level security, sharing rules, profile permissions and permission sets apply in the authenticated user context.

First-party source: Headless 360 MCP Server (Beta)

Does Salesforce MCP bypass field-level security or sharing rules?

No. Salesforce documents that hosted MCP transactions inherit the authenticated user’s CRUD permissions, field-level security and record-sharing access. A user who cannot perform an action in Salesforce cannot perform it through the hosted MCP server.

First-party source: Salesforce hosted MCP security best practices

Should a Salesforce MCP pilot start with read-only access?

Salesforce recommends the most restrictive configuration that meets the use case and documents read-only server and dispatch options. Read-only access is the safer starting point for evidence gathering before bounded writes are considered.

First-party source: Salesforce hosted MCP security best practices

What should be tested before enabling write actions?

Test the named user’s object, field and record access; the exact allowed write; validation and duplicate handling; downstream automation; human approval; audit attribution; reconciliation; and rollback in a sandbox or Developer org before production use.

First-party source: Headless 360 MCP Server (Beta)

Is Salesforce in Claude generally available?

Not according to the official material reviewed on September 6, 2026. Salesforce says selected pilot customers have access and plans an open beta in September 2026. The separate Claude connector directory labels Salesforce as beta, but that listing does not establish general availability.

First-party source: Salesforce and Anthropic announce Claudeforce

Does this checklist mean Emergent Logic implements Claudeforce?

No. This is an evidence-backed readiness resource. It does not claim beta access, implementation experience, certification, partnership, customer results or current product availability for Emergent Logic.

First-party source: Salesforce and Anthropic announce Claudeforce

Related Emergent Logic resources

Salesforce consulting for Canadian teams

Commercial scoping for data, workflow, access, testing and handoff.

Salesforce cleanup before automation

Review data, ownership, stages and reporting before Flow or AI action.

AI CRM audit

A broader self-assessment for CRM operating readiness.

Salesforce admin support

Ongoing governance, documentation and controlled admin work.

CRM integration selection workbook

Compare integration classes and document monitoring, exceptions and rollback.

Free CRM Workflow Assessment

Review one real workflow without providing CRM credentials for the initial assessment.

Official sources

The product is evolving. Recheck the official release, beta, licensing and security documentation before relying on this resource for a purchase or production decision.

Review one workflow before expanding AI access

Choose one Salesforce workflow or proposed AI action. We will review the handoff, ownership, required data and control points before you expand automation. No Salesforce credentials are required for the initial assessment.

Request a Free CRM Workflow Assessment Review Salesforce consulting