Use publish workflow for moving content or configuration from editable state to a selected live target, approval workflow for routed human decisions, review queue for processing many items, and draft state for unfinished saved work.
Use publish workflow for moving content or configuration from editable state to a selected live target, approval workflow for routed human decisions, review queue for processing many items, and draft state for unfinished saved work.
Practice the judgment: Imagine this situation: A scheduled publish accepts invalid content and only fails silently at launch time. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Publish workflow | Approval workflow | Review queue | Draft state | Review before submit | Confirmation page | Activity log | Conflict state |
|---|---|---|---|---|---|---|---|---|
| UI or UX | UI + UX - Workflow for moving edited material to live, staged, scheduled, or retired state | 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 - Unpublished object version lifecycle | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Final endpoint page after a transaction is complete | UI + UX - Searchable and exportable record of system, user, or administrative events | UI + UX - Competing-version resolution state |
| UI guidance | Render publish workflow as a readiness and release surface with content identity, current status, target destination, affected pages or entries, preview, validation, permission, schedule, publish, unpublish, rollback, and live verification. | 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. | Label the current version explicitly as Draft, Unpublished changes, Published, Active, Locked, or Unavailable, and place that label near the object title, list row, editor header, and publish 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 a full page after commit with a prominent completion panel, a page heading that names what finished, a reference or receipt when users need one, and a clear section for what happens next. | 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. | Show both competing versions near the affected object, field, paragraph, file, row, or branch with source labels such as Your edit, Server version, Mina's edit, Target branch, and Current published value. |
| UX guidance | Use publish workflow when a user is moving content, product data, site changes, configuration, release notes, or campaign material from draft, staged, scheduled, or approved state to a selected live or public target. | 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 draft state when users need to pause work on an object, return later, and decide whether to publish, activate, discard, or keep editing an unpublished version. | 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 a confirmation page when the transaction or service journey has ended and users need durable proof, reassurance, next-step timing, or a record they can bookmark, print, quote, or revisit. | Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries. | Preserve each version, explain why automatic merge was unsafe, guide users through the smallest conflicting unit, and make the post-resolution result reviewable before committing. |
| Good UI | A CMS publish panel shows Draft article, production site, English and French locales, validation complete, preview URL, scheduled time, affected entries, and actions to Publish now, Schedule, or Keep draft. | 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 knowledge article header says Draft saved today, shows the currently published title, and offers Resume draft, Compare with published, Discard draft, and Publish. | 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 grant application page says Application complete, shows reference APP-48291, lists what happens next within 5 working days, and offers Save record, Track application, and feedback links. | 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 field report says Conflict on supervisor comment, shows Your offline edit from 11:06 beside Server edit by Mina at 11:07, and offers Keep mine, Keep server, and Merge comment. |
| Bad UI | A production publish happens when the user intended staging only. | A stale email approval applies to a request version that has changed. | The most urgent or oldest item is buried by default sort. | A draft label is missing from the editor, so users publish or discard the wrong version. | Change links lack context, so assistive technology users hear a list of identical Change links. | Users submit twice because refresh or Back replays the final action instead of returning to the receipt. | An export button downloads a different date range and timezone than the on-screen filtered log. | A save banner says Something went wrong and only offers Retry after another user changed the same field. |
| Good UX | A content editor previews a campaign page, fixes a missing hero image, schedules publication and retirement times, sees the job queued, and later verifies the live URL and scheduled unpublish state. | 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 opens a published article that has an unpublished version, chooses Resume draft, reviews a change summary, publishes, and sees the page become visible to viewers. | 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 copies the reference, saves the receipt, follows Track application, and later returns from a bookmark to the same confirmation details or a helpful tracking fallback. | 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. | A user tries to sync an offline field report, reviews only the two changed fields, merges one comment, keeps the server contact number, and commits a resolved version. |
| Bad UX | A user clicks Save and assumes the page is live because the interface uses Save, Submit, Schedule, and Publish interchangeably. | 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 discards a shared draft and unknowingly removes another editor's unpublished changes. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | Users submit twice because refresh or Back replays the final action instead of returning to the receipt. | A user marks a notification read and the corresponding activity evidence disappears from the only log. | The app silently keeps the newest server value and deletes the user's local note. |
| Best fit | Users need to make content, products, pages, releases, site changes, campaigns, or configuration visible to an audience. | 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. | Users need to pause and resume unfinished work across sessions, devices, or routes. | A user has provided multiple answers and should verify them before a consequential submit action. | A transaction or service journey has ended and users need durable proof plus next-step information. | Users need to inspect recorded user, admin, system, security, or integration events. | Concurrent users, devices, branches, or background jobs changed the same object or location. |
| Avoid when | The user is only saving unfinished work. | The user only needs to check their own answers before submission. | The task is a single request moving through a governed approval route. | The change is a small one-field edit that should be saved or canceled immediately. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The user remains inside an ongoing task and only needs local proof near the changed object. | The goal is only to show a readable milestone history for one case or process. | The user is managing an unpublished draft lifecycle rather than resolving competing edits. |
| Required state | Draft or edited but unpublished state | Draft or submit-ready request handoff state | Queue loading and count state | Published or active state with an available draft. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Submitted state immediately after authoritative commit routes to the confirmation page. | Default log state with event records, result count, visible timezone, retention window, and permission scope. | Conflict detected state naming affected object and source versions. |
| Accessibility burden | Use labelled controls for status, target, preview, schedule date and time, timezone, validation, publish, unpublish, rollback, and live URL. | 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 and status regions so screen reader users know whether they are editing a draft or viewing the active version. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Keep interactive controls out of low-contrast panel treatments unless focus and text contrast are explicitly verified. | Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together. | Associate each conflict message with the affected field, row, line, paragraph, or file. |
| Common misuse | Using Save, Submit, Schedule, and Publish interchangeably. | Treating the first approval as final when the rule requires more approvers. | Treating review queue as approval workflow and hiding many-item workload controls. | Using Saved to mean both saved draft and published content. | Labelling the final commit button Continue. | Showing a toast or local success strip as the only proof of a completed transaction. | Using vague activity labels that omit actor, action, object, timestamp, or result. | Treating a conflict as a simple retryable save error. |