Requesting and Completing Version Reviews

Understanding the version review workflow

In Atloria, the version review workflow centers on the Versions list and the version details page. A version usually starts in Draft, moves to In review when you send it for review, changes to Approved when the review decision is accepted, or returns for changes when Rework requested is recorded. The current status appears on the version record, so you can quickly tell whether the version is still being prepared, waiting on reviewers, or ready for the next release step.

Each role has a different part in this process. The Technical Writer prepares the version and uses Request review when the content is ready for formal feedback. The Documentation Manager opens the version, checks the content, and records a decision such as approval or rework. The Project Administrator makes sure the right people can open the project, access the version, and participate in the review process without permission problems.

It helps to separate the actions in the workflow:

• Requesting a review sends the version to selected reviewers.
• Checking reviewer responses means reading comments, decisions, and pending responses on the version details page.
• Recording a decision means a reviewer or approver chooses the available decision option and adds comments.
• Returning a version for changes moves the version out of the active review path so the writer can revise it and submit it again.

The version details page is the main place to manage all of this. That page shows the version status, reviewer assignments, review notes, and decision history in one place. If you already completed the readiness work described in Preparing Versions for Final Approval, this is where that preparation turns into a formal review decision.

Preparing a version before requesting review

Before you click Request review, open the version from the Versions list and confirm that the version record is complete. The version should already be saved and visible in the list. If you cannot find it in Versions, finish saving your work first and return to the version details page before starting the review process.

On the version record, check the main details that reviewers rely on to understand what they are reviewing. At minimum, confirm that the version has a clear title, a useful description, and the correct current status before the review starts. These details help reviewers identify the right release candidate and avoid confusion when several versions are being worked on at the same time.

It is also important to confirm access before sending the request. Reviewers must be able to open the project or workspace where the version lives. If a reviewer does not have access, they may appear to be assigned but still be unable to open the version and submit a decision. This is usually something the Project Administrator checks in advance.

Before sending the request, review the latest content on the version details screen:

• Make sure recent edits are saved.
• Check that any supporting attachments or related review materials are present.
• Confirm you are opening the correct version, especially if there are multiple drafts.
• Re-read any notes that should guide the reviewer’s decision.

This preparation step is where you catch incomplete drafts before they enter formal review. If you need a refresher on getting a version into a ready state, use Preparing Versions for Final Approval as your reference rather than repeating those checks during the review request itself.

Requesting review for a documentation version

1. In Atloria, open the project and go to the Versions list.
2. Select the version you want to review to open its version details page.
3. On the version page, click Request review.
4. In the reviewer selection area, choose one or more reviewers.
5. Add any review notes or decision context that reviewers should read before they begin.
6. Confirm the request to send the version into review.

When you choose reviewers, make sure you are selecting the people responsible for the actual decision. A Technical Writer usually submits the request, while a Documentation Manager often reviews the content and records the decision. If access needs to be adjusted first, ask the Project Administrator to confirm that the selected reviewers can open the version.

Use the review notes area to give clear direction. For example, you might explain what changed in this version, which sections need the closest attention, or whether the review is focused on release readiness. These notes appear as context for reviewers when they open the request, so this is the best place to set expectations without adding separate messages outside the version record.

After you submit the request, stay on the version details page and verify the result:

• The version status should change from Draft to In review.
• The review panel should show the assigned reviewers.
• The request date should be visible.
• The overall review state should show that responses are pending.

If the status does not change, refresh the page and check whether the request was fully submitted. You should not leave the page assuming the review started until you can see the updated status and reviewer list.

Checking review status and reviewer responses

Once a version is in review, return to the version details page to track progress. This page is the clearest place to see whether the version is still waiting on responses, has already been approved, or has been sent back for changes. The status indicator gives the overall result for the version, while the review area shows what each assigned reviewer has done.

As responses come in, read the comments and decision entries in the review history or activity area. This is where reviewers explain why they approved the version or why they want changes before approval. If you need to follow up, use those comments to understand exactly what is blocking the version instead of guessing from the status alone.

Keep in mind that individual reviewer responses and the overall version decision are not always the same thing. One reviewer may have completed their review while another is still pending. The version can remain In review until the required decision is fully recorded. When you monitor progress, look at both the overall status and the list of assigned reviewers.

Use the version details page to answer these questions:

• Is the version still pending review, or has a decision already been made?
• Which reviewers have responded?
• Which reviewers are still pending?
• Did any reviewer leave comments that require clarification or changes?

