## Checking which version you are preparing to share
Before you change any sharing or visibility setting in Atloria, start in the project’s **Versions** list and open the exact version you plan to release. This is especially important if your team keeps several versions in progress at the same time, such as a current public release, a review copy, and a draft for upcoming changes.

When the version opens, confirm the identifying details shown on the version screen:

- **Version name**
- **Status** badge
- **Last updated** details
- Any visible release or revision label tied to that version

These details help you avoid sharing the wrong entry. If the version still shows a draft-style status or appears to be an internal working copy, stop before changing access. A version that is still being edited can expose unfinished page content, incomplete navigation, or notes intended only for your team.

Next, review the version content itself. Open the pages included in that version and make sure the material you expect readers to see is already there. Check that recent edits, screenshots, attachments, and other published changes are included. If your team has already worked through release checks in [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness), use that as your reference point rather than repeating those checks here.

It also helps to confirm who is still working in the version. If Atloria shows editing access separately from viewing or sharing access, make sure you are not opening a version that is still reserved for internal updates. The safest approach is to share only the version whose name, status, and update details clearly match the release you intend external readers to open.

[SCREENSHOT: Versions list showing version name, status badge, and last updated details]

## Choosing the right access mode for readers
In Atloria, the version’s **Visibility**, **Access**, or **Sharing** settings determine who can open the version after you send a link or make it available outside your team. Before you switch anything on, compare the available access choices shown on the version screen.

A typical decision looks like this:

| Access mode | What it means for readers | Best used when |
|---|---|---|
| **Internal** | Only people with the right workspace access can open the version | Team review, editor collaboration, internal sign-off |
| **Restricted** | The version is shareable, but readers may still need permission or sign-in access | Controlled customer review or limited external sharing |
| **Public** | The version is available to external readers without internal workspace access | Published documentation meant for broad distribution |

If Atloria offers a **Share link**, pay attention to whether that link is simply a direct shortcut or whether it still respects sign-in requirements. A copied link does not always mean open public access. In a restricted setup, readers may still land on a sign-in screen or an access message if they are not allowed to view that version.

When you mark a version **Public**, treat that as a deliberate publishing decision. Depending on the project setup, the version may appear through a public documentation address or become available through a direct public link. If your team needs to control exposure carefully, verify the exact reader outcome in preview before distributing the link.

Also remember that project-level permissions and version-level visibility can work together. A **Project Administrator** may have broader control over who can access the project overall, while a documentation lead may only be adjusting the visibility of one version. If a visibility option does not behave as expected, check whether the project’s broader access rules are affecting the version you are preparing.

## Making a version publicly accessible or shareable
Once you have confirmed the correct version, open its **Settings**, **Visibility**, or **Sharing** area in Atloria. This is where you change how readers can access the version and where you usually find the controls for copying or managing a share link.

1. Open the version you want to release from the **Versions** list.
2. Select the version’s **Sharing**, **Access**, or **Visibility** controls.
3. Change the access mode from **Private** or **Internal** to the sharing state you want, such as **Restricted** or **Public**.
4. Click **Save**, **Update**, or the matching confirmation button so Atloria applies the new access setting.
5. Return to the sharing panel and copy the available **Share link** if you plan to send readers directly to that version.

After you save the change, stay on the version screen long enough to confirm the new state is actually shown. You should see the updated visibility reflected in the version details or sharing panel. If Atloria provides link controls, review the options carefully. Some versions may allow you to:

- **Copy** the current share link
- **Disable** a link that should no longer work
- **Regenerate** the link if the old one was distributed too widely
- Review whether the link remains active for future readers

If your handoff includes an export as well as a share link, do not generate the export too early. First confirm that the version is in the correct access state and that the visible content matches what readers should receive. That way, the downloaded file reflects the same release you are sharing in the browser.

[SCREENSHOT: Version sharing panel with visibility selector and share link controls]

## Reviewing what external readers will actually see
After changing access, switch from editor thinking to reader thinking. In Atloria, the safest way to do that is to use the version’s **Preview**, **Reader view**, or **Open shared link** action if it is available. This lets you inspect the version outside the editing workspace and catch issues before anyone else sees them.

1. Open the version’s **Preview** or **Reader view**.
2. If a **Share link** is available, open that link in a separate browser tab.
3. Review the version page by page as if you were an external reader.
4. Check the same link in a signed-out or private browsing window.
5. Confirm that the access result matches the sharing mode you selected.

As you review, focus on what readers actually experience:

- **Page titles** should be correct and easy to scan
- **Navigation** should show the expected sections in the right order
- **Images, screenshots, and embedded media** should load properly
- **Attachments** should appear where expected
- **Callouts and highlighted content blocks** should display cleanly

Just as important, confirm what readers should **not** see. Look for internal notes, draft labels, editor-only reminders, or unfinished sections that may still be present in the version. If the version was moved from internal review to public access too quickly, these details can slip through.

