## Understanding the version review workflow
In Atloria, the version review workflow centers on the **Versions** list and the **version details** page. A version usually starts in **Draft**, moves to **In review** when you send it for review, changes to **Approved** when the review decision is accepted, or returns for changes when **Rework requested** is recorded. The current status appears on the version record, so you can quickly tell whether the version is still being prepared, waiting on reviewers, or ready for the next release step.

Each role has a different part in this process. The **Technical Writer** prepares the version and uses **Request review** when the content is ready for formal feedback. The **Documentation Manager** opens the version, checks the content, and records a decision such as approval or rework. The **Project Administrator** makes sure the right people can open the project, access the version, and participate in the review process without permission problems.

It helps to separate the actions in the workflow:

- **Requesting a review** sends the version to selected reviewers.
- **Checking reviewer responses** means reading comments, decisions, and pending responses on the version details page.
- **Recording a decision** means a reviewer or approver chooses the available decision option and adds comments.
- **Returning a version for changes** moves the version out of the active review path so the writer can revise it and submit it again.

The **version details** page is the main place to manage all of this. That page shows the version status, reviewer assignments, review notes, and decision history in one place. If you already completed the readiness work described in [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval), this is where that preparation turns into a formal review decision.

[SCREENSHOT: Version details page showing status, assigned reviewers, and review history]

## Preparing a version before requesting review
Before you click **Request review**, open the version from the **Versions** list and confirm that the version record is complete. The version should already be saved and visible in the list. If you cannot find it in **Versions**, finish saving your work first and return to the version details page before starting the review process.

On the version record, check the main details that reviewers rely on to understand what they are reviewing. At minimum, confirm that the version has a clear **title**, a useful **description**, and the correct current **status** before the review starts. These details help reviewers identify the right release candidate and avoid confusion when several versions are being worked on at the same time.

It is also important to confirm access before sending the request. Reviewers must be able to open the project or workspace where the version lives. If a reviewer does not have access, they may appear to be assigned but still be unable to open the version and submit a decision. This is usually something the **Project Administrator** checks in advance.

Before sending the request, review the latest content on the version details screen:

- Make sure recent edits are saved.
- Check that any supporting attachments or related review materials are present.
- Confirm you are opening the correct version, especially if there are multiple drafts.
- Re-read any notes that should guide the reviewer’s decision.

This preparation step is where you catch incomplete drafts before they enter formal review. If you need a refresher on getting a version into a ready state, use [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval) as your reference rather than repeating those checks during the review request itself.

[SCREENSHOT: Version details page with title, description, status, and related content ready for review]

## Requesting review for a documentation version
1. In Atloria, open the project and go to the **Versions** list.
2. Select the version you want to review to open its **version details** page.
3. On the version page, click **Request review**.
4. In the reviewer selection area, choose one or more reviewers.
5. Add any review notes or decision context that reviewers should read before they begin.
6. Confirm the request to send the version into review.

When you choose reviewers, make sure you are selecting the people responsible for the actual decision. A **Technical Writer** usually submits the request, while a **Documentation Manager** often reviews the content and records the decision. If access needs to be adjusted first, ask the **Project Administrator** to confirm that the selected reviewers can open the version.

Use the review notes area to give clear direction. For example, you might explain what changed in this version, which sections need the closest attention, or whether the review is focused on release readiness. These notes appear as context for reviewers when they open the request, so this is the best place to set expectations without adding separate messages outside the version record.

After you submit the request, stay on the version details page and verify the result:

- The version status should change from **Draft** to **In review**.
- The review panel should show the assigned reviewers.
- The request date should be visible.
- The overall review state should show that responses are pending.

If the status does not change, refresh the page and check whether the request was fully submitted. You should not leave the page assuming the review started until you can see the updated status and reviewer list.

[SCREENSHOT: Request review panel with reviewer selection, notes field, and updated In review status]

## Checking review status and reviewer responses
Once a version is in review, return to the **version details** page to track progress. This page is the clearest place to see whether the version is still waiting on responses, has already been approved, or has been sent back for changes. The status indicator gives the overall result for the version, while the review area shows what each assigned reviewer has done.

As responses come in, read the comments and decision entries in the review history or activity area. This is where reviewers explain why they approved the version or why they want changes before approval. If you need to follow up, use those comments to understand exactly what is blocking the version instead of guessing from the status alone.

Keep in mind that individual reviewer responses and the overall version decision are not always the same thing. One reviewer may have completed their review while another is still pending. The version can remain **In review** until the required decision is fully recorded. When you monitor progress, look at both the overall status and the list of assigned reviewers.

Use the version details page to answer these questions:

- Is the version still **pending review**, or has a decision already been made?
- Which reviewers have responded?
- Which reviewers are still pending?
- Did any reviewer leave comments that require clarification or changes?

