Back to compare picker

Approval workflow vs Review before submit vs Permission recovery vs Invite user vs Confirmation dialog vs Activity log vs Notification center

Choose approval workflow when work cannot proceed until one or more authorized approvers approve, reject, delegate, reassign, request changes, time out, or cancel a submitted request.

Decision dimensions

Dimension Approval workflowReview before submitPermission recoveryInvite userConfirmation dialogActivity logNotification center
UI or UX UI + UX - Routed decision workflow for requests that require authorized approvalUI + UX - Final editable answer summary before committing a transactionUI + UX - Guided workflow for regaining or routing around missing accessUI + UX - Invitation lifecycle for granting another person accessUI + UX - Consequential alert decisionUI + UX - Searchable and exportable record of system, user, or administrative eventsUI + UX - Durable user-opened notification history and action drawer
UI guidance 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 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.Show a recovery workspace after denial with the current account, current role, requested role, safe owner or admin destination, request reason, policy limits, status timeline, and original blocked task.Render invite user as an access-granting workflow with recipient identity, role or permission, team or channel scope, optional message, delivery method, expiry, pending status, resend, edit, cancel, and acceptance outcome.Render an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope.Render activity logs as evidence-oriented records with event time, actor, action, object, source system, scope, result, and technical context such as IP address or location when available.Provide a persistent notification entry point, usually a bell or inbox control, with a count that represents new unseen notifications rather than every unread item forever.
UX guidance Use approval workflow when a submitted request cannot proceed until an authorized person, group, threshold, sequence, or external policy gate explicitly approves or rejects it.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.Use permission recovery when users can take a concrete step to regain access, use another identity, request a different role, escalate a policy block, or continue with a safe fallback after an authorization denial.Use invite user when an authorized person needs to bring another person into a workspace, organization, project, channel, repository, team, tenant, or shared object.Interrupt users only when the action has a meaningful consequence that cannot be safely recovered afterward.Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries.Use a notification center when users receive enough asynchronous system or collaboration updates that they need a durable place to review, triage, and act later.
Good UI 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 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 restricted report recovery panel shows alex@northwind.example lacks Finance viewer access, lets the user request Viewer or Editor with a reason, names Priya as the approver, shows request ACC-2048 as pending, and returns to the report after approval.A workspace invite form accepts maya@example.com, labels the invite as Workspace member, shows default channels, explains billing impact, lets the inviter add a message, and shows the pending invite with resend and cancel actions.Delete Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive.An organization audit log table shows timestamp, actor, action, target object, app, IP address, result, and a Details drawer with before and after fields.A bell opens a drawer with Unread and All filters, showing comment mentions, approval requests, export results, and background-job failures in newest-first order.
Bad UI A request page says Waiting without naming the approver, required count, due date, or escalation path.A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links.A blocked report only has Retry, so the user repeats the same denied request.An Invite button immediately emails every typed address with Admin access and no review of workspace, channel, or billing scope.A popup says Are you sure? with OK and Cancel but does not name the project, notes, or irreversible outcome.A page titled Activity shows vague entries such as Changed settings with no actor, target, timestamp, or source.A red badge says 42 forever because opening the drawer, reading items, and viewing related work never update the count.
Good UX A requester submits a deployment, sees it is waiting for Release managers, cannot self-approve, receives a change request with a required comment, edits the change summary, and resubmits to the same route.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 user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report.An admin invites an external contractor as a single-channel guest, sees the one-channel limit, adds a note, sends the invite, then extends it when it is still pending after 30 days.Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive.An admin filters to failed SSO events, expands one entry, copies the event ID, exports the filtered range, and sees that records older than 180 days require a different archive.Opening the notification drawer clears the new-notification badge while unread items remain available for later triage.
Bad UX The first approver clicks Approve and the system marks the whole request approved even though policy required everyone to approve.A user selects Change address, edits one field, then has to repeat every later page before finding the review page again.A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure.A member tries to invite a contractor but learns after send that guests require admin approval and no request status is shown.Every archive, filter, and dismiss action opens the same confirmation until users click through automatically.A user marks a notification read and the corresponding activity evidence disappears from the only log.A payment failure that blocks the current checkout is only stored in the notification center and never appears in the task.
Best fit 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 user has provided multiple answers and should verify them before a consequential submit action.A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue.An authorized user needs to bring another person into a workspace, organization, project, channel, repository, team, tenant, or shared object.The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible.Users need to inspect recorded user, admin, system, security, or integration events.Users receive multiple asynchronous updates across objects, jobs, collaborators, approvals, or reminders.
Avoid when The user only needs to check their own answers before submission.The task is a single low-risk field with clear inline validation and an obvious submit action.The product only needs to state that access is denied and no recovery path exists.The current user is creating their own account or profile.The action is routine and easily reversible.The goal is only to show a readable milestone history for one case or process.The product has only occasional current-action feedback that a toast or inline status can handle.
Required state Draft or submit-ready request handoff stateInitial review state with grouped captured answers, relevant sections, and explicit submit action.Recovery start state with original blocked task and current account.Recipient entry or directory lookup statePre-action state with an explicit consequential trigger.Default log state with event records, result count, visible timezone, retention window, and permission scope.Closed entry-point state with zero, new-unseen, and unread-but-seen counts.
Accessibility burden Use labelled request summary, approver, status, due date, decision, comment, and history regions.Use headings that make the review task explicit, such as Check your answers before sending your application.Move focus to the recovery heading when the workflow opens from a denial.Use labelled fields for recipient, role, scope, team, channel, message, and expiry.Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response.Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together.Give the entry-point control an accessible name that includes new or unread count without relying only on a red dot.
Common misuse Showing a generic pending message without the approver, gate, rule, or due date.Using a review page that contains no captured answers.Offering Retry for an unchanged authorization denial.Treating invitation sent as if the user is already a member.Asking users to confirm every routine action until they stop reading.Calling a social feed or notification drawer an activity log without event evidence.Treating the badge count, unread count, and total notification count as one number.

