## Checking who can change version access
In Atloria, version access changes should be handled by the people who manage documentation releases for a project, typically a **Documentation Manager** or **Project Administrator**. If you can already work with project versions, review release settings, and manage project-level controls, you are usually the right person to update who can see a version. If those options are missing when you open a version, you may need someone with broader project access to make the change for you.

Before you look for any sharing or visibility setting, make sure the version already exists in the project. Open the project, go to the **Versions** area, and select the version you want to manage from the version list. You need to be on the version’s own details screen before you can review its access state. If you are still comparing drafts or waiting on approvals, it is better to confirm you are editing the correct version record first.

On the version details page, look for the area that controls **visibility**, **sharing**, or **reader access**. This is where Atloria lets you decide whether a version is broadly available, limited to a smaller group, or not shared at all. The exact wording may vary slightly depending on the project setup, but the control will be part of the version’s settings rather than the document editor.

It also helps to check whether the version is still being prepared or is ready for readers. A version that is missing pages, screenshots, approvals, or audience checks may technically be shareable, but it may not be ready to expose. If you need a refresher on how access modes affect readers, see [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes).

[SCREENSHOT: Version details page showing the visibility or sharing controls]

## Choosing the right access mode for a version
When you choose a version access mode in Atloria, you are deciding two separate things: whether people are allowed to read the version, and whether the version is easy for them to find. That difference matters. A version can be readable through a direct link while still being kept out of general browsing areas such as version selectors or navigation.

The most common access choices can be understood like this:

| Access mode | What readers can do | Where it may appear |
|---|---|---|
| Fully visible | Readers can open and use the version normally | May appear in navigation, version selectors, and shared entry points |
| Restricted | Only approved or permitted readers can open it | May be limited in discovery, even if a direct link exists |
| Not shared | Readers cannot access the version | Does not appear as an available version for general readers |

Use **fully visible** when the version is ready for normal reading and should be available as part of the project’s published documentation experience. This is the right choice when the content has passed review and you want readers to discover it naturally.

Use **restricted** when the version needs a controlled release. This is useful for internal review, stakeholder sign-off, or limited testing before wider publication. In this mode, you can allow access without making the version broadly discoverable.

Use **not shared** when the version is still in preparation, contains incomplete material, or should remain hidden until release day.

If you need more detail on visibility and export decisions, refer to [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness) and [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access).

## Updating version visibility and saving the change
1. Open your project in Atloria and go to the **Versions** list.

2. Find the version you want to update and open its version details page. Make sure you are changing the correct version, especially if several versions have similar names or are in review at the same time.

3. In the version settings area, locate the current **visibility**, **sharing**, or **access** setting. Atloria shows the current state on the version record, so you can confirm whether the version is already visible, restricted, or not shared before making changes.

4. Select the access mode that matches your goal:
   - Choose the broadest option when the version is ready for normal reader access.
   - Choose a restricted option when you want limited review or controlled sharing.
   - Choose the hidden or unshared option when the version should not be available yet.

5. Save the change using the available action on the page, such as **Save**, **Update**, or the version publishing control if the screen combines release and access settings. Do not leave the page until the save finishes and the updated state is shown.

6. Check the version record again after saving. Atloria should display the new access state on the page so you can confirm the change took effect. If the old state still appears, refresh the page and verify that the update was actually stored.

7. If the version is meant for immediate reader use, test the outcome from the reader side by opening the version through the same entry point your audience will use, such as version switching or a shared link.

[SCREENSHOT: Version settings panel with the access mode selected and saved]

## Understanding what readers experience in each sharing state
Reader experience changes noticeably depending on the version’s sharing state. When a version is fully available in Atloria, readers can open it normally and move through the documentation without interruption. If the version is intended for general use, it may also appear in places readers expect to browse, such as version selectors, navigation choices, or other visible version entry points.

Restricted versions behave differently. A reader might receive a direct link, but if they do not have the right access, Atloria does not simply show the content. Instead, the reader is blocked from opening the version and sees an access-related message or unavailable state. This is important for controlled release because it lets you share a link structure without exposing the documentation itself to everyone who receives it.

Hidden or unshared versions are generally not discoverable. Readers should not expect to find them in search, navigation menus, or version switchers. If a version is intentionally kept out of discovery, that does not always mean it is broken. It may be readable only in a limited way, or it may be completely unavailable until release. This is why “readable” and “discoverable” should be treated as separate decisions when you manage access.

Atloria’s unavailable and access-denied states help readers understand what happened. Instead of silently failing, the interface signals that the version is either restricted, not currently shared, or not available to that reader. If you are planning a staged release, this behavior is useful because it prevents confusion while still protecting in-progress content.

