Enterprise AI Summit 2026Register now

Business Workflows

Agentforce Implementation Checklist

An Agentforce implementation checklist: use case, data readiness, subagent design, guardrails, testing, rollout, and what Agentforce consulting should deliver.

By · 5 minute read

Prepared with dotSolved Editorial. Published

Why does an Agentforce implementation start with use-case selection and a success definition?

Because an agent without an agreed job and measure cannot pass or fail. Before any Agentforce consulting engagement moves into build, write down the one workflow the agent will own, the population it serves and the number that proves it worked. A service agent handling order status and return requests is a clearer first scope than a general assistant for every customer question.

Pick a workflow with high volume, documented policies and a human fallback, then define success in a measure your operations lead already tracks, such as resolution without hand-off. Record the baseline now. Salesforce's own planning module asks how success is measured and when to escalate to a live service rep before anything is built, and that order is right.

Is your Salesforce data ready to ground an agent?

It is ready when the agent can retrieve correct, permitted context for every subagent in scope. Agentforce grounds answers through Data 360, formerly Data Cloud. An Agentforce Data Library is the quick path: Salesforce builds the vector store, search index and retriever for unstructured sources such as knowledge articles, one data source per library. Structured records, zero-copy lake data and unified profiles need the full Data 360 setup with ensemble retrievers or data graphs.

Audit permissions before grounding anything. Secure data retrieval in the Trust Layer keeps the permissions already in Salesforce, so the agent sees only what its running user can see. Review that user's profile, permission sets, field-level security and sharing rules against the fields each subagent needs. Clean the knowledge base too: an agent grounded on a stale return policy will state it confidently.

Related: Explore Agentforce implementation and Salesforce AI agents

How do you design subagents, actions and instructions in Agentforce Builder?

Design each subagent as one job with explicit boundaries, then give it only the actions that job needs. Salesforce now calls topics subagents; older documentation mixes the terms. A subagent carries a name and description the reasoning engine uses for routing, a scope, and natural-language instructions. Actions are the tools: flows, Apex, prompt templates, MuleSoft APIs and external services, plus standard actions such as Answer Questions with Knowledge.

Write instructions the way you would brief a new hire who cannot ask questions: which fields to confirm before acting, which currency and date format to use, and when to ask the customer to confirm a refund amount. Instructions are not deterministic, so put control logic in Agent Script or actions and keep instructions for behavior. Keep a change log of every instruction edit, because testing will rewrite them repeatedly.

Which guardrails keep the agent inside its lane?

Two layers: the Einstein Trust Layer's platform controls and the escalation rules you write yourself. The Trust Layer provides secure data retrieval, dynamic grounding, zero data retention with the LLM, toxicity detection and an audit trail that tracks a prompt through each step. Verify each one in your org: Salesforce's Trailhead module on the Trust Layer states that data masking for LLMs is currently disabled for agents, so plan for it if sensitive data must never reach the model.

Escalation is a design decision. Define the triggers that hand the conversation to a person: a request outside every subagent, a refund above a threshold, a frustrated customer, or any regulated subject. List the paths the agent must never pursue; the planning module asks for these too. Decide what context travels with the hand-off. Test these triggers deliberately, because an agent that never escalates is a warning sign.

How do you test an agent before it meets real users?

Test in a sandbox with a stored suite you can rerun after every change. Agentforce Testing Center stores test cases as rows of utterance, expected subagent, expected actions and expected response, uploaded from the CSV template or generated by AI from selected subagents and actions. Include negative cases: wrong inputs, out-of-scope requests and prompts that try to pull the agent off its instructions.

Build reference conversations with the people who do the job today. Ask a support lead for the twenty most common requests and the five that go wrong most often, then turn each into a test case with the response they would accept. Rerun the suite whenever instructions, subagents, actions or guardrails change. Running tests consumes requests and credits and can modify CRM data, so keep the Testing Center in the sandbox.

How do you deploy, monitor and keep Flex Credit consumption predictable?

Deploy through your normal Salesforce release path with a named owner, a pilot population and a rollback plan. Change management decides whether it lands: tell reps and managers what the agent handles, how escalations reach them and where to report a wrong answer. Start with a slice of traffic, review transcripts daily for two weeks, then widen scope when the success measure holds.

Monitor with Agentforce Observability: session tracing, quality scores, near real-time alerts and credit consumption per agent. Agentforce is sold per action, drawing Flex Credits from a pooled balance, or per conversation for customer-facing agents, plus per-user licenses. Flex Credits and Conversations are not supported in the same org, and unused Flex Credits do not roll over, so forecast action volume from pilot data and watch the Digital Wallet.

What should an Agentforce consulting partner deliver at each phase?

Documents you could hand to a second partner. In scoping: a one-page use-case charter with the success measure and baseline. In data readiness: a permission and grounding audit with named gaps. In design: the subagent, action and instruction specification with its change log. In guardrails: the escalation triggers and verified Trust Layer settings. In testing: the suite itself, with pass rates by subagent.

In deployment: the release plan, the pilot results and the training material reps actually used. In operation: an Observability dashboard, a credit forecast and a monthly tuning cadence with a defined exit. Ask any candidate partner to show these from past work. dotSolved's Salesforce team works to this checklist. To walk through it against your first agent, Book a Demo.

Primary references and further reading

The recommendations above are editorial guidance. These primary references explain the relevant technology or risk framework; they do not certify a particular implementation.

Continue your evaluation

Explore the work of Sravan Modugula, Chief Data & AI Officer and creator of Nexatron, or browse all resources.