## Opening the version review page and confirming you can act on it
If you already know how to open a version and start a review from [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions), the next step is making sure you can actually record a decision.

1. In Atloria, open your project and go to the version list where documentation versions are shown.
2. Select the version you want to review to open its details page.
3. Look for the **Review** action on the version page and open it.
4. At the top of the review page, confirm you are looking at the correct version by checking the visible version details, such as the version name and any revision label shown on the page.
5. Check the current review state before doing anything else. If the page shows that the version is already **Approved**, **Rejected**, or no longer waiting for review, you may not be able to submit a new decision.
6. Review the release context shown on the page. If the version is tied to a release or publication target, make sure it matches the release you intend to approve.

Before you continue, confirm that your access level allows you to make a final decision. In Atloria, **Documentation Managers** and **Project Administrators** can finalize approval decisions. **Technical Writers** may be able to add comments, respond to feedback, or prepare updates, but may not see the final **Approve** or **Reject** buttons.

The review page also gives you the context you need for a safe decision. Check the reviewer area for assigned reviewers, and look for any visible release or publication information connected to this version.

[SCREENSHOT: Version review page showing the version name, review status, reviewer list, and Review action]

If the page does not show a pending review, or if the decision buttons are missing, stop here and confirm the version’s current state and your access before proceeding.

## Checking review status, reviewers, and pending decision details
Once you are on the review page, read the status area carefully before making any decision. This section tells you whether the version is still waiting for review or whether something is already blocking approval.

1. Find the review status panel or status indicator near the top of the page.
2. Read the current state shown there. In Atloria, you may see outcomes such as **awaiting review**, **approved**, **rejected**, or a state that indicates the review cannot move forward because feedback is still unresolved.
3. Open or scan the reviewer section to see who has already responded and who is still pending.
4. Check whether all required approvers have completed their review or whether the version is still waiting on one or more people.
5. Review the activity history or decision history area for earlier actions on this version.

The reviewer area is especially important when more than one person is involved. A version may look nearly complete, but still remain pending because another required reviewer has not responded. If Atloria shows approval progress, use that area to confirm whether your decision will complete the review or only record your own response.

The history area helps you avoid repeating earlier issues. Look for timestamped updates, earlier approval attempts, and any rejection notes already attached to the version. If someone previously rejected the version, read the reason before approving it. You should also review any linked comments, change requests, or unresolved discussions shown on the page. A version that still has open feedback may not be ready for final approval even if most reviewers have responded.

Use this section as your review checkpoint:
- **Status** tells you where the version stands now
- **Reviewers** tell you who has acted and who is still pending
- **History** tells you what happened earlier
- **Comments** tell you what still needs attention

[SCREENSHOT: Review status panel with reviewer responses, pending approvals, and decision history]

## Reviewing changes before approving the version
A review decision should be based on the actual changes in the version, not only the status panel. Before you click **Approve** or **Reject**, open the changes view and inspect what was added, removed, or updated.

1. From the version review page, open the comparison view or changes view for the version.
2. Review the list of changed pages to see which pages were added, edited, or removed.
3. Open individual pages that matter most for the release and check the content directly.
4. Look for page-level indicators that show unresolved comments, validation issues, or other items still needing attention.
5. Use the comment tools or feedback controls to ask for clarification if a page is unclear but does not require a full rejection yet.

When you review the changed content, pay attention to both content and structure. A version may include rewritten instructions, new pages, removed sections, or updates to version details and related information. If the page list highlights problem areas, use those markers to focus your review first. Unresolved comments and failed checks are strong signs that the version still needs work.

If you find a small issue that can be clarified quickly, leave a comment instead of rejecting the entire version immediately. This is especially useful when the overall version is close to ready and the writer only needs to answer a question or adjust one section. Inline comments and discussion threads help keep the review moving without losing context.

Before approving, confirm that the version is complete enough for its release stage. In practice, that means checking:
- the changed pages are present and readable
- important feedback has been addressed
- required reviewers are participating
- the version appears ready for publication based on the indicators shown on the page

[SCREENSHOT: Version changes view showing added, edited, and removed pages with comment indicators]

If the comparison view still shows unresolved issues on key pages, hold your decision until those items are addressed.

## Approving or rejecting the version review decision
When your review is complete, use the decision controls on the review page to record the outcome clearly. Atloria treats **Approve** and **Reject** as formal review decisions, so choose the one that matches the current state of the version.

1. On the version review page, click **Approve** if the version meets the review requirements and the required feedback has been resolved.
2. Click **Reject** if the version still needs additional work before it can move forward.
3. If Atloria shows a comment or notes field during the decision step, enter a clear explanation before submitting.
4. Submit the decision and wait for the page to refresh or update the status.

When you approve a version, Atloria records your decision in the reviewer record and updates the review status shown on the page. If your approval is the final required one, the version may move to a release-ready state or show that review is complete. If other required approvers are still pending, your approval is saved, but the overall review may remain in progress until those people respond.

When you reject a version, explain why in direct, useful language. Focus on the specific issue that prevented approval, such as unresolved comments, missing content, or changes that are not ready for publication. A short but clear rejection reason makes it easier for the writer or project lead to fix the right problem quickly.

