## Preparing to generate a new documentation version
Before you start a new version in Atloria, open your project workspace and go to the **Versions** area for that project. This is the main place where you review existing versions, check their current status, and start a new generation run. If you are not already comfortable moving around the project workspace, use [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces) for navigation help and [Managing Project Version Workspaces](doc:managing-project-version-workspaces) for version-specific layout details.

Take a moment to decide exactly what source the new version should represent. Your team may generate from a branch, a release snapshot, a revision, or another source option shown in the version form. In Atloria, the source you choose affects what content is pulled into the generated version, so make sure you are using the same source your team expects for review or release. If your project uses connected repositories or structured onboarding settings, confirm those details before you click the version action.

Choose a version name that will stand out in the **Versions** list. A clear label makes it easier to find later during review, comparison, and approval. Use the same naming style your team already uses so reviewers can quickly tell whether the version is an internal draft, a release candidate, or a release-targeted build. This matters when several versions appear close together in the list.

Also confirm the intended stage of the version before you generate it. In practice, that means deciding whether this run is only for internal checking, for formal review, or for release preparation. If you need a refresher on lifecycle expectations and status planning, see [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness).

[SCREENSHOT: Project Versions screen showing existing versions and the action used to create a new version]

## Creating a documentation version
1. Open your project in Atloria and go to the **Versions** screen.

2. Click the action your workspace uses to start a new version, such as **New Version** or **Generate Version**. This opens the version form where you define what Atloria should generate.

3. Enter the **Version Name** exactly as you want it to appear in the versions list and later review steps. Pick a name that clearly identifies the release, milestone, or review cycle.

4. Complete the source selection fields shown on the form. Depending on how your project is set up, Atloria may ask you to choose a branch, release tag, source revision, or similar source reference. Select the source that matches the content snapshot you want documented.

5. Review any generation options available on the screen. These options may indicate whether the version is meant for internal review, broader review, or release preparation. Choose the option that matches your team’s workflow so the version enters the right path after generation.

6. Submit the form to start the generation run. After you save or confirm, Atloria returns you to the **Versions** list or opens the new version record.

7. Confirm that the new version appears in the list with an early processing state such as **Queued** or **In Progress**. This is your first sign that the request was accepted.

If the version does not appear right away, refresh the **Versions** screen and look again. You should see the new entry with its name, current status, and updated timing details. For a broader walkthrough of starting versions, see [Generating New Documentation Versions](doc:generating-new-documentation-versions).

[SCREENSHOT: New Version form with version name, source selection, and generate action]

## Monitoring generation progress
1. Stay on the **Versions** list after starting the run, or open the new version’s detail page from the list. Atloria uses the version status to show where the run currently stands.

2. Watch for status changes as the version moves through processing. Typical progress states include **Queued**, **Generating**, **Completed**, or **Follow-up Required**. These labels tell you whether Atloria is still working, finished successfully, or found something that needs attention.

3. Refresh the page or reopen the version record if the status has not changed for a while. The version detail view is the best place to check the latest processing state, updated timestamps, and any recent activity tied to the run.

4. Review any visible status messages, activity entries, or log-style details on the version page. These messages help you understand whether Atloria is still building the version, validating the output, or stopping because of a warning or failure.

5. Pay attention to timing. If a version remains in **Queued** or **Generating** much longer than other recent runs in the same project, that is a sign to investigate further.

A healthy run usually shows steady movement from the initial state to a finished state. If you need a deeper explanation of progress tracking and result timing, refer back to [Monitoring Version Generation Progress and Results](doc:monitoring-version-generation-progress-and-results). That guide covers the status flow in more detail, so this page can stay focused on what to do while you are actively generating a version.

When a version appears stalled, compare its latest timestamp with the last visible activity entry. If the time is old and no new messages appear after refreshing, treat the run as needing attention rather than assuming it will finish on its own.

[SCREENSHOT: Version detail page showing status, timestamps, and processing messages]

## Reviewing generation results before approval or release
Once a version reaches a finished state, open its detail page or results area and read the final status before passing it to reviewers. In Atloria, a completed run is not automatically ready for approval or release. You need to check what kind of completion you received and whether any warnings or validation issues were recorded.

Start with the top-level result indicators: final status, completion time, and any links to the generated output. A status of **Completed** usually means the version finished processing, while **Follow-up Required** means Atloria found issues that still need action. If warnings are shown, read them carefully instead of assuming they are harmless. Some teams allow warning-level results for internal review, while others require a completely clean result before a version can move forward.

Use the result details to decide what should happen next:

- If the version completed cleanly, it may be ready for reviewer handoff.
- If the version completed with warnings, decide whether those warnings are acceptable for the current stage.
- If validation failed or follow-up is required, hold the version back until the issue is understood.
- If the generated output does not match the intended source, plan to regenerate rather than forcing the current version through review.

