Workflows, Publishing, and Content Governance
Workflows automate review and approval. Know the difference between workflow models (the design, built in the Workflow Editor), workflow instances (a running execution), and workflow launchers (triggers that start an instance on an event such as page creation or modification). Participants receive inbox tasks; workflow steps can be participant steps, process steps, or container steps. The Request for Activation/Deactivation workflow is the classic approval gate before replication.
Replication moves content from author to publish via agents (default, dispatcher flush). Understand activate (publish), deactivate (unpublish), and tree activation. Dispatcher flush agents invalidate cached pages so new content appears. A frequent trap: assuming publish is instant - dispatcher caching can delay visibility until flush occurs.
Governance concepts: permissions/ACLs on content, version purging, audit logs, and launches for staged content. Know that workflow launchers are configured per path and event, and that disabling a launcher stops new instances but does not stop running ones.
Rule of thumb: if a question asks how to require approval before a page goes live, the answer is a workflow launcher on modification that starts a Request for Activation workflow, combined with replication permissions so authors cannot publish directly. If it asks why a published page still shows old content, check the dispatcher flush agent and cache.