Workflow
Asset management and content management: where the boundary sits
Both systems hold images. Both have a search box, a permissions model and a version history. The question of which one should hold what is therefore asked constantly, and answered badly, usually by whichever system was installed first.
The boundary is not about file types. It is about which system is the record of the thing.
Two different records
An asset library is the record of the asset. It knows where a photograph came from, who owns it, what may be done with it, which versions exist, which is current, and what has been derived from it. It answers the question: what is this file, and may I use it?
A content system is the record of the page. It knows what was published, in what arrangement, when, by whom, and where it is linked from. It answers the question: what did the reader see?
A photograph is an asset that appears on a page. Its rights, provenance and version history belong to the asset library. Its placement, caption in context and publication date belong to the content system.
What goes wrong when the CMS owns the assets
The media library inside a content system is a convenience, and it is not an asset record.
Files uploaded there arrive stripped of their context. Whatever rights information existed is now in an email somewhere. Versions accumulate as separate uploads with numbers in the filename. There is no master and derivative distinction, so the file that happens to be there is the only file there is.
The visible consequence appears after a few years: the same photograph exists eleven times at eight resolutions, nobody knows which is the original, and none of them records that the frame was licensed for one use in 2019.
The invisible consequence is worse. When a licence expires or a rights holder objects, there is no way to find every place the image was used, because the content system indexes pages, not assets.
What goes wrong when the DAM owns the pages
The opposite error is less common and equally awkward.
An asset library asked to publish has no editorial model. It has no concept of a page, a section, a running order, a scheduled publication or an embargo. Its workflow is built around approval of a file, not around the production of an edition.
What it produces is a set of asset pages — one per file — which is a catalogue, not a publication. Every real editorial requirement then arrives as a customisation, and the library slowly becomes a bad content system with an excellent rights model.
How they should meet
The working arrangement is that the asset library remains the record, and the content system references rather than copies.
An editor building a page searches the asset library from inside the content system, selects a frame, and places it. What is stored on the page is a reference to the asset plus a rendition specification — the crop, the size — not a copy of the file.
That single design decision delivers most of the benefit:
Rights travel. The editor sees the restrictions at the point of selection, rather than discovering them afterwards, or not at all.
Corrections propagate. A caption or credit fixed in the asset is fixed everywhere it appears.
Usage is traceable. The asset knows which pages reference it, which is what makes a licence expiry or a takedown actionable rather than theoretical.
Permissions hold. The browser inside the content system shows each editor only what they are entitled to use, because the asset library is still the thing deciding.
Versions stay straight. There is one master, and the page carries a specification for a derivative rather than a derivative that has drifted.
What the content system still owns
References, not files — but plenty else.
The page structure, the running order, the navigation, the publication schedule, the URL, the layout, and the published text including the caption as it appears in this particular context. A photograph's asset caption is the description of the frame; the page's caption is that description fitted to this story. Both are legitimate and they are different records.
The one shared thing
The vocabulary should be the same on both sides. A subject term meaning one thing in the asset library and another in the content system makes it impossible to ask what has been published about anything, which is a question both systems should be able to answer together.
Agree the controlled terms once and use them in both places. It is the cheapest piece of integration available and it is usually skipped.
Conclusion
The asset library is the record of the file; the content system is the record of the page. Pages reference assets rather than copying them, rights and corrections then travel automatically, and usage becomes traceable. Share the vocabulary, keep the records separate, and neither system has to become a poor imitation of the other.