Skip to main content

Agentforce Readiness: Assessing Your Salesforce Org

Assess Agentforce readiness across data, org configuration, use cases, governance, and people. Includes a 25-point checklist and a five-level maturity model.

Updated

Agentforce Readiness: Assessing Your Salesforce Org

TL;DR: Agentforce readiness is the state in which your Salesforce org can run AI agents in production reliably, safely, and at a predictable cost. It spans five pillars: data, org configuration, use cases, governance, and people. Score your org against the 25-point checklist below, map the result to a five-level maturity model, and work the 30/60/90 day plan from wherever you land. Most stalled pilots fail on pillar one.

Looking for the Trailhead superbadge unit “Dashboard Insights for Agentforce Readiness”? That is a different topic, covered on Trailhead. This article is about assessing whether your organization is ready to deploy agents.

What Agentforce Readiness Means

Agentforce readiness is the state in which your Salesforce org can run AI agents in production reliably, safely, and at a predictable cost.

The word does a lot of work, so it helps to say what readiness is not. Readiness is not a license. Enabling Agentforce takes an afternoon; making it trustworthy takes longer. Readiness is also not a single dimension. An org with clean data and no escalation path ships an agent that frustrates customers. An org with a perfect use case and unresolved PII in Case Comments ships a compliance incident.

Five pillars carry the assessment:

Pillar The question it answers Who owns it
1. Data Can the agent retrieve accurate, complete, safe context? Data owner, admin
2. Org configuration Can the agent see and do what the use case requires? Salesforce admin, architect
3. Use case Is this task suited to an agent, and how do we know it worked? Process owner
4. Governance Can we prove the agent behaved correctly? Security, compliance
5. People Who owns the agent the day after launch? Operations lead

The pillars are ordered by how often they break, not by importance. Pillar one causes most of the failures, which is why the rest of this site covers it in depth.

Why Most Agentforce Pilots Stall Before Production

A pilot is easy to start and hard to graduate. The pattern is consistent enough to name the blockers:

Blocker What it looks like in week one Where it surfaces later
Grounding on thin data Demo works on hand-picked records Generic answers on real records with empty Description fields
Unmeasured scope “The agent reads Case and Account” Nobody knows the fill rate of the fields it actually reads
PII in free text Nobody scanned Comments or Notes An SSN appears in a generated response
No success metric “See if it’s useful” No way to justify expanding, so the pilot ends quietly
No owner after launch The project team runs it Quality drifts, nobody notices, trust erodes

Each blocker has the same root: the pilot was scoped as a technology test rather than an operations change. Readiness assessment moves those questions to the front, where they cost days instead of quarters. For the data-specific version of this failure analysis, see Why Agentforce Agents Give Wrong Answers.

Pillar 1: Data Readiness

Agents ground their responses in the records they retrieve. A blank field is not neutral; the agent reads it as absence of fact and answers accordingly. This pillar decides whether the other four matter.

Measure the objects and fields in the agent’s scope across six dimensions, then compare each against a threshold:

Dimension DQS metric Working threshold
Completeness Completeness Rate 85% or higher on fields that ground answers
Consistency Conformance Rate 90% or higher on picklists and references
Validity Validity Rate 90% or higher on formatted fields
Timeliness Timeliness Rate (shown as Data Freshness) Within your defined window
Uniqueness Duplicate Rate Low and trending down
PII safety PII Exposure Rate Below 1% on text fields the agent reads

DQS rolls these into a single weighted score. Worked example: an org scans four dimensions before a pilot and gets Completeness 78, Validity 91, Consistency 84, and PII Safety 96. With default weights of 25, 20, 15, and 10, the calculation is (78 × 25) + (91 × 20) + (84 × 15) + (96 × 10) = 5,990, divided by the sum of those weights, 70. The result is 85.57. Dimensions you did not scan stay out of the denominator, so the score reflects what you actually measured rather than punishing you for gaps in coverage.

One caution on that number: a dimension with no data to measure scores 0, not 100. An empty result is not a clean result.

DQS detects and reports these issues; it does not cleanse, merge, or deduplicate records for you. Remediation happens through the Tasks and Chatter actions it raises on impacted records, and through the process fixes you make upstream. Scans run in batch, manually or on a schedule, which is the right cadence for readiness work: baseline now, re-measure after remediation, then monitor.

Go deeper: Agentforce Data Readiness Checklist for the item-by-item version of this pillar, and Salesforce Data Cleanup for Agentforce for object-level remediation.

Pillar 2: Org Configuration Readiness

An agent inherits the running user’s access and can only perform the actions you expose to it. Configuration readiness is about making that boundary deliberate.

Four things to settle before a pilot:

Permissions and visibility. An agent cannot read a field hidden by field-level security. Many “the agent doesn’t know that” reports turn out to be permission gaps rather than data gaps. Assign the agent user a permission set built for the use case, then verify what it can see against what the use case needs.

