Reviewing and Approving Documentation Versions

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.

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:

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.

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.

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.

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.

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.

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 and 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.
• 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 and Managing Project Version Workspaces.

The next step in this workflow is Managing Version Review Decisions and Approvals, which goes deeper into how decision records are handled after review begins.