Learning objectives
- Trace content through its lifecycle
- Identify the roles on a content management team
- Explain versioning, version stacks, and rollback
- Distinguish scheduling, expiration, workflow, approvals, and collaboration
- Understand permissions and dependency management
1The content lifecycle
Every piece of content has a life. Thinking in terms of its stages helps you design the right services around it. A single object also moves through layers of visibility — much of its life is spent invisible to the public.
Not a straight line. A single object can be several things at once — a published version the public sees, a newer draft an editor is revising, and a stack of archived historical versions. The lifecycle describes states an object moves through, not a one-way conveyor belt.
2The content management team
A CMS project involves more than "editors." Five broad roles recur, each with sub-roles.
Editors
Responsible for creating, editing, and managing content — the role that interacts with the CMS most intimately after launch. "Editor" is a crude generalization: not all editors are equal, and what counts as a "normal" editor is project-specific. Sub-roles are defined by how their capabilities are limited (contributors, approvers, community managers, marketers).
Site planners
Design the website the CMS will manage. Most of their work happens before launch, with sporadic involvement as the site evolves (information architects, designers, content strategists).
Developers
Install, configure, integrate, and template the CMS to match requirements. Effort scales with complexity and fit — a WordPress blog may need almost none; a bespoke enterprise intranet is a huge undertaking. Not all developers are equal, either.
Administrators
Keep the CMS and its infrastructure running. The CMS administrator manages users, permissions, workflow, and licensing — everything not related to creating content itself.
Stakeholders
An amorphous group — usually business or marketing staff — responsible for the results the CMS is meant to produce. They see the CMS purely as a means to an end, generally to increase revenue or reduce cost.
3The editing interface
Most of an editor's time is spent in the editing interface, which has to solve several problems well:
- Findability & traversal — how editors locate and move among content
- Type selection — choosing what kind of content to create
- Preview — seeing how content will look before it's live
- Editing elements — the fields and controls for each attribute (recall the "editorial element" from Lesson 3)
4Versioning
Saving each change as a new copy rather than overwriting the previous state, preserving the full history as a "version stack."
Versioning is one of the highest-value editorial services. Because changes accumulate rather than overwrite, editors can roll back to an earlier version, audit who changed what and when (for security or compliance), and compare versions to see exactly what changed. Publishing, in many systems, is simply marking one version in the stack as "published."
5Scheduling, expiration & dependencies
Scheduling
Publish content automatically at a future date/time — useful for embargoed announcements. Some systems can publish a coordinated "changeset" of many objects at once.
Expiration
Automatically un-publish or archive content when it's no longer relevant, so stale content doesn't linger.
Dependency management
Track what content uses what, so deleting an object doesn't silently break others — and so you can find "orphaned," unused content.
6Workflow vs. approvals vs. collaboration
These three are related but distinct, and confusing them causes real trouble.
A framework that moves content through a defined set of steps. Content is in one state at a time; when that state resolves, it advances to the next until the workflow ends. A step might change content, require a human decision, or run code.
Approvals
A specific pattern where content must be signed off before advancing — e.g. draft → editor review → legal review → published. Many systems have dedicated approval features separate from general workflow.
Collaboration
Several people working on and discussing content together. This is what many organizations actually want when they ask for "workflow" — informal back-and-forth, not a rigid chain.
A common and costly mix-up: teams ask for "workflow" when they need collaboration. Rigid approval chains can actually get in the way of the informal back-and-forth that makes content good. Decide which you truly need before building either — and remember that a heavyweight process imposed on a small team quietly destroys morale and throughput.
7Permissions
Granting (1) a specific user, (2) the ability to perform a specific action, (3) on a specific content object. E.g. "Bob can edit the Privacy Policy."
At scale, granting permissions one user at a time is unmanageable, so they're almost always assigned in bulk through groups and roles. A clean way to keep the concepts straight: workflow moves content along a process; permissions govern who is allowed to act at each step. Both, ultimately, are the CMS enforcing governance decisions that humans made (recall Lesson 1 — governance itself is a human discipline).
🔑 Key terms from this lesson
- Content lifecycle
- Create → Edit → Approve → Publish → Archive → Delete, with content living in layers of visibility.
- Versioning / version stack
- Saving changes as new copies, preserving history for rollback, audit, and comparison.
- Scheduling & expiration
- Automatically publishing at, or un-publishing after, set times.
- Dependency management
- Tracking which content relies on which, to prevent breakage and find orphans.
- Workflow
- A framework moving content through defined steps, one state at a time.
- Permission
- A specific user's authorization to perform a specific action on specific content, usually granted via roles/groups.
Review Questions
Test your understanding. Click each question to reveal the answer.