Internal knowledge base vs Notion vs Confluence — the HR view

If you ask 10 HR managers where their onboarding docs live, you'll get back: 4× Notion, 3× Confluence, 1× SharePoint, 1× "a Google Drive folder", 1× "honestly I'm not sure anymore". The "I'm not sure" is the most-common end state of every knowledge initiative left to drift.

This piece is specifically about HR-owned knowledge — onboarding playbooks, policy documents, role descriptions, benefits explainers, how-to guides for HR-managed systems. Not engineering docs, not product wikis, not legal contracts. Three places that knowledge tends to live, with honest tradeoffs.

Option A: a dedicated KB inside the employee portal

What it looks like: the portal has a "Knowledge" tab. Articles authored in a built-in editor (markdown or rich text), organized by category, searchable from the portal's global search, linkable from other portal pages (employee profiles, absence types, etc.).

Pros:

• Lives where employees already are. The 11am question "where's the vacation policy" doesn't require remembering "is that in Notion or Confluence". It's in the same app they used to request the vacation.
• Permissions inherit from the employee model. New hires automatically see onboarding articles. Manager-level docs are hidden from ICs. No separate user-management.
• Search results include both KB articles AND people, departments, office floors — a single search box that finds "expense policy" and "the person who owns expenses".

Cons:

• The editor is usually less rich than Notion or Confluence. Don't try to author engineering RFCs here.
• No graph-style backlinking (Notion-style) or hierarchical tree depth (Confluence-style space depth).
• Risk of duplication if engineering already keeps onboarding-style docs in their own wiki.

Fits when: you want HR-specific knowledge integrated into the portal experience, and you're OK keeping engineering's deeper documentation needs in a separate tool.

Option B: Notion

What it looks like: a Notion workspace where HR has a top-level page "Company Handbook" with subpages.

Pros:

• Best authoring experience in this category by a margin. Inline databases, embeds, easy formatting, comments, mention-by-typing-@.
• Cross-team friendly: engineering and HR can author in the same workspace, with proper permissions per page tree.
• Templates and templates-of-templates are excellent for repeat structures (role guides, onboarding sequences).

Cons:

• Permissions are page-by-page. Every new sensitive doc is a "who has access to this" question you need to answer manually. Mistakes leak compensation policy.
• Onboarding new hires requires giving them Notion access (paid seat), then walking them to the Handbook. Half of them forget the URL within a week.
• Search across an enterprise Notion workspace becomes unusably noisy at ~500 pages. HR docs get buried under engineering pages.
• Discovery suffers: HR articles don't show up next to "vacation policy" in any context except by remembering to navigate to Notion.

Fits when: your company already heavily uses Notion for everything, you have an admin who actively curates the Handbook structure, and you accept that adoption is "they need to remember to look in Notion".

Option C: Confluence

What it looks like: a Confluence Space called "People" or "HR" with a tree of pages.

Pros:

• Best-in-class for hierarchical, version-controlled, formally-reviewed docs. Approval workflows, page-history audit, mature permissions.
• If your company already uses Jira + Confluence, no new tool to introduce.
• Better than Notion for documents that need formal review/approval before publication (policies, legal-adjacent docs, compliance materials).

Cons:

• Authoring is more cumbersome than Notion. Page templates help; everything else is friction.
• Mobile is functional but not loved.
• The "spaces" model is conceptually heavy for small companies. Often overkill.
• Cost-per-user models add up at 100+ headcount.

Fits when: you already have Confluence for engineering, you have a small group of HR admins authoring most content, and you need formal review workflows (regulated industries, large companies with compliance needs).

How to pick

A simple decision tree:

• <50 employees, no existing wiki habits: portal-integrated KB. Lowest friction to adoption. Easy to migrate later if you outgrow it.
• 50–200 employees, already on Notion: keep Notion as the source of truth, but link HR-relevant pages from the portal. Don't dual-author.
• 50–500 employees, already on Confluence: keep Confluence, same caveat. Resist the urge to migrate to Notion just because Notion is shinier.
• Heavily regulated industries (finance, healthcare) at any size: Confluence wins on audit trail and approval workflows. The portal can link in but shouldn't own.
• Pure remote 200+: portal KB AND a deeper wiki (Notion or Confluence), with the portal KB being the "where do I start" answer and the wiki being where the depth lives.

The duplication trap

The thing every HR ops person eventually does wrong is author the same content in two places. You write the onboarding policy in Notion, then think "but employees won't find it there, let me also put it in the portal." Now you have two copies and they drift.

The fix is to pick one source of truth and make the other a link. If Notion is the canonical Handbook, the portal KB has a stub article "Onboarding policy → see Notion" with a link, not a copy. If the portal is canonical, the Notion space links to the portal.

This sounds obvious. Almost nobody does it. Half the time we audit an HR ops setup we find the same policy in 3 places, with the most-recent edits scattered across them.

What "the portal KB is good enough" means

If you go the portal-KB route, the bar for "good enough" is:

• Markdown or rich-text editor with images, tables, internal links.
• Articles organized into a category tree (depth 1–2 is plenty).
• Search across articles, with results ranked by recency + a small boost for HR-tagged content.
• Drafts that admins can iterate before publishing.
• A "last updated" timestamp visible to readers (so they can spot stale docs).
• Mobile-friendly reading.

The features we don't think a portal KB needs: graph-style backlinking, real-time collaborative editing, version branching, AI-generated summaries. They sound nice; they don't change adoption.

DTPulse's take

We ship a built-in KB with the above features (markdown editor, hierarchical articles, internal linking, search integrated with the portal's global search, drafts, mobile-friendly reading). Designed for the HR-specific content described above. We don't pretend to compete with Notion or Confluence as a general-purpose wiki — that's the wrong fight.

For customers already invested in Notion/Confluence, we recommend keeping engineering content there and using our KB for HR-specific content the portal naturally cross-links into. No migrations, no consolidation pressure.

Related reading

• What is an employee portal — and when does a company really need one
• Office floor plans in your HR system — not just real-estate trivia