Managing Version Workspaces Statuses and Release Tracking

Understanding version workspaces and where status appears

In Atloria, a version workspace is the working area for one documentation version inside a project. This is the screen your team opens when you need to review the current version label, check whether the version is still being edited, or confirm whether it has already moved into review or release. The most useful cues are usually at the top of the workspace: the workspace header, the version identifier, and the status badge. Together, these let you understand the state of the version without opening separate review screens.

You will also see status information repeated in other places so you can track progress from list views. Teams commonly open a workspace from a version list, from a version or document detail page, or from a release tracking view that shows several versions together. In each of these places, the current status helps you decide what to do next. For example, a workspace that still shows an editable working state is usually where a writer continues updating content, while a workspace marked as review-ready signals that the version should be checked before release. A released state tells the team that the version has already reached its publication milestone.

Different roles look at the same workspace for different reasons:

• Technical Writers focus on whether the workspace is still open for editing.
• Documentation Managers look for review-ready versions and confirm whether the status matches the actual review stage.
• Project Administrators use the status badge and version label to watch release timing across multiple versions.

If you need a refresher on how the workspace itself is organized, see Understanding Documentation Version Workspaces.

Moving a workspace through its status progression

1. Open the version workspace from the version list, the version detail page, or a release tracking view.

2. Look near the top of the workspace for the current status control. Depending on the screen, this may appear as a Status dropdown, an action menu, or a workflow button that lets you move the version to its next stage.

3. Review the current state before making a change. In most teams, the normal progression is:

   • an active editing state while content is still being updated
   • a review-ready state when the draft should be checked
   • a released or release-tracked state when the version is approved for release monitoring or has already been released

4. Choose the next status that matches the work that has actually been completed. For example:

   • Move from the editable state to a review-ready state when the pages, screenshots, and version content are ready for review.
   • Move from review-ready to a released or tracked release state when review is complete and the version should be treated as part of the release process.

5. Confirm any prompts that appear. Atloria may prevent the change if required workflow conditions have not been met or if your role does not allow that transition. If a required action is missing, finish the missing work first or ask someone with the right access to complete the change.

After the update is accepted, the new status should appear right away in the workspace header. You should also see the same updated status in version lists and release tracking views. That immediate visibility is important because it tells the rest of the team that the handoff has happened.

If you are managing timing and readiness across several versions, pair status updates with the guidance in Managing Project Version Timelines and Status Decisions.

Comparing workspace versions from the available entry points

1. Start from the place where you already see the version you want to review. In Atloria, comparison tools are typically reached from:

   • a compare action on a workspace record
   • row actions in a version list
   • release tracking views that let you open a comparison directly from a tracked version

2. Select the versions you want to compare. Atloria may present these as source and target selectors, a baseline and current version choice, or side-by-side compare controls. Choose carefully:

   • Use the earlier or released version as the baseline when you want to measure what changed.
   • Use the current workspace as the target when you want to review the latest edits.

3. Open the comparison view and review the differences shown on screen. This view is most useful when you need to answer practical release questions, such as whether the version includes only expected updates or whether important pages changed since the last approved version.

4. Use the results to decide what should happen next. Comparison views help teams spot:

   • changed pages
   • modified content
   • differences between the current workspace and a released version

For Technical Writers, the comparison view is a final check before moving the workspace into review. For Documentation Managers, it is often the fastest way to confirm whether a review-ready version is complete enough to advance. For Project Administrators, it helps explain why one version may still be held back while another is ready for release tracking.

If you need more detail on reading compare results, use Working with Version Comparison Views and Comparing Documentation Versions for Release Decisions.

Tracking releases across workspaces and versions

The release tracking view gives you a higher-level way to monitor multiple version workspaces at once. Instead of opening each workspace one by one, you can use this screen to scan version labels, current statuses, and release-related details together. This is especially useful when several versions are moving through editing, review, and release at the same time.

In Atloria, release tracking typically presents versions in a grid or similar overview. Teams use the visible columns and status indicators to answer three questions quickly: which versions are still being worked on, which are waiting for review, and which are already released. When release-related fields are shown alongside the version label and status, you can judge readiness more accurately than by status alone.

Common items users look for in the release tracking view include:

Project Administrators and Documentation Managers often narrow the list with filters or sorting so they can focus on versions that are in review, blocked, or already released. Grouped views are especially helpful when you need to separate active work from completed releases.

The release tracking view also acts as a navigation hub. When you spot a version that needs attention, open that record to jump back into the individual workspace. From there, you can update the status, review the version details, or launch a comparison. That connection between the high-level release view and the detailed workspace keeps status management practical instead of purely administrative.

Using statuses and release views to coordinate team responsibilities

Statuses are most useful when everyone on the team treats them as shared signals rather than personal notes. In Atloria, the workspace state tells each role when to act and when to wait. That makes handoffs cleaner, especially when writers, reviewers, and release owners all work in the same project.

