Managing Version Visibility and Reader Access

Understanding how version visibility controls reader access

In Atloria, version access is controlled at the individual version level, not only at the project level. That means a project can be available to readers, while a specific documentation version inside that project is still kept hidden or limited. This is the key difference to keep in mind when you are preparing releases: project sharing opens the door to the documentation space, but each version still has its own visibility and reader access settings.

A version can affect readers in two separate ways:

• whether the version is shown in places like the version selector or public navigation
• whether the version can actually be opened and read when someone tries to access it

These are related, but they are not always the same. A version might be readable through a direct link while still being less visible in public browsing areas, or it may be fully hidden so readers cannot discover or open it at all. Because of that, you should always check both discoverability and access before release.

In most teams, the people who change these settings are users with documentation ownership or project administration responsibilities, such as a Documentation Manager or Project Administrator, using the version settings area. If you can open a version’s settings and save access changes, you are working in the right place.

For public readers, these settings directly shape the reading experience. A hidden version may not appear in the version switcher, navigation, or public entry points. A restricted version may behave differently for anonymous visitors than it does for signed-in team members. Direct links can also be affected, so a bookmarked page may stop opening if the version is no longer readable.

If you already worked through Controlling Version Visibility and Export Options, think of this guide as the reader-facing side of that setup: not just whether a version is available, but exactly how people encounter it.

Opening a version and reviewing its current access settings

To review access for a documentation version, start in the relevant project workspace in Atloria and go to the documentation area where your versions are managed. Open the Versions list for the doc set you want to update, then select the version you want to inspect. Do not change settings from memory or from a comparison screen if you can avoid it—open the version’s own details page first so you can confirm its current state before saving anything.

1. Open the project that contains the documentation set you want to manage.
2. Go to the documentation area and open the Versions list.
3. Select the version record you want to review.
4. Open the version details page and find the version settings area.
5. Look for the controls related to visibility and reader access.

When you are on the version details page, review the current access state carefully. You are looking for whether the version is currently set to:

• Public for general reader access
• Restricted or limited to a narrower group
• Hidden from readers

This is also the right time to confirm you are editing the correct version. Teams often work with several releases at once, and it is easy to open a draft, a previous release, and a review build in the same session. Check the version name or label on the page before making changes.

If your team uses stakeholder reviews before public release, pay attention to whether the version is already visible in reader-facing areas. A version that is meant only for internal review should not be left in a public state by mistake. Likewise, if a release is supposed to be live, confirm that it is not still hidden from the public view.

Before changing anything, note the current setting so you can compare the before-and-after result in the public documentation view.

Choosing who can see and read a documentation version

When you update version access in Atloria, you are deciding both who can discover the version and who can open it. The version settings area typically gives you choices that map to three practical states: public visibility, limited reader access, and hidden status. Use these intentionally, because each one changes the experience for readers, reviewers, and internal team members.

Changing the reader access setting can affect different groups in different ways:

• Anonymous visitors may lose access to a restricted or hidden version even if they have an old bookmark.
• Signed-in users may see more than public visitors, depending on their role and whether the version is limited rather than fully public.
• Internal team members often continue to work with versions that are not meant for public readers.

This is where many teams make a common mistake: they assume that because the project itself is shared, every version inside it is automatically available. In Atloria, that is not a safe assumption. Project-level sharing and version-level visibility work together, and a project being accessible does not mean every version should appear in the version selector or open for public readers.

After you save a change, check the practical impact right away. Existing bookmarks may stop working for some readers. Direct links may still open for internal users but fail for anonymous visitors. The version switcher may add or remove the version from the visible list depending on the setting you chose. Treat every access change as something that can alter the public reading path, not just a background setting.

Checking how visibility changes affect the public reading experience

After saving a visibility change, confirm the result from the reader’s point of view. The safest way to do this is to open the public documentation view, or any available preview view, and test the exact version you just updated. Do not rely only on the version settings panel. A version can look correctly configured in its details page but still behave differently in navigation, search, or direct links.

1. Open the public documentation view or preview for the project.
2. Check the version dropdown or version selector.
3. Confirm whether the updated version appears exactly as intended.
4. Open the version and review the navigation menu and landing page.
5. Test a direct page link inside that version.
6. Repeat the check in a signed-out browser window if the version is meant for public readers.

As you test, focus on four reader-facing areas:

• Version selector: The version should appear only if you intend readers to switch to it.
• Navigation and landing pages: Menus and entry pages should expose only the versions you want people to browse.
• Direct links: Paste a known page link from that version into the browser and confirm whether it opens or blocks access.
• Search and cross-version discovery: If your team expects the version to be discoverable, confirm it is surfaced appropriately after the visibility update.

