Requesting Review and Handling Version Decisions

Checking whether a version is ready for review

Before you click any review action in Atloria, open the version from the Versions list and check the version detail page carefully. This step helps you avoid sending reviewers an incomplete draft or a version that cannot move forward yet. If you need a refresher on getting a version into review shape, use Preparing Versions for Review and Approval.

Start by confirming that the version is still editable and not already sitting in a completed review state. On the version page, look at the status badge near the top of the screen. If the version already shows a completed decision such as Approved or Rejected, you may need to update the version first before sending a new request. Also check whether the page shows review-related controls instead of edit controls, which can indicate the version is already in an active review cycle.

Then review the content reviewers will actually judge. Make sure the version title and description are filled in and clearly explain what changed. If the version includes release notes, document updates, screenshots, or other release content, open those sections and verify they are complete and saved. Reviewers should be able to understand the scope of the version without guessing.

Next, check the people involved in the review. If Atloria shows a reviewer selection, approval participants, or a similar review assignment area, confirm the correct people are listed before you continue. A request sent to the wrong reviewers usually delays the decision.

Finally, make sure you can actually request review. If the Request Review or Request Approval button is missing or disabled, that usually means one of three things:

• The version is not in the right status yet
• Required details on the version are still missing
• Your account does not have permission to send the request

Requesting approval for a version

Once the version page is complete, use the review action directly from that version record. In Atloria, this usually starts from the version detail screen, where you will see a button such as Request Review or Request Approval. Click that button to open the review request window.

1. Open the version from the Versions list.
2. Click Request Review or Request Approval.
3. If Atloria shows a reviewer picker, select the required reviewers or approval group.
4. Enter a note in the message area explaining what changed in this version.
5. Submit the request.
6. Return to the version page and confirm the status changed to a review state.

If reviewer assignment is available during the request, take a moment to verify every name before submitting. This is especially important when a version needs sign-off from specific project leads or documentation owners. If the reviewer list is already filled in automatically, review it anyway so you do not send the request to an outdated group.

Use the message or note field to give reviewers context. A short, direct note works best, such as what was updated, what needs special attention, or whether the version is targeting a specific release window. This note appears with the request and helps reviewers focus on the right areas.

After you submit, check the version page again. The status badge should move from a draft or work-in-progress state to a review-related state such as Pending Review. You should also see evidence that the request was recorded, usually in one of these places:

• An activity feed
• A review history section
• A comments or timeline panel
• An updated status badge at the top of the version page

If none of those change after submission, do not assume the request went through. Reopen the version and confirm the review request is visible before leaving the page.

Reading reviewer outcomes and tracking decision status

After you send the request, keep checking the version detail page rather than relying only on notifications. Atloria shows the current review state on the version record, and that status tells you whether the version is still waiting, has been approved, or has been rejected.

The first place to look is the status badge. A review that is still in progress will usually show a pending state. Once reviewers respond, the badge should update to a final outcome such as Approved or Rejected. This top-level status is the quickest way to understand where the version stands.

To understand the full story behind that status, open the review history, approval timeline, or comments area on the version page. These sections help you answer practical questions such as:

• Who has already responded
• When each response was submitted
• Whether comments were added with the decision
• Whether the decision shown is final or still partial

Reviewer comments are especially important after a rejection, but they also matter when a version is approved with notes. Read each comment attached to the decision record so you understand whether the reviewer is fully satisfied or expects a follow-up before release.

If more than one reviewer participates, separate individual responses from the final version decision. One reviewer may approve while another is still pending, and the version may remain in a review state until all required responses are complete. In other cases, a single rejection may immediately set the version to Rejected. The review history or timeline is the best place to confirm how Atloria applied the decision.

When you need a deeper explanation of review outcomes and comment handling, see Understanding Review Statuses Comments and Next Steps and Managing Version Review Decisions and Approvals.

Updating a rejected version and requesting review again

When a version is rejected in Atloria, start from the rejection record rather than editing blindly. Open the version detail page and read the comments attached to the Rejected decision. Those comments usually point to the exact content, release notes, screenshots, or version details that need attention.

1. Open the rejected version from the Versions list.
2. Review the rejection comments in the review history, comments, or timeline area.
3. Return to the editable sections of the version and make the requested updates.
4. Save your changes and confirm the version is no longer blocked by the earlier review cycle.
5. Use Request Review or Request Approval again to submit the revised version.

As you make changes, keep the revision clear and easy to follow. Update the same version carefully so reviewers can see that the rejected issues were addressed. If the version description or release summary needs clarification, revise that too. A clear summary helps reviewers understand what changed since the rejection.

After a rejection, confirm the version has returned to an editable state. You should be able to open the content areas, save updates, and see the earlier rejection preserved in the history rather than mixed into the new request. Atloria should keep the previous decision visible as part of the record while still allowing you to prepare a fresh review cycle.

Before you send the version back, double-check that the new request reflects the latest changes. If Atloria provides a message field during the second request, use it to explain what was fixed. That saves reviewers time and reduces back-and-forth.

