Skip to content

Documentation Publishing & recovery

Choose a guide from the library.

Publishing & recovery

Review exact revisions, coordinate launches and recover earlier work without surprise publications.

Check readiness and publish

Publication creates a stable snapshot. New draft edits leave that snapshot unchanged until another explicit publication. Readiness explains missing required values and reference/media blockers.

How to use it

  1. Save the intended revision and inspect publishing readiness plus dependency impact.
  2. Resolve field and dependency blockers. If review is required, request approval for the saved revision.
  3. Use Publish when your current role permits it. Confirm the publication state and inspect your consuming website.
  4. Use Unpublish to take the public snapshot offline while retaining the draft; inspect Where used first.

Good practice

  • Check current permissions, environment, language and publication state at the point of action.

Avoid

  • Do not assume a disabled browser button is the only protection; backend checks remain authoritative.

Request and decide an editorial review

A workspace settings manager can make review optional or required, with an optional ordered list of stages. Approvals belong to an exact saved revision; publication stays separate.

How to use it

  1. In Workspace settings → Editorial, a settings manager enables Require approval before publishing. Saving policy requires a recent sign-in.
  2. Leave Review stages empty for single-step approval. Optionally add up to five named stages, check eligible reviewer roles and use Move up/down to order them, then save. Policy applies across workspace environments.
  3. An editor saves the intended text and submits a review request.
  4. An independent reviewer with current model/language review permission and an eligible stage role approves or requests changes. The editor shows progress, notes and the next stage. Every configured stage must approve in order.
  5. A publisher explicitly publishes the approved revision. Saving a newer version requires a new valid review when policy demands it.

Good practice

  • Separate authoring, reviewing and publication responsibilities. Each stage needs an available independent approver in every relevant environment; one eligible person may review multiple stages. Custom-role plan limits and existing permissions still apply.
  • Resubmit after changed revisions, schemas, policies or earlier approver access. Changes requested or cancellation restarts the chain on resubmission; schedules and releases recheck all required approvals.

Avoid

  • Do not approve your own request or authored revision, select roles without approval grants, or treat earlier approvals as valid after edits or revoked access. Stage selection never grants additional permissions.

Schedule publication or unpublication

Schedules pin saved revisions and are executed by durable background jobs. Current permissions, dependencies and policy are checked again at execution.

How to use it

  1. Save the entry and open Schedule an action. Choose publication or unpublication, language and local date/time.
  2. Select the correct time zone. Resolve repeated clock times explicitly when required; invalid local times must be corrected.
  3. Review the resulting schedule, cancel or replace it when plans change, and inspect its outcome after the intended time.

Good practice

  • Keep background workers running and inspect blocked/failed outcomes instead of assuming the clock guarantees success.

Avoid

  • Editing an entry after scheduling does not update the pinned revision automatically; create a new valid schedule.

Publish or unpublish selected entries together

Collection checkboxes prepare up to 25 saved entries as a revision-pinned release. Selecting entries and preparing the review do not change public content.

How to use it

  1. Open a content collection in the intended workspace, environment and language. Check individual entries or Select this page. Only the current page is selected by that control; selected IDs and versions remain selected across pages, up to 25 total.
  2. Choose Clear selection to start over. Changing search, filters, sort, saved view, language, content type, workspace or environment clears the selection; leaving the collection also clears it. Entry titles remain links to the ordinary editor.
  3. Choose Review publication or Review unpublication. These actions require draft-read and the chosen model/language permission, plus publisher eligibility under the workspace review policy. Save editor changes first: bulk actions use saved revisions only.
  4. The prepared release shows action counts, languages and pinned versions. Open Pinned draft preview or the current editor for each entry. Use Where used to inspect paginated incoming saved-draft and published references you can read. Restricted usage is omitted; no dependency is automatically selected.
  5. Check readiness and resolve blockers: required values, valid entry approvals, saved versions and the final dependency graph must pass. A deleted or changed selected entry requires clearing/reselecting it; bulk actions never silently substitute a newer revision.
  6. Save readiness review, check the confirmation and Execute release now, or use the existing scheduling workflow. On small screens, Review and execute jumps to those controls. Execution rechecks permissions and all preconditions; either the complete batch commits or its publication changes roll back.
  7. Unpublication preserves drafts and history. Removing the default-language publication also makes the entry’s translations unavailable in delivery until it returns; saved translation snapshots remain. Shared fields and language fallback can affect other language responses when publishing. Consuming websites own cache/rebuild behavior.

Good practice

  • Use a small, intentional selection in one language and inspect reference usage before removal. Choose a named release directly when a launch spans several models, languages or media.

Avoid

  • Do not treat Select this page as Select all matching content, assume a readiness review grants entry approval, or assume retries select the latest revisions. Public/preview API credentials cannot execute bulk operations.

Coordinate a named release

A release groups up to 25 saved entry/translation/media actions into one publication transaction. Invalid final graphs roll back together.

How to use it

  1. Open Releases, create a named release and add authorized saved publication/unpublication actions.
  2. Review selected versions and remove/reselect changed items. Run Check readiness, then Save readiness review.
  3. Optionally capture a website impact comparison through your configured website renderer before deciding to publish.
  4. Confirm and execute now, or schedule the ready release. Inspect completed, blocked, retrying or failed outcomes.

Good practice

  • Include all required dependency changes and review mixed publication/unpublication actions carefully.

Avoid

  • Release readiness is not a substitute for required entry approvals, and website review never grants publishing authority.

Compare revisions, restore and inspect Activity

History preserves saved/publication revisions. Restore returns historical values to the editable draft; Activity records lifecycle operations for authorized workspace users.

How to use it

  1. Open entry history and inspect or compare revisions, keeping language and version in view.
  2. Choose Restore for the intended historical revision and resolve any current schema/validation issues.
  3. Review the restored draft; publish separately if it should become public.
  4. Open Activity to filter authorized lifecycle events by resource, action, actor or date. Workspace management categories remain restricted to Owner and Admin.

Good practice

  • Use a descriptive editorial process around restores and compare the current published snapshot afterward.

Avoid

  • Restoring is not a database rollback, and it does not undo external webhook side effects or automatically publish old content.
Need a hand? Check troubleshooting. Documentation describes the locally verified pilot; production qualification remains in progress.