This step is especially important when replacing an older release with a newer one. Readers often arrive through saved links, search results, or links shared in messages. If the version is hidden, they may not find it in the version selector even if they previously used it. If it is restricted, some users may be able to open it while others cannot.

Use both an admin view and a reader view when possible. What you can see while signed in with elevated access may not match what a public visitor sees.

Preparing a version for release without exposing it too early

A version does not need to be public while your team is still checking structure, page order, screenshots, and links. In Atloria, the safest release workflow is to keep in-progress versions hidden until the content is stable enough for controlled review. This lets editors work freely without placing unfinished material in front of readers.

1. Keep the version in a hidden state while editors review content structure and internal links.
2. Open the version in project views to verify page order, navigation, and release content.
3. Move the version to restricted access when stakeholders need to review it before launch.
4. Collect feedback and make final adjustments.
5. Switch the version to public only when it is ready for readers.

This approach is especially useful when multiple versions exist at the same time. For example, you may have one live release, one stakeholder review version, and one draft in progress. By using hidden and restricted states carefully, you avoid exposing unfinished work in the public version selector or public landing pages.

Before the final release change, confirm two things:

• the intended default version is the one readers should land on first
• the visible version list matches the releases you want readers to browse

If an older release remains more prominent than the new one, readers may continue opening outdated documentation even after the latest version is technically available. The version list should feel intentional, not accidental.

This stage pairs well with the release controls described in Controlling Version Visibility and Export Options. That earlier setup helps you decide when a version is ready to move forward; this step makes sure readers do not see it before you mean them to.

Verifying your visibility configuration before release

Before you announce a release or share public links, do one final visibility check. This is where you confirm that the version is available to the right readers, hidden from the wrong ones, and behaving correctly in public-facing areas. Small differences between display visibility and actual read access can cause confusion if you skip this review.

If a version does not appear publicly, check these first:

• the version’s current visibility setting
• whether the project itself has sharing restrictions that still limit public access
• whether you saved the latest version settings before leaving the page

If readers can open a direct link but cannot find the version in navigation, compare the version’s display behavior with its read permission. In practice, this usually means the version is readable in some situations but not broadly exposed in the version selector or public menus.

If the wrong audience can access the version, test with more than one browser state:

• a signed-out browser window
• a standard non-admin account
• your normal admin or documentation manager account

This matters because elevated access can hide problems. A version may look public to you simply because your role allows you to see more than regular readers.

If changes do not seem to take effect right away, refresh the public documentation view and test again. Also reopen the version details page to verify the setting still shows the value you selected. If needed, save the access setting again and repeat the public check.

Your goal is simple: the version should be visible where you expect it, blocked where it should be blocked, and readable only by the audience you intended. The next step is Validating Version Access Before Sharing or Export, where you’ll test access more formally before sending links or exporting release content.

Overview

Use this guide when you need to control how a specific documentation version appears to readers in Atloria. The focus here is not general project sharing, but the version-level choices that decide whether a release is public, limited to a narrower group, or hidden from reader-facing areas.

This document covers how to:

• open a version from the Versions list
• review its current visibility and reader access settings
• choose the right access level for drafts, stakeholder reviews, and public releases
• test the result in the public documentation view
• confirm that navigation, direct links, and version switching behave as expected

This topic is especially important when your team manages several releases at once. A project may contain a current public version, an older release that still needs to remain available, and a newer version that should stay hidden until launch. In Atloria, those decisions are handled at the version level, so each release can have its own reader experience.

Use this guide after you have already worked through Controlling Version Visibility and Export Options. That earlier document helps you decide how a version should be handled operationally. This one helps you confirm what readers can actually see and open.

If you are preparing to share links, publish a release, or confirm access for reviewers, the sections below will help you check the exact screens and behaviors that matter most.

Prerequisites

Before you start changing version visibility in Atloria, make sure these conditions are already in place:

• You can sign in to Atloria and open the relevant project workspace.
• You have access to the documentation area for that project.
• You can open the Versions list and select the version you want to manage.
• Your role includes permission to update version settings, such as Documentation Manager or Project Administrator access.
• The version already exists and has enough content for you to test navigation, links, and public reading behavior.
• If you plan to test public access, you can open the public documentation view or preview for the project.

It also helps to have these items ready before making changes:

• the version name you intend to update
• at least one known page inside that version for direct-link testing
• a signed-out browser window or private browsing session for public checks
• a non-admin test account if you need to compare internal and reader access

If you are still deciding which release should be visible, or whether export options should remain limited, review Controlling Version Visibility and Export Options first. That gives you the release context you need before you fine-tune who can actually see and read the version.