Asset Lifecycle: Versions, Review, Embargo and Expiry

An asset is rarely finished the moment it is uploaded. It gets reviewed, corrected, replaced by a better take, held back until a launch date, and eventually reaches a point where the organisation no longer has the right to use it. Asset lifecycle features track that progression in the platform itself, so the state of a file is a property of the file rather than something a few people happen to remember.

The States an Asset Moves Through

Every asset occupies one of a defined set of states:

• Processing - uploaded, with previews and derivatives still being generated.
• Creation - processing is complete and the asset is being routed. This state is transient: assets requiring approval move to review, and everything else becomes active.
• Review - awaiting approval from the people responsible for signing it off.
• Embargo - approved, but deliberately not yet available for use.
• Active - approved, released, and available to everyone whose permissions allow it.
• Expiration - the asset has passed the date beyond which it should no longer be used.
• Archive - retained for the record, out of circulation.

The value of naming states this way is that "can I use this?" becomes a question with an answer. Without them, an asset sitting in a folder carries no indication of whether it was ever approved or whether its licence ran out last quarter, and the only defence is that somebody remembers.

Versions

When an asset is corrected or reshot, the replacement belongs with the original rather than beside it. Versioning keeps one asset with a history behind it, so the link you shared last month still resolves and still points at the current file.

This solves the most familiar failure in shared storage: a folder holding logo_final, logo_final_v2 and logo_FINAL_use_this, where the only person who knows which is correct is the one who made them. One asset with versions has an unambiguous current state and a retrievable past. See How to Manage Asset Versions for the mechanics.

Review and Approval

Review routes an asset to the people who need to sign it off before anyone else can use it. An asset in review is visible to its reviewers and held back from general use, and it becomes active only when the review completes. A rejected asset does not quietly proceed.

Reviews can be arranged in chains, so an asset passes through several stages - a brand check followed by a legal check, for instance - with each stage recorded. Where approval matters at all, it usually matters that it can be evidenced later, and a chain provides that as a by-product of doing the work.

Embargo

Approval and availability are different things. Campaign photography can be finished, signed off and completely correct while still being something nobody may publish until a launch date. Embargo covers that gap: the asset is in the library, approved, and unavailable until its release.

Embargoes are managed rather than merely set. A date can be extended when a launch slips or shortened when it moves up, an asset can be released early, and an embargo can be cancelled outright. Assets can also be grouped, so an entire launch shares a release date and moves together - including when that date changes, which is the situation where releasing assets one at a time reliably goes wrong. When the date arrives, release is automatic.

Expiry

Most organisations are better at acquiring rights than at tracking when they end. A model release covers two years, a stock licence covers one campaign, a sponsorship ends - and the image stays in the library, indistinguishable from material the organisation owns outright.

Expiry attaches that end date to the asset. As it approaches, the asset can be escalated so the people responsible are aware while there is still time to renew. When it passes, the asset moves out of active use and can be archived automatically, and deletion can be scheduled where the agreement requires the file to be removed rather than merely withdrawn.

This is the lifecycle feature with the clearest downside when it is absent. Using an image after its rights have lapsed is a legal problem, and it usually comes to light because someone outside the organisation noticed.

Locking

Some assets must stay in the library but must not be used, for example while a rights question is being resolved or after a licence has ended. Asset locking blocks a locked asset from being downloaded, shared or used, and records the reason, so nobody has to guess why it is off limits. Locks can be applied by hand or automatically by lifecycle rules, for example when rights expire.

When someone needs a locked asset, they can request access instead of working around the lock. Admins see these requests in one place and approve or reject them, so exceptions are deliberate and recorded.

Why Track Any of This in the Platform

Every one of these states can be managed with a spreadsheet, a shared calendar and a reliable colleague, and many organisations do exactly that. The difficulty is not that the method fails immediately - it is that it fails invisibly. A tracker only helps the people who know it exists, and the person about to reuse last year's campaign image is typically not one of them.

Recording state on the asset puts the answer where the question gets asked. Someone browsing the library sees that an asset is in review, embargoed until a date, or expired, at the moment they are deciding whether to use it, without needing to know which document to consult or whom to ask.

Availability

Lifecycle features are optional and enabled per workspace, individually. A team wanting expiry tracking without approval workflows can have exactly that, and it is usually better to enable one and use it properly than to switch on everything and have most of it ignored. Speak to your administrator or Data Dwell support about enabling them.