Each of these actions have a default behavior, described in the sections below.
In order to overwrite this default behavior, write a custom action
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:
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_timeparameter 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:
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
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.
This action deactivates the active loop and resets the requested slot. This is used when handling unhappy paths in forms.
If you wish to reset all slots, we recommend using a custom action
that returns the
AllSlotsReset event after form deactivation.
This is a fallback loop that can be used to handle low NLU confidence. Read more about handling low NLU confidence.
This action is used by the
action_two_stage_fallback loop. It asks the user to confirm
the intent of their message. This action can be customized to be more personalized
to your specific use case.
This action is used by the
action_two_stage_fallback loop if the user denies the
action_default_ask_affirmation displays. It asks the user to rephrase
This action undoes the last user-bot interaction. It can be triggered by the user by sending a "/back" message to the assistant if the RulePolicy is configured. |
By default Rasa uses
FormAction for processing any
form logic. You can override this default action with a custom action by
adding a custom action with the form's name to the domain.
Overriding the default action for forms should only be used during the process of
migrating from Rasa 1.0 to 2.0.
You can customize your assistant's behaviour to configure what should happen once
is triggered. For example, as a follow up you can trigger a hand-off to a human agent with a rule:
Alternatively, you can also override it's behaviour as a
custom action by
action_unlikely_intent to the list of actions in the domain and implementing the custom behaviour:
action_unlikely_intent can be triggered at any conversation step during inference,
all policies which are trained on only story data, for example -
MemoizationPolicy ignore its presence in the tracker when making a prediction. However,
takes its presence into account so that conversation behaviour is customizable.
action_unlikely_intent cannot be included in the training stories. It can only be added to rules.
This action runs after each user turn, before the next assistant action prediction and execution.
action_extract_slots loops through the slot mappings of each domain slot in order to set or update
slots throughout the conversation with information extracted from the latest user message.
action_extract_slots finds a custom slot mapping, it will check first if a custom action was defined in the
mapping via the
action key and then run it.
After applying all the slot mappings,
action_extract_slots will run the custom validation action
action_validate_slot_mappings if it is present in the domain actions. Otherwise it will immediately return the already
Note that custom actions used by slot mappings or slot mapping validation should only return events of type
BotUttered. Events of any other type are not permitted and will be ignored when updating the tracker.
The default action
action_extract_slots replaces the slot extraction previously executed by
If you wish to set a slot based on information extracted from intents that trigger forms, you must explicitly specify a
mapping that does not contain the
conditions key. A slot mapping with
conditions applies only once the specified form is active.
action_extract_slots runs directly after each user message, and thus before the activation of the form.
Therefore a mapping that should apply to user messages that trigger a form must not specify
conditions, or the form
will re-ask for the slot once it is activated.
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.