## Understanding How Audiences Shape Project Content
In Atloria, project audiences are managed inside the project workspace, where documentation teams define the reader groups they want to support for that specific project. After you save an audience in the project’s **Audiences** area, that audience becomes available when you work on documentation pages and other content that supports audience targeting. This means you set up the audience once in the project, then select it again later while editing content instead of retyping the same reader group every time.

An audience in Atloria is more than just a label. Each audience record includes a **Name** so writers can recognize it quickly, an internal **Description** so the team understands when to use it, and the project’s targeting details that identify who that content is meant for. Depending on how your project is configured, this may include labels, rules, or visibility criteria used to distinguish groups such as customers, partners, internal teams, or enterprise administrators.

These saved audience definitions shape what readers see in published documentation. Content marked for a specific audience can appear only when that audience is selected or matched in the published view, while content left open to everyone remains visible to all readers. In practice, this lets one page include both shared guidance and audience-specific instructions without forcing you to duplicate the page.

For example, a setup page might show general onboarding steps to all readers, while a section with advanced controls is assigned only to **Enterprise Admins**. In the published documentation, readers in the general view see the shared material, and the audience-specific section appears only in the matching audience view.

If you need help deciding which reader groups to create before you start, review [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation).

[SCREENSHOT: Project workspace showing the Audiences area and an editor view where saved audiences can be selected]

## Setting Up Audiences in a Project
To add a new audience in Atloria, start inside the project where the documentation will be written and published. Open the project, then use the project navigation or project settings to go to **Audiences**. This is the management screen where you create and maintain the reader groups available for that project’s content.

1. Open the target project from your project list or dashboard.
2. In the project workspace, go to **Audiences**.
3. Click **New Audience**.
4. Enter the audience **Name**.
5. Add the **Description** so your team knows when to use this audience.
6. Complete the available targeting details, such as labels, rules, or visibility criteria used in your project.
7. Click **Save**.

When you enter the **Name**, choose wording that writers will immediately understand in the editor. Names such as **Customers**, **Partners**, **Internal Teams**, or **Enterprise Admins** are easier to apply consistently than broad labels that could mean different things to different contributors. Use the **Description** to explain the intended use, especially if two audiences sound similar.

If your project includes audience labels or visibility criteria, set them carefully before saving. These settings are what Atloria uses when content is filtered in published documentation. A clear setup here reduces confusion later when writers assign audiences to pages or sections.

After you save, return to the audience list and confirm the new audience appears with the expected label. If the list includes a status or other identifying details, check that they match what you intended before writers begin using the audience in documentation.

[SCREENSHOT: Audiences management screen with the New Audience button and fields for Name, Description, and targeting details]

## Editing, Renaming, and Organizing Existing Audiences
As projects grow, audience definitions often need cleanup. In Atloria, you can open an existing audience from the **Audiences** list and update its details instead of creating a replacement every time something changes. This is useful when the original audience still represents the same reader group, but the wording, description, or targeting details need to be refined.

1. Open the project and go to **Audiences**.
2. Select the audience you want to update from the list.
3. Edit the **Name**, **Description**, or available targeting details.
4. Click **Save** to keep the changes.

Renaming is especially helpful when your team’s documentation standards become more specific. For example, an audience originally called **Users** may be too broad once the project includes separate content for **Enterprise Admins**, **Partners**, and **Internal Teams**. Updating the audience name makes the editor easier to use because writers can choose the correct audience without guessing.

A consistent naming pattern also helps when several writers work in the same project. Keep names short, specific, and based on real reader groups. If your team uses related audiences, align the wording so they sort naturally in the list and are easy to scan during editing.

When an audience is no longer needed, review it carefully before removing or archiving it. Pages, sections, or reusable content already assigned to that audience may still depend on it. If you remove an audience without updating those assignments, writers may see outdated labels in older content or lose clarity about who a section is meant for. Before cleanup, search through affected documentation and replace older audience assignments with the current project definitions.

[SCREENSHOT: Audience list with an existing audience opened for editing and renamed to a more specific reader group]

## Applying Audiences While Writing and Editing Documentation
Once audiences are set up in a project, writers use them directly in the documentation editor. Open the page you want to update, then look for the audience selector or visibility control used to target content. This is where you decide whether the whole page, a section, or a smaller content block should be shown to everyone or limited to a specific reader group.

1. Open the project and go to the documentation page you want to edit.
2. Click **Edit** to open the page in the editor.
3. Locate the audience selector or visibility control for the page, section, or content block.
4. Choose the audience you want to apply.
5. Save or publish your changes, depending on your team’s workflow.

Use page-level targeting when the entire page is meant for one audience. Use section-level or block-level targeting when only part of the page should change for a specific group. This is often the better choice because it lets you keep shared instructions visible to all readers while adding specialized details only where needed.

For example, a page about project setup might include general steps that every reader sees, followed by an audience-targeted section for **Partners** or **Enterprise Admins**. That approach keeps the page easier to maintain than creating multiple near-duplicate pages.

