Workflow basics
How automations work in Project88 — node-based workflows that run on the server via published triggers or a manual Run.
An automation is a node-based workflow that runs on demand or on a trigger. It uses the same editor as an Agent's pipeline, but it stands alone — there's no agent attached and no conversational turn driving it, and it executes entirely on the server.
When to use an automation vs. an agent
| You have | Use |
|---|---|
| A conversation that needs reasoning each turn | Assistant |
| Per-turn execution that must be deterministic | Agent |
| A standalone workflow on a schedule, webhook, or event | Automation |
| A reusable step a chat agent might call | Automation |
You can also have an Agent delegate to an automation — an Automation is a first-class callable.
Anatomy
An automation is a graph:
- A trigger node at the top fires when the automation starts (see Triggers). The four supported runtimes are Webhook, Schedule, P88 Event, and Manual.
- A chain of typed nodes — Prompt, Process, Tool Call, Delegate, Response, REST API Request, Code, Loop, Wait, Condition, Change Variable, plus first-class record and tag operation nodes (Insert Row, Update Row, Delete Row, Query Rows, Add Tag, Remove Tag) that write through server-side handlers.
- A Response node terminates the path (or several paths if you branched).
The automationNodes.js registry defines every node type;
buildAutomationPipeline.js derives the executable graph from the
saved JSON; extractTriggerMeta.js derives the queryable
trigger_type / trigger_config columns from the trigger node.
Building one
- Open the Automations app (native surface — full-height list on the left, flow editor on the right).
- Click New in the sidebar — creates an empty graph with a Start node and drops you into the editor.
- Drop in nodes from the palette (drag-and-drop or right-click to add).
- Connect handles to wire the flow.
- Bind inputs to variables, upstream outputs, and formula functions via the ƒ binding modal on any input.
- Test — the editor's Test button runs a server dry run through the real executor (sends and row writes are stubbed).
- Save happens continuously (debounced) — the workflow is persisted to Supabase, and unsaved-state is flushed on unmount so navigation can't drop config.
- Publish — validation-gated. Fixes any issues surfaced in the Logs panel, then click Publish again.
Triggering
A saved automation needs a trigger to actually run. The runtime supports Webhook, Schedule, P88 Event, and Manual triggers today (see Triggers). Publishing without a trigger — or with an unsupported one (Heartbeat, WebSocket) — is blocked by publish validation.
Running
Two ways a run starts:
- Live — a published automation's trigger fires. Webhooks land
in the
automation-webhookedge function; schedules and events are picked up by per-minute dispatchers. - Manual — the editor's Run button executes the graph on
the server (real run, real writes) via the
automation-executoredge function. The editor's Logs panel streams status; the Runs tab refreshes when the run settles.
Runs are recorded in automation_runs (one row per execution) with
per-node detail in automation_run_events — both drive the
Runs tab. A nightly
retention cron (migration 157) trims old runs.
An idle pending-drain cron (migration 154) picks up any queued run
the dispatchers may have missed and executes it via the same edge
function, so a run can never sit in pending forever.