In one sentence
The Definitions library is a single org-wide list of terms and abbreviations — and any controlled document can pull in the subset of terms it actually uses with one click, so every document's definitions section stays in sync with the master library automatically.
- One source of truth, per org. The library is org-scoped. Edit a term once and every document that contains it picks up the change the next time it's saved or re-synced.
- Documents pull, they don't push. Each document carries its own definitions table that's a filtered, materialized view of the library — only the terms that appear in the document body. You can't add a term only to one document; if it's not in the library, it's not in the table.
- The table auto-refreshes on save for documents that already have one. Authors don't have to remember to re-sync; new terms used in the body land in the table on the next save.
What's in a definition
Three fields per row:
- Term — the full phrase. "Lockout / Tagout", "Material Review Board", "Critical to Quality".
- Definition — plain-English explanation.
- Abbreviation — short form, optional. "LOTO", "MRB", "CTQ". When present, the document table renders both forms so a reader scanning the page recognizes either the abbreviation or the spelled-out term.
That's it — no categories, types, or per-standard tagging. The library trades flexibility for keeping the format tight.
The library page
Sidebar → Definitions (or Admin → Documents → Definitions, depending on your sidebar configuration).
The page is a single table with:
- A search box filtering across term, definition, and abbreviation.
- A Plus button to add a new term inline.
- A Trash button per row to delete.
- A Bulk paste button that accepts tab-separated or CSV rows (paste from a spreadsheet) and inserts them all at once.
Edits are saved as you go — there's no separate save step.
Bulk-importing from a spreadsheet
For an org with a hundred terms already living in an existing glossary spreadsheet:
- Open your spreadsheet and select the columns Term, Definition, Abbreviation (in that order).
- Copy.
- Click the paste button on the Definitions page.
- Review the parsed rows in the import preview.
- Click Import — every row lands at once.
The parser tolerates either tabs (the format Excel / Google Sheets copies as) or comma-separated text. Rows without a term or definition are silently dropped.
How it lands in a document
The connection from library to document happens in the editor.
- Open any document in edit mode.
- From the toolbar, click Sync definitions.
- A definitions table is inserted at the current cursor position (typically at the end of the document, before any appendices). The table is auto-generated and clearly labeled.
- Save the document.
What the sync does, exactly:
- Scans the document body for every term in the library (case-insensitive whole-word match — MRB in body matches Material Review Board in the library if the abbreviation column is populated).
- For each match, includes that row in the inserted table.
- Sorts alphabetically by term.
The inserted block is recognizable to the editor — auto-refresh on save and re-sync know to find the existing table and replace it, not append a second one.
If a term is referenced in a document and you delete it from the library, the document's definitions table will lose that row on the next save (auto-refresh re-runs the match). The term still appears in the body, just without a definition. Decide deliberately: rename the term in the library if you want the body references to update language; only delete when you genuinely want the term gone.
Auto-refresh on save
Once a document carries a definitions table (i.e., someone clicked Sync definitions on it at least once), the table re-refreshes silently every time the document is saved. New terms added to the body that match library entries land in the table on the next save. Terms removed from the body fall out of the table.
Documents that have never had a definitions table aren't touched — they don't suddenly grow one because someone added a term elsewhere. This is intentional: the editor doesn't decide for the author whether a definitions table belongs in a given document.
Permissions
- Reading the library — every authenticated user in the org can read definitions. Reading is required because documents that pull from the library need access at render time.
- Editing the library — write access is admin-only by default. Restricting it to a specific custom role is a configuration choice you can make in Admin → Roles & Permissions.
Editing the library is not a per-document edit — changes propagate to every document that uses the term. Treat it as a controlled-vocabulary action.
What it doesn't do
- No multi-language support. Each term has one definition. If your QMS operates in two languages, you'd run two separate orgs or extend the data model.
- No per-document overrides. The library is the only source. You can't say "this SOP defines MRB differently from the org default" — write a different abbreviation for the local usage, or accept that the consistent definition is the point.
- No history on individual definitions. Term-level edits aren't tracked in the audit trail today. If you need this, raise it as a feature request — the row-change capture infrastructure exists, it just isn't wired to this table yet.
Related
- Document editor — where the Sync definitions button lives
- Documents — the overall document register
- Admin: Documents — the rest of the Documents admin surface (categories, templates, reusable components)