*Workflows › Build*

# Signals and chaining workflows

> Two ways to make a workflow start another: fire a signal that any number of workflows listen to, or call one specific workflow. In both, the caller does not wait for the result.

## Which one to use

|  | Signal | Trigger workflow |
| --- | --- | --- |
| Who starts | Every live workflow that listens to the signal. | One workflow you choose. |
| Contract | The signal declares its data once; emitter and listeners share it. | The target's own form, which the caller fills in. |
| Target must be live? | Yes: it must be live, published and listening. | No, but it must have been published at least once: the published version runs. A paused workflow can still be called. |
| Targets | Workflows with the signal trigger. | Workflows with the manual trigger or "from another workflow". |
| No listener | Not an error: nothing happens. | n/a |

## Signals

An administrator defines signals in «Workflow signals» (under the AI settings, Workflows). A signal has a name, a description and the data that travels with it: fields of type text, number, yes/no or date, like a small form. Fields of other types cannot be created in that screen, and editing a signal that already has such fields drops them.

- To fire it, add the «Fire a signal» step (the palette lists each active signal as a ready-made entry) and fill in the data. The data is checked against the signal's current definition, so a mistake shows up in the workflow that fires it.
- To listen, choose the Signal trigger and pick the signal. The listener keeps a frozen copy of the signal's data definition when you pick it, and its variables come from that copy.
- One queued run is created per listening workflow that is live and published. Zero listeners is fine.
- Renaming a signal breaks nothing: workflows refer to it by id. A signal is never deleted, only archived. An archived signal cannot be fired or picked; its existing listeners stay published, but workflows that fire it fail until it is restored.
- The table of signals shows how many workflows listen to each one, counting those that are not live.

> **Changing a signal can break its emitters and its listeners:** If you add a field to a signal, the emitters that do not fill it in start failing as soon as they run, because the data is checked against the signal's current definition. Listeners published earlier keep validating against the copy they froze, so they keep working and do not see the new field until you republish them. If you remove or change a field, a listener fails only once an emitter that was published after the change sends data in the new shape, with "the signal's data does not match the declared fields". Open and republish every listener after you change a signal.

## Trigger workflow

- The «Trigger workflow» step starts a manual workflow, or one whose trigger is "from another workflow", with the values you give it. It returns the id and state of the new run (`queued`).
- It does not wait for that run and cannot read its result. If the first workflow needs an answer, have the second one fire a signal back.
- The step is for administrators: it runs with the creator's permissions, and fails if the creator is no longer an administrator.
- Choosing a target that is any other kind of workflow answers 409 when the run starts.

## The limit that stops loops

A chain of runs is cut at ten hops. The count is shared by the three ways a run can start another: firing a signal, triggering a workflow, and a change a workflow makes that fires an event of another one.

| What starts the next hop | When the limit is exceeded |
| --- | --- |
| «Fire a signal» | The step fails: "the limit of 10 workflows chained by signals was reached". |
| «Trigger workflow» | The step fails: "the limit of 10 chained workflows was reached". |
| A change that fires an event | The event is recorded as ignored, not failed, and no run is queued. |

- The depth is stored where a workflow author cannot forge it.
- A workflow is never started by an event that one of the workflows in its own chain caused, so A fires B fires A stops on the return, before the limit.
- A workflow can still call itself, or two workflows call each other, until the limit stops them. The limit is the only protection.

---

Canonical URL: https://docs.filmo.io/workflows/signals-and-chaining  
Last updated: 2026-10-09