For guidance on handling comments and follow-up work between review rounds, see Understanding Version Review Feedback and Follow Up and Managing Version Review Requests and Decisions.

Moving an approved version toward release

Once a version shows Approved, the review phase is largely complete, but you should still verify that the approval is fully finished before moving toward release. Start on the version detail page and confirm the status badge shows Approved, not a partial or still-pending review state.

1. Open the approved version.
2. Confirm all required reviewer responses are complete in the review history or timeline.
3. Look for release-related actions on the version page.
4. Check any release readiness indicators or activity records tied to the approval.
5. Coordinate the actual release timing with the project team.

An approved badge alone is not always enough if multiple reviewers were involved. Open the review history and make sure there are no missing decisions still holding the version in a conditional state. If Atloria uses a timeline or activity area, verify that the approval was recorded as the final decision.

Next, look for controls that become useful after approval. Depending on your project setup, the version page may show actions related to release, publishing, finalization, or the next handoff step. Review those controls carefully before proceeding so you do not move a version forward too early.

It is also helpful to check for signs that approval changed the version’s workflow state. On the version page, this may appear as:

• A new status badge
• A release readiness indicator
• A new item in the activity feed
• A recorded approval entry in the version history

If your team releases on a schedule, do not assume approval means immediate publication. Some approved versions should be held until a planned release window. In that case, confirm the approved version is ready, then coordinate with project administrators or release owners before taking the next action.

The next stage in this workflow is covered in Preparing Versions for Final Approval and Release Handoffs.

Fixing common review workflow problems

Most review issues in Atloria can be traced back to the version page. When something does not behave as expected, return to the version detail screen and check the status, reviewer information, and visible actions before trying again.

If Request Review or Request Approval is unavailable, inspect the version first. The button may be hidden or disabled because the version is in the wrong status, key fields are incomplete, or your account does not have the right access. Check the title, description, and any release-related content areas, then look at the status badge to confirm the version is still eligible for review.

If reviewer decisions seem to be missing or delayed, open the review history or timeline and confirm the request was actually submitted. Then check whether the correct reviewers were assigned. A request sent without the right participants can sit in a pending state even though the version looks submitted.

If the version stays in Pending Review after some responses are in, the most likely cause is that Atloria is waiting for all required reviewers. Compare the list of assigned reviewers with the responses shown in the history. One approval does not always create a final decision.

If an approved version still cannot move forward, look for release blockers on the version page. These may include a status lock, missing release prerequisites, or project-level approval rules that still need to be satisfied.

A quick troubleshooting checklist:

• Review button missing: Check version status, required details, and your permissions
• No reviewer response visible: Confirm reviewer assignment and that the request was submitted
• Still pending after responses: Check whether all required reviewers must respond
• Approved but not releasable: Review release readiness indicators and project approval rules

If you need more help with admin-level review controls, see Using the Admin Workspace, Reviewing Security and Audit Controls, and Monitoring Administrative Analytics and Activity.

Overview

Use this workflow when a documentation version is ready to leave editing and enter formal review in Atloria. The main work happens on the Versions list and the individual version detail page, where you check readiness, send the review request, monitor decisions, and respond to approval or rejection outcomes.

This guide focuses on the handoff point between preparation and decision handling. It assumes the version content has already been reviewed for completeness and that you are ready to use the Request Review or Request Approval action. If you still need to finish the version itself, return to Preparing Versions for Review and Approval before continuing.

You will use this process to:

• Confirm the version can enter review
• Send the review request to the right people
• Read approval, pending, and rejection outcomes
• Update a rejected version and submit it again
• Move an approved version toward release planning

In Atloria, the most important signals are visible directly on the version page: the status badge, the review history, the comments area, and any release-related actions that appear after approval. Staying on that page gives you the clearest picture of what happened and what still needs attention.

This guide does not repeat the broader version lifecycle, comparison work, or release preparation steps covered elsewhere. For that surrounding context, see Managing Documentation Versions Across the Release Cycle, Comparing Documentation Versions for Release Decisions, and Reviewing and Approving Documentation Versions.

Prerequisites

Before you request review for a version in Atloria, make sure these conditions are already in place:

• You can sign in and reach the project workspace where the version is stored
• You can open the Versions list and access the relevant version detail page
• The version already contains the content reviewers are expected to evaluate
• The version title and description are filled in clearly
• Any release-related content included with the version has been saved
• The correct reviewers or approval participants are available for selection, if Atloria allows manual assignment
• Your role includes permission to send a review request or approval request
• The version is not already locked by a completed decision that prevents a new request

It also helps if you have already completed the earlier preparation work covered in:

• Preparing Versions for Review and Approval
• Requesting and Completing Version Reviews
• Preparing Versions for Final Approval

If you expect to move quickly from approval into release coordination, keep your project administrators or release owners aligned before you submit the request. That way, an Approved version does not sit waiting because the next handoff was never planned.

For users who also manage project-level settings, it may be useful to understand the surrounding workspace and approval context in Managing Project Administration from the Project Home and Controlling Version Sharing and Export Readiness.