An approval flow looks like the easy case: someone requests, someone approves, someone gets notified. It's the one that loses the most requests. Not because of the tool, but because of four design decisions that look harmless on day one.

Mistake one: marking the record before the notification goes out

The pattern is tempting. You mark the item as "notified" and then send the email, so a retry can't send it twice.

The problem is what happens when the send fails. The record already says "notified", the pending filter no longer shows it, and that request leaves the radar for good.

Nobody chases it, because nobody knows it exists.

The fix: mark it after the send confirms, and keep an intermediate state — "in progress" — for the gap between the two actions. If the flow dies halfway, the item stays visible in a review filter instead of vanishing.

Mistake two: one email per order line

When the flow loops over the lines of an order and sends inside the loop, a six-line order produces six emails. The approver gets six near-identical notifications, stops reading them at the third, and from then on the workflow is broken even though it technically works.

The fix: collect the lines first, compose a single card with a header and a line count, and send once per order. The practical rule: one notification per human decision, not per database row.

6 emailsfor a six-line order
1 notificationper human decision, not per row

Mistake three: approving without enough context

Approvals get answered from a phone, between two other things. If the notification only says "Order 2026-418 awaiting approval", the approver has to go in and find out what it is — which turns a ten-second reply into an item for the afternoon. The afternoon never comes.

The fix: put the minimum needed to decide into the notification itself — who's asking, for what, how much, by when and why — and leave the link for anyone who wants detail. If the decision can be made without opening anything, it gets made.

Mistake four: hanging the whole chain off a personal account

This is the most expensive and the most common. The flow was created under someone's account, the connections are theirs, and permissions hang off their user. It works perfectly until the day that person goes on holiday, changes department or leaves.

Then everything falls at once and nobody knows where to start.

The fix: a service account or a solution that owns the flow, permissions by group rather than by person, and documenting the real identifier of every element — not its display name, which repeats — so whoever arrives next knows what they're looking at.

What you should be able to answer

Before signing off an approval workflow, it's worth being able to answer these four:

  1. If the notification fails, where does that request show up tomorrow?
  2. How many emails does the approver get per order?
  3. Can the decision be made without opening another screen?
  4. If the person who built it isn't here, does it still run?

Whichever one has no answer is where the lost request is going to come from.

I wrote about how one forgotten action breaks a flow separately. If you have an approval workflow that's already dropping things, tell me about it or see how I take it on.