Salesforce Agentforce 360 for Public Sector AP common mistakes
Salesforce Agentforce 360 for Public Sector AP · Understand the traps and how to avoid them.
Describing the agent as a keyword/intent chatbot - writing it as 'when the user says X, reply Y' and mapping every FAQ entry to its own branch instead of defining a small set of business-intent topics with actions.
Candidates carry over Einstein Bots / classic NLU habits, where utterances map to scripted dialogs, and they under-estimate that Atlas plans over topics and actions rather than following a fixed decision tree.
What to do instead
Re-answer fundamentals in agentic terms: a topic is a scope boundary with a description the classifier reasons over, actions are the invocable capabilities (Flow, Apex, prompt template, API), and the planner chooses actions at runtime. Practise writing topic descriptions and action descriptions, not dialogue trees.
Assuming any user who can open the agent can use it - skipping the licensing and access model (permission set licenses, agent access, and the running user's permissions) when predicting agent behaviour.
Configuration works in the builder under an admin context, so candidates never see the access failures that appear for a licensing-limited employee or a guest/Experience Cloud user.
What to do instead
For each persona, trace the chain: does the user hold the required permission set license, is the agent assigned to them, and does their profile/perm set allow the objects and fields the action touches. Test in a session as that persona, not as admin.
Building one oversized topic that covers the whole department, or several topics with overlapping descriptions (e.g., three topics all named around 'case status'), then blaming the model when routing is wrong.
Topics are named after org objects or team names rather than citizen intent, and the descriptions restate the label instead of describing what the user is trying to accomplish.
What to do instead
One topic per distinct citizen intent; write the description in the user's words with a couple of example requests and an explicit statement of what is out of scope; merge or delete topics whose descriptions a colleague cannot tell apart on first read, and verify with utterance tests.
Defining an action whose required inputs the agent can never supply - a mandatory record ID, an internal picklist code, or a free-text parameter with no description - then reporting that the action 'sometimes fails'.
Candidates design actions from the Flow's perspective (it already has the ID) rather than from the planner's perspective (it only has the conversation).
What to do instead
Design action inputs as collectable or derivable: describe every input and output, mark inputs optional where a lookup is possible, add a preliminary lookup action to resolve the record, and put explicit confirm-before-invoke instructions in the topic so the agent gathers values before calling.
Assuming the agent answers from Salesforce records out of the box, or pointing it at a knowledge source and expecting answers, without configuring grounding (data ingestion, data model mapping, search index/retriever) and validating retrieval.
The builder's chat window gives convincing demo answers from the model's own knowledge, so the absence of a retriever is invisible until the agent is asked about a specific citizen's record.
What to do instead
Learn the grounding path end to end: which objects/fields feed the structured side, which documents feed the unstructured side, how chunking and the search index affect recall, and how citations are returned. Test with questions whose answers only exist in the indexed data.
Indexing raw public sector data without a data-quality and permission pass - duplicate Individual/person records, unmasked national ID or health fields, and an indexing identity whose field access differs from the runtime user's.
Grounding is treated as a plumbing task rather than a data governance task, so duplicates dilute retrieval and sensitive fields leak into the index or into prompts.
What to do instead
Deduplicate and standardise person/account records before ingestion; decide field by field what may enter the index and mask the rest; align the indexing user's and the agent's field-level access; re-check the index after any data model or permission change.
Modelling a permit, licence, inspection, grant, or benefit application as a plain Case with custom fields instead of using the Public Sector Solutions objects, then discovering the agent cannot reason over the citizen journey.
Candidates default to Service Cloud patterns they already know and have not mapped the PSS data model (Individual, Individual Application, Application Intake, Program, Benefit, Benefit Assignment, Business License, Permit, Inspection Task, Violation) to citizen-facing intents.
What to do instead
Build a one-page map of PSS objects to citizen scenarios and to the actions an agent would need for each; where the org is genuinely Case-centric, state that choice explicitly rather than by default; confirm which PSS and platform features are available in the Government Cloud org before designing around them.
Designing a high-stakes scenario - eligibility determination, benefit award, enforcement action - as a fully autonomous agent, or conversely refusing any autonomy at all.
The demo framing ('the agent handles it end to end') collides with public sector due-process and auditability expectations, and candidates have not practised the middle ground of agent-assists-human.
What to do instead
Classify each use case by consequence of error: the agent may triage, gather documents, explain status, and draft; adjudication and adverse decisions escalate to a named human with a recorded rationale. Write the escalation path and the decision-authority boundary into the topic instructions, and be able to justify the split.
Testing by chatting with the agent manually in the builder a few times, with no saved test suite, no out-of-scope or adversarial cases, and no re-run after editing a topic or action description.
Manual spot checks feel sufficient because the failures are intermittent - a topic-description tweak silently reroutes utterances that used to work, and the candidate never sees it before the exam scenario or the deployment.
What to do instead
Build expectation-based test cases from real citizen utterances: expected topic, expected action, expected escalation. Include negative cases (out of scope, ambiguous, incomplete information), prompt-injection attempts, and multi-turn cases. Re-run the full suite after any change to topics, actions, or grounding sources, and treat it as regression, not a one-off check.
Assuming Trust Layer protections are universal defaults - that zero data retention, toxicity detection, and PII masking apply identically to every model, channel, and action - or enabling masking without verifying what the action actually receives.
The Trust Layer is often studied as a feature list rather than as configuration with scope and exceptions, so candidates cannot tell which guarantee holds where, or notice that masking on the prompt does not automatically sanitise values passed into an Apex/Flow action.
What to do instead
For each agent, write down the model and channel in use, confirm the retention behaviour that applies, list the fields masked and at which boundary (prompt, response, action input), and verify with a real payload plus the audit/feedback records. Treat the audit trail as the evidence, not the documentation.