Is Your Salesforce Org Ready for Claudeforce? A 12-Point Readiness Checklist

SEO Brief

Is Your Salesforce Org Ready for Claudeforce? A 12-Point Readiness Checklist

By the HyphenX Solutions team. Last updated: September 28, 2026.

Your Salesforce org is ready for Claudeforce when four things are true:

• you meet the edition and plan requirements
• your permissions reflect what each seller should actually see
• your opportunity and activity data is current enough to reason over
• you have a secure, monitored connection with a clear policy on when Claude may write to Salesforce

Connecting Salesforce to Claude takes an afternoon. Getting an org into a state where that connection is safe and useful is the real project, and it is the part most teams skip.

This checklist covers the 12 checks we run before any Salesforce in Claude pilot. Each one explains why it matters, how to check it, what “pass” looks like, and the gap we find most often.

Key takeaways

• Claude acts as each signed-in user. Any over-broad permission in your org becomes an over-broad permission in Claude, so the permission audit is the most important check on this list.
• The plugin’s skills reason over your records. Stale close dates, empty next steps and missing contact roles turn into confident but wrong briefings.
• Salesforce’s own research found data leaders estimate 26% of their organization’s data is untrustworthy. Budget time for cleanup before the pilot, not after.
• Plan the External Client App, the read-only phase and the monitoring approach before anyone connects.
• You do not need a perfect org to start. You need no blockers on checks 1 to 5 and 10, and a plan for the rest.

Why readiness matters more for Claudeforce than for past Salesforce features

Claudeforce is the expanded Salesforce and Anthropic partnership announced on August 26, 2026. Its first product, Salesforce in Claude, is a plugin with 37 prebuilt sales skills that lets sellers research accounts, prep for calls, review pipeline and update records from inside Claude. It entered beta on September 15, 2026. That was the same day Salesforce announced AIforce, the layer that brings Salesforce data, logic and permissions into Claude, Slack and Lightning.

Three properties of this design change what “ready” means.

Claude inherits permissions exactly

Salesforce’s hosted MCP servers support only the OAuth authorization code flow, so every session is tied to one named user. Salesforce states there is no option to run sessions through a shared integration user. Object permissions, field-level security and sharing rules all apply to every tool call.

This is good news for security, but it means Claude will faithfully expose every permission mistake you have. A sales rep who was accidentally given “View All Data” three years ago can now ask Claude to summarize every account in the company in seconds.

Agents read far more records than people do

Salesforce’s AIforce announcement describes agents reading across hundreds of records at once. Patrick Stokes, Salesforce’s president of applications, has said a seller’s morning prioritization takes something like 10,000 clicks in the Salesforce UI and about 30 seconds in Claude. A person clicking through records rarely stumbles on a sensitive field. An agent summarizing an entire book of business will surface whatever that user can access.

Output quality follows data quality

Salesforce’s plugin documentation says the skills work with your org’s own schema, field names, stages and permissions. They do not invent a sales process. If next steps are empty and close dates are six months stale, the deal review will be built on those values.

Salesforce’s own State of Data and Analytics research found that 84% of data and analytics leaders believe their data strategies need an overhaul before AI can succeed. The same research found leaders estimate 26% of their data is untrustworthy.

How to use this checklist

Score each check as Ready, Needs work or Blocker. A blocker means you should not connect production users until it is fixed. The owner column shows who usually runs the check.

Check 1: Edition, licenses and Claude plan

Why it matters: during beta, Anthropic lists the latest Sales Cloud Enterprise edition as the eligibility requirement for Salesforce in Claude. The plugin depends on Salesforce’s hosted MCP servers, which Salesforce made generally available in April 2026 for Enterprise Edition orgs and above. On the Claude side, the plugin is available on paid plans, and it currently runs in Claude chat and Claude Cowork on web and desktop.

How to check:

• In Setup > Company Information, confirm your edition and that API access is enabled.
• Confirm which Claude plan your organization uses. Team or Enterprise gives Owners control over which groups get the plugin.
• List the users you plan to include, and confirm each has an active Sales Cloud license and a paid Claude seat.
• Submit the beta access request on AgentExchange early. Nothing else in setup can finish until Salesforce’s acceptance email arrives.

