Workflow Template

Origin & evolution

The idea descends from business process modelling. Business Process Model and Notation, first released by the Business Process Management Initiative🚀InitiativeStrategyA large coordinated effort to achieve a strategic goalView reference → in 2004 and adopted by the Object Management Group in 2006, gave organisations a shared way to draw a process once and run it many times. BPMN 2.0 (January 2011) added execution semantics, so the same diagram a business analyst drew could be handed to an engine and run.

The data-engineering world arrived at a parallel idea through code. When Maxime Beauchemin built Apache Airflow at Airbnb in 2014, the central move was to express a pipeline as a directed acyclic graph: nodes are steps, edges are dependencies⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference →, and the graph is defined once then scheduled repeatedly. A workflow template inherits both lineages. It carries the structure of a BPMN process and the as-code, version-controlled shape of an Airflow DAG.

How it works in practice

A team defines a template called release-changelog. Its trigger is "a release🚢ReleaseProduct SpecificationA shipped version of the productView reference → branch is tagged". Step one drafts release notes from merged pull requests. Step two routes the draft to a review gate🚥Review GateWorkflows & AgentsA human review checkpoint in a workflowView reference → for a human to approve wording. Step three publishes to the docs site and posts to the announcements channel. The template names three steps, one trigger, and one gate. None of those mention a specific release.

In March the team ships v2.4; in April, v2.5. Both runs follow the identical template. The April run differs only in its inputs and its log, not in its definition. When the team later decides every release also needs🫀NeedUserA user need, pain, desire, or constraintView reference → a social post🐦Social PostMarketingA social media postView reference →, they edit the template once, and the change applies to all future runs.

Workflow template vs. its neighbours

• Workflow run⏯️Workflow RunWorkflows & AgentsAn execution of a workflowView reference → is a single execution of the template, with concrete inputs and a recorded outcome🏆OutcomeStrategyA desired business or user outcomeView reference →. The template is the class; the run is the instance. One template produces many runs, the way one recipe produces many meals.
• Review gate is one element a template can contain, a checkpoint that holds the process until someone approves. The template owns the gate as part of its structure; the gate governs whether a given run advances past that point.
• Agent definition🦾Agent DefinitionWorkflows & AgentsAn autonomous agent definitionView reference → describes an autonomous actor that can carry out work. An agent definition can orchestrate a template, deciding when to run it and supplying its inputs, while the template stays the fixed score the agent conducts.

In the graph

In the Unified Product Graph, a workflow template lives in the automation region, where it acts as the durable definition that the product's automated work refers back to. A product connects to it through product_automated_via_workflow_templateProductautomated viaWorkflow Templatehierarchy; each execution is recorded by workflow_template_executed_as_workflow_runWorkflow Templateexecuted asWorkflow Runhierarchy; any human checkpoint it contains is held by workflow_template_gated_by_review_gateWorkflow Templategated byReview Gatehierarchy; and an autonomous actor that drives it is linked by agent_definition_orchestrates_workflow_templateAgent DefinitionorchestratesWorkflow Templatehierarchy. Keeping the template separate from its runs means the definition can be audited, versioned, and reasoned about on its own, while the history of what actually happened accumulates against the runs.