Skip to main content

​
What Is a Workflow?

In gu1, workflows are automations: WHEN [something happens] → IF [optional conditions] → THEN [run actions]. They are configured in the app (Automations / Workflow Builder) or created and updated through the Workflows API (see API Reference in the sidebar).
Workflows here are not the same as AML rules (rules engine). Rules have their own triggers and actions. A rule can start a workflow via the “when rule matches” trigger.

​
Guide (Concepts)

​
Execution Modes (Summary)

If both exist, graph takes priority over a flat steps / actions list.
  • Condition nodes: wire both true and false outputs for a real IF/ELSE.
  • Multiple edges from one action node: the engine runs all branches in sequence (fan-out), not “pick one.”

​
Standby (Short)

Standby pauses one execution until continue or cancel. It only works when the run uses runAutomationById (e.g. POST /automations/:id/run with Manual execution, rules, scheduler). Purely reactive events (processEvent) do not create a durable execution: wait does not pause on that path. See Context and standby and the API: Continue execution, Cancel execution.

​
Creating a Workflow (Product UI)

  1. Automations → New automation → pick a trigger and optional filters.
  2. Build conditions and actions (graph or steps).
  3. Save. The API validates synergy and graph shape (see Synergy).

​
Testing vs. Production Runs

  • POST /automations/:id/execute — Test run: synthetic event, processEvent, no standby.
  • POST /automations/:id/run — Production-style for manual_execution: runAutomationById; standby and waiting apply when configured.
  • API Reference (sidebar) — endpoints under /automations, starting with List automations.