Before You Activate Agentforce: A Pre-Launch Checklist

Your Agentforce demo went well. The agent answered questions, pulled up information, and completed a few tasks.

Then a customer asks about a case that has been open for three weeks, or requests a change they are not authorized to make, or asks something nobody thought to prepare for. Will your agent know what to do next?

That gap between a working demo and a reliable agent is where most launches succeed or stumble. Activation is the moment your agent goes live, but it is the starting line, not the finish. The teams that get the most from Agentforce treat activation as the last step of a careful build.

This guide walks through what activation means in Salesforce, how it differs from configuration and production readiness, and what to check before you press the button. It is written for admins, architects, and the leaders who approve the budget.

Activation is the moment your agent goes live, so make it count

In Salesforce, activating an agent makes it available to users on every channel where it is deployed. Salesforce’s help documentation confirms that activation takes effect immediately on those channels, including the Agentforce panel. Once an agent is active, people can use it right away.

That immediacy is powerful, and it is why preparation matters. Every hour an untested agent runs is an hour real customers are talking to it. Get the work done first, and activation becomes a confident step rather than a leap.

Activate, configure, or go live? Know which one you are doing

These terms are related, but they describe different stages of getting an agent ready for use.

Stage	What it covers	What it does not guarantee
Platform enablement	Making Agentforce capabilities available in your Salesforce org, subject to access, licensing, and edition. In Salesforce’s Winter ‘27 documentation, the platform is enabled by default for orgs with the right access, and the separate Setup toggle is being removed.	That an agent has been configured or is ready for users.
Agent configuration	Defining the agent’s instructions, topics or subagents, actions, data access, and intended behavior.	That the agent will perform reliably across real-world scenarios.
Agent activation	Activating a committed agent version so it becomes available on its connected channels. Salesforce requires a version to be committed before it can be activated.	That the agent is accurate, secure, or ready for every production scenario.
Production readiness	Validating behavior, permissions, integrations, guardrails, escalation paths, and monitoring.	That no monitoring, incident handling, or ongoing improvement is needed after launch.

Because the platform is enabled by default for many orgs, do not assume you can skip access checks. Confirm that your org has the Agentforce capabilities and agent type you intend to use, then check licensing, Einstein generative AI setup, and user permissions against Salesforce’s current Agentforce setup documentation.

Then the sequence is: configure the agent, validate it, commit the version, and activate the validated version. Before activation, confirm that testing is complete, intended users have the required access, and someone is responsible for reviewing issues after launch.

Before you flip the switch: the four checks that decide your launch

Start with one workflow, not the whole org. Pick a process that happens often, follows a predictable pattern, and ends in a Salesforce record. An agent that answers order status questions is a strong first project. A process where experienced staff regularly disagree on the right answer is a poor first pick, because the agent will inherit that confusion. Before you build, name one owner who will answer for the agent’s results. If you cannot yet name a use case or an owner, start there.

Then check your environment. Confirm your edition, licenses, and Einstein setup. Salesforce’s Help Agent guided setup, for example, is available in Enterprise and Unlimited Edition with Agentforce enabled, and it checks for Data 360 (formerly Data Cloud) and Agentforce before it continues. Requirements differ by setup, so confirm them against the current documentation for your org.

Next, look at the data. An agent reasons over the records it can reach. Duplicate accounts, blank statuses, and outdated fields all show up in its answers. Clean the fields the agent depends on first. You do not need to fix the whole org before you start.

Finally, review permissions and sharing. Agents work inside your existing security model, and many orgs still run on permission sets built years ago. Decide what data the agent can see, which actions it can take, and which actions need a person to approve.

Data, actions, and integrations

An agent is only as useful as the actions it can take. An action might look up an order, update a case, or open a follow-up task. Each one depends on a Salesforce object, a flow, an Apex class, or an external system.

Test every dependency before customers reach the agent. Flows used by actions can be checked with Flow Builder’s debug feature or, for autolaunched and record-triggered flows, with Test Mode. Confirm that each action returns what the agent expects, handles missing data gracefully, and fails in a way the agent can explain to the customer.

Integrations need the same attention. If an action calls an external system, decide what happens when that system is slow or down. A customer should never wait indefinitely, and the agent should never guess.

Guardrails: what your agent should never do on its own

Separate two questions: what a user is allowed to see, and what the agent is allowed to do. Give the agent the narrowest access that still lets it finish its job. A support agent that answers order status questions has no business issuing refunds.

Guardrails are the plain-language rules that keep an agent inside its lane. Write them before you build. For example, the agent may share order status and tracking links, but it may not change a shipping address or promise a refund. Every guardrail should map to a topic, an action, or an escalation path, so nothing is left to chance.

Testing your agent before real customers do

A successful test conversation is a good start, but it does not tell you how the agent will behave across different requests, data conditions, or failed actions. Testing should cover both the agent’s responses and the actions it takes.

Start with Agentforce Builder preview. Use it to check how the agent interprets a request, selects a topic or subagent, and chooses an action. Simulate mode validates configuration and behavior without changing org data. Live Test runs actions against real data and can change Salesforce records, so use a sandbox or controlled setup when validating actions that modify data. Start with common requests, then work through less predictable scenarios: missing information, ambiguous questions, restricted records, and unsuccessful actions.

