Reference Glossary
Version control
Version control in a DAM is the system's ability to preserve, distinguish, and roll back between successive iterations of the same asset while recording what changed and by whom.
Why it matters in a DAM
Creative and legal work goes through many rounds of revision, and teams need to retrieve the exact version that was actually approved and used in a specific campaign — not just whatever the latest edit happens to be. Without real version control built into the DAM, an approved final can get silently overwritten by a later edit, and there is no reliable way to prove afterward which version was actually published.
A worked example
Common mistake
Teams rely on filename conventions like v1, v2, final, final_FINAL instead of the DAM's built-in version history, which breaks the moment two people edit the same source file independently and upload under matching names.
Real version control keeps every prior iteration of an asset accessible and distinguishable, rather than treating each save as a replacement for the last. That matters practically whenever someone needs to answer ‘which version did we actually use’ — a question that comes up in disputes over what a campaign showed, in legal review of a claim that changed between drafts, or simply when a later edit turns out to have introduced an error and the team needs to revert.
The filename convention teams reach for instead — appending v2, final, or final_v3 to a file — looks like version control but is not: it depends entirely on everyone following the same naming discipline, breaks as soon as two people edit independently, and gives the system no actual record of what changed between those files, only guesses based on the name.
Where version control adds real value is in linking a specific version to its actual use — recording that campaign X ran with version 4 of an asset, not just that version 4 exists somewhere in the history — since without that link, having many saved versions does not by itself answer which one was live at a given time.
Frequently asked
Why do filename conventions like "v2_final_FINAL" fail as version control?
They depend entirely on everyone following the same naming discipline and break as soon as two people edit the same source file independently and upload under matching names — the system has no actual record of what changed.
What's the practical value of linking a version to its actual use?
Recording that a specific campaign ran with version 4 of an asset, not just that version 4 exists somewhere in history — without that link, having many saved versions doesn't answer which one was actually live at a given time.
What can go wrong without real version control in a DAM?
An approved final can get silently overwritten by a later edit, and there's no reliable way to prove afterward which version was actually published.
What should a DAM's version record capture for each iteration?
A unique version number or ID, ideally a visual or metadata diff of what changed, and the ability to roll back or reference a prior version without losing the current one.
When does the question "which version did we actually use" typically come up?
In disputes over what a campaign showed, in legal review of a claim that changed between drafts, or when a later edit introduces an error and the team needs to revert.
How is real version control different from just saving over a file each time?
It keeps every prior iteration accessible and distinguishable rather than treating each save as a replacement for the last, preserving the ability to compare and roll back.