Metadata is the structured information attached to a digital asset: what it shows, who owns it, where it may be used and when it expires. In a digital asset management system, metadata is what turns a shared folder of files into a library people can actually search. This article covers why metadata matters, the field types available and what each is good for, and how tags, languages and visibility classification fit alongside them.
Without metadata, finding an asset depends on someone remembering where it was filed and what the file was called. That works for a few hundred files and breaks down completely at scale, which is the point most organisations start looking for a DAM in the first place.
Good metadata delivers five things:
Every uploaded file arrives carrying technical metadata, and this is read on upload without anyone configuring anything:
This is free organisation, but it only ever describes the file. It cannot tell you which campaign an image belongs to, whether it has been approved, or which markets it may be used in. That business context is what custom fields are for.
Custom fields, called metafields, capture the information specific to your organisation. The type you choose decides how a value is entered and, more importantly, whether it can be used as a filter.
These are searchable but are not offered as filters, so use them for detail people read rather than for narrowing a result set:
Beyond the type, each field carries a few settings worth knowing about:
A metadata profile is a template that decides which fields appear on an asset. Rather than showing every field the platform has to every user, a profile presents only the ones relevant to that kind of content: a product photograph and a sales presentation need very different information recorded against them.
Profiles also decide which of those fields are required, so the rules can be strict for the content that matters and relaxed elsewhere. A profile is applied when an asset is uploaded and can be changed afterwards by editing the asset, and metadata set on a folder is applied to assets uploaded into it. This is the mechanism that keeps metadata consistent without asking people to remember conventions.
Beyond custom metafields, the platform provides its own metadata. This comes in two forms.
These are captured by the platform and always present on an asset:
System metafields are built-in fields that behave like custom metafields but are provided by the platform rather than created by your organisation. They include:
Important: A system metafield must be added to a Metadata Profile before it appears on an asset. This is the most common reason a field seems to be missing: if your team cannot set a language, add an alert note, or record copyright on an asset, check that the field is included in the profile that asset uses.
Languages are the one system metafield with their own configuration. Administrators create and manage the available languages in Asset Settings > Languages, where each language is defined and given its flag. As above, Language must then be added to a Metadata Profile before users can assign it.
Metadata can be assigned at folder level as well as on individual assets. When a folder has metadata assigned, assets uploaded into that folder inherit those values automatically, which removes a large amount of repetitive entry for teams that organise content by campaign, product, or project.
Two behaviours are worth understanding:
Folder metadata is an optional feature enabled by an administrator, and is not available on the root of the Library. Assets cannot currently be searched or filtered by folder-assigned values specifically, and folder metadata cannot be bulk-edited across multiple folders.
Tags are a shared, free-form vocabulary across the whole library. Unlike a dropdown, there is no predefined list: anyone editing an asset can add a tag, and tags extracted from a file's embedded keywords land here too. That openness is the strength and the weakness. Tags capture the things nobody thought to build a field for, but they drift quickly if left ungoverned.
Choosing between tags and a field comes down to how controlled the vocabulary needs to be:
Whichever you use, agree the basics early: singular or plural, one term per concept rather than a set of synonyms, and a periodic review to merge the duplicates that inevitably appear.
Languages are maintained as a list for the workspace and then assigned to assets, which lets a library hold the same brochure in six markets without six competing naming conventions. Captions and transcriptions carry their own language, and users can filter by language to see only the versions relevant to them. User groups can also be restricted to particular languages, so a regional team sees the versions it is responsible for rather than everything.
Language here describes the content of the asset, not the interface, and no translation is performed on the asset or its metadata.
Visibility levels add asset-level access control on top of folder permissions. Each level is a named tier, users are granted a tier through their user group, and they see assets at or below that tier. Both checks apply: a user needs folder access and a sufficient tier before an asset appears, and assets with no level assigned sit at the lowest tier so they stay visible to everyone with access to the folder.
This solves a specific problem: content with different access requirements that has to live in the same place. Typical uses include:
If your content can simply be separated into different folders, folder permissions are the simpler tool. Reach for visibility classification when your folder structure is organised around something other than access, such as project or asset type.
The Metadata item in the Library navigation offers an alternative to folder browsing. It is hidden when a workspace has no metafields and no tags configured, and access to it is controlled by a permission, so not every user will see it. If you expect the Metadata view and cannot find it, contact your administrator.
How dates, times and numbers are displayed is controlled in Site Settings for the workspace and in My Profile for an individual user, under Date & Time. Only supported formats are accepted:
H:i, H:i:s, h:i a, h:i:s ad/m/Y, m/d/Y, Y/m/d, d-m-Y, m-d-Y, Y-m-den-US, de-DE, no-NOCombined date and time display can also be configured. Entering a format outside these lists is rejected.
As a rule of thumb:
Start with the smallest set of fields that answers the questions people actually ask when they are looking for something, and add more only when a real search fails. A short, well-maintained schema beats a comprehensive one nobody fills in.