Skip to content
D
Documentation

Managing Project Version Workspaces

11 min readUpdated

Opening the project version workspace

In Atloria, the project version workspace is the main place to monitor documentation versions for a single project. Open your project from the main project area, then go to the section where versions are listed and managed. This workspace is most useful when you want one screen that shows version progress, current state, and the next page you may need to open.

When the workspace loads, look first for the version list. Each version appears as its own entry, making it easy to scan several versions without opening them one by one. Alongside the list, Atloria surfaces status information so you can quickly tell which versions are still being worked on, which are ready for review, and which have already moved further through the release process. You should also see action controls tied to each version or to the currently selected version, plus links that let you open the related comparison page or review page.

This workspace is especially helpful for Documentation Managers, Project Administrators, and Technical Writers who need to coordinate version work. Managers typically use it to track progress across multiple versions. Writers often use it to jump into the version that needs checking next. Administrators may use it to confirm the current state before making version-related decisions.

Use the project version workspace as your starting point when you are not yet sure which version needs attention. If you already know you need a detailed difference check, the comparison page may be the faster destination. If you already know a version is waiting for a decision, the review page may be more direct. For a refresher on how comparison views work, see Working with Version Comparison Views.

Reading the version list and status indicators

The version list is the quickest way to understand what is happening across your project’s documentation versions. Each row represents one version and gives you a compact summary before you open any details. In practice, this means you can scan the list to find the version you need, check its current state, and decide whether to open comparison or review next.

Start by reading each row from left to right. The version name or identifier tells you which release or documentation set you are looking at. Nearby, Atloria shows the current status for that version. These status indicators are important because they help separate versions that are still in progress from versions that are ready for review or already completed. If you are managing several releases at once, the status display is often the fastest way to decide where to focus.

The list may also include supporting details that help you confirm you have the right version before opening it. Depending on what is visible in the workspace, look for labels, badges, or other row-level markers that signal recent activity or a version that needs attention. These visual cues are useful when several versions have similar names or when one version is waiting on review while another is already further along.

A practical way to use the list is:

  • Find the version row that matches the release you are working on.
  • Check the status badge before opening anything.
  • Use any visible labels or activity markers to spot urgent items.
  • Open the next page only after confirming you selected the correct version.

If you need a broader explanation of how version states fit into the release cycle, refer to Understanding Version Lifecycle and Release Readiness and Managing Version Lists Statuses and Comparisons.

Moving between comparison and review pages

The project version workspace is designed to help you move into detailed version work without losing your place. Once you identify the correct version in the list, select that version and use the available link or action to open its comparison page. The comparison page is where you inspect differences tied to that version and confirm what changed before anyone makes a review decision.

  1. Open the project version workspace and locate the version you want in the version list.
  2. Check the version’s status so you know whether you should inspect differences first or go straight to review.
  3. Select the version and open the Comparison page to examine changes connected to that version.
  4. After checking the differences, use the workspace navigation options to move to the Review page for the same version.
  5. When you finish on either page, return to the version workspace and confirm you are still looking at the same version row.

In most cases, open the comparison page first when the version is still being checked, when you need to verify what changed, or when the status suggests work is still in progress. Go directly to the review page when the version is already at a stage where a decision is expected and the changes have already been examined.

The key benefit of using the workspace for navigation is that you do not need to back out to the broader project area each time. The version list keeps the current context clear, so you can move from one detailed page to another and then return to the same set of versions. If you want more detail on reading change views before making review decisions, see Working with Version Comparison Views.

Managing version actions from one workspace

One of the biggest advantages of the project version workspace is that it brings version actions together in one place. Instead of opening several pages just to confirm the state of a version and then act on it, you can review the version list, select the right version, and use the available controls from the same workspace.

Look for action controls near the selected version or within the version row itself. These controls are tied to the current version state, so the actions you see may differ from one row to another. For example, a version that is still in progress may offer different options than a version already under review or already completed. This helps prevent you from taking the wrong step at the wrong time.

A good workflow is:

  1. Select the version from the list.
  2. Read the visible status indicator before choosing any action.
  3. Use the available action control for that version.
  4. Wait for the workspace to refresh or update.
  5. Confirm the result by checking the version row again.

After an action completes, the clearest sign of success is usually an updated status badge or refreshed version details in the list. If the version moves to a new stage, that change should be reflected directly in the workspace. You may also notice that the available actions change immediately after the update, which is another sign that Atloria has accepted the change.

Because action availability depends on status, always check the version row first. If an option is missing, the current version state may not allow that action yet. This is one reason the workspace is so useful: you can see the version’s current state and the allowed next step together, without switching screens.

Keeping reviews organized across multiple versions

