Skip to main content
Access Tags decide who can see a document. Custom Metadata describes what the document is about. They look similar in the UI but solve different problems — do not use Access Tags as a substitute for metadata (or the reverse).

​
Prerequisites

​
Access Tags

​
What they are

Tags control who can see a document — a badge system. A document can require a badge to open it, or block anyone holding a certain badge. Tags exist for visibility and access control. A tag can be named after a department or topic, but that is just a label — its only real effect is who can (or cannot) see the document. It does not organize, categorize, or filter documents the way Custom Metadata does.

​
End-to-end setup

  1. Create the tag catalog in My Account → Tags (for example HR-Only, Sales-Team, Finance-Confidential).
  2. Assign tags to people when editing a team member (same place you change role). Each member can hold one or more tags.
  3. Apply tags on documents from the resource detail page → Access Tags → Edit Access Tags (opens Document Access Control).

​
Modes on a document

Rules of thumb:
  • If a document has no Access Tags, everyone who can access the project can see it — tags only restrict once applied
  • When both modes could apply to the same person, a block always wins over an allow
  • The document modal reminds you: create tags under My Account → Tags if the catalog is empty
Example: Upload a salary review and set Allow Only: HR-Only. A user with the HR-Only tag can open and search it; anyone without that tag will not see it in search results or chat answers.
Note: Access Tags govern what shows up in AI-powered search and chat answers (including EKB Runtime search_knowledge and ask_* as that user). Treat them as an added layer on top of — not a substitute for — correct project-level access.

​
When to use Access Tags

  • Confidential or sensitive documents (HR records, payroll, legal, financial data)
  • Department-specific material that should not be visible company-wide inside the same project
  • Documents meant only for a specific role or clearance
For everyday organizing — sorting by department, topic, or type — use Custom Metadata below.

​
Custom Metadata

​
What it is

Custom Metadata attaches descriptive labels to a document — facts like Department: Engineering, Author: Jane Smith, Version: 2.1. It answers “what is this document about?” rather than “who can see it?” On the resource Details tab, Custom Metadata appears in two sections:

​
Two types at a glance

​
Agent: Custom Metadata Filtering

On an agent’s Knowledge Base toolkit configuration, enable Custom Metadata Filtering (enable_metadata_filtering) to:
  • Add a metadata_filter parameter to knowledge search tools
  • Add a tool that lists available metadata fields/values
This is how agents intentionally limit retrieval to documents with specific searchable metadata (for example SharePoint columns). Matching is exact, not fuzzy — keep values consistent (Engineering, not Eng / eng. dept).

​
Flat fields only

Metadata fields are flat, single-level labels — not nested categories. You can have Department: Engineering, but not a single nested structure Department → Team → Sub-team. If a second level of detail is needed, add a second field (for example Sub-Team alongside Department). Both can still be combined when filtering.

​
Quick comparison

​
Troubleshooting