Skip to content

Workflows

A workflow is the central unit of automation in Orvanta — a script running standalone, or a flow: a directed acyclic graph (DAG) of steps, where each step runs a script, branches, loops, calls another flow, or runs an AI agent.

Trigger → Node A → Node B ──→ Node C
└──→ Node D (parallel branch)

Each workflow has:

  • A unique path and name. Used to reference the workflow in the CLI and API (e.g. f/folder/my_workflow).
  • Steps. Individual nodes connected in sequence, with branches and loops where needed.
  • Input transforms. Define, per step, where each argument’s value comes from — a static value, the flow’s own input, or a previous step’s result.
  • Triggers. Determine when the workflow runs (manual, scheduled, webhook, or API call).
TypeDescription
ScriptRuns a versioned script (by path) or inline code, in any supported runtime (Bash, Python, TypeScript, Go, …).
Branch one / Branch allRoutes execution down one matching branch, or fans out across every branch, based on a condition.
For loop / While loopRepeats a set of steps over an iterator or until a condition is no longer met, optionally in parallel.
Sub-flowInvokes another flow by path and waits for it to complete.
AI agentRuns an LLM-driven agent step with access to a defined set of tools.
IdentityPasses its input through unchanged — useful as a placeholder or branch default.

Any script or flow step can also act as a human-in-the-loop gate by returning resume/cancel URLs from its own logic — there’s no separate “approval” node type. See Approval steps.

Workflows can be triggered in four ways:

  1. Manual. Via the UI Run button or orvanta flow run.
  2. Scheduled. Cron expression defined on the workflow.
  3. Webhook. An inbound HTTP POST to the workflow’s unique webhook URL.
  4. API. Programmatic trigger via the REST API.

Every workflow change is versioned. You can pin a trigger to a specific version or always run the latest. Previous versions remain available for audit and rollback.