If one or more assigned reviewers have not responded, the review is not fully complete. In that case, the writer or manager may need to follow up outside the version page, but the version record remains the source of truth for what has and has not been submitted.

For more detail on interpreting comments and review outcomes, see Understanding Version Review Feedback and Follow Up.

Approving a version or sending it back for rework

1. Open the version from the Versions list and confirm it is currently marked In review.
2. On the version details page, find the decision controls in the review area.
3. Choose Approve if the version is ready to move forward, or choose Request rework if changes are still needed.
4. Enter decision comments explaining why you approved the version or why it is being returned.
5. Submit the decision and wait for the page to update.
6. Confirm the new status and review history entry on the version record.

Decision comments matter because they become part of the version history. If you approve the version, your comments can explain what was reviewed and any limitations that were accepted. If you request rework, use the comments to point the writer to the exact content or attachments that need attention. Clear comments reduce back-and-forth and make the next review cycle faster.

After an approval, verify that the version status changes to Approved. The review history should also show the approval decision and the comment you entered. This gives everyone working on the release a visible record that the review step is complete.

If you choose Request rework, confirm that the version moves into a rework-needed state. At that point, the writer can reopen the version, make the required edits, save the changes, and submit a new review request when the updates are ready. Rework does not end the process; it sends the version back into revision so it can return to review with the issues addressed.

If you need more guidance on decision handling, see Managing Version Review Decisions and Approvals.

Common issues and how to fix them

The most common review problems in Atloria are easy to spot once you know where to look on the version details page.

• Request review is unavailable

  • Check whether the version has been saved.
  • Confirm the version is not already marked In review.
  • Review the version record for missing required details such as title, description, or other information expected before review.
  • Return to the version page, save your updates, and try Request review again.

• A reviewer cannot access the version

  • Confirm the reviewer has access to the correct project or workspace.
  • Check that the reviewer was actually assigned in the review request.
  • Make sure you are sending the correct version from the correct project.
  • If needed, ask the Project Administrator to review permissions before resending the request.

• The status does not update after a decision

  • Refresh the version details page.
  • Check whether the reviewer fully submitted the decision after entering comments.
  • Look in the review history or activity area for a new decision entry.
  • If no entry appears, the reviewer should reopen the version and submit the decision again.

• The version stays blocked in rework

  • Make sure the writer saved all requested edits.
  • Confirm the version was submitted for review again after the changes were completed.
  • Check that the status moved out of the rework state and back to In review after the new request.

When troubleshooting, always start with the version details page. It shows the current status, reviewer assignments, and decision history together, which makes it the fastest place to identify whether the problem is missing information, access, or an incomplete review action.

Overview

Version reviews in Atloria are managed from the Versions list and the version details page. The workflow is straightforward: a writer prepares a version, uses Request review, selected reviewers respond, and the version either moves to Approved or returns for changes through Request rework. The status shown on the version record is the main indicator of where that version stands in the approval process.

This workflow is shared across the people involved in release decisions:

The most important thing to remember is that requesting a review is not the same as completing one. Sending the request only moves the version into In review. You still need to watch reviewer responses, read comments, and confirm that a final decision appears in the review history. If the version is returned for changes, the writer must update the version and submit a new request.

If you have already worked through Preparing Versions for Final Approval, this guide picks up from that point and shows how the actual review request and decision cycle works in Atloria.

Prerequisites

Before you start a version review in Atloria, make sure the version and the people involved are ready. This avoids failed review requests, missing reviewer access, and versions getting stuck in the wrong status.

Use this checklist before opening Request review:

• The version appears in the Versions list.
• The version opens correctly on its version details page.
• The version has been saved after the latest edits.
• The version record includes a clear title and description.
• The current status still allows the version to be sent for review.
• The intended reviewers can access the same project or workspace.
• Any supporting attachments or related review material are already visible on the version record.
• The writer knows what feedback or decision is being requested.

You should also know who is responsible for each part of the workflow:

• The Technical Writer sends the review request.
• The Documentation Manager reviews the version and records the decision.
• The Project Administrator helps resolve access or workspace issues if reviewers cannot open the version.

If the version is still being finalized, do that work first before starting the review cycle. The earlier preparation steps are covered in Preparing Versions for Final Approval. After you complete the review process described here, the next step is Preparing Versions for Review and Approval.