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?
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.
What happens if admins are allowed to override and skip straight to approved?
The workflow exists on paper but gets bypassed under deadline pressure, usually on exactly the asset that most needed the check — undermining the entire point of having three stages.
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?
Metadata like alt text and the usage-rights field — draft is deliberately incomplete by default until the review stage fills in and confirms those gaps.