Internal vs External Knowledge Bases in Jira Service Management
Internal vs External Knowledge Base in JSM: Setup Guide & Licensing Explained
You’re setting up a knowledge base in Jira Service Management and suddenly everything becomes… political: who can read what, where it appears, and why licensing keeps popping up in conversations that should be about “how do I reset my VPN?”
Whether you’re running ITSM for IT teams or general service management for HR and facilities, this guide clears up the real difference between external and internal knowledge bases in JSM (with Confluence behind the scenes), explains what licensing actually means in practice, and gives you a configuration pattern that works beautifully when:
- IT agents need deep internal runbooks and SOPs
- Other internal users (employees) should self-serve through the help center
- You want clarity, clean permissions, and zero “oops, we exposed something” moments
⚡ Quick answer:External KB = self-service portal / help center, can work for users without Confluence seats (when configured correctly).
Internal KB = agent/internal hub experience in Confluence, requires Confluence licensing for the people who use it.
📑 What you’ll learn
- External vs internal KB in plain language
- Do you need Confluence licenses for your JSM knowledge base?
- Can you access internal KB without Confluence seats?
- How should you structure internal and external KB in JSM?
- Step-by-step configuration (practical)
- How to structure content so it stays useful
- Common gotchas (and how to avoid them)
- FAQ
- Copy-paste checklist
1. External vs Internal KB in Plain Language
Think of your knowledge base as two different “libraries,” built for two different audiences.
External knowledge base (customer-facing / self-service portal)
This is the knowledge base people consume through the JSM customer portal / help center. It’s designed for self-service — “I just want to solve my problem” reading.
Typical content:
- How-to articles (“Set up email on mobile”, “Request VPN access”)
- FAQ (“Where do I find my payslip?”)
- Light troubleshooting (“Try X, then Y”)
- Known issues (“Outage info”, “Temporary workaround”)
Internal knowledge base (agent-facing / internal team playbook)
This is the “backstage” part: internal-only documentation meant for support staff. It’s where your team keeps the stuff you absolutely do not want general users to browse — not because it’s secret-squirrel, but because it’s operational.
Typical content:
- Runbooks and SOPs (“If alert A triggers, do steps 1–9”)
- Deeper troubleshooting and diagnostics
- Escalation pathways (“When to call vendor / security / infra”)
- Internal policies and internal tools documentation
2. Do You Need Confluence Licenses for Your JSM Knowledge Base?
Here’s the part that usually causes confusion: reading Confluence pages can happen in more than one way — and Atlassian treats those paths differently.
External KB: can be readable without giving everyone Confluence seats
When you set up the JSM Confluence integration for your service project, you can configure article visibility so that users can read through the self-service portal even if they don’t have a Confluence license.
This is why external KB is the go-to for:
- Employee self-service at scale
- Customer support help centers
- Reducing ticket volume without growing Confluence licensing
Internal KB: if you truly want the internal KB experience, you’ll need Confluence licensing
If your plan is “agents should use the internal knowledge base hub in Confluence” (the internal KB experience), then yes — the people using it need Confluence product access.
Quick comparison
| Aspect | External KB | Internal KB |
|---|---|---|
| Primary audience | Employees, customers | IT agents, support staff |
| Access method | JSM self-service portal / help center | Confluence directly |
| Confluence license needed? | No (if configured correctly) | Yes |
| Content type | How-tos, FAQs, light troubleshooting | Runbooks, SOPs, escalation paths |
| Best for | Self-service & ticket deflection | Deep operational knowledge |
3. Can You Access Internal KB Without a Confluence License?
If by “internal KB” you mean the agent/internal hub experience inside Confluence:
Then no — that’s a Confluence feature and requires Confluence licensing for the users who use it.
If what you actually want is: “Let internal people read useful articles while working in JSM, without buying Confluence seats for everyone,”
then yes — the trick is to use the external knowledge base model for broad consumption and keep the truly internal content separated.
That’s the pattern we recommend below, because it scales, it’s safe, and it keeps your permissions story simple.
4. How Should You Structure Internal and External KB in JSM?
If you want the cleanest experience (and the least ongoing drama), treat this as a two-space architecture. For more configuration tips, see our guide on JSM best practices.
Recommended architecture (two spaces)
| Space | Description |
|---|---|
| Space A — Employee Help Center (External KB) | Safe, polished, employee-friendly articles. Linked to the JSM self-service portal. Readable broadly. |
| Space B — IT Runbooks & SOPs (Internal KB) | Restricted to IT. Contains deeper diagnostics and internal-only procedures. Used by agents. |
Why this works so well
- ✅ Employees get self-service without drowning in internal details.
- ✅ IT keeps sensitive or operational knowledge where it belongs.
- ✅ You avoid accidental oversharing when permissions change.
- ✅ You can improve content in one space without breaking the other.
- ✅ A properly configured external KB can deflect up to 45% of support requests (according to Atlassian).
If you also have external customers (three spaces)
Add a third space if you support external customers too:
Space C — Customer Support KB (External) — customer-facing articles for the public help center
This prevents mixing “employee internal” guidance with “public customer” guidance — which always turns messy over time.
5. Step-by-Step: How to Configure Your JSM Confluence Integration
Below is the practical implementation path for setting up your knowledge base. The naming might vary slightly by UI version, but the logic stays the same.
Step 1 — Create your Confluence spaces (separation first)
- Create Space A: “IT Help Center (Employees)” — use the Knowledge Base space template
- Create Space B: “IT Runbooks (Internal)”
Rule of thumb: if a page contains internal system details, diagnostic steps, escalation contacts, vendor instructions, or anything “agents-only”, it goes into Space B.The Knowledge Base space template comes pre-configured with Livesearch and Content By Label macros, making it easy for users to find articles by topic.
For tips on setting up your Confluence spaces effectively, read using Confluence for efficient documentation.
Step 2 — Link Space A to your JSM project (the JSM Confluence integration)
In your JSM service project:
- Open Project settings → Knowledge base
- Select the Confluence space (Space A) to link to the project
- Set viewing permissions to something appropriate for employee self-service (commonly: All logged-in users)
- Enable auto-search so customers see recommended articles as they type their request in the portal
Outcome: employees can find and read articles from the self-service portal, which is what you want for ticket deflection. Users without Confluence licenses can still access these articles through the help center.
Step 3 — Lock down Space B (runbooks)
- Restrict Space B so only IT/support staff can access it
- Use page restrictions where necessary (especially for sensitive runbooks)
- Give Confluence licenses only to the people who truly need to use internal KB capabilities
Step 4 — Make article creation sustainable (the hidden step most teams forget)
Decide now who owns what. Otherwise, your KB becomes a museum of outdated instructions within 90 days.
- Assign topic owners (VPN, devices, access, HR tools, etc.)
- Define a review rhythm (monthly for top articles; quarterly for the rest)
- Track what’s actually used (views, searches, deflection) — see JSM reporting with examples for tracking ideas
6. Content Strategy That Keeps the KB Actually Useful
Here’s a simple pattern that consistently works in IT organizations:
The “two-layer article” approach
For anything that affects both employees and agents, write two articles:
| Layer | Location | Content focus |
|---|---|---|
| Employee article | Space A (self-service portal) | Clean, short, safe, step-by-step. No deep internals. |
| Agent runbook | Space B (internal) | Diagnostics, decision tree, logs to check, escalation steps. |
Example article pairs:
- “VPN not working (Employee guide)” ↔ “VPN not working (IT runbook)”
- “Password reset (Employee guide)” ↔ “Password reset (IT runbook)”
- “Request new laptop (Employee guide)” ↔ “Laptop provisioning (IT runbook)”
Understanding issue types vs request types in JSM can also help you align your KB structure with how tickets are categorized.
Use Confluence’s built-in templates
Confluence provides How-to and Troubleshooting article templates specifically designed for knowledge bases. Using these templates ensures consistency and makes it easier for agents to create new articles quickly.
Write like you’re helping a tired human
Your best articles don’t sound “official.” They sound like a calm coworker who has fixed this 50 times and doesn’t want you to suffer.
✍️ Writing tips:
- Use short steps
- Include what “success” looks like after each step
- Add a “Still stuck?” section that funnels into the right request type
- Use screenshots where they genuinely help
- Avoid jargon in employee-facing content
7. Common Gotchas (and How to Avoid Them)
⚠️ Gotcha #1: “All logged-in users” can be broader than you think
This is usually the correct setting for employee self-service — but treat it with respect. Don’t place internal runbooks into the employee space and hope permissions will save you forever. They won’t.
⚠️ Gotcha #2: Public access (“Anyone”) is rarely what you want
If you enable public visibility, you’re effectively publishing a public help center website. Great for some companies — a problem for many. Choose it only deliberately.
⚠️ Gotcha #3: Mixing audiences makes your KB worse for both
When employee help articles and agent runbooks live together, the self-service experience becomes noisy, and the internal experience becomes risky. Separate spaces keep everyone happier.
⚠️ Gotcha #4: No ownership = slow decay
Knowledge bases rot quietly. The fix is boring but effective: ownership + review rhythm + simple hygiene. Consider defining SLAs for your KB maintenance as well!
8. FAQ
If agents need to use Confluence as Confluence users (internal KB hub, broader internal navigation, editing in Confluence, etc.), then yes — those people need Confluence product access. If they only need portal-facing article consumption, that can be handled via the external KB model.
Yes, commonly. This is exactly why external knowledge bases exist: let people self-serve via the help center without turning everyone into a Confluence user. The key is configuring your JSM Confluence integration and knowledge base visibility correctly.
You can, but it becomes fragile over time. Teams change, permissions drift, people copy pages around, and suddenly internal content leaks into a broad audience. Two spaces is the “sleep well at night” solution.
Use the two-layer approach: employee guide + internal runbook. Link them to each other at the top, and keep the titles parallel. It scales surprisingly well.
When you enable auto-search in the JSM customer portal, users automatically see recommended KB articles as they type their request. If they find their answer before submitting, the ticket is “deflected” — saving time for both the user and your support team.
Technically yes, but this approach doesn’t scale well. Page-level permissions require constant maintenance, are easy to misconfigure, and create confusion about what’s visible to whom. Two separate spaces is simpler and safer.
9. Checklist (Copy-Paste for Your Rollout Doc)
📋 KB Setup Checklist
- ☐ Create Space A: Employee Help Center (External KB) — use the Knowledge Base template
- ☐ Create Space B: IT Runbooks (Internal)
- ☐ Set up the JSM Confluence integration: link Space A to your service project
- ☐ Set Space A visibility for employee self-service (commonly: All logged-in users)
- ☐ Enable auto-search in the customer portal settings
- ☐ Restrict Space B to IT/support staff only
- ☐ Decide edit ownership: who maintains which topics
- ☐ Establish a review rhythm (monthly for top articles; quarterly otherwise)
- ☐ Adopt the “two-layer article” pattern for shared topics
- ☐ Use How-to and Troubleshooting templates for consistency