Managing Version Review Requests and Decisions

Understanding version review requests and decision states

In Atloria, version review happens on the version record itself. After you finish the preparation work described in Preparing a Version for Final Release Review, you open the version and use the review controls on that page to ask for a formal decision. The version page is where you can see whether review has started, whether a reviewer has responded, and whether the version can move toward release.

Look for review-related details in the version header and surrounding panels. The most important item is the Review status indicator. This shows the current review state for that version. You may also see an activity area or decision history that records review events in order, along with action buttons such as Request review, Approve, Reject, or a follow-up action that moves the version forward after approval.

These review states are the ones to pay attention to:

• No review requested: no formal review has been opened yet.
• Review requested or Pending review: the version has been submitted and is waiting for reviewer input.
• Approved: the reviewer recorded a positive decision and the version can continue in the release workflow.
• Rejected: the reviewer recorded a negative decision and the version should be updated before another review request.
• Ready for release: review is complete and the version has been moved to the next release-ready stage.

The review state is different from the broader version lifecycle status. A version can still be in a draft or pre-release stage while also having a review request in progress.

Atloria preserves decision tracking on the version record. In the activity history or decision log, you can confirm who requested the review, who approved or rejected it, when each action happened, and any comments entered with the decision. This history matters when a version goes through more than one review cycle, because older decisions remain visible instead of disappearing.

Preparing a version before requesting review

Before you click Request review, open the version and make sure it is still in a state where changes and review actions are allowed. If the version has already been fully released, locked by a completed release step, or already has an active review decision that has not been resolved, Atloria may not show the review request action or may prevent you from submitting a new request.

Start with the version details that reviewers are most likely to check. Confirm that the version title is correct, the version identifier is final, and any release notes or summary information on the version page are complete. If your workspace shows reviewer, approver, or owner fields, make sure those are filled in before you begin. Missing ownership or release information often creates confusion later, even if Atloria allows you to continue.

It also helps to review the page for visible warnings before opening review. Pay attention to:

• Required fields marked as incomplete
• Validation messages near the version header or form sections
• Status warnings that suggest the version is not ready
• Existing rejection notes that still need to be addressed
• Missing reviewer or approver assignments, if those fields appear in your workspace

Your ability to request review or record a decision depends on your role in the project. In most teams, a Documentation Manager or Project Administrator is responsible for opening formal review and moving the version forward after approval. A Technical Writer may prepare the version content and in some workspaces may also request review, but decision actions such as Approve or Reject may be limited to designated reviewers or approvers.

If the review controls are missing, do not assume the version is broken. First check whether the version is already under review, already approved, or in a state that no longer accepts changes. Then confirm that your account has the right level of access for review actions.

Opening a review request for a version

1. In Atloria, open the project and go to the version you want to submit. You can usually start from the versions list or from the project’s version detail area, then click the target version to open its full record.

2. On the version page, find the review action in the main toolbar or the actions menu. Depending on your workspace, the button may appear as Request review or Open review. Click that action to start the review request.

3. Complete the review form that appears. Atloria may ask for one or more of the following details before it will send the request:

   Field	What to enter
   Reviewer	Select the person who should review the version
   Due date	Choose the date by which the review should be completed
   Review notes	Add context about what changed or what needs special attention
   Decision context	Explain the release goal, scope, or any known issues if this field appears

4. Review the information you entered, then submit the request. After you save, return to the version page and check the Review status indicator. It should change from a not-requested state to Review requested or Pending review.

5. Open the version’s activity history or decision history and confirm that the request was recorded. You should see an entry showing that the review was opened, along with the requester name and timestamp.

If the status does not change after submission, refresh the version page and check for any validation message that may have prevented the request from being saved.

Reading review status and decision history on the version

Once a review request is open, the version page becomes the main place to monitor what is happening. The first item to check is the Review status badge or status field. This tells you the current review outcome for that version. Do not confuse it with the version’s broader workflow status, which may still show a draft, in-progress, or pre-release stage. A version can be technically ready for review while still not being ready for release.

When reading the status, use it as a release signal:

• Pending review means the version is waiting for a reviewer and is typically blocked from moving forward.
• Approved means the review step is complete and the version can continue to the next release action.
• Rejected means the version should not move forward until the issues are addressed and a new review cycle begins.
• Ready for release means the approval has already been carried into the next workflow stage.

To understand how the version reached its current state, open the activity stream, audit area, or decision history panel on the same page. This section shows the sequence of review events over time, such as:

• review requested
• comments added by the reviewer
• approval recorded
• rejection recorded
• status changed after a follow-up review

