Native Confluence approvals are a strong baseline. What about the terms inside approved pages?

[Katerina Bletsch]

Hi Confluence Community!

Native Confluence approvals answer one critical question: was this page reviewed and signed off?

For regulated teams, the next question is often about the content inside that approved page: were the key terms controlled, current, and used consistently across the rest of Confluence?

Atlassian's native approvals for Confluence are a useful step for teams that need more structure around important pages.

For compliance, quality, legal, HR, finance, security, and operational documentation, a page-level approval flow answers several important questions:

• Who was asked to review this page?
• Was the page approved, or only discussed?
• What is the current review status?
• Is there a visible approval history?
• Can the space enforce a standard review path for important pages?
• Does the page need reapproval after a lifecycle or expiry window?

That is a strong baseline, and for many Confluence teams it may be enough.

But in regulated documentation there is a second layer that often sits inside the approved page: the controlled vocabulary that the page relies on.

Page Approval And Term Governance Are Different Jobs

A native approval flow proves that a page went through a review process.

Term governance answers a different set of questions:

• What is the approved definition of this term?
• Who approved the definition, and when?
• Why did the definition change?
• Which pages still use an old, undefined, or unapproved term?
• Can we show term-level evidence when someone reviews the documentation set?
• Who owns terminology when the same term appears across SOPs, policies, risk files, product documentation, training material, and audit evidence?

These are not competing jobs. They are two layers of control over the same knowledge base.

A Simple Two-Layer Model

Layer	Main object	Evidence question	Typical owner
Native page approvals	Confluence page or page version	Was this page reviewed and approved?	Space admin, process owner, legal, QA, manager
Term governance	Definition, acronym, controlled concept, or regulated term	Was this term approved, current, and used consistently?	Compliance, QA, regulatory, GRC, security, product, legal ops

The page-level layer is about signing off the document.

The term-level layer is about making sure the language inside the document is controlled enough to rely on.

The job insight is that compliance teams are not always asking one question. They may be asking several evidence questions about the same Confluence knowledge base:

Job	Page approval layer	Term governance layer
Approve the document	Primary job	Supports it by reducing terminology findings before approval
Govern definitions	Outside the page-approval job	Primary job
Find drift before review	Not the main object	Scan pages for undefined, deprecated, or unapproved terms
Explain what changed	Page history and approval activity	Term version history and definition-level approval history
Export review evidence	Page-level approval evidence	Term-level evidence across the glossary

Where The Gap Shows Up

The gap is not obvious in a single page. It becomes visible when the same concept appears across many pages and teams.

Examples:

• A policy defines "incident" one way, while a response playbook uses "security incident" differently.
• A QMS page uses "nonconformity," "deviation," and "CAPA" without a shared approved definition.
• An AI governance space uses terms like "high-risk AI system," "provider," "deployer," and "substantial modification" across several pages, but no one owns the definitions.
• A DORA, NIS2, SOC 2, ISO, FDA, or MDR documentation set has approved pages, but terms drift between SOPs, controls, risk files, training pages, and evidence pages.

In those cases, approving the page is necessary but not always sufficient. The next question is whether the controlled concepts inside the page are current and consistent.

A Practical Workflow

For teams using Confluence as a compliance or quality knowledge base, the workflow could look like this:

1. Create or update the controlled page in Confluence.
2. Check the page for undefined, deprecated, or unapproved terms.
3. Resolve terminology findings before sending the page for approval.
4. Use native Confluence approvals for page-level sign-off.
5. Keep the term history and page approval history as separate but complementary evidence.

This keeps the document workflow native where native Confluence is strong, while keeping terminology control focused on the definition layer.

What The Second Layer Looks Like

These screenshots are from Compliance Glossary for Confluence. The goal is to show the term-level jobs that sit before and beside page approval.

 

Controlled terms are records with status, version, category, and review actions.

 The scanner surfaces terminology findings across a Confluence space before a page is sent for approval.

