Use Your Run History to Build Better Workflows

Every workflow you build starts as a theory about how your leads behave. A Yelp message comes in, you qualify it, you text, you wait, you call if nobody replies, you book. On the canvas it looks obvious.

Then real leads run through it. People reply at 11pm. They answer a question you didn’t ask. They say “just looking” in a way your classifier reads as a hot lead. The branch you spent twenty minutes wiring never fires once.

Run history is where you find all of that out. It’s the difference between guessing at your second version and knowing what to change.

Start with the runs that failed

Filter the runs list to Failed and look at what’s actually there.

The list gives you status, the starter that kicked the run off, when it began, and how long it took. That’s enough to spot a pattern before you open anything: eight failures in a row from the same starter is a very different problem from eight failures scattered across every source.

Open one and you get the workflow as a graph, drawn from the exact version that ran. Click the node that failed and you’ll see the error message, the timestamps, the duration, and the attempt count.

That attempt count is worth paying attention to. Niche retries a failing step automatically, so a node showing attempt 3 didn’t fail once, it fought for a while and lost. A CRM push that regularly needs three attempts is telling you something about that integration that a single red badge doesn’t.

Follow the path that was actually taken

Open a completed run and look at which edges are highlighted. That’s the route this lead took through your workflow.

Do this across a handful of runs and you learn things the canvas can’t tell you:

• Branches that never fire. You built a path for commercial jobs and every run has gone down the residential side for a month. Either your classifier isn’t catching them, or that work isn’t coming through this channel.
• Branches that swallow everything. A condition meant to catch the occasional edge case is catching half your leads. The rule is looser than you thought.
• Steps everyone skips past. A node that’s always skipped is either dead weight or wired to a condition that’s never true.

The execution flow view in Metrics makes this easier at volume. It shows per-node run counts and the exit paths people take, so you can see the shape of the whole thing rather than reading runs one at a time.

Read the context, not just the steps

This is the part most people skip, and it’s where the useful answers usually are.

Open Details from this run and you get every piece of information the workflow collected, what its value ended up as, and which node set it. Select a node first and it reconstructs the context as of that step, so you see what the workflow knew at the moment it made a decision.

That distinction matters. A workflow that took the wrong branch didn’t necessarily have a broken condition. More often the condition was fine and the data feeding it was empty:

• An AI extraction node that returned nothing because the lead’s message was three words long
• A phone number that arrived in a format your CRM push didn’t accept
• A field your condition depends on that gets set two nodes after the branch that reads it

That last one is the classic. It looks like a logic bug and it’s an ordering bug, and you can only see it by checking what the context held at that specific step.

Notice where runs are sitting, not just where they stopped

Not every problem shows up as a failure. Runs marked In Progress are paused somewhere, waiting, and Niche tells you what they’re waiting for: scheduled for later, awaiting a reply, on a call, pending review.

A pile-up in one of those states is a design signal.

Twenty runs sitting in Pending review means the human review step you added as a safety net has become the bottleneck, and someone has to clear it before those leads move. Runs stacking up in Awaiting reply with no timeout means leads that ghosted you are parked forever instead of falling through to a follow-up call.

Neither shows up in your failure count. Both are costing you jobs.

Let the metrics choose your next edit

The Metrics view covers the last 7, 30, or 90 days, and it’s the fastest way to decide what’s worth your attention.

Completion rate with its change against the previous period tells you whether your last edit helped. If you tightened a condition two weeks ago and completion dropped, that’s your answer.

The run trend chart stacks completed, active, and failed by day. A spike of failures on one day usually means a provider had a bad afternoon, not that your workflow is wrong. A slow drift upward is a real problem.

Duration, broken out as median, average, and p90. The gap between median and p90 is the interesting number. A median of 90 seconds with a p90 of two hours means most leads fly through and a tail of them get stuck somewhere. That tail is where your worst customer experience lives, and it’s invisible if you only look at averages.

The lead source table breaks volume and completion out per starter, and clicking a row filters the runs list to it. If Thumbtack leads complete at half the rate of Yelp leads through the same workflow, the workflow is making an assumption that only holds for one of them.

Change one thing, then compare

Every run records the workflow version it ran on. That’s what makes the loop work: you can look at a run from three weeks ago and see the workflow as it existed then, not as it exists now.

So change one thing at a time. Tighten a single condition, add one timeout, reorder two nodes. Then come back in a week and compare completion rate and duration against the period before. If you change five things at once, you’ll know the number moved and you won’t know which edit moved it.

Before you activate an edit, run Preview in the builder. It walks the flow with simulated data so you can confirm the branching does what you expect. It’s a dry run, so it never contacts a real customer, which also means it won’t surface problems that only appear with real provider responses. Preview catches logic mistakes. Run history catches reality.

A loop worth running weekly

It takes about fifteen minutes:

1. Filter to Failed for the last 7 days. Open two or three. Look for a repeated node or a repeated error.
2. Check In Progress for pile-ups. Anything waiting longer than it should be needs a timeout or an escape path.
3. Open Metrics. Compare completion rate to the previous period, and look at p90 duration against median.
4. Check the lead source table for a starter that’s underperforming the others.
5. Open one successful run end to end and read the context. Confirm the fields you care about are actually getting populated.
6. Make one change. Preview it. Activate it.

Workflows don’t get good because someone designed them perfectly the first time. They get good because the person running them keeps reading what happened and making one more small correction.

Your run history is already recording all of it. The only question is whether you’re using it.