UX Patterns Guide
UI + UX Task And Workflow Patterns established

Publish workflow

Provide a publish workflow that checks readiness, previews the exact target, shows visibility and affected scope, supports publish now, schedule, reschedule, cancel, unpublish, rollback, and live verification, and records outcome state separately from draft saving or approval routing.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users need to make content, products, pages, releases, site changes, campaigns, or configuration visible to an audience.
  • Publishing target, timing, dependencies, validation, permission, or rollback matter.
  • The product can represent status changes between draft, staged, scheduled, live, failed, retired, and rolled back states.

Avoid when

  • The user is only saving unfinished work.
  • The user is only asking someone else to approve the work.
  • The task is reviewing many items in a queue rather than publishing one item or release.
  • The action has no visibility or live-state change.
  • The system cannot show or verify the target that changed.

Problem it prevents

Publishing is risky when products hide whether work is saved, staged, scheduled, public, or retired; which target will change; whether validation passed; who has permission; what dependencies will publish; and how to verify or undo a bad release.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Publish workflow in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The item may be an article, page, product, collection, site branch, release, campaign, locale, configuration, media asset, documentation page, or channel-specific listing.

Pattern promise

Provide a publish workflow that checks readiness, previews the exact target, shows visibility and affected scope, supports publish now, schedule, reschedule, cancel, unpublish, rollback, and live verification, and records outcome state separately from draft saving or approval routing.

Required state

Draft or edited but unpublished state

Recovery path

A production publish happens when the user intended staging only.

Access contract

Use labelled controls for status, target, preview, schedule date and time, timezone, validation, publish, unpublish, rollback, and live URL.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • 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 site builder publish dialog lets a user choose staging or production domains, shows unpublished page changes, warns that production is public, then confirms the live URL and offers rollback.
  • 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 merchandiser schedules a product to publish only to Online Store at 09:00, sees other sales channels excluded, edits the schedule, then cancels before launch without changing draft content.
Weak implementation

Vague, hidden, hard to recover from

  • A Publish button sends changes live to every domain with no staging/production target, preview, validation, or affected-page list.
  • A scheduled product launch silently fails because the workflow accepted missing channel data and did not surface validation before scheduling.
  • A user clicks Save and assumes the page is live because the interface uses Save, Submit, Schedule, and Publish interchangeably.
  • An editor updates a live page from an old draft and overwrites newer production copy because the workflow did not compare versions.
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.
  • Separate saving, submitting for review, approving, scheduling, publishing, unpublishing, and confirming live state so users can tell whether work is only stored, waiting, approved, queued, visible, retired, or failed.
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 visibility and blast radius explicit before publication: who can see it, which domain, environment, page, entry, locale, channel, time, dependency, and version will change.
Implementation contract

What the implementation must handle

States

  • Draft or edited but unpublished state
  • Preview state with target URL or destination
  • Validation pending state
  • Validation blocked state

Interaction

  • Saving a draft does not imply publication, and publishing cannot proceed until target, readiness, permissions, and validation requirements are resolved.
  • The workflow shows the item version, target destination, affected scope, current live state, and side effects before a publish or schedule action.
  • Preview opens the same version and target that will be published, or clearly labels where preview differs from production.
  • Schedule actions store date, time, timezone, target, actor, item version, and validation result.

Accessibility

  • Use labelled controls for status, target, preview, schedule date and time, timezone, validation, publish, unpublish, rollback, and live URL.
  • Announce validation progress, validation errors, scheduled, publishing, published, failed, unpublished, and rollback updates through status text.
  • Do not rely on color alone to communicate draft, scheduled, live, failed, or retired states.
  • Associate validation errors with the exact field, channel, locale, dependency, or permission that blocks publication.

Review

  • What is live now, what is changing, and which version will publish?
  • Which domain, environment, page, release, locale, sales channel, or audience will be affected?
  • What validation checks must pass before publish or schedule?
  • Is this saving a draft, submitting for review, scheduling, publishing now, unpublishing, or rolling back?
Evidence trail

Source-backed claims behind this guidance

WordPress post status

WordPress.org Documentation - checked

WordPress supports publish, draft, future, pending, private, trash, role-based workflow, and post status as public visibility state.

Contentful scheduled publishing

Contentful Help Center - checked

Contentful supports scheduled publish and unpublish actions for entries and releases with date and time selection.

Contentful content operations

Contentful Help Center - checked

Contentful supports validation checks before scheduled publishing jobs enter the queue and failure handling when scheduled publishing cannot run.

Webflow publish or unpublish a site

Webflow Help - checked

Webflow supports staging and production target selection, unpublishing, permissions, and single collection-item publishing and scheduling.

Shopify future publishing

Shopify Help Center - checked

Shopify supports future publishing for products and collections to Online Store with date and time selection.

Full agent/debug reference

Problem Context

  • The item may be an article, page, product, collection, site branch, release, campaign, locale, configuration, media asset, documentation page, or channel-specific listing.
  • Publishing may affect staging, production, public web, selected domains, sales channels, locales, entries, dependencies, cached pages, search indexes, subscribers, social channels, or release bundles.
  • The workflow may include draft, pending review, approved, scheduled, queued, validating, publishing, live, failed, missed, canceled, unpublished, retired, or rolled-back states.
  • The product must distinguish low-risk save operations from visibility-changing publish operations.
  • Users may need scheduled publication, scheduled unpublication, channel selection, permissions, branch approval, preview URLs, validation errors, and post-publish verification.