Term approval is separate from page approval: a reviewer can approve or reject the definition record.

 

The evidence export collects definitions, status, approval chain, and version history for review.

How The Categories Fit Together

There are several useful app categories around this problem, and I would not treat them as the same job.

Generic glossary apps are strong when the job is to make terms easy to find, explain, translate, highlight, and reuse in daily knowledge work. That is valuable knowledge-management work. A different regulated need appears when the team needs definition ownership, approval history, version history, scan findings, and exportable evidence.

Document workflow and QMS apps are strong when the job is to move a page or document through draft, review, approval, publishing, recertification, and audit trail. That is valuable document-control work. The term-governance layer starts when the question moves from "was this document approved?" to "were the regulated definitions inside this document controlled and current?"

Native Confluence approvals are strong when the job is simple page-level sign-off inside Confluence. That is a useful baseline, especially because it keeps approval close to the page. The term-governance layer starts when a team needs controlled definitions as records, page scans for outdated or unapproved terms, and evidence that travels across many pages rather than one page.

Broader GRC or QMS systems are strong when Confluence is only one part of a larger control environment. The lightweight Confluence-native layer becomes relevant when teams still write and review their policies, SOPs, controls, and evidence pages in Confluence and want terminology control where the writing happens.

When Native Approvals May Be Enough

Native approvals may be enough if:

• the team only needs to prove page sign-off;
• terms are not reused across many regulated documents;
• terminology ownership is already handled in another controlled system;
• definition-level evidence is outside the reviewer, auditor, or internal approver scope;
• the cost of another workflow is higher than the terminology risk.

That is a valid outcome. Not every Confluence space needs term-level governance.

When Term Governance Is Worth Considering

Term governance becomes more relevant when:

• the same regulated terms appear across many spaces or document types;
• terminology drift creates review comments, audit findings, or rework;
• definitions live in spreadsheets, tables, comments, or scattered pages;
• QA, regulatory, GRC, security, legal, or product teams disagree on terms;
• the team needs exportable evidence for who changed and approved definitions;
• page approval proves the document was reviewed, but not that the vocabulary inside it was controlled.

This is the boundary I find most useful:

Native Confluence approvals cover page-level sign-off. Term governance covers controlled language inside those approved pages.

What I Am Exploring

Disclosure: I build Compliance Glossary for Confluence around this second layer: controlled definitions, approval history, page scanning for unapproved or deprecated terms, and exportable term-level evidence inside Confluence.

The native approvals beta makes the distinction clearer rather than less important. Confluence can own the page approval flow. A glossary governance layer can focus on the terms that appear inside those pages.

I would be interested to hear from Confluence admins and regulated teams:

• Do your reviewers ask only whether a page was approved, or also whether definitions are controlled?
• Do terms drift across SOPs, policies, controls, risk files, and evidence pages?
• Who owns approved terminology today?
• If someone asked for evidence, would you export page approval history only, or also term approval history?

I am also exploring the jobs around the approval moment. If you evaluate apps in this area, would any of these be something you expect or look for?

Before page approval:

• starter regulation packs or controlled vocabulary templates for AI Act, DORA, SOC 2, ISO, FDA, MDR, or similar frameworks;
• a way to map terms to requirements, controls, policies, or regulatory articles before the page is reviewed;
• a readiness view showing which terms are approved, in draft, undefined, or used inconsistently;
• one controlled glossary space that other Confluence spaces can reuse.

After page approval:

• an evidence package that combines approved terms, approval history, scan history, and finding resolution;
• proof of where approved terms are used across pages;
• notifications when controlled definitions change and affected teams may need to review content;
• onboarding or training checks so teams understand the controlled vocabulary they are expected to use.

Some of these likely belong in different tools. I want to learn which surrounding jobs are actually expected by Confluence admins and compliance teams, and which ones are better left to native Confluence, Jira, QMS, or GRC workflows.

Different teams will draw the boundary differently. I am exploring where page-level approval is enough, and where term-level evidence becomes a real operational gap.