Every member of your organization can:
There is no permission to grant for this and no way to switch it off. The Knowledge Base is a shared reference — a runbook nobody can find is not doing its job.
Everything below is about writing, not reading.
| Permission | What it lets you do |
|---|---|
| Create knowledge-base articles | Create articles and drafts. |
| Edit knowledge-base articles you authored | Edit articles you created. Requires Create. |
| Edit any member's knowledge-base articles | Edit anyone's articles. An admin override that implies the two above. |
| Publish knowledge-base articles | Publish, unpublish, and archive articles; edit slugs and audience; manage the category tree. Requires Create. |
Holding any of the four gets you into the Manage articles surface and the article editor. Holding none means you read the Library and nothing more.
Publish knowledge-base articles is the curation permission, not just the publish button. It covers:
There are no separate category permissions. If you want someone curating your structure, this is the permission to give them.
DevStride ships a template that bundles the usual authoring set:
Manage knowledge base — Create, edit, publish, and organize knowledge-base articles and categories.
It grants Create, Edit your own, and Publish. This is the right choice for most people who write documentation.
It deliberately excludes Edit any member's knowledge-base articles. Publish already covers the moderation you normally need — you can unpublish or archive anything that should not be live — without also handing over the ability to silently rewrite a colleague's words. Grant that one explicitly, per role, when someone genuinely needs it.
| Control | Requires |
|---|---|
| Knowledge Base nav link, Library, article reader | Nothing |
| Manage articles button | Any of the four |
| New Article | Create |
| Title, body, category, visibility editing | (Author and Edit your own) or Edit any member's |
| Publish / Unpublish / Archive / Unarchive | Publish |
| Audience panel — Visibility and Companies | Publish, plus edit rights on that article |
| Change URL | Publish |
| Category +, ⋯ menu, drag-reordering | Publish |
| Dragging articles to reorder | Publish |
| Filing an article into a category | Edit rights on that article |
| Seeing other members' drafts | Publish, or Edit any member's |
Archived articles are read-only for everyone regardless of permission. Only Unarchive is offered.
A small team where everyone documents. Give the Manage knowledge base template to everyone who writes. Simple, and the category tree stays tidy because everyone can fix it.
A larger team with editorial control. Give most writers Create plus Edit your own. Give a smaller group Publish as well. Writers draft freely; the publishers decide what goes live, own the structure, and control what customers see.
Customer-facing content with a review step. Same as above, and lean on the fact that unarchiving always returns an article to draft — retired content can never go live again without someone deliberately republishing it.
They are not per-category. Permissions apply across the whole Knowledge Base. You cannot let one team edit only the Product A section — see Overview for what version 1 leaves out.
A category's audience is not a permission. Marking a category Internal controls who can read it on the customer portal. It has no effect on who can edit it, and every member still sees it in the Library.
The Customer Help Center
What your customers experience — reaching the Help center, browsing and searching, and the article suggestions shown while they submit a request.
My Work
My Work is your personal, cross-project view of the items that are yours — choose what to show, work items in place, and shape and save the view to fit how you work.