One extra zero. Ten times the order.

Imagine an operator intending to order 250 packs and entering 2,500. A positive whole number passes validation, but the system cannot know that the intention changed. The brief called for a review point before accidental inputs reached operational work.

The response was an approval layer inside the existing dashboard, covering stock orders, inventory adjustments, price changes, and batch releases. A proposed change and an applied change needed to become visibly different states.

For an enabled operator workflow, submitting preserves the proposed values and creates a pending request without applying the business action. An eligible reviewer then decides whether it should proceed.

The gate is configurable by action. Open allows multiple requests, Locked permits one unresolved operator request, and Throttled limits submission frequency. A blocked submission explains the lock or cooldown instead of leaving the operator with an unexplained disabled button.

The first screens tried to explain everything at once. Template cards came before workflow rows, request counts repeated across summary cards, and the new-request action appeared twice. The user’s request for less clutter exposed competing starting points.

The refinement brings rules and current requests forward. Template guidance, history, filters, and optional context open when needed. Consequential state stays visible: active filters still show their count, and blocked or failed work still explains itself.

The review drawer leads with the requester and proposed values. Submission time, template, and attempt details sit under Request context; the activity log has its own tab. Decision controls remain available at the bottom.

Authority and freshness are part of the interaction. A requester cannot review their own pending request, even after becoming an administrator. If the target changes while waiting, the reviewer must acknowledge the difference, and the engine rechecks the context before execution.

A reviewer can approve the right proposal and the action can still fail. The prototype labels execution failure explicitly, retains the error, and allows an eligible retry on the same request. A Locked workflow stays blocked while that work is unresolved.

Other outcomes preserve their own meaning. Rejection requires a reason; a revision becomes a linked new attempt. Cancellation withdraws a pending request, and a version check prevents an earlier open review from overriding the withdrawal.

• Refusal explains what is blocking submission.
• Rejection gives the requester something to revise.
• Execution failure keeps a visible route to recovery.

Twenty-nine regression checks cover the workflow’s main transitions and exception paths. Browser walkthroughs checked forms, disclosures, configuration confirmation, review details, active filters, and the phone layout at 390 pixels.

Those checks establish software behavior, not whether staff understand the screens. The next meaningful step is a pilot with operators and reviewers: catch an excessive quantity, explain whether stock has changed, revise a rejection, and recover from failure. Success must include both fewer unintended changes and an acceptable review burden.