Setting management permissions for articles

You apply these at article level, not section level, and separating editing from publishing is an Enterprise option rather than a setting everyone has.

Management permissions decide who may edit and publish, separately from who may read. Two things to know before you plan around them: you apply them at article level rather than section level, and separating editing from publishing is an Enterprise option rather than a setting everyone has.

Apply one to an article

1. Open the article and click Edit article, or open it from Manage articles in Knowledge admin.
2. Click the Article settings icon to expand the panel.
3. Click the Management card.
4. Choose the permission.

A Knowledge admin can apply any management permission. An agent can apply only the permissions they themselves belong to, which stops somebody handing away access they do not have.

The built-in choices

You can also build a custom permission from a user segment, which is how you get a subject-based group rather than an everyone-or-nobody choice. That one needs Suite Growth or higher, because user segments do; the built-in choices above work on any Suite plan.

Article level, not section level

Permissions are applied per article. You cannot set them on a section or a category and have articles inherit them, which is the assumption most people arrive with.

The practical consequence: moving an article into a section changes nothing about who may edit it, and a new article in a well-governed section does not pick up that governance. Set it on the article, every time.

Separating editing from publishing is Enterprise

Where accuracy matters, letting more people write and fewer people publish is the arrangement you want, and Editors and Publishers is how you get it. On Professional that separation is not available, so plan for a review step you run rather than one the product enforces.

Two different questions

Visibility is who may read an article. Management permission is who may change it. An article can be visible to everybody and editable by three people, which is the normal arrangement.

Mixing them up produces the two classic mistakes: an internal article everybody can read, and a public article anybody can rewrite.

Group by subject, not by department

The people who should edit the billing articles are the people who know billing, which is rarely the same as a box on an org chart. Permissions built on subjects survive reorganisations.

Check what a contributor sees

Ask somebody in the group to open an article and try. Reading a permission screen tells you what you configured; watching somebody work tells you what you achieved.

See also

• Who sees what: user segments explained
• Submitting an article for review
• What Team Publishing is