## Opening the version workspace and understanding what it tracks
In Atloria, you open the **documentation version workspace** from inside a specific project. This means the screen already reflects the project you came from, so the versions you see belong to that project only. If you were reviewing release planning in [Coordinating Version Statuses and Release Readiness](doc:coordinating-version-statuses-and-release-readiness), this workspace is where that planning becomes day-to-day version tracking.

Once the workspace opens, the page is centered around a **version list**. Each row represents one documentation version for the current project, such as a release branch, milestone, or planned documentation update. Teams use these versions to keep release-specific content organized without mixing draft work for one release into another. Instead of treating the whole project as one moving set of pages, Atloria lets you work version by version.

Across the workspace, users typically focus on four areas:

- The **version list**, where you see all versions in the current project
- **Status badges** or progress indicators that show where each version sits in the release workflow
- **Compare entry points**, used to check differences between one version and another
- **Review actions**, which let you move a version into review or open its review-related work

[SCREENSHOT: Documentation version workspace showing the project context, version list, status badges, compare option, and review actions]

Different roles usually read this screen in different ways:

- **Documentation Managers** scan the list for versions that are close to release and versions that are blocked
- **Project Administrators** use the same workspace to understand project-wide progress across multiple active versions
- **Technical Writers** usually focus on the versions assigned to them, checking whether content is still in drafting, already under review, or waiting for follow-up

Because the workspace stays tied to one project, it becomes the main place to monitor release progress without leaving that project’s documentation flow.

## Reading the version list to see release progress
The **version list** is the fastest way to understand how documentation work is moving across releases in Atloria. Each row represents one version, and the row-level details help you judge whether that version is still being written, already in review, approved, or held up somewhere in the workflow.

The most important item in each row is the **version name**. This tells you which release, milestone, or documentation branch you are looking at. Next to that, Atloria shows a **status badge** that summarizes the version’s current stage. This badge is the clearest signal when you are scanning the list quickly. A version in active writing looks different from one that is under review or already approved, so you can spot bottlenecks without opening each version individually.

Depending on the row, you may also see other progress signals tied to release readiness. These are used to help you answer practical questions such as:

- Which version still needs writer attention
- Which version is waiting on reviewer input
- Which version is ready for the next release checkpoint
- Which version should not be published yet

The list view is especially useful when several releases are active at the same time. Instead of opening versions one by one, you can compare their statuses side by side and identify which release branch needs attention first.

The workspace may also include controls that narrow what you see, such as **sorting**, **filtering**, or **grouping** options. Use these controls when the project has many versions and you want to focus on a specific release cycle or only versions in a certain stage.

[SCREENSHOT: Version list with version names, status badges, and row actions]

When you need deeper detail, open the row actions for a version. That is usually where you move from list-level monitoring into comparison or review work.

## Following version statuses from draft work to release-ready content
In Atloria, the version workspace acts like a release progress board. The **status** shown on each version tells your team what kind of work is expected next and who should take action. Rather than opening every version to understand its condition, you can use the visible status in the list to tell whether writing is still underway, review is in progress, approval is complete, or the version is blocked before release.

The usual flow moves from **drafting** into **review**, then toward **approval** and final release preparation. Even if your team’s pace differs from project to project, the workspace still shows the same core idea: a version advances through clear checkpoints before it is considered release-ready.

Here is how teams typically interpret the visible statuses:

- **Draft** or similar early-stage status means contributors are still writing, editing, or organizing content
- **In Review** means the version has moved beyond active drafting and is waiting on reviewer input or review completion
- **Approved** means the version has passed review and is generally ready for the next release checkpoint
- A **blocked** or incomplete state means something still needs attention before the version can move forward

These badges matter differently depending on your role:

- **Contributors** look for statuses that tell them whether they should keep editing or pause for review
- **Reviewers** look for versions already submitted and ready for feedback
- **Administrators and managers** look for versions that are stalled between checkpoints

When a status changes, the update appears directly in the workspace so the row reflects the latest stage. If a version does not seem ready to move forward, the status usually tells you where it is waiting:

- still in writing
- waiting for review
- waiting for approval
- not yet ready for final release preparation

This is why the workspace is so useful during release coordination. It gives everyone a shared view of progress inside the project, turning version tracking into something visible and easy to act on.

## Comparing versions to see what changed between releases
The **Compare** option in the version workspace helps you understand what changed between one documentation version and another. You usually start from a version row, a row action menu, or another compare entry point tied to the selected version. This keeps the comparison anchored to the project you are already working in, so you are always comparing versions from the same documentation set.

When you open comparison, Atloria lets you choose the two versions you want to review. In most cases, this means selecting a **source version** and a **target version**. Teams often use this to compare a current draft against the last approved or last published version. That makes it easier to validate whether the latest release work includes the expected updates before sending it forward.

The comparison view is designed to surface release differences clearly. Instead of manually opening pages side by side, you can review the version delta in one place. Atloria highlights content that was:

- **added**
- **removed**
- **modified**

This is especially helpful when a release includes many page updates and you need to confirm what actually changed. A documentation manager might compare the current release against the previous published version to confirm scope. A writer might compare a draft against the last approved version to double-check that required updates were included. A project administrator might use comparison before a release checkpoint to make sure the version reflects the planned release work.

[SCREENSHOT: Version comparison screen showing source version, target version, and highlighted changes]

Common comparison scenarios include:

