Porting a Fusion scenario to Make.com wasn’t just cleanup. It was an architectural reveal.
Published July 17th, 2025
Each Clarity Audit Story documents a real system I’ve worked on — not as a case study, but as an architectural readout.
The goal isn’t to celebrate fixes. It’s to surface structure.
These aren’t stories of failure. They’re stories of what the system allowed, why it behaved that way, and what changed when it was rebuilt with intent.
The fixes are just a side effect.
The flow had over 250 modules. It ran for more than an hour. And it looked like it was working.
It was built in Workfront Fusion — a no-code orchestration tool used to move project data from ServiceNow into Workfront. The job ran daily on a timer. Logic branched by project type, then by assignee, then by status and priority. Every fork spawned more forks. Each variation duplicated logic with minor edits. From a distance, it resembled a system.
This wasn’t about making it better. It was about making it make sense.
The tree shape wasn’t a mistake — it was the natural outcome, given how the tool allows construction without variables or structural primitives.
From 250 to 35
When I ported the flow to Make.com, I rebuilt it from first principles:
- A single data table replaced dozens of hardcoded routing paths
- Variables replaced repeated lookups
- Subflows replaced parallel schedules
- Failures became isolated — one bad record no longer killed the batch
- Runtime dropped from 60+ minutes to under 20
- Module count: 35
But the numbers weren’t the point. The system became governable.
It no longer depended on continuity, luck, or tribal memory.
Where the Old System Broke
Some failures were subtle.
One branch tried to pull a project’s parent — but was actually pulling the parent of the parent. The wrong ID was written across dozens of records. The logic wasn’t wrong everywhere — just inconsistent in just enough places to be dangerous.
Other failures were louder.
The original scenario was split into two scheduled flows — one to prepare, one to submit. They were designed to run in order. But the platform didn’t enforce that. If the timing slipped, they ran in parallel. The result? Every project duplicated. Every run created a second copy — and nothing deleted them.
This wasn’t edge-case chaos.
It was a system that had no concept of orchestration — only events.
It Wasn’t the Client’s Fault
The client said: “I’m not an expert in this stuff.”
That wasn’t an excuse. It was a diagnosis.
These platforms promise that business users can automate complex workflows without understanding control flow, data structure, or execution context.
They offer drag-and-drop interfaces — and conceal the architecture underneath.
But hiding isn’t simplification. It’s obfuscation.
The tools abstract away the very concepts that make systems work — and in doing so, they encourage complexity to accumulate invisibly.
Failures don’t appear when you build.
They appear when your assumptions no longer hold — and the system has no model to fall back on.
What This Really Was
This wasn’t a refactor. It was a clarity audit.
The original flow hadn’t been designed. It had grown.
Each branch solved a local problem. No one owned the shape.
There was no vantage point — just lineage.
Rebuilding forced a single question:
What is this system actually trying to do?
Once that was answered, everything got smaller.
Simpler. More durable.
And representative of the business it was meant to support.
This wasn’t about performance. It was about legibility.
And legibility is what makes systems last.