Agentforce Go-Live Checklist: 7 Gates to Pass Before Launch
Most Agentforce checklists hand you questions. This one asks for receipts. Every gate below has a pass condition and the evidence behind it, and if you can't produce the evidence, the gate stays shut, however good the demo looked.
Gate 1: The agent user has only the access its job needs
When you create an agent with a new user, Salesforce creates a real user record on the Einstein Agent license and Einstein Agent User profile. It starts with almost no access. Salesforce Ben's September 2026 walkthrough groups Agentforce permission sets into three kinds: who can use the agent, who can build it, and what the agent can touch at runtime. Agents end up with more reach than anyone intended when those three get mixed together.
Pass: the agent user holds only the permission sets its topics and actions require, and nobody added access "to make the demo work."
Evidence: an export of the agent user's permission set assignments, reviewed and signed off by the org owner on your side.
Gate 2: Verified identity actually limits what the agent can see
For service agents, verifying a customer doesn't narrow the data the agent can read by itself. The agent still runs as its agent user unless the channel requires login. Records have to be filtered to the verified customer in the flows or Apex behind each action, and actions that need verification have to be blocked until it happens.
Pass: every action that returns customer data filters by the verified customer, and unverified conversations can't reach those actions.
Evidence: the filter condition in each action's flow or class, plus a test conversation that tries to reach another customer's record and fails.
Gate 3: The data the agent reads is fit for purpose
Every duplicate, placeholder value, stale owner and inconsistent format in the objects the agent reads ends up in an answer, delivered with confidence.
Pass: duplicate rate, field completeness and freshness on the agent's source objects meet the thresholds you set before the build.
Evidence: a dated data quality report on those objects, with the thresholds written down in advance.
Gate 4: Every action is listed, scoped and reversible
Build one table before go-live, with a row for every action the agent can call and four columns: the action, the objects and fields it writes, its owner, and how to undo it.
Pass: every action has a row, a named owner, and an undo method.
Evidence: the completed table.
Gate 5: The agent has been tested at volume, not just in a demo
Salesforce provides Agentforce Testing Center in the UI and a Testing API for batch tests, so you can run many utterances against the agent instead of trying a few by hand in Builder.
Pass: a test set covering normal requests, edge cases, out-of-scope requests and attempts to reach data the user shouldn't see, run with results above the threshold you agreed before testing.
Evidence: the test set, the run results, and the list of failures with what was changed.
Gate 6: A person reviews outputs, and someone owns escalation
The Einstein Trust Layer includes an audit trail that tracks a prompt through each step. Trailhead also states that data masking is disabled for agents, so don't count masking as a control for agent conversations.
Pass: a named reviewer on your side samples agent conversations on a fixed schedule, and there's a written path for handing a conversation to a person.
Evidence: the review schedule with the reviewer's name, the escalation path, and the first week's review log.
Gate 7: Can you turn it off and recover?
Pass: someone can deactivate the agent in minutes, and you know how to reverse what it changed while it was live.
Evidence: a written rollback runbook, rehearsed once in a sandbox, with the time it took.
How to use the gates
Run them in order. Gates 1 and 2 cover access, and they come first: test results mean nothing if the agent can reach records it shouldn't. If a gate fails, fix it and re-run that gate before moving on. Keep the evidence in one place. It's also what your auditors and your board will ask for.
Frequently asked questions
What is the agent user in Agentforce?
When you create an agent with a new user, Salesforce creates a user record on the Einstein Agent license and Einstein Agent User profile. It starts with almost no access. Give it only the permission sets its topics and actions require.
Does verifying a customer limit what a service agent can see?
Not by itself. The agent runs as its agent user unless the channel requires login, so every action that returns customer data has to filter records to the verified customer.
How do you test an Agentforce agent before go-live?
Use Agentforce Testing Center or the Testing API to run a test set covering normal requests, edge cases, out-of-scope requests, and attempts to reach data the user should not see. Agree the pass threshold before you run it.
Where to go next
AI Governance for Salesforce teams: review cycles, ownership and escalation for AI in production.
Salesforce AI data readiness checklist: the data side of Gate 3 in more detail.
Salesforce AI Data Readiness Assessment: an architect-led review of these gates in your org.
