## Understanding the version review workflow
In Atloria, version review usually starts in the **Versions** list inside a project workspace. Each version appears with a status badge that shows where it is in the review cycle. The main statuses you will work with are **Draft**, **In Review**, **Approved**, **Rejected**, and **Released**. A version in **Draft** is still being prepared. When someone clicks **Request review** on the version details page, the status changes to **In Review**. After a reviewer makes a decision, the version changes to **Approved** or **Rejected**. Once an approved version is published or finalized for release, it moves to **Released**.

The main screens for this workflow are the **Versions** list, the **version details** page, the **Review status** badge, and the decision actions such as **Request review**, **Approve version**, and **Reject version**. The **Versions** list helps you scan multiple versions at once, while the version details page gives you the full review record for one version.

Different team members usually handle different parts of the process:
- **Technical Writer** prepares the version content, updates the change summary, and requests review.
- **Documentation Manager** checks quality, confirms readiness, and may approve or reject the version.
- **Project Administrator** may step in to review, approve, or manage release readiness depending on project permissions.

On the version details page, reviewers typically look for the **version number or version name**, the **change summary**, any **release notes**, the current **review status**, reviewer **comments**, and the **approval history**. They use that information to decide whether the version is ready to move forward or needs more work.

[SCREENSHOT: Version details page showing status badge, change summary, comments, and approval history]

## Preparing a version and requesting review
Before you ask anyone to review a version in Atloria, open the project’s **Versions** list and select the version you want to send forward. On the version details page, first check the status badge near the top of the screen. It should show **Draft**. If the version is already **In Review**, **Approved**, or **Released**, you are no longer in the initial request stage and should review the current status before making changes.

Reviewers need enough context to understand what changed, so complete the key version details before you click **Request review**. In practice, that means checking the version name and filling in the summary information that explains what this version includes. The most important fields are usually the version label itself, the **change summary**, and the **release notes**. If those areas are incomplete, reviewers may not have enough information to make a decision, and Atloria may prevent you from sending the version for review.

Use this checklist on the version details page before submitting:

| Field or area | What to confirm |
|---|---|
| **Version name** | Clearly identifies the version being reviewed |
| **Change summary** | Explains what was added, updated, or removed |
| **Release notes** | Gives reviewers release context and highlights important changes |
| **Status badge** | Shows **Draft** before review is requested |

When everything is ready, click **Request review**. If Atloria shows a review request dialog, confirm the assigned reviewers and add helpful notes in the **reviewer comments** field. Use that space to point out sections that need special attention or explain what changed since the last draft.

After you submit the request, confirm that the status changes to **In Review** and that a new entry appears in the activity or history area with your name, the time of the request, and the updated status.

[SCREENSHOT: Request review dialog with reviewer selection and reviewer comments field]

## Checking review progress and reviewer feedback
Once a version is under review, the fastest place to check progress is the project’s **Versions** list. The **Review status** badge lets you quickly see whether a version is still **In Review**, has been **Approved**, or has been **Rejected**. This is especially useful when several versions are moving through review at the same time.

For a full picture, open the version details page. That page usually shows the current status near the top and includes the review conversation below it. Look through the **comments** area and the **approval history** to see what each reviewer has said and whether anyone still needs to respond. If Atloria shows pending reviewer assignments, use that list to tell whether the version is waiting on a specific person or whether all required decisions have already been recorded.

When you need to sort through many versions, use the available status filters or tabs in the versions area. These help you focus on:
- versions waiting for action in **In Review**
- versions already marked **Approved**
- versions marked **Rejected** and ready for revision

The approval history is the most reliable place to understand what happened during review. Each entry helps answer three basic questions:
- **Who** reviewed the version
- **What** decision they made
- **When** that decision was recorded

Keep in mind that comments and decisions are not always the same thing. A reviewer may leave feedback without formally approving or rejecting the version. In that case, the version can remain **In Review** even though new comments appear. If you are unsure whether review is complete, rely on the recorded decision and the status badge rather than comments alone.

[SCREENSHOT: Versions list filtered by review status with Approved, In Review, and Rejected badges]

## Approving or rejecting a documentation version
If you are assigned to make a review decision, open the version from the **Versions** list and confirm that its status is **In Review**. On the version details page, look for the decision controls. In Atloria, these actions appear as **Approve version** and **Reject version**. Before choosing either option, review the version information carefully, including the **change summary**, **release notes**, existing **review comments**, and the **approval history** so far.

When you click **Approve version**, Atloria may prompt you to enter a decision comment. Use that comment to explain why the version is ready. A short note is often enough if the version meets expectations, but you can also mention any conditions already satisfied, such as completed edits or reviewed release notes.

When you click **Reject version**, add a clear explanation of what needs to change. The most helpful rejection comments point to the exact issue, such as missing release details, incomplete documentation updates, or content that still needs correction. This gives the writer a clear path for revision before the next review cycle.

After you submit your decision, Atloria updates the version record in two places:
1. The **status badge** changes to reflect the decision, such as **Approved** or **Rejected**.
2. A new entry appears in the **approval history** with your name, decision, comment, and timestamp.