Use Testing Center for broader validation. For repeatable testing, Salesforce’s Agentforce Testing Center documentation describes test cases created from agent configuration, generated scenarios, and uploaded CSV files. Teams can evaluate topic selection, action execution, response quality, and how well the agent follows its instructions. Testing Center can execute actions that modify CRM data, so Salesforce recommends using it in a sandbox rather than a production org.

Test human handoff separately. Salesforce documents that conversation-level testing in Testing Center does not support escalation. If an escalation is triggered during such a test, the conversation ends with a transfer message rather than validating the full handoff. Test escalation through an appropriate end-to-end path. Confirm that the request reaches the correct person or queue, that the conversation context is available, and that the customer can continue without repeating everything.

Build a test set around real requests. Use questions your team already receives, with variations in wording, spelling, and context. Include requests that need more information, actions that fail, attempts to access restricted records, and situations where the agent should hand off to a person. Document expected behavior, review failures, refine the configuration, and rerun the relevant tests before activation.

The objective is not just to get the agent to respond. It is to establish that it can complete the intended task, stay within its permissions, and handle situations it cannot resolve.

When the agent gets stuck: designing a smooth human handoff

Every production agent needs a graceful exit to a person. Design that exit before activation, because the first unhappy customer is not the time to figure it out.

Start with the triggers. Common ones include a request outside the agent’s topics, two failed attempts to resolve an issue, a customer who asks for a human, and any action that needs approval, such as a refund above a set amount.

Next, decide what the human receives. The person taking over should see the full conversation, the customer’s record, and what the agent already tried. Customers should never have to repeat themselves, and that single detail often decides whether the handoff feels seamless or frustrating.

Finally, name the owners. Who works the escalation queue? Who reviews failed conversations each week? Clear answers turn escalation from a fallback into a feedback loop that makes the agent better.

For voice channels, the handoff carries extra weight. The Agentforce Voice quickstart covers use case selection, voice and telephony configuration, topic and action creation, testing, and success metrics, so the handoff is planned alongside the channel rather than bolted on later.

Activating a new version without losing your footing

Activation works on versions, and that has practical consequences. When you activate a new version, the active version is deactivated automatically. Salesforce’s documentation also states that once you activate a version, you cannot change it, even after deactivating it. Plan every change as a new version, and test it fully before you switch.

Channels matter as well. Activation puts the agent live wherever it is deployed. If the agent runs on the Agentforce panel and on your website, a change reaches both. Confirm the channel list before you activate.

Always plan for rollback. Know which version you will reactivate if the new one misbehaves, and know who has permission to do it. A few minutes of planning now can save a very long afternoon later.

Proving the agent works: picking the metric that matters

Choose one success metric before you build. Good metrics are specific and tied to a business result. The share of order status questions resolved without a transfer to a person is one example. Average time to first response on a service channel is another.

Record a baseline before launch so you can see change later. Measure over a fixed period and review failed conversations regularly. Each failure is a candidate test case, so your test suite grows from real usage rather than guesswork.

Most struggling launches come down to skipped edge cases, broad permissions never tightened, messy data, undefined escalation, versions changed without a rollback plan, or no success metric. The checklist below covers each one.

Your pre-activation checklist

Work through this list before you select Activate:

• The workflow is narrow, frequent, and ends in a Salesforce record, and it has a named owner.
• Your edition, licenses, and Einstein setup meet current requirements.
• The data fields the agent reads are checked for duplicates, blanks, and outdated values.
• Agent permissions cover only the actions the workflow needs.
• Each action has been tested with normal, missing, and error data.
• Flows behind actions have been tested in Flow Builder or Test Mode.
• Batch tests in Testing Center cover common phrasings, edge cases, and out-of-scope requests.
• Escalation triggers, handoff context, and queue owners are documented.
• You know which version to reactivate if the new one fails.
• One success metric and its baseline are recorded.
• A named owner reviews failed conversations every week.

Already built, but stuck or not trusted?

If your build has stalled, or you inherited an agent from another partner and do not trust it yet, the same checks still apply. Start with the data, permissions, and escalation design, then decide whether to fix what exists or rebuild the parts that will not hold up in production. A short readiness review can show which is which before you commit more budget.

How LevelShift takes your agent from activation to production

LevelShift is an Agentforce-ready partner with 14 years of Salesforce work behind it and a team of more than 120 certified consultants and architects. That depth shows up where launches usually get hard: the data, the integrations, and the rules that keep an agent safe.

Our Agentforce implementation services cover agent configuration in Salesforce, Data 360 (formerly Data Cloud) and CRM integration, and embedded data governance and escalation rules, so the design you approve is the design that goes live. We also offer pre-built accelerators for different industries and use cases, which support a quick six-week rollout. Real timelines depend on your data, permissions, and scope, and every accelerator is checked against your escalation and governance needs before it goes live.

Forrester independently evaluated 42 Salesforce consulting services providers and recognized LevelShift for its Agentforce capabilities, reflecting our delivery work with enterprise clients building and deploying AI agents across Salesforce ecosystems. Read more about the report, and browse more customer success stories to see how teams have put agents to work.

Customers describe the difference in their own words:

“LevelShift’s expertise in Agentforce implementation was instrumental in our successful deployment. Their team worked closely with us to design and launch AI agents that have significantly improved our customer service operations.”

Chris Sirosky, EVP of Customer Experience, Ever.Ag

Watch the customer story

If you are planning an Agentforce activation, book a 30-minute Agentforce readiness review with our team to walk through your readiness checks, your first use case, and the testing and escalation plan you will need before go-live.