Everything Is a Workflow
Most tooling models either the automated parts of a process or the manual parts. The insight that changed how I think about this: they are all just nodes in the same graph.
I've been working on a workflow migration recently. The details are specific to where I am now, but the shape of the problem is familiar: steps with dependencies, steps that can parallelise, rollback conditions, success criteria, and a mixture of things a machine does and things a human decides.
That last part is the bit I keep thinking about.
Two Things That Stuck
A while back our team sat through a vendor presentation on pipeline templates — the idea being that if you abstract your pipeline definitions into reusable templates with well-defined inputs and outputs, you can compose complex automation out of simple building blocks and share them across teams without duplicating logic. Less copy-paste YAML, more composable primitives. Every vendor pitch eventually arrives at "stop copy-pasting YAML," and every time, the room nods like it's the first time we've heard it.
Around the same time a workflow orchestration vendor came in to walk us through their platform. We were already using it, but this was the first time I'd seen the GUI editor properly demonstrated. What struck me wasn't the feature set. It was the framing.
In their model, a workflow is a sequence of tasks. Some tasks are automated. Some tasks are human. You can model a workflow that runs a deployment script, waits for an approval, sends a notification, executes a test suite, then waits for an engineer to manually validate something before continuing.
Automated and manual. Mixed. In the same graph.
That shouldn't have been a revelation. But it was.
The Gap We Don't Talk About
Most CI/CD tooling models the automated parts of a process. Ticketing systems model the manual parts. Documentation holds the context that explains why those two things relate to each other.
In practice, most real processes are a mixture. A deploy might be automated end-to-end in the happy path, but require a human sign-off for certain environments, or a manual validation step after a config change, or an on-call engineer to confirm that downstream systems look healthy before the pipeline continues. These steps don't disappear because your CI/CD tool can't represent them — they just live outside the tool, in someone's head or a runbook or a Slack message.
What that demo made visible is that these are all just nodes in the same workflow graph. The human task isn't a gap in your automation. It's a first-class step with inputs, outputs, an assignee, and a timeout.
Two Angles, Same Idea
The two presentations pointed at the same insight from different directions.
The pipeline templates were about abstraction level: if you define your pipeline at the level of intent rather than implementation, you get something composable and reusable. You stop thinking about shell scripts and start thinking about tasks and contracts.
The workflow platform was about scope: if your model is expressive enough to include human steps alongside automated ones, you can represent your entire process in one place — not just the parts a machine executes.
We were already running that orchestration platform. Which raised an obvious question: could we replicate what the templates tool does, but inside a model that was already built to capture human steps too?
Put those together and you get something interesting. A workflow model that sits above the CI/CD tool. Above the ticketing system. Above the runbook. A single graph describing the full process — who does what, in what order, under what conditions — where "who" might be a pipeline runner or it might be a network engineer with a maintenance window.
Why Stop at Deployment?
That thought kept going. A deployment pipeline is a late-stage artefact. By the time code reaches it, a lot has already happened — a project was kicked off, a repository was created, tickets were written, environments were provisioned, somebody named the Slack channel. All of that is also a workflow. It's just one nobody has drawn.
The idea then was: what if you modelled the whole thing in the same platform? From the manual task of scheduling a kickoff meeting, to creating the project repository, to generating the initial ticket structure, to standing up the deployment pipelines — one graph, start to finish. You'd be able to see the entire project lifecycle in a single view: what's done, what's blocked, what's waiting on a human, what's waiting on a machine. From conception through delivery and into iteration, visible in one pipeline.
That idea stayed theoretical. Life moved on.
What the Migration Is Bringing Back
The current task is a lot more modest. An old workflow engine is being deprecated, and we need to migrate what it does to something new. For now, the scope is config deployment — not exactly the sweeping vision from a few years ago.
But working through it is making those old ideas resurface. Because the same question keeps coming up: where does this workflow actually start?
Config deployment feels like the natural boundary until you trace it back. Before deployment there's testing. Before testing there's provisioning. Before provisioning there's procurement. Before procurement there's planning. Before planning there's someone in a meeting deciding a project exists.
None of that has to stay out of frame. The same orchestration platform sitting right there can model it — the manual steps, the automated steps, the approvals, the handoffs between teams. Planning to procurement to network setup to appliance configuration to deployment to testing, all in one place.
The workflow migration is a scoped task. But it's also a doorway.
Everything Is a Workflow
It sounds obvious when you say it. Processes are workflows. CI/CD pipelines are workflows. Runbooks are workflows. Change management procedures are workflows.
But the tooling we use treats these as separate concerns, and that separation has a cost. It hides the full shape of our processes, makes it hard to reason about end-to-end state, and encourages us to think of automation as a binary — either a step is automated or it isn't — rather than as a spectrum we're moving along over time.
The framing I keep coming back to: start with the workflow. Model the full process, human steps and all. Then automate into it, node by node, as confidence grows.
Everything is a workflow. The question is just whether you've written it down yet.