Skip to main content
This is a documentation pilot. Confirm final interface labels, permissions, and release behaviour against the production build before publication.
A Workflow Builder flow is more than a sequence of connected steps. It carries the evidence, decisions, and responsibility for a report from one stage to the next.

One run, fixed evidence

A workflow run begins with an ingestion manifest: the specific source objects and fragment versions admitted for that run. The workflow uses that fixed evidence throughout drafting and review. If new data arrives while a reviewer is assessing the report, it belongs to a later run rather than changing the report under review.

Why review is version-bound

An agent can create a draft, and a reviewer can request changes. Each change produces another report version. Approval is therefore attached to one exact version. Loom should not publish a revised report using the approval for an earlier one. This preserves a clear decision trail: what the reviewer saw, what they decided, and what was ultimately published.

Why the start condition matters

The workflow should explain why it started. In the initial report journey, the condition requires a successful ingestion and the required enrichment results. This prevents a workflow from drafting a report with incomplete required evidence. A later recovery can complete the same manifest and then satisfy the condition.

The outcome is accountable

The final publication produces a receipt identifying the approved evidence and delivered output. That makes it possible to trace a published report back through its review decision, draft version, workflow version, enrichment results, and original input. This is the reason to use a workflow rather than pass intermediate results manually between tools: the analyst sets the purpose and reviews the outcome, while Loom carries the work and its decision trail between stages.