Agentforce Readiness Checklist for Lean Salesforce Teams

An Agentforce implementation checklist should not start with your org. It should start with one workflow.

That distinction is the whole answer. Most readiness assessments circulating right now grade an entire Salesforce environment against enterprise-scale criteria, produce a long remediation list, and leave a five-person team with no defensible first move. A workflow-level assessment does the opposite. It asks whether one specific, repeated process is ready to be automated, scores it across eight concrete dimensions, and tells you whether to build, fix something first, or wait.

This guide gives you that scoring model, the thresholds for a stop or go decision, and the cost categories that belong in a separate line item rather than folded into a single number.

Step one: choose the workflow you are actually assessing

Before any readiness question makes sense, name the process. Vague scope is the most common reason small-team AI projects produce a demo and never reach production.

A good first candidate runs frequently enough to matter, has a recognizable shape, and ends in a Salesforce record. Frequency is the first filter: a process that runs twenty or more times per week generates enough repetition to justify the setup effort and enough volume to measure a result within a few weeks. Predictability is the second: if two experienced people would handle the same input differently and both be right, the process is a judgment call, and judgment calls are poor first automations. The third filter is destination. You should be able to name the object and the specific fields that must end up populated correctly.

Salesforce's own implementation guidance makes a related point about scope discipline: agents built to handle everything become difficult to maintain, test, and debug, while focused agents with clear boundaries stay manageable and can hand off to each other later. Salesforce's engineering write-up on common AI agent implementation pitfalls treats the monolithic agent as one of six recurring production failures. The same logic applies before you build anything. Score one workflow.

The eight readiness dimensions

Score each dimension from 0 to 2. Zero means the answer is unknown or clearly not in place. One means partially in place with known gaps. Two means documented and verified in your own org, not assumed.

The maximum is sixteen. Score interpretation comes later in this article. The dimensions themselves deserve some detail, because three of them account for most late-stage surprises.

Permissions are the dimension teams underestimate most

Salesforce's implementation guidance describes a failure pattern worth internalizing before you scope anything: an agent built for case assignment passed testing with access to the Case object, then failed in production because it needed case comments for context, and comments live on a separate object with separate permissions. The lesson is not that permissions are hard. It is that the dependency chain is longer than the object diagram suggests. Comments, attachments, history, and custom relationships each carry their own access requirements.

The safe pattern is to start restrictive, map every object and field the workflow touches including related records, test with users whose permission sets mirror production, and document why each permission exists. When a permission error appears, the instinct is to widen access until the error stops. Resist it. Trace the specific need instead.

Flow and action readiness depends on skills you may not have audited

Flow is the execution layer beneath most Salesforce AI work, which makes existing Flow maturity a readiness input rather than a background detail. Salesforce Ben's 2026 admin survey of more than 1,100 Salesforce professionals found that roughly 57 percent described themselves as confident or very confident designing and building flows, with confidence dropping sharply among newer admins. Their analysis of Flow as a make-or-break Agentforce skill also notes that the harder problem is no longer learning to build flows but maintaining and governing them over time.

That matters here for a specific reason. Flows were designed for deterministic, rules-based automation. Connecting an AI layer introduces inputs that are phrased in ways the original builder never anticipated, and latent gaps in validation or error handling surface quickly. Auditing the flows a workflow will touch, and hardening them against malformed input, is readiness work that happens before the AI configuration, not after.

Data readiness is scoped to the workflow, not the enterprise

Generative AI capability in Salesforce depends on Data 360 being provisioned and enabled, and Salesforce's own Trailhead material draws a useful line between enabling Data 360 and implementing it. Enabling unlocks a set of capabilities. Implementing, with connected sources, unified profiles, identity resolution, and retrieval indexes, is a larger program that specific grounding-dependent workflows require and others do not.

For a readiness score, the practical question is narrower than either. Does this one workflow have the fields, the recent activity, the related records, and the source documents it needs, in a state a person would trust? Waiting for org-wide data perfection is how small teams postpone useful work indefinitely.

Budget the categories separately

A single implementation number hides the parts that actually vary. Separate them before you take an estimate to a decision-maker.

The last row is the one most often omitted. Agents drift as user behavior, business rules, and underlying data change, which is why Salesforce frames launch as the start of refinement rather than the end of the project. Testing Center gives you a regression suite when test cases are labeled with expected topics, actions, and responses, though Salesforce notes it currently covers single-turn interactions, so multi-turn paths still need manual review. Budget the recurring hours honestly or the score in the team capacity dimension is fiction.

Define the baseline, threshold, and review period before you build

A readiness assessment without measurement is an opinion. Three numbers, written down in advance, convert it into a decision you can defend.

The baseline is current effort. Tasks per month, multiplied by minutes per task, divided by sixty, gives current hours per month. To illustrate the arithmetic only: a workflow running 120 times a month at 12 minutes each represents 24 hours a month today. Those inputs are illustrative. Use your own.

The success threshold is the result that would justify continuing. Express it as a percentage of the baseline recovered, plus a quality condition, plus an exception rate you can tolerate. A threshold of half the baseline hours returned with no increase in rework, and fewer than one in ten runs requiring escalation, is a reasonable shape. The specific numbers should reflect your own tolerance.

