Knowledge Base Overview

What the Knowledge Base is for

The Knowledge Base is where your organization writes things down: runbooks, how-tos, policies, troubleshooting guides, onboarding notes, answers to the questions your customers keep asking.

You write an article once. Then you decide who reads it:

• Your team, inside DevStride.
• Your customers, through the Service Desk portal's Help center.
• Both — the same article can serve internal readers and customers at the same time.

That last point is the whole idea. A troubleshooting guide your support team relies on is usually the same guide a customer needs at 2am. Instead of maintaining two copies that drift apart, you maintain one and point it at both audiences.

The three places articles live

It helps to know these by name, because they behave differently and the documentation refers to them constantly.

1. The Library — where your team reads

Knowledge Base in the left navigation.

The Library is the reading room. It lists every published article, browsable by category and searchable by keyword. Every member of your organization can open it — no special permission required.

The Library shows internal articles and customer-facing ones, so your team gets the complete picture. Internal-only articles carry an Internal badge so a reader can tell at a glance whether a customer could also be looking at it.

The Library never shows drafts — not even to the person who wrote them. Drafts are previewed while you are editing them, not published to a reading surface.

2. Manage articles — where your team writes

Manage articles, reached from the button at the top right of the Library.

This is the authoring surface: a table of every article in every state, the editable category tree, and the controls for filing, ordering, and publishing. It requires at least one Knowledge Base permission, so members who only read never see it.

3. The Help center — where your customers read

/portal/<your-portal-slug>/kb, reached from the Help center link on a customer's My requests page.

Customers see a deliberately narrower slice: only articles that are published, marked for the portal, not hidden by a category, and shared with their company. Everything else is invisible to them — not greyed out or locked, but genuinely absent.

::alert{type="note" title="Customers see "Help center", not "Knowledge Base""} The customer-facing surface is branded Help center throughout the portal. The two names refer to the same articles; only the wording and the visible subset differ. ::

How an article reaches a reader

Every article carries three independent settings. A reader sees the article only when all three allow it. This is the single most important thing to understand about the Knowledge Base, and it has its own page.

Your team's Library ignores visibility, category audience, and companies entirely — members see everything published. Those three settings exist to control the customer side.

A tour in one paragraph

You click New Article and get a draft called Untitled article. You type a title and body; it saves as you go. You file it into a category, choose whether it is for customers or internal only, and click Publish — which mints a permanent URL slug. From then on it appears in your team's Library immediately, and on your customers' Help center if you pointed it at them. Later you can unpublish it back to a draft, or archive it when it is no longer relevant. Nothing is ever deleted.

Where to go next

• Write and publish your first article — the step-by-step walkthrough. Start here if you have never used the module.
• Organizing with categories — building the tree your readers navigate.
• Who can see an article — visibility, the category audience clamp, and company sharing. Read this before you publish anything sensitive.
• The article lifecycle and URLs — draft, published, archived, and how slugs work.
• Searching and browsing — how readers find things, and how ranking works.
• The customer Help center — what your customers actually experience.
• Knowledge Base permissions — who can write, publish, and curate.

What version 1 does not do yet

Worth knowing up front so you can plan around it:

• No version history. Articles do not keep revisions, and there is no way to see what changed or roll back. Treat a published article as the single current copy.
• No per-category permissions. Knowledge Base permissions apply across the whole module. A category's audience controls who can read it on the portal, but it does not control who can edit it.
• No article templates. Every article starts from a blank editor.
• No delete. Archiving is how you retire an article. This is deliberate — a published URL that suddenly 404s is worse than one that quietly stops being listed.
• No bulk actions. Filing, publishing, and audience changes are one article at a time.