Version: Latest

Default Actions

Default actions are actions that are built into the dialogue manager by default. Most of these are automatically predicted based on certain conversation situations. You may want to customize these to personalize your assistant.

Each of these actions have a default behavior, described in the sections below. In order to overwrite this default behavior, write a custom action whose name() method returns the same name as the default action:

class ActionRestart(Action):
def name(self) -> Text:
return "action_restart"
async def run(
self, dispatcher, tracker: Tracker, domain: Dict[Text, Any]
) -> List[Dict[Text, Any]]:
# custom behavior
return [...]

Add this action to the actions section of your domain file so your assistant knows to use the custom definition instead of the default one:

- action_restart

After adding this action to your domain file, re-train your model with rasa train --force. Otherwise, Rasa won't know you've changed anything and may skip re-training your dialogue model.


This action is predicted to signal that the assistant should do nothing and wait for the next user input.


This action resets the whole conversation history, including any slots that were set during it.

It can be triggered by the user in a conversation by sending a "/restart" message, if the RulePolicy is included in the model configuration. If you define an utter_restart response in your domain, this will be sent to the user as well.


This action starts a new conversation session, and is executed in the following situations:

  • at the beginning of each new conversation
  • after a user was inactive for a period defined by the session_expiration_time parameter in the domain's session configuration
  • when a user sends a "/session_start" message during a conversation

The action will reset the conversation tracker, but by default will not clear any slots that were set.


The default behavior of the session start action is to take all existing slots and to carry them over into the next session. Let's say you do not want to carry over all slots, but only a user's name and their phone number. To do that, you'd override the action_session_start with a custom action that might look like this:

from typing import Any, Text, Dict, List
from rasa_sdk import Action, Tracker
from import SlotSet, SessionStarted, ActionExecuted, EventType
class ActionSessionStart(Action):
def name(self) -> Text:
return "action_session_start"
def fetch_slots(tracker: Tracker) -> List[EventType]:
"""Collect slots that contain the user's name and phone number."""
slots = []
for key in ("name", "phone_number"):
value = tracker.get_slot(key)
if value is not None:
slots.append(SlotSet(key=key, value=value))
return slots
async def run(
self, dispatcher, tracker: Tracker, domain: Dict[Text, Any]
) -> List[Dict[Text, Any]]:
# the session should begin with a `session_started` event
events = [SessionStarted()]
# any slots that should be carried over should come after the
# `session_started` event
# an `action_listen` should be added at the end as a user message follows
return events

If you want to access the metadata which was sent with the user message which triggered the session start, you can access the special slot session_started_metadata:

from typing import Any, Text, Dict, List
from rasa_sdk import Action, Tracker
from import SessionStarted, ActionExecuted
class ActionSessionStart(Action):
def name(self) -> Text:
return "action_session_start"
async def run(
self, dispatcher, tracker: Tracker, domain: Dict[Text, Any]
) -> List[Dict[Text, Any]]:
metadata = tracker.get_slot("session_started_metadata")
# Do something with the metadata
# the session should begin with a `session_started` event and an `action_listen`
# as a user message follows
return [SessionStarted(), ActionExecuted("action_listen")]


This action undoes the last user-bot interaction and sends the utter_default response if it is defined. It is triggered by low action prediction confidence, if you have this fallback mechanism enabled.


If action_default_fallback is the next action predicted and executed by the assistant, this will result in a UserUtteranceReverted event which will unset the slots previously filled in the last user turn.


This action runs slot validation rules written directly in the flows yaml file. When the assistant asks the user for information in a flow, action_run_slot_rejections is executed as a step in the default flow pattern_collect_information. If the action evaluates one of the rules to True, then it will reset the originally requested slot and ask the user for the slot again by dispatching the response indicated in the utter property. If no rule is evaluated to True, then the action will retain the original value which filled the slot and the assistant will continue to the next step in the flow.



This action requires Enterprise Search policy

This action can be used to trigger the Enterprise Search Policy from any flow, rule or story. It works by manipulating the dialogue stack frame. The result of this action is an LLM generated response to the user. Enterprise Search Policy generates the response by prompting the LLM with relevant knowledge base documents, slot context and conversation transcript.

If you have an out_of_scope intent, here is how you can use this action:

- rule: Out of scope
- intent: out_of_scope
- action: action_trigger_search

In case you're using FallbackClassifier, here is how you can use this action:

- rule: Respond with a knowledge base search if user sends a message with low NLU confidence
- intent: nlu_fallback
- action: action_trigger_search


This action is needed for Coexistence of NLU-based and CALM systems. It acts as a softer version of the default action action_restart:

  • It resets all slots not marked for persistence (see section).
  • Instead of completely resetting the tracker, it hides all previous tracker events from the featurization for the NLU-based system policies. This way, things that happened in CALM won’t show up in the tracker for the NLU-based system policies, but you can still see the full tracker history in tools like rasa inspect. If the events were not hidden, the tracker would look different for the NLU-based system policies during inference than what it had looked like during training. This would result in bad predictions. One exception to the hiding of events are SlotSet events for slots that are persisted (see section).

This action also resets the slot route_session_to_calm, making sure the coexistence router is engaged again on the next incoming user message. This way the user can achieve multiple skills in a single session.


This action plays a crucial role in maintaining stack integrity following a bot update.

A bot update refers to a modification or enhancement made to the bot's codebase, typically to introduce new features, fix bugs, or improve performance. In this context, the bot version transition from A to B signifies an update being deployed to the bot, which may include changes to its behavior, responses, or underlying functionality. When a bot update occurs during an ongoing conversation, it necessitates special handling to ensure that the conversation remains coherent and unaffected by the update.

This action accomplishes this by setting all frames in the stack to the end step. Currently, it is utilized within the pattern_code_change flow.