Reference Glossary
Draft / review / approved workflow
The standard three-stage pipeline an asset moves through — created as a draft, checked in review, released as approved — before it becomes eligible to publish.
Why it matters in a DAM
This is the mechanism that turns publish state into something enforced rather than aspirational: each transition can require a specific role, a completed metadata field, or a rights check before the asset is allowed to advance. It also builds an audit trail — if a wrong asset ships, the log shows exactly who approved it and when, instead of leaving that to memory.
A worked example
Common mistake
Teams add a review stage but let anyone skip straight to 'approved' with an admin override, so the workflow exists on paper but gets bypassed under deadline pressure — usually on exactly the asset that most needed the check.
The draft/review/approved pipeline is the concrete implementation behind an abstract idea like ‘we review our assets.’ Draft is where an asset lands on ingest, incomplete by default — missing metadata, unconfirmed rights, no crop presets generated yet. Review is where a defined set of stakeholders check it against whatever criteria matter for that asset type. Approved is a locked state: rights confirmed, required fields complete, ready to be pulled into a publish state.
What makes the workflow useful rather than ceremonial is gating each transition on something specific — a required field, a named reviewer’s sign-off, a rights check — rather than a single unlabeled ‘approve’ button anyone with edit access can click. A workflow that lets any user move an asset from draft straight to approved isn’t really enforcing three stages, just displaying three labels.
The audit trail this produces is often the workflow’s most-used feature outside of day-to-day work: when a compliance question or a wrong-asset incident comes up later, being able to show exactly which stage the asset was in, who approved it, and what they checked is worth more than the review itself.
Frequently asked
What are the three stages of this workflow and what happens at each?
Draft is where an asset lands on ingest, incomplete by default (missing metadata, unconfirmed rights); review is where designated stakeholders check it against defined criteria; approved is a locked state with rights confirmed and required fields complete, ready to be pulled into a publish state.
What makes this workflow more than just three labels in a system?
These three stages function as enforcement gates, not descriptive tags. A draft asset is typically invisible in general search and unavailable for use elsewhere in the system until it clears review. Review requires sign-off from a specific, authorized reviewer — not just any user with access. Approved unlocks the actual permission to publish or download the asset. Each status carries a real technical restriction, not just a label.
What happens if admins are allowed to override and skip straight to approved?
Overriding removes the workflow's protective function. If admins can skip review and jump straight to approved, unreviewed content can reach publication through the exact same path as properly vetted content — the gate no longer actually gates anything. This override tends to happen under deadline pressure, on exactly the assets that need the most scrutiny, leaving the review stage as a formality rather than a real check on what gets published.
How does this workflow connect to publish state?
It's the concrete mechanism behind an abstract 'we review our assets' claim — completing the approved stage is what makes an asset eligible to move into a publish state like 'published.'
What's the most-used feature of this workflow outside of day-to-day review?
The audit trail it produces — when a compliance question or wrong-asset incident comes up later, being able to show exactly which stage the asset was in, who approved it, and what they checked is often worth more than the original review.
What's missing from an asset in the draft stage, typically?
An asset at the draft stage typically lacks finalized metadata — usage rights, keywords, a full description — because it can still change before final approval. Filling these fields in prematurely risks having to redo the work if the asset itself is altered during review. Draft is deliberately left incomplete by design; that gap is what review is meant to close before the record locks.