| UI or UX | UI + UX - Runtime checkpoint that pauses AI or automation until an eligible human authorizes the next step | UI + UX - Routed decision workflow for requests that require authorized approval | UI + UX - Actionable queue for triaging many items that need human review | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Context-sensitive workflow action suggested for the user's current record, case, conversation, or task |
| UI guidance | Render a human approval gate as a paused automation checkpoint with the proposed action, tool or workflow step, triggering rule, risk level, payload snapshot, requester or agent, approver eligibility, timeout, and explicit approve, reject, edit, cancel, or bypass controls. | Render approval workflow as a routed request record with requester, object, requested action, approver eligibility, required rule, current gate, due date, decision controls, comment history, and outcome consequences. | Render review queue as an actionable worklist with queue scope, counts, filters, sort order, row reason, owner, priority, age or SLA, status, preview context, selection, and row actions. | Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action. | Render the recommended next action as a bounded suggestion card or action slot that names the action, trigger context, expected outcome, owner, due time or urgency, eligibility status, and why the system is suggesting it now. |
| UX guidance | Use human approval gate when automation is ready to act but policy, risk, confidence, cost, access, publication, deployment, customer impact, or legal consequence requires a human decision before execution continues. | Make the approval route understandable over time: who has the request, what decision is needed, what happens on approval or rejection, what blocks self-review, and where the requester can revise or withdraw. | Use review queue when a team repeatedly processes a changing set of tickets, comments, pull requests, content items, cases, requests, or records that require human inspection and action. | Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed. | Keep recommended next action separate from broad recommendations, task lists, primary buttons, assignments, approvals, and review queues because it is optional, contextual, explainable, and directly tied to the current work state. |
| Good UI | An AI support agent pauses before issuing a refund, shows the proposed amount, customer, policy match, confidence, source grounding, approver role, timeout, Approve refund, Edit amount, Reject, and Stop run controls. | A production deployment request shows requester, service, environment, change summary, required reviewer group, self-review restriction, wait timer, Approve and Reject with reason controls, and a timeline of route changes. | A moderation queue has Held, Likely spam, Reported, and Escalated tabs, row evidence, policy reason, reviewer claim state, approve/remove/escalate actions, and bulk-action preview. | A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address. | A support case sidebar recommends Send refund-policy article because the customer asked about a refund twice, shows confidence, source snippets, and opens a draft for review. |
| Bad UI | A reviewer can approve an automation run after the action already executed, making the gate only decorative audit text. | A stale email approval applies to a request version that has changed. | The most urgent or oldest item is buried by default sort. | Change links lack context, so assistive technology users hear a list of identical Change links. | Required onboarding tasks and optional suggestions are mixed in one list labelled Next best actions. |
| Good UX | A billing lead opens the paused refund gate, sees that the amount is under policy but source grounding is partial, edits the refund to the verified amount, approves, and the agent resumes only that step. | A finance approval requires both manager and controller approval; the first approval advances the sequence, a rejection stops downstream processing, and the requester sees the exact rejection reason and revise action. | A reviewer claims the oldest SLA-at-risk ticket, opens a preview, assigns it to Billing, returns to the queue with the row removed, and lands on the next oldest item. | A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved. | A representative reviews the suggested reply, sees that it was triggered by customer intent and a matching knowledge article, edits the draft, and sends it. |
| Bad UX | A human approves a stale agent action from email and the agent applies it to a different customer state. | The first approver clicks Approve and the system marks the whole request approved even though policy required everyone to approve. | A reviewer marks a pull request reviewed from an old queue row after the author pushed new commits and re-requested review. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | A user accepts a suggested discount and only afterward learns it changed contract terms. |
| Best fit | An AI agent, workflow, deployment, or automation is ready to perform a high-impact step and must pause for human authorization. | A submitted request needs authorized approval before a deployment, purchase, access grant, publication, content change, policy exception, financial action, or workflow step can proceed. | A team or individual repeatedly reviews many independently queued items. | A user has provided multiple answers and should verify them before a consequential submit action. | Users are working in a record, case, conversation, or workflow where choosing the next action is costly or error-prone. |
| Avoid when | The action has already happened and users only need an audit log. | The user only needs to check their own answers before submission. | The task is a single request moving through a governed approval route. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The action is always required and should be a task, validation, or workflow gate. |
| Required state | Paused gate state with proposed action, payload snapshot, reason for gate, and run context. | Draft or submit-ready request handoff state | Queue loading and count state | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Recommended action state with action title, reason, evidence, trigger, consequence, and accept or review path. |
| Accessibility burden | Expose gate status, proposed action, target, payload summary, risk, approver rule, timeout, and current run state as text. | Use labelled request summary, approver, status, due date, decision, comment, and history regions. | Use labelled queue name, count, filters, sort, group, row status, selection, preview, and action controls. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Use a labelled region or card heading that identifies the suggestion as recommended, optional, and scoped to the current work object. |
| Common misuse | Using a post-action audit record as if it were a pre-action human gate. | Treating the first approval as final when the rule requires more approvers. | Treating review queue as approval workflow and hiding many-item workload controls. | Labelling the final commit button Continue. | Hiding why the action was suggested, what evidence was used, or what will change. |