Content workflow
A content workflow is the predefined sequence content follows between drafting and publication, with the tasks to complete, the roles that complete them and the approvals required before going live. It makes explicit the handoffs between whoever drafts, reviews, approves and publishes.
Definition and how it works
The simplest workflow has one approval step. A large organization can chain several: editorial review, legal approval for some content types, translation, then scheduled publication. Some approvals can run in parallel rather than in sequence, which shortens lead times when several departments have to sign off.
A content workflow is judged on its edge cases more than its happy path. What happens when the approver is away? When an urgent fix has to go out within the hour? When content is rejected, does it return to its author with a reason or sit blocked with no owner? A workflow that cannot answer these questions gets bypassed. Publications then escape any control.
In Jahia, changes are saved in an editing workspace (the default workspace) and only become visible to visitors once published to the live workspace. A workflow can be attached to publishing as well as unpublishing, so that another person reviews the action before it is carried out.
Related terms: Work In Progress · Content lifecycle · Workspace · Multilingual CMS
Resources that cover this term
Content workflow vs permissions and roles: the differences
Permissions say who can do what. A workflow says in which order and with which approvals. The content lifecycle covers the whole existence of content, well beyond publication. A well-designed workflow does not make up for overly broad permissions. Conversely, fine-grained permissions do not replace a workflow when several departments are involved.
| Notion | What distinguishes it |
|---|---|
| Permissions and roles | Define what a user is allowed to do. The workflow organizes the sequence of actions between those roles. |
| Content lifecycle | Also covers review, archiving and retirement. A workflow covers one specific stage, such as publication. |
| Work In Progress | In Jahia, a status that blocks publication while drafting is unfinished. Once the status is removed, the content can enter the publication process. |
| Default workspace | In Jahia, the part of the repository where content is stored before publication, used for editing and preview. |
Content workflow in practice
Start from risk rather than the org chart. An internal news item does not need the same workflow as a pricing page or regulatory content. Define two or three workflows by risk level, each attached to a content type or a site section, rather than a single workflow too heavy for low-risk publications.
Edge cases are best tested with the teams: an approval while the main approver is on leave, an urgent fix on a Friday evening, a rejection with a change request. Finally, check that every publication leaves a searchable record of who approved, which version and on what date. That record is what an audit may ask for.
Frequently asked questions
Should rejected content go back to its author?
It should go back with a reason. A rejection that leaves content blocked with no owner is one of the edge cases that push teams to bypass the workflow. The workflow must say who gets the rejected content back, with which change request, then who resubmits it. This scenario is best tested with the teams before go-live, just like the approver’s absence.
How many approval steps should a content workflow have?
As few as the risk allows. Each step adds a delay and a point of blockage. For low-risk editorial content, one step can be enough. Legal, pricing or regulatory content justifies an extra approval by the relevant department. If a workflow goes beyond three steps, check whether some of them could run in parallel instead of one after another.
What should happen when an urgent fix cannot wait for the workflow?
Plan for it inside the workflow instead of letting it be bypassed. A restricted role can hold a direct publishing right reserved for urgent fixes, always logged and followed by a review after the fact. Without that planned path, teams end up widening everyone’s permissions, which defeats the purpose of the workflow.