From the Field / Field Work
It Looked Like a Tree
Porting a Fusion scenario to Make.com wasn't just cleanup. It was an architectural reveal.
Each Clarity Audit documents a real system engagement. An architectural readout. The goal is to surface structure.
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.
The goal was to make it make sense.
The tree shape was the natural outcome of how the tool allows construction without variables or structural primitives.
From 250 to 35
When the flow was ported to Make.com, it was rebuilt 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
The numbers mattered less than what they represented. 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 was 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.
The system 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.”
Fair. And that's exactly the problem these platforms create.
They 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.
Hiding complexity isn't the same as simplifying it.
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
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.
The system needed to be understandable to someone who didn't build it. Once it was, it lasted.