When a project has several active documentation versions, the workspace becomes the easiest way to stay organized. Documentation Managers and Project Administrators can use the version list as a live tracking board for the project. Instead of opening each version separately, they can scan statuses, identify which items are still active, and decide where attention is needed first.

The most effective approach is to treat the version list as your daily review queue. Versions that are still active stand out through their status display, while completed versions are easier to ignore once they no longer need action. If Atloria shows badges, labels, or row-level indicators, use those visual markers to separate items that need follow-up from items that are already settled.

Technical Writers can also work faster from this screen. A writer may start with one version that needs a comparison check, open the comparison page, return to the workspace, and then move to another version already waiting in review. Because the list keeps all versions together, it reduces the risk of working on the wrong release or forgetting which version is currently under review.

Helpful habits for multi-version work include:

  • Scan the full version list before opening any detailed page.
  • Use status indicators to group versions mentally into active, review-ready, and completed work.
  • Return to the workspace after each comparison or review task so the next step stays clear.
  • Check the version row again before taking any action, especially when several versions have similar names.

This workspace is the best central checkpoint before any version-related action. It gives you the current state, the available navigation, and the next likely step in one place. For release-stage decision-making after this point, continue with Managing Project Version Timelines and Status Decisions.

Fixing common issues when working with project versions

Most issues in the project version workspace come down to selecting the wrong project, viewing an outdated list, or trying to open a page that is not available for the version’s current state. The workspace itself usually gives you the clues you need, especially through the version row and its status indicator.

If a version does not appear in the list, first make sure you are in the correct project’s version area. It is easy to confuse similar projects when switching between workspaces. Once you confirm the project, refresh the workspace and check the version list again. If the version still does not appear, compare the visible versions carefully so you do not overlook a similar name.

If you cannot move to the comparison page or review page, check the selected version’s status before trying again. Some navigation options are only available when the version has reached the right stage. When the status suggests the version is still earlier in the process, Atloria may not show the next page link yet.

If an expected action is unavailable, the status is the first thing to inspect. The workspace only shows actions that fit the version’s current state. A version that is already completed, for example, may not offer the same controls as one still moving through review.

If the status looks outdated after you take an action, reload the workspace and recheck the version row. A refreshed list should show the latest state. Confirm the update by looking for:

  • A changed status badge
  • Updated row details
  • Different available actions
  • Access to the next page in the workflow

When you need help understanding whether a version’s current state should allow review activity, see Understanding Version Lifecycle and Release Readiness.

Overview

The project version workspace in Atloria is the central screen for managing version activity inside a project. It combines the version list, status indicators, action controls, and links to comparison and review pages so you can manage version work without jumping through unrelated screens.

Use this workspace when you need to:

  • See all project versions in one place
  • Check which versions are in progress, ready for review, or completed
  • Open the comparison page for a selected version
  • Move from comparison into review with less back-and-forth
  • Confirm whether a version action has updated the version’s status

This screen is especially useful when several versions are active at the same time. Instead of relying on memory or opening pages one by one, you can use the visible status display to decide what needs attention first. Documentation Managers often use it to monitor progress across releases. Project Administrators use it to confirm version state before taking action. Technical Writers use it to move quickly between versions that need comparison checks and versions already in review.

If you already know exactly which detailed page you need, you can open that page directly. But when you want a reliable starting point that keeps the current version context visible, the project version workspace is usually the better choice. It reduces context switching and helps you avoid acting on the wrong version.

For related tasks, you can revisit Working with Version Comparison Views. The next step after mastering this workspace is learning how version timing and state changes affect release decisions in Managing Project Version Timelines and Status Decisions.

Prerequisites

Before working in the project version workspace, make sure you have the basics in place so the version list and related pages are meaningful.

You should have:

  • Access to Atloria with permission to open the project you need
  • A project that already contains documentation versions
  • Familiarity with the project’s release naming so you can recognize the correct version in the list
  • A clear reason for opening the workspace, such as checking differences, reviewing progress, or confirming a version’s current state

It also helps if you already understand the earlier parts of the version workflow. In particular, you should be comfortable reading version lists and recognizing version states. If those areas are still new, review Managing Documentation Versions Across the Release Cycle and Managing Version Lists Statuses and Comparisons before relying on the workspace for day-to-day decisions.

If your goal is to inspect changes between versions, be ready to open the comparison page from the workspace. If your goal is to participate in review, make sure the version has reached a status that supports opening the review page. The workspace will help you confirm this by showing the current status and the actions or links available for that version.

You do not need to start from a comparison page or review page to use this guide. In fact, the project version workspace is the preferred starting point when you want to confirm the current state first and then decide what to do next.

Was this page helpful?

Download as PDF