Understanding Version Access Modes and Reader Outcomes

Identifying which access mode a version is using

In Atloria, start from the project workspace and open the version you want to review. The version settings area is where you confirm how that version is exposed to readers. If you already worked through Preparing Versions for Public Access and Sharing, use that same version configuration screen to verify the current access choice instead of setting it again from scratch.

When you review a version’s visibility setup, focus on whether the version is configured for:

• Internal-only access — available to signed-in team members inside Atloria
• Public access — available to readers outside Atloria through published documentation routes
• Mixed audience behavior — the same version is available, but what readers see depends on the audience rules applied to pages and navigation

The important point is that Atloria does not create separate copies of the same version for each audience. The same version can produce different reading experiences based on its visibility rules and audience filtering. That means the version home page and its nested document pages can behave differently for internal readers and public readers even though they come from the same release.

As you check the version, also confirm whether it is included in public navigation. A version can be publicly readable but still be hidden from menus. Documentation Managers and Project Administrators should verify both settings together:

• the version is allowed for public reading
• the version is listed in public navigation, if you want readers to discover it from menus

This matters on the version landing page and on deeper document links. A version may have a working public route while still being absent from the public version switcher or navigation tree.

Comparing what internal users and public readers can open

The clearest way to understand version access in Atloria is to compare the same versioned page as two different reader types:

• a signed-in internal user
• an anonymous public reader

Internal users usually have broader access through the project workspace, version lists, and internal navigation. Public readers only see what the version’s public settings and audience rules allow.

If a version is not publicly visible, a public reader who opens that version’s route should not get the same result as an internal user. Depending on the page and route, the public reader may see:

• no access to the version
• a missing page result
• a public fallback that does not expose the restricted version content

By contrast, internal users can still open that restricted version from inside Atloria and may also be able to reach it through a direct version link. This is especially important during review, approval, and pre-release checks, when a version is meant for internal use only.

Audience behavior adds another layer. Even when the version itself is public, a specific page inside that version may render differently depending on the audience view. In practice, that can lead to three outcomes for the same page route:

• Full content appears for internal readers
• Limited public content appears for public readers when only part of the version is meant for them
• No page appears when that page is excluded from the public audience view

This is why checking only the version home page is not enough. A version can look public at the top level while some child pages remain hidden or filtered out for outside readers.

Following versioned routes and audience-specific page views

A versioned route in Atloria includes the version as part of the page address, which tells Atloria which documentation set to open. When a reader opens a version home page or a nested document page, Atloria first identifies the requested version and then decides what that reader is allowed to see for that route.

That decision happens before the page content and navigation links are shown. In practical terms, Atloria checks the version and audience rules first, then displays one of the following:

• the requested page with its allowed content
• a filtered navigation view with some pages removed
• no page, if that route is not available to that reader

This is why the same child page can behave differently depending on how it is opened. There are three common entry points:

• Direct URL — useful for testing whether a page is reachable even when it is not visible in menus
• In-app navigation — used by signed-in team members inside the project workspace
• Public navigation — used by outside readers on the published documentation site

A direct URL can sometimes open a page that does not appear in public navigation, if the version is publicly readable but intentionally hidden from menus. On the other hand, if a page is excluded by audience rules, the route may exist for internal readers but still fail for public readers.

Pay close attention to child pages under the version landing page. A version can resolve correctly at the top level while deeper pages are filtered out by audience-specific visibility. If a public reader reports that “the version opens, but one page is missing,” the issue is often the page’s audience view rather than the version itself.

Controlling what appears in public navigation

In Atloria, public readability and public navigation visibility are related, but they are not the same setting. A version may be available to public readers while still being omitted from public menus. This is useful when you want to share a version by direct link without making it broadly discoverable from the published navigation.

When you review a version’s setup, confirm whether the version is configured to appear in public navigation. This affects places such as:

• the public version selector
• version lists in published documentation
• navigation areas that help readers browse available releases

If a version is publicly readable but hidden from navigation, public readers can still open it if they already have the direct version link, as long as the version and page are allowed for public access. In that case:

• the version does not appear in public menus
• the direct link may still work
• discoverability is reduced, but access is not fully blocked

This distinction is important when teams share review links with selected readers before wider release. It also helps when you want to keep older or transitional versions available without advertising them in the public browsing experience.

Internal navigation is separate. Signed-in users inside Atloria may still see the version in project and version workspaces even when the public site hides it from menus. To confirm this, compare:

• the internal version list in the project workspace
• the public navigation on the published documentation side

