> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ferrufino-tech-solutions.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Review Workflow

> Move cases through review: submit, one reviewer decides, verify or send back.

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.

<Warning>
  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.)
</Warning>

<Tip>
  Anything a reviewer needs to know belongs in the case itself — that is what a later reader will see too.
</Tip>

## 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.

<Warning>
  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.
</Warning>

## Approval Decision

A reviewer chooses one of **two** actions:

<CardGroup cols={2}>
  <Card title="Verify" icon="check">
    The case moves to **Verified** and is ready to publish.
  </Card>

  <Card title="Request changes" icon="pencil">
    The case goes back to **Draft** so the author can work on it.
  </Card>
</CardGroup>

<Warning>
  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.
</Warning>

<Warning>
  **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.
</Warning>

## 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.

<Info>
  Every decision is written to the audit log. You will always see who decided what and when.
</Info>

## 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

<Warning>
  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.
</Warning>

From Verified, the creator (or admin) clicks **Publish** to make it discoverable via search and browsing.

<Tip>
  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.
</Tip>

## 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

<Warning>
  Re-opening a published case may confuse team members who relied on the old version. Always communicate changes clearly.
</Warning>

## Review Analytics

The admin dashboard shows the **average time from creating a case to verifying it**, in days.

<Warning>
  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.
</Warning>

## Best Practices for Reviewers

<AccordionGroup>
  <Accordion title="Review within 48 hours">
    Prompt feedback keeps momentum and keeps creators engaged.
  </Accordion>

  <Accordion title="Be constructive in comments">
    Explain *why* you're requesting a change, not just what to change.
  </Accordion>

  <Accordion title="Request evidence if needed">
    Don't approve cases with unsubstantiated claims. Ask for proof.
  </Accordion>

  <Accordion title="Look at the audit log">
    Check if the case was revised recently. Understanding context helps your review.
  </Accordion>
</AccordionGroup>

<CardGroup>
  <Card title="Cases" icon="folder-open" href="/en/features/cases">
    Understand the case lifecycle and states.
  </Card>

  <Card title="Roles & Permissions" icon="shield" href="/en/features/roles-permissions">
    Learn which of the three roles may verify and publish cases.
  </Card>
</CardGroup>