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.

In addition to these actions, NLU-based assistants can leverage these actions:

action_deactivate_loop

This action deactivates the active loop and resets the requested slot. This is used when handling conversation repair in forms.

note

If you wish to reset all slots, we recommend using a custom action that returns the AllSlotsReset event after form deactivation.

action_two_stage_fallback

This is a fallback loop that can be used to handle low NLU confidence. Read more about handling low NLU confidence.

action_default_ask_affirmation

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.

action_default_ask_rephrase

This action is used by the action_two_stage_fallback loop if the user denies the intent action_default_ask_affirmation displays. It asks the user to rephrase their message.

action_back

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.

Form Action

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.

action_unlikely_intent

Rasa triggers action_unlikely_intent via UnexpecTEDIntentPolicy. You can control how often this action is predicted by tuning the tolerance parameter of UnexpecTEDIntentPolicy.

Customization

You can customize your assistant's behaviour to configure what should happen once action_unlikely_intent is triggered. For example, as a follow up you can trigger a hand-off to a human agent with a rule:

- rule: trigger human handoff with action_unlikely_intent
steps:
- action: action_unlikely_intent
- action: ask_human_handoff
- intent: affirm
- action: trigger_human_handoff

Alternatively, you can also override it's behaviour as a custom action by adding action_unlikely_intent to the list of actions in the domain and implementing the custom behaviour:

class ActionUnlikelyIntent(Action):
def name(self) -> Text:
return "action_unlikely_intent"
async def run(
self, dispatcher, tracker: Tracker, domain: Dict[Text, Any],
) -> List[Dict[Text, Any]]:
# Implement custom logic here
return []
note

Since action_unlikely_intent can be triggered at any conversation step during inference, all policies which are trained on only story data, for example - TEDPolicy, UnexpecTEDIntentPolicy, MemoizationPolicy ignore its presence in the tracker when making a prediction. However, RulePolicy takes its presence into account so that conversation behaviour is customizable.

note

action_unlikely_intent cannot be included in the training stories. It can only be added to rules.

action_extract_slots

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.

If 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 extracted slots.

Note that custom actions used by slot mappings or slot mapping validation should only return events of type SlotSet or 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 FormAction. 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.