Approval workflow

UI or UX
UI + UX - Routed decision workflow for requests that require authorized approval
UI guidance
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.
UX guidance
Use approval workflow when a submitted request cannot proceed until an authorized person, group, threshold, sequence, or external policy gate explicitly approves or rejects it.
Good UI
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.
Bad UI
A request page says Waiting without naming the approver, required count, due date, or escalation path.
Good UX
A requester submits a deployment, sees it is waiting for Release managers, cannot self-approve, receives a change request with a required comment, edits the change summary, and resubmits to the same route.
Bad UX
The first approver clicks Approve and the system marks the whole request approved even though policy required everyone to approve.
Best fit
A submitted request needs authorized approval before a deployment, purchase, access grant, publication, content change, policy exception, financial action, or workflow step can proceed.
Avoid when
The user only needs to check their own answers before submission.
Required state
Draft or submit-ready request handoff state
Accessibility burden
Use labelled request summary, approver, status, due date, decision, comment, and history regions.
Common misuse
Showing a generic pending message without the approver, gate, rule, or due date.

Review before submit

UI or UX
UI + UX - Final editable answer summary before committing a transaction
UI guidance
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.
UX guidance
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.
Good UI
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.
Bad UI
A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links.
Good UX
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.
Bad UX
A user selects Change address, edits one field, then has to repeat every later page before finding the review page again.
Best fit
A user has provided multiple answers and should verify them before a consequential submit action.
Avoid when
The task is a single low-risk field with clear inline validation and an obvious submit action.
Required state
Initial review state with grouped captured answers, relevant sections, and explicit submit action.
Accessibility burden
Use headings that make the review task explicit, such as Check your answers before sending your application.
Common misuse
Using a review page that contains no captured answers.

Permission recovery

UI or UX
UI + UX - Guided workflow for regaining or routing around missing access
UI guidance
Show a recovery workspace after denial with the current account, current role, requested role, safe owner or admin destination, request reason, policy limits, status timeline, and original blocked task.
UX guidance
Use permission recovery when users can take a concrete step to regain access, use another identity, request a different role, escalate a policy block, or continue with a safe fallback after an authorization denial.
Good UI
A restricted report recovery panel shows alex@northwind.example lacks Finance viewer access, lets the user request Viewer or Editor with a reason, names Priya as the approver, shows request ACC-2048 as pending, and returns to the report after approval.
Bad UI
A blocked report only has Retry, so the user repeats the same denied request.
Good UX
A user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report.
Bad UX
A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure.
Best fit
A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue.
Avoid when
The product only needs to state that access is denied and no recovery path exists.
Required state
Recovery start state with original blocked task and current account.
Accessibility burden
Move focus to the recovery heading when the workflow opens from a denial.
Common misuse
Offering Retry for an unchanged authorization denial.

Invite user

UI or UX
UI + UX - Invitation lifecycle for granting another person access
UI guidance
Render invite user as an access-granting workflow with recipient identity, role or permission, team or channel scope, optional message, delivery method, expiry, pending status, resend, edit, cancel, and acceptance outcome.
UX guidance
Use invite user when an authorized person needs to bring another person into a workspace, organization, project, channel, repository, team, tenant, or shared object.
Good UI
A workspace invite form accepts maya@example.com, labels the invite as Workspace member, shows default channels, explains billing impact, lets the inviter add a message, and shows the pending invite with resend and cancel actions.
Bad UI
An Invite button immediately emails every typed address with Admin access and no review of workspace, channel, or billing scope.
Good UX
An admin invites an external contractor as a single-channel guest, sees the one-channel limit, adds a note, sends the invite, then extends it when it is still pending after 30 days.
Bad UX
A member tries to invite a contractor but learns after send that guests require admin approval and no request status is shown.
Best fit
An authorized user needs to bring another person into a workspace, organization, project, channel, repository, team, tenant, or shared object.
Avoid when
The current user is creating their own account or profile.
Required state
Recipient entry or directory lookup state
Accessibility burden
Use labelled fields for recipient, role, scope, team, channel, message, and expiry.
Common misuse
Treating invitation sent as if the user is already a member.

