The mandate
A public research university’s engineering college needed a budget approval workflow, and they needed it fully automated. Students and faculty would submit requests for courses and labs. Administration would approve them. It had to read from their existing database and respect role-based access tied to their user account profiles.
Nothing about that is unreasonable. It’s the kind of request that sounds like a weekend of work right up until you try it.
What the last team tried
The college already had Microsoft Power Automate, and Power Automate has an AI assistant that generates process flows for you. The team on it before described the workflow they wanted and asked the AI to build the thing.
That began weeks of the same loop. Describe the workflow again. Re-prompt. Regenerate. Read the result, find it still didn’t work, start over.
It never worked. Not once, and not partway. Worse, it didn’t fail cleanly: the half-built flow was writing bad records into the database the whole time. So the college had a system that didn’t do its job and quietly made their data less trustworthy while not doing it. There was no fallback.
What the administrative specialist worked out
This is the part most people get wrong, and they got it right.
By the time it landed on their desk, they had already reached the conclusion themselves: the AI was the problem. So they stopped prompting it and started building the flow in Power Automate by hand.
That was the correct call, and it was more than the job asked of them. They are an administrator, not a software engineer. Building an approval flow by hand, against a live database, with role-based access tied to user profiles, is engineering work. Monday was coming either way.
So they did the second right thing and asked for help.
Sunday afternoon
The request reached us that afternoon. Spring break ended the next morning: at 8am Monday, Pacific, everyone would be back and the first budget requests would arrive. The system meant to handle them had never worked once.
There was no backup system to fall back on. There was no earlier version to roll back to. The database was already holding records the broken flow had written.
A deadline nobody could move, a system nobody could trust, and one evening to do something about it. We put a working session on the calendar for 8:00 PM that night.
Two hours and nineteen minutes
We went through it with the administrative specialist who’d been carrying this, and watched what they were actually doing.
Most of that time went on reading what was already there. The open question was not whether AI had been misapplied, because the specialist had settled that before the call. The real question was which specific steps in the workflow should use AI, and which should never have gone near it.
Only a small part of that workflow genuinely benefited from AI. The rest of it (routing, role checks, database writes) was more predictable and faster to build directly, and it needed someone who builds software for a living.
The weeks before were not lost because anyone worked too slowly. They were lost because every round of “let me re-prompt it” was a round spent making the wrong approach slightly less broken (and in some cases, much worse).
We rebuilt it that evening, with AI doing the one job it was suited for and conventional logic doing the rest. The call started at 8:00 PM. It was working at 10:19 PM. Two hours and nineteen minutes, start to finish, and the deadline was still eleven hours away.
Here is the rule: AI isn’t a panacea. It doesn’t have to be used for everything. Reach for it where it’s the best tool for the job, and leave it alone everywhere else.
What happened next
The new automated workflow went live at 8am Monday. The first request came in. The system handled it. And the next one.
Nobody had to watch it. The college is still running it to this day. The rebuilt flow is also simpler than the one they had been fighting, which is usually what happens when you stop asking a tool to do the parts it was never good at.
A week later came the part we care about more. With a working version to read, the specialist refactored a second workflow themselves, armed with what we left them.
Seeing the completed code made it infinitely easier for me to go and refactor a different one too
They are still not a software engineer. Working backwards through something that already ran taught them the pattern in a week. Weeks of fighting prompts only soured the previous team’s view of AI. It taught them bad prompting, not system design.
Who got the credit
Not us, as intended. The administrative specialist did.
They inherited a problem that had already eaten weeks. The end of spring break was looming with nothing working. They realized what was wrong with it. Then they recognised the part they could not do themselves and asked for help instead of prompting at it for another week.
Both of those are hard calls, and neither of them requires being an engineer. The foresight of the administrative specialist is the reason the workflow was live before the first request came in.
Their leadership saw a deadline met by an internal team on a system that had been failing for weeks. They did not see a consulting firm redesigning their system from scratch. This is how it should be. We are not the story here, and we do not want to be.
If you have a similar problem to our client above, the smart move is the same one they made: Ask for help.
Why this was a custom project
We didn’t build software, and we didn’t run a trade study. We didn’t go looking for a new tool either, because the one they’d already licensed was right.
They didn’t need a product. They needed somebody to look at their workflow and say which parts actually needed AI and which parts didn’t. That judgment is the whole job.