Managing Version Lists Statuses and Comparisons

Opening a project’s version lists and understanding what each status means

In Atloria, version work happens inside a specific project, so start by opening the project you want to review. From the main workspace, go to the project area and open its version list. Before you click into any version, check the project name shown in the page header so you know you are looking at the correct project. This matters when several projects use similar version names.

Use the version list as your release tracking view. Each row represents one version and helps you scan the project’s progress at a glance. Look across the row for the version name, the creation date, and the status badge. Those three items tell you what the version is, when it was created, and how far it has moved through the documentation workflow.

The status badge is the quickest way to understand what you can do next:

• Draft or another early editing state means the version is still being prepared.
• In progress means content work is still active and the version is not yet ready for formal review.
• Review-ready or a similar review state means the version can be opened for checking and approval work.
• Released or Published means the version has moved beyond review and is being treated as a completed release state.

These badges help Documentation Managers and Project Administrators separate versions that still need writing or cleanup from versions that are ready for review decisions. If you already worked through release-cycle planning in Managing Documentation Versions Across the Release Cycle, this page is where that planning becomes visible day to day.

Reviewing version details and moving between status-driven workflows

Once you find the version you want, open its row to move from the list into the version’s detail page. This page gives you a closer view of that version’s current state and is the best place to confirm whether the version is still being prepared, already under review, or close to release.

1. Open the project’s version list.
2. Find the version by its name and status badge.
3. Click the version row to open its detail page.
4. Review the status shown near the top of the page.
5. Check any available output and review actions before deciding your next step.

The version detail page is where status starts to control your workflow. If the version is still in a draft or active editing state, you should treat it as work in progress. In that case, comparison results may be incomplete, and review activity may not yet be useful. If the version has moved into a review-ready state, the page becomes a launch point for formal checking and release decisions.

Technical Writers can use this page to answer a simple question before sharing anything: “Is this version ready for someone else to review?” If the status still shows active preparation, continue editing or wait for the version to advance. If the status shows review readiness, you can move into review and comparison work with more confidence.

Status also affects downstream tasks. A version that is still being prepared is usually not a reliable release candidate. A version that has reached review-ready status is much more useful for side-by-side comparison, approval discussions, and release tracking. When you use the detail page first, you reduce the chance of comparing unfinished work or sending reviewers to the wrong version.

Opening review pages for a version and checking review readiness

The review page is the handoff point between preparing content and asking others to evaluate it. You can usually reach it from the version list or from the version detail page, but before opening it, confirm that the version status supports review. If the version is still being edited, sending someone to review it too early can create confusion and unnecessary feedback.

1. Open the project’s version list.
2. Locate the version you want to review.
3. Check the status badge in the row or on the detail page.
4. If the status shows a review-ready stage, select the review action.
5. On the review page, confirm the version label and project context in the header.
6. Inspect the rendered output and any visible review context before sharing it with others.

On the review page, focus on the elements that support release decisions. First, verify that the page clearly shows the correct version. Next, read through the rendered output rather than relying only on the version name. This helps you confirm that the content matches the intended release stage. If the page includes review context or visible indicators tied to the version, use them to make sure reviewers are looking at the right material.

Documentation Managers often use this page as the formal checkpoint before approval tracking begins. Instead of reviewing scattered draft pages, they can send stakeholders to one version-specific review view. That makes it easier to align comments, confirm completeness, and decide whether the version is ready to move forward.

If the review option is not available, return to the version status first. In most cases, the version has not advanced far enough in the workflow yet. It is better to resolve that status issue before asking for review.

Comparing outputs between versions to see what changed

Comparing versions helps you answer a practical question: what changed between one release stage and another? In Atloria, use the compare action from the version list or the version detail page when you need to inspect changes before review, approval, or release planning.

1. Open the project’s version list.
2. Identify the first version you want to use as the starting point.
3. Select the compare action.
4. Choose the second version you want to compare against.
5. Open the comparison view.
6. Confirm the source version and target version shown at the top of the page.
7. Review the differences, paying attention to added, removed, and changed content.

Always pause on the comparison header before reading the results. If the wrong source and target versions are selected, the page may still show valid differences, but they will not answer the question you intended to ask. The version names in the comparison header are your final check that the diff reflects the correct release progression.

Use the comparison view to focus on meaningful output changes. Look for:

