Content life cycle and workflow
Contents
A content item’s life cycle is described by three independent states:
-
its workflow state — is the work done?
-
its publish state — is it live?
-
its change status — what has changed since it was last published?
Workflow state
Workflow records whether work on the draft is In progress or Ready for publishing. An icon next to the content type shows this state. If the content fails validation, a red Invalid icon takes precedence.
- Invalid
-
A mandatory field is missing, or a validation test fails. Blocks publishing.
- In progress
-
Default state for a new or modified content item. Blocks publishing.
- Ready for publishing
-
The editor has explicitly flagged the content as done, making it eligible for publishing.
Creating or editing content puts its draft In progress. Explicitly marking valid content ready changes it to Ready for publishing. Publishing hides the workflow icon while there are no unpublished changes; editing again returns the draft to In progress.
Invalid (blocking)
Set whenever the content fails validation. Invalid content is marked with a red icon, and invalidity takes priority over the other state icons — an invalid item is shown as invalid whether it is in progress or ready.
Typical causes:
-
a required field is empty — including the display name
-
an input has fewer or more entries than its allowed number of occurrences
-
a value fails the validation of its input type — a regular expression on a text line, a malformed rich text field, an invalid attachment
-
a required field is missing in a mixin, or in the app configuration of a site
-
a custom validator on the server rejects the content
Validation runs when content is opened and while it is edited. The Content form highlights invalid inputs and summarizes errors at the top of the form.
Invalid content can still be saved, but cannot be marked ready or published. Correcting validation errors makes the content valid; it does not automatically mark an in-progress item ready. For handling invalid items in a publishing batch, see Publishing validation.
Editing a published item into an invalid state is allowed: the red icon appears for the draft version, while the version already live on master is untouched.
| Validity is not a stored state — unlike In progress and Ready it is derived, by validating the content every time it is loaded or changed. |
In progress (blocking)
The default state of a new content item. Signals that the content is being worked on; it will stay in this state until explicitly marked as ready.
In progress blocks publishing, even when the content is valid. Saving an item does not change its readiness. See Mark as ready for individual and bulk readiness actions.
Ready (for publishing)
Set by the Mark as ready action. The yellow ! icon is replaced with a green ✓. Marking an item ready does not publish it or change what is currently online.
Ready content can be published by a user with publish permission, provided validation and the other publishing checks pass. A publish request can hand it to another user for review and publishing.
Any edit to a Ready for publishing item immediately resets it to In progress — the editor must mark it ready again once the edits are finished.
Publish state
In addition to the workflow state, the UI displays the publishing state of each content item. This is shown as a text element in the second column of the content list, and in the Content Editor toolbar.
There are four publishing states:
- Offline
-
The item is not published. This is the default state of a new content item, and Unpublishing an item returns it to this state as well.
- Online
-
A published version is live. The draft may contain changes that have not yet been published.
- Scheduled
-
The editor has set a future date and time for the content to be published. It is not live yet.
- Expired
-
The editor set a date and time for the content to be unpublished, and that time has been reached. The item was previously online.
Publishing immediately takes an offline item Online. Scheduling a future start takes it to Scheduled, then Online when the start time is reached. When its configured end time is reached, it becomes Expired. Unpublishing an online item takes it Offline.
Editing an online item changes its draft workflow state to In progress, but its publish state remains Online. The published version on master is unaffected until the item is published again. |
Change status
Change status describes how the draft differs from the published content:
- New
-
The item has never been published. There is no live version to compare with.
- Modified
-
The item is published, and the draft version differs from the live one.
- Moved
-
The item has been renamed or moved to another parent since it was published.
- Unpublished
-
The item was previously published, and has since been taken offline with Unpublish.
- Published
-
The draft version is identical to the live one — no changes to publish.
| Moved may be combined with other states, since an item can be both edited and relocated in the same round of work. Such an item reads Modified, Moved. |
Publishing changes New, Modified, or Moved content to Published. Subsequent edits make it Modified; renaming or moving it makes it Moved. Unpublishing changes it to Unpublished; publishing it again returns it to Published.
The change status is shown in the Preview panel toolbar, the Details panel, and the Publishing wizard. It can appear alongside the publish state, for example:
ONLINE | Modified, Moved
Here the published version remains online, while the draft has changes to its content and location.
Publish request
Publish requests are part of the effective workflow, but not a workflow state in themselves, as they operate across multiple items. They exist so work can be handed to someone else for review and publishing — typically when the editor lacks publish permission, or wants sign-off before going live. The full wizard, the request dialog, and how requests are managed are documented under Publish requests.
| Content items can also be attached to tasks, the other issue type. Unlike publish requests, tasks are purely editorial work items — they have no effect on an item’s workflow or publish state. See Issues. |