Pass: eligible edition, paid Claude seats for every pilot user, and an access request submitted.

Common gap: companies on Professional Edition assume they can use the plugin because they can see Claude marketing. They cannot during beta. If that is you, the practical options are to plan an edition upgrade or wait for broader availability.

Check 2: Legal, beta terms and AI policy

Why it matters: Salesforce describes both the plugin and its Salesforce connector as Beta Services governed by its Beta Services terms. Many companies have policies about beta software touching customer data, and about which AI providers may process it.

How to check:

• Share the beta terms with legal or procurement and get written sign-off.
• Confirm Anthropic is an approved AI vendor under your AI or acceptable-use policy. Anthropic states it does not train its models on data from Team and Enterprise plans by default.
• Confirm how the model provider handles data under AIforce. Salesforce describes AIforce as operating with zero data retention by the model provider.
• If you operate in regulated industries or have data-residency commitments to customers, confirm with your account teams whether the beta meets them before including those users.

Pass: written approval to pilot with a named group and a defined set of data.

Common gap: sales leadership approves the pilot, but nobody asks security or legal until a customer questionnaire arrives. Get sign-off first. It rarely takes long when you bring the documentation.

Check 3: Least-privilege permissions

Why it matters: this is the most important check on the list. Salesforce’s guidance on securing hosted MCP servers says MCP tools run with the same permissions as the user who connected, and recommends least-privilege permission sets reviewed regularly. Stokes has put the rule in one line: if a user does not own a record or have permission to see it, the MCP server cannot read or write it either.

The corollary is uncomfortable. If a seller can see something they should not, so can Claude, and Claude will find it much faster. Our guide to running AI agents safely with permissions, data boundaries and human-in-the-loop controls covers the wider governance model.

How to check:

• List every user who holds View All Data, Modify All Data, View All or Modify All on key objects, or Customize Application. In most orgs, some of these are sales users who were given them years ago to fix a one-time problem.
• Review the profiles and permission sets assigned to your pilot group. Look for object permissions that go beyond the job, for example sellers with delete rights on Accounts, or read access to HR, finance or support objects.
• Check permission set groups and muting permission sets, which are easy to overlook.
• Test as a real pilot user, not an admin. Salesforce recommends testing permission behavior before production, including Apex and Flow tests that run as users with different access levels.

Pass: no pilot user holds org-wide “view all” or “modify all” permissions, and each user’s object access matches their role.

Common gap: the sales operations team. RevOps users often hold broad access for reporting and data loads. If they are in the pilot, either narrow their access or keep them out of the first phase.

Check 4: Sharing model and record ownership

Why it matters: object permissions decide which types of records a user can open. The sharing model decides which specific records. Claude respects sharing rules, so the question is whether your sharing model reflects your intent.

How to check:

• Review organization-wide defaults for Account, Opportunity, Contact, Lead, Case and any custom objects that hold commercial or personal data. Public Read/Write is sometimes set on objects that should be Private.
• Review the role hierarchy, sharing rules, account teams and opportunity teams for the pilot group.
• Pick three records a pilot user should not see (another region’s strategic account, a confidential deal, an executive’s opportunity). Confirm they are hidden in the Salesforce UI when logged in as that user.
• Check record ownership accuracy. Skills such as pipeline review and daily briefing work from the records a seller owns or is on the team for. Orphaned records owned by departed employees disappear from everyone’s view.

Pass: the three test records are invisible to the pilot user, and owned records reflect current territories.

Common gap: confidential deals (acquisitions, strategic partnerships, executive-sponsored accounts) stored as ordinary opportunities with default sharing. Before any AI tool can summarize everything a user can see, move these to restricted record types or tighter sharing.

Check 5: Field-level security on sensitive fields

Why it matters: a user may legitimately see an Account but not every field on it. Claude honors field-level security, so it will only surface fields the user can see. Salesforce’s Headless 360 workshop lists “Claude sees fewer fields than expected” as a symptom caused by field-level security, which confirms the control works. The risk is the opposite: sensitive fields that are visible when they should not be.

How to check:

