## Checking what makes a version shareable or export-ready
In Atloria, a documentation version is only ready for wider use when three separate controls line up on the version screen:

- **Access or visibility**
- **Review status**
- **Release or published state**

These controls work together. A version can look finished to your team and still not be ready for sharing or export if even one of those indicators is missing. Start from the project’s **Versions** area, open the version you want to use, and review the status details shown on the version page. You are looking for clear signs that the version is not limited to internal work, that review has been completed, and that the version has moved out of draft status.

This is different from basic collaborator access. A version that project members can open inside Atloria is not automatically ready for public sharing. Internal visibility only means people with project access can view it in the workspace. Public sharing requires a version setting that allows external access, and export workflows usually expect the version to be in a released or published state as well.

On the version details view, check for badges, labels, or status indicators that show:

| What to check | What it tells you |
|---|---|
| **Visibility / Access** | Whether the version is restricted to collaborators or available for broader sharing |
| **Review Status** | Whether the version is still pending review, in review, or complete/approved |
| **Release / Published State** | Whether the version is still a draft or has been released for downstream use |

If you already worked through [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export), use that validation process here as a quick pre-check. This guide focuses on changing the version so it becomes eligible, not just inspecting the current state.

[SCREENSHOT: Version details view showing visibility, review status, and release badges together]

## Setting access so the version can be shared with the right audience
1. Open your project in Atloria and go to the **Versions** list.

2. Select the version you want to share, then open its **Settings**, **Access**, or **Visibility** area on the version page.

3. Find the current access choice. In most cases, you will see a difference between a restricted option and a broader sharing option. Restricted access keeps the version available only to project members and collaborators inside Atloria. A public or share-enabled option allows the version to be used for external sharing.

4. Change the access setting to the option that matches your intended audience. If you plan to use a public link or another external sharing action, the version must no longer be limited to internal-only access.

5. Click **Save** or apply the change from the version settings panel.

After saving, return to the main version view and check the version toolbar or **Actions** menu. If the version is now configured for broader access, sharing actions such as a public link or external sharing option should become available or stop appearing disabled. If those actions are still unavailable, another requirement—usually review completion or release state—is still blocking the version.

Use access settings carefully. Changing a version from restricted to public affects who can reach that version once it is also released and approved for use. If your team is still deciding who should see which content, review [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) before making the change.

A good way to confirm the update is to compare the version’s access label before and after saving. The version should no longer show an internal-only or collaborator-limited state if you intend to share it outside the project workspace.

[SCREENSHOT: Version settings panel with access or visibility options and Save button]

## Completing review requirements before sharing or export
1. Open the version in Atloria and locate the **Review Status** area on the version page.

2. Check whether the version is marked as **Pending**, **In Review**, **Complete**, or **Approved**. A version that is still waiting on review work usually cannot be treated as ready for public sharing or export.

3. Look through the version’s review activity for anything still open. This can include unresolved feedback, comments that still need action, or approvals that have not yet been recorded.

4. Finish the remaining review work. Resolve outstanding comments, address requested changes, and complete the final approval step used by your team on that version.

5. Return to the version header or review panel and confirm that the status changes to the completed state your team uses for release-ready versions.

This step matters because Atloria separates content creation from release readiness. A version may contain all the right pages and still remain blocked if its review trail is incomplete. If the version still shows **In Review** or another unfinished state, Atloria continues to treat it as work in progress rather than approved documentation.

When you check the version after review, focus on the visible review indicator rather than assuming the work is finished. If comments were resolved but the final approval was never recorded, the version may still fail readiness checks. The same is true if approval was expected from a reviewer and that action has not been completed yet.

If you need a refresher on how review decisions affect release progress, see [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) and [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). Those guides cover the review workflow in detail; here, your goal is simply to make sure the version shows a completed review state before you try to share or export it.

[SCREENSHOT: Version review panel showing completed or approved status]

## Releasing the version so it can be used outside the draft workflow
1. Open the version details page and check the current state shown near the version name or in the status area.

2. If the version still shows **Draft** or another unreleased state, open the version toolbar or **Actions** menu.

3. Click **Release**, **Publish**, or the equivalent action available for that version.

4. Confirm the action if Atloria asks you to review the change before continuing.

5. Wait for the version page to refresh, then verify that the status badge now shows **Released** or **Published**.

This step moves the version out of the internal drafting workflow and into the state expected by external sharing and export processes. Even if the content is complete and approved, a draft version is usually treated as internal working material. That means export options may stay disabled, and public-facing actions may remain unavailable until the release state changes.

Release state does not replace access settings or review completion. These three controls are separate. For example:

- A **released** version with **restricted access** is still not ready for public sharing.
- A **public** version that is still in **draft** may still be blocked from export.
- A **review-complete** version that has not been **released** may remain unavailable in downstream workflows.

After releasing the version, check whether export-related actions appear in the version toolbar, action menu, or export flow. You should also see the updated released or published badge in the version details area. If the badge changed but sharing or export is still unavailable, go back and compare all three readiness indicators together.

