# Actions

Actions can be appended to a rule to define how the processed data is handled. A rule can correspond to one or more actions, and actions need to be set with defined connectors, which means where the data is sent.

## Add Actions

After you have created the rule, click the **Next** button on the **New Rule** step page to proceed to the **New Action (Sink)** step page. On that page, select the associated Connector from the **Connector** dropdown box. The page will display different action configuration options based on the type of associated Connector selected. See the detailed action configuration examples in [Add Republish Action](#add-republish-action) and [Add Action for Forwarding Data to Target Services](#add-action-for-forwarding-data-to-target-services).

A rule can be associated with multiple actions. When you click **Confirm** to complete the action creation, a **Successful new rule** pop-up appears. If you want to add another action, you can click **Back to Rules** to proceed and select another Connector. For example, one action can forward data to Kafka while another action sends data to an HTTP service.

### Add Republish Action

The following steps demonstrate how to add an action to republish the original messages received from a topic to another topic, such as `a/1`.

1. Select **Republish** from the **Connector** dropdown box. 
2. Configure the following settings:
   - **Topic**: Set the target topic, `a/1` in this example.
   - **QoS**: Set the QoS of the republished message, `0` in this example;
   - **Retain**: Set whether to forward this message as a retained message; for this tutorial, keep the default setting, `false`;
   - **Payload**: Enter `${payload}`, indicating the republished message will have the same payload as the original message, without any modifications.
   - **MQTT 5.0 Message Properties**: Click the toggle switch to configure the user properties and MQTT properties as necessary. The properties options allow you to add rich message metadata descriptions for the republished message.
     - **Payload Format Indicator**: Enter a value to indicate whether the payload of the message is in a specific format. When the value is set to `false`, the message is considered as undetermined bytes. When set to `true`, it indicates that the payload within the message body is UTF-8 encoded character data. This will help MQTT clients or MQTT servers parse message content more efficiently without the need for explicit formatting or type identification for the message body.
     - **Message Expiry Interval**: Enter a value (in seconds) to specify a time interval after which the message should expire and be considered invalid if it hasn't been delivered to the intended recipient.
     - **Content Type**: Enter a value to specify the type or format of the payload content within the republished message (MIME type), for example, `text/plain` represents a text file, `audio/aac` represents an audio file, and `application/json` signifies an application message in JSON format.
     - **Response Topic**: Enter the specific MQTT topic to which you want the response message to be published. For example, if you want responses to be sent to a topic named "response/my_device," you would enter: `response/my_device`.
     - **Correlation Data**: Enter a unique identifier or data to correlate a response message with the original request message. For example, you could enter a unique request identifier, a transaction ID, or any other information that is meaningful in your application context.
3. Click **Confirm** to complete the action creation.
4. In the **Successful new rule** pop-up, click **Back to Rules** to complete the rule creation. 

To create and test a complete data integration process with a message republish action, see [Message Republish](./republish.md).


### Add Action for Forwarding Data to Target Services

You can also add actions to forward the processed results to target services using associated Connectors. On the **New Action** step page, select the target Connector from the Connector drop-down list. For details on the action configuration, see [Ingest MQTT Data into HTTP Server](./http_server.md) and [Stream MQTT Data into Apache Kafka](./kafka.md).

## Fallback Actions

::: tip Note

The Fallback Actions feature is available for EMQX versions 5.91 and later in the Dedicated and Dedicated Flex edition.

:::

You can define one or two (at most) fallback actions for any given action. These fallback actions will be triggered when the primary action fails to process a message. This mechanism helps improve data reliability and observability by allowing messages to be redirected to secondary targets such as another Sink or a republish action.

Fallback actions can be used to:

- Forward failed messages to a backup data system (e.g., another Sink).
- Republish failed messages to a monitoring topic for troubleshooting or alerting.
- Minimize data loss in the event of temporary issues with the primary action.

### Key Characteristics

- Fallback actions are triggered only when the primary action fails to process a message. Failures include delivery errors, buffer overflow, and request TTL expiry.
- They always operate in asynchronous request mode, regardless of their own configuration.
- If two fallback actions are defined, they will be triggered concurrently. EMQX Cloud does not attempt them one-by-one or stop at the first success.
- Fallback actions share the same buffering mechanism as regular actions, meaning messages are retried up to their request TTL or if there is buffer overflow.
- Fallback actions do **not** trigger further fallback actions. If a fallback action itself fails, its own configured fallback actions (if any) will **not** be triggered.
- Processing of messages by fallback actions do not affect metrics of their primary actions or of the original rule that triggered the primary action.