## Confirming the audience targeting prerequisites

Before you start release validation in Atloria, make sure the audience setup is already in place. This guide assumes you have already defined your audience structure, as covered in [Validating Audience Targeted Publishing](doc:validating-audience-targeted-publishing). On the audience management side, confirm that at least one audience exists and that each audience has a clear **name** and a recognizable purpose. If Atloria shows a description for the audience, review that as well so you can tell the difference between similar groups such as internal, partner, and public readers.

Next, open the project where the release will happen and check that you can reach the areas used during validation. You should be able to open the project workspace, access the version-related screens, and reach the publishing or preview controls used to inspect release output. If your team uses public review links, confirm that those links or preview options are available before you begin checking audience-specific pages.

Permissions matter here because audience validation usually crosses both content and release settings. In practice, the people doing this work need access to create or review targeted content and also enough access to manage audience and release settings. If you can open the project content, version details, and audience-related settings without seeing access errors, you are ready to continue. If not, ask an administrator to review your access using the guidance in [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions).

Finally, review the content included in the release. Make a simple list of the pages, articles, or versioned documents you plan to publish, and note which ones are meant for a specific audience and which should stay visible to the default public audience.

- Check that each audience has a clear label you can recognize during preview
- Confirm you can open version settings and publishing controls in the project
- Verify that public review or preview options are available
- List the pages included in the release and mark their intended audience

[SCREENSHOT: Audience list next to a project version or publishing screen]

## Setting up audiences for the release

Use this section to review or finalize the audiences that will receive content in the upcoming release. In Atloria, open the audience configuration area for your organization or project and inspect each audience one by one. Focus on the visible details on screen: the audience label, any description shown under the name, and any membership rules or inclusion settings available in the form. The goal is to make sure each audience is easy to identify when you later assign pages and validate previews.

1. Open the audience management area and review the list of available audiences.
2. Select each audience and confirm its displayed name and description match the release plan.
3. Check any membership or rule-based settings shown on the audience form so you understand who should receive that content.
4. Create missing audiences if your release plan includes a group that does not yet appear in the list.
5. Save any changes before moving to content assignment.

As you review the list, map each audience to a real release destination. For example, one audience may be used for internal documentation, another for partner-facing material, and another for the default public experience. Even if your team already knows this informally, it helps to write it down before validation starts. A simple audience matrix prevents confusion when two versions of the same page exist.

A small planning table is often enough:

| Audience | Intended readers | Typical release use |
|---|---|---|
| Public | General visitors | Default published documentation |
| Internal | Team members | Internal-only instructions or notes |
| Partner | External partners | Partner-specific guidance |

If Atloria shows preview counts, test-user inclusion, or any visible way to confirm who falls into an audience, use those checks now. This is the best time to catch an audience that is too broad, too narrow, or mislabeled. Once the audience list looks correct, note which audience should receive each page in the release so your later validation has something concrete to compare against.

[SCREENSHOT: Audience settings screen showing audience name, description, and membership options]

## Planning content versions for each audience

After the audience list is stable, move into release planning at the page and version level. The main decision here is whether a page needs a separate audience-specific version or whether one shared version can serve everyone. In Atloria, this usually becomes clear when you compare the page content itself. If the title, instructions, screenshots, or linked resources are the same for all readers, keep one shared version. If the content changes meaningfully for a specific group, prepare a separate targeted version.

1. Open the pages or versioned documents included in the release.
2. For each item, decide whether it should stay shared or have an audience-specific variant.
3. Review the visible version label and draft status so you can tell working drafts from release-ready content.
4. Check how each targeted page relates to its base content so you do not lose track of which versions belong together.
5. Use the audience selector or release assignment controls on the page to connect each version to the correct audience.
6. Save your changes and record the result in your audience matrix.

As you work, pay close attention to naming and status. If Atloria shows labels such as draft, ready, or published, use those labels to separate unfinished work from versions that can safely enter release validation. This is especially important when multiple audience variants exist for one page. A clearly labeled version is much easier to validate than a set of nearly identical drafts.

Also look for coverage gaps. A common issue is that one audience has no matching version at all, or that two versions are both assigned to the same audience for the same release. Either problem creates confusion during preview and can lead to the wrong page being shown after publishing. Compare what you see in the page list and version details against the audience matrix you created in the previous section.

[SCREENSHOT: Page editor or version details showing audience assignment and version status]

## Validating targeted versions before publishing

This is the main release check. In Atloria, open each version that is part of the release and inspect the publishing details shown on screen. You are looking for three things first: the assigned audience, the current version status, and any release timing details shown in the publishing panel. If one of those items is missing or does not match your plan, fix it before you rely on preview results.

1. Open a version from the release list or publishing workflow.
2. Check the audience assignment shown in the version or publishing panel.
3. Confirm the status is appropriate for release validation and not still an unfinished draft.
4. Review any scheduled release details if your team is publishing on a set date or time.
5. Launch the available preview or validation view for that version.
6. Repeat the preview for each audience option available in the page or release workflow.
7. Compare the previewed content against your audience matrix and release notes.
8. Record any mismatch before moving to the next version.

During preview, do more than just glance at the page body. Compare the **title**, main content, attachments, screenshots, and linked pages. A targeted version may look correct at first but still include an outdated attachment or a link that points to the wrong audience variant. If Atloria shows related pages or linked content inside the preview or version details, inspect those too.

Watch for on-screen warnings. Atloria may surface messages about missing audience assignments, unpublished dependencies, or conflicting release states. Treat these as release blockers until you understand them. A warning about a missing assignment often means a page will fall back to the wrong version, while a dependency warning can mean readers will land on a page that links to content they cannot access yet.

