Workflow Builder
From conversation to production workflow
Enterprise teams knew exactly what they needed to automate. The problem was they couldn’t build it themselves — every workflow lived behind an engineering ticket and a sprint queue. I defined and shipped a conversational AI wizard that changed that.
- AI Product Management
- Enterprise SaaS
- Conversational AI
- No-Code Automation
- Cortx
ROLE
Product Manager
Associate
Associate
PRODUCT
Cortx — AI Control Plane
for Enterprises
for Enterprises
Timeline
One Quarter
(13 Sprints)
Tools
Workflows in Production
0
+
Faster Product Development
0
%
Reduction in Dev Costs
0
%
THE PROBLEM
Everyone knew what to build. Nobody could build it.
Enterprise workflow creation had a dependency problem — and it wasn’t subtle. The people who understood the business processes best had zero ability to build the workflows themselves. And the people who could build them — engineers — were always working on something else.
Every new workflow, regardless of complexity, had to go through the same bottleneck: describe it in a ticket, wait for a sprint, review the output, iterate, ship. A simple three-step approval flow and a complex multi-agent automation were treated identically. Both had to wait. And a quiet culture of “we’ll automate that later” meant most automation never happened at all.
There were five specific failure points I identified in discovery:
Engineering as the only path to production
No workflow could be built without an engineering ticket. There was no self-serve layer — non-technical users had no way to define and activate a workflow without going through the dev team.
No standard workflow structure
Different engineers built workflows differently. No consistent node structure, no common framework, no shared language between business and technical teams for describing what a workflow should do.
No accountability layer baked in
Enterprise workflows involve multiple people at multiple steps. But there was no standard for who executed each step and who signed off on it. Accountability was assumed, not enforced.
New capabilities required new engineering work
When a workflow needed a capability that didn’t exist yet — a new AI agent — the entire workflow was blocked until that agent was separately scoped, built, and shipped.
Business teams had no visibility and no agency
Teams couldn’t see the status of their requests, couldn’t prototype what they wanted, and couldn’t iterate without going back to the engineering queue. Every change was a new ticket.
THE PROBLEM
Everyone knew what to build. Nobody could build it.
Enterprise workflow creation had a dependency problem — and it wasn’t subtle. The people who understood the business processes best had zero ability to build the workflows themselves. And the people who could build them — engineers — were always working on something else.
Every new workflow, regardless of complexity, had to go through the same bottleneck: describe it in a ticket, wait for a sprint, review the output, iterate, ship. A simple three-step approval flow and a complex multi-agent automation were treated identically. Both had to wait. And a quiet culture of “we’ll automate that later” meant most automation never happened at all.
There were five specific failure points I identified in discovery:
Engineering as the only path to production
No workflow could be built without an engineering ticket. There was no self-serve layer — non-technical users had no way to define and activate a workflow without going through the dev team.
No standard workflow structure
Different engineers built workflows differently. No consistent node structure, no common framework, no shared language between business and technical teams for describing what a workflow should do.
No accountability layer baked in
Enterprise workflows involve multiple people at multiple steps. But there was no standard for who executed each step and who signed off on it. Accountability was assumed, not enforced.
New capabilities required new engineering work
When a workflow needed a capability that didn’t exist yet — a new AI agent — the entire workflow was blocked until that agent was separately scoped, built, and shipped.
Business teams had no visibility and no agency
Teams couldn’t see the status of their requests, couldn’t prototype what they wanted, and couldn’t iterate without going back to the engineering queue. Every change was a new ticket.
TWO USERS, ONE PRODUCT
The non-technical builder and the power user
The non-technical builder
Ops leads · Business analysts · PMs
They know exactly what they want to automate — the steps, the owners, the approvals — but have never touched a node canvas or written a line of automation logic. What they needed: a conversational experience that asks smart questions, interprets their intent, and builds the workflow for them — with a confirmation step at every node so they always feel in control.
Design principle: the wizard should feel like a capable colleague asking smart questions — not a form to fill out.
The Power User
Technical PMs · Solution architects
They know what they’re doing. They don’t need a wizard walking them through every step — they want direct access to node configuration, fast. What they needed: an advanced mode that bypasses the wizard entirely and lets them build directly on the canvas, with the same underlying framework, just without the guided scaffolding.
Design principle: same product, different front door. No feature gates, no separate SKU — just 2 entry points into the same builder.
The two-mode decision wasn’t just a UX call. Enterprise tools that only serve power users leave most of the organisation behind. Tools that only serve non-technical users frustrate the people who need depth. Both groups existed at every enterprise client — the right answer was both.
THE SOLUTION
A conversational wizard that builds production-ready workflows
Workflow Builder is a conversational AI wizard inside Cortx that interviews the user about the workflow they want to build, interprets their intent, and generates a fully structured node-based workflow — with a human confirmation checkpoint at every step. The user describes what they need in natural language. The wizard asks clarifying questions when it needs more context. Nothing is built without the user’s knowledge. Nothing is locked without their approval.
The node framework
Every workflow is built from a consistent set of node types — input, process, approval, and output. Each node carries the same properties: what happens at this step, who executes it (the maker), and who signs off on it (the checker). This maker/checker framework is the accountability layer baked into every workflow at the structural level — not added as an afterthought.
Sub-workflows — building new agents on the fly
When the wizard detects that a workflow step requires a capability that doesn’t exist yet, it doesn’t block. It surfaces the gap, explains what’s missing, and guides the user through building a sub-workflow that creates that agent in context — without leaving their main workflow. Once complete and validated, the parent workflow continues. This was the feature that made self-serve workflow building genuinely self-serve.
The result
Non-technical users building production-ready AI workflows in minutes. No engineering ticket. No sprint wait. No dependency. 50% faster solution shipping across three enterprise clients from day one of rollout.
HOW IT ALL CAME TOGETHER
The Product work behind
Week 1–2
Discovery — mapping the bottleneck
Structured conversations with enterprise users experiencing the workflow creation gap firsthand. Consistent finding: users weren’t lacking ideas — they were lacking access. Mapped the full dependency chain from workflow request to production activation and timed each step.
Week 3
Defining the two user profiles
Synthesised discovery into two distinct profiles with fundamentally different needs and mental models. Made the call to design one product with two entry points rather than two separate tools. This became the organising principle for every design and engineering decision that followed.
Week 4–5
Defining the maker/checker model
Defined the complete node data model: node types, properties, maker/checker assignment logic, and sub-workflow trigger conditions. Ran alignment sessions with engineering and design — separately — before any code was written.
Week 6
Briefing design
Briefed the design team across five workstreams: the conversational wizard flow, the node canvas, the maker/checker assignment interface, the sub-workflow trigger state, and the two-mode entry point. Reviewed every iteration before it went to engineering.
Week 7–10
Build and QA
Coordinated with engineering across three workstreams: the conversational wizard, the node framework, and the sub-workflow engine. Built the edge case matrix before QA started — defining expected behaviour for ambiguous inputs, missing assignees, circular dependencies, and sub-workflow failures.
Week 11–12
Ship, GTM, and documentation
Wrote all help documentation covering the wizard flow, node types, maker/checker assignment, and sub-workflow creation. Created the feature demo video used for client onboarding and sales. Aligned GTM messaging around the core proposition: build production-ready AI workflows in minutes — no engineering required.
KEY DESIGN DECISIONS
The calls that shaped the product
01 — AI autonomy
Suggest, never decide
The wizard makes suggestions at every step — which nodes to create, how to structure each step, who to assign as maker and checker — but never proceeds without explicit user confirmation. Each node is a checkpoint. I considered full wizard autonomy: let the AI build the complete workflow from a single prompt, show the output, let the user edit after.
Why I didn’t: Trust is earned in stages. If the first workflow the wizard builds has three nodes wrong, the user doesn’t come back. The checkpoint model means every suggestion is small and verifiable — users catch mistakes early and build confidence in the system over time. Autonomy can increase once trust is established. It can’t be assumed upfront.
02 — Sub-workflows
In v1, not v2
Including sub-workflow functionality in the first release added significant complexity. I could have deferred it — shipped the core wizard and node builder first, added sub-workflows in a follow-up sprint. The standard PM instinct is to simplify v1 and defer what you can.
Why I didn’t: Without sub-workflows, users would hit a hard wall every time a workflow step needed a new agent capability. That wall would have made the product feel unfinished at exactly the moment users were most engaged — mid-workflow, invested in what they were building. Some features aren’t deferrable without undermining the core value. Sub-workflows were load-bearing.
03 — Entry points
Two modes over one
I could have built a single experience — pick either guided or advanced, not both. Simpler to design, simpler to build, simpler to explain. Some stakeholders pushed for this. The counterargument was real: two modes adds surface area, adds edge cases, adds documentation complexity.
Why I didn’t: Enterprise tools that only serve power users leave most of the organisation behind. Tools that only serve non-technical users frustrate the people who need depth. Both groups existed at every enterprise client. Building one mode would have meant a conscious choice to exclude half the user base — same product, different front door was the right answer.
KEY DESIGN DECISIONS
The calls that shaped the product
Every possible node type at launch
I scoped v1 to four node types: input, process, approval, and output. There were requests for more — conditional branching, parallel execution, scheduled triggers. I deferred all of them. The principle: launch with a framework that works reliably for the most common use cases, then extend. Shipping twelve node types would have added engineering complexity without adding proportional user value — most users would never touch eight of them in their first month.
A separate product for power users
The initial instinct from some stakeholders was to build the advanced mode as a separate, more technical product. I pushed back. A separate product would have created two codebases to maintain, two user bases to support, and a positioning problem — which one do you sell? The same-product-different-front-door model kept the team focused and gave power users a path to the guided experience when they needed to onboard someone new.
AI-assigned maker/checker without user confirmation
There was a conversation about letting the wizard auto-assign makers and checkers based on org data and context — skipping the confirmation step for efficiency. I said no. Accountability is the entire point of the maker/checker framework. If users don’t consciously assign those roles, they don’t feel ownership over them. And if something goes wrong at a node, “the AI assigned that” is not an acceptable answer in an enterprise context.
LEARNINGS
What I'd carry forward
01
Designing for two users is harder than designing for one — and almost always the right call. The temptation is to pick a primary user and optimise for them. The better question is: who gets left behind if you do?
02
Deferred complexity isn’t always safe complexity. Some features aren’t deferrable without undermining the core value. Sub-workflows were load-bearing — shipping without them would have made the product feel broken at exactly the wrong moment.
03
The maker/checker framework worked because it was structural, not procedural. Accountability baked into the workflow at the node level is fundamentally different from accountability guidelines. One is enforced by the system. The other is forgotten by lunchtime.
04
I’d measure trust-building more explicitly next time. The checkpoint model was the right call. What I didn’t do was instrument that hypothesis — tracking how user behaviour changed as they got more familiar with the wizard. I’d build that measurement in upfront.