• Inventory sensitive fields: personal data (personal phone, date of birth, national ID), commercial terms (floor price, discount approval notes, margin), internal notes about customers, and anything subject to regulation in your industry.
• For each, check field accessibility for the sales profiles and permission sets in the pilot.
• Review custom fields created in the last 12 months. When admins create fields quickly, visibility is often granted to every profile by default.

Pass: every sensitive field is hidden from users who do not need it for their job.

Common gap: free-text fields. A “Description” or “Internal Notes” field may contain information that would never be allowed in a structured field, and Claude will read and summarize it. Review a sample of long-text fields on Accounts and Opportunities for content that should not be there.

Check 6: Opportunity data hygiene

Why it matters: most of the plugin’s high-value skills work from opportunity data. In Salesforce’s public plugin repository:

• pipeline review builds a seller’s pipeline assessment from stage data and deal samples
• deal review scores deal health from fields, contacts and activity
• forecast narrative builds the forecast-call brief from opportunity aggregates and field history

If the underlying fields are wrong, the analysis is wrong.

How to check: the plugin includes a skill built for this. Salesforce’s repository describes salesforce-hygiene-check as an audit of open opportunities for missing fields, stale dates, weak next steps, stage mismatches and single-threading, producing prioritized fixes without changing records. Once your pilot is connected in read-only mode, ask Claude to “check my pipeline for data problems” for each pilot user.

Before connection, run equivalent reports:

• Open opportunities with a close date in the past.
• Open opportunities with no activity in the last 30 days.
• Open opportunities with an empty Next Step field, or a Next Step not updated this quarter.
• Opportunities past a mid-funnel stage with only one contact role (single-threaded deals).
• Opportunities with no amount, or an amount that has not changed since creation.
• Stage values that do not match your documented stage definitions.

Pass: fewer than 10% of open opportunities fail any of these reports, or you have a cleanup sprint scheduled before the pilot. If the numbers are well above that, a focused Salesforce CRM cleanup is usually faster than asking sellers to fix records one by one.

Common gap: contact roles. Many teams track stakeholders in email and Slack, not on the opportunity. Anthropic’s launch post says the call-prep workflow adds stakeholders it finds in threads as new contacts. It also says the deal-review workflow adds missing stakeholders as contact roles once approved. That helps, but it works best when the existing data is a reasonable starting point.

Check 7: Activity and meeting capture

Why it matters: briefings and call prep depend on knowing what happened recently. In Salesforce’s plugin repository, the calendar skill builds schedules from Salesforce Event data, and the activity-history skill builds interaction timelines from closed Tasks and Events. If meetings are not logged in Salesforce and no calendar is connected in Claude, a daily briefing may show no meetings at all.

How to check:

• Confirm whether your team uses email and calendar sync (such as Einstein Activity Capture) or logs activities manually, and what percentage of meetings actually appear on Salesforce records.
• Decide whether pilot users will connect Gmail, Google Calendar or Google Drive in Claude. These connectors are not bundled with the plugin, and Salesforce’s setup notes say they must be connected separately if you want those sources.
• Decide whether call transcripts will be available. The call follow-up skill works from a transcript or the seller’s notes.
• Confirm which Slack channels hold deal discussion, since Slack is the one non-Salesforce connector bundled with the plugin.

Pass: for a sample of five pilot users, at least three of their last five customer meetings are visible in Salesforce or in a connected calendar.

Common gap: activity capture that syncs email to Salesforce without storing it as standard Task records. Test what the plugin can actually read for one user before assuming it sees everything.

Check 8: Account, contact and lead data

Why it matters: several skills rank and route, and each depends on fields many orgs leave empty:

• Account tiering ranks accounts using ICP fit, engagement, activity, contact and opportunity data.
• Lead triage produces a priority and routing recommendation from Lead and Account data.
• Expansion whitespace looks at owned products and opportunities.

How to check:

• Duplicate rate on Accounts and Contacts. Duplicates split activity history and confuse account context.
• Completeness of firmographic fields used in your ICP (industry, employee band, region, revenue band).
• Whether owned products or assets are tracked, if you want expansion recommendations.
• Lead source and status values, and whether lead assignment rules reflect current territories.

Pass: ICP fields are at least 70% complete on active accounts in the pilot territories, and duplicate rules are active.

