Bot Action
A Bot Action is a configurable step inside an Einstein Bot dialog that does work beyond conversation.
Definition
A Bot Action is a configurable step inside an Einstein Bot dialog that does work beyond conversation. It calls Apex, runs a Flow, searches or creates a Salesforce record, sends data to an external API, transfers the chat to a human agent, or returns a Knowledge answer. Bot Actions are the link between the conversational layer, where the bot recognizes intent and replies, and the rest of Salesforce, where the real business logic lives.
A bot that only sends messages is just a script. A bot that looks up an order, books an appointment, or opens a case uses Bot Actions to do it. You add an action by dragging an action component onto the dialog canvas in Einstein Bot Builder, naming it, then mapping its input and output variables. The dialog chains that action together with messages, questions, and rules so the whole exchange feels like one coherent conversation.
How Bot Actions turn a chatbot into a worker
The action types you can add to a dialog
Salesforce groups dialog action steps into a few families. An Object Search action returns records from a standard or custom object so the bot can read live CRM data into the conversation. Object create, update, and delete actions write back to those same objects. A Standard Action calls a built-in invocable action directly, without you wiring up Apex or a Flow first, and this family covers things like Knowledge answers and notifications. An External Service action sends and receives data with an outside API provider using a registered schema, so the bot can reach a third-party system with no custom code. Beyond those, a dialog can call an autolaunched Flow or an Apex invocable method when you need logic that the point-and-click actions cannot express. Every Einstein Bot also ships with two system actions out of the box: Transfer to Agent and End Chat. The action you pick at any given step depends entirely on what the conversation needs to do right there, so most real bots mix several types across their dialogs.
Input and output variables carry the data
Bot Actions do not run in isolation. Each one takes input variables and returns output variables, and those variables are how data moves through the conversation. Inputs are filled from earlier context: a slot the customer typed into, a value passed in from the chat deployment, or a record looked up by a previous action. When you configure an action that uses an invocable method, the configuration screen automatically shows the fields you can map, based on the InvocableVariable entries in the input class. Outputs hold whatever the action produced, such as the order number it found or the case ID it created. Later steps reference those outputs to shape the next message or to drive a rule. One detail trips people up: custom values typed directly into an Apex input are interpreted as strings, so type matters. Salesforce also limits structure depth here, allowing up to five levels of nested objects in outputs but only one level in inputs. Consistent variable naming across the whole bot is the cheapest way to keep these chains from breaking silently.
Calling a Flow versus calling Apex
When the point-and-click actions are not enough, you reach for either Flow or Apex. The Call Flow action invokes an autolaunched Flow, passing input variables in and reading output variables back out. For most admin-written automation this is the better default. Flow is easier to read, version, and maintain than Apex, and a single Flow can fan out to subflows or even call Apex when it has to. The Call Apex action invokes a method marked with the InvocableMethod annotation. Reach for Apex when the logic is genuinely complex, when you are integrating with a system that needs custom callout handling, or when you need something Flow cannot express cleanly. Both paths run inside the bot's strict performance envelope. A single Apex action times out after ten seconds, the bot's overall response processing is capped at twenty seconds, and a maximum of fifty Apex calls can run before the bot sends its next outbound message. Those ceilings push you toward lean, bulkified logic and away from chatty multi-step callouts inside one turn.
Transfer to Agent and the human handoff
No bot resolves every conversation, so the Transfer to Agent action is the supported escape hatch on every Einstein Bot. When the bot cannot help, or when the customer asks for a person, this action hands the chat off to a live representative through Omni-Channel routing. The transfer carries the transcript and any context the bot captured, so the agent who picks up sees the full history instead of starting cold. Because a blank bot built from scratch already includes the Transfer to Agent and End Chat system dialogs, the handoff path exists before you write a single custom step. The design work is in deciding when to trigger it and what to do when no agent is available. Routing to Omni-Channel assumes an agent can take the chat, and that is not always true at 2am or during a spike. A well-built bot plans the unavailable case explicitly, perhaps by offering a callback, creating a case, or pointing to self-service, rather than leaving the customer stuck waiting in a queue that no one is watching.
Returning Knowledge answers
A large share of bot conversations are really just questions with answers that already exist in your help content. Bot Actions handle this through Knowledge-oriented standard actions. Article Answers deliver FAQ-style content drawn from your Lightning Knowledge base directly in the chat, which is the classic deflection pattern. Generative Knowledge Answers go a step further: the action searches the knowledge base and uses generative AI to compose a conversational reply grounded in those articles, rather than just linking the customer to a document. Either way, the configuration ties the action to the customer's question so the right content surfaces at the right moment. This is where a bot earns its keep on volume. Every order-status or password-reset question the bot answers from Knowledge is one that never reaches a human queue. The trade-off is content hygiene. These actions are only as good as the articles behind them, so stale or thin Knowledge produces confident but wrong answers. Teams that get real value from Knowledge actions treat their article base as a living asset, not a one-time import.
Error handling and the Agentforce successor
Any Bot Action can fail. A Flow can hit an error, an Apex method can throw, an external callout can time out. The dialog should branch on the action's success or failure output and route the conversation to a graceful fallback, usually a clear message plus a transfer to a human. Without that explicit branch, the bot stalls or replies with something confusing, and customer trust drops faster than from any wording mistake. Looking forward, Agentforce is the successor surface for this whole pattern. Where an Einstein Bot fires actions along a designer-built dialog tree, Agentforce uses the Atlas reasoning engine to decide which Topics and Actions to invoke based on the user's request. The plumbing underneath is familiar: Agent Actions still wrap Flow, Apex, prompt templates, and standard actions. Customers moving from Einstein Bots to Agentforce keep their Flow and Apex investments and rewire them as Agent Actions in the reasoning-driven model. The mental shift is from scripting every path to giving the agent capable actions and letting it choose.
How to add a Bot Action to a dialog
Here is the path to add an action step to an existing Einstein Bot dialog in Einstein Bot Builder. The exact action type you pick changes the configuration panel, but the surrounding flow is the same for all of them.
- Open the dialog
In Setup, go to Einstein Bots, open your bot, and select the dialog where the action should run. The dialog canvas shows the existing message, question, and rule steps in order.
- Drag an action onto the canvas
From the Dialog Component Library, drag an action component to the spot in the conversation where it belongs. Give the step a clear name in the Step Properties panel so later steps can reference it.
- Choose the action type and target
Pick the action type: Object Search, an external service, a standard invocable action, an autolaunched Flow, or an Apex invocable method. Select the specific Flow, method, or object the action will run against.
- Map input and output variables
Fill each input from a bot variable, slot, or constant, and store each output in a variable that later steps can read. For Apex inputs, remember that typed-in constants are treated as strings.
- Branch on success and failure
Add a rule step after the action that checks its success or failure output, and route the conversation accordingly. Save the dialog and test the path in the bot preview before activating.
Reads or writes standard and custom object records so the bot works with live CRM data without custom code.
Calls a built-in invocable action directly, including Knowledge answers and notifications, with no Apex or Flow wrapper.
Sends and receives data with an outside API provider through a registered schema, codelessly.
Runs an autolaunched Flow with mapped inputs and outputs; the preferred home for non-trivial admin logic.
Invokes an InvocableMethod for complex logic or custom integrations, subject to the bot's timeout and call limits.
- A single Apex action times out at 10 seconds, total bot response processing is capped at 20 seconds, and only 50 Apex calls run before the next outbound message. Keep action logic lean.
- Custom values typed into an Apex input are interpreted as strings, which causes silent type mismatches if the method expects a number or boolean.
- Outputs allow up to five levels of nested objects but inputs allow only one level, so flatten complex input structures before mapping them.
- Always add a failure branch. An unhandled Flow error or Apex exception leaves the bot stalled or confusing instead of gracefully transferring to a human.
Trust & references
Cross-checked against the following references.
- Set Up a Dialog Action StepSalesforce
- Understand Einstein Bot DialogsSalesforce
Straight from the source - Salesforce's reference material on Bot Action.
- Create an Einstein BotSalesforce
- Compare Einstein Bots with Agentforce Service AgentSalesforce
Hands-on resources to go deeper on Bot Action.
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 Action in Einstein Bots?
Q2. Which of these is NOT a typical Bot Action type?
Q3. How are Bot Actions used to build a dialog?
Discussion
Loading discussion…