Categories are the navigation your readers use. They appear as a tree down the left of the Library, the Manage surface, and the customer Help center.
A category does three jobs:
Categories are managed on the Manage articles surface only, and every change requires the Publish knowledge-base articles permission. Members without it see the tree but cannot alter it.
Top-level category: click the + button (titled New category) beside the Categories heading.
Subcategory: open a category's ⋯ menu and choose New subcategory.
In the dialog:
Click Save.
You will meet these as error messages, so they are worth knowing in advance:
| Rule | What you will see |
|---|---|
| Maximum 5 levels of nesting | KB categories cannot be nested more than 5 levels deep |
| Sibling names must be unique, ignoring case | A sibling KB category named "Billing" already exists |
| A category cannot move inside its own subtree | Moving a KB category under itself or one of its descendants would create a cycle |
Sibling uniqueness is case-insensitive — Billing and billing collide. It is also per-parent, so the same name under two different parents is fine, which is what you want for a FAQ under each product area.
The depth limit applies to the whole subtree you are moving, not just the category you grabbed. Dragging a three-deep branch under a category that is already at level 3 is rejected, because the leaves would land at level 6.
Drag the grip on a category row to move it.
A category you re-parent lands at the end of its new sibling set rather than keeping its old position number, which would otherwise collide arbitrarily with the existing order there.
You can also re-parent from the dialog by changing Parent category — useful for precise moves, and the only way to nest one existing sibling under another (a same-parent drag always reorders instead).
Three ways, all equivalent:
Filing requires edit rights on that article.
Uncategorized is not a real category — it is the bucket of articles with no category at all. You cannot rename it, delete it, nest anything under it, or give it an audience.
It appears at the bottom of the tree, and on the Library it only appears when the current list actually contains uncategorized articles.
Because it is not a category, it carries no audience clamp. An uncategorized article's own visibility setting is the only thing deciding whether customers see it. That is worth remembering when you un-file something out of an Internal category.
In the customer Help center, uncategorized articles are grouped under General.
Articles have a curated order that readers see, both in your team's Library and on the customer Help center. Drag article rows in the Manage table to set it.
Reordering is only available when the list you are looking at is unambiguously one ordered bucket. If it is not, a hint tells you exactly what to change:
| Hint | Fix |
|---|---|
| Select a single category to reorder articles. | You are on All articles — pick one category. |
| Clear the state filter to reorder articles. | Set the state chip back to All. |
| Clear the search to reorder articles. | Empty the search box. |
| Only articles filed directly in this category can be reordered. | The list includes articles from subcategories; those belong to their own buckets. |
Dragging downward drops the article after the row you land on; dragging upward drops it before. This is what makes a downward drag actually pass the target rather than swapping with it.
Open the category's ⋯ menu and choose Delete. The confirmation states exactly what will happen:
Delete the category Runbooks? This cannot be undone. Child categories move up one level; its articles become Uncategorized.
That is the whole behaviour, and the important part is what it does not do:
A delete is never blocked. If re-homing creates two siblings with the same name, DevStride allows it rather than refusing to delete or silently renaming something.
This is the one case where the audience is not purely derived. If the category you delete was hiding its contents from customers, that restriction would vanish with it — so where it is needed, DevStride writes Internal down on what survives: the articles that become Uncategorized, and the child categories that move up.
Where the restriction is not at risk — a surviving parent is still Internal and still hides them — nothing is written, so those categories keep their own setting and re-opening that parent later brings them back properly.
Either way, nothing that was hidden becomes visible. Anything written down shows in the UI and can be widened again. Deleting a Portal category writes nothing at all.
Say you are building help content for two products.
Getting started Portal
Product A Portal
├─ Setup Portal
├─ Troubleshooting Portal
└─ Internal runbooks Internal ← hides everything below it
Product B Portal
├─ Setup Portal
└─ Troubleshooting Portal
Company policies Internal ← whole section is team-only
What this gives you:
| Action | Where | Permission |
|---|---|---|
| Create top-level category | + beside Categories | Publish knowledge-base articles |
| Create subcategory | Category ⋯ → New subcategory | Publish knowledge-base articles |
| Rename / re-parent / set audience | Category ⋯ → Edit | Publish knowledge-base articles |
| Reorder or move | Drag the grip | Publish knowledge-base articles |
| Delete | Category ⋯ → Delete | Publish knowledge-base articles |
| File an article | Editor rail → Organization → Category, or drag the row | Edit rights on the article |
| Reorder articles | Drag rows in the table | Publish knowledge-base articles |
Write and Publish Your First Article
A step-by-step walkthrough: create a draft, write it, file it, choose an audience, publish it, and confirm your readers can see it.
Who Can See an Article
The three gates that decide whether a customer can read an article: its own visibility, the audience of every category above it, and the companies it is shared with.