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.
Every asset occupies one of a defined set of states:
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.
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 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.
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.
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.
Asset locking prevents two people from editing the same asset at once. In a library where several contributors work on the same material, it removes the class of problem where one person's changes silently replace another's, and it makes it obvious that an asset is currently being worked on rather than available to take.
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.
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.