> 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/triggers-and-http/trigger.md).

# Trigger

### Overview

The **System Event Trigger** is the default starting point for automation flows that depend on state changes in internal records (such as in CRM) or redirect commands from the ecosystem itself. Its main function is to listen for specific events associated with the data lifecycle or receive "bridge" instructions coming from external relationship sequences and other competing automation flows.

### Configuration Parameters

The trigger configuration defines the nature of the flow input. It is managed through the following main controls:

* **Base Event Selection:** Defines which data mutation will trigger the automation. Native events include:
  * `Conversion`: Triggered when a lead or contact performs a conversion action (e.g., form fill, material download).<br>
  * `Person created`: Triggered immediately after a new contact record is inserted into the database.<br>
  * `Person updated`: Activated when any field or property of an existing contact is modified.<br>
  * `Person deleted`: Triggered when a record is removed from the system.<br>
  * `Person merged`: Executed when two duplicate records are merged.<br>
  * `Person blocked`: Triggered when communication or privacy restrictions are applied to the contact.<br>

### Visual Conditional Builder

The component has a block-structured visual rules engine to filter which records that generated the event will actually start the flow:

* **AND Block:** Groups criteria that must be simultaneously true. It is used to narrow the event (e.g., Event = `Person created` **AND** State = `SP`).<br>
* **OR Block:** Groups alternative criteria. The flow will start if any of the inserted lines matches (e.g., Channel = `WhatsApp` **OR** Channel = `Telegram`).<br>
* **Add Condition Button:** Allows nesting multiple complex logical blocks for advanced segmentations.<br>

### Special Operators and Trigger Sources

In addition to the manual and automatic registration events, this trigger responds to two special operational sources within the automation architecture:

* **Trigger via Automation Sequence (CRM):** The trigger acts as the receiving node for external campaigns or relationship sequences. When the lead reaches a certain stage in the CRM funnel, the CRM itself injects the contact directly into this trigger to start the secondary automation.<br>
* **Redirection via Bypass Component (`goTo`):** It works as an anchoring point for process reuse. A flow "A" can use a component of type `goTo` (Go To) pointing to this trigger to transfer the customer journey to the current flow, without the need to duplicate code blocks.<br>

### Practical Examples

The table below demonstrates common scenarios for using this trigger in the ecosystem:

| **Selected Event**       | **Configured Condition**       | **Practical Use Case**                                                               |
| ------------------------ | ------------------------------ | ------------------------------------------------------------------------------------ |
| **Person created**       | `None`                         | Trigger an immediate welcome message for leads coming from ads.                      |
| **Won card**             | `None`                         | Start the onboarding flow and access provisioning after purchase.                    |
| **Person updated**       | `Funnel Stage` equal to `Lost` | Move the contact to a re-engagement sequence or send a satisfaction survey.          |
| *(None - External call)* | Triggered via component `goTo` | Centralize the sending of invoices coming from 3 different sales flows in one place. |

<br>


---

# 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/triggers-and-http/trigger.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.