Common challenges when migrating to Agentforce and how to solve them

The migration fails on a Friday, in a way that looks like a model problem and is not one. Every channel is cut over. The bot that used to ask for a case number is off. The agent guesses the Account from a first name, answers with certainty about the wrong person, and the escalation that follows arrives with no order number, no case number, and no note of what was already tried. Supervisors see a worse queue and blame the wording. The missing piece is the slot the tree was collecting, and the subagents that moved before anyone had checked what they were allowed to quote.

Most migration pain is that assumption, not the switch itself. The bot's intent list is not the agent's design. An intent that collected an order number and called a Flow can stay a Flow. An intent that guessed at a long, angry paragraph cannot be pasted across as a subagent and expected to behave.

Salesforce describes Service Agent as a replacement for traditional chatbots that can handle a wide range of service issues without preprogrammed scenarios. That is a different object from a dialog tree. A dialog is correct because someone drew the branch. Service Agent is useful where you could not draw the branch, and where a maintained source can still answer. Treat the move as a redesign of a few subagents, not as an import. The sequence for keeping the narrow paths on the bot while one channel moves is how to transition from Einstein Bots. This page is the set of things that stall that sequence.

#Intents do not map one to one

Take a bot intent called "check status". In the dialog it may have been three menus, a slot for a case number, and a handoff when the match failed. The slot was doing real work. It forced an identifier before any answer, and the failed match had an owner. In Agentforce that becomes one subagent only if you still have the slot, the read action, and the stop. Otherwise it becomes a plan that guesses which Case you meant, and a guess that happens to be right in the demo will be wrong on a common name.

Some intents should not become subagents at all. A menu that only creates a Case and assigns a queue is a Flow. Put the Flow behind whichever front door you keep. The front door can be the bot, the agent, or a person. The owner of the create and the assignment does not change when the front door does. Building twelve agents because the bot had twelve intents scatters the action library. The plan then picks a neighbour of the right action, because several actions are legal and only one is correct. A neighbour is worse than a miss. The reply still completes.

Write a sheet with three columns before anyone opens Agent Builder. Dialog name. What the dialog actually did, including the slot it collected and the Flow or assignment it called. The owner after the move: a Flow, a grounded subagent, or a person. If you cannot fill the third column, the intent is not ready, and volume on the intent report does not make it ready. High volume is how you choose which ready subagent to move first. It is not evidence that the subagent is ready.

The third column is the migration. Everything else is configuration that can wait until the column is filled. A programme that imports first and classifies later will spend the rework on duplicate subagents and on Flows that were retired a week too early.

#Grounding is the long task

The agent answers from trusted business data, including CRM records and external data from Data 360. Data Cloud is the name you may still see. Salesforce rebranded it to Data 360 on 14 October 2025. The name on the screen does not change the job. If two Knowledge articles disagree, or the article describes a policy retired last year, the plan can still sound finished. That is a grounding fault. Editing the subagent name will not fix it, and adding a sentence to the instruction that says "only use current policy" will not fix it either. The plan quotes what retrieval returned.

Run the checks in the grounding checklist before a subagent faces a customer. The failure you are looking for is specific, and it comes in two shapes that need different owners.

The article exists, the running user cannot see it, and the agent fills the gap with a plausible sentence. That is a permissions fault wearing a content complaint. Widening the user so the sentence becomes a quote does not make the article appropriate for the channel. It makes the leak reliable.

Or the article is visible and simply wrong, and the agent quotes it faithfully. That is a content fault. The agent is doing what it was asked to do. The person who maintains the article is the owner, and a subagent should not go live on a source nobody is willing to correct. Two articles that disagree are the same fault with two owners. The plan will pick one, often the friendlier one, and you will not see the choice in the reply. You will see it when a customer and a supervisor quote different paragraphs of your own knowledge base.

Grounding is also why a subagent that "worked" on the bot can fail after the move. The bot recited a line a designer typed. The agent retrieves. If the line and the article have drifted apart, the move surfaces the drift. That is a reason to ground before the cutover, not a reason to keep reciting the drifted line because customers have not complained yet.

#The running user's permissions

The agent acts as a user. Sharing rules, permission sets, and field-level security on that user are the boundary of what it can say. Teams often reuse the integration user that let the bot read everything, because that made the demo easy and because the bot mostly collected slots rather than quoting records. The agent then quotes a Case the person on the channel is not allowed to open. The bot's user was wide because the bot's job was narrow. Those two facts do not travel together.

Set the running user to the visibility of the channel, then test with a user who should be denied. Ask for a record in another region, another brand, or another person's Account. The correct result is a refusal and a handoff, not a helpful summary. A summary that happens to be factually right is still a fail. The test is the boundary, not the trivia.

Widening access so the refusal goes away is the failure mode. You have taught the agent to see past the organisation's own rules, and you have done it in the name of a cleaner demo. Put the facts the channel is allowed to hear into a payload or an article written for that channel. Do not grant the agent a user whose only merit is that it made the refusal stop. Field-level security is part of the same test. A running user who can see a Case but not a field should not invent the field. The reply says the field is not available, and stops, or it hands off.

There is a related mistake on employee-facing agents, where the running user is a real person and the risk is the opposite shape: the agent acts with that person's access and then takes an action the person did not mean to commit. The customer-channel version is the one that leaks. Both versions are fixed by reading the trace as that user, not as an administrator watching over their shoulder.

#Cut one channel over

Keep the old bot live on every channel you are not deliberately moving. On the channel you do move, transfer only the subagents that have passed grounding and a handoff test. Ambiguous subagents stay on the bot, or go straight to a queue. Complaints, money, and anything the bot used to "resolve" with a vague article are the usual residents of that queue. Leaving them there is not a delay. It is the design, until retrieval and the payload exist.

The handoff test is concrete. A person receives the record Id, the question in the customer's words, and what was already tried, including a refusal. If the escalation arrives empty, the subagent is not ready, even if the reply the customer saw was polite. Empty escalations are how a Friday cutover gets blamed on the model. The model spoke. The Flow that used to collect the slot was switched off. The person inherited the mess.

Watch reopens on the first subagent before you consider a second channel. A subagent that stays closed, with escalations that arrive full, can have a neighbour. A subagent that reopens, or that quotes an article the channel user cannot open, goes back to the bot or the queue. Adding a channel multiplies whatever you have, including the fault. Dull on one channel is the permission to touch a second. Dull means reopens are quiet, the denied-user test still refuses, and the sheet's third column has not been quietly edited in production.

#What to do in the weeks before a cutover

The first week is the sheet. Sit with the person who owns the bot dialogs and fill the three columns, including the intents everyone is slightly embarrassed by. Those are usually the ones the report calls resolved. The second week is grounding and the running user, on the subagents whose owner is "grounded subagent" and on no others. Run the denied-user test and read twenty retrievals by hand. The third week is the handoff payload on one channel, with the bot still available on that channel for everything you did not move.

Then turn one subagent on. Not the menu that already works. That menu can stay. Turn on the subagent where the wording varies and the article is fit to quote. Read the plan, not the farewell message. If the trace guesses an Account, the subagent comes back off the same day. The readiness questions that sit under this cutover, including what has to be true six months later, are in what separates an Agentforce rollout that is still running. A migration that survives the first channel is mostly a migration that refused to import the intent list.