Actions the agent can take. Agents act through Flows, Apex, and standard actions. Every action you expose is a capability and a risk. List them, and for each one decide whether the agent runs it unattended or hands off to a person.

Technical debt in the org. Years of custom objects, overlapping automations, and abandoned fields make the agent’s context ambiguous. Three deprecated status fields with conflicting values teach the agent three versions of the truth.

Knowledge as a source. If the agent grounds on Knowledge articles, the articles need owners and review dates. Outdated documentation produces confidently wrong answers.

Worked example: a service team scopes an agent to read Case, Contact, and Knowledge, and to execute two actions (update Case status, create a follow-up Task). That is 3 objects and 2 actions to review, not the whole org. Scoping the review this way is what makes it finishable in a week.

Pillar 3: Use Case Readiness

Not every task suits an agent. The ones that do share three traits: they repeat often, they have a verifiable correct answer, and the cost of being wrong is recoverable.

Score a candidate use case on four questions:

  1. Volume. Does this happen enough that automating it changes a number someone tracks?
  2. Determinism. Can a reviewer look at the agent’s output and say whether it was right?
  3. Blast radius. If the agent is wrong, is the damage a bad answer, a bad record, or a bad refund?
  4. Escalation. What triggers a handoff to a person, and does that path exist today?

Define the success metric before launch, not after. “Resolution rate on tier-1 password-reset cases, measured weekly against the six weeks before launch” is a metric. “See if customers like it” is not. If you cannot name the number you will look at in 60 days, the use case is not ready.

Pillar 4: Governance, Security, and Compliance

This is the pillar competitors skip and regulators do not. Three questions decide it.

What sensitive data can the agent reach? PII accumulates in free-text fields through copy-paste, email-to-case, and integrations. A Social Security Number in a Case Comment is inside the agent’s context the moment it retrieves that record. Scan text fields in scope for patterns such as SSNs and credit card numbers before you connect an agent, and remediate confirmed matches. DQS runs entirely inside Salesforce, so records never leave the org during detection, and PII values appear as [REDACTED] in CSV exports rather than being copied into a file. See Agentforce and PII and PII Detection.

Where does the data go, and under which rules? GDPR, CCPA, HIPAA, and PCI DSS obligations do not pause for a pilot. Confirm your data residency position, what leaves the org for model processing, and what your Data Processing Agreement covers before an agent touches customer records.

Can you reconstruct a decision? When someone asks why the agent answered as it did, you need the retrieved context, the action taken, and the timestamp. Decide who reviews agent transcripts, how often, and what happens when a review fails.

Worked example: a scan of Case Description and Comments across 40,000 records returns 312 pattern matches, a PII Exposure Rate of 0.78%. That is below a 1% threshold but not zero, so the remediation task is finite: review 312 records, mask or delete confirmed matches, then rescan to confirm the rate.

Pillar 5: People and Ownership

An agent is a system that degrades. Data drifts, processes change, and the answers get worse slowly enough that nobody notices until trust is gone.

Name three roles before launch:

  • Agent owner. Accountable for the agent’s behavior in production, including the decision to pause it.
  • Data owner. Accountable for the quality metrics on the objects in scope. If nobody owns completeness, completeness does not improve. See Who Owns Data Quality in Salesforce.
  • Reviewer. Samples agent outputs on a schedule and reports on accuracy.

Then handle the human side: the support and sales teams whose work the agent changes need to know what it does, what it will not do, and how to escalate around it. An agent introduced without that conversation gets routed around.

What Drives Agentforce Cost

Agentforce is priced on consumption, so cost scales with how much the agent does rather than how many seats you buy. Readiness affects the bill directly, which is why this belongs in an assessment rather than a procurement conversation.

Four drivers to estimate before a pilot:

Driver Why it moves the number
Volume of agent actions Consumption is per action, so use case volume is the primary multiplier
Retries and failed answers Poor grounding produces re-asks, which are billable work with no outcome
Data platform footprint Unifying or ingesting data for grounding carries its own cost line
Scope creep Each new topic added to a live agent expands the action surface

Note the second row: bad data does not only produce bad answers, it produces more of them. An agent that cannot resolve a request on the first attempt burns consumption on the retry and the escalation. Fixing pillar one is a cost control, not only a quality control. Check current rates on Salesforce’s own pricing pages before you model a budget, because consumption pricing changes more often than license pricing.

The Agentforce Readiness Checklist

Twenty-five checkpoints, five per pillar. Score one point per item you can confirm with evidence rather than opinion. The total maps to the maturity model in the next section.

