The Agentforce setup checklist

The decision has been made: your company is deploying Agentforce. Someone has a launch date in mind, someone else has a use case, and you — the admin or architect — are the person who has to make the org ready for it. This is the guide for that job. It is not a build tutorial; we’ve written that separately. It’s not a deployment guide either; that one exists too. This is the pass that comes before both: the org-level readiness checklist that decides whether the build goes smoothly or stalls on a provisioning surprise in week two.

That ordering matters because of a pattern we see repeatedly. Agentforce projects rarely stall on the AI. They stall on the org: a Data 360 instance that was never provisioned, an agent user with silently missing permissions, a knowledge base nobody audited, a channel that needed licensing nobody checked. Every one of those is discoverable before the project starts — if someone runs the checklist. Here it is, in the order we run it.

Phase 1: Licensing, edition, and the credit conversation

Start with the commercial floor, because everything else is moot without it.

Confirm the edition. Agentforce is a paid, usage-metered product, and the free on-ramp — Salesforce Foundations — is available on Enterprise Edition and above. Per Salesforce’s own pricing documentation, Foundations includes 100,000 free Flex Credits for Enterprise+ customers, which is comfortably enough for a pilot. If you’re below Enterprise, the conversation changes before it starts.

Understand the meter before finance discovers it. List pricing as of mid-2026 is $2 per conversation, or 20 Flex Credits per action (about $0.10, with credits at $500 per 100,000). Which model applies, how actions accumulate, and what a realistic monthly bill looks like are questions worth answering now — we’ve broken down the credit math in detail. Assign an owner for the credit budget the same way you’d assign an owner for API limits. Agents that work get used more, and consumption pricing rewards the team that modeled it early.

Settle the Data 360 question. Agentforce’s retrieval features — data libraries, knowledge grounding — and parts of the Trust Layer run on Data 360 (the platform formerly named Data Cloud). Whether your use case needs it, and how much, depends on what the agent must know, but for a service agent that answers from your content, treat Data 360 provisioning as a prerequisite, not an add-on. In orgs where it was never set up, this is the single most common source of unplanned schedule slip.

Phase 2: The enablement toggles, in the right order

The switches themselves take an afternoon. The order keeps the afternoon from becoming a week.

Provision Data 360 first, and let it finish. Salesforce’s setup guide is explicit that Data 360 must be provisioned and set up before you enable Einstein generative AI. Half-provisioned Data 360 produces half-working AI features that are miserable to debug.
Turn on Einstein. In Setup, find Einstein Setup and enable the toggle. Every generative AI feature in the org sits behind this switch; until it’s on, the agent menus don’t exist.
Configure the Trust Layer before you build anything. The same setup guide puts Trust Layer configuration immediately after the Einstein toggle, and that’s the right sequence — posture first, agents second. More on this in Phase 4.
Enable Agentforce. Search Setup for Agentforce Agents and switch it on. Only now do the builder surfaces appear.

Do all of this in a sandbox first. Sandboxes support both Data 360 and Agentforce, and running the full enablement sequence there surfaces the org-specific surprises — a stuck provisioning step, a permission gap — where they cost nothing.

Phase 3: Permissions — the builders and the agent’s own user

There are two permission surfaces, and teams reliably prepare one and forget the other.

The humans. Builders and admins need Agentforce and Einstein permission sets assigned before they can create or manage agents, and the enabling admin needs standard configuration authority. Decide deliberately who gets build access. An agent builder can wire actions that touch real records; that’s configuration power, and it deserves the same short list you’d apply to any deployment-capable permission.

The agent. This is the one that bites. Every Agentforce agent runs as a real user in your org, and everything the agent reads or writes passes through that user’s object permissions, field-level security, and sharing. The failure mode is silent: an agent whose user lacks access doesn’t throw an error at the customer — it apologizes and says it can’t help, and you burn a day blaming the instructions. For a service agent grounded in Knowledge, Salesforce’s troubleshooting documentation spells out what the running user needs:

