Flow Authoring

Breyta flow authoring guide for production workflows: structure definitions, publish safely, configure runtime requirements, and promote releases.

Quick Answer

Author in a strict sequence: define shape, push updates, configure + check runtime requirements, optionally validate, release an immutable version, then run.
Keep orchestration thin in :flow and move shaping logic/content into :functions and :templates as complexity grows.

Do This Now

Design your flow in this order:

define :slug and :name
set :concurrency
add :triggers
declare :requires
implement :flow with deterministic logic

What This Does

keeps flow behavior predictable
separates runtime bindings from authoring
reduces replay and debugging issues

For the exact command lifecycle (push/validate/release/configure/run), use CLI Workflow.

When To Use

Use this once your first flow works and you need production-ready structure.

Advanced Options

keyed concurrency
multi-trigger flows
reusable requirements/bindings
templates for prompts, request bodies, and SQL
function refs for reusable deterministic transforms
:persist refs for data-heavy step outputs that can exceed inline limits
child-flow orchestration with flow/call-flow for complex branches

Production Pattern: Parent + Child Flows

When a single :flow starts mixing ingress logic, routing, and domain application behavior, split it:

parent flow does ingress + normalization
parent delegates specialized branches with flow/call-flow
each child flow owns one domain concern (routing, apply/update, reporting)

This keeps orchestration readable and reduces duplicate branching logic across flows.

Common Anti-Patterns

adding bindings commands before push succeeds
hiding side effects in non-step code
changing many steps at once without isolation checks
using unclear step ids that make timelines hard to read