Data (5 points)

  • Every object and field the agent will read is listed and scoped
  • A baseline scan exists for each dimension in scope
  • Completeness Rate is 85% or higher on fields that ground answers
  • Conformance and Validity Rates are 90% or higher on picklists and formatted fields
  • PII Exposure Rate is below 1% on text fields in scope

Org configuration (5 points)

  • A dedicated permission set defines what the agent user can see
  • Field-level security has been verified against the use case, not assumed
  • Every action the agent can execute is documented and approved
  • Conflicting or deprecated fields in scope have been retired or excluded
  • Knowledge articles in scope have owners and review dates

Use case (5 points)

  • The first use case is high-volume and verifiable
  • A success metric and its baseline are recorded before launch
  • The escalation path to a person exists and has been tested
  • The blast radius of a wrong answer is understood and acceptable
  • A rollback or pause procedure is written down

Governance (5 points)

  • Text fields in scope have been scanned for sensitive data
  • Data residency and processing terms are confirmed for your region
  • Agent transcripts are retained and reviewable
  • A review cadence and failure threshold are agreed
  • Compliance has signed off on the post-remediation scan

People (5 points)

  • An agent owner is named
  • A data owner is named per dimension in scope
  • A reviewer samples outputs on a schedule
  • Affected teams have been briefed on scope and limits
  • A recurring scan schedule keeps the data metrics current

Five Levels of Agentforce Readiness

Add your checkpoints and find the band. The bands are deliberately unequal: the last two points are the hardest, because they are the operational ones.

Level Score State What unlocks the next level
1. Unaware 0-5 Licenses discussed, nothing measured Scope the objects and fields, run a baseline scan
2. Exploring 6-11 Baseline exists, gaps are known Remediate data, define one use case with a metric
3. Preparing 12-17 Data improving, use case chosen Close permissions, actions, and PII items
4. Pilot-ready 18-22 Safe to run a scoped pilot Assign ownership, set review cadence and monitoring
5. Production-ready 23-25 Safe to expand scope Repeat the assessment per new use case

Worked example: an org scores Data 2, Org configuration 4, Use case 3, Governance 2, and People 3. The total is 14, which places it at Level 3, Preparing. The two weakest pillars are Data and Governance, both at 2, so the next 30 days go to scanning and remediation rather than to agent configuration. The instinct at Level 3 is usually to start building the agent, because configuration feels like progress. It is the most common way to reach Level 4 on paper and Level 2 in production.

After You Score: A 30/60/90 Day Plan

Days 1-30: measure and remediate. Scope the objects and fields the agent will read. Run a baseline scan across the dimensions in scope, starting with PII because it is the only category that can block deployment outright. Fix the highest-impact, lowest-effort items, then rescan and compare against the baseline. In parallel, choose the first use case and write down its success metric.

Days 31-60: pilot narrowly. Build the agent for one use case, one team, one channel. Verify the permission set and the action list against what the agent actually needs. Test outputs against remediated data and confirm no sensitive values appear in generated responses. Keep the scope small enough that a bad week is recoverable.

Days 61-90: measure and decide. Compare the success metric against its pre-launch baseline. Review a sample of transcripts for accuracy. Re-run the readiness checklist, because the score changes once real usage exposes gaps. Then make an explicit decision: expand, iterate, or stop. A pilot without a decision date becomes a permanent pilot.

Set a recurring scan schedule before day 90, not after. Data quality degrades as users create new records, so an org that passed in month one drifts by month three unless something is watching. See Running Scans for scheduling.

Frequently Asked Questions

What is Agentforce readiness?

Agentforce readiness is the state in which your Salesforce org can run AI agents in production reliably, safely, and at a predictable cost. It covers five pillars: the quality of the data agents read, the configuration of the org they act in, the use cases they are assigned, the governance around them, and the people who own them after launch. Readiness is measured, not assumed.

Do I need Data Cloud to use Agentforce?

Not for every use case. An agent can ground its answers in the Salesforce records and Knowledge articles it already has access to. Data Cloud becomes necessary when the agent needs a unified customer profile across systems, or needs to retrieve unstructured content at scale. Decide this per use case, because it changes both your architecture and your cost model.

How do I get my data ready for AI agents?

Scope the objects and fields the agent will read, measure them across completeness, consistency, validity, timeliness, uniqueness, and PII exposure, then remediate against defined thresholds before deployment. Measurement comes first: until you have a baseline rate per dimension, data readiness is an opinion rather than a number.

How long does it take to become Agentforce ready?

For a single narrow use case, a realistic path is 90 days: 30 days to measure and remediate the data the agent will read, 30 days to run a scoped pilot, and 30 days to measure results and decide whether to expand. Orgs with heavy technical debt or unresolved PII exposure in text fields take longer, because those items block deployment rather than slow it down.

Next Steps

Readiness is a number, not a feeling. The fastest way to find your starting point is to measure the pillar that breaks most often.