> ## Documentation Index > Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt > Use this file to discover all available pages before exploring further. # Send message/receive message tasks > Send message task and Receive message task nodes are used to handle the interaction between a running process and external systems. This is done using Kafka. ## Send message task This node is used to configure messages that should be sent to external systems. ![Send Message Task](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/release34/send-task_node.svg#center) ### Configuring a send message task Node configuration is done by accessing the **Node Config** tab. You have the following configuration options for a send message task: #### General configuration Inside the **General Config** tab, you have the following properties: * **Node Name** - the name of the node * **Can Go Back** - switching this option to true will allow users to return to this step after completing it When encountering a step with `canGoBack` switched to false, all steps found behind it will become unavailable. * [**Swimlane**](../../platform-deep-dive/user-roles-management/swimlanes) - choose a swimlane (if there are multiple swimlanes on the process) to ensure only certain user roles have access to certain process nodes; if there are no multiple swimlanes, the value is **Default** * [**Stage**](../../platform-deep-dive/core-extensions/task-management/using-stages) - assign a stage to the node ![General Config](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/building-blocks/node/message_send_task_action.png) To configure a send message task, we first need to add a new node and then configure an **action** (**Kafka Send Action** type): 1. Open **Process Designer** and start configuring a process. 2. Add a **send message task** node. 3. Select the **send message task** node and open the **Node Configuration**. 4. Add an **action** , the type of the action set to **Kafka Send Action**. 5. A few action parameters will need to be filled in depending on the selected action type. ![](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/release34/kafka_send_task.gif) Multiple options are available for this type of action and can be configured via the FlowX.AI Designer. To configure and [add an action to a node](../../flowx-designer/managing-a-project-flow/adding-an-action-to-a-node), use the **Actions** tab at the node level, which has the following configuration options: * [Action Edit](#action-edit) * [Back in steps (for Manual actions)](#back-in-steps) * [Parameters](#parameters) * [Data to send (for Manual actions)](#data-to-send) #### Action Edit * **Name** - used internally to make a distinction between different [actions](../actions/actions) on nodes in the process. We recommend defining an action naming standard to easily find the process actions * **Order** - if multiple actions are defined on the same node, set the running order using this option * **Timer Expression** - it can be used if a delay is required on that action. The format used for this is [ISO 8601 duration format](./timer-events/timer-expressions#iso-8601) (for example, a delay of 30 seconds will be set up as `PT30S`) * **Action Type** - should be set to **Kafka Send Action** for actions used to send messages to external systems * **Trigger Type** (options are Automatic/Manual) - choose if this action should be triggered automatically (when the process flow reaches this step) or manually (triggered by the user); in most use cases, this will be set to automatic * **Required Type** (options are Mandatory/Optional) - automatic actions can only be defined as mandatory. Manual actions can be defined as mandatory or optional. * **Repeatable** - should be checked if the action can be triggered multiple times * **Autorun Children** - when this is switched on, the child actions (the ones defined as mandatory and automatic) will run immediately after the execution of the parent action is finalized #### Back in steps * **Allow BACK on this action** - back in the process is a functionality that allows you to go back in a business process and redo a series of previous actions in the process, or for more details, check [**Moving a Token Backwards in a Process**](../../flowx-designer/managing-a-project-flow/moving-a-token-backwards-in-a-process) section ![Action Edit](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/building-blocks/node/message_send_action_edit.png) #### Data to Send * **Keys** - are used when data is sent from the frontend via an action to validate the data (you can find more information in the [User Task Configuration](./user-task-node) section) You can configure **Data to Send** option only when the action **trigger type** is **Manual**. ![Parameters](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/building-blocks/node/parameters_message_send.gif) For more information about Kafka, check the following sections: ### Example of a send message task usage Send a message to a CRM integration to request a search in the local database: #### Action Edit * **Name** - pick a name that makes it easy to figure out what this action does, for example, `sendRequestToSearchClient` * **Order** - 1 * **Timer Expression** - this remains empty if we want the action to be triggered as soon as the token reaches this node * **Action Type** - Kafka Send Action * **Trigger Type** - *Automatic* - to trigger this action automatically * **Required Type** - *Mandatory* - to make sure this action will be run before advancing to the next node * **Repeatable** - false, it only needs to run once #### Parameters Parameters can be added either using the **Custom** option (where you configure everything on the spot) or by using **From Integration** and import parameters already defined in an integration. More details about **Integrations Management** you can find [here](../../platform-deep-dive/core-extensions/integration-management/integration-management-overview). ##### Custom * **Topics** - `ai.flowx.in.crm.search.v1` the Kafka topic on which the CRM listens for requests * **Message** - `{ "clientType": "${application.client.clientType}", "personalNumber": "${personalNumber.client.personalNumber}" }` - the message payload will have two keys, `clientType` and `personalNumber`, both with values from the process instance * **Headers** - `{"processInstanceId": ${processInstanceId}}` ![](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/building-blocks/node/message_send_param1.png) ![](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/building-blocks/node/message_send_param2.png) ![](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/building-blocks/node/message_send_param3.png) ## Receive Message Task This type of node is used when we need to wait for a reply from an external system. ![Receive Message Task](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/release34/receive-task%20_node.svg#center) The reply from the external system will be saved in the process instance values, on a specified key. If the message needs to be processed at a later time, a timeout can be set using the [ISO 8601](./timer-events/timer-expressions) format. For example, let's think about a CRM microservice that waits to receive requests to look for a user in a database. It will send back the response when a topic is configured to listen for the response. ![](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/release34/kafka_receive_message.png) ### Configuring a Receive Message Task The values you need to configure for this node are the following: * **Topic Name** - the topic name where the [process engine](../../platform-deep-dive/core-components/flowx-engine) listens for the response (this should be added to the platform and match the topic naming rule for the engine to listen to it) - `ai.flowx.out.crm.search.v1` A naming pattern must be defined on the process engine to use the defined topics. It is important to know that all the events that start with a configured pattern will be consumed by the Engine. For example, `KAFKA_TOPIC_PATTERN` is the topic name pattern that the Engine listens to for incoming Kafka events. * **Key Name** - will hold the result received from the external system; if the key already exists in the process values, it will be overwritten - `crmResponse` For more information about Kafka configuration, click [here](../../../setup-guides/flowx-engine-setup-guide/engine-setup#configuring-kafka). ![Example of a Receive Message Task for a CRM integration](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/release34/message_receive_kafka_ex.png) #### From integration After defining one integration (inside [Integration Management](../../platform-deep-dive/core-extensions/integration-management/)), you can open a compatible node and start using already defined integrations. * **Topics** - topics defined in your integration * **Message** - the **Message Data Model** from your integration * **Headers** - all integrations have `processInstanceId` as a default header parameter; add any other relevant parameters ![](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/building-blocks/node/message_send_from_integr.gif) ## Related topics - [Task management setup](/4.7.x/setup-guides/plugins-setup-guide/task-management-plugin-setup.md) - [Kafka send action](/4.7.x/docs/building-blocks/actions/kafka-send-action.md) - [Start integration workflow action](/4.7.x/docs/building-blocks/actions/start-integration-workflow.md) - [Message Events](/4.7.x/docs/building-blocks/node/message-events/message-events.md) - [Node actions](/4.7.x/docs/building-blocks/actions/actions.md)