Custom Metadata Categories
Metadata Categories let you define reusable templates for Custom Metadata and assign them to folders. A Category is a named schema of keys, where each key either accepts free-form text or restricts entries to a fixed list of allowed values. A single Category can mix both kinds of keys.
Assigning a Category to a folder applies the schema to its files and subfolders unless a subfolder replaces or explicitly disables the inherited assignment. Any user with Full or Admin permission on the folder can set Custom Metadata on those files, picking from the Category's keys and from each restricted key's allowed values. For example, a Category for invoice folders might define a Department key with allowed values like Sales, Marketing, and Engineering, plus a free-form Notes key for ad-hoc detail.
Site Administrators and Workspace Administrators (within the folders they administer) can create and assign Metadata Categories. Because Categories are reusable, a single schema defined once can be assigned to as many folders as need it, so teams keep metadata consistent everywhere the same kind of file lives.
How Metadata Categories Work
Each folder uses one Metadata Category at a time. Metadata Category has a Replace nested effect, so a Category assigned to a subfolder takes precedence over the inherited Category. The schemas do not combine: people editing Custom Metadata use the keys and allowed values from the Category that applies to that folder.
A subfolder can also explicitly disable the inherited Category, allowing that branch to use Custom Metadata without the parent's schema. A deeper folder can assign its own Category. Replacing, removing, or explicitly disabling an assignment leaves existing Custom Metadata keys and values in place.
A Category can also designate default columns, which are keys that automatically appear on the Files page of the Web App for any folder using that Category. Default columns make the relevant metadata visible without each user configuring their own column layout, so every folder using the same Category presents the same view. For a vendor-onboarding Category, default columns such as Vendor ID and Onboarding Stage keep those details visible in each vendor folder.
A Child Site's or Connected Site Host's assigned Category is not visible through the viewing Site's _/Sites/<site-id> folder. An authorized administrator views and configures it directly on the storing Site. A Partner Channel Route Path instead shows its final target's Category, under the target's normal visibility rules. Access Across Sites and Storage explains the distinction between a route and a Site view.
Custom Metadata vs. Metadata Categories
Using Custom Metadata without Metadata Categories leaves the metadata open-ended. Anyone with Full or Admin permission can attach any key and any value to a file or folder. That flexibility lets casings, typos, and key names drift over time, which complicates searching, reporting, and Automations that depend on exact matches.
Metadata Categories add structure on top of Custom Metadata. Use plain Custom Metadata when each folder needs ad-hoc tagging or when the keys vary widely across files. Use a Metadata Category when many folders share the same kind of file, when downstream tooling depends on consistent values, or when users benefit from a controlled list instead of free-form entry.
Who Can Manage and Assign Metadata Categories
Site Administrators and Workspace Administrators can create, view, edit, delete, and assign Metadata Categories. Workspace Administrators work within the Workspaces they administer, and Folder Admins work within the folders they administer, so individual teams can apply standard schemas to their own areas without involving a Site Administrator.
Users without admin permissions can't create or assign Categories. Anyone with Full or Admin permission on a folder can set Custom Metadata on files in that folder, picking from the Category's keys and from each restricted key's allowed values. Users with List permission can view Category-driven Custom Metadata but can't modify it.
For a processing workflow, a Category can define a Status key with values such as Under Review, Approved, and Rejected. People updating the metadata choose from the same list, reducing differences in spelling or casing that affect searches and downstream rules. Assigning the Category does not remove older values that fall outside the list; review the mismatches described below.
A Classification key can offer your organization's labels, such as Internal or Confidential. Those labels describe the files; they do not grant or restrict access. Folder permissions control access independently.
Handling Changes to a Metadata Category
Metadata Categories are reusable, so a Category can change after it's been assigned to one or more folders. Three changes can produce a mismatch between a folder's existing Custom Metadata and the Category assigned to it. In every case, when using the web app, the system flags affected entries instead of changing or deleting them, so an authorized user decides what to do with each flagged value.
Deleting the Assigned Category
Deleting an assigned Category does not remove the Custom Metadata in that Category. When an assigned Category is deleted, Site Administrators and Workspace Administrators see a banner on the folder naming the deleted Category so they can assign a replacement.
Removing the Allowed Value
When someone removes a value from a key's allowed list, the Metadata Panel flags any Custom Metadata entry that used the removed value. Custom Metadata using that value is not removed from files or folders where it is used.
Swapping the Assigned Category
When someone replaces the assigned Category with a different one, the Metadata Panel flags any existing entries that don't match the new schema.
How Existing Metadata Is Validated
Assigning a Metadata Category to folders and files that contain Custom Metadata does not replace any of the existing keys and values. The Metadata Panel flags any mismatch instead of changing or deleting the entry, so an authorized user resolves each flagged value.
Three outcomes are possible:
- The key matches a Category key and the value is free-form text or one of the allowed values. The entry stays as defined, and nothing is flagged in the web app.
- The key matches but the value isn't in the allowed list. The Metadata editor flags the value as no longer allowed, and the original stays in place until someone updates it.
- The key isn't in the Category schema at all. The Metadata editor flags it as an unrecognized metadata key, and an authorized user has to remove it.