Bot Dialog
A Bot Dialog is the conversation building block inside Salesforce Einstein Bots.
Definition
A Bot Dialog is the conversation building block inside Salesforce Einstein Bots. It is a single segment of a conversation, such as a welcome, a main menu, an order-status lookup, or an identity check, built from an ordered list of steps that decide what the bot says and does. Each dialog can be tied to a dialog intent that the natural language model is trained to recognize, so when a customer types a request, the matching dialog fires. The dialog is the unit you design, test, and reuse; the bot is the set of dialogs plus the intent model that routes input to them.
A dialog is assembled in Einstein Bot Builder from four step types: Outbound Messages, Questions, Actions, and Rules. Designers drag these components onto the canvas to model the back-and-forth of a real conversation, capture the data the bot needs, do the work through Actions, and route the customer onward. A production bot usually holds dozens of dialogs that link together and share common subroutines. Salesforce now positions Agentforce as the next step, where the Atlas reasoning engine chooses Topics and Actions instead of following a fixed tree, but the underlying ideas of steps, variables, decisions, and bound work still apply.
How a Bot Dialog is built and behaves
The four step types inside a dialog
A dialog is an ordered list drawn from four step types, and almost every useful dialog mixes them. Outbound Messages display what the bot says to the customer, from static text like a greeting to messages that interpolate captured values. Questions gather customer input and store the answer, often presenting buttons or a menu so the choice is clean rather than free text. Actions perform Salesforce work: create, read, update, or delete records, retrieve data, call an external API, or start a Flow. Rules act as a conditional engine, letting the dialog make runtime decisions, redirect to another dialog, transfer to an agent, or set and clear variables. You add steps by dragging components from the Dialog Component Library onto the canvas, then configure each one in the Step Properties panel. Because the four types compose freely, a single dialog can greet a customer, ask a question, branch on the answer, run a lookup, and report the result. Keeping that sequence short and readable is what separates a maintainable bot from one nobody wants to touch six months later.
Dialog intents and how a dialog gets selected
A dialog can be associated with a dialog intent, which is trained to understand variations in how customers phrase the same request. When someone types a message, the bot uses natural language understanding to classify it to an intent, and the dialog bound to that intent fires. Training quality decides whether this works. Salesforce guidance for getting started is three to five intents with a minimum of 20 utterances each, and more real phrasings improve accuracy. Utterances are the example sentences customers might use, so a Reset Password intent should be trained on wordings like cannot log in, forgot my password, and locked out. Thin training leaves the model guessing and sends customers into the wrong dialog, which feels broken even when each dialog is well built. Not every dialog needs an intent. Common subroutines like Verify Identity are usually reached by navigation from other dialogs rather than by direct customer input, so they carry no intent of their own. Pairing strong intent training with clean dialog design is what makes a bot feel like it actually understood the question.
Capturing and reusing variables
Question steps capture information into variables, and those variables persist for the rest of the session. That persistence is what lets a conversation feel coherent. A dialog can ask for an order number once, store it, then reference it in a later Outbound Message (you said order 12345) and pass it into an Action that looks the order up. Variables also carry across dialogs when one navigates to another, so a value collected in an identity check is still available in the order-status dialog that called it. Variable hygiene is the practical difference between a bot that feels conversational and one that asks the same thing twice. The common mistake is re-prompting for data the bot already holds, usually because a designer forgot a value was captured earlier in the flow. Before adding a Question step, it is worth checking whether the answer is already in a variable from an earlier step or a previous dialog. Treating variables as shared session state, rather than something each dialog owns in isolation, keeps the conversation tight and avoids the frustration of repeated questions.
Branching with Rule steps
Rule steps are the dialog's decision points. A rule evaluates conditions against captured variables, CRM context, or values returned by an Action, then sends the conversation down the matching path. A Reset Password dialog might branch on whether the customer has multi-factor authentication enabled, taking one route for users who do and another for users who do not. Rules can also redirect to another dialog, transfer the session to an agent, skill, or queue, and set or modify variables along the way. Good branching keeps the conversation moving without forcing the customer to answer questions that the bot could answer for itself. The anti-pattern is a flat dialog that asks for everything up front and then figures out what to do, which feels like a form rather than a conversation. Well-placed rules let the bot ask only what it needs based on what it already knows. Because rules drive transfers as well as branches, they are also where you decide when the bot should stop trying and hand the customer to a person. That decision, made deliberately at design time, is one of the most important in any bot.
Composing dialogs through navigation
Dialogs are meant to call each other, not to grow into one giant tree. A Rule or Action can redirect the session from one dialog to another while preserving captured variables, which lets common subroutines be defined once and reused. Verify Identity, Confirm Email, Schedule Selection, and Knowledge Lookup are typical examples: each lives as its own focused dialog and is reached from several main intent dialogs. This composition is what keeps individual dialogs small and the overall bot maintainable. Without it, designers tend to copy the same verification steps into every dialog, and a change to the identity process then has to be made in a dozen places. With reusable subroutines, the change happens once. The pattern mirrors how developers factor repeated logic into shared functions. A practical rule of thumb is to watch for the same sequence of steps appearing in more than one dialog, then extract it into a dialog of its own. The result is a bot built from a library of small, testable pieces rather than a handful of monoliths that no one fully understands.
The Agentforce evolution: dialogs become Topics and Actions
Salesforce has shifted its conversational strategy from scripted dialog trees toward Agentforce, where the Atlas reasoning engine decides what to do. In that model a Topic is the rough successor to a dialog, grouping a set of related Actions, and an Action is the bound work, much like an Action step inside a classic dialog. The key difference is control. A dialog follows a designer-defined path, while the reasoning engine uses a large language model to pick the relevant Topic and the next Action based on the conversation and the customer's goal. That makes Agentforce more flexible with unexpected phrasing, but it also moves design effort from drawing the flow to writing clear Topic instructions and well-scoped Actions. The two worlds are not mutually exclusive. Salesforce supports patterns where an Einstein Enhanced Bot handles an entry point, evaluates intent, and routes the customer to an Agentforce agent for the harder reasoning. When teams migrate existing bots, the usual mapping is dialogs to Topics and Action steps to Actions, carrying over the work the bot already does while letting the reasoning engine handle routing that rules used to.
Common pitfalls in dialog design
Three problems show up again and again, and each is fixable with discipline. The first is the monolithic dialog that tries to handle an entire customer journey in one long sequence. It becomes impossible to test or change, and it usually duplicates steps that belong in shared subroutines. Keeping dialogs small and composing them through navigation avoids this. The second is weak intent training. When intents have only a handful of utterances, the model misclassifies real customer phrasings and sends people into the wrong dialog, which reads as the bot not listening. Training each intent on twenty or more genuine wordings, ideally mined from real conversations, fixes most misrouting. The third is the dead end. A dialog that cannot resolve the request and offers no way out leaves the customer stuck, which is more frustrating than a slower handoff to a person. Every dialog should include a Rule that can transfer to an agent when the bot has done what it can. None of these pitfalls is exotic. They are the predictable result of skipping design discipline, and a short review of each dialog against these three points catches most of them before launch.
How to create a Bot Dialog in Einstein Bot Builder
You create a Bot Dialog inside Einstein Bot Builder, then fill it with steps. These instructions cover making the dialog itself; adding and configuring steps happens on the canvas afterward.
- Open Bot Builder and go to Dialogs
From Setup, open your Einstein Bot, then choose Bot Builder. In the Bot Builder menu, click Dialogs to see the list of existing dialogs for this bot.
- Create a new dialog
In the Dialogs panel, click New. Give the dialog a clear name that describes its job, such as Check Order Status or Verify Identity, so other builders can find it later.
- Set the API name and description
Confirm or adjust the auto-generated API name and add an optional description that explains what the dialog handles. Decide whether it should appear in the bot's options menu, then save.
- Add steps on the canvas
With the dialog open, drag components from the Dialog Component Library onto the canvas to add Outbound Messages, Questions, Actions, and Rules. Configure each step in the Step Properties panel.
- Train the dialog intent and test
If the dialog should be triggered directly by customers, add a dialog intent and train it with twenty or more utterances. Use the preview to test the conversation before activating the bot version.
A human-readable label shown in Bot Builder. Make it describe the dialog's purpose so the team can navigate the bot.
The unique developer name used in references and metadata. Bot Builder suggests one from the dialog name and you can adjust it.
Optional but recommended text explaining what the dialog does, which helps when a bot has dozens of dialogs to maintain.
- A dialog with no associated intent will not fire from direct customer input. It can only be reached by navigation from another dialog.
- Changes apply to the bot version you are editing. You must activate a new version for them to reach live customers, so test in preview first.
- Do not pack an entire customer journey into one dialog. Extract reusable steps like identity checks into their own dialogs and navigate to them.
Prefer this walkthrough as its own page? How to Bot Dialog in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Understand Einstein Bot DialogsSalesforce
- Create an Einstein Bot from ScratchSalesforce
Straight from the source - Salesforce's reference material on Bot Dialog.
- Understand Einstein Bot DialogsSalesforce
- Chat with Customers with Einstein BotsSalesforce
Hands-on resources to go deeper on Bot Dialog.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Bot Dialog inside an Einstein Bot?
Q2. Can a Bot Dialog call another Bot Dialog directly?
Q3. What is the best practice when designing a Bot Dialog?
Discussion
Loading discussion…