> ## Documentation Index > Fetch the complete documentation index at: https://docs.enginy.ai/llms.txt > Use this file to discover all available pages before exploring further. # Triggers > Choose how a workflow starts: run it manually, on a schedule, from a webhook, or when something happens in Enginy. Every workflow starts with a trigger. It decides when a run begins and, for intent signals, which contact or company the run is about. Configure it from the trigger card at the top of the canvas — changes stay in draft until you publish. Triggers come in two families: **trigger types** (you or an external system starts the run) and **intent signals** (something happening in Enginy starts the run). ## Trigger types

Manual run

Trigger the workflow on demand from the editor. This is the default for workflows you run yourself, like one-off list builds. **Settings** | Setting | Required | What it controls | | -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Ask at runtime | No | "Don't ask" runs the first step as built. "Select contacts" / "Select companies" prompts you to pick a list every time you run the workflow, instead of hard-wiring one. | Once the workflow has steps after the entry block, the Ask at runtime choice is locked — remove the later steps to change it.

Recurring schedule

Run automatically on a fixed cadence. Use it for workflows that should keep themselves up to date, like refreshing a list or re-checking open positions. **Settings** | Setting | Required | What it controls | | ---------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------- | | Frequency | Yes | Daily, weekly, monthly, or yearly, with a "repeat every N" interval. | | Days of the week | Weekly only | Which weekdays the run fires on (at least one). | | Monthly mode | Monthly only | Same day of the month as the first run, or an ordinal weekday (e.g. second Tuesday). | | First run | Yes | The date and time of the first run. Later runs keep this wall-clock time in your timezone, across daylight saving changes. | | Ends | No | Never, on a date, or after a number of runs. |

Webhook received

Start the workflow whenever an external event hits a URL. This is how other systems — your product, your CRM, an automation platform — start Enginy workflows. How it works: 1. **Delivery URL** — publishing the workflow generates a unique URL to send `POST` requests to. Copy the URL, the secret, or a ready-made cURL command from the trigger drawer. 2. **Request validation** — every request must carry the workflow's secret in the `x-enginy-webhook-secret` header, or it is rejected. 3. **Request body** — the trigger drawer shows the exact JSON body the workflow expects, based on the inputs you declare. **Declared inputs** let the request body feed the workflow: | Input type | What happens | | -------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Contact IDs / company IDs | Seed the first step with those records (up to 10,000 per request). | | Contact payload / company payload | Automatically adds an "Import contact/company" step that creates or matches the record from the payload. | | Value inputs (text, number, choice, …) | Bind to the same-named setting on a step, so the caller controls it per request. | **Requirements**: the workflow must be published before the delivery URL exists, and the first step must accept the kind of input you declare — the drawer flags mismatches before you can save. ## Intent signals Intent signals start a run for the specific contact or company the event is about: Enginy wires a locked "Select" entry node for you, so each event feeds exactly one record into the flow. Contact signals and company signals can't be swapped while the workflow has steps after the entry block — the canvas is already typed to one entity. Remove the later steps to switch.

When a contact replies

Run when a contact replies to a conversation. Use it to route engaged contacts — notify the owner, create a CRM task, or move them to a nurture list the moment they answer. **Settings** | Setting | Required | What it controls | | ---------- | -------- | -------------------------------------------------------------------------------------- | | Reply tags | No | Only fire for replies classified with these tags (e.g. interested). Empty = any reply. | | Identities | No | Only fire for conversations on these identities. Empty = all identities. |

When a company visits your site

Run when a company is identified from a website visit — a strong buying signal you can act on while it's fresh. **Settings** | Setting | Required | What it controls | | ------------------ | -------- | --------------------------------------------------------------------------------------------------------- | | Minimum confidence | No | Only fire when the visitor identification is at least this confident (Any, Low, Medium, High, Very high). | **Requirements**: available once website-visitor tracking is configured for your workspace — the option doesn't appear in the trigger drawer before that.

When a contact is created

Runs when a new contact is created in Enginy, whatever created it — an import, an enrichment, the API, or another workflow. No settings; every new contact starts a run.

When a company is created

Runs when a new company is created in Enginy. No settings; every new company starts a run.

When a contact property is updated

Runs when selected contact properties change. Use it to react to meaningful field changes — a status flipping, an owner being set, an email getting verified. **Settings** | Setting | Required | What it controls | | ------------------ | -------- | ----------------------------------------------------------------------------------------------------- | | Watched properties | Yes | Which contact properties to watch — the run fires when any of them changes. At least one is required. |

When a company property is updated

Runs when selected company properties change. **Settings** | Setting | Required | What it controls | | ------------------ | -------- | ----------------------------------------------------------------------------------------------------- | | Watched properties | Yes | Which company properties to watch — the run fires when any of them changes. At least one is required. |

When a contact is added to a list

Runs when a contact is added to a list. Combined with an "Add to list" action in another workflow, this is the standard way to chain automations off a list. **Settings** | Setting | Required | What it controls | | ------- | -------- | ----------------------------------------------- | | Lists | Yes | Which lists to watch. At least one is required. |

When a company is added to a list

Runs when a company is added to a list. **Settings** | Setting | Required | What it controls | | ------- | -------- | ----------------------------------------------- | | Lists | Yes | Which lists to watch. At least one is required. | ## Next steps What the workflow does with the records once it starts. How triggers, steps, and branching fit together.