Common gap: industry picklists with 60 values, a third of which are unused. Consolidate them before asking any AI to tier accounts.

Check 9: Documented sales process context

Why it matters: Claude can read your stages and fields, but it cannot infer why you sell the way you do. Salesforce’s plugin documentation says context such as customer profiles, qualification frameworks, competitors and preferred writing style can be supplied through Claude’s instructions. Anthropic’s launch post says deal review scores an opportunity against the team’s methodology. Without that methodology written down, deal reviews fall back to generic criteria.

How to check: confirm you have a short, current document covering:

• Your ideal customer profile and disqualifiers.
• Your qualification framework (for example MEDDICC or BANT) and the fields that capture it.
• Stage definitions with entry and exit criteria.
• Main competitors and approved positioning against each.
• Approved pricing and objection-handling guidance, since the objection-handling skill draws on approved internal documents.
• Writing guidelines for customer email, if you have a house style. The plugin also includes a voice-profile skill that learns an individual seller’s style from recent sent email, which requires access to sent mail.

Pass: a two-to-four page document exists, is current, and has an owner who will keep it updated.

Common gap: the methodology lives in an old enablement deck nobody has opened in a year. Write a fresh, short version. It will help new human hires as much as Claude.

Check 10: Connection security plan

Why it matters: the connection between Claude and Salesforce runs through an External Client App that you create and control. Its settings decide who can connect, what the tokens can do and how long sessions last.

How to check: before setup day, agree the following with your security team:

• A dedicated External Client App for Claude. Salesforce recommends one per MCP client, not one shared across AI tools, to make access control and auditing easier.
• Minimum scopes. Access Salesforce hosted MCP servers (mcp_api) and Perform requests at any time (refresh_token). Salesforce created the mcp_api scope so you do not need the broad api scope, which grants full Platform API access.
• PKCE and JWT-based access tokens enabled, as Salesforce’s documentation specifies.
• Permitted users. Restrict the app to pre-authorized users through a permission set, rather than the default where any user can self-authorize.
• Refresh token policy. The default token can last a year. Salesforce’s documentation suggests a shorter validity, such as 30 days, with refresh token rotation.
• IP restrictions, if your policies require them, and how they interact with Claude’s requests.
• MCP servers. All are inactive by default. Plan to activate only the server the plugin needs.
• Credential handling. Decide how the consumer key and secret will pass from the Salesforce admin to the Claude Owner (a password manager share, not email).

Pass: each item above has an agreed value and a named owner.

Common gap: reusing an existing connected app built for another integration because it “already works.” It will carry scopes and policies designed for something else, which is exactly how integration sprawl becomes a security risk. Create a new one.

Check 11: Write-access policy and audit trail

Why it matters: Salesforce’s setup notes for the plugin recommend setting tool restrictions to keep the beta read-only. With a read-only connection, analysis still works, and write steps provide manual guidance instead. When you do enable writes, Anthropic’s documentation says Claude asks the user to approve each proposed change by default, with options to allow once, always allow or deny. Salesforce says writes route through Salesforce, so validation rules and business logic still apply.

How to check:

• Decide the phases: read-only for the first two to four weeks, then writes for a small group.
• List the fields Claude is most likely to update: stage, close date, next step, amount, contact roles, tasks and logged calls.
• Enable field history tracking on those opportunity fields so every Claude-made change can be reviewed. Changes made through Claude are attributed to the signed-in user.
• Review validation rules and required fields on those objects. Make sure the error messages are clear, since sellers will see them when an approved change fails.
• Agree an approval norm for the pilot. We recommend “Allow once” rather than “Always allow” until you trust the outputs.

Pass: a written phase plan, field history on key fields, and a team norm for approvals.

Common gap: validation rules written years ago that block legitimate updates with vague messages. Test five typical updates as a pilot user before enabling writes.

Check 12: Monitoring, consumption and support model

Why it matters: once sellers use Claude daily, you need to know who is using it, what it is doing, what it costs, and who fixes problems.

How to check:

