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, Abbreviation, Definition — in that order.
- Copy.
- Click anywhere on the Definitions page and press ⌘V / Ctrl+V.
- The rows appear immediately and save themselves.
The column order matters: the second column is read as the abbreviation, not the definition. A two-column paste is treated as Term then Definition, with no abbreviation.
The parser reads tab-separated text — the format Excel and Google Sheets put on the clipboard when you copy cells. A comma-separated paste is not split, so every row fails the "at least two columns" check and nothing is imported. If you have a CSV, open it in a spreadsheet first and copy from there. Rows without a term or a definition are dropped silently.
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)