If one or more assigned reviewers have not responded, the review is not fully complete. In that case, the writer or manager may need to follow up outside the version page, but the version record remains the source of truth for what has and has not been submitted.

For more detail on interpreting comments and review outcomes, see [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up).

[SCREENSHOT: Review history showing reviewer names, comments, decisions, and pending responses]

## Approving a version or sending it back for rework
1. Open the version from the **Versions** list and confirm it is currently marked **In review**.
2. On the **version details** page, find the decision controls in the review area.
3. Choose **Approve** if the version is ready to move forward, or choose **Request rework** if changes are still needed.
4. Enter decision comments explaining why you approved the version or why it is being returned.
5. Submit the decision and wait for the page to update.
6. Confirm the new status and review history entry on the version record.

Decision comments matter because they become part of the version history. If you approve the version, your comments can explain what was reviewed and any limitations that were accepted. If you request rework, use the comments to point the writer to the exact content or attachments that need attention. Clear comments reduce back-and-forth and make the next review cycle faster.

After an approval, verify that the version status changes to **Approved**. The review history should also show the approval decision and the comment you entered. This gives everyone working on the release a visible record that the review step is complete.

If you choose **Request rework**, confirm that the version moves into a rework-needed state. At that point, the writer can reopen the version, make the required edits, save the changes, and submit a new review request when the updates are ready. Rework does not end the process; it sends the version back into revision so it can return to review with the issues addressed.

If you need more guidance on decision handling, see [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals).

[SCREENSHOT: Decision controls showing Approve and Request rework options with comment box]

## Common issues and how to fix them
The most common review problems in Atloria are easy to spot once you know where to look on the version details page.

- **Request review is unavailable**
  - Check whether the version has been saved.
  - Confirm the version is not already marked **In review**.
  - Review the version record for missing required details such as **title**, **description**, or other information expected before review.
  - Return to the version page, save your updates, and try **Request review** again.

- **A reviewer cannot access the version**
  - Confirm the reviewer has access to the correct project or workspace.
  - Check that the reviewer was actually assigned in the review request.
  - Make sure you are sending the correct version from the correct project.
  - If needed, ask the **Project Administrator** to review permissions before resending the request.

- **The status does not update after a decision**
  - Refresh the version details page.
  - Check whether the reviewer fully submitted the decision after entering comments.
  - Look in the review history or activity area for a new decision entry.
  - If no entry appears, the reviewer should reopen the version and submit the decision again.

- **The version stays blocked in rework**
  - Make sure the writer saved all requested edits.
  - Confirm the version was submitted for review again after the changes were completed.
  - Check that the status moved out of the rework state and back to **In review** after the new request.

When troubleshooting, always start with the **version details** page. It shows the current status, reviewer assignments, and decision history together, which makes it the fastest place to identify whether the problem is missing information, access, or an incomplete review action.

## Overview
Version reviews in Atloria are managed from the **Versions** list and the **version details** page. The workflow is straightforward: a writer prepares a version, uses **Request review**, selected reviewers respond, and the version either moves to **Approved** or returns for changes through **Request rework**. The status shown on the version record is the main indicator of where that version stands in the approval process.

This workflow is shared across the people involved in release decisions:

| Role | Main action in the review workflow | Where they usually work |
|---|---|---|
| Technical Writer | Prepares the version and clicks **Request review** | **Versions** list and **version details** page |
| Documentation Manager | Reviews content and records **Approve** or **Request rework** | Review area on the **version details** page |
| Project Administrator | Confirms access and keeps the review process moving | Project access and workspace controls |

The most important thing to remember is that requesting a review is not the same as completing one. Sending the request only moves the version into **In review**. You still need to watch reviewer responses, read comments, and confirm that a final decision appears in the review history. If the version is returned for changes, the writer must update the version and submit a new request.

If you have already worked through [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval), this guide picks up from that point and shows how the actual review request and decision cycle works in Atloria.

## Prerequisites
Before you start a version review in Atloria, make sure the version and the people involved are ready. This avoids failed review requests, missing reviewer access, and versions getting stuck in the wrong status.

Use this checklist before opening **Request review**:

- The version appears in the **Versions** list.
- The version opens correctly on its **version details** page.
- The version has been saved after the latest edits.
- The version record includes a clear **title** and **description**.
- The current status still allows the version to be sent for review.
- The intended reviewers can access the same project or workspace.
- Any supporting attachments or related review material are already visible on the version record.
- The writer knows what feedback or decision is being requested.

You should also know who is responsible for each part of the workflow:

- The **Technical Writer** sends the review request.
- The **Documentation Manager** reviews the version and records the decision.
- The **Project Administrator** helps resolve access or workspace issues if reviewers cannot open the version.

If the version is still being finalized, do that work first before starting the review cycle. The earlier preparation steps are covered in [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval). After you complete the review process described here, the next step is [Preparing Versions for Review and Approval](doc:preparing-versions-for-review-and-approval).