An **Approved** version is generally considered ready to move toward release, subject to any remaining release checks in the project. A **Rejected** version does not move forward. Instead, it returns to an editable state, typically **Draft**, so the writer can update the content and request review again later.

[SCREENSHOT: Decision panel showing Approve version and Reject version actions with comment box]

## Managing revisions after a rejection or review change request
When a version is rejected or sent back with requested changes, start on the version details page rather than editing immediately. Read the reviewer feedback in the **comments** area and the **decision history** so you understand exactly what needs to be fixed. If more than one reviewer responded, compare their notes carefully and look for repeated concerns. Those repeated comments usually point to the highest-priority changes.

Before making updates, check the status badge. The version should return to **Draft** or another editable status before you revise it. If the version still shows **In Review**, look for whether reviewers only added comments without recording a final decision. In that case, you may need to wait for a formal rejection or ask the reviewer to complete the decision step before you continue.

As you revise the version, update more than just the main content when needed. Reviewers often rely on the summary fields to understand what changed since the last review. Revisit these areas:
- the documentation content itself
- the **change summary**
- the **release notes**
- any reviewer-facing notes that explain what was corrected

After you finish the updates, request review again from the version details page. In the **reviewer comments** field, explain what changed since the previous cycle. Keep that note specific. For example, mention that you updated release notes, corrected missing sections, or addressed comments from a named reviewer. This saves reviewers time because they can focus on the revised areas instead of rechecking the entire version from scratch.

If you expect another detailed review round, the version history becomes especially important. Use it to confirm that the new request is recorded with the updated timestamp and that the status changes back to **In Review**.

## Resolving common review and approval issues
Most review problems in Atloria come down to status, missing information, or permissions. If **Request review** is unavailable, first open the version details page and check the status badge. The version usually needs to be in **Draft** before you can send it for review. Then confirm that the key fields are filled in, especially the **version name**, **change summary**, and any **release notes** required for your team’s process. If one of those areas is incomplete, Atloria may keep the review action unavailable until the version is ready.

If you cannot see **Approve version** or **Reject version**, the most likely cause is access level. Those decision actions are typically limited to assigned reviewers, documentation managers, or project administrators with review authority. If you can open the version but do not see the decision controls, compare your access with another reviewer or check with the person who manages project permissions. For related admin areas, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions).

Another common point of confusion is a version that stays **In Review** even after feedback appears. In many cases, that means reviewers added comments but did not submit a formal decision. Comments alone do not always change the status. Open the **approval history** and look for a recorded **Approved** or **Rejected** entry. If there is no decision entry, the review is still open.

If a version is **Approved** but still cannot move to release, review the version details page for anything still incomplete. Common blockers include missing **release notes**, unresolved required comments, or project-level release restrictions that must be cleared before the version can be finalized. If you need help with broader release preparation, continue with [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review).

## Overview
Use Atloria’s version review workflow when a documentation version is ready for formal feedback and a decision. The process begins in the **Versions** list, where you open a version and confirm it is still in **Draft**. From the version details page, you complete the key review context—especially the **version name**, **change summary**, and **release notes**—and then click **Request review** to move the version into **In Review**.

From there, reviewers use the same version details page to inspect the content context, read reviewer notes, and record a decision with **Approve version** or **Reject version**. Atloria tracks each action in the version’s history so your team can see who requested review, who responded, what decision was made, and when that happened. The status badge in both the **Versions** list and the version details page gives you the quickest way to understand whether a version is still pending, approved for the next stage, or returned for revision.

This workflow is most useful when your team needs a clear handoff between writing, review, and release preparation. Writers can submit a version with enough context for reviewers to evaluate it properly. Reviewers can leave comments and make formal decisions without losing the timeline of what happened. Managers and administrators can monitor progress across multiple versions by filtering the list for **In Review**, **Approved**, or **Rejected** items.

If you are already comfortable working with version lists and comparisons, this guide focuses on the actual review decision stage. For broader version management before review begins, see [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness).

## Prerequisites
Before you start reviewing or approving versions in Atloria, make sure these basics are in place:

- You can sign in and open the correct project workspace. If you need help getting into Atloria, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems).
- The project already has at least one documentation version in the **Versions** list.
- The version you want to submit is in **Draft** if you are requesting review for the first time.
- The version details page includes enough review context, especially the **version name**, **change summary**, and **release notes**.
- You have the right level of access for your task:
  - **Technical Writer** to prepare the version and request review
  - **Documentation Manager** to review readiness and make approval decisions
  - **Project Administrator** to manage review access or release-related controls
- Reviewers are identified before you send the request, so the review dialog can be completed without delay.
- If the version was previously rejected, you have already reviewed the earlier comments and updated the version before resubmitting it.

It also helps to be familiar with the project’s version workspace before starting this process. If you need a refresher on finding versions, reading statuses, or opening a version record, see [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) and [Managing Project Version Workspaces](doc:managing-project-version-workspaces).

The next step in this workflow is [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals), which goes deeper into how decision records are handled after review begins.