On this page (11)
Your Salesforce org is ready for Agentforce when the agent will have clean data to work from, permissions that limit what it can see and do, trusted knowledge to ground its answers, no conflicting automation to trip over, a way to evaluate its output, and a named owner. Most orgs need some preparation on at least two of those. This checklist covers what to review before you build.
1. Data quality
- Duplicate rate on accounts, contacts and cases is known and falling.
- The fields the agent will read are consistently filled and mean the same thing to everyone.
- Stale records are archived or clearly flagged.
- Data the agent needs from other systems is either integrated or deliberately out of scope.
2. Permissions and security
- The agent’s access follows least privilege: only the objects, fields and actions its use case needs.
- Sharing rules are understood; an agent will expose any record its permissions allow.
- Sensitive fields are identified and excluded where appropriate.
- Actions that change records or contact customers require a human step until results are proven.
3. Knowledge and grounding
Service agents are only as good as the knowledge behind them. For a biotech company, an AI agent grounded in 19 well-maintained knowledge articles produced send-ready draft responses for 30% of question-type cases. Before building, check that articles are current, have owners, and cover the questions customers actually ask.
4. Automation conflicts
Old workflow rules, Process Builder and overlapping Flows can fire when an agent updates a record, producing results nobody intended. Inventory the automation on every object the agent will touch and consolidate it first.
5. Evaluation
- A set of real historical cases or requests to test the agent against.
- Clear criteria for a good answer or action, agreed by the business.
- A way to review a sample of live agent output every week at first.
- A threshold for widening the agent’s scope, and one for pulling it back.
6. Ownership and governance
- A business owner accountable for what the agent does.
- A technical owner for its configuration, subagents (formerly topics) and actions.
- A change process for prompts, actions and knowledge.
- A plan to tell customers or employees when they are interacting with AI, where required.
Start small
The best first use case has high volume, clear answers and low risk: drafting responses for common service questions, summarizing records, or triaging inbound leads. For a business lender triaging 24,000 leads a month, the right first step was a lead-prioritization framework and a Data 360 (formerly Data Cloud) architecture, not a fully autonomous agent.
How do you score your org’s readiness?
Rate each area from the checklist as ready, partly ready or not ready. Build only when no area scores not ready for the chosen use case.
| Area | Ready | Partly ready | Not ready |
|---|---|---|---|
| Data | Key fields filled and trusted | Gaps known and being fixed | Nobody knows the duplicate or completion rate |
| Permissions | Agent user designed with least privilege | Profiles exist but are broad | Agent would run with admin access |
| Knowledge | Owned, current and covering top questions | Current but with coverage gaps | Scattered across files and inboxes |
| Automation | Documented and consolidated | Inventoried but overlapping | Unknown rules fire on key objects |
| Evaluation | Test set and success criteria agreed | Test cases exist, criteria unclear | No way to judge a good answer |
| Ownership | Business and technical owners named | One owner named | No owner |
How do you check knowledge quality before grounding an agent?
Compare your articles with the questions customers actually ask, then fix the gaps. An agent cannot give a good answer that no article contains.
- Pull recent cases and group them by question; check each group has a matching article.
- Flag articles past their review date or with no named owner.
- Remove duplicates and contradictions, so two articles never give different answers.
- Write articles in plain steps, with one topic per article.
- Mark internal-only content so it cannot reach a customer-facing answer.
- Ask a frontline agent to read a sample and confirm the steps still work.
What steps does a permission review include?
Build the agent’s access from nothing, rather than copying an existing user. Then test what it can see before it goes live.
- Create a dedicated user and permission set for the agent.
- List every object, field and action the use case needs, and grant only those.
- Check sharing: log in as the agent user and try to open records outside its scope.
- Review field-level security on personal, financial and health data.
- Record who approved the access and set a date to review it again.
How do you choose the pilot?
Pick a use case that is frequent, measurable and easy to reverse. Score the candidates side by side before committing. Two or three candidates are usually enough to compare.
- Volume: enough requests each week to learn from quickly.
- Clarity: most answers already exist in approved knowledge or records.
- Risk: a wrong answer is easy to catch and correct.
- Measure: a baseline exists, such as handling time or response quality.
- Sponsor: a team lead who wants it and will review the output.
