Folders, taxonomy and metadata in AEM Assets

/content/dam/<project>/
  <brand>/
    <market>/
      <campaign-or-year>/
        <asset-type>/        # product, lifestyle, logo, document

# Folders, taxonomy and metadata in AEM Assets

Verified 2026-09 against
<https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/assets/overview>.

## Folder design

Permissions, processing profiles and metadata profiles are all applied to folder trees, so the tree
is the unit of governance. Design it around the questions "who may see this" and "what processing
does this need", then check it still matches how people browse.

A workable shape for a multi-brand, multi-market DAM:

```
/content/dam/<project>/
  <brand>/
    <market>/
      <campaign-or-year>/
        <asset-type>/        # product, lifestyle, logo, document
```

Rules of thumb:

- A few thousand children per folder at most. Beyond that, listing, moving and permission changes
  all slow down, and the authoring UI becomes unpleasant well before anything technically fails.
- Depth is cheap; breadth is not. Prefer another level to a folder with 50,000 children.
- A dimension that cuts *across* the tree (photographer, licence type, colour) is metadata or a tag,
  never a folder — an asset lives in exactly one folder.
- Plan the split before ingest. Re-filing at volume means re-running references, and anything that
  linked to the old path has to be found.

## Metadata schemas

A schema defines the form authors see for a given asset type. Keep the required set small and
meaningful:

| Field | Type | Required | Why |
|---|---|---|---|
| Title | text | yes | Everything else assumes it |
| Description | multiline | no | Useful, rarely complete |
| Licence / rights | tag or dropdown | yes | Legal exposure if unknown |
| Expiry date | date | yes where rights are time-bound | Enforced at delivery |
| Market | tag | yes | Drives both search and permissions |
| Asset type | tag | yes | Drives processing and search facets |
| Source / photographer | text | no | Attribution and re-licensing |

Anything not searched on, governed by or used to drive processing is optional — a long required list
produces junk values, not better metadata.

## Metadata profiles

A metadata profile applies default values to assets uploaded into a folder. This is how required
fields actually get populated at volume: apply a profile to `<brand>/<market>` that sets market,
brand and default licence, and the author only supplies what is genuinely per-asset.

Apply profiles before a bulk import, not after — a profile does not retroactively fill existing
assets.

## Tags

- Controlled taxonomy under `/content/cq:tags/<project>`, mirroring the facets people search by.
- Namespaces per dimension (market, product line, asset type) rather than one flat list.
- A tag rename keeps existing references (assets point at the tag node); deleting one does not.
- Free-text keyword fields defeat search at scale: "t-shirt", "tshirt" and "T Shirt" are three
  values. Use tags wherever a value should be selectable.

## Where large collections start to hurt

- **Folder listing and move** degrade with children per folder — the first thing users notice.
- **Search** depends on indexes; a facet on an unindexed property gets slow as the collection grows.
  Check `aem-performance` for index diagnosis.
- **Permission evaluation** costs more with deep, heavily-overridden ACL trees. Permission at a few
  deliberate levels rather than per campaign folder.
- **Reprocessing** a large tree is a long-running job. Validate profiles on a sample folder first.