Coordinating Version Work Before Release

Confirming access and release prerequisites

Before you start release preparation in Atloria, make sure you can open the project workspace and switch to the correct documentation version in the version selector. The version you plan to release should already exist and should be the team’s chosen release candidate, not an older draft or a version still being evaluated. If you need help deciding whether the version is actually ready for release work, use Managing Project Version Timelines and Status Decisions before continuing.

Check that the parts of Atloria you need are available to you in the interface. For this workflow, you should be able to:

• open the version workspace
• start Generate or Regenerate
• open the Compare Versions view
• review changed pages
• update screenshots where needed
• open version visibility or access settings
• view available export options

If one of those actions is missing from the page, stop here and ask an administrator or project owner to confirm your access.

You should also confirm that the source content for this release is stable enough to build. In practice, that means your team has already agreed on the content scope for the release candidate. If your project uses a selected branch, connected source, or a defined set of pages for generation, verify that everyone is preparing the same source before you run the build.

Before sign-off, most teams in Atloria check the same release items:

• content differences against the previous release
• screenshot updates on changed pages
• visibility and access settings
• export needs for reviewers, customers, or archive copies

Generating the release candidate version

Once the release candidate is confirmed, open that version’s details or workspace screen and start the build using Generate or Regenerate. Use Generate when the version has not been built yet, and use Regenerate after content, screenshots, or source settings have changed and you need a fresh output for review.

1. Open the project in Atloria and select the release candidate from the version selector.
2. On the version screen, click Generate or Regenerate.
3. In the build dialog, choose the scope shown for this run. If Atloria offers a choice such as all pages or only changed content, select the option your team uses for release review.
4. Confirm the action and watch the status indicator on the version screen.

During processing, the version may show a queued or in-progress state. Wait until the status changes to a completed state before you begin comparison or sign-off work. If you start reviewing too early, you may miss pages that have not finished rendering yet.

After the build completes, review the output summary carefully. Look for anything that suggests the release candidate is incomplete, including:

• failed pages
• missing images or other assets
• warnings tied to specific pages
• sections that did not generate as expected

If the output includes warnings, open the affected pages before moving on. A release candidate can look mostly complete while still hiding missing content in a few topics. It is better to catch those issues now than after reviewers begin approval.

Comparing the version against the previous release

After the release candidate finishes generating, open Compare Versions and set up the comparison using the new release candidate and the previous published version. This gives you a focused view of what changed between releases and helps you decide what needs review before approval.

1. Open the release candidate in Atloria.
2. Click Compare Versions.
3. Select the release candidate as the version to review.
4. Select the previous published version as the baseline.
5. Load the comparison results and review the page list.

Start with the page-level indicators. These usually help you spot which topics were added, removed, or modified. That high-level view is useful for assigning work to writers, reviewers, and approvers because it shows where the release changed most.

Next, open the detailed differences for pages that could affect release readiness. Pay close attention to:

• renamed pages that may confuse readers
• navigation changes that move or hide important topics
• missing generated sections
• broken or incomplete links
• pages that appear in one version but not the other

As you review, separate expected release changes from unexpected ones. Expected changes are the edits your team planned for this release. Unexpected changes are the ones that need correction, clarification, or a second review before approval.

If you need a deeper walkthrough of the comparison screen itself, use Working with Version Comparison Views. For this release workflow, the goal is not to study every small edit. The goal is to identify which differences are acceptable for release and which ones still block sign-off.

Reviewing pages and resolving screenshot updates

Once comparison results show which pages changed, open those pages directly from the comparison list and move through your team’s review process. Focus first on pages with major edits, navigation changes, or visual content, because those are the most likely to create release issues.

1. Open a changed page from the comparison results.
2. Review the page content in preview or the available review view.
3. Check whether the text, headings, links, and page structure match the intended release content.
4. Look for screenshot placeholders, image references, or screenshot status markers that suggest a visual needs attention.
5. Replace outdated screenshots where necessary.
6. Save the page or screenshot update, then regenerate the version if the updated visual does not appear immediately.
7. Mark the page or review task complete using the review controls your team uses in Atloria.

Screenshot review is especially important when the release includes interface changes. A page can have correct text but still mislead readers if the screenshot shows an older screen. When you replace a screenshot, confirm that the new image appears correctly in preview and fits the surrounding instructions.

Watch for these common visual problems:

• an old screenshot still appears after content changed
• the image is missing from preview
• the screenshot shows a different menu or button label than the text describes
• the screenshot was updated on one page but not on related pages

If your team tracks review progress inside Atloria, keep page statuses current as you work. That gives the documentation manager a clear view of what is finished and what is still waiting on content, screenshots, or approval. For more detail on managing screenshots across versions, see Managing Screenshot Workflows Across Projects and Versions.