Compare what you see on the version record with your team’s release criteria. If your process requires a clean generation result before approval, do not send a warning-heavy version into the review queue. For comparison guidance after generation, use [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness) and [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review).

[SCREENSHOT: Completed version showing final status, completion time, warnings, and generated output links]

## Handling versions that need follow-up
When a version shows **Follow-up Required**, open the warning or error details first. In Atloria, that status means the run finished with issues that block normal progress. The details on the version page help you determine whether the problem is related to missing content, validation checks, broken links, or generation settings.

Use those details to decide the next action. If the issue points to the source content itself, update the affected documentation pages, screenshots, or linked material before trying again. If the problem appears tied to how the version was generated, return to the version setup and correct the source selection or generation options. In some cases, the cleanest approach is to create a replacement version rather than trying to advance the current one through review.

Make the reason visible to others working in the project. If Atloria provides notes, comments, assignments, or status updates on the version record, use them so reviewers know why the version is blocked and who is handling the fix. This prevents someone from treating a blocked version as ready simply because it appears in the versions list.

After the issue is corrected, start a new generation run and monitor it until it finishes. Then compare the new result with the earlier failed or warning-heavy run. You want to confirm that the follow-up state is gone and that the new version reflects the intended source and output.

If your team needs a structured handoff after the fixes are complete, continue with [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions) once the version is clean enough to move forward.

[SCREENSHOT: Version with follow-up required status and visible warning details]

## Common issues and how to fix them
A few generation problems appear often in Atloria, and the fix usually starts on the version record itself.

- **The version stays in Queued or Generating too long**  
  Open the version detail page and refresh it to check whether the status, timestamp, or activity messages have changed. If nothing updates, review any visible processing messages or log details. Compare the run with other recent versions in the same project. If this run is clearly not progressing, stop treating it as active and investigate before starting more review work around it.

- **The version finishes with warnings**  
  Read each warning on the results panel. Decide whether the warning is acceptable for the current stage. A version that is good enough for internal review may still be unsuitable for release preparation. If the warning affects content quality, validation, or output trust, fix the source and regenerate.

- **The version cannot move toward release after generation**  
  Check the final status and any validation-related messages on the version page. A generated version may still be blocked if required checks did not pass or if the version is not in the right state for approval. Review your team’s release criteria before sending it forward.

- **A regenerated version still shows Follow-up Required**  
  Compare the latest run with the earlier run side by side in the **Versions** list or by opening both version records. Confirm that you actually changed the source content or generation settings before rerunning. If the same issue appears again, the original cause was probably not resolved.

For more help deciding whether a version is acceptable after generation, use [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons).

## Overview
Atloria’s version generation workflow centers on one practical goal: create a documentation version from the right source, watch it move through processing, and decide whether the result is ready for review or needs more work. The **Versions** screen is where that work begins and where most follow-up happens. From there, you can start a new version, track its status, open the detail page, and review the final outcome.

The most important statuses to recognize are the early processing states and the final result states. Early states such as **Queued** and **Generating** tell you Atloria has accepted the request and is working on it. Final states such as **Completed** and **Follow-up Required** tell you whether the version can continue through the release workflow or needs intervention first. Those labels are not just informational—they determine whether the version should move to review, be held for fixes, or be replaced with a new run.

This guide focuses on the moment where generation and monitoring overlap: you are not just creating a version, you are actively checking whether the run is healthy and whether the result meets your team’s standards. It does not repeat the deeper status-reading guidance from [Monitoring Version Generation Progress and Results](doc:monitoring-version-generation-progress-and-results), and it does not go deep into comparison decisions that belong in the next stage.

Use this page when you need to move from “start a version” to “judge the result.” If your version completes successfully and you are ready to evaluate changes between runs before a release decision, continue with [Comparing Version Changes for Release Decisions](doc:comparing-version-changes-for-release-decisions).

## Prerequisites
Before working through version generation in Atloria, make sure these basics are already in place:

- You can sign in to Atloria and open the correct project workspace.
- You can reach the project’s **Versions** area and view existing version entries.
- You know which source the version should be generated from, such as the branch, release tag, or revision shown in your project’s version form.
- You know your team’s version naming pattern so the new entry is easy to identify in the **Versions** list.
- You understand whether the version is being created for internal review, review handoff, or release preparation.
- You have already learned how to read generation progress and result states at a basic level from [Monitoring Version Generation Progress and Results](doc:monitoring-version-generation-progress-and-results).
- If your team uses connected project sources or structured onboarding settings, those project details are already configured and available in the project workspace.

It also helps to have a clear release context before you begin. If several versions are active at once, confirm which one should move forward so you do not generate from the wrong source or attach the wrong label. When the versions list contains many similar names, reviewers can easily pick up the wrong record unless naming and timing are clear.

If you are still getting familiar with project-level navigation, review [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Managing Project Operations Across Project Home Tabs](doc:managing-project-operations-across-project-home-tabs) before starting a new generation run.