This history is especially important when a version has been reviewed more than once. The latest decision is the active one, but older entries still remain visible. That means you may see an earlier rejection followed by a later approval. In that case, treat the newest recorded decision as the current one, while using the older entries to understand what changed between review rounds.

Recording approvals and rejections with clear rationale

1. Open the version that is currently in Pending review or Review requested status. On the version page, locate the decision controls in the toolbar or actions area.

2. Click Approve if the version is ready to move forward, or click Reject if it needs more work before release. Atloria records the decision on the version itself, so make sure you are on the correct version before saving.

3. In the decision form, enter the explanation Atloria asks for. Depending on your workspace, this may include a Decision comment, Reviewer notes, or a Rejection reason. Keep the comment specific. For example, use the notes to point to missing release notes, unresolved content issues, or confirmation that the version is ready for the next release step.

4. Save the decision. Return to the version header and confirm that the Review status updates immediately to Approved or Rejected.

5. Open the activity history or decision log and verify that the entry includes:

   • the reviewer’s name
   • the date and time of the decision
   • the decision type
   • the comment or rationale entered with the decision

Clear rationale matters because review decisions often affect release timing, handoffs, and follow-up work. A short but direct comment is usually enough if it explains why the version passed or failed review. If you reject a version, make sure the note helps the writer or project owner understand what must be corrected before another review request is opened.

Moving an approved version toward release and fixing common review issues

After a version is marked Approved, use the next available workflow action on the version page to move it forward. Depending on how your Atloria workspace is set up, this may appear as Mark ready for release, a status promotion action, or another release-related button in the version toolbar. After you use that action, check that the approval remains visible in the version history so the release record still shows who approved it and when.

If the version does not move forward, look for blockers on the version page before trying again. Common causes include:

• required release fields still missing
• validation warnings on the version record
• unresolved issues from an earlier rejected review cycle
• a version state that allows approval but not final release progression

You may also run into cases where the review buttons are missing entirely. When Request review, Approve, or Reject does not appear, check these items first:

• your role may not have permission to perform that action
• the version may already have an active review in progress
• the version may already be approved, rejected, or released
• the version may be in a state that no longer accepts review changes

If the wrong decision was recorded, avoid trying to hide or replace the older entry. In Atloria, the safer approach is to reopen the review process by creating a new review request or starting another review cycle on the same version, if that option is available in your workspace. The earlier decision should remain in the history so the audit trail stays complete. That preserved history is useful when teams need to understand why a version was delayed, revised, and then approved later.

The next step is Understanding Version Review Feedback and Follow Up, which explains how to work through reviewer comments and prepare the next response.

Overview

Use this workflow when a version is ready for a formal decision but has not yet been released. In Atloria, the review process centers on the version page, where you request review, monitor the Review status, read decision history, and record an Approve or Reject outcome. This document focuses on the decision-handling part of the workflow rather than the earlier preparation work. If you still need to finish the version before sending it out, return to Preparing a Version for Final Release Review.

The core tasks covered here are:

• opening a review request from the version record
• checking whether the version is waiting for review, approved, or rejected
• reading the activity history to understand what happened and when
• recording a clear decision with comments that remain attached to the version
• moving an approved version into the next release stage

You will spend most of your time in a few visible areas on the version page:

• the Review status indicator
• the version toolbar or actions menu
• the activity history or decision history panel
• any review form that appears when you request review or record a decision

This guide is most useful for team members who coordinate release readiness, including documentation leads, project administrators, and reviewers who are responsible for formal approval steps. It is also useful for writers who need to understand why a version is blocked and what the latest review decision means.

Prerequisites

Before you work through review requests and decisions in Atloria, make sure these conditions are already met:

• You can sign in and open the correct project workspace.
• The target version already exists in the project’s versions list.
• The version has been prepared for review, including any required title, version identifier, and release details that appear on the version page.
• You have the right project role to perform the action you need, such as requesting review or recording an approval decision.
• You know whether you are acting as the requester, reviewer, or release coordinator for that version.

It also helps to have these items ready before you begin:

• the name of the reviewer or approver, if Atloria asks you to select one
• any review notes you want to include with the request
• a clear reason for approval or rejection if you are the person recording the decision

Use this guide after you have already learned the basics of version review status and approval handling in:

• Reviewing and Approving Documentation Versions
• Managing Version Review Decisions and Approvals
• Understanding Review Statuses Comments and Next Steps

If the version is not yet ready for formal review, complete the preparation steps in Preparing a Version for Final Release Review before opening a new review request.