Once a spec is agreed and published, people rely on it. A quiet edit can change what a client signed off without anyone noticing. Turn on approval for a category and nobody's edit reaches a published article in it until a publisher has looked at it.
With approval on, editing a published article saves a proposed change instead. The live version stays exactly as it was, for your team and your customers, until a publisher approves the change. Then it goes live in one step and is recorded in the article's history.
On Manage articles, open the category's ⋯ menu and choose Edit. Switch on Changes to published articles need approval and click Save. Like every category setting, this needs Publish knowledge-base articles.
The setting covers:
Nobody is told about a proposed change unless they watch the article or the category, so watch the category if you approve its changes. See Watching articles and categories.
Open the published article and edit it as usual. A note above the body tells you what is happening:
Changes to this published article need approval. Your edits are saved as a proposed change; the live version is unchanged.
Your edits autosave into your proposed change, not the live article. You can close the editor and come back later: it reopens on your proposed change. If you change everything back to how the live version reads, there is nothing left to approve and the proposed change goes away.
When it is ready, click Submit for approval. Only the person who proposed the change can submit it.
Two more buttons sit beside it:
Restoring an earlier version from History under approval works the same way: the restored title and body become a proposed change rather than going live. See Article history and restore.
An article has at most one open proposed change. While it is open, nobody else can edit the article:
A published article under approval cannot be moved to another category, or have its visibility changed: Changes to this published article need approval, so it cannot be moved or have its audience changed. Unpublish it first.
When a change is waiting, holders of Publish knowledge-base articles see Review proposed change on the article. It opens a full-screen comparison, Published now beside Proposed, with who proposed it.
A publisher can approve their own proposed change. Comments pinned to the live article's words while the change was waiting keep their pins when it is approved.
A proposed change is compared against the version it was started from. If the published article has changed since, approving it would silently undo that change, so DevStride refuses: The published article changed after this proposal was started, so it cannot be approved. Request changes or discard it. The comparison then offers Discard the proposed change. The proposer can also no longer submit it, and is told to discard it and propose the change again.
If the article was unpublished after the change was submitted, it cannot be approved either: request changes, discard it, or publish the article again first. Once an article is a draft again, edits to it save directly.
If someone submits the change again while you have the comparison open, your decision is refused and you are asked to review the current version.
Switching the category's setting off makes edits to its published articles save live again. A change already waiting for approval can still be reviewed, approved, sent back or discarded.
| Action | Who |
|---|---|
| Switch approval on or off for a category | Publish knowledge-base articles |
| Propose a change | Anyone who can edit the article's content (see Knowledge Base permissions) |
| Submit for approval | The person who proposed it |
| Withdraw submission, Discard changes | The person who proposed it, or a holder of Publish knowledge-base articles |
| Review proposed change: Approve, Request changes | Publish knowledge-base articles |
Proposing, submitting and sending back a change add nothing to the article's history, because the article itself has not changed. An approved change is one Approved change entry, credited to the person who proposed it, with the name of the publisher who approved it: for example Sam Lee, approved by Ana Ruiz.
Spec Stages
Define the stages your specs move through, show each article's stage as a badge to your team and your clients, and keep some stages for publishers to set.
Watching Articles and Categories
Watch an article, or a whole category, to be told in the app when a spec changes stage, gets a new published version, or has a change proposed or decided.