Features / Stage 1 · Create

Custom metadata

Every document carries the attributes your organization cares about — searchable, filterable, governable.

A document without metadata is a file. A document with structured metadata is a record. The difference shows up everywhere: search, filtering, cross-references, expiration tracking, compliance reporting, access control. docs365.ai lets you define exactly the metadata fields each document type should carry — and whether each field is read-only (populated from the template, untouchable) or editable by the author (typed in during drafting).

Stage 1 · Create Business: Standard schema Enterprise: Fully custom Premium: Fully custom Diamond: Fully custom

Illustration placeholder

At a glance

What you get

Four metadata behaviors separate this product from a shared folder with custom columns: field-per-type configuration, read-only enforcement, auto-population, and deep integration with every downstream feature.

Fields per document type

SOPs, policies, work instructions, contracts — each type has its own schema of metadata fields.

Read-only vs editable

Fields can be locked (template-driven) or editable by the author — per field, per document type.

Filterable and searchable

Every metadata field is a searchable column — find every SOP owned by a specific team in seconds.

Feeds every downstream feature

Expiration reminders, Power BI dashboards, access rules — they all read from metadata.

How it works

From schema design to operational metadata

Metadata schemas are designed during implementation based on the customer's governance model. Each document type gets its own schema; fields are populated either automatically (from the template, the protocol sequence, or the current user) or by the author during drafting.

1

Design schema per document type

During implementation, each document type gets its metadata schema — which fields, which are required, which are read-only.

2

Fields populate at creation

Template-driven fields fill themselves; author-driven fields prompt for input during drafting.

3

Values flow through the lifecycle

Metadata is visible in SharePoint columns, drives search, feeds dashboards, controls expiration reminders.

4

Updates go through versioning

Editing a metadata field creates a new version; the audit log captures who changed what, when.

Before / after

What changes when this is on

Metadata-free libraries degrade in predictable ways. Without field constraints, you get inconsistent data; without read-only enforcement, you get accidental edits; without a schema per type, you get one-size-fits-none. The before/after pairs below cover the most common cases.

Without it
With intranet.ai
A library of thousands of documents with no way to filter by owner, department, or expiration
Every document carries the fields you need; filtering is instant, at scale
Authors edit metadata fields that should be locked (version number, protocol code)
Read-only fields are system-enforced; editable fields are the only ones authors can touch
One generic schema across every document type — too loose for SOPs, too tight for policies
Each document type has its own tailored schema — SOPs get SOP fields, policies get policy fields
Metadata doesn't connect to anything; it's decorative, not functional
Metadata feeds expiration reminders, Power BI dashboards, and access rules — it runs the governance

Availability

Plan availability

Custom metadata is a core capability on every DMS plan. Business includes a standard schema; Enterprise and above unlock fully customized fields and per-type configuration. Expiration-date behavior (a Govern-stage feature) integrates directly with the metadata layer on Enterprise+.

business
enterprise
premium
diamond
Standard schema
Fully custom
Fully custom
Fully custom

Business comes with a proven standard metadata schema. Enterprise and above unlock per-type customization — define your own fields, your own required-vs-optional rules, your own read-only enforcement.

Deep dive

Read the full narrative

For the buyer who wants the full detail — compliance context, edge cases, adjacent workflows.

+

System-owned fields stay trustworthy. Author-owned fields keep documents findable.

Metadata is not just governance plumbing. It powers filtering, grouping, custom views, Power BI reporting, expiration reminders, and the approval flow. A library with well-designed metadata is a library that answers questions in seconds. A library with sloppy or missing metadata is an archaeology project every time the compliance officer asks for something.

Fully customizable per document type

Each document type can define its own metadata fields. An SOP might need: effective date, applicable facility, document owner, review cadence, related processes. A contract might need: counterparty, contract value, governing jurisdiction, expiration date. A procedure might need: departments affected, training requirement, safety class. Each field has a data type (text, date, number, choice list) and behavior.

Read-only vs. editable — the key distinction

Every field is either read-only (system-owned) or editable (author-owned).

System-owned fields (read-only)

Written by the system, not changeable by authors:

  • Version number — minor versions during drafting, major versions at publication.
  • Protocol code — the unique document identifier.
  • Creation date — when the document was first instantiated.
  • Last approval date — timestamp of the most recent approval.
  • Published date — when the current major version went public.

These fields are the backbone of audit evidence. Authors don’t change them; the system does.

Author-owned fields (editable)

Populated by the author during drafting, changeable as the document evolves:

  • Document owner — who is responsible for keeping this document current.
  • Effective date — when the document takes effect.
  • Applicable departments — which parts of the organization this applies to.
  • Review cadence — how often this document should be reviewed.
  • Tags or categories — free-form or choice-list classification.

Authors fill these because they know the content. The system stores them and uses them for filtering, views, and the expiration-reminder workflow.

Metadata powers filtering and views

End users filter the public library by any metadata field: show only SOPs applicable to a specific facility, only documents effective in a specific quarter, only documents owned by a specific person. Custom views persist these filters for recurring use — the quality manager’s “my SOPs” view, the legal team’s “active contracts” view, the compliance officer’s “expiring this quarter” view.

Metadata powers Power BI reporting

On Enterprise plans and above, a Power BI dashboard reads the same metadata and surfaces it as charts and filters. Most-common dashboard views: expiration risk in the next 30/60/90 days, approval cycle times by document type, document volumes by department, activity trends over time. Because the dashboard reads the same metadata the library uses, no data duplication and no reconciliation.

Configured once at setup, adjustable as you go

During implementation, the customer decides which metadata fields matter for each document type and which are system-owned vs. author-owned. The Excel-driven configuration import generates the full information architecture — sites, libraries, document types, metadata fields — in one pass. Fields can be added or adjusted after go-live without disrupting the existing library.

Lifecycle stage: Create →

See this feature running on your documents

Thirty minutes. No cost. No obligation. We'll walk through how custom metadata fits into your current document-governance practice.