A common responsibility pattern looks like this:

• Technical Writers

  • Work mainly in workspace detail pages
  • Keep the version in an active editing state while content is still changing
  • Use comparison views before handing work off for review

• Documentation Managers

  • Watch for workspaces that move into a review-ready state
  • Open comparison views to confirm what changed
  • Decide whether the version is ready to continue through the release process

• Project Administrators

  • Use release tracking views to monitor several versions at once
  • Check whether version statuses match release timing
  • Focus on versions that are blocked, late, or already released

The screens each role checks most often usually follow that same pattern:

• workspace detail pages for editing and direct status updates
• comparison views for review decisions
• release tracking dashboards for schedule oversight

Consistent status updates improve team coordination because they remove guesswork. A writer does not need to message a manager to say a draft is ready if the workspace clearly shows a review-ready state. A manager can see when a version is awaiting approval. An administrator can identify which versions belong to the active release window.

Access can also affect what each person can do. Some users may be able to open workspaces and compare versions but not change the status. Others may be able to manage release tracking records or move versions into release states. If an option is missing, it is often related to role permissions rather than a problem with the version itself.

For broader role setup, see Managing User Access and Administrative Permissions.

Fixing common issues with status changes, comparisons, and release visibility

When a version does not behave the way you expect, start by checking the screen you are on and the exact version you opened. Most problems with status changes, comparisons, and release tracking come from permissions, filters, or selecting the wrong version.

• The status control is unavailable or a transition option is missing

  • Confirm that your role is allowed to update version status.
  • Check whether the workspace still needs a required workflow step before the next status becomes available.
  • If the version appears locked or unavailable for editing, reopen the workspace and verify that the record is not being held by another process.

• The compare view does not show the differences you expected

  • Make sure you selected the correct source and target versions.
  • If the comparison is between a current workspace and an earlier version, confirm that you chose the right baseline.
  • Save your latest changes before opening the comparison again. Unsaved edits may not appear in the results.

• A workspace does not appear in release tracking

  • Clear or adjust active filters in the release tracking view.
  • Confirm that you are looking at the correct project and version set.
  • Check whether the workspace status qualifies it to appear in the release view you are using.

• Release tracking shows an outdated status

  • Refresh the workspace and confirm the status change was saved.
  • Return to the release tracking screen and refresh that view as well.
  • If the workspace header shows the new status but the release view does not, reopen the version from the tracking list to verify the latest record.

When the issue is specifically about review progression, Understanding Version Review Feedback and Follow Up can help you tell the difference between a blocked workflow and a simple status mismatch.

Overview

Atloria gives you several connected ways to manage documentation versions as they move toward release. The version workspace is where you check the version label, review the current status badge, and make status changes when the draft is ready to move forward. Version lists and release tracking views extend that same information across multiple records so you can monitor progress without opening each workspace individually.

The most important habit is to treat the workspace status as the shared signal for the whole team. Writers use it to show when editing is still active. Documentation Managers use it to identify versions that are ready for review. Project Administrators use release tracking views to line up version status with release timing. Because Atloria repeats status information in workspace headers, list rows, and release tracking screens, one update can immediately improve visibility for everyone involved.

Comparison tools are the bridge between editing and release decisions. When you open a compare action from a workspace, a version list, or a release tracking record, you can review what changed between the current workspace and another version. That makes it easier to decide whether the version should stay in editing, move into review, or advance toward release.

If you are working through the full version workflow, this guide fits best alongside:

• Managing Version Lists Statuses and Comparisons
• Coordinating Version Work Before Release
• Understanding Documentation Version Workspaces

Use those guides when you need more detail on list-level management, release coordination, or the workspace layout itself.

Prerequisites

Before you manage workspace statuses and release tracking in Atloria, make sure the following pieces are already in place:

• You can sign in to your Atloria account and open the main project area. If you need help getting into your account, use Signing In to Atloria and Solving Access Problems.

• You already have access to a project that contains documentation versions. This guide assumes you can open version workspaces from project views, version lists, or related release tracking screens.

• At least one version workspace already exists. If your team is still creating versions, review Managing Documentation Versions Across the Release Cycle or Generating Documentation Versions for Release Cycles.

• You understand the basic layout of a version workspace, including where the version identifier and status badge appear. If that screen is still unfamiliar, read Understanding Documentation Version Workspaces.

• Your role includes the actions you need. Depending on your permissions, you may be able to view a workspace but not change its status, open comparison tools, or manage release tracking records. If access seems limited, check with your Atloria administrator and review Managing User Access and Administrative Permissions.

• Your team has agreed on how statuses are used for editing, review, and release. Atloria can show the current state clearly, but the status labels only help if everyone uses them consistently.

If you are continuing through the Documentation Versions set, the next useful step is usually to return to your project and apply these status and tracking checks to the versions currently moving through review.