Is Your Salesforce Org Ready for Agentforce? A Practical Readiness Checklist

Agentforce has moved from pilots to production in a lot of Salesforce orgs. For most teams, the important question isn't "should we use AI agents?" — it's "is our org ready for them?"

It's the right question. An agent doesn't fix your Salesforce org. It uses it: the records, the fields, the automation and the permissions you already have. If those are messy, the agent will be confidently wrong — at scale, and in front of customers.

This checklist covers the four areas that decide whether an agent succeeds: data, process, automation and access.

Why readiness matters more for agents than for people

A person working a case can notice that a contact has three duplicate records, or that a product name changed last year. An agent can't — unless the data tells it. Agents also act faster and more often than any user, so a small data problem that a person works around once a week becomes a problem the agent repeats hundreds of times a day.

That's why the first Agentforce project is usually a Salesforce foundations project in disguise.

1. Data: can the agent trust what it reads?

• Duplicates are under control. Duplicate and matching rules are active on Accounts, Contacts and Leads, and existing duplicates have been merged. An agent that finds three versions of a customer will pick one — maybe the wrong one.
• Key fields are complete. For the objects the agent will use, the fields it relies on (status, category, product, owner, region) are filled in consistently — not "Other" half the time.
• Picklists mean one thing. Values are current, retired values are deactivated, and there's no "Misc" bucket holding a third of your records.
• Knowledge is current. If the agent answers from Knowledge articles, they're reviewed, owned, and free of discontinued products and processes. Stale articles become wrong answers.
• Customer history is usable. Closed cases have resolution notes and consistent categories. That history is what lets an agent recognise a familiar problem.

Quick test: pull a report of 50 random records the agent would work with. If your team argues about whether they're correct, the agent will get them wrong too.

2. Process: does anyone agree how the work should go?

An agent needs a defined process to follow. For each use case, you should be able to answer:

• What starts the process, and what does "done" look like?
• What are the steps, and which require a human decision?
• What are the exceptions — and who handles them?
• Which Salesforce records change at each step?

If the honest answer is "it depends who you ask," document the process first. Agent topics and instructions are only as clear as the process behind them.

3. Automation: will the agent collide with what's already running?

Agents trigger the same record changes as users — which means they also trigger every flow, validation rule and Apex trigger on those objects.

• Know what fires. You have an inventory of record-triggered automation on the objects the agent touches. (If you still have Workflow Rules or Process Builder, start there — see our guide to migrating legacy automation to Flow.)
• No hidden side effects. An agent updating a case status shouldn't unexpectedly send customer emails or create duplicate tasks.
• Error handling exists. Flows fail gracefully and someone is notified when they do.

4. Access: does the agent see only what it should?

• Least privilege. The agent's user and permission sets grant only the objects and fields its job needs. Agents work within the access you give them; Salesforce explains how that responsibility is split in Agentforce security and the shared responsibility model. For the controls themselves, see our Salesforce security and governance work.
• Sharing is understood. You know which records the agent can read, and it matches what you'd allow a human in the same role to see.
• Sensitive data is identified. Fields holding personal, financial or health information are classified, so you can decide deliberately what the agent may use and show.
• Audit trail. Field history and agent activity can be reviewed after the fact.

5. Start with one narrow, measurable use case

Good first use cases share three traits: a clear, repeatable process, data you already trust, and a human fallback. Examples include answering order-status questions, triaging and routing incoming cases, or summarising account history for a rep before a call.

Define success before you build — for example, how many conversations are resolved without escalation, or how much handling time drops — and review real transcripts weekly in the first month.

Readiness checklist (copy this)

Frequently asked questions

Do we need Data 360 (formerly Data Cloud) to use Agentforce?

Not for every use case. Many agents work directly with core Salesforce records and Knowledge. Data 360 matters when the agent needs data that lives outside Salesforce or must be unified across systems. Start from the use case, not the product list.

How long does it take to get an org ready?

It depends on how much clean-up the data and automation need. A focused assessment of the objects in your first use case is usually the quickest way to find out.

Can we start small?

Yes — and you should. One well-defined use case, on clean data, with a human fallback, teaches you more than a broad rollout.

Where to start

The fastest way to know whether you're ready is to look at the org as it actually is. That's what our Salesforce org assessment does: it reviews data quality, automation, security and technical debt, so your first agent is built on a foundation you trust.