Testing in an incognito or signed-out browser window is one of the most useful checks because it shows the real outcome of the selected access mode. If the version is public, it should open as expected. If it is restricted, you should see the same sign-in or permission requirement that an outside reader would see. This is the fastest way to verify whether your sharing choice matches the intended audience.

[SCREENSHOT: Public or shared reader view of a documentation version]

## Confirming the version is ready for export and distribution
Before you send a link or export file to customers, stakeholders, or other external readers, run one final readiness check in Atloria. This step ties together the version’s visibility, reader experience, and release approval so you know the distributed copy matches the intended publication state.

Use a simple checklist based on the version screen and shared view:

- The correct **version name** is selected
- The **status** reflects a share-ready or release-ready state
- The chosen **visibility** or **access mode** is saved
- The **share link** opens with the expected reader outcome
- The **preview** matches the content you want to distribute
- Final content approval has already been completed by the right team members

If you are also exporting the version, compare the exported output with the browser preview. The headings, screenshots, attachments, and version-specific content should match what you just reviewed in the shared reader view. If they do not match, stop and regenerate the export only after the version has been finalized.

It is also worth checking whether the version label, publication date, or revision identifier is visible where readers will notice it. These details help recipients confirm they are looking at the correct release, especially when several versions may still circulate internally.

For team coordination, record who approved the release and where future corrections should be made if something needs to change after sharing. In practice, that usually means noting the approved version in your team’s release workflow and making sure any follow-up edits happen in the correct version rather than in a newer draft.

If you need a deeper review of reader outcomes after access is set, continue with [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes).

## Fixing common sharing and visibility problems
Most sharing problems in Atloria come from a mismatch between the version you intended to release and the access settings actually saved on that version. When a link or export behaves unexpectedly, go back to the version’s **Sharing**, **Access**, and **Preview** areas and recheck each one in order.

If a shared link opens an **access denied** message or a **sign-in** screen, the version is usually still using an internal or restricted access mode. Open the version’s sharing settings and confirm whether readers are expected to sign in. If they are not, switch the version to the correct public-facing option, save the change, and test the same link again in a signed-out browser window.

If readers are seeing an outdated version, return to the **Versions** list and verify that you copied the link from the correct version entry. Compare the **version name**, **status**, and **last updated** details. Then reopen the version and make sure the latest edits were saved and included before you copied the link.

If internal notes or draft content appear in the shared view, inspect the version page by page in **Preview** or **Reader view**. Remove content that was only meant for editors, and confirm that any draft-only markers are no longer present. This is especially important after moving a version from internal review to public access.

When the exported file does not match the browser preview, compare the export output against the current version state. A common fix is to finalize the version first, confirm visibility and content in preview, and then generate the export again. Treat the browser preview as the reference point for what external readers should receive.

## Overview
This guide focuses on the final preparation work you do in Atloria before a documentation version is shared outside your immediate editing team. The goal is not just to turn on public access, but to make sure the version readers open is the right one, shows the right content, and behaves the right way when accessed through a share link or exported file.

You will usually work across a few connected areas in the version workflow:

- The **Versions** list, where you choose the correct version entry
- The version **Status** and identifying details, which help confirm release readiness
- The version **Visibility**, **Access**, or **Sharing** controls, where you decide who can open it
- The **Preview**, **Reader view**, or shared link experience, where you verify the real reader outcome
- Any **Export** action tied to the version, if you are distributing a file as part of the release

This document assumes you have already handled the earlier release checks around sharing and export readiness. If you still need to review those decisions, go back to [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness). Here, the focus is narrower: preparing one version for public access or controlled sharing and confirming that external readers will see exactly what you intend.

Because Atloria supports both internal project workspaces and public-facing documentation experiences, a version can look correct inside the editor but still behave differently for outside readers. That is why this guide emphasizes checking the actual shared outcome, not just the saved setting.

## Prerequisites
Before you start preparing a version for public access or sharing in Atloria, make sure the basic release conditions are already in place. This helps you avoid changing visibility on a version that is still incomplete or not approved for distribution.

You should have the following ready:

- Access to the project’s **Versions** list
- Permission to open the version’s **Sharing**, **Access**, or **Visibility** settings
- A version that already contains the content you intend to share
- Final or near-final page updates, including screenshots, attachments, and navigation changes that should appear to readers
- Any required internal review or approval already completed for that version
- A reason for the release choice, such as internal review, limited external sharing, or public documentation access

It also helps if you can test the result from a reader’s perspective. For example:

- A separate browser window for opening the **Share link**
- A signed-out or private browsing session for checking public access behavior
- Enough time to compare the shared view with any exported output before distribution

If your team manages version access alongside audience planning, public navigation, or release approvals, keep those related decisions nearby while you work. You do not need to repeat those setup steps here, but you do need to confirm that the version you are sharing reflects them correctly.

Once these items are in place, you can move through the version’s sharing controls with confidence and verify the exact experience external readers will receive.