Trigger taxonomy
The trigger is the anchor of every workflow. The system surfaces the trigger question early when intent is ambiguous: “What starts this workflow?”
Trigger determines center-pane mode: UI-backed workflows show the live app; headless workflows show the test/run console.
Multi-trigger workflows
A single workflow can have more than one trigger when the trigger shapes are compatible.Data-change triggers
Data-change events fire when an entity record or field changes inside the project. They are the substrate for cross-workflow communication. Every data-change event carries:
Workflows filter on any combination. The actor metadata is load-bearing for cycle prevention: a workflow that writes to an entity and listens to changes on the same entity filters its own writes out with
actor != self.
The system proactively detects potential loops whenever a workflow is compiled or modified. If your workflow’s writes could trigger another workflow that writes back to the same entity, the advisor surfaces the loop and proposes a guard.
Authoring a headless workflow
For workflows without a UI, the center pane is the test/run console. Use it to:- Compose a trigger payload — The system generates a sample payload matching the trigger schema. Edit values to match your test case.
- Run — Fires the workflow against sandbox data. Integration calls are edge-sandboxed (never real in sandbox mode).
- Inspect the trace — The trace view shows every step, input, output, decision, and side effect. See Trace & Replay.
- Iterate — Refine in chat. Run again.
Authoring a UI-backed workflow
For workflows with a UI surface, the center pane is the live app. The rendered form or dashboard runs against sandbox data. You interact with it exactly as your users will, submit forms, and watch the trace update in real time.Deterministic vs. agentic steps
Workflows can mix deterministic steps (conditional branches, data transformations, integration calls with fixed schemas) and agentic steps (AI inference calls that produce variable output based on context). Agentic steps run through the AI Gateway — every inference call is PHI-guarded, audited, and governed by your org’s model policy. You do not specify model or provider directly; the system selects per your org’s configuration and tier. When authoring an agentic step, describe the intent:“If the intake summary indicates urgency, classify the risk level as low, medium, or high.”The system compiles a step with: model call, prompt anchored to the intake entity fields, output schema (
risk_level: enum[low, medium, high]), and an explicit confidence threshold you can tune.
Step types
You do not choose a step type directly — the system compiles one from your intent — but the contract view names it, and the trace shows it per step. The runtime supports:
Two are worth calling out because they are not obvious from a chat description:
escalationputs a human in the loop. The run pauses on an approval decision, with a timeout disposition deciding what happens if nobody answers in time. Use it for anything a clinician or compliance reviewer must sign off on.solvehands a declarative assignment or scheduling spec to the deterministic constraint solver rather than to a model. Same input always yields the same answer, and an infeasible spec comes back with the conflicting constraints named instead of a plausible-looking guess. Reach for it on rostering, slot allocation, and routing problems where “close enough” is wrong. It is also exposed directly asPOST /v1/solve.
Agent-invoked workflows
Workflows with audience Agent-callable can be invoked by anAgentCaller under delegated authority — no human in the loop. The delegating user’s authority bounds what the agent can do; the audit chain records every invocation, every tool call, and the full delegation chain. See A2A Protocol.
Step graph inspection
After the system compiles or updates the contract, the contract view (right-side panel) shows:- Each step with its type, inputs, outputs, and conditions
- Entity references and field dependencies
- Integration calls with payload schema
- Branching conditions
- The trigger definition
Common authoring patterns
Conditional routing:“If risk is flagged high, page the on-call clinician. Otherwise, assign to the next available slot.”Parallel steps:
“At the same time, notify the billing coordinator and update the scheduling system.”Error handling:
“If the EHR call fails, retry twice, then flag the record for manual review.”Schema changes:
“Add a field to track whether the patient has given consent for AI-assisted notes.”Schema changes are surfaced as explicit confirmation gates because they have migration consequences.