If the version appears internally but not publicly, that may be the expected result rather than a problem.

Testing reader outcomes before publishing a version

Before you publish or share a version widely, test the actual reader experience in Atloria instead of relying only on the version settings screen. The most reliable check is to open the same versioned page in two browser contexts:

• Signed in as an internal user
• Signed out or in a private browser window as an anonymous public reader

Start with the version landing page, then move to several child pages. Compare what appears in each context:

• whether the version opens at all
• whether it appears in internal navigation
• whether it appears in public navigation
• whether child pages render full content, limited content, or no page

This side-by-side check helps you catch differences between version-level visibility and page-level audience filtering. A version may look correct on its main page while deeper pages behave differently for public readers.

Also test direct-link behavior. If the version is hidden from public navigation, paste the version URL into an anonymous browser session and confirm whether the page still opens. This tells you whether the version is merely hidden from menus or fully unavailable to public readers.

When you test, include pages from different parts of the version, not just the first page in the navigation. Look for signs such as:

• a page visible internally but missing publicly
• a version absent from public menus but reachable by direct link
• a navigation tree that changes between signed-in and public views

If anything looks inconsistent, return to the version settings and audience configuration before release. For a broader readiness check, pair this review with Validating Version Access Before Sharing or Export.

Fixing unexpected visibility and navigation results

When version access does not behave as expected in Atloria, compare the result against the version’s visibility mode, public navigation setting, and audience-specific page rules. Most issues come from one of those three areas.

If the version is visible to internal users but missing for public readers, first check the version’s access mode. Make sure the version is actually set for public reading, not internal-only access. Then review the audience view used for public readers. A version can be public at the top level while key pages are still excluded from the public audience.

If the version opens by direct URL but does not appear in public navigation, review the navigation visibility setting separately. This usually means the version is publicly readable but intentionally hidden from menus. In that case, direct-link access is working as designed, and the missing menu entry is controlled by the public navigation option.

If a public reader sees a missing page on a child route, focus on that specific page rather than the whole version. Confirm that the page is included in the public audience view for that version. This is a common issue when the version landing page is public but one or more nested pages are filtered out.

If internal and public readers see different navigation trees, compare whether filtering is happening at the version level, the page level, or both. Differences in the navigation menu often reflect audience-based filtering rather than a broken link.

A practical troubleshooting checklist is:

• verify the version’s access mode
• verify whether the version is included in public navigation
• test the direct URL in an anonymous session
• test multiple child pages, not only the landing page
• compare internal navigation with public navigation

For the next stage, continue with Managing Version Access and Sharing Outcomes.

Overview

This guide focuses on how one documentation version in Atloria can lead to different reader outcomes depending on who opens it and how that version is exposed. The main areas covered are:

• how to identify whether a version is internal-only, public, or using audience-based visibility
• how the same versioned route can behave differently for internal users and public readers
• how public navigation can hide a version even when direct-link access still works
• why child pages inside a version may be available internally but missing in the public view

This topic sits after Preparing Versions for Public Access and Sharing. That earlier guide helps you configure the version for sharing. Here, the focus is on understanding the outcome of those settings when real readers open versioned pages.

You will work mainly with:

• the version settings area inside a project
• the internal version list and project navigation
• the published documentation navigation
• direct links to version landing pages and nested document pages

Use this guide when you need to answer questions such as:

• “Why can my team open this version, but public readers cannot?”
• “Why does the version open from a link but not show in the public menu?”
• “Why is the version home page visible, but one child page is missing?”

Prerequisites

Before using this guide, make sure you already have access to the parts of Atloria where version visibility is reviewed and tested. You should be able to open a project, view its versions, and reach the published documentation side for comparison.

You will get the most value from this guide if the following are already in place:

• you can sign in to Atloria and open the relevant project workspace
• the project already has at least one documentation version
• the version has been prepared for sharing or public access decisions
• you can view both the internal project navigation and the public documentation view
• you understand the basic version-sharing setup from Preparing Versions for Public Access and Sharing

It also helps if you can test with two reading contexts:

• a normal browser session while signed in
• a private or signed-out browser session for the public reader view

That comparison is important because many visibility issues only appear when you switch from an internal session to an anonymous one. If you only test while signed in, Atloria may continue showing versions and pages that public readers cannot open.

If your role includes release review, documentation management, or project administration, keep a few sample page links ready from the version you are checking. Include:

• the version landing page
• one or two nested document pages
• any page that is expected to be audience-specific

Those examples make it easier to confirm whether the version behaves consistently across navigation, direct links, and audience views.