> ## Documentation Index
> Fetch the complete documentation index at: https://docs.solya.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflows — anatomy

> The complete structure of a workflow: nodes, edges, the flow definition, statuses, and execution model.

A **workflow** automates a reaction to your data: a **trigger** plus a chain of
**actions**, executed by the data platform. This reference documents the full model. For
the user-facing guide, see [Tags & automation → Workflows](/en/automation/workflows).

## Flow definition

A workflow stores a `flowDefinition`: a graph of **nodes** and **edges**.

```json theme={null}
{
  "nodes": [ { "id": "…", "type": "trigger", "position": { "x": 0, "y": 0 }, "data": { /* node data */ } } ],
  "edges": [ { "id": "…", "source": "<node id>", "target": "<node id>" } ]
}
```

| Element  | Shape                                                                                                |
| -------- | ---------------------------------------------------------------------------------------------------- |
| **Node** | `{ id, type, position: { x, y }, data }` — `data.nodeType` is the authority (`TRIGGER` or `ACTION`). |
| **Edge** | `{ id, source, target }` — connects node ids, defining execution order.                              |

Node `data` is a discriminated union by `nodeType` / `actionType`:

* **Trigger** — `nodeType: "TRIGGER"` → see [Triggers](/en/developers/workflows/triggers).
* **Action** — `nodeType: "ACTION"` with an `actionType` of `CREATE_OR_GET_PLAN`,
  `ADD_ITEMS_TO_PLAN`, `CALL_WEBHOOK`, or `SEND_EMAIL` → see
  [Actions](/en/developers/workflows/actions) and
  [Integrations](/en/developers/workflows/integrations).

## Workflow record

| Field            | Meaning                                     |
| ---------------- | ------------------------------------------- |
| `name`           | Display name (required).                    |
| `description`    | Optional.                                   |
| `status`         | `DRAFT` · `ACTIVE` · `PAUSED` · `ARCHIVED`. |
| `flowDefinition` | The nodes + edges graph.                    |

### Status

```
DRAFT → ACTIVE ⇄ PAUSED → ARCHIVED
```

* **DRAFT** — editable, not triggerable.
* **ACTIVE** — triggerable; only active workflows execute.
* **PAUSED** — temporarily not accepting new runs.
* **ARCHIVED** — historical.

## Execution model

A run starts from the **trigger** (which resolves the matched entities), then follows the
**edges** through the action nodes in order. Each node becomes a **step** with its own
status, resolved inputs, and output — and a node's output can feed later nodes via
[interpolation](/en/developers/workflows/integrations#interpolation). See
[Runs & examples](/en/developers/workflows/runs-and-examples).

```mermaid theme={null}
flowchart TB
  T["Trigger<br/>resolves matched entities"] --> P["CREATE_OR_GET_PLAN"]
  P --> I["ADD_ITEMS_TO_PLAN"]
  I --> W["CALL_WEBHOOK"]
  W --> E["SEND_EMAIL"]
```

An example chain — your workflow uses whichever action nodes you connect; each becomes one
step in the run.

## Validation rules

The builder enforces a few invariants:

* **Exactly one trigger** node per workflow.
* An `ADD_ITEMS_TO_PLAN` node's `planType` must **match** the `CREATE_OR_GET_PLAN` it
  references via `sourcePlanNodeId`.
* `sourcePlanNodeId` must point at an existing create-plan node.
* **No circular edges.**
* Discount percentages are bounded to `[0, 100]`.

<Note>
  Continue to [Triggers](/en/developers/workflows/triggers),
  [Actions](/en/developers/workflows/actions),
  [Integrations & interpolation](/en/developers/workflows/integrations), and
  [Runs & examples](/en/developers/workflows/runs-and-examples).
</Note>