• Activity logs. Salesforce logs hosted MCP activity through Event Monitoring. In the Event Log File Browser, filter by API Total Usage and look for rows where API_CLIENT_CATEGORY equals SALESFORCE_HOSTED_MCP to see which users called which tools and which objects they touched. Depending on your licenses, some event types and longer retention require Salesforce’s Event Monitoring add-on, so confirm what your org has.
• Sign-in logs. Login History and OAuth Usage show connection attempts and let you revoke tokens.
• API consumption. Stokes has said Salesforce charges for this usage through headless consumption tied to your edition and licenses, with Claude contracted separately through Anthropic. Check your org’s API request limits in Setup > Company Information and watch usage during the pilot, because daily briefings and pipeline reviews read many records.
• Support routing. Decide who users contact, and which issues go to Salesforce (sign-in, skill behavior) or Anthropic (errors in Claude after sign-in).
• Feedback loop. Set up a channel or form where pilot users report wrong outputs, with the prompt and the record involved.

Pass: a named pilot owner, a weekly log review, and a known path for escalations.

Common gap: no owner. When a pilot belongs to “sales and IT together,” nobody reviews the logs. Name one person.

The readiness scorecard

Copy this into a spreadsheet and score each line as Ready, Needs work or Blocker.

A 30-day readiness plan

Week 1: Eligibility and approvals

• Confirm edition, licenses and Claude plan (Check 1).
• Submit the AgentExchange access request.
• Send beta terms and vendor information to legal and security (Check 2).
• Name the pilot owner and pick 5 to 15 pilot users (Check 12).

Week 2: Permissions and security

• Run the permission audit and remove over-broad access (Check 3).
• Test sharing with restricted records (Check 4).
• Review field-level security and free-text fields (Check 5).
• Agree the External Client App design (Check 10).

Week 3: Data and context

• Run hygiene reports and a cleanup sprint with pilot users (Check 6).
• Confirm activity capture and connector decisions (Check 7).
• Fix duplicates and critical ICP fields in pilot territories (Check 8).
• Write the sales process context document (Check 9).

Week 4: Controls and launch

• Enable field history on key fields and test validation rules (Check 11).
• Set up log reviews and a feedback channel (Check 12).
• Complete setup in read-only mode and run permission tests as a pilot user.
• Launch the pilot.

What “ready enough” looks like

No org passes all 12 checks perfectly, and waiting for a perfect org means never starting. Our rule of thumb:

• Must pass before any production user connects: Checks 1, 2, 3, 4, 5 and 10. These are about eligibility, approval and exposure. Getting them wrong creates risk, not just weak outputs.
• Can improve during a read-only pilot: Checks 6, 7, 8 and 9. A read-only pilot is a good way to find data problems, because sellers see exactly where the briefings go wrong.
• Must pass before enabling writes: Checks 11 and 12.

Beyond Salesforce in Claude

These checks apply to more than one product. Salesforce’s AIforce layer launched with three interfaces: Claudeforce in Claude, Slackforce in Slack, and Agentforce Coworker in Lightning. All three read Salesforce data under the user’s existing permissions. An org that passes this checklist is ready for any of them, and for Agentforce agents that act on the same data.

Get a readiness assessment

HyphenX Solutions runs this 12-point assessment for Salesforce teams preparing for Claudeforce, Slackforce and Agentforce. We audit permissions and sharing, score your data, design the External Client App and rollout, and deliver a prioritized fix list. Talk to our Salesforce Agentforce services team to book your assessment.

Frequently asked questions

What is Claudeforce readiness?

Claudeforce readiness means your Salesforce org can safely and usefully connect to Claude through Salesforce in Claude, the first product of the Salesforce and Anthropic partnership. A ready org meets the edition and Claude plan requirements, and has permissions that match what each seller should see. It also holds opportunity and activity data current enough to reason over, and has a secure, monitored connection with a clear policy on when Claude may write to Salesforce. Readiness is less about the connection itself, which takes an afternoon, and more about the state of the org behind it.

How long does it take to get a Salesforce org ready for Claudeforce?

For a mid-sized sales org, plan on about four weeks to reach a pilot-ready state. Week one covers eligibility, legal sign-off and choosing pilot users. Week two covers the permission audit, sharing tests, field-level security and the External Client App design. Week three covers data hygiene, activity capture and your sales process document. Week four covers write controls, monitoring and launch. Orgs with years of permission sprawl, heavy customization or poor opportunity hygiene should allow longer, because those issues take time to fix properly.