[SCREENSHOT: Version page showing Publish or Release action and released badge after completion]

## Confirming that the version is ready for public sharing and export
Before you share a version outside your team or include it in an export workflow, confirm all three readiness requirements on the version page:

- **Access** is set to a public or share-enabled option
- **Review Status** is complete or approved
- **Release State** is released or published

Start with public-sharing readiness. Open the version and look at the toolbar or **Actions** menu. If the version is ready, sharing choices such as **Share**, **Public Link**, **External Access**, or a public view option should be available without warning messages. If those actions are missing or disabled, compare the version’s access label, review status, and release badge to find the missing requirement.

Next, test export readiness. Open the export workflow from the version page or the related export area in Atloria. A ready version should appear as a selectable version, not as a disabled item and not hidden from the list. If the version does not appear, or appears but cannot be selected, Atloria is still treating it as not ready for export.

Typical behavior when one requirement is missing:

| Missing requirement | What you will usually see |
|---|---|
| **Access still restricted** | Public sharing actions remain unavailable |
| **Review not complete** | Readiness warnings or blocked sharing/export steps |
| **Still draft / unreleased** | Export disabled, version unavailable in release-based workflows |

This final check is especially useful after you make several changes in a row. A version can be approved but not released, or released but still private. Confirming all three indicators together helps you avoid sharing the wrong version state.

[SCREENSHOT: Version actions menu with share and export options enabled]

## Fixing versions that still are not eligible to share or export
If a version still is not available for sharing or export in Atloria, check the visible status indicators one by one instead of retrying the same action.

- **Share option is unavailable**
  - Open the version’s **Access** or **Visibility** setting.
  - Make sure the version is not set to a private, internal-only, or collaborator-limited option.
  - Save the change, then return to the version toolbar and check whether public sharing actions are now enabled.

- **Export action is disabled**
  - Check the version state near the top of the version page.
  - If the version still shows **Draft** or another unreleased state, use **Release** or **Publish** first.
  - Reopen the export flow and confirm the version now appears as an eligible choice.

- **The version passed review work, but readiness still fails**
  - Look again at the **Review Status** label.
  - Make sure approvals were fully recorded and that unresolved comments or pending review items are no longer present.
  - If the review work is done but the status did not update to **Complete** or **Approved**, the version is still not ready.

- **The version is publicly visible but missing from export**
  - Compare the version’s release badge and readiness indicators in the details panel.
  - Public visibility alone does not guarantee export eligibility.
  - The version may still be unreleased or waiting on final review completion.

When troubleshooting, the version details panel is your best reference point because it shows the current state in one place. If you only check the share menu or only check the export flow, you may miss the actual blocker. For a more structured pre-check process, return to [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export).

[SCREENSHOT: Version details panel highlighting a missing readiness requirement]

## Overview
Atloria uses three visible version controls to decide whether a documentation version can move beyond internal workspace use: **access**, **review status**, and **release state**. You manage these on the version itself, not in a separate publishing screen. That means the version details page is the main place to confirm whether a version is still internal, ready for public sharing, or eligible for export workflows.

A version can be available to collaborators inside a project without being ready for external use. That is the key distinction in this workflow. Internal visibility only allows project members to work with the version in Atloria. Public sharing requires a share-enabled access setting, and export workflows usually depend on the version also being approved and released.

This guide focuses on the point where a version moves from “ready inside the team” to “ready for outside use.” You will use the version page to:

- Check the current **Visibility** or **Access** setting
- Confirm the **Review Status** is complete or approved
- Verify the version shows a **Released** or **Published** badge
- Test whether **Share** and **Export** actions are available

If you are still deciding whether the current settings are correct, review [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options) and [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access). If you already validated the current state and now need to make the version ready, the sections above walk you through the exact checks and changes to make on the version screen.

The next step in this sequence is [Preparing Versions for Public Access and Sharing](doc:preparing-versions-for-public-access-and-sharing), which focuses on getting a version ready for the public-facing experience after these readiness controls are in place.

## Prerequisites
Before you start, make sure you have the right version open in Atloria and that you can access its version details page.

- You can open the project’s **Versions** list and select the version you want to prepare.
- You can view the version’s current **Access** or **Visibility** setting.
- You can see the version’s **Review Status**.
- You can see whether the version is marked **Draft**, **Released**, or **Published**.
- You have permission in Atloria to update version settings, complete review actions, or use the **Release** or **Publish** action if your team requires those steps.

It also helps if the version content is already in a stable state. This guide does not cover editing pages, comparing version output, or running the full review workflow from the beginning. If you still need to finish those tasks, use these related guides first:

- [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness)
- [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions)
- [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review)

If you want to confirm the current state before making changes, use [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export). That guide is the best companion when you are unsure which readiness requirement is missing.

[SCREENSHOT: Project Versions list with a selected version ready to open]