# Documentation for Rasa Open Source Project

You are viewing documentation for our open source project which is maintained by the community. If you want to get started building assistants with Rasa please check out our latest [documentation here](/content/docs/index.html).

## 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](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/custom-actions) whose `name()` method returns the same name as the default action:

```python
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:

```yaml
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](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/rules) 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](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/domain#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:

```python
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`:

```python
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")]
```

### New in 2.3
The slot `session_started_metadata` was added.

## 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](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/fallback-handoff) enabled.

## action_deactivate_loop
This action deactivates the active loop and resets the requested slot. This is used when [handling unhappy paths in forms](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/forms#writing-stories--rules-for-unhappy-form-paths).

### Note
If you wish to reset all slots, we recommend using a custom action that returns the [`AllSlotsReset`](/content/docs/rasa/reference/rasa/shared/core/events#allslotsreset-objects/index.html) event after form deactivation.

## action_revert_fallback_events
### Deprecated!
The `action_revert_fallback_events` action is deprecated since the 2.0 release. The [`action_two_stage_fallback`](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/default-actions#action_two_stage_fallback) action now handles all [two-stage fallback behavior](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/fallback-handoff).

## 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](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/fallback-handoff#nlu-fallback).

## 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](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/policies#rule-policy) is configured.

## Form Action
By default Rasa Open Source uses `FormAction` for processing any [form logic](/content/docs/rasa/2.x/forms/index.html). 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 Open Source 1 to 2. In this case, you can override the default action to instruct Rasa Open Source to use the deprecated `FormAction` which is part of the Rasa SDK.

## action_unlikely_intent
### New in 2.8
`action_unlikely_intent` was added together with `UnexpecTEDIntentPolicy`. Rasa Open Source triggers `action_unlikely_intent` via [`UnexpecTEDIntentPolicy`](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/policies#unexpected-intent-policy). You can control how often this action is predicted by tuning the [`tolerance`](/content/docs/rasa/2.x/policies#unexpected-intent-policy/index.html) 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:

```yaml
- 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 its behaviour as a [`custom action`](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/custom-actions) by adding `action_unlikely_intent` to the list of actions in the domain and implementing the custom behaviour:

```python
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](https://legacy-docs-oss.rasa.com/docs/rasa/2.x/default-actions#customization-1).

### Note
`action_unlikely_intent` cannot be included in the training stories. It can **only** be added to rules.