Folders vs metadata: how to organise a DAM

Why it matters

Most organisations arrive at a DAM with a shared drive, and the shared drive was organised with folders. A folder tree has one built-in limit: each file sits in exactly one place, so the tree can only express one way of grouping files. The Smithsonian's file-organisation guidance shows the choice this forces. A large image set can be filed by year, then month, then location, or by location with the date moved into the file name, but not both ways at once R8. Every other way of grouping the files has to go somewhere else: into the file name, into duplicate copies, or nowhere. One DAM vendor sums up the same limit: folders let you organise files efficiently "in one way" only R14.

ANSI/NISO Z39.19 explains why digital collections need not accept this limit. It recommends facet analysis, rather than a single top-down hierarchy, for content that can be seen from several perspectives. It also recommends it for electronic content objects, where physical location and the placing of related items side by side do not matter R1. A DAM can show the same asset under brand, product, campaign, market and rights status at once, if those are stored as metadata rather than as folder levels.

When folders carry the whole organisation, these problems tend to follow:

• Duplicates. The same image is copied into "Campaign X", "Product Y" and "Social" folders. Copies drift apart, and updating or withdrawing an asset means finding every copy.
• Silos. The UK National Archives warns that folders named after business units or individuals discourage sharing, cause duplication that complicates disposal, and leave legacy areas behind for teams that no longer exist R5.
• Lost context. Description held only in a folder name disappears when the file is downloaded or moved R8 (see file naming conventions).
• Permissions and structure that cannot change independently. If the tree also defines who sees what, reorganising for findability means re-doing security, and the other way round.
• Hard-to-use depth. Nielsen Norman Group's research on navigation concludes that, other things being equal, deep hierarchies are harder to use than flat ones R3.

Metadata is not free either. Faceted navigation only works when every existing and future item has a value for each facet, which is a real ongoing cost R2. So the practical question is not "folders or metadata?" but which job each mechanism should do. No independent, freely accessible study was found that measures time lost to folder-only DAM organisation. Vendor figures exist but are not repeated here.

Core concepts

Three access-control models also matter here. NIST SP 800-162 describes identity-based control through access control lists (ACLs) on each object, role-based control (RBAC) through predefined roles, and attribute-based control (ABAC). In ABAC, policies evaluate attributes of the user, the object and the context at the moment of each request R6. In DAM terms, folder permissions are usually group or role grants on a container. Metadata-based permissions are a form of ABAC.

Recommended practices

1. List the jobs, then assign each to one mechanism

Before you draw a tree, write down what the organisation needs from "structure". The jobs usually include:

If a job appears twice in the "Best default" column of your own version of this table, decide which mechanism wins. If the folder tree is doing more than two jobs, it will probably be hard to maintain. Vendor guidance tends to land on the same hybrid: folders for structure, metadata and tags for findability R12 R15.

2. Keep folders for what is truly exclusive

A folder is the right tool when an asset can only have one value and that value controls behaviour. Access boundaries, lifecycle stage, legal entity and stewardship are typical. The National Archives' guidance on shared drives describes this kind of tree: well-designed folders let an organisation apply access controls and disposal schedules to whole aggregations of records consistently, which reduces management overhead R5.

Many DAMs also attach settings to folders, and these are a valid reason to keep a folder level. In the wiki, Adobe Experience Manager Assets documents metadata schema forms and processing profiles per folder, and Cloudinary documents folders as the hierarchy used for access control . If your platform works this way, design the top levels around the settings that need to differ, and nothing else.

3. Design the tree around stable functions, and keep it shallow