For a broader explanation of reader outcomes, see [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes).

## Preparing a version for sharing or controlled release
Before you expose a version to readers, review whether the content is actually ready to be seen. In Atloria, that means more than checking whether the version exists. Open the version details page and confirm the version includes the pages, updates, screenshots, and audience-facing material you expect readers to see. If the version is part of a release process, make sure internal review is complete and any required approvals have already been handled.

A restricted access mode is the safest choice when stakeholders need to validate the version before public release. This lets you share the version with a smaller group without placing it into normal reader discovery. It is especially useful when teams need to check wording, structure, screenshots, or release timing in a near-final state.

You should also coordinate the visibility change with your release schedule. If you make a version broadly visible too early, readers may encounter incomplete material, outdated screenshots, or pages that are still being revised. Keeping the version restricted until the planned release time helps avoid accidental exposure.

When the review group confirms the version is ready, return to the version’s access setting and move it from restricted access to a broader visible state. This final switch should happen only after the version has passed internal review and is ready for normal reader traffic.

If you are still checking whether a version is safe to expose, use [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export) alongside your release review process.

[SCREENSHOT: Version details page reviewed before switching from restricted to visible]

## Fixing common access and sharing problems
If a version does not appear for readers after you shared it, start by reopening the version details page and checking the saved access setting. In Atloria, the most common issue is that the intended visibility change was selected but not actually saved. Confirm the version record now shows the expected state. If it still shows the old state, save the change again and refresh the page.

If readers can open a link but see an access error, the version is likely still in a restricted state or limited to a smaller set of people than expected. Review the version’s sharing setting and confirm whether the audience you are testing with should truly have access. A direct link does not override restrictions. Atloria will still block readers who are outside the allowed group.

If a version becomes visible too early, go back to the version settings immediately and switch it to a more limited state, such as restricted or not shared. This removes broad exposure while you finish review. After saving, test the version again from the reader side to confirm it no longer appears where it should be hidden.

If the expected version is missing from selectors, menus, or navigation, do not assume the version is unavailable. It may still be readable through a direct link while intentionally hidden from discovery. Check whether the version was set to be accessible without being broadly listed.

When troubleshooting, compare what you expected readers to see with where they are trying to access the version:
- **Direct link works, but version is not listed:** likely hidden from discovery
- **Link opens an access message:** likely restricted
- **Version is missing everywhere:** likely not shared or not saved correctly
- **Version appears too broadly:** visibility is set wider than intended

The next step is [Validating Version Access Before Public Release](doc:validating-version-access-before-public-release).

## Overview
This guide focuses on the practical side of managing version access outcomes in Atloria after you already understand the basic access modes. Instead of repeating the definitions covered in [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes), this document shows how to apply those choices on a real version record and how to predict what readers will experience once the change is live.

The main tasks covered here are:
- Checking whether you are the right person to change a version’s visibility
- Opening the correct version from the **Versions** list
- Choosing between visible, restricted, and not shared states
- Saving the updated access setting on the version details page
- Confirming whether readers can discover the version, open it directly, or are blocked
- Correcting common mistakes when a version appears too early or does not appear at all

This topic is especially useful when you are managing staged releases. In many Atloria projects, a version is not simply either “published” or “unpublished.” You may need to let a small review group open the version first, keep it out of version selectors until launch, or temporarily remove it from reader view while updates are still in progress. Those are the sharing outcomes this guide helps you manage.

Use this document when you are actively changing a version’s exposure and need to confirm the result from a reader’s point of view. If you are still deciding whether the version is ready for exposure at all, pair this guide with your version review and release checks.

## Prerequisites
Before you work through version access changes in Atloria, make sure the following are already in place:

- You can sign in to Atloria and open the correct project workspace.
- The project already has at least one existing version in the **Versions** list.
- You have access to version-level settings, typically as a **Documentation Manager** or **Project Administrator**.
- You know which version you are updating and whether it is meant for internal review, limited sharing, or broader reader access.
- The version has reached a point where sharing decisions make sense, even if it is still restricted for review.
- You understand the difference between a version being readable and being discoverable. If needed, review [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes).

It also helps to have these decisions ready before you open the version settings:
- Whether the version should appear in normal reader browsing
- Whether only a limited group should be able to open it
- Whether the version should stay hidden until a planned release time
- Whether you need to test the result using a direct link or reader-facing navigation

If your team is still reviewing content quality, approvals, or release timing, you may want to pause before changing visibility. In that case, review your version readiness process first and return to this guide when the version details page is ready for an access update.