I’ve been exploring different approaches to our BPM migration, and one approach that keeps coming up is using AI to generate workflows from plain-language descriptions. The idea is you write something like ‘automate our order-to-payment process with conditional approvals for orders over $50k,’ and the system generates a ready-to-run workflow.
It sounds almost too good to be true, which makes me skeptical. In my experience, the gap between a high-level requirement and production code is where most complexity lives. Edge cases, system integration, data validation—these are the things that bite you.
But if this actually works well enough to give us a head start on our migration timeline, it could be valuable even if we need to do some rework. I’m trying to figure out what percentage of a plain-language description typically translates into production-ready workflow without significant rebuilding.
Has anyone actually tried using AI to generate workflows from text descriptions? If you did, how much of the generated workflow survived contact with reality, and how much got rewritten by your engineering team?
We tried this with a fairly straightforward procurement workflow. Described it in plain text: ‘requests route to manager approval, then budget approval, then procurement, with email notifications at each step.’
The AI generated about 70% of the workflow correctly. It got the routing logic right, set up the notifications, and structured the data flow. But it missed some real-world details: we needed to support concurrent approvals instead of sequential, we had custom validation rules based on department, and the email templates needed specific fields for our system.
Engineering spent maybe two days reworking those gaps. The time we saved was in not having to describe and iterate on the high-level structure. Usually we’d spend a week going back and forth on requirements. With the generated workflow as a starting point, we just said ‘okay, that logic is right, now we handle these specific cases.’
I’d say 60-70% of the generated workflow is usually production-quality for straightforward processes. More complex workflows with multiple dependencies probably translate at 40-50%.
The honest answer: AI is really good at creating the shape of a workflow, but it struggles with the details that make it actually work in your specific environment.
We tested this on an expense approval process. The generated workflow understood approvals, routing, and notifications. But it didn’t know about our company’s policy that international expenses need an extra compliance check, or that certain departments have different approval thresholds.
What helped was treating the AI generation as a scaffolding step, not a final product. We’d generate the workflow, review it as a team to identify gaps, then either let the AI add those details or we’d engineer them directly. The time savings came from not starting from a blank canvas.
For your migration, if you have 20 processes to move, I’d estimate maybe 80% gets generated usably and 20% needs custom work for your specific business rules. That’s still time savings, but don’t expect fire-and-forget.
We ran a test where we described five different workflows in plain language and had them generated. The results varied widely. A simple email-notification workflow was like 85% production ready. A complex multi-system integration workflow was maybe 40% usable without rework.
The pattern we noticed: the AI is good at standard patterns it has seen before. Sequential approvals, notifications, branching logic—these it handles well. But anything specific to your business, your systems, or your data structure required engineering input.
What changed our timeline was using generated workflows as a foundation for code review instead of building from scratch. We’d read the generated workflow, spot the issues, and fix them. That was faster than writing from nothing and then defending our design choices in meetings.
Plain-language workflow generation works best for straightforward, pattern-based processes. Standard approval workflows, notification chains, and conditional routing typically generate at 70-80% production quality. More complex orchestrations with multiple system dependencies, custom business logic, and error handling usually need substantial rework.
The actual timeline impact is meaningful but not revolutionary. You save time on scaffolding and structure. You still need engineering for validation, integration, and edge cases. For a migration project, I’d estimate you save 20-30% of development time on workflows that match standard patterns, and little to nothing on custom processes.
The more valuable aspect is that generated workflows create a concrete starting point for discussions with stakeholders. It’s easier to say ‘this is wrong’ about something you can see than something described in writing.
Generated workflows are 60-70% production ready for simple processes. Complex workflows need significant rework. Time savings are real but not transformative—maybe 20-30% overall.
We were skeptical too, but we tested this on a dozen workflows during our migration planning. The AI Copilot took plain-language descriptions and generated actual workflow scaffolding. ‘Route order approvals based on amount, notify stakeholders, log results’—it turned that into a working workflow structure.
Here’s what surprised us: It wasn’t 100% production ready, but it was way more than scaffolding. For straightforward flows like sequential approvals and notifications, we got 75-80% of the way there. For more complex multi-system orchestrations, maybe 50%. But even at 50%, we were starting from something concrete instead of a blank canvas.
The time we saved wasn’t in avoiding engineering—we still needed engineers for edge cases and system integration. The saving was in avoiding five cycles of requirements clarification. We’d generate a workflow, review it, see what was wrong, fix it, and move forward. No meetings about misunderstanding what was supposed to happen.
For your migration, this approach probably saves you 15-25% on overall timeline, depending on process complexity. But it definitely improves clarity and reduces misalignment between business and engineering.