Forms with Approval Workflow

A form that marks an item "done" the moment a file uploads is measuring activity, not correctness. Nothing about the upload confirms the file is the right one, current, or legible.

Treating the two as the same state hides the actual bottleneck: it's rarely collection that's slow, it's review. A dashboard full of green checkmarks for unreviewed uploads makes the process look faster than it is.

The fix is structural, not a matter of trying harder to review promptly: give submitted and approved separate states in the workflow, so the two can be reported and acted on independently.

A minimal, workable set is: requested, submitted, approved, and rejected — with rejected requiring a reason before it can move again. Resist adding more states than reviewers will consistently use; an eight-state workflow usually collapses back to three in practice.

Decide up front whether an item can move straight from submitted to approved, or whether every item needs an explicit reviewer action either way. The former is faster for high-volume, low-risk items; the latter is safer where a missed error has real consequences.

Make the states visible to the client too, not just internally. A client who sees "rejected — needs a clearer scan" can act immediately; one who just sees their file sitting in a queue has no idea whether anything is wrong.

Not every item needs the same reviewer. Route by item type or by case, so a specialist sees only what falls in their remit and a generalist isn't stuck approving something they aren't qualified to check.

Set a default owner for every item at checklist creation, not after submissions start arriving. An item with no clear approver is the one most likely to sit unreviewed, because nobody considers it specifically theirs.

Build in a fallback: if the assigned approver is unavailable, reassignment should be a deliberate action someone takes, not a silent handoff that leaves the item ownerless.

A rejection should reopen only the specific item, not the entire submission. Asking a client to resubmit five approved documents because one was wrong is the fastest way to turn a minor correction into a frustrating experience.

Pair every rejection with a specific, written reason tied to that item. "Rejected" with no explanation forces the client to guess, which usually produces another wrong resubmission and a second round of the same problem.

Let the client see and respond to the rejection in the same place they submitted, rather than through a separate email thread. That keeps the correction and the original request linked, instead of scattered across two systems.

Record who approved or rejected each item and when, as a permanent part of the case — not just a status label that can silently change with no history behind it.

This trail matters most when a decision is questioned later: an internal audit, a client dispute, or a regulator asking how a file was validated. "It's approved now" is a weaker answer than "approved by X on this date, after one rejection for a wrong document type."

Keep the trail itself separate from the documents it describes, so reviewing the history of decisions on a case doesn't require reopening every file in it.