# Common challenges when migrating to Agentforce and how to solve them A bot intent is a branch in a dialog. An Agentforce subagent is a grounded job with an action and a stop. The migration fails when those are treated as the same list, or when every channel is cut over while the ambiguous work still has no owner. **Published:** 2025-11-07 **Canonical:** https://synconai.com/challenges-migrating-to-agentforce **Author:** SynconAI Architecture Team ## In short Bot intents do not map one to one onto Agentforce. A dialog branch is not a grounded subagent. The hard parts are grounding, the permissions of the user the agent runs as, and cutting one channel over while the old bot still owns the ambiguous subagents. Service Agent handles issues without preprogrammed scenarios. Move a subagent only after retrieval and the handoff both work. ## Sources - **Agentforce: What types of AI agents are there?** (retrieved 2026-10-10) https://www.salesforce.com/agentforce/ > Service Agent replaces traditional chatbots with AI that can handle a wide range of service issues without preprogrammed scenarios, improving customer service efficiency. - **Agentforce: What is an AI agent?** (retrieved 2026-10-10) https://www.salesforce.com/agentforce/ > These agents generate responses that are consistent with your company’s brand voice and guidelines using trusted business data, including Salesforce CRM data, external data from Data 360, and more. ## What to take away - Do not turn each Einstein Bot intent into its own agent. Many intents are a Flow with a menu in front of it. - Ground the subagent first. A confident answer from a stale or contradictory article is a data fault, and a new subagent name will not repair it. - The agent sees what its running user sees. Reusing a wide bot integration user leaks records the channel should not open. - Move one channel, and leave ambiguous subagents on the bot or with a person until retrieval and the handoff both work. ## The guide 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](/transition-einstein-bots-to-agentforce). 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. | What the dialog did | Owner after the move | Ready when | | --- | --- | --- | | Collected one slot and called one Flow | The Flow, behind whichever front door you keep | The agent can call that Flow and stop, or the bot still does | | Answered from a menu of fixed lines | The bot, until a maintained article replaces the lines | Someone can point at the article and the running user can open it | | Guessed at a long paragraph | A grounded subagent, or a person | Retrieval and the handoff have both been tested | | Escalated when the match failed | A person, via the existing path | The new channel still reaches that person with the slot attached | | "Resolved" with a vague article | Nobody yet | You have admitted it was never resolved | 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](/insights/agentforce-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. ::: warn A confident answer from a stale article is a data fault. Treat it as one. Changing the subagent description, the tone, or the channel label leaves the quote in place, and the next customer receives the same retired policy in cleaner sentences. ::: 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. ::: note One channel is a constraint, not a lack of ambition. The bot stays on for the paths you have not redesigned. Service Agent is for issues without a preprogrammed scenario, which is a poor description of a half-grounded long tail. ::: ## 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](/insights/agentforce-implementation-best-practices). A migration that survives the first channel is mostly a migration that refused to import the intent list. ## Questions ### Can we map each Einstein Bot intent to an Agentforce subagent? Not one to one. A dialog intent is often a menu plus a Flow, and that Flow should remain the owner behind whichever front door you keep. A subagent is a grounded job with an action and a stop. Split the old list into Flow, grounded subagent, or person before you build anything. High volume on an intent report tells you which ready subagent to move first. It does not make an ungrounded intent ready. ### What is the first thing that goes wrong in a migration? Grounding, closely followed by the running user. The agent will quote whatever that user can see, including a stale Knowledge article or a Case the channel should not open. A plausible sentence in the gap, where retrieval returned nothing, is the same fault. Fix retrieval and permissions before you judge the wording of the reply. A new subagent name does not change what the article says. ### Should we turn the bot off when Service Agent is enabled? No. Keep the bot on the channels and subagents you have not moved. Service Agent is meant to handle issues without preprogrammed scenarios, which is a poor fit for a half-grounded long tail and a poor replacement for a slot that already collected an identifier. One channel, grounded subagents only, is the cutover. Watch reopens on that subagent before you add another. ### How do we test that the agent cannot see too much? Use a user who should be denied, and ask for another region's record or another brand's Case. The pass is a refusal and a handoff. A useful-sounding answer is a fail, even if the facts happen to be right. Do not widen sharing, permission sets, or field-level security to clear the test. The bot's integration user was often wide because the bot's job was narrow. Those two facts do not travel together. ### What should we do with topics the bot never really handled? Leave them with a person, or on the bot's existing handoff, until grounding and the payload are in place. Moving them because they are on the intent report only transfers the failure into the new channel. Ambiguous work needs an owner, and that owner is often still a queue. A vague article the bot used to "resolve" with is not a source you should ask Service Agent to quote. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Agentforce consulting (https://synconai.com/salesforce-agentforce-consulting).