The review period is a date. Four to six weeks of real production volume is usually enough signal for a first workflow. The stop or go decision at that date has three outcomes: expand to a second workflow, hold and fix the specific dimension that underperformed, or stop and document why. Naming the third outcome in advance is what keeps a pilot from becoming a permanent experiment.

What your score means

Two dimensions function as gates regardless of total. If permissions score zero, stop. If measurement scores zero, you cannot evaluate the result, so the pilot cannot succeed or fail on evidence. A high total with a zero in either of those places is not a passing score.

A worked example

Consider a mid-market service team processing inbound equipment support requests that arrive as email attachments and PDFs. Volume is steady, the destination is a Case with six required fields, and today a coordinator re-keys each one by hand.

Process clarity scores two, because the steps are documented and consistent. Data scores one, because the source documents are reliable but serial numbers are inconsistently formatted. Permissions score one, because Case access is defined but attachment and comment access has not been mapped. Flow and actions score one, because an existing assignment flow has no input validation. Channel and deployment score two. Governance and review score two, because the team has already decided a person confirms every Case before creation. Measurement scores two. Team capacity scores one, because an owner is named but has not been given recurring time.

The total is twelve. That is a proceed-with-conditions result, and the conditions are specific: map attachment and comment permissions, add input validation to the assignment flow, and commit two hours a week of ownership. None of those requires a platform decision. All three are a week of work. This example is illustrative and not a projection of any customer outcome.

Where ConvoPro fits, and where it does not

If the readiness score points toward a broad, multi-team agent program with the administrative capacity to operate it, Agentforce is the platform built for that scale, and Salesforce's Agentforce hub is the right starting point. Native Salesforce Flow remains the correct answer for processes that are fully inside Salesforce, stable, and rules-based.

ConvoPro is a practical AI workflow layer for Salesforce, and it fits a narrower pattern: work that starts outside Salesforce as an email, a file, a note, or an external submission, needs to be structured, and must end in a clean Salesforce record with a person confirming the change. Salesforce remains the system of record. Administrators control what each workflow can access, which actions and tools are available, where human review is required, and how published workflows are owned and retired. Review-before-create is the governance pattern, and it is documented in more depth in our guide to review-before-create Salesforce workflows.

The readiness argument for a lighter layer is capacity, not capability. Teams without a large admin or development bench can start with the Salesforce environment they already have. Details on the control points sit on the security and governance page, and architecture, retention, and compliance documentation belongs in a security review rather than a blog post. Current plans and the usage model are on the pricing page. If you are weighing the two paths directly, the ConvoPro and Agentforce comparison lays out the fit questions, and the alternatives guide covers the wider option set. For budget-model questions specifically, see our breakdown of how Agentforce pricing models work.

Next steps

1. Name one workflow and write its current steps, inputs, and exceptions on a single page.

2. Score the eight dimensions honestly, marking anything unverified as zero rather than assuming.

3. Write the baseline hours, the success threshold, and the review date before any configuration begins.

4. Close the lowest-scoring dimension, then build, measure against the threshold, and make the stop or go call on the date you set.

The workflow value estimator on our home page will help you put numbers on the baseline for one process. When you are ready to scope a focused pilot with the controls and review points defined up front, you can plan a pilot. For governance framing beyond Salesforce specifics, the NIST AI Risk Management Framework is a useful reference when documenting risk and review criteria.

Frequently asked questions

What are the actual Agentforce implementation requirements?

At a platform level, Agentforce requires Data 360 to be provisioned and enabled in the org along with Einstein generative AI, plus the relevant permission sets assigned to builders and users. Edition eligibility and license names vary, so confirm the specifics for your org with Salesforce. At a workflow level, the requirements are the eight dimensions above: a documented process, the right data, mapped permissions, hardened flows, a decided entry point, defined review points, a measurement plan, and a named owner.

How long does an Agentforce readiness assessment take?

Scoring one workflow across eight dimensions is a focused exercise, usually a single working session with the admin and the person who performs the work. Verifying the answers takes longer than scoring them, particularly the permission mapping, which is where assumptions tend to hide. Assessing an entire org is a different and much larger undertaking, which is why the workflow-level version is more useful for lean teams.

Do we need Data Cloud before we can start?

Data 360 must be provisioned and enabled for Salesforce generative AI features, but a full implementation with connected sources, unified profiles, and retrieval indexes is only required for workflows that depend on that grounding. The distinction between enabled and implemented is worth confirming against Salesforce's current documentation for your specific use case rather than assumed either way.

What is the difference between a readiness assessment and a pilot?

A readiness assessment predicts whether one workflow can succeed. A pilot tests it against a threshold you defined in advance. Running a pilot without the assessment means discovering the permission and data gaps in production. Running the assessment without a pilot means you never learn whether the estimate held.

How much does an Agentforce implementation cost?

There is no single figure, because the six cost categories in the table above vary independently. Salesforce publishes current consumption rates and license options on its own pricing pages and marks them subject to change, so treat those as the source for platform figures and build implementation, data, testing, and ongoing administration from your own labor rates. Any estimate that combines all six into one number is hiding the variables you most need to see.

What should a Salesforce AI pilot checklist include?

The pilot checklist is shorter than the readiness checklist. Confirm the workflow scope has not expanded, confirm the review points are configured and not merely intended, confirm the baseline is recorded, confirm the regression test cases exist, confirm the owner has time allocated, and confirm the review date is on a calendar with the stop or go criteria written next to it.