• Functions, not departments. The National Archives recommends modelling the filing structure on the organisation's functions, or on subject themes in places, and not using the names of business units or individuals R5. Brands, regions or legal entities are often more stable than team names.
• Few levels. The same guidance describes a functional structure of three levels (function, activity, transaction), with records captured only at a fourth, defined level. The upper "classification folders" never hold records R5. Nielsen Norman Group finds deep hierarchies harder to use and suggests extra routes, such as shortcuts to popular items, where depth cannot be avoided R3. Vendor guidance often suggests two to four levels for a DAM R12. Treat that as a rule of thumb, not a standard.
• Controlled creation. Uncontrolled folder creation is the main way trees decay. The National Archives recommends that only a few people control the creation, moving and deletion of classification folders, so that ad hoc sub-structures do not multiply R5.
• Names and documentation. Use a short, consistent naming rule for folders and document what belongs where R8 R5. Do not repeat information in the folder name that is already in the file name or in metadata R8.

4. Describe with metadata, and let people navigate with facets

Everything that describes the asset (what it shows, which product, campaign, market, channel, rights status) belongs in metadata fields with controlled values, not in folder levels. Z39.19's facet analysis is the method: identify the independent characteristics of your content and give each its own small vocabulary R1. The taxonomy & controlled vocabularies guide covers how to build those vocabularies, and metadata schema & governance covers which fields to make mandatory.

Each facet costs something to maintain, because every asset needs a value for it R2. Make facet fields mandatory at ingest, fill them from defaults or upload templates where you can, and drop facets nobody filters on. Some platforms skip the folder tree entirely: Sitecore Content Hub has no folder tree by default and organises assets through metadata and taxonomy relations shown as facets . That shows a metadata-first model is workable, but it puts more weight on metadata quality.

5. Use collections for curation, and govern them lightly

Collections answer "which assets belong together for this purpose?" without moving anything. The Dublin Core type vocabulary simply defines a collection as a group of resources R10. Repository data models such as PCDM record it as membership links, so an object can sit in several collections and collections can nest R9. That is the many-to-many relationship a folder tree cannot express.

Platforms implement this in different ways. In the wiki, Canto stores assets in albums inside folders, and one asset can sit in several albums. MediaValet lets one asset belong to several categories . Check whether a "second location" is a real membership link or a copy before relying on it.

Collections need light governance, or they multiply:

• Distinguish personal, shared and external collections, with different defaults for visibility and lifetime.
• Give shared collections an owner and, for campaign kits, an end date after which they are archived.
• Check that a collection share respects the permissions and rights of each asset in it. A shared collection should never become a way around an embargo or licence limit.

6. Use saved searches and dynamic collections for "always current" views

Anything that should change by itself as assets arrive or expire is better as a query than as a hand-built list. Examples are "current approved logos", "product images for market X" and "assets whose licence expires within 30 days". In the wiki, Adobe Experience Manager Assets documents smart collections built on saved searches, Cloudinary offers rule-based dynamic collections, and MediaBeacon can block downloads of assets that fall outside a configured saved search, such as an expiry-date rule .

Two conditions make this reliable. First, the fields being queried must be complete and controlled, or the view silently misses assets. Second, queries should reference stable field and term identifiers, so that renaming a label does not break them (see taxonomy & controlled vocabularies). Review shared saved searches whenever the schema or a vocabulary changes.

7. Design permissions deliberately

Folder permissions are the most common reason organisations keep a tree, and also the most common reason trees become tangled. A few principles from records-management and security guidance apply directly:

• Open by default where possible. The National Archives recommends setting access within the filing structure as wide as possible unless there is a specific reason to restrict it. This reduces both the administrative overhead and the barriers to sharing R5.
• Grant to groups, at a high level. Assigning access to individuals is hard to monitor. Groups, applied at the highest practical level of the tree, are easier to manage R5. Provision those groups from your identity provider (for example with SCIM) so that leavers lose access automatically.
• Avoid per-asset exceptions. Every exception is a separate rule to maintain and audit. Platforms impose limits for this reason: SharePoint in Microsoft 365, for example, supports up to 50,000 unique permission scopes per list or library but recommends staying below 5,000 R11. If you need many exceptions, the tree is probably answering the wrong question.
• Use attributes for restrictions that cut across folders. An embargo, a market-specific licence or a confidential product launch rarely fits one folder. NIST notes that role-based models struggle with such multi-factor decisions and tend towards "role explosion". ABAC evaluates attributes of the user and the object against a policy instead R6. OWASP's authorization guidance also recommends attribute- or relationship-based models over pure RBAC for fine-grained rules, together with least privilege and deny-by-default R13. In the wiki, Keepeek documents three permission modes that can be combined: by folder, by status, and by matching asset metadata against user attributes .
• Treat metadata errors as security errors. When a field controls access, a missing or wrong value exposes or hides assets. Make such fields mandatory, validate them on every ingest path, and default to the restrictive value when the field is empty R6 R13. Rights and embargo fields are covered in more depth in rights & usage management.
• Document and review. Keep a record of groups and the folders or rules they apply to, outside the system if necessary, and review them on a schedule R5.

8. Decouple identifiers and delivery URLs from folder paths

If an asset's public URL, API reference or integration key contains its folder path, every reorganisation breaks something. Use the DAM's stable asset ID for integrations, and use delivery URLs that do not change when a folder is renamed or moved. In the wiki, Cloudinary illustrates both models: in its default "dynamic folders" mode the folder is separate from the public ID and URL, while in the legacy "fixed folder" mode the folder path is part of the public ID . Ask the same question of any platform before you commit to a tree. The file naming conventions guide covers the related point of keeping identity out of file names.

9. When migrating from a folder tree, mine it rather than copy it

An old folder path holds information, but in an unstructured form. Treat it as a source to analyse:

1. Export the full paths with the file inventory.
2. Classify each path segment: does it mean a brand, a year, a campaign, a team, a status, or nothing in particular?
3. Map meaningful segments to fields and controlled values. Discard segments that only reflected an old team or personal habit.
4. Keep the original path in a read-only field. Archivists preserve the original order of records because it shows how their creator used them and makes the records easier to interpret R7. A stored path does the same job for a DAM: it lets you trace any asset back to its source and justify later clean-up.
5. Build the new tree from practice 2, not from the old one. Vendor guidance warns against simply digitising the old filing system R12.

Some migration services already convert folders this way. Brandfolder, for example, documents that its assisted migration turns the source folder structure into tags . Automatic conversion only moves the problem, though. Raw folder names as tags still need mapping to your vocabulary. The planned DAM migration guide covers the wider process.

10. Test with users and watch for decay

• Tree testing. Ask representative users to find specific items using only the proposed hierarchy, and measure success, directness and time before building it. Tree testing evaluates an existing or proposed structure. Card sorting helps generate one R4.
• Findability tasks with facets. Repeat the exercise in the real DAM with facets and search, and compare.
• Search and navigation logs. Look at zero-result searches, and at folders that are browsed often but whose contents are rarely downloaded.
• Sprawl reports. Count folders created outside the agreed levels, empty folders, collections without an owner or untouched for a year, and saved searches that return nothing.

Common pitfalls

How DAM platforms support this

The wiki's solution pages document each platform's organisation model in the Organization, Search & discovery and Rights & governance sections of their features pages. The examples below are the ones linked in the practices above; each shows a distinct design choice. They are not a ranking, and many other platforms offer similar functions.

Questions to put to any platform, in demos or RFPs:

• Can one asset appear in several places without being copied? Is that a membership link, an alias or a duplicate?
• Can permissions be set by folder, by metadata value, by status, or by a combination? What happens when they conflict?
• Is there a documented limit on restricted folders, unique permissions or collection size?
• Do public URLs and API identifiers change when a folder is renamed or moved?
• Can saved searches be shared, used as dynamic collections, and drive rules such as download restrictions?
• Can settings (schemas, processing, retention) be inherited from folders, keyed on metadata, or both?
• How does the platform's migration service treat source folder paths?

Where a solution page says Unknown for saved searches or permission models, the vendor documentation did not cover it at the time of research. Ask the vendor directly.