- checking what changed since the last published version
- validating updates before starting or requesting review
- confirming that a release branch contains only the intended documentation changes
- reviewing whether a version is truly ready for approval

For a broader explanation of comparison decisions, see [Working with Version Comparison Views](doc:working-with-version-comparison-views).

## Starting reviews from the workspace and tracking review entry points
The version workspace is not only for monitoring progress. It also gives you direct **review entry points** so you can move a version from drafting into formal review without leaving the project context. These entry points may appear as a **button**, a **row action**, or a control connected to the version’s current status.

From the version list, start by locating the row for the version you want to review. Open the available action for that row and choose the review-related option. When you do this, Atloria carries the selected version with you into the review flow. That means you do not need to reselect the project or hunt for the correct release again—the review opens in the context of the version you started from.

This handoff is especially useful when several versions are active at once. Managers can move directly from scanning the list to opening review on the version that is ready. Writers can use the same entry point to submit work or check whether feedback is still pending.

Review availability usually depends on the current **status** of the version. In practice, that means:

- versions still being drafted may need more work before review can begin
- versions already in review may show review-related actions instead of a fresh submission option
- versions with pending feedback may need follow-up before they can move ahead
- approved versions may no longer need a review start action because they have already passed that checkpoint

[SCREENSHOT: Version row with review action and status badge]

This workspace-level review access helps teams coordinate handoffs cleanly. A writer can finish updates, open the review action from the same row, and move the version forward. A manager can later return to the list and immediately see whether that version is still under review, waiting on feedback, or already approved. For more detail on review decisions themselves, refer to [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions).

## Resolving common issues when versions, statuses, or comparisons do not look right
If something in the version workspace looks wrong, start with the project context shown in Atloria. Most issues come from being in the wrong project, comparing the wrong versions, or expecting a status change before the related review step is complete.

If the **version list is missing an entry** you expected to see, first confirm that you opened the workspace from the correct project. The version list only shows versions for the current project. If you are in the right project and the version still does not appear, check whether that documentation version has actually been created in that project yet.

If a **status badge does not match team expectations**, look at where the version is in the workflow. A version may still be waiting for review completion, approval, or another release checkpoint before the badge updates. For example, a team might think a version is ready, but the workspace can still show a review-related status until that stage is fully completed.

If the **Compare** option is unavailable or the comparison looks incomplete, make sure there are at least two valid versions available to compare. Then confirm that you selected the correct source and target versions. Many comparison problems come from choosing the wrong pair, especially when several similarly named releases exist in the same project.

If the **review action cannot be started**, check two things:

- whether the version is currently in a review-eligible state
- whether your Atloria access level includes permission to open the review workflow from the workspace

[SCREENSHOT: Version workspace with missing compare or review action highlighted]

When troubleshooting, it often helps to scan the row carefully for the **version name**, **status badge**, and available **actions** before assuming data is missing. If the release itself is progressing but the workspace still seems confusing, revisit [Coordinating Version Statuses and Release Readiness](doc:coordinating-version-statuses-and-release-readiness) to align your team’s expectations with the visible workflow stages.

## Overview
The documentation version workspace in Atloria gives you one project-focused place to monitor release progress and act on it. Instead of treating versions as separate, disconnected records, the workspace brings together the details your team uses most often: the **version list**, **status badges**, **comparison tools**, and **review entry points**.

At a glance, this screen helps you answer several important release questions:

- Which versions exist in this project
- Which versions are still being drafted
- Which versions are under review
- Which versions are approved or close to release
- Which versions need comparison before the team moves forward

This workspace is especially useful when a project has multiple active releases. A writer may only care about one assigned version, but a documentation manager or project administrator can scan the full list and quickly understand where work is moving and where it is stuck. Because the workspace stays tied to the current project, every action you take—whether opening a comparison or starting a review—happens in the right release context.

You will get the most value from this screen when you use it as a working dashboard rather than just a list. Open it regularly to:

- spot versions that are waiting on review
- identify versions that are ready for the next checkpoint
- compare release changes before approval
- keep project-wide documentation work aligned with release timing

If you need more detail on related tasks, use the linked guides for comparison, review, and release coordination rather than trying to do everything from memory. The workspace is where those tasks come together in one visible project view.

## Prerequisites
Before this workspace is useful, a few basics need to already be in place inside Atloria. You do not need advanced setup, but you do need the right project context and at least some version activity to review.

Make sure the following are true:

- You can open the relevant **project** in Atloria
- The project already has one or more **documentation versions**
- You have access to the project’s version workspace
- If you want to use **Compare**, the project has at least **two versions**
- If you want to start or follow **Review**, the version is far enough along in the workflow for review-related actions to appear

It also helps if you are already familiar with the earlier version guides, especially:

- [Managing Project Version Workspaces](doc:managing-project-version-workspaces)
- [Managing Project Version Timelines and Status Decisions](doc:managing-project-version-timelines-and-status-decisions)
- [Coordinating Version Statuses and Release Readiness](doc:coordinating-version-statuses-and-release-readiness)

Those guides explain the broader release planning context. This document focuses on how that work appears inside the version workspace itself.

Different users may approach the workspace with different expectations:

- **Technical Writers** should know which version they are responsible for
- **Documentation Managers** should know the release cycle they are monitoring
- **Project Administrators** should have access to the project areas where version progress is tracked

If you are ready to move from understanding the workspace to actively managing release movement through it, continue with [Managing Version Workspaces Statuses and Release Tracking](doc:managing-version-workspaces-statuses-and-release-tracking).