Confirmation dialog

UI or UX
UI + UX - Consequential alert decision
UI guidance
Render an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope.
UX guidance
Interrupt users only when the action has a meaningful consequence that cannot be safely recovered afterward.
Good UI
Delete Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive.
Bad UI
A popup says Are you sure? with OK and Cancel but does not name the project, notes, or irreversible outcome.
Good UX
Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive.
Bad UX
Every archive, filter, and dismiss action opens the same confirmation until users click through automatically.
Best fit
The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible.
Avoid when
The action is routine and easily reversible.
Required state
Pre-action state with an explicit consequential trigger.
Accessibility burden
Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response.
Common misuse
Asking users to confirm every routine action until they stop reading.

Activity log

UI or UX
UI + UX - Searchable and exportable record of system, user, or administrative events
UI guidance
Render activity logs as evidence-oriented records with event time, actor, action, object, source system, scope, result, and technical context such as IP address or location when available.
UX guidance
Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries.
Good UI
An organization audit log table shows timestamp, actor, action, target object, app, IP address, result, and a Details drawer with before and after fields.
Bad UI
A page titled Activity shows vague entries such as Changed settings with no actor, target, timestamp, or source.
Good UX
An admin filters to failed SSO events, expands one entry, copies the event ID, exports the filtered range, and sees that records older than 180 days require a different archive.
Bad UX
A user marks a notification read and the corresponding activity evidence disappears from the only log.
Best fit
Users need to inspect recorded user, admin, system, security, or integration events.
Avoid when
The goal is only to show a readable milestone history for one case or process.
Required state
Default log state with event records, result count, visible timezone, retention window, and permission scope.
Accessibility burden
Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together.
Common misuse
Calling a social feed or notification drawer an activity log without event evidence.

Notification center

UI or UX
UI + UX - Durable user-opened notification history and action drawer
UI guidance
Provide a persistent notification entry point, usually a bell or inbox control, with a count that represents new unseen notifications rather than every unread item forever.
UX guidance
Use a notification center when users receive enough asynchronous system or collaboration updates that they need a durable place to review, triage, and act later.
Good UI
A bell opens a drawer with Unread and All filters, showing comment mentions, approval requests, export results, and background-job failures in newest-first order.
Bad UI
A red badge says 42 forever because opening the drawer, reading items, and viewing related work never update the count.
Good UX
Opening the notification drawer clears the new-notification badge while unread items remain available for later triage.
Bad UX
A payment failure that blocks the current checkout is only stored in the notification center and never appears in the task.
Best fit
Users receive multiple asynchronous updates across objects, jobs, collaborators, approvals, or reminders.
Avoid when
The product has only occasional current-action feedback that a toast or inline status can handle.
Required state
Closed entry-point state with zero, new-unseen, and unread-but-seen counts.
Accessibility burden
Give the entry-point control an accessible name that includes new or unread count without relying only on a red dot.
Common misuse
Treating the badge count, unread count, and total notification count as one number.
Decision rules
  • Choose approval workflow when work cannot proceed until one or more authorized approvers approve, reject, delegate, reassign, request changes, time out, or cancel a submitted request.
  • Choose review before submit when the requester is still checking and changing their own captured answers before the request is committed to an approval route.
  • Choose permission recovery when the initiating user is blocked by missing access and needs to request, regain, switch, or escalate authorization for themselves.
  • Choose invite user when an authorized inviter sends another person a trackable access invitation with pending, accepted, expired, resend, edit, or cancel states.
  • Use confirmation dialog only for a local immediate decision such as Approve this item or Reject with reason, not for the multi-step approval route, policy, notification, and audit lifecycle.
  • Use activity log to show the historical trail after approval events happen; it is not the workflow surface for collecting required decisions.
  • Use notification center to alert approvers and requesters that action or status changed; it must deep-link to the approval record rather than replacing the record.
  • Approval workflow must show requester, object, requested action, approver eligibility, required count or sequence, current state, due date or escalation, decision controls, comments, and outcome consequences.
  • Sequential approvals must identify the current approver and next gate; parallel approvals must distinguish everyone-must-approve, first-to-respond, threshold, and any-rejection semantics.
  • Rejected, change-requested, canceled, expired, bypassed, delegated, and self-review-blocked states need distinct treatment instead of one generic failure banner.
Inspect live examples
Failure modes
  • A requester sees Submitted with no approver, required count, due date, or next step.
  • An approver sees Approve and Reject buttons without the requested action, risk summary, attachment, or impact.
  • A sequential process appears complete after the first approval even though another approver still has the request.
  • A rejection loses the comment or does not return the request to the requester with a correction path.
  • A request allows self-approval for a protected action that policy says must be reviewed by someone else.
  • A notification says approval needed but opens a dashboard with no focused approval record.
  • An audit trail cannot explain who approved, who rejected, who bypassed, what changed, or when the approval timed out.