Most Agentforce implementations fail at scoping — not at configuration. Here are the 12 questions every implementation team must answer before touching Agent Builder.
We get the same call about once a month. A Salesforce admin or a VP of Technology rings us and says something like: “We bought Agentforce licences six months ago and we still haven't deployed anything.” Or worse: “We built something, it went live, and now the agents are doing things we didn't intend.”
In almost every case, the root cause is the same: the team skipped scoping. They looked at Agent Builder, saw the drag-and-drop interface, and assumed the hard part was the tool. It isn't. The hard part is deciding — with precision — what the agent should do, what data it needs, what it should never do, and how you'll know if it's working.
The Agentforce implementations that succeed consistently share one trait: the team spent two to three days on structured scoping before touching a keyboard. They answered a set of fundamental questions about business logic, data access, failure modes, and success criteria. Only then did they open Agent Builder.
This isn't a process formality. The answers to these questions are what you put directly into your Topics and Instructions. If you don't know them, your Instructions will be vague, your Topics will be over-scoped, and your agent will start behaving unpredictably the moment it encounters an edge case.
Work through these in order. Don't skip to Agent Builder until you have clear, documented answers to all twelve. If you can't answer a question, that's a scoping blocker — resolve it before you build.
Not “handle customer service” — that's a department, not a job. Not “help with sales” — that's a team function. The job should be expressible in one sentence: “Respond to inbound loan status queries from authenticated customers and return current loan balance, payment due date, and next scheduled payment amount.” If you need two sentences, you're scoping two agents. Build one first.
List every object the agent will touch. For each, specify whether it needs read, write, or both. This drives your permission set design and determines which Actions you'll need to build. An agent that can read but accidentally writes (or vice versa) is a production incident waiting to happen.
Inbound message (chat, email, SMS), record change (new Case, updated Opportunity), scheduled trigger, or user-invoked from a UI? The trigger determines your channel configuration, your activation condition in the Topic, and how context is passed to the agent at the start of the conversation. Each trigger type has different data available at the point of invocation.
Define the metric before you build. Autonomous resolution rate? Average handle time? CSAT score? Escalation rate? You need a number, a baseline, and a target — not a vague sense that “it should be better.” This is also what your UAT sign-off will be based on. No measurement definition means no objective pass/fail for go-live.
This is as important as what it should do. The “never do” list goes directly into your Instructions as hard constraints. Typical examples: never make commitments about refund timelines, never quote prices, never discuss competitor products, never access account data without authentication, never process transactions above $X without human approval. Write these down explicitly.
ERP inventory data, EHR patient records, payment processor transaction history, logistics tracking systems — if your agent needs data that lives outside Salesforce, you need an integration strategy before you build. The options are MuleSoft API connectors, direct Apex HTTP callouts, or MCP server integrations (Agentforce 3+). Each has different latency, failure mode, and governance implications.
Every agent needs a defined escalation path. Name the queue, the team, or the specific role. Specify what context the agent should pass when escalating — case summary, sentiment flag, customer tier, prior interaction history. An agent that escalates with “I couldn't help” and no context is worse than no agent at all, because it's added a frustrating step to a customer who already needs a human.
Agent Builder doesn't have automatic retry logic for failed Actions. If your external API returns a 503, what does the agent say? If the agent exceeds its context window mid-conversation, what happens to the customer? Design these failure states explicitly. A well-designed fallback degrades gracefully. An undesigned fallback either surfaces a raw error or silently drops the conversation.
Agentforce agents reason over the data they're given access to. If your Account records have 40% blank fields, your Contact data is three years stale, or your Knowledge base hasn't been updated since last year's product refresh — your agent will either hallucinate, give outdated answers, or escalate everything. Data readiness isn't a nice-to-have; it's a hard prerequisite.
PII handling (GDPR, CCPA), audit trail requirements, financial advice restrictions (FCA, SEC), healthcare data rules (HIPAA) — these drive your Einstein Trust Layer configuration, your audit logging setup, and in some cases your entire architecture. Financial services orgs especially: the agent must not give personalised financial advice. Healthcare: PHI cannot be passed to the LLM in identifiable form. Map these before you build.
Name the UAT owner. This is the person who will run test scenarios, sign off on edge case behaviour, and formally approve go-live. Without a named UAT owner, UAT either doesn't happen or everyone reviews it but nobody owns the decision. Both situations lead to a go-live with known issues and no accountability.
Set a 30-day threshold before go-live. Not a vague aspiration — a number: “55% autonomous resolution rate on loan status queries with CSAT ≥ 4.2/5.” This is your pilot pass/fail criterion. If you hit it, you expand to the next use case. If you don't, you investigate the failure modes before scaling. This framing also makes the business case for a second agent dramatically easier.
Here's how the scoping questions map directly to the three core components you'll configure in Agent Builder:
Topics are defined by questions 1, 3, and 5. Question 1 gives you the Topic name and classification label. Question 3 defines your Activation Condition — the specific phrasing or context that tells Atlas to route to this Topic. Question 5 becomes your out-of-scope guard: you'll add explicit language to the Topic telling the agent what categories of request it should decline.
Actions are driven by questions 2 and 6. Each object that needs read access becomes a Get [Object] Action. Each write becomes an Update or Create Action. External data needs (question 6) become Apex or MuleSoft-backed Actions with proper error handling. Question 8 (fallback design) shapes how each Action handles failure — specifically what the Action returns when the upstream system is unavailable.
Instructions are the most detailed artefact and draw from questions 4, 5, 7, 8, and 10. Your success metrics (question 4) shape how you phrase the agent's goal in the Instructions preamble. Your “never do” list (question 5) goes in verbatim. Your escalation path (question 7) is written as an explicit instruction: “If you cannot resolve the issue within two exchanges, use the Escalate to Human Action and pass [these specific fields] as context.” Compliance constraints (question 10) are written as hard stops with exact language.
Questions 9 (data readiness) and 11 (UAT owner) don't map to Agent Builder directly — they're prerequisites. Data readiness must be confirmed before you create any Actions that depend on that data. The UAT owner must be identified before you schedule the test phase.
Talk to our team. We run structured scoping workshops that take you from “we have licences” to a fully signed-off agent design in two days.
The most common mistake is treating Agentforce as a general-purpose assistant for an entire department. A “Service Cloud agent” that handles returns, complaints, billing queries, technical support, and appointment booking is five agents masquerading as one. Each job requires different data access, different escalation paths, and different compliance constraints. Mashing them together produces an agent that handles simple cases inconsistently and fails on complex ones silently.
We've seen production agents that respond to any query they can't handle with the LLM's default refusal language — cold, unhelpful, and confusing for the customer. Fallback design is not an edge case. Depending on your use case, 20–35% of interactions will hit a boundary condition in the first 90 days. Plan for this explicitly or you'll be firefighting post-launch.
Discovery call: “We want the agent to give customers their order status.” Build call: “Oh, order data is in SAP, not Salesforce.” This is a 2-week detour for an integration that should have been identified in scoping. We now ask about data location on the first call before any scoping work starts.
Without explicit constraints, the LLM will attempt to be helpful in ways the business can't authorise. We've seen agents promise specific refund timelines (which the business can't guarantee), quote prices that are out of date, and give what amounts to personalised financial advice. The “never do” list isn't just about safety — it's about keeping the agent within the scope of what it's actually authorised to say.
Download this checklist and block two days on the calendar with your team — a Salesforce admin, a business process owner, and ideally whoever owns the system that holds the relevant data. Work through each question and document the answers together. Disagreements on the answers are a good sign: they surface ambiguities that would have become production defects.
Once you have clear answers to all twelve questions, you're ready to start your org audit. Check your Data Cloud enablement status, your Einstein Trust Layer configuration, and the current state of the objects your agent will need to touch. If you find gaps, you now know what to fix before building.
If your org is complex — multiple clouds, legacy integrations, or a large volume of existing configuration — consider starting with a structured readiness assessment. Our Agentforce Strategy & Readiness engagement covers exactly this: a full org audit, use case prioritisation, and a deployment roadmap — delivered in 10 days.
For a deeper technical understanding of what happens once you do start building — how Atlas actually reasons, how Topics get selected, and how Actions are executed — read our Atlas Reasoning Engine breakdown.
A technical breakdown of hybrid reasoning, topic classification, and action execution — with real org examples.
12 min readCase StudyStep-by-step walkthrough of a financial services deployment — architecture, MuleSoft integration, and guardrail configuration.
15 min read