Controlling Version Visibility and Export Options

Understanding how version access mode affects visibility

In Atloria, version visibility is controlled at the individual version level. When you open a project and go to the Versions area for that documentation set, each version has its own visibility state. This is the setting Documentation Managers and Project Administrators use to decide whether a version is available only inside the workspace or visible to external readers in published documentation.

A version set to Public is intended for published use. In practice, that means external readers can find it in the public documentation experience, including the version selector or published versions list. If your team shares a public documentation link, readers should be able to switch to that version from the version menu and browse its pages the same way they would browse any other published release.

A version set to a restricted or private access mode stays inside Atloria for internal work. Workspace users with the right access can still open it from the project’s Versions list, review content, compare it, and continue preparing it for release. Public readers do not see that version in the public documentation navigation, and it should not appear in the public version switcher.

When you review version visibility, start in the project workspace rather than the public site. The Versions management screen is where you can confirm the current state for each release before sharing links or enabling exports. This is especially useful when you are managing multiple releases at once, such as a live public version, a review version, and a draft version being prepared for a future release.

Changing a documentation version from private to public

1. Open the project in Atloria and go to the documentation area where you manage releases and published versions.

2. Select Versions to open the full versions list for the current documentation set. Find the version you want to expose to readers. This is usually the release you have already reviewed and approved for public use.

3. Open that version’s settings or access controls. Look for the visibility setting or access mode for the selected version. The exact wording may vary on the screen, but it will indicate whether the version is private, restricted, internal, or public.

4. Change the version to Public. This tells Atloria that the version should be available in the published documentation experience rather than only inside the project workspace.

5. Click Save to apply the change. If Atloria shows a confirmation message or updated status on the version row, use that as your first check that the change was stored successfully.

6. Open the public documentation view for the project and use the version selector to confirm the version is now listed. If the version was previously hidden, it should now appear alongside other public releases.

7. Open the newly public version from the public side and confirm that readers can browse its pages normally.

This is a good point to verify release readiness as well. If you are making a version public for the first time, compare what you see in the workspace with the published result so you do not expose a version earlier than intended. If you need a broader release check, continue with Validating Version Access Before Sharing or Export.

Limiting access to internal or in-progress versions

Draft, review, and unreleased versions should usually stay out of the public documentation view until your team is ready. In Atloria, you handle that by keeping the version in a restricted or internal-only access mode from the Versions management screen.

1. Open the project and go to Versions.

2. Review the list and identify versions that are still in progress. Focus on versions your team is drafting, reviewing, comparing, or holding for a future release.

3. Open the target version’s settings or access controls.

4. Change the access mode to the restricted or internal option shown on that screen.

5. Click Save and return to the versions list to confirm the updated state is displayed for that version.

When a version is not public, Atloria keeps it available to the people who manage work inside the project while removing it from the public documentation experience. That means external readers should not see it in the public version selector, and it should not be presented as a published release on public-facing pages. This helps you keep unfinished material, review copies, or internal-only documentation out of customer-facing navigation.

This setting is especially important when your team uses direct links during review. A Documentation Manager or Project Administrator may still be able to open and maintain the hidden version inside Atloria because they are working in the internal workspace. That does not mean public readers can see it. Internal preview access and public visibility are separate outcomes, so always check the public side if you need to confirm what outside readers can actually access.

If your team is also planning audience-based access, that is covered next in Managing Version Visibility and Reader Access.

Managing export controls for each version

Export availability in Atloria is managed per version, not as one setting for the entire project. This matters when you want one release to be downloadable while keeping another release view-only. To adjust this, open the version you want to manage and look for its export-related controls on the version configuration screen.

You should treat export settings as part of release preparation. For example, a public release may be visible to readers, but you may still decide whether that same version can be downloaded. A draft or internal review version might remain hidden and also have exports turned off so it cannot be distributed as a downloadable package.

When exports are enabled for a version, readers can find the export action while viewing that version in published documentation. The exact action may appear as an Export button or another download option in the published reading interface. Because the setting belongs to the selected version, readers may see export actions on one version and not on another.

When exports are disabled for a version, Atloria removes or withholds those export actions for that release. In the public documentation view, readers should not see the export button for that version. This makes it possible to publish a version for online reading without allowing downloads.

A useful way to manage this is to review each version individually from the Versions list:

• Open the version you want to control.
• Check its visibility setting.
• Check its export setting.
• Save any changes before moving to the next version.

