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:
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:
caution
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.
action_listen
This action is predicted to signal that the assistant should do nothing and wait for the next user input.
action_restart
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.
action_session_start
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.
Customization
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:
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
:
action_default_fallback
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.
note
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.
action_run_slot_rejections
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.
action_trigger_search
note
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:
In case you're using FallbackClassifier, here is how you can use this action:
action_reset_routing
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 areSlotSet
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.
action_clean_stack
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.