[SCREENSHOT: Publishing panel with audience assignment, status, and preview controls]

## Reviewing the public audience experience

After validating the targeted versions themselves, switch to the public-facing review. This step confirms what readers will actually see after release, especially people who are not signed in and should only receive the default public experience. In Atloria, open the public review link, preview mode, or any audience switcher available from the release workflow. Start with the public view before checking restricted audiences.

1. Open the public review link or preview mode for the release.
2. View the documentation as the default public audience.
3. Confirm that navigation, page lists, and search results show only the public content you expect.
4. Open key pages directly and verify they display the default public version.
5. Switch to one or more targeted audience previews if Atloria provides an audience switcher.
6. Compare the same pages across audience views to confirm the correct version appears for each audience.
7. Note any page that exposes internal or restricted content in navigation, search, or direct links.
8. Collect reviewer approval once the public view matches the release plan.

This check is especially important for pages that exist in more than one version. A page may be correctly assigned in the editor but still appear incorrectly in public navigation if the default audience version was not reviewed carefully. Open the top-level navigation, browse to a few child pages, and test direct links where possible. If a restricted page appears in the public path, stop and correct it before release.

If your team uses a formal sign-off process, capture approval based on what reviewers can actually see in preview: page visibility, version accuracy, and overall release readiness. That sign-off should be tied to the public review output, not just to the internal editing view.

[SCREENSHOT: Public preview with audience switcher or public review link open]

## Fixing audience targeting problems before release

If validation reveals a problem, work backward from what you see in preview. In Atloria, the fastest way to solve audience issues is to compare the visible page assignment, version status, and release setup against the audience matrix you created earlier. Most problems come from one of four places: the wrong audience was assigned, the correct version is still in draft, the public default is misconfigured, or two versions are competing for the same audience.

1. When the wrong version appears, open the page or version details and recheck the audience assignment shown there.
2. Confirm the selected version is the one included in the release and not an older or duplicate variant.
3. Review the version status to make sure the intended page is ready for release.
4. If public users see restricted content, inspect the default audience setup and any navigation links that point to the wrong page.
5. If a target audience cannot see its content, review the audience definition and any visible membership or test-user settings.
6. Compare the release list against your audience matrix to find missing or duplicate coverage.
7. Re-run preview after every correction so you confirm the fix before moving on.

When public pages show restricted material, focus on the default public path first. A restricted version may be linked from navigation, surfaced in search, or opened through a direct page link that bypasses your intended audience flow. Check the page list and linked pages around that content, not just the page itself.

When an audience sees nothing, the issue is often simpler: the targeted version was never moved out of draft, or the audience assignment was left blank. If Atloria shows validation messages, use them as a guide and then verify the result in preview. Do not rely on the page editor alone. The preview is the final proof that the audience rules and release settings are working together correctly.

[SCREENSHOT: Version list or page settings showing corrected audience assignment after a validation issue]

## Overview

This document focuses on the final checks you perform before releasing audience-targeted documentation in Atloria. The goal is not to define audiences from scratch or explain the full publishing process. Instead, it helps you confirm that each audience-specific version is assigned correctly, previewed correctly, and safe to release without exposing the wrong content to the wrong readers.

The workflow in this guide follows the same path most teams use in Atloria: confirm the audience setup, map audiences to release content, review version assignments, preview each targeted variant, and then inspect the public-facing result. That sequence matters because audience problems are easier to fix before you begin final release approval. If you skip directly to public review, you may find issues without knowing whether they came from audience setup, version planning, or release selection.

Use this guide when you already have audience-based documentation prepared and need to validate release readiness. If you still need to set up audience strategy or initial targeting rules, start with [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences) and [Validating Audience Targeted Publishing](doc:validating-audience-targeted-publishing). Those guides cover the earlier planning work so you can keep this review focused on release validation.

In practice, this guide is most useful when:
- A release includes both public and restricted pages
- One page has multiple audience-specific versions
- Reviewers need proof of what each audience will see
- You want to catch visibility mistakes before publishing
- Your team needs a repeatable sign-off process for audience-targeted releases

The next step after this validation pass is [Validating Audience Specific Publishing Before Launch](doc:validating-audience-specific-publishing-before-launch), where you move from pre-release checking into launch-focused confirmation.

## Prerequisites

Before you work through the validation steps in this guide, make sure the release is far enough along that preview results will be meaningful. In Atloria, that usually means the project already contains the pages and versions you intend to publish, and the audience structure has already been reviewed. You do not need every page to be perfect, but you do need stable content assignments and enough access to open the relevant project and publishing screens.

You should have the following in place:

- Access to sign in to Atloria and open the target project workspace
- Permission to view and update documentation pages, versions, and release-related settings
- At least one configured audience available for targeted publishing
- A release candidate or version set that includes the pages you plan to validate
- Access to preview tools, public review links, or audience switching options if those are available in your workspace
- A simple audience matrix or release checklist showing which page belongs to which audience

It also helps to have already completed these related tasks:

- Defined project audiences using [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation)
- Reviewed organization-level audience behavior in [Using Audience Settings Across the Organization](doc:using-audience-settings-across-the-organization)
- Prepared the release content using [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle)
- Confirmed the release candidate is ready for review in [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review)

If your team also uses admin-level review areas such as **Analytics & Insights** or **Security & Audit**, keep in mind that those screens are separate from audience publishing validation. They may support broader review work, but the checks in this guide happen in the project, version, preview, and public review areas where audience-targeted content is actually inspected.