During revisions, always recheck audience assignments. A page may have been written for one audience earlier in the project, but later updates might broaden or narrow who should see it. If the audience definitions in the **Audiences** screen have changed, update the page, section, or block assignments so the published result still matches the current project plan.

[SCREENSHOT: Documentation editor showing a page with a visibility or audience selector applied to a section of content]

## Using Audiences Across Projects and Published Views
In Atloria, audiences are managed at the project level. That means an audience you create in one project is intended for that project’s documentation and should not be assumed to automatically appear in another project. If your organization runs several projects for similar reader groups, plan your audience naming carefully so teams use the same labels and descriptions wherever possible.

For example, if multiple projects serve the same reader types, choose one naming standard such as **Customers**, **Partners**, **Internal Teams**, and **Enterprise Admins**, then apply that pattern consistently in each project’s **Audiences** area. This makes it easier for writers, reviewers, and documentation managers to move between projects without relearning audience labels.

Published documentation uses these audience assignments to tailor what readers see. Content marked for all readers remains visible in the default public view, while content assigned to a specific audience appears differently when that audience is selected or matched in the published experience. This allows a single documentation set to support both broad public guidance and more specialized instructions.

Before publishing, check how audience filtering behaves in the project view or preview tools available to your team. Compare the default view with the view for a selected audience and confirm that shared content stays visible while targeted sections appear only where expected. If your project includes multiple published outputs or audience-aware navigation, verify each one before release.

For teams managing several documentation sets, governance matters. Documentation managers should keep audience names, descriptions, and intended usage aligned across projects so published documentation feels consistent. If your organization also manages audience settings beyond a single project, see [Managing Audience Settings Across the Organization](doc:managing-audience-settings-across-the-organization).

[SCREENSHOT: Published documentation preview comparing the default reader view with a selected audience view]

## Common Issues When Managing Audiences and How to Fix Them
Most audience problems in Atloria come from one of four places: the audience was never saved in the current project, the wrong audience was assigned in the editor, older audience names are still in use, or the published view is being checked with different filters than the editor preview.

If an audience does not appear while you are editing a page, first return to the project’s **Audiences** screen and confirm that the audience exists in that same project. If it was created somewhere else, it will not be available here. Also check that you can access the project settings and content-targeting controls needed for audience work. If those options are missing, ask a project administrator to review your access.

When content is visible to the wrong readers, inspect both the page-level setting and any section-level or block-level audience assignments. A page may be shared with all readers while one section is restricted, or the reverse may be true. Overlapping assignments can make content appear broader than expected, especially when shared content and targeted content are mixed on the same page.

Renamed or deleted audiences can also create confusion. Writers may still recognize the old label and continue using outdated assumptions when editing. Review existing pages for older audience names and replace them with the current project definitions so the editor and published output stay aligned.

If the published result does not match what you saw while editing, compare the selected audience in the preview with the audience filter in the published view. Also confirm you are checking the correct published output for that project and that the latest changes were republished. A mismatch often comes from viewing the right page with the wrong audience filter rather than from the content itself.

[SCREENSHOT: Side-by-side check of editor audience settings and published audience filter]

## Overview
- In Atloria, project audiences let you tailor documentation for specific reader groups without duplicating entire pages.
- You create audiences inside a project’s **Audiences** area, then reuse those saved audiences while editing documentation.
- Each audience should have a clear **Name**, a useful **Description**, and the project’s available targeting details so writers know exactly when to apply it.
- Audience assignments can be applied to a full page or to smaller sections and content blocks, depending on how targeted the information needs to be.
- Shared content can remain visible to all readers while specialized instructions appear only for selected audiences in published documentation.
- Audience definitions are project-based, so teams working across multiple projects should use consistent naming patterns to reduce confusion.
- Before publishing, compare the default view with the audience-specific view to confirm the right content appears for the right readers.
- If you see missing audiences, incorrect visibility, or mismatched published results, start by checking the project’s **Audiences** list, the editor’s audience settings, and the selected audience filter in the published view.

This document focuses on managing the audience records themselves and applying them in project content. The next step is using those audience choices to shape how pages are structured and written in [Applying Audiences to Documentation Structure and Content Decisions](doc:applying-audiences-to-documentation-structure-and-content-decisions).

## Prerequisites
- You can sign in to Atloria and open the correct project workspace. If needed, review [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) and [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems).
- You already understand the reader groups your documentation needs to support. If you have not planned those groups yet, read [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation).
- You have access to the project’s **Audiences** area and to the documentation editor where audience targeting is applied.
- Your project already exists in Atloria and contains documentation pages or draft content that can be tagged for different audiences.
- Your team has agreed on basic audience naming conventions so labels in the **Audiences** list are easy for writers and reviewers to recognize.
- If you are working across several projects, decide whether the same audience names should be repeated in each project for consistency.
- If you plan to verify audience behavior before release, make sure you can open the project’s preview or published view and compare the default reader view with an audience-specific view.