• New sections added for the upcoming release
• Removed sections that may affect existing readers
• Updated wording that changes instructions or product behavior
• Differences large enough to affect release notes or approval decisions

A common pattern is to compare a draft or in-progress version against the latest released version when you want to measure how much has changed since the last public release. Another useful pattern is comparing two review-ready versions in the same project when you need to understand which one is the stronger release candidate. In both cases, the compare view gives you evidence for release decisions instead of relying on memory or informal notes.

Using statuses and comparisons to track release readiness across a project

Version lists become much more useful when you read statuses and comparisons together. The status column tells you where each version sits in the workflow, while the comparison view tells you whether the content changes match what you expected for the release.

1. Open the project’s version list and scan the status column.
2. Separate versions into three groups: still being prepared, awaiting review, and likely release candidates.
3. Open the versions that appear closest to release.
4. Compare those versions against the latest released version or another review-ready version.
5. Use both the status badge and the comparison results to decide whether the version is ready to move forward.

When you scan the list, look for versions that remain in preparation longer than expected. Those versions may be blocked, incomplete, or simply waiting for someone to finish content updates. Versions in a review-ready state deserve closer attention because they are the most likely candidates for release decisions. Versions already marked as released or published give you a baseline for comparison.

Project Administrators can use one project’s version list to monitor several active release tracks at once. If one version is still in progress while another is ready for review, the list helps you spot where work is moving and where it has stalled. Documentation Managers can then open the review page to judge content quality and open the compare view to judge release completeness.

This combination is especially helpful when a version looks ready based on status alone but the comparison results show missing sections or unexpected removals. In that situation, the status may say “ready,” but the output still needs attention. Using both views together gives you a more accurate picture of release readiness than either one on its own.

Fixing common problems when statuses, reviews, or comparisons do not look right

When something feels off in the version workflow, start with the visible context on the screen: project name, version label, status badge, and the action you expected to use. Most problems come from opening the wrong version, checking the wrong project, or trying to review a version that is still too early in the workflow.

If the Review option is missing:

• Open the version detail page.
• Check the current status near the top of the page.
• If the version is still in Draft or In progress, treat that as the reason the review action is not available yet.
• Return after the version reaches a review-ready state.

If the comparison page shows unexpected differences:

• Reopen the compare action from the version list or detail page.
• Confirm you selected the intended source version and target version.
• Check the comparison header before reading the results.
• If the version names are not the ones you expected, start the comparison again.

If a version seems to be in the wrong release stage:

• Open the version detail page for that version.
• Review the current status shown there rather than relying only on memory.
• Confirm whether the workflow step that marks the version as ready has actually been completed.
• If the status still does not match the work already done, pause review or sharing until the version state is corrected.

If teammates are reviewing the wrong version:

• Ask them to check the project name in the header.
• Ask them to confirm the version label on the review page or comparison page.
• Compare that label with the version row in the project’s version list before continuing.

Overview

• This guide focuses on how to work with a project’s version list in Atloria after versions already exist.
• You use the version list to identify each version by its name, creation date, and status badge.
• Status badges help you quickly tell whether a version is still being edited, ready for review, or already treated as released or published.
• From the version list or a version’s detail page, you can open review pages and comparison views.
• Review pages help you confirm that a version is ready for formal checking and approval work.
• Comparison views help you see what changed between two versions so you can support release decisions with visible output differences.
• This guide does not repeat version planning basics covered in Managing Documentation Versions Across the Release Cycle.
• Use this guide when you need to:
  • monitor multiple versions inside one project
  • confirm whether a version is ready for review
  • compare release candidates against earlier versions
  • spot versions that appear stalled before release

Prerequisites

• You can sign in to Atloria and open the main authenticated workspace.
• You have access to at least one project that includes documentation versions.
• The project already contains version entries in its version list.
• You can open the project workspace and view version-related pages.
• If you need help getting into Atloria or moving through account screens, see Signing In to Atloria and Solving Access Problems and Understanding Account Entry Points and Session Navigation.
• If you need help finding the right project before working with versions, see Working with Project Lists and Dashboards.
• If you need a broader explanation of how versions fit into the release cycle, review Managing Documentation Versions Across the Release Cycle.

For the next step in this workflow, continue with Understanding Version Lifecycle and Release Readiness.