After submission, check the page again to confirm:
- your decision appears in the reviewer section
- the status indicator has updated
- the history area shows your action
- any approval count or required-approver progress has changed

[SCREENSHOT: Approval decision dialog with Approve, Reject, and comment field]

If the version does not become fully approved right away, that usually means Atloria is still waiting for additional required reviewers or another release condition has not been met.

## Coordinating release decisions after review is complete
An approved review does not always mean the version can be released immediately. After the review is complete, use the version page to confirm whether the version is truly ready to move forward.

1. Return to the version details page after the review decision is recorded.
2. Check the final review status and any release readiness indicators shown for the version.
3. Confirm whether all required approvers have completed their decisions.
4. Review any remaining blockers, unresolved feedback, or project-level conditions that still prevent release.
5. Record or confirm the final decision in the version record so other team members can see why the version is moving forward, delayed, or sent back for updates.

In Atloria, release coordination often involves more than one role. **Documentation Managers** may confirm content readiness, **Project Administrators** may provide the final sign-off needed for release, and **Technical Writers** may still need to address late feedback. Use the reviewer outcomes and visible status indicators on the version page to keep everyone aligned.

If the version has mixed outcomes, do not rush it into release. For example, one reviewer may have approved while another left unresolved concerns. Late comments can also appear after most reviewers have already approved. In those cases, use the version record and comment history to decide whether the version should wait, be updated, or be reviewed again.

A good final record should make the decision easy to trace later. Anyone opening the version should be able to understand:
- whether it was approved or delayed
- who approved it
- whether any blockers remained
- why it was returned for revision, if applicable

[SCREENSHOT: Version details page showing final review status, release readiness, and reviewer outcomes]

This keeps the release team from guessing and helps avoid confusion when the version is handed off for publication.

## Fixing common problems with review decisions and approvals
If a review decision does not behave the way you expect, start by checking the visible status and reviewer information on the page. Most approval issues come from version state, permissions, or incomplete reviewer progress.

- **Approve** or **Reject** is unavailable  
  Open the version review page and check whether the version is still in a reviewable state. If the page already shows a final decision or the review is closed, the decision buttons may be hidden. Also confirm your role. In Atloria, final decisions are typically available to **Documentation Managers** and **Project Administrators**, while **Technical Writers** may only be able to comment or prepare updates.

- The version still shows **Pending** after your decision  
  Check the reviewer list to see whether other required approvers are still pending. Your own approval may have been saved correctly, but the overall review stays open until everyone required has responded. Also look in the history area to confirm your decision appears there.

- A release cannot proceed after approval  
  Return to the version page and look for unresolved comments, blocked review indicators, or missing sign-off from another required reviewer. A version can be approved by one reviewer and still not be release-ready if Atloria shows outstanding blockers.

- A rejected version does not move back to the expected stage  
  Review the updated version status on the version page and check whether the writer has reopened or updated the version since the rejection. If the page still shows the old state, refresh the version details and confirm the rejection was recorded in the history.

[SCREENSHOT: Review page with disabled decision buttons and visible status indicators]

If the issue is not on the review page itself, compare the version status, reviewer list, and history together. Those three areas usually show exactly why the version is still pending, blocked, or unable to move forward.

## Overview
Managing review decisions in Atloria means doing more than clicking **Approve** or **Reject**. You need to confirm that the version is still open for review, check who else is involved, inspect the actual content changes, and make sure the final decision matches the version’s release readiness.

This workflow usually starts from the version list and continues into the version details page and the review page. From there, the key areas to watch are:
- the **review status** indicator
- the **reviewer** section
- the **decision history** or activity area
- the **changes** or comparison view
- the final **Approve** and **Reject** actions

A careful review decision helps the whole team. It tells writers whether their updates are ready, shows project leads whether required approvals are complete, and gives the release team a clear record of what happened. That matters most when several people are reviewing the same version or when a version is close to publication.

Use this guide when you need to:
- confirm whether you can submit a decision
- understand why a version is still pending
- review changed pages before deciding
- record an approval or rejection with useful notes
- verify whether the version is ready for release after review

If you need help opening the review flow itself or understanding the earlier review steps, go back to [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions). This guide focuses on the decision stage and what to check before and after that decision is recorded.

## Prerequisites
Before you manage a version review decision in Atloria, make sure the version and your access are ready for review work.

- You can sign in to Atloria and open the project that contains the documentation version you need to review.
- You can access the version list and open the selected version’s details page.
- The version is already in a review stage or shows a review action that lets you open the review page.
- You understand the earlier review flow covered in [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions).
- Your role allows the action you need to take:
  - **Documentation Managers** can finalize review decisions
  - **Project Administrators** can finalize review decisions
  - **Technical Writers** may be limited to comments, feedback, or update preparation depending on project permissions
- The version includes enough visible review information for a decision, such as status, reviewer assignments, and changed content.
- Any pages or comments you need to inspect are available from the version review or comparison view.

It also helps to confirm a few practical details before you start:
- You know which version name or revision you are reviewing
- You know whether the version is tied to a specific release or publication target
- You know whether other reviewers are expected to approve before the version can move forward

If you are preparing for the next part of the workflow, continue with [Understanding Review Statuses Comments and Next Steps](doc:understanding-review-statuses-comments-and-next-steps).