Salesforce Agentforce 360 for Public Sector AP cheat sheet

An Agentforce agent is assembled from a large language model, the Atlas Reasoning Engine, a set of topics, and the actions those topics may invoke.

The reasoning loop runs: receive request, match a topic, plan and sequence actions, execute them, generate a grounded response, then respond or hand off.

The Atlas Reasoning Engine owns topic selection, action planning, and escalation decisions; the LLM supplies language understanding and generation rather than task routing.

Assistive agents sit inside a workflow or channel and respond to a person; autonomous agents are triggered by events, schedules, or record changes and complete work without a live prompt.

Every action executes under the Einstein Agent user's permissions and sharing rules, so the agent can never read or write more than that user context allows.

Agentforce surfaces include messaging channels, Experience Cloud sites, and Service Cloud consoles; the same topic and action definitions are reused across surfaces.

Human handoff routes a conversation or work item through Omni-Channel and passes conversation context so the representative does not restart discovery.

Agent Builder covers declarative configuration of topics, actions, and instructions; the pro-code Agent Script layer is chosen when exact step order must be enforced.

Commercial packaging separates per-conversation Agentforce Service entitlements from the Einstein Agent user license that provides the runtime execution identity.

A topic contains a name, a classification description, a scope statement, topic-level instructions, and the list of actions the agent may call for that job.

The classification description is what the reasoning engine compares a request against; distinct vocabulary and representative requests raise topic-selection accuracy and overlapping wording causes misroutes.

Scope statements declare what a topic must not handle, so out-of-scope requests produce a refusal or a handoff instead of a speculative answer.

Supported action types are Flow, Apex, prompt template, standard actions, and external API or MuleSoft integrations described by an OpenAPI specification.

Each action declares typed inputs and outputs; the agent binds inputs from conversation context, from variables, or from the output of a preceding action in the same plan.

If the Einstein Agent user lacks object and field permissions or record access, the action fails or returns incomplete data even when the definition is correct.

Agent-level instructions set persona, tone, formatting, and universal guardrails for all topics; topic-level instructions specialize behavior for one job and cannot override platform enforcement.

Agent Script introduces typed variables, conditional branches, and explicit instruction blocks so an agent follows deterministic sequencing rather than relying entirely on model planning.

Conversation preview in the builder shows the selected topic and executed actions for a test utterance, exposing misroutes before the agent is activated.

Grounding is retrieval augmented generation: relevant records or document chunks are retrieved first and inserted into the prompt, so answers derive from enterprise data instead of model training.

Structured grounding retrieves records through Flow or Data 360 query actions; the returned fields must be permission-visible to the agent's running user or they are omitted.

Unstructured grounding ingests files into the Data Library, splits them into chunks, embeds the chunks into a vector index, and retrieves top-matching passages per question.

Chunk size is a trade-off: larger chunks preserve context but dilute similarity scores and consume prompt space; smaller chunks sharpen matching but can split a clause from its conditions.

The ingestion path is data stream to data lake object, then mapping and transformation into data model objects that queries and actions actually read.

Identity resolution reconciles records across sources into one unified profile, which is what makes a single constituent or household view answerable by an agent.

Data spaces partition data and users so retrieval returns only records belonging to the relevant agency or program, which is the practical mechanism for permission-aware grounding.

Calculated insights precompute metrics with SQL-like definitions over data model objects, so time-sensitive answers such as caseload counts do not require raw record queries.

Freshness is a design constraint: streaming ingestion supports near-real-time answers while scheduled batch refreshes can return stale status for fast-moving records.

Salesforce Government Cloud provides FedRAMP Moderate and High authorizations; Government Cloud Plus adds DoD Impact Levels 2, 4, and 5 for the most sensitive workloads.

Government Cloud Plus runs in dedicated US regions, so any workload holding data subject to DoD impact level or strict US residency requirements belongs there rather than in commercial instances.

Public Sector Solutions delivers packaged modules for Licensing and Permitting, Inspection Management, Grant Management, Benefit Management, Emergency Response Management, and constituent case management.

OmniStudio supplies OmniScripts for guided multi-step intake, FlexCards for constituent summary views, and Integration Procedures for multi-system data assembly without custom code.

The Business Rules Engine evaluates declarative eligibility and determination logic and returns a decision that flows, OmniScripts, and agent actions consume downstream.

Document Generation produces permit decisions, inspection notices, and grant award letters from templates populated with record data at the point of determination.

A 311 service request is modeled as a case, routed by Omni-Channel to the responsible department, and tracked through closure so status inquiries can be answered from the record.

High-value agent use cases are status and eligibility inquiries, inspection scheduling, application intake, and document checklist guidance; final statutory determinations remain with authorized staff.

Document each agent capability against the governing program rule, because an agent answering from retrieved data inherits the accuracy of the underlying record and rule set.

The Einstein Trust Layer masks sensitive fields before transmission, prevents the model provider from retaining prompts, detects toxic content, and retains prompt and response records for audit.

Zero data retention means the provider stores neither prompts nor completions and cannot train on customer data; a bring-your-own-model deployment shifts retention responsibility to the customer.

Dynamic grounding restricts retrieval to records the running user can access, so the trust boundary is the Einstein Agent user's permission set plus sharing rules.

Apex and Flow actions inherit their sharing behavior from code and flow configuration; without explicit sharing enforcement an action can expose records the user should not see.

Prompt injection defenses combine trust-layer input scanning with the rule that no secret, credential, or internal threshold is ever placed in agent-level or topic instructions.

The testing workflow is: define test cases with expected topic and expected actions, run them in batches, compare actual routing and outputs, and only then activate the agent version.

Test coverage must include out-of-scope utterances, ambiguous requests that could match two topics, and handoff triggers, since these are the paths where routing failures appear.

Audit and feedback data from the trust layer, plus platform Event Monitoring, provide the evidence trail for investigating what an agent was asked and what it returned.

Governance controls are least-privilege permission sets per agent, sandbox validation before deployment, versioned promotion through change sets or DevOps, and Shield encryption or field audit trail on regulated fields.