Checking version visibility and export decisions before publishing

Before a version moves toward publishing, confirm that people can see exactly what they should see—and nothing more. In Atloria, this means checking the release candidate’s visibility and any page or portal access rules that affect who can open it during final review.

1. Open the release candidate version.
2. Review the version visibility settings and confirm whether it is limited to internal reviewers or available to a broader audience.
3. Check page-level restrictions or audience-related access rules if your project uses them.
4. Confirm that unfinished pages are not exposed through the release candidate view.
5. Open the export options for the version and review which formats are available.
6. Decide whether this release needs export output for review, sharing, or archiving.

A release candidate often needs tighter access than a published version. For example, reviewers may need access while general readers should not. Make sure the current settings match that stage of the workflow.

When reviewing exports, focus on what your team actually needs for this release. Depending on your setup, that may include:

• a PDF for stakeholder review
• an offline package for distribution
• another export option shown on the version screen

Do not treat export as automatic. If screenshots are unresolved, pages are restricted unexpectedly, or the latest generation includes warnings, those issues can affect export quality or completeness. Note those limitations clearly before anyone expects a final deliverable.

If you need a deeper review of access controls, use Managing Version Visibility and Reader Access. If you are deciding whether exports are ready, Controlling Version Sharing and Export Readiness is the best companion guide.

Fixing common release-preparation issues

Even when the workflow is clear, a few problems show up often during release preparation. In Atloria, the fastest way to recover is to trace the issue back to the specific version, page, or access setting instead of restarting the whole process.

If generation completes with warnings, open the build output and review the affected pages one by one. Warnings usually point to missing assets, incomplete content, or pages that did not render as expected. Correct the page content or replace the missing visual, then run Regenerate again so the release candidate reflects the fix.

If comparison results look incomplete, check the versions selected in Compare Versions. The most common mistake is comparing the release candidate to the wrong baseline. Make sure the baseline is the previous published version and confirm that both versions finished generation successfully. If one version is outdated or incomplete, the comparison will not be reliable.

If updated screenshots do not appear in preview or export, verify that you replaced the image in the correct page and version context. Then regenerate the version if needed. A screenshot may be updated in the library or page settings but still not appear in the rendered output until the version is rebuilt.

If reviewers cannot access the release candidate, recheck:

• version visibility settings
• reviewer permissions
• page-level restrictions
• audience or portal access rules that may hide the content

When a release issue affects approval timing, document the blocker directly in your team’s review workflow so others do not assume the version is ready. That is especially important when the problem is not obvious from the page list alone, such as a hidden access rule or an export that omits restricted pages.

Overview

Coordinating version work before release in Atloria means bringing several review tasks together around one release candidate. You are not just checking whether the version generated successfully. You are confirming that the generated output matches the intended release, that the differences from the previous published version are understood, that screenshots still match the content, and that access and export settings support the release plan.

This stage usually happens after your team has already organized the version workspace and made timeline or status decisions. If you still need to confirm where the version sits in the release process, refer back to Managing Project Version Workspaces and Managing Project Version Timelines and Status Decisions.

The key screens you will use in Atloria are:

• the version selector
• the version details or workspace screen
• Generate or Regenerate
• Compare Versions
• page preview and review views
• screenshot-related page controls
• version visibility settings
• export options

This workflow is most useful when the team is close to sign-off and needs a reliable way to catch release blockers before publishing. Instead of reviewing pages in isolation, you work from the release candidate outward: build it, compare it, inspect changed pages, refresh visuals, confirm access, and decide whether exports are ready.

The next document in this sequence is Generating Documentation Versions for Release Cycles, which goes deeper into running version generation as a repeatable release activity.

Prerequisites

Before you coordinate release work in Atloria, make sure the project and version are already far enough along for final preparation. This workflow assumes you are not creating a brand-new version from scratch and not doing early draft review. You are working with a version that already exists and is being prepared as the release candidate.

Use this checklist before you begin:

• You can sign in to Atloria and open the correct project workspace.
• The target version appears in the version selector.
• Your team has identified that version as the release candidate.
• You can use Generate or Regenerate for that version.
• You can open Compare Versions.
• You can review changed pages and page previews.
• You can update screenshots or coordinate with the person who manages them.
• You can review version visibility or access settings.
• You can open export options for the version, if exports are part of the release.

It also helps to have these decisions already settled:

• which earlier version should be used as the comparison baseline
• which source content belongs in this release
• who is responsible for page review
• who confirms screenshots
• who makes the final release or export decision

If those decisions are still unclear, release preparation can stall even when the version itself looks complete. In that case, return to Managing Version Lists Statuses and Comparisons or Understanding Version Lifecycle and Release Readiness before moving forward.