> For the complete documentation index, see [llms.txt](https://docs.hablla.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hablla.com/hablla-docs-en/automation-flows/all-components/hablla/internal-message.md).

# Internal message

### Overview

The **Internal Message Component** is an action node focused on private communication and back-office team coordination. Its main function is to automatically trigger structured messages or alerts into rooms, chat channels, or internal groups within the platform itself (such as team channels or open support rooms). It serves to notify operators, supervisors, or test channels about crucial events occurring in the automation journey, without this message being visible to the end customer.

### Configuration Parameters

The component's configuration defines the destination and formatting of the message that will be injected into the team's internal channel:

* **Operation:** Static system field, natively restricted to the function `Create`, which establishes that the block's exclusive purpose is the insertion of new text or media records in the internal conversation thread.<br>
* \_*Room ID (* Required Field):\_\* The unique identifier or name of the internal chat room to which the message will be sent (e.g., a channel called "test", "support\_level\_2", or a dynamic ID tag for the current room).<br>
* \_*Type (* Required Field):\_\* Defines the structural format of the data sent. The displayed standard is `Text`, but it may cover other file structures depending on the capabilities of the internal chat.<br>
* \_*Message (* Required Field):\_\* The text body of the notification. This is the field where the administrator describes the alert, instruction, or report that the internal team should receive.<br>

### Visual Builder

The graphical interface is designed for quick filling and integration with the platform's environment variables:

* **Required Field Validation:** The interface displays asterisks (`*`) in the fields of *Room ID*, *Type* and *Message*. This prevents the flow from saving or processing the node if any routing or content information is missing.<br>
* **Continuous Execution Port:** Unlike terminal components, this node has normal input and output connectors in the graphical editor. This means that after triggering the message to the support team's internal group, the flow immediately continues its execution to the next automation block.<br>

### Special Operators

The logical properties of this component manage string interpolation and silent process monitoring:

* **Dynamic Variable Interpolation:** The field of *Message* accepts the double curly brace syntax (`{{...}}`). This allows standard text to be mixed with contextual automation data (e.g., "Alert: The customer `{{cliente_nome}}` requested urgent support in room `{{sala_id}}`").<br>
* **Scope Layer Separation (Invisible Message):** The component's processing engine ensures complete channel isolation. The message generated by this node is sent strictly to the operators' internal environment, ensuring that the customer who triggered the automation has no visibility into the team's technical discussion.<br>

### Practical Examples

The table below demonstrates classic application scenarios for this component to keep internal teams informed:

| **Selected Room ID**    | **Message Type** | **Configured Content (Message)**                                                               | **Practical Use Case**                                                                                                |
| ----------------------- | ---------------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **teste**               | `Text`           | "Triage automation started for the global ID `{{id}}`."                                        | Use the test room to validate chatbot variable behavior before publishing it to customers.                            |
| **alertas\_financeiro** | `Text`           | "⚠️ ATTENTION: The customer `{{name}}` just reported an error in Pix processing."              | Immediately notify the group of administrators in the finance department about a critical payment failure.            |
| **canal\_vendas\_vip**  | `Text`           | "🚀 HOT LEAD: The contact `{{name}}` met all scoring criteria and is waiting for an operator." | Alert the sales group about the arrival of a lead with high purchase potential to speed up the time to first contact. |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.hablla.com/hablla-docs-en/automation-flows/all-components/hablla/internal-message.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.