This version-by-version approach is important when you support multiple active releases, such as a current public version, an older archived public version, and an internal upcoming release with no export access.

Checking what public readers can see and download

After changing visibility or export settings, verify the result from the public side rather than relying only on the internal workspace. Atloria can show more options to internal users, so the public view is the best place to confirm the actual reader experience.

1. Open the project’s public documentation site.

2. Find the version selector and review the list of available versions. Only versions marked as public should appear here for anonymous or external readers.

3. Switch between the listed versions and confirm that each one opens correctly in the public documentation view.

4. For each public version you are checking, look for the Export action or download option in the published interface.

5. Compare what you see:

   • If exports are enabled for that version, the export action should be visible.
   • If exports are disabled, the export action should be absent.

6. Return to the internal Versions screen in Atloria and compare the public result with the settings shown for each version. This helps you confirm that hidden versions remain hidden and that export controls match your intended release policy.

This comparison is especially helpful when you manage several versions at once. A version may be visible publicly but not downloadable, while another may be hidden entirely. Checking both the internal management view and the public reading view makes it easier to catch mistakes before you share links with customers, reviewers, or other external readers.

Fixing versions that appear unexpectedly or cannot be exported

If a version is showing up publicly when it should be hidden, start in the project’s Versions list and reopen that version’s settings. Check the current access mode and make sure it is set to the restricted or internal option rather than Public. Then click Save again and recheck the public documentation site. If the public side still shows the version, compare the version row in the internal list with the public version selector to make sure you are reviewing the same release.

If a version does not appear in public documentation, confirm two things on the version record: it must be a published release and it must be set to the public visibility option. A version that is still being prepared, reviewed, or kept internal will remain available inside Atloria for authorized users but will not be listed for public readers.

If the Export button is missing for a version, open that version’s configuration page and inspect the export setting for that specific release. Because export availability is version-specific, enabling exports for one release does not automatically enable them for others. Save the setting, then return to the public view of that same version and check again.

You may also notice that an admin user can still open a version that public readers cannot. In Atloria, that usually means the version is hidden from the public site but still available in the internal workspace for maintenance, review, or preview. This is expected behavior. Internal access for Documentation Managers and Project Administrators is not the same as public visibility.

When you need a stricter release check before sharing links or downloads, use Controlling Version Sharing and Export Readiness together with Validating Version Access Before Sharing or Export.

Overview

Use version visibility and export settings together whenever you prepare a release in Atloria. Visibility controls whether a version appears in published documentation and in the public version selector. Export controls decide whether readers can download that same version. Because both settings apply to each version separately, you can support different release outcomes across the same project.

A practical setup often looks like this:

• A current release is Public and export-enabled.
• An older release is Public but export-disabled.
• A draft or review release is restricted to internal workspace users.

The main screens involved are:

• The project Versions list, where you review each release
• The selected version’s settings or configuration panel, where you update access and export options
• The public documentation site, where you confirm the reader experience

Keep these points in mind:

• Public versions are visible to external readers.
• Restricted or private versions stay available to authorized workspace users.
• Export actions are tied to the version currently being viewed.
• Internal access for admins does not mean the version is public.

If you are working through the full release process, this topic fits after version review and before final public validation. For related release preparation, see Reviewing and Approving Documentation Versions and Comparing Version Output and Release Readiness.

The next step in this section is Managing Version Visibility and Reader Access.

Prerequisites

Before you change version visibility or export settings in Atloria, make sure you have the right project context and enough access to edit version configuration.

You should have:

• Access to the correct project workspace
• Permission as a Documentation Manager or Project Administrator
• At least one existing documentation version in the project
• A version that is ready to review for public or restricted access
• Access to the public documentation view if you want to verify the result after saving

It also helps if you have already completed these related tasks:

• Created or generated the version you want to manage
• Reviewed its content and release status
• Confirmed whether the version should be public, internal-only, or downloadable

If you still need to prepare the version itself, use these guides first:

• Generating New Documentation Versions
• Managing Version Lists Statuses and Comparisons
• Reviewing and Approving Documentation Versions

Before changing settings, gather the decisions your team has already made for that release:

• Should external readers see this version?
• Should the version appear in the public version selector?
• Should readers be allowed to export or download it?
• Is this version still in draft, review, or internal preview?

Having those answers ready makes the update much faster when you open the version settings. Once those decisions are clear, continue to Managing Version Visibility and Reader Access to refine who can read each version after it becomes available.