Salesforce Agentforce Specialist common mistakes
Salesforce Agentforce Specialist · Understand the traps and how to avoid them.
Building the agent as one long instruction prompt plus a single catch-all topic, then trying to force accuracy by adding more sentences to the instructions each time a user request fails.
Candidates carry over a generic prompt-engineering mental model (one model, one prompt) and don't realize Agentforce behavior is driven by topics, actions, and the Atlas reasoning engine's planning, not prompt text volume.
What to do instead
Design a topic map first: each topic gets a distinct description and scope, and each user intent maps to a concrete action (Flow, Apex, prompt template, or standard action). Keep the agent's instructions limited to persona, tone, and guardrails; move capability logic into topics and actions.
Stating that the Atlas reasoning engine stores knowledge, writes the response text, and enforces security, then designing the solution as if no actions or permissions are needed.
Confusing Atlas (intent detection, topic selection, planning, action invocation, response grounding in retrieved content) with the underlying LLM (natural-language generation) and with the platform's sharing/FLS layer.
What to do instead
Describe the division of labor explicitly: Atlas plans and selects topics/actions; the LLM drafts language; retrieval actions supply grounded content; the platform enforces record access. Then ensure every needed capability exists as an action with a properly permissioned running user.
Uploading a folder of raw PDFs, scanned policies, and outdated help articles into a knowledge source and blaming the agent when answers are wrong or cite the wrong document.
Treating RAG ingestion as 'dump and go' instead of curating content: duplicated, contradictory, scanned-image, or poorly structured documents degrade retrieval before the model ever sees them.
What to do instead
Curate before ingesting: remove duplicates and superseded versions, keep one authoritative source per topic, prefer structured/well-headed text, split long documents into coherent sections, and add retrievable metadata. Then verify by running representative questions and checking which chunks are retrieved.
Assuming that once the agent is connected to Salesforce, it can read any object or field a user asks about, and skipping the work of defining how record data reaches the agent.
Overestimating implicit data access - grounding for record-level data is delivered through actions (Flow/Apex/retriever), and results are still filtered by the running user's sharing rules and field-level security.
What to do instead
Design explicit retrieval actions per data need with defined inputs (e.g., record ID, search term) and outputs. Test as the actual running user to confirm sharing rules and FLS return the intended rows and fields, and handle 'no results' explicitly in the action output.
Writing topics like 'Handle customer questions', 'Help with orders', and 'Support' that overlap heavily, then expecting the classifier to route correctly.
Topic selection depends on the topic descriptions being distinguishable; overlapping scope forces the planner to guess and produces inconsistent routing that looks like random flakiness.
What to do instead
Make topics mutually exclusive with concrete, differentiated descriptions that name the intents, entities, and boundaries (including what the topic does NOT cover). Validate with ambiguous utterances and add disambiguation instructions or an explicit 'clarify' path when confidence is low.
Registering an action named 'doStuff' with inputs labelled 'input1'/'input2' and no description, then debugging why the agent asks the wrong question or passes the wrong value.
Action and input descriptions are the planner's only specification for when to call an action and what to fill in; vague metadata makes selection and slot-filling guesses rather than deterministic.
What to do instead
Write action descriptions in user-intent language ('Use when a customer asks to reschedule a delivery'), mark required vs optional inputs, describe each input's expected format, and supply example utterances. Re-test with paraphrases to confirm the planner collects the right slots before invoking.
Validating the agent only by typing a handful of well-formed happy-path questions into the conversation preview, then declaring it ready because those responses looked good.
Demo-style testing never exercises the failure surface: ambiguous requests, out-of-scope questions, missing data, adversarial phrasing, and multi-turn corrections are where routing and grounding actually break.
What to do instead
Build an explicit test set covering each topic, each action, ambiguous/overlapping utterances, out-of-scope requests, and expected escalation. Include assertions on expected topic, action invoked, and key response content; run the full set after every change rather than sampling one prompt.
Shipping to a channel after a successful preview, then making no further changes and not reviewing conversation logs, so quality quietly degrades as new products, policies, and knowledge sources appear.
Treating deployment as the finish line instead of the start of an optimization loop; without reviewing real sessions and re-running regression tests, drift, new intents, and stale knowledge go undetected.
What to do instead
Establish a post-launch cadence: review session transcripts and escalation/deflection metrics, tag unmatched or escalated utterances, promote recurring gaps into new topics/actions or updated sources, and re-run the regression suite plus a staged rollout before each change.
Assigning the agent an admin-level or broadly permissioned user (or leaving a guest/community user with wide access) because it made the demo work without troubleshooting access errors.
Choosing the fastest path past 'no results' errors swaps a permissions problem for a data-exposure problem; agents act with the running user's access, so over-privilege means over-sharing customer data.
What to do instead
Use a dedicated least-privilege running user scoped to exactly the objects, fields, and records the topics require, and verify behavior for guest/external channels separately. Fix access gaps by adjusting sharing/FLS deliberately rather than by escalating the user's profile.
Answering 'the Einstein Trust Layer handles that' for PII masking, toxic-content blocking, and audit trails, without configuring any of those settings or checking what is actually enabled in the org.
Trust Layer is a set of capabilities that must be enabled and tuned (masking rules, toxicity thresholds, audit and feedback data retention, zero-retention with the model provider), not a blanket default that covers every channel and field.
What to do instead
Enumerate each Trust Layer control, confirm it is enabled for the specific channels in scope, define which fields are masked before the prompt is sent, set toxicity thresholds, verify audit/feedback logging and retention, and record this configuration in the deployment checklist with a re-check after any channel or model change.