Which Salesforce edition do I need for Salesforce in Claude?

During the beta, Anthropic lists the latest Sales Cloud Enterprise edition as the eligibility requirement for Salesforce in Claude. The plugin depends on Salesforce’s hosted MCP servers, which Salesforce made generally available in April 2026 for Enterprise Edition orgs and above. Professional Edition orgs cannot use it during the beta, so the options are an edition upgrade or waiting for broader availability. Each pilot user also needs an active Sales Cloud license and a paid Claude seat, and Team or Enterprise plans give Claude Owners control over plugin distribution.

Can Claude see data a user cannot see in Salesforce?

No. Claude acts as the signed-in user and inherits their object permissions, field-level security and sharing rules, so it can only read and act on what that user can already see. Salesforce’s hosted MCP servers tie every session to one named user, with no shared integration account. The risk runs the other way: any over-broad permission a user holds becomes available to Claude, which can summarize hundreds of records in seconds. That is why permission cleanup comes before data cleanup in any readiness plan.

Why is the permission audit the most important readiness check?

Because Claude inherits permissions exactly and reads far more records than a person does. A seller clicking through Salesforce rarely stumbles on a sensitive field, but Claude summarizing an entire book of business will surface everything that seller can access. Users who were given View All Data or Modify All Data years ago to fix a one-time problem suddenly expose the whole org. Auditing profiles, permission sets and permission set groups before the pilot removes that exposure at the source, for Claude and every other connected tool.

Do we need Data Cloud (Data 360) to use Salesforce in Claude?

Data Cloud, now called Data 360, is not listed as a requirement for the Salesforce in Claude beta. Anthropic lists the latest Sales Cloud Enterprise edition and a paid Claude plan as the eligibility requirements, and the plugin reads your core Sales Cloud records through Salesforce’s hosted MCP server. Other AIforce products, such as Agentforce Coworker, have their own edition and licensing requirements. If you plan to roll out more than one AIforce interface, check the requirements for each product separately before you budget or schedule the pilot.

Should we clean our Salesforce data before connecting Claude?

Clean permissions and security issues first, because they create real risk: exposed records, visible sensitive fields and over-scoped connections. Data quality can improve during a read-only pilot. The plugin includes a hygiene-check skill that audits open opportunities for missing fields, stale close dates, weak next steps, stage mismatches and single-threaded deals, without changing any records. Sellers see exactly where their data is incomplete, which makes cleanup faster and more targeted. Aim for fewer than 10% of open opportunities failing basic hygiene reports before you enable writes.

Should Salesforce in Claude be read-only during the pilot?

Yes. Salesforce’s own setup notes for the plugin recommend setting tool restrictions to keep the beta read-only. In read-only mode, sellers still get briefings, call prep, pipeline reviews and forecast narratives, while skills that would normally update records explain the change instead. Run read-only for two to four weeks. Then enable writes for a small group once field history tracking is on for key opportunity fields and validation rules have clear error messages. Keep “Allow once” as the approval norm until the team trusts the outputs.

Can we run a Claudeforce pilot in a Salesforce sandbox?

Salesforce’s hosted MCP servers support sandbox orgs using separate server URLs, so a sandbox is useful for testing the connection, External Client App settings and permission behavior. Confirm sandbox support for the beta plugin itself with Salesforce when you request access on AgentExchange. For the pilot, most teams use production with a small group and a read-only connection, because the skills only show their value on realistic data. Stale or synthetic sandbox data makes briefings and deal reviews look weaker than they will be in production.

Who should own a Claudeforce pilot?

One named person, usually a Salesforce admin or a RevOps lead, with sponsorship from sales leadership and sign-off from security. The owner runs the weekly log review in Event Monitoring, Login History and OAuth Usage, and tracks API consumption. They also collect feedback on wrong outputs and decide when to move from read-only to controlled writes. Pilots owned jointly by sales and IT tend to stall, because nobody reviews the logs or chases data fixes. A single accountable owner keeps the pilot moving and the org safe.