Agent user readiness (service agent with knowledge grounding):
  [ ] AgentforceServiceAgentUserPsg permission set group assigned
  [ ] Access to the relevant Data 360 data space
  [ ] "Allow View Knowledge" permission enabled
  [ ] Read access on Knowledge, plus field-level security on every
      field the data library indexes
  [ ] Object/field access for each record type the agent's actions
      touch -- granted explicitly, from a minimum-access baseline

The principle behind the checklist: start the agent user from minimum access and grant only what the job requires. The agent will act with every permission that user holds, whether or not you intended it to.

Phase 4: Trust Layer posture — decide it before the first prompt

The Einstein Trust Layer sits between your agent and the model on every request, and most of it works without configuration. Two pieces deserve an explicit decision before launch rather than a default you discover later.

Data masking. Masking of sensitive data in prompts is configurable — which entity types get masked is a setting, not a constant. Review the configuration against the data your agent will actually handle, and test with realistic records, because compliance reviewers will ask and “whatever the default was” is not an answer.

The audit trail. Einstein generative AI audit and feedback data — prompts, responses, masking behavior — can be collected and stored in Data 360, where your security team can actually monitor it. Turn this on before launch. An audit trail enabled after the first incident explains nothing about the incident.

One honest boundary: the Trust Layer governs the pipeline between org and model — masking, retention, toxicity scoring, auditing. It does not make the agent itself unfoolable, and it doesn’t replace scoping decisions about what actions the agent may take. Those remain yours, which is what the rest of this checklist is for.

Phase 5: Data grounding readiness — the content audit nobody wants

An agent that can’t answer from your actual policies deflects nothing. Grounding readiness has a mechanical half and an editorial half.

The mechanical half: Salesforce Knowledge (with Lightning Knowledge) must be enabled if you’re grounding on articles; an Agentforce Data Library must be created and its search index must reach Ready status before retrieval returns anything; and uploaded files have real limits — 4 MB for text and HTML, 100 MB for PDFs, with only text content indexed. Build indexing time into the plan; the index isn’t instant after setup or after content changes.

The editorial half is the long pole: retrieval quality tracks content quality, and the agent will eventually surface your worst article to a customer. Ten current, well-structured articles beat two hundred stale ones. If the knowledge base needs a cleanup — and in most orgs that have never had a retrieval consumer before, it does — schedule that work now, because it’s the item on this checklist with the longest lead time and the least glamour.

Phase 6: Channel prerequisites — the plumbing the agent talks through

An agent with no channel is a demo. For the common case — a web chat agent — the prerequisite stack is Service Cloud plumbing: Messaging enabled, a routing configuration and a queue, a Messaging for In-App and Web channel, and an Embedded Service Deployment published to your site. Verify your licensing covers Messaging before the project plan assumes it.

Two readiness points hide in that plumbing. First, the queue is your human fallback — build it and staff it even if human handoff is officially “phase two,” because escalation paths are a launch requirement, not an enhancement. An agent that can’t hand a frustrated customer to a person, with transcript intact, isn’t ready for customers. Second, if the channel is voice, Slack, or an external surface rather than web chat, its prerequisites differ enough to deserve their own checklist line — identify the target channel now and pull its requirements forward.

Phase 7: Topic and action scope — the pre-build design review

This phase happens on a whiteboard, not in Setup, and it’s the cheapest place to prevent the most expensive failures.

Scope the first agent to one job. “Answer order-status questions and create a case when it can’t” is a job; “handle customer service” is a wish. Topics are the agent’s routing layer, and how you partition them determines how predictably the agent behaves — fewer, crisper topics with mutually exclusive classification descriptions beat a broad catalog every time.

Inventory the actions and classify them by blast radius. List every action the agent needs, then sort: read-only lookups, reversible writes, and consequential or irreversible operations. For launch, keep the third category out of scope entirely or behind explicit human approval. A refund below a threshold is a policy decision to make in this review, in writing — not something to discover in an agent transcript.

