Skip to main content
The review workflow ensures that cases meet quality standards before becoming trusted knowledge in your operations. It enables collaborative feedback and enforces consistency.

​
Submitting a Case for Review

From a case in Draft state:
  1. Click Submit for Review
That is the whole step. The case moves to In Review and appears in the review queue of everyone in your organisation who holds the Reviewer or Admin role.
There is no reviewer picker and no cover note. You cannot address a case to a named colleague — the queue is shared. If a particular person should look at it, tell them. (Open item #99.)
Anything a reviewer needs to know belongs in the case itself — that is what a later reader will see too.

​
Reviewer Responsibilities

Reviewers examine:
  • Accuracy: Do the facts align with their experience?
  • Completeness: Is evidence adequate? Are claims well-supported?
  • Clarity: Can someone unfamiliar with the incident understand the case?
  • Actionability: Will others benefit from publishing this?

​
Feedback & Comments

A review carries one comment field, written together with the decision. That comment is the whole feedback channel.
There are no inline comments on sections of the case, no comments on individual evidence files, no @-mentions, no reply threads and no live updating. Earlier versions of this page promised all of them. What exists is the comment a reviewer writes when they decide, and the audit log entry that records the decision.

​
Approval Decision

A reviewer chooses one of two actions:

Verify

The case moves to Verified and is ready to publish.

Request changes

The case goes back to Draft so the author can work on it.
There is no third Reject decision, and there is no approval threshold. One review decides. Nobody has to be assigned, and no second reviewer has to agree. An earlier version of this page promised a configurable threshold such as “any 2 of 3 reviewers” — that setting does not exist.
Requesting changes puts the case back into Draft. It does not stay in review. The author edits it there and submits it again, which puts it back into the shared queue.

​
Revision Cycles

When a reviewer requests changes:
  1. The case returns to Draft
  2. The author sees the reviewer’s comment in the Reviews panel on the case page — the case history records that a review was submitted, never its wording
  3. The author edits the case to address the feedback
  4. The author clicks Submit for Review again
  5. The case re-enters the shared queue and any reviewer can pick it up
You can cycle through revision and re-submission as often as you need.
Every decision is written to the audit log. You will always see who decided what and when.

​
Moving to Verified

Once a reviewer verifies the case:
  1. The case moves to Verified
  2. The author is notified
  3. The case is now ready to publish to your knowledge base
While your organisation has the four-eyes setting switched on, an author cannot verify their own case even if they hold the Reviewer role. An Admin can switch that setting off.
From Verified, the creator (or admin) clicks Publish to make it discoverable via search and browsing.
You don’t have to publish immediately after verification. Keep cases in Verified state as a staging area—useful if you want to coordinate publishing with team announcements.

​
Re-opening Published Cases

If a published case needs revision:
  1. Open the case and click Edit Case, then save your change
  2. There is no separate “move to draft” step: saving a change to a published case automatically returns it to Draft and clears its verification, because verified text that has since been rewritten must be reviewed again
  3. The case is removed from search/discovery
  4. You can now edit and re-submit for review
  5. After it is verified again, republish
Re-opening a published case may confuse team members who relied on the old version. Always communicate changes clearly.

​
Review Analytics

The admin dashboard shows the average time from creating a case to verifying it, in days.
That single figure is the whole of it. Most-active reviewers, approval rates by case type and “common feedback themes” were promised by an earlier version of this page and do not exist.

​
Best Practices for Reviewers

Prompt feedback keeps momentum and keeps creators engaged.
Explain why you’re requesting a change, not just what to change.
Don’t approve cases with unsubstantiated claims. Ask for proof.
Check if the case was revised recently. Understanding context helps your review.

Cases

Understand the case lifecycle and states.

Roles & Permissions

Learn which of the three roles may verify and publish cases.