A version is defined as a particular form or variant of something. In the case of Digital Asset Management (DAM), versions apply to digital assets and their respective metadata.  Versioning can involve updating, editing or changing assets and/or metadata safely. A version often involves a correction or an improvement by editing.

Versions are not variations nor renditions

Be careful not to mix up the concept of versions vs. variations vs. renditions.

Versions  in a DAM are important to maintain control over edits. We should be able to have full control of versions and accountability of the version history so we can save/restore older versions if an error is made. Older versions can remain available as needed.

There is rarely one true “final” asset, but rather multiple assets with variations, depending on the use or situation, which may be used in different places. It is highly possible to have different versions of the same asset. We may also need different renditions of an asset which may have different file types (different file extensions) of similar content.

A version is not a child asset either. If we want to start talking about parent-child relationships between assets, that will be another rabbit hole we can tumble down in the future.

No version control needed here?

Don’t think you need version control nor version history in a DAM? Then you must not make any mistakes nor does anyone else. Ever. Good for you! Some of us wish we could live in your world.

Now back to reality…

When we start accumulating assets for projects, we are bound to have corrections.

Without version control or version history, changes are more permanent (like an overwrite) which can yield more work if the last change (or changes) were an error. Without version control, there is no going back even if we need to. There is little record as to what was done to reach this point without version history. The lack of version control does not help job security either. At some point, a version will be selected and it may be the latest version.

If we do not have/use version control in the DAM, we are left with few options to add a new version by overwriting an existing asset, by deleting an asset or by uploading the asset again as a new asset. These are bad ideas either way.Why?

First, these are very poor workflows with near term repercussions. These are also archaic options.

Second, if we overwrite asset on top of asset, we are bound by failure on top of failure with no recourse except for more failure (and it still equals fail).

If  we have version history without full version control, that is simply having the ability to watch disasters after they happen, but yet again have no ability to fix them.

If we upload a new asset followed by uploading more edits of this asset (as separate, new assets) with a occasional “final edited” new asset upload, we are creating digital dump ground of more incorrect assets and this will likely confuse most users on which happens to be the correct asset to use, since there is no version history nor version control.

Referencing backups are possible, but how often are backups done and which backup is relevant to your need?

No ‘single source of truth’ can exist without proper version control in the long term. That goes for brand consistency or any consistency as well.

Metadata versions for assets

There are plenty of reasons to edit an asset, but what about the respective metadata of that asset? Whether the metadata is embedded or associated, version control may still be needed. There are DAM systems with full version control for assets and metadata, even down to a single character change within the metadata. You either have full version control or you do not have full control of versions for assets and metadata. Test the DAM and see for yourself.

When selecting a DAM system…

When reviewing DAM systems for the one that best suits your business needs, be sure to check:

• Can the DAM support version control?
• How does the DAM handle version control and to what degree?
• How does the DAM display version history to users?
• How does the DAM  represent versions?
• How does the DAM handle an asset version?
• How does the DAM handle a metadata version? (yes, metadata sometimes needs to change even if the asset does not)
• How can DAM users see the version history of an asset and/or its metadata?
• If the DAM can handle both asset versions and metadata versions, are these handled as one version jointly or separately?
• Can we edit the metadata of an asset to only version the metadata (a credit for example)? Or does a version affect the asset and metadata combined? Which is edited more often?
• By testing with common assets and metadata, which need full version control?
• What happens to UIDs when versions occur in the DAM?
• Can the version in the DAM be handled in a programmatic way or by human users (one asset at a time) only? Yes, versioning can sometimes be automated, but can the DAM handle this automation? Or is that handled manually?

Do you have full version control in your DAM?