Selection Rules

  • Choose publish workflow when the primary task is making edited material visible, live, scheduled, retired, or no longer visible in a selected destination.
  • Use approval workflow when human approval is required before publication but the interface is primarily the decision route, not the live-target release surface.
  • Use review queue when many items await editorial, moderation, or code review before individual publish decisions.
  • Use draft state when the user is saving unfinished work without selecting target, schedule, preview, publish, or unpublish behavior.
  • Use review before submit for final field checking before a publish or schedule action is created.
  • Use confirmation page after publish succeeds to show live URL, affected target, time, reference, and next steps.
  • Show staging versus production, selected domains, channels, locales, dependencies, and audience before any live-changing action.
  • Validate required content, links, media, inventory, permissions, slug, translations, channel eligibility, schedule time, and dependency state before publish or schedule.
  • Represent scheduled, rescheduled, canceled, missed, failed, live, unpublished, and rolled-back states distinctly.
  • Provide a safe way to unpublish, retire, rollback, or open the live target when the platform supports it.

Required States

  • Draft or edited but unpublished state
  • Preview state with target URL or destination
  • Validation pending state
  • Validation blocked state
  • Ready to publish state
  • Target selection state for staging, production, domain, channel, locale, page, or release
  • Publish now confirmation state
  • Scheduled publish state
  • Reschedule or cancel scheduled publish state
  • Publishing in progress state
  • Published live verification state
  • Failed publish or missed schedule state
  • Unpublish or retire state
  • Rollback or restore previous live version state
  • Permission denied to publish state
  • Version conflict or newer live version state

Interaction Contract

  • Saving a draft does not imply publication, and publishing cannot proceed until target, readiness, permissions, and validation requirements are resolved.
  • The workflow shows the item version, target destination, affected scope, current live state, and side effects before a publish or schedule action.
  • Preview opens the same version and target that will be published, or clearly labels where preview differs from production.
  • Schedule actions store date, time, timezone, target, actor, item version, and validation result.
  • Validation failures block publish or scheduling and point to the exact field, dependency, channel, locale, or permission that must be fixed.
  • Publish, schedule, reschedule, cancel schedule, unpublish, retire, and rollback actions update the same release history and visible status.
  • Conflicts with newer live content, unsaved edits, changed dependencies, or revoked permissions require refresh, compare, or retry paths before publication.
  • After a successful action, the user can open the live target, copy the URL, see affected destinations, and inspect the audit trail.

Implementation Checklist

  • Define item type, statuses, target destinations, affected dependencies, permission roles, preview behavior, validation rules, schedule semantics, rollback support, and audit requirements.
  • Model save, submit for review, approve, schedule, publish, unpublish, retire, rollback, and confirm-live states separately.
  • Show current status and target-selection controls for staging, production, domains, sales channels, locales, releases, pages, or item-only publishing.
  • Run validation before publish and again before scheduled jobs execute when content can change between scheduling and launch.
  • Expose schedule date, time, timezone, reschedule, cancel schedule, and missed or failed schedule recovery.
  • Protect production publish, all-channel publish, dependency publish, unpublish, and rollback with appropriate review or confirmation steps.
  • Write publish history with actor, item version, target, action, time, schedule, validation outcome, failure reason, and rollback reference.
  • Test draft versus live distinction, staging-only publish, production publish, scheduled publish, scheduled unpublish, invalid content, permission denied, stale version, dependency change, failed publish, rollback, mobile, keyboard, screen reader status updates, and localization.

Common Generated-UI Mistakes

  • Using Save, Submit, Schedule, and Publish interchangeably.
  • Hiding whether the target is staging, production, one page, whole site, one channel, all channels, or a release bundle.
  • Allowing scheduled publishing without validation or later failure reporting.
  • Publishing stale draft content over a newer live version.
  • Failing to show affected dependencies or locales.
  • Treating approval as publication or publication as approval.
  • Providing no way to unpublish, retire, rollback, or verify live output.
  • Showing success before the live target, cache, search index, or channel actually updates.

Critique Questions

  • What is live now, what is changing, and which version will publish?
  • Which domain, environment, page, release, locale, sales channel, or audience will be affected?
  • What validation checks must pass before publish or schedule?
  • Is this saving a draft, submitting for review, scheduling, publishing now, unpublishing, or rolling back?
  • Can users preview the exact target and verify the live result?
  • What happens if the scheduled job fails, content changes before launch, or permissions are revoked?
Accessibility
  • Use labelled controls for status, target, preview, schedule date and time, timezone, validation, publish, unpublish, rollback, and live URL.
  • Announce validation progress, validation errors, scheduled, publishing, published, failed, unpublished, and rollback updates through status text.
  • Do not rely on color alone to communicate draft, scheduled, live, failed, or retired states.
  • Associate validation errors with the exact field, channel, locale, dependency, or permission that blocks publication.
  • Make preview, target selection, schedule, publish, cancel schedule, unpublish, rollback, and open-live controls keyboard reachable.
  • Warn before navigation when unsaved edits differ from the version selected for publish.
  • Keep live URL and scheduled time copyable and readable without requiring pointer hover.
Keyboard Behavior
  • Tab order follows status summary, target selection, preview, validation summary, schedule controls, primary action, secondary actions, and history.
  • Date and time controls accept keyboard entry and expose timezone text.
  • After validation fails, focus moves to the validation summary or first blocking field.
  • After scheduling or publishing, focus moves to the resulting status and live or scheduled action summary.
  • Cancel schedule, unpublish, and rollback confirmations return focus to the publish workflow surface.
  • Opening a preview preserves return context to the publish workflow.
Variants
  • Publish now
  • Schedule publish
  • Scheduled unpublish
  • Staging publish
  • Production publish
  • Single page publish
  • Whole site publish
  • Sales channel publish
  • Locale publish
  • Release bundle publish
  • Branch publish
  • Rollback publish
  • Retire content

Verification

Source trail checked:

Saved items