Confirm each action has an implementation and an owner. Every action resolves to a flow, Apex, or a prompt template that someone must build, test, and maintain. If the inventory names an action nobody can own, the scope is wrong. The build guide covers how to construct these well; this checklist only asks whether the list is honest.

Phase 8: The testing gate and go-live governance

The last two boxes are gates, not tasks — conditions that must be true before the agent meets a customer.

The testing gate. Define, in advance, what passing looks like: which utterances must route to which topics, which actions must fire, what the agent must refuse. The Agentforce Testing Center runs those expectations as batch tests from CSV in a sandbox — necessary because test conversations execute real actions against real records. Expect non-determinism: classification varies between runs, so judge trends across repeated suites, not single passes, and supplement batch runs with adversarial manual testing. The full testing methodology is its own discipline; the checklist item is simply that the gate exists and someone owns the pass/fail call.

Go-live governance. Before activation, the answers to four questions should be written down: who reads transcripts in the first weeks, who owns the credit budget, who can pause the agent and how fast, and how changes reach production. That last one matters more than it sounds — an agent moves between orgs as a graph of metadata with real sharp edges, and it should ride your normal release pipeline, not a side channel. And if this launch is the first of several, decide now how you’ll keep an inventory of agents, their users, and their permissions — fleet governance is far cheaper to start at one agent than to retrofit at ten.

What the checklist actually buys you

Run the phases in order and something useful happens to the project plan: every long-lead item — Data 360 provisioning, the knowledge cleanup, the licensing conversation, the approval-policy decision — surfaces in week zero instead of mid-build. The build itself becomes the short, pleasant part it’s advertised to be, because the org underneath it is ready. That’s the whole trick. Agentforce setup isn’t hard; it’s just wide, and the cost of skipping a phase is never visible on the day you skip it. Teams that treat readiness as the project — and the agent as the deliverable that falls out of it — are the ones whose Agentforce launches are boring in the way launches should be.

Understanding the basics

What do you need before setting up Agentforce?

A Salesforce org on Enterprise Edition or above, Agentforce licensing (Salesforce Foundations includes 100,000 free Flex Credits on Enterprise+), Data 360 provisioned, Einstein generative AI enabled in Setup, and Agentforce enabled. Beyond the toggles, you need permission sets assigned to both builders and the agent’s running user, grounding content worth retrieving, and a channel — typically Messaging for In-App and Web — with its licensing confirmed.

Does Agentforce setup require Data Cloud (Data 360)?

For most real deployments, effectively yes. Salesforce’s setup guidance calls for Data 360 to be provisioned before enabling Einstein generative AI, and the retrieval features — data libraries and knowledge grounding — run on it, as does Trust Layer audit data storage. A minimal agent with no grounding leans on it less, but treating Data 360 as optional is the most common cause of surprise delay in Agentforce projects.

What permissions does an Agentforce agent need?

The agent runs as a real user, and every read and write passes through that user’s permissions. For a service agent with knowledge grounding, Salesforce documents the AgentforceServiceAgentUserPsg permission set group, access to the relevant Data 360 data space, the Allow View Knowledge permission, and read plus field-level security on every Knowledge field the data library indexes — plus explicit access to any object the agent’s actions touch. Start from minimum access and grant only what the job requires; missing permissions fail silently as “I can’t help with that.”

How long does Agentforce setup take?

The toggles — Einstein, Trust Layer, Agentforce — are an afternoon in an org where Data 360 is already provisioned. The honest schedule is set by the long-lead items around them: Data 360 provisioning if it was never done, the knowledge-content cleanup, licensing and credit-budget conversations, and building the testing gate. Running the readiness checklist before the build starts is what keeps those from becoming mid-project surprises.

Getting your org ready for Agentforce and want the readiness pass run by people who’ve done it — permissions, Trust Layer posture, grounding, and the go-live gates — before the build clock starts? Talk to us, or start by running our free Agentforce Readiness assessment against your org.

The Agentforce setup checklist: permissions, topics, and actions to verify before launch