JSM Knowledge Base Setup & Knowledge-Centered Service Loop

Most JSM knowledge base setups fail because teams don't understand three things:

1. They think they need to buy a Confluence license for every customer who reads an article (they don't, if configured correctly).

2. They write articles the way humans scan them (in prose walls), which breaks Atlassian's AI engines trying to parse the content for Rovo-powered deflection.

3. They build the knowledge base as a static library instead of a living system where agents turn solved tickets into articles in one click.

   
   

The setup itself takes 30 minutes. Getting it right — so it survives your licensing audit, works with your AI layer, and scales as your team grows — requires understanding the licensing paradox, the AI layer, and the Knowledge-Centered Service loop.

This guide covers all three.

The Confluence Licensing: How to Give Portal Access Without Buying Seats

The Problem Every IT Director Hits

You set up a knowledge base. You link a Confluence space. You publish 10 articles. Then your admin counts how many customer portal users just accessed the KB and panics: "Do we need 500 Confluence licenses now?"

The answer is no, but only if you understand the distinction between how Confluence content is accessed versus how Confluence is licensed.

Confluence licensing charges for "product access", the ability to log into Confluence and write/edit pages. Reading an article through JSM's customer portal doesn't trigger a license, as long as that Confluence space is configured correctly. Reading an article inside Confluence itself (not via JSM) does trigger a seat cost.

This distinction is where most setups go sideways.

The Permission Blueprint: Who Can Read What, Without Licensing Bloat

Use this table as your configuration reference. Different user roles, different permission requirements, zero hidden licensing bombs:

User Role	JSM Project Access	Confluence Space Permission	Atlassian License Cost	Notes
Service Desk Agent	Service Desk Team	Can View, Edit, Publish	Paid: JSM Agent + Confluence License	Agents need licenses to write/edit articles. These are your $8–10/month team seats.
Internal Employee (Contractor/Staff)	Service Desk Customer	Can View Only (via Portal)	Free ($0)	They read KB through JSM portal. No Confluence login needed. No seat cost. Configured via portal-specific permissions.
External Client (B2B Customer)	Service Desk Customer	Anonymous Portal Access	Free ($0)	They never see Confluence. They read KB through JSM public/client portal. Requires "Allow anonymous access" toggled on. No account, no seat.
Partner/Reseller (Portal)	Service Desk Customer (Organization-scoped)	View Only (Portal)	Free ($0)	Same as external, but scoped to their organization. Still no Confluence access, no seat cost.

The key insight: Confluence product access is separate from content visibility. You can have 5,000 portal users reading Confluence articles without a single additional license, as long as they're reading through JSM's portal interface and the Confluence space is set to either "All portal users" or "Anonymous" under visibility.

Step-by-Step: Configuring Portal-Only Access (No License Required)

In your JSM project settings:

1. Go to Knowledge base → Select the linked Confluence space

2. Under Visibility, choose:

   • "All logged-in portal users" — internal employees and contractors see articles in the portal without needing Confluence seats

   • "Anonymous (public web)" — external customers on your public portal see articles without any account at all

3. Under Confluence Space Settings (in Confluence itself):

   • Ensure the space is set to Restricted in Confluence's native permissions

   • Restrict who can edit (agents only) via the Confluence space admin settings

   • Do NOT set the space to "Public" or "Open" (that would require licensing for different access models)

   • 
     

Why this works: JSM's portal renders the Confluence articles inside JSM's interface. The reader never logs into Confluence. They access zero Confluence "product features," so Atlassian doesn't charge a license seat. The content is served, the reader never touches Confluence, the license bill stays flat.

Audit your current setup:

If your team is paying for more Confluence licenses than you have people editing articles, you probably have permissions misconfigured. Pull your Atlassian billing report and your Confluence product access list — they should match (agents) plus a small buffer (admins). If they don't, you're overpaying.

Is your Knowledge Base Set up So Atlassian Rovo Can Actually Parse Them

Why Your Article Library Fails the AI Test

In 2026, Atlassian Intelligence and Rovo use Retrieval-Augmented Generation (RAG) to read your Confluence space. When a customer types a question in the portal or via Slack, Rovo searches the KB, finds relevant articles, and — critically — extracts the exact answer from the article text.

If your articles are prose walls, Rovo can't find the answer efficiently. It either hallucinates a guess or surfaces a vague article title without the specific workaround, forcing the customer to click through and read manually. That kills deflection before the AI even tries.

The solution is a structured article that an RAG engine can parse.

Writing for the AI Layer: The Formatting Rules

Rule 1: One Answer Per H2, Maximum 400 Words Per Section

Structure articles so that each major problem gets exactly one H2 header with one complete answer beneath it. If you have three different "How do I reset X?" problems, give each its own H2 and self-contained answer block.

Bad (AI struggles here):

How to reset passwords and manage access

Employees often need help with password resets. You can do this in several ways depending on the system. 
First, you might try the password reset portal, or you could submit a ticket, or sometimes you can use 
the command line... [continues for 8 paragraphs]

Good (AI parses this cleanly):

How to reset your password through the self-service portal

1. Go to [portal URL]
2. Click "Forgot Password"
3. Enter your email
4. Check email for reset link (3-minute expiry)
5. Create new password (12+ chars, mixed case required)

**If you don't receive the email:** Check spam folder. If still missing, [submit support request].

Rovo reads the second version and immediately knows: Portal reset in 5 steps, email requirement, what to do if it fails. The first version leaves Rovo guessing.

Rule 2: Use Semantic Hierarchy (H1 → H2 → H3, Not Just Bold Text)

RAG engines read heading structure, not visual formatting. If you have a "Prerequisites" section, make it an H3 under a clear H2 parent. Don't bold the word "Prerequisites" and hope the AI figures it out.

Rule 3: Label Every Article With Semantic Tags

Confluence labels are the signal Rovo uses to restrict auto-search recommendations to the right request type. Use consistent label naming:

• request-type:password-reset

• request-type:access-provisioning

• severity:p1-critical

• product:business-central

• audience:internal or audience:external

  
  

When a customer submits a request with type "Password Reset," Rovo only searches articles tagged request-type:password-reset. Without labels, it searches everything and brings fluff.

Rule 4: Lead With the Action, Not the Explanation

Your first sentence should be the fix, not the problem description.

Not this: "Many users have trouble with authentication systems because of token expiry. This can happen when your session times out..."

This: "To log back in after a timeout, use [URL] and select 'Resend verification code.'"

Rovo pulls the first 1-2 sentences. Make them the answer.

Rule 5: Use Bullet Lists for Steps, Not Prose Paragraphs

Numbered lists with short, scannable steps are 10x better for RAG parsing than procedural paragraphs. Rovo can extract "Step 3: Click 'Approve'" from a list instantly. It struggles to extract the same instruction buried in paragraph prose.

Audit Your Existing KB for AI-Readiness

Pull your top 10 highest-traffic articles on your knowledge base setup. For each, ask:

• Does it have clear H2 headers for each distinct problem?

• Is the first sentence the action/fix, not background?

• Are steps numbered lists, not prose?

• Is it tagged with request-type:* labels?

• Does it stay under 400 words per section?

  
  

If 3+ articles fail these checks, your AI deflection is probably under-performing. Rovo can work with what you have, but it won't excel until content is restructured.

Using Resolved Ticket to Create Live Article in One Click

The Problem: Articles Written in a Vacuum

Most knowledge bases grow like this:

1. Manager decides "we need a KB"

2. Team writes 10 articles from guesses

3. Customers search for answers not in the articles

4. Tickets pile up

5. Nobody updates the KB because the agent who solved ticket #4,827 never documented it

   
   

The Knowledge-Centered Service (KCS) model flips this: the agent solving a complex ticket is the expert who should write the KB article, not someone months later trying to reverse-engineer what happened.

In JSM, this loop can be almost automatic.

Setting Up the Agent-Driven Article Creation Workflow

Step 1: Enable the "Create Article" Button in Agent View

In your JSM project settings:

• Go to Knowledge base → Create article from issue

• Toggle this ON

• Set the article workflow to include an approval state (Draft → Under Review → Published)

  
  

Now when an agent resolves a ticket, they see a "Create article" button directly in the issue view. One click, and a draft article based on the ticket description + resolution appears in your Confluence space.

Step 2: Create a Template for Draft Articles

Don't let agents start blank. Create a Confluence template that pre-fills the structure:

Title: [Autofilled from ticket summary]

## Problem
[Autofilled from issue description]

## Solution
[Space for agent to fill in]

## Related Issues
[Autofilled links to similar tickets]

---
*Drafted from ticket [TICKET-ID] on [date]. Awaiting approval.*

When an agent creates an article from a ticket, they get this template and only have to fill in the "Solution" section. That's low friction.

Step 3: Assign Approval to a "KB Owner" Role

Don't let every draft auto-publish. Create a service project role (e.g., "KB Content Owner") and route all drafted articles through that person for 24-hour review before publishing.

This prevents:

• Articles with confidential customer data

• Typos or incomplete solutions going live

• Duplicate articles (the KB owner can spot that during review)

  
  

The approval step takes 2 minutes per article but saves dozens of bad articles from reaching customers.

Step 4: Measure KB Creation Volume Alongside Deflection

Add this to your monthly reports:

• Articles created from tickets: Should trend up as agents engage

• Articles approved vs. rejected: If rejection rate >10%, your template or process is broken

• Time from ticket resolution to article publication: Target <3 days (draft creation + review)

  
  

Once you have 5+ agents contributing articles monthly, your KB scales without the manager writing everything.

A Real KCS Loop in Action

1. Tuesday 10 AM: Customer submits ticket "Business Central currency conversion failing for USD→EUR"

2. Tuesday 2 PM: Agent debugs, finds root cause (decimal place configuration in chart of accounts)

3. Tuesday 2:15 PM: Agent clicks "Create article" → template pre-fills → Agent types 200-word solution

4. Tuesday 4 PM: KB owner reviews draft, adds label request-type:business-central + severity:p2, approves

5. Wednesday 9 AM: Article goes live tagged and auto-search-enabled

6. Thursday: Next customer with the same issue searches the portal, finds the article, self-serves. Ticket deflected.

   
   

That's the loop. The knowledge base grows because agents who solved the problem documented it, not because a manager guessed what customers need.

Putting It Together

This is a licensing defense, an AI optimization, and a living knowledge system:

1. Layer 1 (Licensing): Portal-only access with correct permissions = zero hidden Confluence license costs. Your bill stays flat even as customer portal traffic grows.

2. Layer 2 (AI): Structured articles with semantic headers, labels, and short paragraphs = Atlassian Rovo can parse them accurately. Deflection jumps from 20% to 40%+ when AI can extract specific answers.

3. Layer 3 (Growth): KCS loop where agents turn resolved tickets into articles = your KB grows from your actual ticket patterns, not from assumptions. It scales without hiring a dedicated content person.

Teams that execute all three simultaneously see:

• Ticket deflection increase 30–50% in the first 6 months

• Confluence licensing costs decrease or stay flat despite 3x portal traffic growth

• First-time deflection rates on new article topics (agent knows the exact answer because they just solved it)

  
  

Teams that skip one usually stall. Skip licensing clarity and you overpay. Skip AI formatting and deflection caps at 15–20%. Skip KCS and your KB becomes stale.

How to configure JSM knowledge base access without Confluence license costs:

User Type	Can Access KB Via	Confluence License Needed	Configuration
Service Desk Agent	Confluence editor + JSM agent view	Yes ($8–10/mo)	Grant Confluence space "Edit" permission
Internal Staff / Contractor	JSM Portal (web or mobile app)	No	Set Confluence space to "All logged-in portal users" visibility
External Customer / B2B Client	JSM Public Portal	No	Set Confluence space to "Anonymous (public)" visibility
Partner / Reseller	Org-scoped JSM Portal	No	Create organization in JSM, assign portal scope, leave Confluence permissions restricted

Bottom line: Confluence licenses cover editing. Reading through JSM's portal interface doesn't trigger a license, regardless of how many portal users you have.

FAQ: Licensing, AI, and KCS Questions

Q: We use Atlassian Intelligence (Rovo). Do we need to do anything special to our knowledge base?

A: Rovo works out of the box once your Confluence space is linked, but it performs much better if your articles follow the AI formatting rules above (semantic headers, labels, short paragraphs, action-first). Run an audit of your top 20 articles against those rules; if <50% comply, spend a week reformatting. You'll see deflection jump.

Q: Can we auto-generate articles from tickets using AI?

A: Atlassian Intelligence can draft articles from ticket text, but don't let them auto-publish. They often capture extraneous details or miss the core solution. Use the KCS approval state so a human can review before live publication.

Q: Our Confluence space is marked "Public." Are we overpaying for licenses?

A: Possibly. Pull your Confluence product access list. If it includes everyone in your portal user base, yes — you're paying a license per portal user. Change the space to "Restricted" and rely on JSM's portal permissions instead. You'll drop license count immediately.

Q: How do we know if articles are AI-friendly?

A: Rovo includes a "Search suggestions" report showing which searches returned no results or low-confidence matches. Those are your gaps. Pull that report quarterly; articles that don't appear in successful searches probably need reformatting (better headers, clearer labels, shorter sections).

Q: Should we write separate articles for humans vs. AI?

A: No. One well-structured article works for both. The AI-friendly formatting (semantic headers, labels, action-first) is also more scannable for humans. You're not optimizing for robots at the expense of people.

Where This Fits in Your ITSM Strategy

A knowledge base is the first deflection layer in a mature ITSM practice. Once KB deflection is working (20–40% of requests), that frees your team to focus on the recurring incidents your KB can't catch because nobody's fixed the root cause. That's where incident management and problem management enter the picture, every problem record should generate a KB article that prevents the next round of tickets.

For teams building JSM from scratch, this also connects to your ITSM implementation roadmap — knowledge base maturity is often the first measurable quick win before you tackle deeper process work.

Further Reading

• Atlassian Support: The difference between internal and external knowledge bases — Official guidance on how visibility permissions avoid license creep

• Atlassian Support: Set up your knowledge base with Confluence — Step-by-step technical setup

• Knowledge Base management in JSM best practices — Operational best practices

• Full suite of ITSM metrics including KB utilization

Setting up a JSM knowledge base properly means more than clicking "create space." It means understanding your licensing model, formatting for AI, and building a system where agents keep it alive. Get in touch if you want to audit your current setup against these three layers, licensing spend, AI readiness, and KCS automation.