Workflows, Approvals, and Publishing
What to know
Workflows automate review and approval. Candidates must know the workflow model (steps, participants, transitions), workflow instances (running copies), and payloads (the content being processed). Understand participant steps (assigned to users/groups), OR/AND splits, and dynamic participants.
Know the Request for Activation and Request for Deactivation workflows, and how they differ from direct Activate/Deactivate actions. Understand replication agents (author to publish), the replication queue, and tree activation for bulk publishing. Know inbox behavior: tasks appear for assignees, and completing a step advances the instance.
Traps
- A workflow model is a template; an instance is a running execution.
- Completing a task in the inbox does not necessarily publish - publishing depends on the workflow's steps.
- Deleting a workflow instance does not delete the payload.
- Replication is asynchronous; a queued item may not appear instantly on publish.
- "Request for Activation" routes through approvers; direct Activate bypasses approval.
Rule of thumb
If a question says "content must be reviewed before going live," the answer involves a workflow with an approval step, not just replication permissions.
Worked example: An editor submits a page for approval. The Request for Activation workflow creates a task in the approver's inbox; on approval, the step triggers replication to publish, and the page becomes live.