Graph vs steps (legacy)
| Mode | Behavior |
|---|---|
| Graph | Visual nodes: trigger → condition nodes (Yes/No) → action nodes. If the automation has a valid graph (nodes + edges and at least one trigger node), the engine runs the graph. |
| Steps | Ordered blocks; each block has conditions and actions. If the block’s conditions fail, the entire block is skipped. |
Branching (IF / ELSE)
- Condition nodes expose true and false outputs. Wire both for a real IF/ELSE.
- If only one edge leaves a condition, the engine uses that edge for both outcomes (usually unintended).
Fan-out from an action
If one action node connects to several next nodes, the engine runs all outgoing branches in sequence (fan-out). It does not mean “pick one branch”—use a condition node to choose.Conditions
Conditions compare a field from the context (see Triggers) to a value with an operator (equals, not equals, numeric comparisons, in list, contains, etc.). The UI only offers fields that match the allowed contexts for your trigger. After actions that recalculate risk or change status, later conditions see the updated values.Saving and validation
When you save in the app or via the API, the product validates:- Synergy — trigger ↔ each action, and each immediate action → next action (Synergy).
- Graph shape — e.g. a trigger node must exist; edges must make sense for the builder.
Testing vs production
| Endpoint | Purpose |
|---|---|
POST /automations/:id/execute | Test run: synthetic event, processEvent, no standby. |
POST /automations/:id/run | Production-style for manual_execution: runAutomationById; standby and waiting responses apply when configured. |
Maintenance: Graph traversal order for synergy checks uses
getOrderedActionTypesFromGraph in workflow-synergy.ts; complex graphs with many branches should be reviewed in the builder.