Skip to main content

Default Actions

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:

actions:
  - action_restart
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:

from typing import Any, Text, Dict, List
from rasa_sdk import Action, Tracker
from rasa_sdk.events import SlotSet, SessionStarted, ActionExecuted, EventType


class ActionSessionStart(Action):
    def name(self) -> Text:
        return "action_session_start"

    @staticmethod
    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
        events.extend(self.fetch_slots(tracker))

        # an `action_listen` should be added at the end as a user message follows
        events.append(ActionExecuted("action_listen"))

        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 rasa_sdk.events 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
        print(metadata)

        # the session should begin with a `session_started` event and an `action_listen`
        # as a user message follows
        return [SessionStarted(), ActionExecuted("action_listen")]

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.

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:

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

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

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

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 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.

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.

action_cancel_flow​

This action is designed to gracefully terminate an ongoing conversation flow, ensuring a clean and controlled interruption of the current flow.

When action_cancel_flow is executed, it performs the following tasks:

  • It immediately stops the execution and prevents further progression of the current flow that is in progress.
  • It cleans up any ongoing conversation context related to the cancelled flow.
  • It resets any slots that were set during the cancelled flow.

Currently, action_cancel_flow is used within the pattern_cancel_flow flow.

action_hangup​

This action is meant to be used in Voice Conversations to hang up a call. It can be used within flows to disconnect a call.

This action uses the output_channel.hangup(sender_id) method to hang up the call.

action_repeat_bot_messages​

Verbatim repeat the last bot message. It is currently used for conversation repair in two patterns:

  • pattern_repeat_bot_messages, when user requests to repeat something.
  • pattern_user_silence, when a user has been silent for a while.
Last updated on