# Atloria ## Administrator Guide Overview Welcome to the Administrator Guide for Atloria. This section helps administrators understand where to go, what they can manage, and which guides to use for common administrative tasks. In Atloria, administrators typically manage account access, user and organization controls, security settings, project setup, project oversight, analytics, and documentation release work. ## What administrators manage in Atloria Depending on your role, you may use Atloria to: - Control sign in and account access - Manage users, permissions, and organization settings - Review security-related options - Monitor analytics and activity - Create and oversee projects - Open project dashboards and linked workspaces - Manage onboarding, settings, versions, and audit records - Coordinate technical documentation and authored documentation work - Prepare and validate documentation releases ## Administrator Guide categories ### Authentication Authentication covers account access and sign in features for entering Atloria. This category includes 7 documents focused on how administrators and users access Atloria securely. ### Administration Administration covers administrative controls for users, security, analytics, and organization settings. This category includes 5 documents for broader administrative oversight in Atloria. ### Project Management Project Management covers project creation, administration, settings, analytics, and technical documentation workspaces. This category includes 32 documents. Key overview and navigation guides include: - [Using the Admin Workspace](/using-the-admin-workspace) — Learn how to use the Admin workspace to navigate to user controls, security pages, analytics, and AI-related settings for platform administration. - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) — Learn how to browse the project list, interpret project status indicators, open project dashboards, and move into project-specific workspaces. - [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) — Learn how project administrators use the project home to complete onboarding, manage settings, review analytics and versions, inspect audit records, and access technical documentation tools. - [Exploring Technical Documentation Inside a Project](/exploring-technical-documentation-inside-a-project) — Learn how to open a project's technical documentation area, browse generated API and entity reference content, and navigate between overview and detailed technical pages. - [Managing Project Workspaces and Recent Activity](/managing-project-workspaces-and-recent-activity) — Learn how Documentation Managers, Project Administrators, and Technical Writers use the project list, project cards, and project home pages to find workspaces, review project status, and move into daily project work. - [Managing Project Operations Across Project Home Tabs](/managing-project-operations-across-project-home-tabs) — Learn how to use the tabs on a project home page to move between project administration, analytics, versions, technical documentation, and audit-related areas. - [Understanding Project Navigation and Linked Workspaces](/understanding-project-navigation-and-linked-workspaces) — Learn how Atloria project pages connect Documents, Versions, Analytics, Technical Documentation, Onboarding, linked workspaces, and Settings so you can move between areas without losing project context. - [Managing Project Portfolio and Operational Oversight](/managing-project-portfolio-and-operational-oversight) — Learn how documentation managers and project administrators use the Projects list, project home, linked workspaces, and Recent Activity views to monitor project status, open the correct workspace, and coordinate daily operations. - [Using Project Home to Coordinate Documentation Work](/using-project-home-to-coordinate-documentation-work) — Learn how to use project home to review project status, switch between tabs, track linked workspaces, and coordinate content, version, analytics, and technical documentation work from one project context. - [Navigating Project Workspaces and Linked Tools](/navigating-project-workspaces-and-linked-tools) — Learn how to navigate a project workspace and move between linked tools for documents, versions, analytics, audit history, settings, technical documentation, and onboarding. - [Managing Project Setup After Initial Onboarding](/managing-project-setup-after-initial-onboarding) — Learn how to revisit project administration after onboarding to update structure, delivery settings, connected options, and readiness checks without creating the project again. - [Running a Documentation Release from Project Workspaces](/running-a-documentation-release-from-project-workspaces) — Learn how to run a documentation release from project workspaces by preparing documents, aligning versions, completing review checkpoints, validating access, and publishing the final release set. - [Running a Project from Setup to Public Documentation Release](/running-a-project-from-setup-to-public-documentation-release) — Learn how to run a documentation project from project setup and onboarding through authoring, review, version generation, access validation, and public release with clear role responsibilities. - [Using Analytics Audit and Exports in Release Operations](/using-analytics-audit-and-exports-in-release-operations) — Learn how to validate a documentation release by reviewing project analytics, checking audit history, and exporting release evidence before sharing content with readers or stakeholders. - [Coordinating Technical Reference and Authored Content Workflows](/coordinating-technical-reference-and-authored-content-workfl) — Learn how to coordinate technical reference review, authored documentation updates, version preparation, and public publication in a single documentation workflow. ## Where to start If you are new to Atloria administration, start with [Using the Admin Workspace](/using-the-admin-workspace), then continue to [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) and [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home). These guides will help you understand how Atloria is organized before you begin managing projects and releases. ## Basic Terminology This guide explains common words you will see in Atloria. Use it as a quick reference while you move through projects, documentation, reviews, and publishing. ### Account Your personal sign-in for using Atloria; it appears when you log in, update your profile, or manage access. ### Admin Dashboard The main area for administrators to review activity, permissions, security, and usage; it appears after entering the admin area. ### Agent An AI helper in Atloria that answers questions using your project documentation; it appears in the support agent setup and chat areas. ### Analytics Information that helps you understand documentation usage and performance; it appears in reporting and project insights areas. ### Approval A decision that confirms a documentation version is ready to move forward; it appears in review and release steps. ### Approval Workflow The review path used to request, approve, or reject documentation before release; it appears when managing version readiness. ### Audience A group of readers you define so content can be shown to the right people; it appears in audience settings and public documentation views. ### Audit Activity A history of important actions taken in Atloria; it appears in audit and security review areas. ### Document A page of written content in Atloria; it appears in the editor, project workspace, and published documentation. ### Document Editor The writing area where you create and update documentation; it appears inside a project when working on content. ### Documentation Version A saved release of your documentation at a point in time; it appears in version lists, comparisons, approvals, exports, and publishing. ### Draft Work that is still being written or reviewed and is not yet final; it appears in the editor and version workflow. ### Export A saved copy of documentation or records taken out of Atloria; it appears in export actions and export history. ### Filter A way to narrow what you see in a list; it appears in project lists, version lists, audit records, and analytics views. ### Integration A connection between Atloria and another service, such as a code provider; it appears in connection and settings pages. ### Project The main workspace for a set of documentation, settings, versions, and team activity; it appears throughout Atloria. ### Project Dashboard The overview page for a project, showing its key activity and shortcuts; it appears after opening a project. ### Project Onboarding The setup steps for creating a new project in Atloria; it appears when starting a project for the first time. ### Publish The action of making documentation available to readers; it appears in version and document release actions. ### Public Documentation The reader-facing documentation site shared outside your private workspace; it appears at published documentation links. ### Record A saved item in Atloria, such as a project, document, version, audience, or audit entry; it appears in lists, tables, and detail pages. ### Repository The connected source Atloria uses to help build documentation from project files; it appears during project setup and integration settings. ### Review The step where someone checks documentation before it is approved or published; it appears in approval and collaboration areas. ### Screenshot An image captured from a page or link for use in documentation; it appears in screenshot capture and document editing flows. ### Settings The area where you control project, account, AI, access, or connection options; it appears in project and admin pages. ### Stage A step in a process, such as drafting, reviewing, approving, or publishing; it appears in workflows and version progress. ### Status A label that shows the current state of something, such as draft, approved, or published; it appears in lists and detail pages. ### Support Agent An AI assistant built from your documentation to help answer questions; it appears in the support agent management area. ### Version Control The way Atloria keeps track of different documentation versions over time; it appears in version management and comparison areas. ### View A way of displaying information, such as a list, dashboard, or public reading page; it appears across projects, analytics, and documentation. ### Workflow A set of steps used to move work from start to finish; it appears in approvals, publishing, and project processes. ## Related Guides If you want to learn where these terms are used, start with these guides: - [Project Onboarding](/project-onboarding) - [Project Management](/project-management) - [Document Editor](/document-editor) - [Documentation Versions](/documentation-versions) - [Approval Workflow](/approval-workflow) - [Version Access Control](/version-access-control) - [Support Agents](/support-agents) - [Public Documentation Viewer](/public-documentation-viewer) - [Admin Dashboard](/admin-dashboard) - [Audit Trail](/audit-trail) ## Common Issues & Solutions This guide helps you quickly troubleshoot common problems in Atloria. Issues are grouped by what you notice first, such as trouble signing in, missing content, confusing version status, or incomplete analytics. For each issue, start with the symptom you see, review the likely cause, and then follow the suggested solution. If you need step-by-step instructions, use the linked help articles. ## Login and Account Access Issues ### I cannot find the correct sign-in page **Symptom** You are on a page that does not look like the normal Atloria sign-in screen, or you are not sure whether you are in the right place. **Likely cause** You may have opened the wrong page, or you may be on the registration form instead of the sign-in form. **Solution** Start from the Atloria public site and select **Sign in** in the top navigation. Confirm that the page includes the **Email** field, **Password** field, and **Sign in** button. If you are on **Register** but already have an account, use the link on that page to switch back to **Sign In**. See: - [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems) - [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account) - [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation) ### Atloria says my email or password is invalid **Symptom** You see **Invalid email or password** when trying to sign in. **Likely cause** The email address may not match your Atloria account, or the password may be incorrect. **Solution** Re-enter both fields carefully. Make sure you are using the same email address used when your Atloria account was created. If you still cannot sign in, use **Forgot password** to reset your password. See: - [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems) ### I cannot sign in because I forgot my password **Symptom** Your usual password no longer works. **Likely cause** Your password may have changed, expired, or been entered incorrectly. **Solution** On the Atloria sign-in page, select **Forgot password** and complete the reset steps. After resetting, return to the sign-in screen and try again with the new password. See: - [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems) ### Atloria keeps sending me back to Sign in **Symptom** You sign in, but Atloria returns you to the sign-in page again. **Likely cause** Your sign-in may not have completed successfully, or your session may not be staying active. **Solution** First confirm that you actually signed in successfully and did not see an error message. Then try opening the main account area again. If the problem continues, sign out fully and sign back in. If you recently received new access, signing in again can refresh what Atloria shows in navigation. See: - [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems) - [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation) ### I am trying to register, but I already have an account **Symptom** You are on the registration page even though you only want to sign in. **Likely cause** You selected the wrong account entry option. **Solution** Switch from **Register** to **Sign In** using the link on the page. Then enter your existing Atloria account details. See: - [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account) ## Navigation and Workspace Issues ### I cannot find the Admin area **Symptom** The **Admin** workspace is missing. **Likely cause** You may be signed in with the wrong account, your access may not include admin permissions, or your access was added recently and has not refreshed in your current session. **Solution** Confirm that you are signed in with the correct Atloria account. If you were recently granted admin access, sign out and sign back in. If the area is still missing, ask an administrator to confirm your role and workspace permissions. See: - [Using the Admin Workspace](/using-the-admin-workspace) - [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions) ### I cannot find a project **Symptom** A project you expect to see is missing from the **Projects** list. **Likely cause** A search term, filter, sort order, or wrong workspace view may be hiding it. **Solution** Clear the search box, remove active filters, and check the current sort order. Also confirm that you are in the correct Atloria workspace and not inside another project with a similar name. See: - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) - [Managing Project Workspaces and Recent Activity](/managing-project-workspaces-and-recent-activity) - [Managing Project Portfolio and Operational Oversight](/managing-project-portfolio-and-operational-oversight) ### I opened the right project, but the workspace I need is missing **Symptom** You are inside a project, but a linked workspace or documentation area does not appear. **Likely cause** You may be in the wrong project view, or your role may not include access to that area. **Solution** Check that you are on the main project area and not a different sub-area. Confirm the project name at the top of the screen. If the workspace is still missing, ask a project administrator to confirm your access. See: - [Using Project Home to Coordinate Documentation Work](/using-project-home-to-coordinate-documentation-work) - [Exploring API Reference Sections Inside Projects](/exploring-api-reference-sections-inside-projects) - [Exploring Technical Documentation Inside a Project](/exploring-technical-documentation-inside-a-project) ## Document Editing and Page Issues ### A page will not save **Symptom** You make changes in Atloria, but the page does not save. **Likely cause** Required page details may be missing, such as the title, slug, or page location. **Solution** Check the top of the editor and the page settings area for missing required information. Review the **Title**, **Slug**, and parent page or location. Save again after filling in any missing details. See: - [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) - [Managing Project Content from Drafts to Published Pages](/managing-project-content-from-drafts-to-published-pages) ### A new page does not appear where I expected **Symptom** You created a page, but it is not showing in the expected part of the navigation. **Likely cause** The page may have been created under the wrong parent section, saved in the wrong place, or not included in the right version workflow. **Solution** Open the page settings and confirm its parent section and placement. Then review whether the page was saved correctly and included in the version you are checking. See: - [Managing Project Content from Drafts to Published Pages](/managing-project-content-from-drafts-to-published-pages) - [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) ### Preview and public content do not match **Symptom** The page looks correct in preview, but the public page shows older or different content. **Likely cause** You may be viewing a draft in preview while the public site is still showing the last released version. You may also be checking the wrong version. **Solution** Check the page’s publication state and confirm which version you opened. Refresh the public page and compare again. If needed, verify that the correct version was published. See: - [Understanding Document Preview and Public Page Checks](/understanding-document-preview-and-public-page-checks) - [Running a Documentation Release From Draft to Publication](/running-a-documentation-release-from-draft-to-publication) ## Version, Review, and Release Issues ### A version is missing from the version list **Symptom** You expect to see a version in Atloria, but it is not listed. **Likely cause** You may be in the wrong project, the list may be filtered, or the version may not have been saved as expected. **Solution** Confirm the project name first. Then clear any filters and refresh the version list. If the version still does not appear, return to the version details or generation area to confirm it was created successfully. See: - [Understanding Documentation Version Workspaces](/understanding-documentation-version-workspaces) - [Managing Project Version Workspaces](/managing-project-version-workspaces) ### Request review is unavailable **Symptom** You cannot request review for a version. **Likely cause** The version may not be saved yet, may already be in review, or may still be missing required details. **Solution** Open the version details and confirm the version has been saved. Check for empty required fields such as title, description, owner, or other workflow details. Save your changes and try again. See: - [Requesting and Completing Version Reviews](/requesting-and-completing-version-reviews) - [Preparing Versions for Review and Approval](/preparing-versions-for-review-and-approval) ### Approve or Reject is missing **Symptom** You are reviewing a version, but approval actions are not available. **Likely cause** The version may not be in a reviewable state, the review may already be closed, or your role may not allow review decisions. **Solution** Open the version review page and check the current status. If the version is still a draft or already has a final decision, review actions may not appear. Also confirm that your Atloria role includes reviewer access. See: - [Managing Version Review Decisions and Approvals](/managing-version-review-decisions-and-approvals) - [Managing Version Review Feedback and Follow Up](/understanding-version-review-feedback-and-follow-up) - [Publishing a Project from Setup to Public Release](/publishing-a-project-from-setup-to-public-release) ### The Review option is missing **Symptom** You expect to review a version, but the **Review** option is not shown. **Likely cause** The version may still be in **Draft** or **In progress**, or you may be looking at the wrong version. **Solution** Open the version detail page and check the status badge near the top. Make sure you selected the correct version and project. See: - [Managing Version Lists Statuses and Comparisons](/managing-version-lists-statuses-and-comparisons) ### A comparison shows no differences **Symptom** You compare two versions, but Atloria shows no changes. **Likely cause** You may have selected the same version twice, chosen nearly identical versions, or opened the comparison before the latest version was fully ready. **Solution** Check the version selectors at the top of the comparison view. Make sure the source and target versions are different and are the versions you intended to compare. If needed, return later after the latest version is fully available. See: - [Working with Version Comparison Views](/working-with-version-comparison-views) - [Comparing Documentation Versions for Release Decisions](/comparing-documentation-versions-for-release-decisions) - [Comparing Version Changes for Release Decisions](/comparing-version-changes-for-release-decisions) ### Export validation fails even though the version looks complete **Symptom** A version appears ready, but Atloria still blocks export. **Likely cause** A hidden child page, unpublished page, or missing required page detail may still be preventing validation. **Solution** Review child pages under approved parent pages and confirm that all required page details are filled in. Check that every needed page is assigned correctly and included in the intended publish state. See: - [Validating Export Readiness for Documentation Versions](/validating-export-readiness-for-documentation-versions) ### Pages are missing after publication **Symptom** You published a version, but some pages do not appear in the public documentation. **Likely cause** The missing pages may not have been included in the released version, may not be published, or may belong to a different audience or visibility setup. **Solution** Check the published version first, then review the missing pages in the project workspace. Confirm that each page was included in the correct release and is set up for the intended public visibility. See: - [Running a Documentation Release From Draft to Publication](/running-a-documentation-release-from-draft-to-publication) - [Running a Project from Setup to Public Documentation Release](/running-a-project-from-setup-to-public-documentation-release) - [Reviewing Public Audience Pages Before Launch](/reviewing-public-audience-pages-before-launch) ## Audience and Public View Issues ### An audience does not appear in the editor **Symptom** You want to assign an audience, but it is not available while editing a page. **Likely cause** The audience may not exist in the current project, or it may have been created in a different project. **Solution** Return to the project’s **Audiences** area and confirm that the audience exists there. If needed, create it in the correct project and then return to the page editor. See: - [Managing Project Audiences for Targeted Documentation](/managing-project-audiences-for-targeted-documentation) - [Defining Audiences for Targeted Documentation](/defining-audiences-for-targeted-documentation) ### An audience slug is rejected **Symptom** Atloria does not accept the audience slug you entered. **Likely cause** Another audience may already be using the same slug. **Solution** Compare the slug with the rest of your audience list and choose a unique value. See: - [Defining Audiences for Targeted Documentation](/defining-audiences-for-targeted-documentation) ### The public page does not change when I switch audiences **Symptom** You choose a different audience, but the page still looks the same. **Likely cause** The audience change may not have fully applied, or you may be checking the wrong page or view. **Solution** Refresh the page, reselect the intended audience, and compare the navigation, title, and visible sections again. Also confirm that you opened the published public page rather than a private workspace view. See: - [Reviewing Audience Specific Pages in Public Documentation](/reviewing-audience-specific-pages-in-public-documentation) - [Reading Audience Tailored Documentation](/reading-audience-tailored-documentation) ### A page appears under the wrong audience **Symptom** A page is visible in the wrong audience experience. **Likely cause** The page may be assigned to the wrong audience, grouped under the wrong section, or published in the wrong place. **Solution** Review the page’s audience assignment, navigation group, and publication setup. Correct the placement, then check the public view again. See: - [Planning Audience Specific Documentation Experiences](/planning-audience-specific-documentation-experiences) - [Reviewing Public Audience Pages Before Launch](/reviewing-public-audience-pages-before-launch) ## Screenshot and Media Issues ### The screenshot shows the wrong page **Symptom** You captured a screenshot, but it shows the wrong content. **Likely cause** The page address may be incorrect, incomplete, or redirecting somewhere else. **Solution** Recheck the **URL** field and confirm that it points to the exact page you want. Open the page directly first if needed, then capture again. See: - [Capturing Website Screenshots for Documentation](/capturing-website-screenshots-for-documentation) - [Capturing and Saving Screenshots for Documentation](/capturing-and-saving-screenshots-for-documentation) ### The screenshot is blank, partial, or incomplete **Symptom** The image is missing content or appears unfinished. **Likely cause** The page may not have fully loaded before the capture was taken. **Solution** Return to the capture screen, wait until the page is fully loaded in the state you want to show, and then capture again. See: - [Capturing Website Screenshots and Saving Reusable Assets](/capturing-website-screenshots-and-saving-reusable-assets) - [Capturing Website Screenshots for Documentation](/capturing-website-screenshots-for-documentation) ### A screenshot is missing from a page or library **Symptom** You expect to see an image, but it is not there. **Likely cause** The image may have been moved, renamed, saved in the wrong folder, or hidden by filters. **Solution** Check filenames, folder placement, and any active filters such as project, version, locale, or approval status. Also confirm that you are reviewing the correct version. See: - [Managing Enterprise Screenshot Libraries](/managing-enterprise-screenshot-libraries) - [Managing Screenshot Workflows Across Projects and Versions](/managing-screenshot-workflows-across-projects-and-versions) - [Reviewing Version Screenshots Before Release](/reviewing-version-screenshots-before-release) ### A screenshot looks outdated **Symptom** The screenshot does not match the current Atloria layout or release. **Likely cause** The image may come from an older version or an earlier workflow state. **Solution** Check where the image came from and compare it with the current version label and page state. Replace outdated images before release. See: - [Checking Screenshot Readiness Before Version Release](/checking-screenshot-readiness-before-version-release) ## Support Agent and AI Issues ### A message will not send in a support conversation **Symptom** You type a message, but it does not send. **Likely cause** The message field may not be ready, the send action may be unavailable, or the screen may still be loading. **Solution** Make sure your text is still in the input field. Check whether the **Send** action is available. Look for any visible error message and try again after the screen finishes loading. See: - [Chatting with Support Agents and Managing Conversations](/chatting-with-support-agents-and-managing-conversations) ### A reply appears in the wrong conversation **Symptom** You see your message or Atloria’s reply in a different thread than expected. **Likely cause** The wrong conversation may be selected in the history list. **Solution** Check the highlighted thread and conversation header before sending another message. Open the correct thread, then continue there. See: - [Managing Agent Conversations and Chat History](/managing-agent-conversations-and-chat-history ## Error Messages This guide helps you understand common error messages in Atloria, what they usually mean, and what to do next. Use the exact message you see on screen to find the closest match below. If the wording in Atloria is slightly different, choose the item with the same meaning. ## Account Access ### Invalid email or password **What it means** Atloria could not match the email address and password you entered to a valid account. **How to resolve it** - Re-enter your **Email** carefully - Re-enter your **Password** carefully - Make sure you are using the **Sign in** page, not the **Register** page - Try your password again without extra spaces - If you no longer know your password, use **Forgot password** For step-by-step help, see [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems) and [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account). ### Session expired **What it means** Your signed-in session is no longer active. This can happen if Atloria has been open for a while or if your session did not stay active after sign-in. **How to resolve it** - Sign in again - Reload the page after signing in - Try opening the page you wanted one more time - If Atloria keeps sending you back to **Sign in**, sign out fully and sign back in For related help, see [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation). ### You do not have access to this page **What it means** Your Atloria account can sign in, but it does not have permission to open the page or workspace you selected. **How to resolve it** - Confirm you signed in with the correct account - Return to the project or admin area and try again - Ask a workspace administrator to review your role or project access - If you recently received access, sign out and sign back in For more help, see [Using the Admin Workspace](/using-the-admin-workspace) and [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions). ## Admin and Access Management ### User not found **What it means** Atloria could not find a matching person in the current user list or search results. **How to resolve it** - Search again using the person’s full name - Try their email address - Clear any active filters such as status, role, or admin access - Confirm you are searching in the correct workspace For more help, see [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions). ### Unable to update permissions **What it means** Atloria could not save the permission change you tried to make. **How to resolve it** - Check that you have permission to manage access - Review the selected role or access setting - Refresh the page and try the change again - Confirm you are editing the correct user in the correct workspace For related guidance, see [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions). ## Projects ### Project not found **What it means** Atloria cannot open the project you selected. The project may be hidden by your current view, unavailable to your account, or no longer available. **How to resolve it** - Return to the **Projects** list - Clear the search box - Remove filters - Check sorting - Confirm you are signed in to the correct account - Ask a project owner whether you still have access For more help, see [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) and [Managing Project Workspaces and Recent Activity](/managing-project-workspaces-and-recent-activity). ### Unable to load project dashboard **What it means** Atloria could not show the project dashboard as expected. **How to resolve it** - Refresh the page - Confirm you opened the correct project - Return to the project list and open it again - Check whether filters or view settings are affecting what you see For related help, see [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards). ## Document Editor ### Page could not be saved **What it means** Atloria could not save your page changes. A required detail may be missing, or the page setup may need attention. **How to resolve it** - Check the page **Title** - Check the page **Slug** - Review the page location or parent page - Look for any highlighted required fields - Save again after fixing missing details For more help, see [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) and [Managing Project Content from Drafts to Published Pages](/managing-project-content-from-drafts-to-published-pages). ### Slug already in use **What it means** Another page or audience in Atloria is already using that slug. **How to resolve it** - Change the slug to something more specific - Compare it with similar page or audience names - Save again after updating the slug For page help, see [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages). For audience help, see [Defining Audiences for Targeted Documentation](/defining-audiences-for-targeted-documentation). ### Preview does not match published page **What it means** You are likely viewing draft changes in preview while the public page is still showing an older released version. **How to resolve it** - Check the page’s publication state - Confirm which version you are previewing - Open the public page again and refresh it - Make sure the intended version has actually been published For more help, see [Understanding Document Preview and Public Page Checks](/understanding-document-preview-and-public-page-checks). ## Audiences ### Audience not found **What it means** Atloria cannot find the audience you expected in the current project. **How to resolve it** - Confirm the audience was created in this project - Return to the project’s **Audiences** area and check the list - Clear filters or search terms - Make sure you are not confusing audiences from another project For related help, see [Managing Project Audiences for Targeted Documentation](/managing-project-audiences-for-targeted-documentation) and [Defining Audiences for Targeted Documentation](/defining-audiences-for-targeted-documentation). ### Audience slug is already in use **What it means** The audience identifier must be unique, and the one you entered is already taken. **How to resolve it** - Review the existing audience list - Choose a different slug - Keep the new slug short and clearly different from existing ones For more help, see [Defining Audiences for Targeted Documentation](/defining-audiences-for-targeted-documentation). ## Versions and Release Workflow ### Request review is unavailable **What it means** Atloria is not allowing the version to move into review yet. The version may be missing required details or may not be in the right state. **How to resolve it** - Save the version first - Review the version title, description, owner, and other required details - Confirm the version is not already in review - Return to the version page and try again For more help, see [Requesting and Completing Version Reviews](/requesting-and-completing-version-reviews) and [Preparing Versions for Review and Approval](/preparing-versions-for-review-and-approval). ### Approve or Reject is unavailable **What it means** The version is not currently reviewable by you, or the review is already complete. **How to resolve it** - Check the version status - Confirm the version is in a review stage - Make sure you are an assigned reviewer or have the right role - Refresh the review page and check again For more help, see [Managing Version Review Decisions and Approvals](/managing-version-review-decisions-and-approvals). ### Review option is missing **What it means** Atloria is not showing review actions because the version is still too early in the workflow or you are viewing the wrong version. **How to resolve it** - Open the version details page - Check the status badge near the top - Confirm you are in the correct project - Make sure you opened the intended version, not an older draft For more help, see [Managing Version Lists Statuses and Comparisons](/managing-version-lists-statuses-and-comparisons) and [Understanding Documentation Version Workspaces](/understanding-documentation-version-workspaces). ### Validation failed **What it means** Atloria found something in the version that is preventing export or release readiness. **How to resolve it** - Check for unpublished child pages - Review required page details - Confirm the correct version assignment on included pages - Re-run the validation after fixing missing items For more help, see [Validating Export Readiness for Documentation Versions](/validating-export-readiness-for-documentation-versions). ### Export failed **What it means** Atloria could not complete the export using the current version or export settings. **How to resolve it** - Confirm the version passed validation - Recheck the selected project and version - Review export filters or scope - Try the export again after correcting any missing content or setup issues For more help, see [Validating Export Readiness for Documentation Versions](/validating-export-readiness-for-documentation-versions) and [Managing Audit Exports and Activity Records](/managing-audit-exports-and-activity-records). ### No differences found **What it means** Atloria is not showing any changes between the selected versions. In many cases, the same version was selected twice, or the two versions are nearly identical. **How to resolve it** - Check the source and target version selectors - Make sure you did not compare a version against itself - Confirm the latest changes were saved before comparison - Reopen the comparison with the correct version pair For more help, see [Working with Version Comparison Views](/working-with-version-comparison-views), [Comparing Documentation Versions for Release Decisions](/comparing-documentation-versions-for-release-decisions), and [Comparing Version Changes for Release Decisions](/comparing-version-changes-for-release-decisions). ### Compare option is missing **What it means** Atloria cannot compare versions until there are at least two saved versions available, or your current view does not support the action. **How to resolve it** - Confirm the project has at least two saved versions - Refresh the version list - Open the correct project version area - Try again from the version workspace For more help, see [Comparing Documentation Versions for Release Decisions](/comparing-documentation-versions-for-release-decisions). ### Version not found **What it means** Atloria cannot find the version you expected in the current project or list view. **How to resolve it** - Confirm you are in the correct project - Refresh the version list - Clear filters or search terms - Check whether the version was saved successfully For more help, see [Managing Project Version Workspaces](/managing-project-version-workspaces) and [Understanding Documentation Version Workspaces](/understanding-documentation-version-workspaces). ### Version stuck in Queued or In Progress **What it means** Atloria has started the version process, but the status is not moving forward as expected. **How to resolve it** - Open the version details page - Refresh and compare the current status with the last updated time - Check whether the timeline is still changing - If nothing changes for a long time, review the result notes and rerun if appropriate For more help, see [Monitoring Version Generation Progress and Results](/monitoring-version-generation-progress-and-results) and [Generating Documentation Versions and Monitoring Results](/generating-documentation-versions-and-monitoring-results). ## Publishing and Public Documentation ### Page not available in public view **What it means** The page may exist in the project workspace but is not currently published in the public documentation view. **How to resolve it** - Confirm the page is included in the published version - Check the page’s visibility and publication state - Make sure you opened the public site, not a private workspace page - Review audience and navigation placement if the page should appear publicly For more help, see [Understanding Document Preview and Public Page Checks](/understanding-document-preview-and-public-page-checks), [Reviewing Public Audience Pages Before Launch](/reviewing-public-audience-pages-before-launch), and [Managing Technical Documentation Browsing and API Reading](/managing-technical-documentation-browsing-and-api-reading). ### Published pages are missing **What it means** Atloria published a version, but some expected pages are not visible. **How to resolve it** - Confirm the correct version was published - Check whether the missing pages were included in that version - Review page visibility and audience setup - Refresh the public page and test again For more help, see [Running a Documentation Release From Draft to Publication](/running-a-documentation-release-from-draft-to-publication) and [Running a Project from Setup to Public Documentation Release](/running-a-project-from-setup-to-public-documentation-release). ## Integrations ### Connection expired **What it means** Atloria no longer has active permission to use the connected provider. **How to resolve it** - Open the project integration page - Start the reauthorization flow - Complete the provider approval steps fully - Return to Atloria and refresh the page For more help, see [Reauthorizing and Disconnecting Git Integrations](/reauthorizing-and-disconnecting-git-integrations). ### Wrong account connected **What it means** Atloria was connected to a different provider account than the one you intended to use. **How to resolve it** - Disconnect the current connection if needed - Start the connection or reauthorization flow again - Make sure you choose the correct provider account before returning to Atloria For more help, see [Reauthorizing and Disconnecting Git Integrations](/reauthorizing-and ## First Time Login If this is your first time using Atloria, this guide will help you sign in and understand what happens next. ## Before You Begin Make sure you have: - The Atloria sign-in web address shared by your team - Your email address or username - Your temporary or permanent password - Access to your email if your team asks you to confirm your sign-in If you do not have your sign-in details yet, contact your Atloria administrator. For a full overview of account access options, see [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account). ## Open the Atloria Sign-In Page 1. Open your web browser. 2. Enter the Atloria web address provided by your team. 3. Wait for the Atloria sign-in page to load. You will usually see: - A sign-in form - A way to enter your email address or username - A password field - A sign-in button - In some cases, a link to create an account or reset your password If you want to understand the different entry pages you may see, read [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation). ## Enter Your Login Details 1. Type your email address or username. 2. Type your password. 3. Select **Sign In**. If your organization uses an extra sign-in step, follow the on-screen instructions to complete it. If you cannot sign in, forgot your password, or see an access message, go to [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems). ## What You See After Login After your first successful login, Atloria usually takes you to one of these places: ### Project List Many users first see a list of projects they can open. From here, you can: - View available projects - Open a project workspace - Start a new project if you have permission To learn more, see [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards). ### Admin Area If you are an administrator, Atloria may open in the admin area instead. From there, you may have access to: - Team activity - User access - Security review tools - Usage and performance information For an overview, see [Using the Admin Workspace](/using-the-admin-workspace). ## First-Time Setup You May Be Asked to Complete On your first login, Atloria may guide you through a short setup flow. What you see depends on your role and whether your team already set things up for you. ### Join or Open an Existing Project If your team already created projects, you may only need to: 1. Select a project from the list. 2. Open the project home. 3. Review the project sections available to you. To understand the project home area, see [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home). ### Create Your First Project If no project has been created yet and you have permission, Atloria may prompt you to create one. This usually includes: - Naming the project - Choosing how you want to set it up - Confirming basic project details For the full setup process, see [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding). If you need help deciding how to begin, read [Choosing Between Manual and Connected Project Setup](/choosing-between-manual-and-connected-project-setup). ## What to Do Next After your first login, your next step depends on what you need to do in Atloria. ### If You Need to Set Up a Project Start with: - [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding) - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) ### If You Need to Manage a Project Start with: - [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) - [Managing Project Settings and Website Options](/managing-project-settings-and-website-options) ### If You Need to Start Writing Documentation Start with: - [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) ### If You Are an Administrator Start with: - [Using the Admin Workspace](/using-the-admin-workspace) - [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions) - [Reviewing Security and Audit Controls](/reviewing-security-and-audit-controls) ## Tips for a Smooth First Login - Use the exact Atloria web address shared by your team - Enter your login details carefully - Keep your password in a secure place - Follow any extra sign-in steps shown on screen - If something does not look right, ask your Atloria administrator before continuing ## Need Help? If your first login does not work: - Check that your email address or username is correct - Re-enter your password carefully - Try the password reset option if it is available - Contact your Atloria administrator if you still cannot access your account For sign-in help, see [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems). ## Frequently Asked Questions ## General ### What is Atloria used for? Atloria helps teams turn project knowledge into organized documentation that can be reviewed, shared, and published. You can use it to create projects, write and manage docs, generate versions, and publish public documentation. See [Running a Project from Setup to Public Documentation Release](/running-a-project-from-setup-to-public-documentation-release). ### Who should use Atloria? Atloria is designed for teams that need a clear place to manage internal and public documentation. Writers, reviewers, project owners, administrators, and support teams can all use different parts of Atloria based on their role. See [Using Project Home to Coordinate Documentation Work](/using-project-home-to-coordinate-documentation-work). ### Do I need to create an account before I can use Atloria? Yes, you usually need an Atloria account before you can enter private workspaces, projects, or admin areas. If you are new, register first, then sign in with the same details next time. See [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account). ### What happens after I sign in? After you sign in, Atloria usually returns you to the page you were trying to open. If you started from a direct link to a project or admin page, you should be sent back there automatically. See [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems). ### Why does Atloria keep sending me back to the sign in page? This usually means your sign-in did not fully complete or your session did not stay active. First confirm that you signed in with the correct account, then try opening the page again. See [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation). ## Account and Access ### How do I sign in to Atloria? Start on the Atloria public site and select **Sign in** from the top navigation. Enter your email and password, then continue to your workspace. See [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems). ### How do I create a new Atloria account? Open the access page and choose **Register**. Fill in your name, email, and password carefully so you can use the same details the next time you sign in. See [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account). ### What should I do if I forgot my password? Use the **Forgot password** link on the Atloria sign in page. Follow the reset steps, then return and sign in with your new password. See [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems). ### Why can’t I see the Admin area? In Atloria, the Admin area only appears for people with the right access. Make sure you are signed in with the correct account, and if your access was just updated, sign out and sign back in. See [Using the Admin Workspace](/using-the-admin-workspace). ### Why can’t I find a user or update someone’s access? This is often caused by search terms or filters hiding the person you need. Try searching by full name or email, then clear any active filters before trying again. See [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions). ## Projects and Setup ### How do I get started with a new project in Atloria? Most teams begin by creating a project and completing the setup steps for that workspace. Depending on your team’s process, you may connect an existing source or start with a manual setup. See [Running a Project from Setup to Public Documentation Release](/running-a-project-from-setup-to-public-documentation-release). ### Why can’t I find my project in the Projects list? The project may be hidden by search text, filters, or sorting choices. Clear the search box, remove filters, and check that you are in the correct workspace view. See [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards). ### What should I do if the project dashboard does not look right? Start by confirming that you opened the correct project, especially if several projects have similar names. Then review the visible filters and linked work areas to make sure you are not looking at a narrowed view. See [Using Project Home to Coordinate Documentation Work](/using-project-home-to-coordinate-documentation-work). ### Can I connect Atloria to a Git provider? Yes, Atloria supports project connections to supported Git providers. If a connection expires or points to the wrong account, you can reauthorize or disconnect it from the project integration area. See [Reauthorizing and Disconnecting Git Integrations](/reauthorizing-and-disconnecting-git-integrations). ## Writing and Managing Documentation ### How do I create or edit documentation pages? Open the document area for your project and create a new page or edit an existing one. If a page will not save, check that required details such as title or location are filled in. See [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages). ### Why doesn’t my new page appear where I expected? In Atloria, a page may be saved under a different parent section or not yet included in the right version flow. Check the page location, save state, and navigation placement before creating it again. See [Managing Project Content from Drafts to Published Pages](/managing-project-content-from-drafts-to-published-pages). ### Why does the preview look different from the public page? Preview can show newer draft changes while the public page may still show the last released version. Check the page’s publication state and make sure you are looking at the intended version in both places. See [Understanding Document Preview and Public Page Checks](/understanding-document-preview-and-public-page-checks). ## Versions, Review, and Release ### How do documentation versions work in Atloria? Versions help your team group documentation changes into reviewable and publishable releases. You can generate, compare, review, approve, export, and publish versions as they move through the release cycle. See [Managing Documentation Versions Across the Release Cycle](/managing-documentation-versions-across-the-release-cycle). ### What should I do if a version is missing from the version list? First confirm that you are in the correct project, because version lists are project-specific in Atloria. Then check whether filters or the current status view are hiding the version. See [Understanding Documentation Version Workspaces](/understanding-documentation-version-workspaces). ### Why can’t I request review for a version? This usually means the version is missing required details or is not in the right state yet. Open the version details, fill in any required information, save your changes, and try again. See [Requesting and Completing Version Reviews](/requesting-and-completing-version-reviews). ### Why can’t a reviewer approve or reject a version? Approval actions may be unavailable if the version is not currently in review or if the reviewer does not have the right access. Check the version status first, then confirm the reviewer’s role and permissions. See [Managing Version Review Decisions and Approvals](/managing-version-review-decisions-and-approvals). ### Why does the comparison view show no differences? This often happens when the same version was selected on both sides or when the wrong pair was chosen. Review the version selectors at the top of the comparison screen and choose the intended source and target versions. See [Comparing Version Changes for Release Decisions](/comparing-version-changes-for-release-decisions). ### What should I check before publishing a version? Make sure the correct version was reviewed, approved if needed, and selected for release. After publishing, open the public view and confirm readers are seeing the intended version. See [Running a Documentation Release From Draft to Publication](/running-a-documentation-release-from-draft-to-publication). ## Audiences and Public Documentation ### What are audiences in Atloria? Audiences help you organize content for different reader groups. You can use them to shape navigation, tailor page visibility, and guide readers to the most relevant version of the documentation. See [Defining Audiences for Targeted Documentation](/defining-audiences-for-targeted-documentation). ### Why is a page showing under the wrong audience? This usually means the page was assigned to the wrong audience or placed in the wrong section. Review the page’s audience setup and then confirm the public view is using the audience you intended to test. See [Planning Audience Specific Documentation Experiences](/planning-audience-specific-documentation-experiences). ### Why can’t I find a page in the public documentation? Start with the public navigation and check whether you are in the correct version and audience view. If the page still does not appear, it may not be published in the location you expected. See [Using Public Navigation to Browse Documentation](/using-public-navigation-to-browse-documentation). ## Screenshots and Media ### How do I capture screenshots for documentation in Atloria? Open the screenshot capture area, enter the page address you want to capture, and save the image for later use in your docs. Before capturing, make sure the page is fully loaded and showing the exact content you want readers to see. See [Capturing Screenshots from Web Pages](/capturing-screenshots-from-web-pages). ### Why is my screenshot blank, incomplete, or showing the wrong page? This is usually caused by an incorrect page address or capturing before the page finished loading. Recheck the URL, open the page again, and confirm the visible content before taking another screenshot. See [Capturing Website Screenshots for Documentation](/capturing-website-screenshots-for-documentation). ### Why can’t I find a screenshot I already saved? Many missing screenshots are actually hidden by filters such as project, version, locale, or approval status. Review those filters first, then check whether the image was saved under a different version or location. See [Managing Screenshot Workflows Across Projects and Versions](/managing-screenshot-workflows-across-projects-and-versions). ## AI and Support Agents ### What are support agents in Atloria? Support agents are AI helpers that answer questions using your project documentation as their source. Teams use them to support readers, test documentation coverage, and manage question-and-answer workflows. See [Chatting with Support Agents and Managing Conversations](/chatting-with-support-agents-and-managing-conversations). ### Why won’t my message send to a support agent? Check whether your text is still in the message field and whether the send action is available. If you see an error or the conversation is still loading, wait a moment and try again. See [Chatting with Support Agents and Managing Conversations](/chatting-with-support-agents-and-managing-conversations). ### Why does my support agent reply seem wrong or appear in the wrong conversation? This often happens when the wrong conversation thread is selected or when you continue an older discussion by mistake. Check the highlighted conversation in the history list before sending another message. See [Managing Agent Conversations and Chat History](/managing-agent-conversations-and-chat-history). ### Where can I check AI usage or request history? Atloria provides usage and request views so teams can review activity over time. If the numbers look incomplete, first check the date range and any project, team, or user filters. See [Monitoring AI Usage and Request History](/monitoring-ai-usage-and-request-history). ## Analytics, Audit, and Export ### Why does analytics data look empty or incomplete? In Atloria, this is usually caused by filters, date range choices, or viewing a narrower scope than expected. Check the selected time period and confirm whether you are looking at one project or all projects. See [Analyzing Documentation Performance Across Projects](/analyzing-documentation-performance-across-projects). ### Why can’t I find the audit records I expected? Audit records are often hidden by date, user, action, or project filters. Start from the audit history screen, widen the date range, and remove filters one at a time until the missing records appear. See [Reviewing Audit History and Exporting Compliance Records](/reviewing-audit-history-and-exporting-compliance-records). ### What should I do if an export looks incomplete? Go back to the source screen and confirm that the visible list matches what you expected to export. In Atloria, incomplete exports are often caused by filters or exporting the wrong project or version scope. See [Managing Audit Exports and Activity Records](/managing-audit-exports-and-activity-records). ### Why does export validation fail even when the version looks ready? A version can still fail validation if a child page is unpublished, required page details are missing, or some content was not assigned correctly. Review the version carefully and fix the remaining page-level issues before trying again. See [Validating Export Readiness for Documentation Versions](/validating-export-readiness-for-documentation-versions). ## Getting Help If you are not sure where to start, this page helps you find the right support resource in Atloria. ## Start with Help & Troubleshooting If something is not working as expected, go first to the Help & Troubleshooting section. It is the best place to find step-by-step guidance for common problems, account access issues, setup questions, publishing problems, and other day-to-day issues. Use Help & Troubleshooting when you need to: - fix a problem in Atloria - understand an error message - check why a project, version, or document is not behaving as expected - find recovery steps before contacting support ## Check the FAQ If you have a quick question, the FAQ is often the fastest place to look. It is useful for common questions about how Atloria works, what certain options mean, and where to find key actions. Use the FAQ when you want: - a short answer to a common question - clarification before starting a task - help understanding basic Atloria terms and actions ## Find help by topic If you already know what area you need help with, go directly to the related documentation section: - Account access: [Authentication](/authentication) - Setting up a new project: [Project Onboarding](/project-onboarding) - Managing existing projects: [Project Management](/project-management) - Creating and updating content: [Document Editor](/document-editor) - Working with documentation releases: [Documentation Versions](/documentation-versions) - Controlling who can view versions: [Version Access Control](/version-access-control) - Reviewing and approving releases: [Approval Workflow](/approval-workflow) - Connecting outside services: [Integrations](/integrations) - Managing audiences: [Audiences](/audiences) - Capturing images for documentation: [Screenshot Capture](/screenshot-capture) - Publishing and reading public docs: [Public Documentation Viewer](/public-documentation-viewer) - Using AI-powered help experiences: [Support Agents](/support-agents) - Reviewing activity records: [Audit Trail](/audit-trail) - Checking usage and performance: [Enterprise Analytics](/enterprise-analytics) - Exporting records and documentation: [Export Center](/export-center) - Managing AI-related options: [AI Settings](/ai-settings) ## When to contact support Contact your support channel if: - you cannot sign in or access the right workspace - a setup step is blocked and the documentation does not solve it - publishing, approvals, or version access are not working as expected - you believe a permission or access setting is incorrect - you need help with account, billing, or workspace ownership questions - you have reviewed Help & Troubleshooting and still need assistance When you contact support, include: - what you were trying to do - what happened instead - the project or workspace involved - any message shown in Atloria - the steps you already tried This helps the support team respond faster. ## For team-specific help Some questions are best handled by your Atloria administrator, project administrator, or documentation manager. Contact your internal team first if you need: - access to a workspace or project - permission to edit, approve, or publish - help choosing the right audience or version - guidance on your team’s review or publishing process ## If you are reading public documentation If you are using a public documentation site powered by Atloria, start with the published navigation, search, and version options on that site. If the information you need is missing or unclear, contact the company that published the documentation, since they manage the content you are viewing. ## Recommended path If you are unsure which resource to use, follow this order: 1. Check the relevant feature section in the documentation. 2. Review Help & Troubleshooting. 3. Look through the FAQ. 4. Contact your internal Atloria administrator or team owner. 5. Reach out through your support channel. ## About This Path This learning path is for the **Documentation Manager** in Atloria. If you are responsible for documentation quality, structure, publishing, and ongoing upkeep across one or more projects, this path will help you build confidence step by step. You will start with account access and basic navigation, then move into project setup, content work, version and review workflows, audience planning, screenshots, analytics, exports, technical documentation, and support agent features. This order matters because Documentation Managers usually need to understand how Atloria is organized before they can guide content, coordinate releases, and improve documentation across teams. ## Prerequisites Before you begin, make sure you: - Have your Atloria sign-in details ready - Can access the right Atloria workspace for your role - Know which project or projects you are expected to manage - Have permission to review project settings, versions, and publishing-related areas - Are ready to follow the documents in order, especially if you are new to Atloria ## Your Learning Journey 1. [Accessing and Registering Your Atloria Account](doc:/accessing-and-registering-your-atloria-account) — Start here to understand how new and returning users enter Atloria and reach the right account pages. **6 min read | Beginner** 2. [Signing In to Atloria and Solving Access Problems](doc:/signing-in-to-atloria-and-solving-access-problems) — Learn how to sign in smoothly and recover quickly from common access issues. **5 min read | Beginner** 3. [Using the Admin Workspace](doc:/using-the-admin-workspace) — This gives you an early view of the administrative areas a Documentation Manager may need for oversight. **6 min read | Beginner** 4. [Managing User Access and Administrative Permissions](doc:/managing-user-access-and-administrative-permissions) — Useful for understanding who can do what in Atloria and how access affects documentation work. **8 min read | Intermediate** 5. [Monitoring Administrative Analytics and Activity](doc:/monitoring-administrative-analytics-and-activity) — Helps you see broader activity patterns that matter when managing documentation across teams. **8 min read | Beginner** 6. [Working with Project Lists and Dashboards](doc:/working-with-project-lists-and-dashboards) — Learn how to find projects quickly and understand their current state. **7 min read | Beginner** 7. [Creating Projects and Completing Onboarding](doc:/creating-projects-and-completing-onboarding) — Important when you need to launch new documentation work with a strong starting structure. **8 min read | Beginner** 8. [Managing Project Settings and Website Options](doc:/managing-project-settings-and-website-options) — Shows how project choices shape internal work and public delivery. **8 min read | Intermediate** 9. [Analyzing Project Performance and Activity](doc:/analyzing-project-performance-and-activity) — Helps you use project signals to guide maintenance and publishing decisions. **8 min read | Intermediate** 10. [Creating and Editing Documentation Pages](doc:/creating-and-editing-documentation-pages) — This is the core content work every Documentation Manager needs to understand. **8 min read | Beginner** 11. [Managing Documentation Versions Across the Release Cycle](doc:/managing-documentation-versions-across-the-release-cycle) — Gives you the big picture of how documentation moves from draft toward release. **9 min read | Intermediate** 12. [Generating New Documentation Versions](doc:/generating-new-documentation-versions) — Learn how new versions are created and when they are ready for the next step. **7 min read | Beginner** 13. [Reviewing and Approving Documentation Versions](doc:/reviewing-and-approving-documentation-versions) — Essential for managing approval flow and keeping releases under control. **8 min read | Intermediate** 14. [Controlling Version Visibility and Export Options](doc:/controlling-version-visibility-and-export-options) — Helps you decide who can see a version and how it can be shared. **7 min read | Intermediate** 15. [Defining Audiences for Targeted Documentation](doc:/defining-audiences-for-targeted-documentation) — Important for tailoring content to different reader groups. **6 min read | Beginner** 16. [Using Public Navigation to Browse Documentation](doc:/using-public-navigation-to-browse-documentation) — Lets you see Atloria from the reader’s point of view. **6 min read | Beginner** 17. [Viewing Public Documentation by Audience](doc:/viewing-public-documentation-by-audience) — Helps you confirm that audience-specific experiences make sense to readers. **7 min read | Beginner** 18. [Managing Screenshots for Documentation](doc:/managing-screenshots-for-documentation) — Useful for keeping visual content organized and ready for release work. **8 min read | Beginner** 19. [Capturing Screenshots from Web Pages](doc:/capturing-screenshots-from-web-pages) — Shows how to create clean screenshots that support clear documentation. **6 min read | Beginner** 20. [Creating and Managing AI Support Agents](doc:/creating-and-managing-ai-support-agents) — Helpful if your documentation is also used to support guided help experiences. **8 min read | Beginner** 21. [Chatting with Support Agents and Managing Conversations](doc:/chatting-with-support-agents-and-managing-conversations) — Lets you test whether support responses match the documentation you manage. **7 min read | Beginner** 22. [Configuring AI Settings for Your Organization](doc:/configuring-ai-settings-for-your-organization) — Gives you the context needed to understand how organization-wide AI choices affect documentation work. **8 min read | Intermediate** 23. [Monitoring AI Usage and Request History](doc:/monitoring-ai-usage-and-request-history) — Helps you review how AI-supported work is being used and monitored in Atloria. **8 min read | Beginner** 24. [Analyzing Documentation Performance Across Projects](doc:/analyzing-documentation-performance-across-projects) — Important for Documentation Managers who need to compare results across multiple projects. **8 min read | Intermediate** 25. [Exporting Audit and Version Records](doc:/exporting-audit-and-version-records) — Useful when you need release records, history, or review evidence. **7 min read | Beginner** 26. [Exporting Documentation and Related Records](doc:/exporting-documentation-and-related-records) — Helps you prepare documentation outputs for sharing, reporting, or retention. **8 min read | Intermediate** 27. [Reading API and Technical Reference Pages](doc:/reading-api-and-technical-reference-pages) — Gives you a practical view of technical reference content that may sit beside your authored documentation. **6 min read | Beginner** 28. [Uploading and Parsing Code in the Workspace](doc:/uploading-and-parsing-code-in-the-workspace) — Useful for understanding how technical source material can support documentation work. **8 min read | Beginner** 29. [Viewing Supported Languages and Parser Coverage](doc:/viewing-supported-languages-and-parser-coverage) — Helps you judge whether Atloria can support the technical content your projects need. **6 min read | Beginner** 30. [Publishing a Project from Setup to Public Release](doc:/publishing-a-project-from-setup-to-public-release) — Finish with the full end-to-end workflow so you can connect everything into one release process. **12 min read | Intermediate** ## What You'll Be Able to Do After completing this path, you will be able to: - Access Atloria confidently and help others get into the right workspace - Understand how Atloria is organized across admin, project, content, and public reading areas - Create and set up documentation projects with better early decisions - Manage documentation pages and keep content moving toward release - Oversee version creation, review, approval, and visibility choices - Plan and validate audience-specific documentation experiences - Review public documentation the way readers will see it - Organize and manage screenshots as part of documentation quality - Use analytics to monitor documentation performance across projects - Export documentation, version records, and audit-related information when needed - Understand how technical reference content and code-based inputs support documentation work - Evaluate and support AI-based help experiences that rely on Atloria documentation - Coordinate a full documentation release from setup through public publishing ## About This Path This learning path is for the **Project Administrator** in Atloria. It is designed for people who set up projects, manage access, connect outside services, review settings, and keep documentation operations running smoothly. You will move from basic account access, into admin controls, then into project setup, version work, publishing, AI settings, integrations, and ongoing oversight. This order matters because a Project Administrator usually needs to **get access first, understand the admin areas next, and then manage projects and release work with confidence**. ## Prerequisites Before you begin, make sure you: - Have your Atloria sign-in details ready - Can access the email inbox used for your Atloria account - Know whether you already have administrator access in Atloria - Have any project names, team details, or setup notes you may need - Know which outside services your team plans to connect - Set aside time to follow the path in order, especially if you are new to Atloria ## Your Learning Journey 1. [Accessing and Registering Your Atloria Account](doc:/accessing-and-registering-your-atloria-account) — Start here to understand how new and returning users enter Atloria and reach the right account access pages. **6 min read | Beginner** 2. [Signing In to Atloria and Solving Access Problems](doc:/signing-in-to-atloria-and-solving-access-problems) — This helps you sign in reliably and handle common access issues before you begin admin work. **5 min read | Beginner** 3. [Using the Admin Workspace](doc:/using-the-admin-workspace) — Learn where the main administrative areas live so you can move around Atloria with confidence. **6 min read | Beginner** 4. [Managing User Access and Administrative Permissions](doc:/managing-user-access-and-administrative-permissions) — As a Project Administrator, this is essential for understanding who can do what and how to manage access responsibly. **8 min read | Intermediate** 5. [Reviewing Security and Audit Controls](doc:/reviewing-security-and-audit-controls) — This shows you how to review sensitive activity and use Atloria’s oversight tools. **7 min read | Beginner** 6. [Monitoring Administrative Analytics and Activity](doc:/monitoring-administrative-analytics-and-activity) — Use this to understand overall activity and keep an eye on operational health in Atloria. **8 min read | Beginner** 7. [Working with Project Lists and Dashboards](doc:/working-with-project-lists-and-dashboards) — This introduces the main project views you will use to find, open, and monitor projects. **7 min read | Beginner** 8. [Creating Projects and Completing Onboarding](doc:/creating-projects-and-completing-onboarding) — Read this before starting any new project so your setup choices are clear from the beginning. **8 min read | Beginner** 9. [Choosing Between Manual and Connected Project Setup](doc:/choosing-between-manual-and-connected-project-setup) — This helps you choose the best setup path based on how your team works. **7 min read | Beginner** 10. [Managing Project Administration from the Project Home](doc:/managing-project-administration-from-the-project-home) — Learn how to use the project home area as your main control point for day-to-day administration. **7 min read | Beginner** 11. [Managing Project Settings and Website Options](doc:/managing-project-settings-and-website-options) — This matters because Project Administrators shape how each project is configured and presented. **8 min read | Intermediate** 12. [Connecting and Managing External Integrations](doc:/connecting-and-managing-external-integrations) — Use this when you need to connect outside services that support project workflows in Atloria. **7 min read | Beginner** 13. [Configuring Project Webhooks and Related Controls](doc:/configuring-project-webhooks-and-related-controls) — This is useful for managing project update behavior and related operational controls. **7 min read | Intermediate** 14. [Managing Documentation Versions Across the Release Cycle](doc:/managing-documentation-versions-across-the-release-cycle) — This gives you the big picture for how versions move from creation to release. **9 min read | Intermediate** 15. [Generating New Documentation Versions](doc:/generating-new-documentation-versions) — Learn how to create new versions and confirm they are ready for the next step. **7 min read | Beginner** 16. [Reviewing and Approving Documentation Versions](doc:/reviewing-and-approving-documentation-versions) — This helps you guide review decisions and keep releases moving. **8 min read | Intermediate** 17. [Controlling Version Visibility and Export Options](doc:/controlling-version-visibility-and-export-options) — Read this to manage who can see a version and how it can be shared. **7 min read | Intermediate** 18. [Managing Screenshots for Documentation](doc:/managing-screenshots-for-documentation) — This supports release quality by helping you manage the images used in documentation. **8 min read | Beginner** 19. [Defining Audiences for Targeted Documentation](doc:/defining-audiences-for-targeted-documentation) — This introduces audience setup so you can support targeted reader experiences. **6 min read | Beginner** 20. [Viewing Public Documentation by Audience](doc:/viewing-public-documentation-by-audience) — Use this to validate what different reader groups will actually see after release. **7 min read | Beginner** 21. [Creating and Managing AI Support Agents](doc:/creating-and-managing-ai-support-agents) — This is a strong starting point for using Atloria documentation in AI-assisted support experiences. **8 min read | Beginner** 22. [Configuring AI Settings for Your Organization](doc:/configuring-ai-settings-for-your-organization) — Project Administrators need this to understand organization-wide AI choices and controls. **8 min read | Intermediate** 23. [Setting Up and Maintaining AI Providers](doc:/setting-up-and-maintaining-ai-providers) — This helps you manage the provider settings that support AI features in Atloria. **6 min read | Beginner** 24. [Monitoring AI Usage and Request History](doc:/monitoring-ai-usage-and-request-history) — Read this to track usage, review activity, and support responsible oversight. **8 min read | Beginner** 25. [Analyzing Documentation Performance Across Projects](doc:/analyzing-documentation-performance-across-projects) — This helps you compare results across projects and spot where attention is needed. **8 min read | Intermediate** 26. [Exporting Audit and Version Records](doc:/exporting-audit-and-version-records) — Use this when you need to keep records, support reviews, or share release history. **7 min read | Beginner** 27. [Exporting Documentation and Related Records](doc:/exporting-documentation-and-related-records) — This rounds out your workflow by showing how to export the outputs and records tied to documentation work. **8 min read | Intermediate** ## What You'll Be Able to Do After completing this path, you will be able to: - Access Atloria, sign in, and recover from common access problems - Navigate the Admin workspace and find the right control areas quickly - Review user access and support permission decisions with confidence - Monitor security, audit activity, and administrative trends in Atloria - Find projects, open dashboards, and manage project work from the right starting points - Create new projects and choose the right onboarding approach - Update project settings, website options, and related operational controls - Connect and maintain outside services used in project workflows - Manage documentation versions from creation through review and release readiness - Control version visibility, sharing, and export-related decisions - Organize screenshots and support documentation quality checks - Define audiences and confirm audience-specific public views - Set up and oversee AI-related features, including agents, providers, and usage review - Compare documentation performance across projects and use that information to guide action - Export documentation, audit records, and version records for review, sharing, or retention ## About This Path This learning path is for the **Public Documentation Reader** in Atloria. It is designed for people who visit published documentation to learn about a product, move through pages confidently, switch between versions, and read content meant for a specific audience. You will start with the basics of finding your way around public documentation, then move into audience-specific reading, technical and reference content, and finally version-aware reading. This order matters because it helps you build confidence step by step: first understanding where things are, then learning how content changes based on audience, technical section, or version. ## Prerequisites Before you begin, it helps to: - Have a link to a published Atloria documentation site - Be ready to browse public pages in a web browser - Know which product, version, or audience you want to read about, if that applies - Start with a beginner mindset — this path assumes you are new to reading documentation in Atloria You do not need admin access or project setup experience for this path. ## Your Learning Journey 1. [Using Public Navigation to Browse Documentation](doc:/using-public-navigation-to-browse-documentation) — Learn the basic layout of published documentation in Atloria so you can move through pages without getting lost. **6 min read | Beginner** 2. [Viewing Public Documentation by Audience](doc:/viewing-public-documentation-by-audience) — Understand how Atloria shows different public content for different reader groups. **7 min read | Beginner** 3. [Reading API and Technical Reference Pages](doc:/reading-api-and-technical-reference-pages) — Get familiar with the kinds of technical reference pages you may see in published documentation. **6 min read | Beginner** 4. [Using API Reference Pages in Published and Project Views](doc:/using-api-reference-pages-in-published-and-project-views) — See how reference pages can appear in more than one reading context and how to make sense of them. **7 min read | Beginner** 5. [Understanding Entity Detail Pages in Technical Documentation](doc:/understanding-entity-detail-pages-in-technical-documentation) — Learn how detailed technical pages are organized so you can read them with confidence. **8 min read | Beginner** 6. [Browsing Published Documentation and Finding the Right Page](doc:/browsing-published-documentation-and-finding-the-right-page) — Practice locating the page you need within a published documentation set. **6 min read | Beginner** 7. [Reading Published API and Technical Documentation](doc:/reading-published-api-and-technical-documentation) — Build confidence moving between regular documentation and public technical sections in Atloria. **6 min read | Beginner** 8. [Using Public Navigation with Audience Specific Content](doc:/using-public-navigation-with-audience-specific-content) — Learn how navigation changes when the documentation is tailored for a specific audience. **7 min read | Beginner** 9. [Reviewing Audience Specific Pages in Public Documentation](doc:/reviewing-audience-specific-pages-in-public-documentation) — Understand how to check whether the pages you are seeing match the intended audience view. **6 min read | Beginner** 10. [Viewing Technical Entities and Related Reference Details](doc:/viewing-technical-entities-and-related-reference-details) — Learn how to open and read detailed technical reference pages and their related information. **6 min read | Beginner** 11. [Managing Reader Navigation in Published Documentation](doc:/managing-reader-navigation-in-published-documentation) — Strengthen your ability to move through public documentation in a clear, repeatable way. **6 min read | Beginner** 12. [Finding Content Through Public Documentation Structure](doc:/finding-content-through-public-documentation-structure) — Understand how page groups and reading structure help you find the right content faster. **6 min read | Beginner** 13. [Finding and Reading Content in Published Documentation](doc:/finding-and-reading-content-in-published-documentation) — Improve how you choose pages, stay oriented, and read efficiently in Atloria. **6 min read | Beginner** 14. [Reading Audience Tailored Documentation](doc:/reading-audience-tailored-documentation) — Learn how to confirm that you are reading the right content for your audience. **6 min read | Beginner** 15. [Understanding Version Access Modes and Reader Outcomes](doc:/understanding-version-access-modes-and-reader-outcomes) — See how visibility and version settings affect what public readers can access. **7 min read | Intermediate** 16. [Understanding Public Document Views and Version Context](doc:/understanding-public-document-views-and-version-context) — Learn how to recognize which version or context a public page belongs to. **6 min read | Beginner** 17. [Reading Versioned Documentation in Public Views](doc:/reading-versioned-documentation-in-public-views) — Practice reading version-specific documentation and understanding how it differs from current content. **6 min read | Beginner** 18. [Understanding Public Navigation and Content Discovery](doc:/understanding-public-navigation-and-content-discovery) — Reinforce the main ways readers discover content in Atloria’s public documentation. **7 min read | Beginner** 19. [Reading Audience Specific Documentation Views](doc:/reading-audience-specific-documentation-views) — Learn how audience-specific views differ from general public views and how to spot the difference. **6 min read | Beginner** 20. [Reading API Reference Sections in Technical Documentation](doc:/reading-api-reference-sections-in-technical-documentation) — Build confidence finding the right reference section and reading it efficiently. **6 min read | Beginner** 21. [Browsing Technical Documentation and Entity Reference Pages](doc:/browsing-technical-documentation-and-entity-reference-pages) — Understand how technical sections and detailed reference pages connect to each other. **7 min read | Beginner** 22. [Managing Reader Navigation Across Public Documentation](doc:/managing-reader-navigation-across-public-documentation) — Learn how to move smoothly across categories, pages, and versioned content. **7 min read | Beginner** 23. [Managing Technical Documentation Browsing and API Reading](doc:/managing-technical-documentation-browsing-and-api-reading) — Bring together your technical reading skills across different kinds of reference content. **7 min read | Beginner** 24. [Reviewing Audience Specific Reading Experiences](doc:/reviewing-audience-specific-reading-experiences) — Deepen your understanding of how audience and version combinations shape the public reading experience. **7 min read | Intermediate** 25. [Browsing Entity Reference Pages and Related Details](doc:/browsing-entity-reference-pages-and-related-details) — Practice reading detailed entity pages and following related information between them. **6 min read | Beginner** 26. [Reading API Reference in Project and Public Views](doc:/reading-api-reference-in-project-and-public-views) — Learn how API reference reading stays consistent across public and project-based views. **6 min read | Beginner** 27. [Browsing Technical Reference Sections and Entities](doc:/browsing-technical-reference-sections-and-entities) — Finish by tying together how technical overviews and detailed reference pages work in Atloria. **6 min read | Beginner** ## What You'll Be Able to Do After completing this path, you will be able to: - Open published documentation in Atloria and understand the basic page layout - Use sidebar navigation, page groups, and on-page navigation to move through content - Find the right public page more quickly by following the documentation structure - Recognize when content is tailored for a specific audience - Confirm whether you are reading the correct audience-specific view - Understand when you are viewing current content versus versioned content - Move between standard documentation pages and technical reference sections with confidence - Read API reference pages and technical detail pages more effectively - Understand how detailed entity pages relate to broader technical sections - Stay oriented while browsing across public, audience-specific, and version-aware documentation in Atloria ## About This Path This learning path is for the **Support Team Lead** in Atloria. It is designed for people who help customers get answers quickly by using documentation, support agents, and AI activity insights. You will move from the basics of getting into Atloria, to setting up and managing support agents, to reviewing conversations, usage, and analytics so you can improve support outcomes over time. The order matters because each step builds on the one before it. You first learn how to access Atloria, then how to create and manage support agents, then how to guide their behavior, review their activity, and use what you learn to improve documentation and self-service support. ## Prerequisites Before you begin, make sure you: - Have your Atloria sign-in details ready - Can access the Atloria workspace for your team - Know which documentation your team wants support agents to use - Have permission to view support agent settings and AI activity in Atloria - Are ready to review both customer-facing support experiences and internal team workflows ## Your Learning Journey 1. [Accessing and Registering Your Atloria Account](doc:/accessing-and-registering-your-atloria-account) — Start here to understand how new and returning users enter Atloria and complete the first access steps. **6 min read | Beginner** 2. [Signing In to Atloria and Solving Access Problems](doc:/signing-in-to-atloria-and-solving-access-problems) — This helps you sign in confidently and handle common access issues before you begin support work. **5 min read | Beginner** 3. [Creating and Managing AI Support Agents](doc:/creating-and-managing-ai-support-agents) — Learn how to create support agents and connect them to the documentation your team depends on. **8 min read | Beginner** 4. [Chatting with Support Agents and Managing Conversations](doc:/chatting-with-support-agents-and-managing-conversations) — Use this to practice real conversations, review responses, and understand how support chats behave in Atloria. **7 min read | Beginner** 5. [Configuring AI Settings for Your Organization](doc:/configuring-ai-settings-for-your-organization) — This shows you the wider AI choices that affect how support experiences work across your organization. **8 min read | Intermediate** 6. [Monitoring AI Usage and Request History](doc:/monitoring-ai-usage-and-request-history) — Read this to track how AI is being used and to keep an eye on quality, volume, and oversight. **8 min read | Beginner** 7. [Managing Support Agent Workspaces and Knowledge Setup](doc:/managing-support-agent-workspaces-and-knowledge-setup) — This gives you a clearer view of where support agents are organized and how their knowledge is prepared. **7 min read | Beginner** 8. [Configuring Support Agent Behavior and Availability](doc:/configuring-support-agent-behavior-and-availability) — Learn how to shape agent replies and decide where and when agents should be available. **8 min read | Intermediate** 9. [Using Analytics to Prioritize Documentation Improvements](doc:/using-analytics-to-prioritize-documentation-improvements) — This helps you turn support signals into better documentation decisions for your team and your customers. **8 min read | Intermediate** 10. [Reading Published API and Technical Documentation](doc:/reading-published-api-and-technical-documentation) — Even if you are not a technical specialist, this helps you understand the kinds of published content customers may use for self-service. **6 min read | Beginner** 11. [Viewing Technical Entities and Related Reference Details](doc:/viewing-technical-entities-and-related-reference-details) — This builds your confidence when checking detailed reference pages that may influence support conversations. **6 min read | Beginner** 12. [Managing Support Agent Knowledge Sources and Project Linking](doc:/managing-support-agent-knowledge-sources-and-project-linking) — Use this to make sure each support agent is connected to the right project content. **7 min read | Beginner** 13. [Managing AI Usage and Request History](doc:/managing-ai-usage-and-request-history) — This expands your ability to review activity patterns and use them to guide responsible team operations. **8 min read | Intermediate** 14. [Embedding and Operating Support Agents in Documentation Experiences](doc:/embedding-and-operating-support-agents-in-documentation-experiences) — Learn how support agents appear in reader-facing documentation and what to check before customers use them. **8 min read | Intermediate** 15. [Managing Support Agent Setup and Availability](doc:/managing-support-agent-setup-and-availability) — This gives you another practical view of preparing agents for team use and customer-facing availability. **7 min read | Beginner** 16. [Managing Agent Conversations and Chat History](doc:/managing-agent-conversations-and-chat-history) — Read this to better review past chats, understand context, and restart conversations when needed. **6 min read | Beginner** 17. [Monitoring AI Usage and Request Activity](doc:/monitoring-ai-usage-and-request-activity) — This helps you spot patterns in AI activity that may affect support quality or team workload. **8 min read | Intermediate** 18. [Configuring Support Agent Behavior and Embedded Experiences](doc:/configuring-support-agent-behavior-and-embedded-experiences) — Use this to refine how agents behave and appear inside documentation experiences. **8 min read | Intermediate** 19. [Managing AI Configuration Across Organization Settings](doc:/managing-ai-configuration-across-organization-settings) — This gives you a broader view of organization-level AI choices that influence support work in Atloria. **5 min read | Intermediate** 20. [Using Published Documentation as Support Agent Knowledge](doc:/using-published-documentation-as-support-agent-knowledge) — Learn the full workflow for using published documentation as the source behind support agent answers. **8 min read | Intermediate** 21. [Managing Agent Conversations and Session Follow Up](doc:/managing-agent-conversations-and-session-follow-up) — This helps you use chat outcomes to improve follow-up, support handling, and future agent behavior. **8 min read | Beginner** 22. [Managing Reusable Prompt Templates for AI Workflows](doc:/managing-reusable-prompt-templates-for-ai-workflows) — Read this to create more consistent support experiences across agents and team workflows. **8 min read | Beginner** 23. [Reviewing AI Usage and Request Activity](doc:/reviewing-ai-usage-and-request-activity) — This strengthens your ability to review usage trends and make informed decisions about quality and cost. **8 min read | Intermediate** 24. [Turning Analytics into Documentation Improvement Actions](doc:/turning-analytics-into-documentation-improvement-actions) — Finish here to turn everything you have learned into clear content improvement actions for your support program. **8 min read | Intermediate** ## What You'll Be Able to Do After completing this path, you will be able to: - Access Atloria, sign in smoothly, and resolve common entry problems - Create support agents that use the right documentation for customer support - Organize support agent workspaces and confirm knowledge sources are linked correctly - Test support agents through chat and review how they respond to real questions - Manage conversation history, restart sessions, and follow up on support interactions - Adjust support agent behavior and availability for both team use and customer-facing experiences - Understand how published documentation, including technical reference content, supports self-service answers - Review AI settings that affect support work across your organization - Monitor AI usage and request activity to support quality, visibility, and responsible team operations - Use analytics and conversation patterns to identify gaps in documentation - Turn support findings into practical improvements for documentation and self-service support in Atloria ## About This Path This learning path is for the **Technical Writer** who creates, updates, reviews, and prepares documentation in Atloria. It walks you from first access, to daily writing work, to version review, screenshots, technical reference reading, audience planning, and release support. The order matters because it follows the way most Technical Writers actually work in Atloria: first you get in, then you find your project, then you write and organize content, then you prepare versions, review changes, check supporting assets, and finally help move documentation toward release. ## Prerequisites Before you start, it helps to: - Have your Atloria sign-in details ready - Know which project or team you will be working with - Confirm that you can access the right project in Atloria - Be ready to collaborate with reviewers or subject matter experts - Set aside time to move through the path in order, especially if Atloria is new to you ## Your Learning Journey 1. [Accessing and Registering Your Atloria Account](doc:/accessing-and-registering-your-atloria-account) — Start here to understand how new and returning Technical Writers enter Atloria for the first time. **6 min read | Beginner** 2. [Signing In to Atloria and Solving Access Problems](doc:/signing-in-to-atloria-and-solving-access-problems) — This helps you sign in confidently and handle common access issues without getting stuck. **5 min read | Beginner** 3. [Understanding Account Entry Points and Session Navigation](doc:/understanding-account-entry-points-and-session-navigation) — Learn how Atloria moves you from public pages into your working areas so navigation feels familiar early on. **8 min read | Beginner** 4. [Working with Project Lists and Dashboards](doc:/working-with-project-lists-and-dashboards) — This shows you how to find the right project and understand where your documentation work lives. **7 min read | Beginner** 5. [Using Project Home to Coordinate Documentation Work](doc:/using-project-home-to-coordinate-documentation-work) — Use this to understand the main project view and move between related work areas without losing context. **7 min read | Beginner** 6. [Understanding Project Navigation and Linked Workspaces](doc:/understanding-project-navigation-and-linked-workspaces) — This gives you a clear picture of how documents, versions, analytics, and other areas connect in Atloria. **8 min read | Beginner** 7. [Creating and Editing Documentation Pages](doc:/creating-and-editing-documentation-pages) — This is the core writing guide for creating pages and making updates as a Technical Writer. **8 min read | Beginner** 8. [Managing Project Content from Drafts to Published Pages](doc:/managing-project-content-from-drafts-to-published-pages) — Read this to understand how page work moves from early drafting into release preparation. **9 min read | Beginner** 9. [Organizing and Reviewing Document Content](doc:/organizing-and-reviewing-document-content) — This helps you keep pages readable, structured, and ready for review. **8 min read | Beginner** 10. [Collaborating on Document Changes and Page Quality](doc:/collaborating-on-document-changes-and-page-quality) — Use this when you need to work with reviewers and improve page quality before version work begins. **8 min read | Intermediate** 11. [Managing Document Comparisons During Content Updates](doc:/managing-document-comparisons-during-content-updates) — This helps you understand what changed and confirm that your edits are accurate. **7 min read | Beginner** 12. [Understanding Document Preview and Public Page Checks](doc:/understanding-document-preview-and-public-page-checks) — Read this to check how your content will look to readers before release. **8 min read | Beginner** 13. [Understanding Documentation Version Workspaces](doc:/understanding-documentation-version-workspaces) — This introduces the version area where release progress is tracked. **8 min read | Beginner** 14. [Managing Version Generation Jobs and Results](doc:/managing-version-generation-jobs-and-results) — Learn how new documentation versions are created and how to follow their results. **8 min read | Intermediate** 15. [Comparing Documentation Versions for Release Decisions](doc:/comparing-documentation-versions-for-release-decisions) — This matters when you need to confirm what changed between versions before review. **7 min read | Intermediate** 16. [Preparing Versions for Review and Approval](doc:/preparing-versions-for-review-and-approval) — Use this to make sure a version is complete before asking others to review it. **8 min read | Beginner** 17. [Requesting and Completing Version Reviews](doc:/requesting-and-completing-version-reviews) — This explains the review flow that Technical Writers often help start and track. **8 min read | Intermediate** 18. [Understanding Review Feedback and Follow Up Actions](doc:/understanding-review-feedback-and-follow-up-actions) — Read this to respond clearly to comments, approvals, and requested changes. **5 min read | Intermediate** 19. [Capturing and Saving Screenshots for Documentation](doc:/capturing-and-saving-screenshots-for-documentation) — This helps you create and save screenshots that support your written content. **6 min read | Beginner** 20. [Saving and Organizing Captured Screenshots](doc:/saving-and-organizing-captured-screenshots) — Use this to keep images easy to find and reuse across documentation work. **8 min read | Beginner** 21. [Reviewing Version Screenshots Before Release](doc:/reviewing-version-screenshots-before-release) — This shows you how to confirm that screenshots are complete and current before release. **6 min read | Beginner** 22. [Reading API Reference Sections in Technical Documentation](doc:/reading-api-reference-sections-in-technical-documentation) — This helps you read technical reference content that may support your writing. **6 min read | Beginner** 23. [Browsing Technical Documentation and Entity Reference Pages](doc:/browsing-technical-documentation-and-entity-reference-pages) — Use this to understand how generated technical details are organized inside Atloria. **7 min read | Beginner** 24. [Uploading Code and Reviewing Parsing Results](doc:/uploading-code-and-reviewing-parsing-results) — This gives you a practical starting point for bringing source material into Atloria when technical reference work is needed. **8 min read | Beginner** 25. [Evaluating Supported Languages and Parser Availability](doc:/evaluating-supported-languages-and-parser-availability) — Read this before technical reference work so you know what Atloria supports. **6 min read | Beginner** 26. [Using Technical Reference Pages During Documentation Work](doc:/using-technical-reference-pages-during-documentation-work) — This connects technical reference material to everyday writing and content improvement. **7 min read | Intermediate** 27. [Planning Audience Targeting for Project Content](doc:/planning-audience-targeting-for-project-content) — This helps you think about who your content is for and how to shape it for different readers. **9 min read | Intermediate** 28. [Publishing Documentation for Specific Audiences](doc:/publishing-documentation-for-specific-audiences) — Use this to understand how audience-focused content is prepared for release. **8 min read | Intermediate** 29. [Coordinating Project Publishing From Draft to Public Release](doc:/coordinating-project-publishing-from-draft-to-public-release) — Finish with this end-to-end guide so you can see how your writing work supports the full release journey in Atloria. **9 min read | Intermediate** ## What You'll Be Able to Do After completing this path, you will be able to: - Access and sign in to Atloria with confidence - Find the right project and move through connected work areas smoothly - Create, edit, organize, and review documentation pages in Atloria - Check page changes, previews, and overall content quality before release work begins - Work with documentation versions and understand how changes move toward approval - Prepare versions for review and respond to review feedback clearly - Capture, save, organize, and verify screenshots for documentation use - Read technical reference content and use it to improve written documentation - Review support for languages and related technical reference inputs before using them - Plan content for different reader groups and support audience-specific publishing - Contribute effectively to a documentation release from draft content to public delivery ## Navigation Basics If you are new to Atloria, the easiest way to feel comfortable is to learn the main places you will move between every day. Atloria is organized around a few core areas: account access, the admin workspace, project areas, and documentation pages. This guide explains how to move around Atloria, how to open records, and how to use breadcrumbs and search to stay oriented. ## Start from the Main Entry Points Most people begin in one of these places: - the sign-in page - the registration page - the admin workspace - the project list - a specific project dashboard - a documentation page or public documentation link If you need help understanding where to enter Atloria and what happens after you sign in, see [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation), [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account), and [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems). ## Understand the Main Navigation Areas ### Admin workspace The admin workspace is where administrators and other authorized users manage higher-level settings and oversight areas. From the admin workspace, you may move to areas such as: - analytics - users and permissions - security and audit - AI assistant pages To learn how these areas are grouped and used, see [Using the Admin Workspace](/using-the-admin-workspace), [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions), [Reviewing Security and Audit Controls](/reviewing-security-and-audit-controls), and [Monitoring Administrative Analytics and Activity](/monitoring-administrative-analytics-and-activity). ### Project areas Project areas are where most day-to-day documentation work happens. A common path is: **Project list → Project dashboard → Project settings, versions, or documentation work** From the project list, you can open a project record and move into its dashboard. From there, you can continue into setup, settings, performance views, or documentation-related work. Helpful guides include: - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) - [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) - [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding) - [Choosing Between Manual and Connected Project Setup](/choosing-between-manual-and-connected-project-setup) - [Managing Project Settings and Website Options](/managing-project-settings-and-website-options) - [Configuring Project Webhooks and Related Controls](/configuring-project-webhooks-and-related-controls) - [Analyzing Project Performance and Activity](/analyzing-project-performance-and-activity) ### Documentation work areas When you are writing or reviewing content, you will usually move through paths like: **Project dashboard → Documentation pages** **Project dashboard → Versions** **Project dashboard → Editor** If your focus is creating or updating content, see [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages). ## Use the Menu to Move Between Areas The menu is your main tool for moving around Atloria. It helps you switch between broad work areas without needing to go back to the beginning each time. In general, use the menu when you want to: - switch from one major area to another - move from the admin workspace to project work - open settings or management pages - return to a list after viewing a single record As you move through Atloria, pay attention to whether you are in: - a top-level area, such as admin or projects - a list view, such as a project list - a single record, such as one project or one page - a detailed working area, such as the editor This simple habit makes navigation much easier, especially when you are new. ## Follow Common Navigation Paths Here are a few common ways people move through Atloria. ### Open a project from the project list A common path is: **Projects → Project list → Select a project → Project dashboard** Use this path when you want to: - review project status - continue setup - open project settings - access documentation work For more detail, see [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards). ### Move from a project dashboard to project setup or settings A common path is: **Project dashboard → Setup or Settings** Use this path when you need to: - finish onboarding - review website options - update project controls - manage related project options For more detail, see [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home), [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding), and [Managing Project Settings and Website Options](/managing-project-settings-and-website-options). ### Move from a project dashboard to documentation work A common path is: **Project dashboard → Documentation pages or Editor** Use this path when you want to create, update, or organize content. For more detail, see [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages). ### Move through admin pages A common path is: **Admin workspace → Analytics, Users and Permissions, or Security and Audit** Use this path when you need to review organization-level information or controls. For more detail, see [Using the Admin Workspace](/using-the-admin-workspace). ## Open and Review Records In Atloria, a record is a single item you open from a list or dashboard. For example, a project in a project list is a record. A documentation page can also be treated as a record when you open it to review or edit it. A simple pattern to remember is: **List → Select item → Record view → Related actions** When you open a record, look for: - the title at the top of the page - the surrounding menu options - nearby actions for editing, reviewing, or managing that item - breadcrumbs that show where the record sits in Atloria If you are not sure where you are, return to the related list or dashboard using the menu or breadcrumbs. ## Use Breadcrumbs to Keep Your Place Breadcrumbs help you understand where you are inside Atloria. They usually show the path from a broader area to the page you are viewing. For example, you may see a path that follows this pattern: **Projects → Project name → Current page** Use breadcrumbs when you want to: - go back one level - return to the project dashboard - confirm which project or section you are working in - avoid getting lost after opening several pages Breadcrumbs are especially useful when you move from a list into a single project and then into a deeper page such as settings or documentation work. ## Use Search to Find What You Need Faster Search is the quickest way to find a project, page, or other item when you do not want to browse through menus. Use search when: - you already know the name of what you want - you need to jump directly to a project or page - you want to avoid clicking through several levels - you are returning to something you worked on recently When searching, try: - the full name - part of the name - a distinctive word from the title If your first search does not help, go back to the related list or dashboard and browse from there. ## Stay Oriented as You Move Around When learning Atloria, use this quick check on every page: - **Where am I?** Look at the page title. - **What area is this in?** Check the menu and breadcrumbs. - **What can I do here?** Look for the main actions on the page. - **How do I go back?** Use breadcrumbs or return to the related list. This small routine helps you build confidence quickly. ## A Simple Way to Learn Atloria Navigation If this is your first time in Atloria, follow this order: 1. Sign in and get familiar with your starting page. 2. Open the project list. 3. Select a project and view its dashboard. 4. Use the menu to open settings or documentation work. 5. Use breadcrumbs to return to the project dashboard. 6. Visit the admin workspace if your role includes admin access. These guides are the best next steps: - [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation) - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) - [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) - [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) - [Using the Admin Workspace](/using-the-admin-workspace) ## Related Guides - [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account) - [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems) - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) - [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) - [Using the Admin Workspace](/using-the-admin-workspace) ## Setting Up Your Profile Your profile helps Atloria feel more personal and work better for your daily routine. A few quick updates can make it easier to recognize your account, see the right time in activity areas, and get the notifications you want. This guide gives you a simple starting point for updating your profile settings in Atloria. ## Why your profile matters Setting up your profile can help you: - Show your name clearly to teammates - Add a profile photo so people can recognize you - Use Atloria in your preferred language - See times that match your local timezone - Choose which notifications you want to receive If you are new to Atloria, this is one of the best first steps after signing in. ## Before you start Make sure you are signed in to Atloria with your account. If you need help getting into your account first, check your sign-in or registration guides in the Atloria documentation. ## Open your profile settings In Atloria, profile settings are usually available from your account menu. A common path is: 1. Sign in to Atloria. 2. Select your profile image or account icon. 3. Open **Settings** or **Profile**. 4. Review the available personal settings. The exact layout may vary depending on your workspace or account type, but your personal settings are typically grouped in one easy-to-find area. For detailed settings information, refer to the User Guide settings documents. ## Update your name Your name is how teammates will usually see you in Atloria. You may want to update it if: - You prefer a shorter display name - Your name has changed - You want your profile to match how your team knows you When updating your name: - Use the name you want others to recognize - Double-check spelling before saving - Keep it consistent with your team directory if needed For the full steps, see the related settings guide in the User Guide. ## Add or change your profile photo A profile photo helps people quickly identify you in shared spaces. A good profile photo should be: - Clear and easy to recognize - Professional if you use Atloria for work - Current, so teammates know it is you If Atloria allows photo updates in your profile settings, you can usually select an image and save your changes from the same personal settings area. For exact instructions, use the User Guide settings documentation. ## Choose your language If Atloria supports multiple languages for your account experience, you can choose the one that feels most comfortable. Changing your language can help you: - Read menus and settings more easily - Work faster in a familiar language - Reduce confusion when completing tasks After changing your language, some areas may update right away, while others may need a refresh or a new sign-in. For full details, check the User Guide settings pages. ## Set your timezone Your timezone helps Atloria show times in a way that matches where you work. This is useful for: - Activity times - Review timing - Notifications - Team coordination across regions Choose the timezone that matches your normal working location. If you travel often, you may want to review this setting from time to time. For more guidance, see the User Guide settings documentation. ## Manage notification preferences Notification settings let you decide how Atloria keeps you informed. You may be able to control notifications for things like: - Project activity - Review requests - Approvals - Publishing updates - Team changes A good approach is to start with the most important updates, then adjust later if you receive too many or too few notifications. When reviewing notification preferences: - Keep important alerts turned on - Turn off updates you do not need - Revisit your choices after your first week using Atloria For exact options and steps, refer to the User Guide settings docs. ## Save your changes After updating any profile setting, make sure you save your changes before leaving the page. It is a good idea to review your profile once more after saving to confirm that: - Your name appears correctly - Your photo looks right - Your language is correct - Your timezone matches your location - Your notifications reflect your preferences ## Related guides For step-by-step instructions, use the settings guides in the User Guide. You may also want to explore related Atloria documentation for account access and personal setup. ## System Requirements Use this page to confirm that your device and browser are ready for Atloria. ## Supported browsers Atloria works best in current versions of modern web browsers, including: - Google Chrome - Microsoft Edge - Mozilla Firefox - Safari For the best experience, use the latest available version of your browser. Older browsers may load Atloria, but some pages or actions may not work as expected. If you have trouble signing in or loading pages, first update your browser, then review [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems). ## Internet connection Atloria is used online, so you need a stable internet connection. A faster connection is especially helpful when you: - upload files - generate documentation - review analytics - work with screenshots - open large documentation projects If pages load slowly or actions do not finish, check your connection before trying again. ## Screen size and resolution Atloria is designed for standard laptop and desktop screens. Recommended minimum screen resolution: - **1280 × 720** Recommended for more comfortable use: - **1440 × 900** or higher A larger screen is helpful when you are writing, reviewing versions, comparing content, or managing project settings. ## Supported devices You can access Atloria from: - desktop computers - laptop computers - tablets with a modern browser Atloria can be opened on phones, but some work areas may be harder to use on a small screen. For tasks such as editing documents, managing approvals, reviewing analytics, or setting up projects, a desktop or laptop is recommended. ## Browser settings To use Atloria smoothly, make sure your browser allows: - cookies - JavaScript - pop-ups for Atloria, if your browser blocks sign-in or download windows If these settings are blocked, parts of Atloria may not open or save correctly. ## Account access and setup Before you begin, make sure you can reach Atloria and sign in with your account. If you are new to Atloria, start with: - [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account) - [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation) If you are setting up your first project after signing in, see: - [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding) - [Choosing Between Manual and Connected Project Setup](/choosing-between-manual-and-connected-project-setup) ## Best experience For the most reliable experience in Atloria: - use an up-to-date browser - use a stable internet connection - work on a laptop or desktop when possible - use a screen resolution of at least 1280 × 720 If your device meets these general requirements, you should be able to use Atloria for everyday documentation work. ## Understanding the Interface When you first open Atloria, you will see a few main areas that help you move around, find your work, and keep track of what needs attention. This guide gives you a simple tour of the interface so you can feel comfortable finding your way around before you start working. ## Why the interface is organized this way Atloria is built to help teams move between projects, documentation, reviews, publishing, and administration without getting lost. Most pages in Atloria are organized around the same core areas: - the **sidebar** for moving between major sections - the **header** for quick actions and account-level tools - **breadcrumbs** for seeing where you are - **search** for finding projects, pages, and other items faster - **notifications** for updates that may need your attention Once you understand these areas, it becomes much easier to move confidently through Atloria. ## Sidebar The sidebar is usually the main navigation area on the side of the screen. You will use it to move between the biggest parts of Atloria, such as: - projects - documentation workspaces - analytics - approvals - settings - administrative areas, if you have access The exact options you see may depend on: - your role - the workspace you are in - whether you are viewing a project area or an administrative area For example, someone managing documentation may see options related to pages, versions, and publishing, while an administrator may also see broader controls for users, security, or activity. ### What the sidebar helps you do The sidebar helps you: - switch between major sections without going back to a home page - understand what area of Atloria you are currently using - access project-level or admin-level tools quickly ### What to expect As you move through Atloria, the sidebar may change slightly to match the area you are in. This is normal. Atloria keeps the most relevant options close at hand so you do not have to search through unrelated choices. If you want a broader view of project areas, see [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards). If you are using admin pages, see [Using the Admin Workspace](/using-the-admin-workspace). ## Header The header is the top area of the page. It usually contains quick-access tools that stay useful no matter where you are in Atloria. Depending on the page, the header may include: - the current page or section name - search - notifications - account or profile access - quick actions related to the page you are viewing ### What the header helps you do The header gives you a fast way to: - confirm where you are - jump to common actions - check updates - open account-related options Because the header stays in a familiar place, it becomes one of the easiest ways to stay oriented while moving between different parts of Atloria. ## Breadcrumbs Breadcrumbs are a small trail of links near the top of a page. They show the path to your current location. For example, breadcrumbs may show that you are inside: - a project - then a documentation area - then a specific page or section ### Why breadcrumbs matter Breadcrumbs help you: - see where the current page fits - move back to a previous level - avoid feeling lost in deeper areas of Atloria This is especially helpful when you are working inside large documentation sets, project settings, or review flows. If you are still getting familiar with project structure, [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) can help you understand how project areas are organized. ## Search Search helps you find what you need without clicking through every section manually. In Atloria, search is useful when you want to quickly locate: - a project - a documentation page - a setting - a version - another item you know by name ### When to use search Search is helpful when: - you already know what you are looking for - you are working across many projects - you want to move faster - you are not sure which section contains an item For new users, search is often the fastest way to build confidence. Even if you do not yet know the full layout of Atloria, search can help you get where you need to go. ## Notifications Notifications help you stay aware of updates and tasks that may need your attention. Depending on your role and the work you do in Atloria, notifications may relate to things like: - review activity - approval decisions - project updates - publishing changes - other important events tied to your work ### Why notifications are useful Notifications help you: - notice changes without checking every area manually - respond to reviews or approvals more quickly - stay informed about important activity If your work includes approvals, you may also want to read [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) for content work and [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) for project-level organization. For approval-specific tasks, follow the links available from the relevant project area in Atloria. ## How the interface changes by area Atloria supports several kinds of work, so the interface may look a little different depending on where you are. ### In project areas You will usually see navigation focused on: - project overview - documentation - versions - settings - connected work related to that project To learn more, see [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) and [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding). ### In documentation workspaces You will usually see navigation focused on: - page creation - editing - organization - previewing - publishing To continue from there, see [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages). ### In admin areas If you have administrative access, you may also see navigation for: - users and permissions - security - audit activity - analytics - broader account controls To explore those areas, see [Using the Admin Workspace](/using-the-admin-workspace), [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions), and [Reviewing Security and Audit Controls](/reviewing-security-and-audit-controls). ## Tips for getting comfortable quickly If Atloria is new to you, these simple habits can help: - start with the sidebar to understand the main sections - use the header to check where you are - look at breadcrumbs before going deeper into a page - use search when you know the name of what you need - check notifications for updates that may affect your work You do not need to memorize everything at once. After a little use, the layout of Atloria will begin to feel familiar. ## Where to go next After you understand the main interface areas, these guides are good next steps: - [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation) - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) - [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding) - [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) - [Using the Admin Workspace](/using-the-admin-workspace) If you are completely new to Atloria, starting with project navigation and then moving into documentation work is usually the easiest path. ## User Guide Overview Welcome to the Atloria User Guide. This section helps you find the right instructions based on what you want to do in Atloria, whether you are setting up a project, writing documentation, publishing updates, reviewing analytics, or managing AI support agents. If you are new to Atloria, start with the areas that match your goal instead of trying to read everything in order. ## Where to Start ### I’m new to Atloria Start with **Documentation Production** for the main day-to-day documentation workflow in Atloria. If you are setting up projects or connecting services, also check **Integrations and Technical Sources**. ### I want to create and publish documentation Go to **Documentation Production**. This area covers writing, organizing, previewing, versioning, approvals, screenshots, audiences, and public reading. ### I want to manage AI support agents Go to **AI and Support**. This area covers setting up support agents, managing AI behavior, and reviewing AI activity. ### I want reports or exports Go to **Reporting and Exports**. This area covers analytics, audit review, and export-related tasks. ### I want to connect Atloria to other tools Go to **Integrations and Technical Sources**. This area covers connected services, technical source workflows, and supported language and framework views. ### I want a full workflow from setup to publishing Go to **Cross Module Workflows**. This area connects tasks across projects, content, audiences, publishing, and support agents. ## User Guide Categories ### Product Workspaces (0 docs) This category is intended for major Atloria work areas used to manage projects, versions, screenshots, support agents, and technical documentation. There are currently no guides published in this category. ### Documentation Experience (0 docs) This category is intended for public reading, audience presentation, and documentation asset workflows that shape how Atloria content is consumed and reviewed. There are currently no guides published in this category. ### Documentation Lifecycle (0 docs) This category is intended for managing documentation versions from creation through review, access control, and release preparation in Atloria. There are currently no guides published in this category. ### Content Management (0 docs) This category is intended for creating, organizing, releasing, and validating documentation content across authoring and version workflows. There are currently no guides published in this category. ### Atloria (0 docs) This category is intended for top-level Atloria workspace guidance covering project operations, content lifecycle management, publishing, and reader experiences. There are currently no guides published in this category. ### Product Management (0 docs) This category is intended for major operational areas used to manage Atloria projects, releases, analytics, exports, and connected services. There are currently no guides published in this category. ### Content and Delivery (0 docs) This category is intended for content creation, audience delivery, public reading, and screenshot workflows for Atloria documentation teams. There are currently no guides published in this category. ### End to End Documentation Workflows (0 docs) This category is intended for cross-module processes that connect setup, authoring, versions, audiences, publishing, and support agent outcomes. There are currently no guides published in this category. ### Technical Reference (0 docs) This category is intended for technical documentation browsing, code parsing, and language support workflows available through Atloria screens. There are currently no guides published in this category. ### Publishing Workflows (0 docs) This category is intended for end-to-end Atloria workflows that connect projects, versions, audiences, publication, and support agent knowledge use. There are currently no guides published in this category. ### Documentation Visual Assets (0 docs) This category is intended for capturing, organizing, reviewing, and validating screenshots used in documentation. There are currently no guides published in this category. ### AI Management (0 docs) This category is intended for monitoring AI activity and managing organization-level AI usage visibility in Atloria. There are currently no guides published in this category. ### AI and Support Management (0 docs) This category is intended for support agent setup, knowledge use, behavior controls, and visible AI activity monitoring. There are currently no guides published in this category. ### Documentation Production (94 docs) This is the main user area for authoring and publishing documentation in Atloria. It covers project onboarding, document editing, versions, approvals, audiences, screenshots, access control, and the public documentation viewer. Key docs include [Project Onboarding](/project-onboarding), [Document Editor](/document-editor), [Documentation Versions](/documentation-versions), [Approval Workflow](/approval-workflow), [Audiences](/audiences), [Screenshot Capture](/screenshot-capture), [Version Access Control](/version-access-control), and [Public Documentation Viewer](/public-documentation-viewer). ### Governance and Export (0 docs) This category is intended for audit review, compliance-oriented record handling, and export workflows in Atloria. There are currently no guides published in this category. ### Reporting and End to End Workflows (0 docs) This category is intended for analytics-driven decisions and cross-module workflows that connect setup, authoring, release, audiences, and support experiences. There are currently no guides published in this category. ### AI and Support (17 docs) This category covers Atloria support agents and AI configuration features used across your organization. Use it when you want to create agents, adjust AI settings, or review AI activity. Key docs include [Support Agents](/support-agents) and [AI Settings](/ai-settings). ### Reporting and Exports (25 docs) This category covers visibility and record-sharing workflows in Atloria. Use it for analytics, audit review, and export tasks tied to documentation activity and version records. Key docs include [Enterprise Analytics](/enterprise-analytics), [Audit Trail](/audit-trail), [Export Center](/export-center), and [Admin Dashboard](/admin-dashboard). ### Integrations and Technical Sources (41 docs) This category covers connecting Atloria to external services and working with technical source material. It also includes supported language and framework information and code parsing work areas. Key docs include [Integrations](/integrations), [Languages & Frameworks](/languages-frameworks), and [Code Parsing Workspace](/code-parsing-workspace). ### Cross Module Workflows (10 docs) This category helps you follow complete processes that span more than one area of Atloria. Use it when your task involves setup, content creation, audiences, publishing, and support agents together. Start here after you understand the basics in [Project Management](/project-management), [Documentation Versions](/documentation-versions), and [Support Agents](/support-agents). ## Tips for Navigating the User Guide ### Use categories by goal Choose a category based on the outcome you want, such as publishing content, reviewing reports, or managing AI support. ### Start broad, then go specific Begin with a category overview, then open the linked guides for step-by-step help. ### Check related areas when your task crosses teams In Atloria, many tasks connect across projects, versions, publishing, and support. If one guide does not cover the full process, check **Cross Module Workflows** next. ## What Can You Do with Atloria? Atloria helps teams turn project knowledge into organized documentation that can be created, reviewed, managed, and shared. Depending on your role, you might use Atloria to set up projects, write pages, manage releases, control access, review activity, publish public docs, or support customers with AI-powered answers. ## Get Started and Access Your Workspace Use Atloria to get into your account and move between the main entry points for your work. - Sign in, register, and return to your workspace from Atloria’s access pages - Understand where to start when moving between home, sign-in, and registration screens - Solve common access and sign-in issues - Learn how account entry and session navigation work See: - [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account) - [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation) - [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems) ## Set Up and Manage Projects Atloria gives project administrators and documentation owners the tools to create projects, complete setup, and manage project-level options. - Create new projects and complete guided onboarding - Choose the setup path that fits your team, including manual setup or a connected source - Open project lists and dashboards to track active work - Manage project settings, website options, and related controls - Review project activity and performance from project-level views See: - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) - [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) - [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding) - [Choosing Between Manual and Connected Project Setup](/choosing-between-manual-and-connected-project-setup) - [Managing Project Settings and Website Options](/managing-project-settings-and-website-options) - [Configuring Project Webhooks and Related Controls](/configuring-project-webhooks-and-related-controls) - [Analyzing Project Performance and Activity](/analyzing-project-performance-and-activity) ## Create and Maintain Documentation Atloria supports day-to-day writing and editing so teams can build clear, structured documentation together. - Create new pages and update existing content - Organize documentation so readers can find the right information - Preview and prepare content before sharing it more widely - Collaborate on documentation updates across your team See: - [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) ## Manage Teams, Permissions, and Oversight Atloria includes administrative areas for managing access, reviewing activity, and monitoring organization-wide controls. - Open the admin workspace to reach key administrative areas - Manage user access and administrative permissions - Review security-related controls and audit activity - Monitor analytics and activity across administrative views See: - [Using the Admin Workspace](/using-the-admin-workspace) - [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions) - [Reviewing Security and Audit Controls](/reviewing-security-and-audit-controls) - [Monitoring Administrative Analytics and Activity](/monitoring-administrative-analytics-and-activity) ## Control Releases and Visibility Atloria helps teams manage documentation versions, review readiness, and decide who can see what. - Generate and manage documentation versions across a project - Compare versions and track their status before release - Request approval, approve changes, or reject a version that is not ready - Control who can access a version and how visible it is - Export documentation versions and related records when needed Related areas in Atloria include documentation versions, approval workflow, version access control, audit trail, and export center. ## Publish Public Documentation Atloria supports public-facing documentation experiences for readers outside your private workspace. - Publish documentation to public URLs - Offer readers version switching so they can view the right release - Present content for different audiences - Give public readers a clear browsing experience across published documentation Related areas in Atloria include public documentation viewer and audiences. ## Use AI-Powered Documentation and Support Tools Atloria includes AI-supported features that help teams create documentation and answer questions from project content. - Generate documentation from project knowledge - Configure AI-related settings and review usage - Create support agents that answer questions using your documentation - Manage and chat with support agents for self-service support - Capture screenshots for use in documentation content Related areas in Atloria include AI settings, support agents, and screenshot capture. ## Connect Sources and Explore Supported Content Atloria also helps teams connect outside sources and understand what kinds of project content Atloria can work with. - Connect supported source providers and manage connection status - Reconnect or remove a source connection when needed - Review supported languages and frameworks - Upload files or content into a parsing workspace and inspect the results Related areas in Atloria include integrations, languages & frameworks, and code parsing workspace. ## What is Atloria? Atloria helps teams turn project knowledge into clear, organized documentation that can be shared with the right people at the right time. Many teams keep important information in scattered notes, conversations, files, and project tools. That makes it hard to create reliable documentation, keep it up to date, and publish it in a way that others can trust. Atloria brings that work into one place so teams can create documentation, review changes, manage access, and publish content for internal or public use. Atloria supports the full documentation journey. Teams can set up projects, connect source material, generate draft documentation, edit and organize pages, manage versions, request approvals, publish to public websites, and track how documentation is being used. Atloria also includes AI-powered help features that can answer questions based on your project documentation. ## Who Atloria is for Atloria is designed for teams that create, manage, and share documentation as part of their daily work. Common users include: - **Documentation managers** who oversee structure, quality, publishing, and lifecycle decisions - **Writers and contributors** who create and update documentation pages - **Project administrators** who set up projects, manage settings, and control access - **Support leaders** who use documentation and AI support agents to help customers find answers - **Public readers** who visit published documentation to browse guides, versions, and audience-specific content ## What problems Atloria solves Atloria helps teams solve several common documentation challenges: - **Knowledge is scattered** Atloria brings project information, documentation work, and published content together. - **Documentation is hard to maintain** Teams can create structured pages, update content over time, and manage documentation by version. - **Reviews and approvals are unclear** Atloria supports review and approval steps before documentation is released. - **Different people need different access** Teams can manage who can view, edit, review, or publish documentation. - **Publishing takes too much manual work** Atloria helps teams move from draft content to public documentation in a more organized way. - **Support teams need faster answers** AI support agents can use project documentation to answer questions and support self-service help. ## How Atloria is organized Most work in Atloria happens in two connected spaces: - **Private project workspaces**, where teams set up projects, create and review documentation, manage versions, and control access - **Public documentation experiences**, where readers view published documentation, switch between versions, and browse content meant for their audience This means Atloria supports both the team creating the documentation and the people reading it later. ## Main areas you will use Depending on your role, you may work with different parts of Atloria: - **Account access** for signing in, registering, and moving between entry pages - **Admin workspace** for user access, permissions, security, audit activity, and high-level oversight - **Project setup and onboarding** for creating new documentation projects - **Project management** for dashboards, settings, and day-to-day administration - **Document editing** for writing, organizing, previewing, and publishing pages - **Documentation versions** for generating, reviewing, comparing, and releasing updates - **Approval workflows** for requesting and completing reviews before release - **Audience management** for tailoring content to different reader groups - **Integrations** for connecting Atloria with supported code hosting services - **Screenshot capture** for saving images from web pages to use in documentation - **Analytics and audit history** for understanding usage and reviewing activity - **Export tools** for downloading documentation versions and related records - **Public documentation viewing** for reading published content - **AI settings and support agents** for managing AI-powered features and question-answering experiences ## Where to go next If you are just getting started, these guides will help you understand how Atloria is set up and where to begin: - [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account) - [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation) - [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems) If you are setting up or managing work in Atloria, start here: - [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding) - [Choosing Between Manual and Connected Project Setup](/choosing-between-manual-and-connected-project-setup) - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) - [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) If you will be creating documentation, continue with: - [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) If you manage access, oversight, or controls, see: - [Using the Admin Workspace](/using-the-admin-workspace) - [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions) - [Reviewing Security and Audit Controls](/reviewing-security-and-audit-controls) - [Monitoring Administrative Analytics and Activity](/monitoring-administrative-analytics-and-activity) ## In summary Atloria is a documentation workspace for teams that need to create, manage, review, publish, and support documentation across private and public experiences. It helps turn project knowledge into structured documentation that stays usable over time, while giving teams the controls they need for access, approvals, publishing, and support. ## Who Uses Atloria Atloria supports several kinds of users, from people who manage documentation behind the scenes to people who simply read published content. If you are new to Atloria, this page helps you identify the role that best matches your work and the areas of Atloria you will use most often. ## Documentation Manager A Documentation Manager is usually responsible for the overall health of documentation across one or more projects. This person keeps content organized, makes sure releases are ready to publish, and helps teams maintain a clear documentation process. Typical responsibilities include: - Planning documentation structure - Overseeing drafts, reviews, and publishing - Managing versions of documentation - Setting audience visibility - Monitoring performance and activity Modules used most often: - **Project Management** for project dashboards and settings - **Document Editor** for organizing and reviewing pages - **Documentation Versions** for tracking releases and comparing versions - **Approval Workflow** for review and sign-off - **Version Access Control** for deciding who can see each version - **Audiences** for content targeting - **Export Center** when documentation records need to be shared or archived - **Enterprise Analytics** for usage and performance review Helpful guides: - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) - [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) - [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) - [Analyzing Project Performance and Activity](/analyzing-project-performance-and-activity) ## Technical Writer A Technical Writer focuses on creating, updating, and improving documentation content. In Atloria, this role often works closely with reviewers, project owners, and subject matter experts to turn project knowledge into clear documentation. Typical responsibilities include: - Writing and editing pages - Organizing content for readers - Updating existing versions - Preparing content for review - Adding visuals and supporting material Modules used most often: - **Document Editor** for writing, editing, previewing, and organizing pages - **Documentation Versions** for working within the right release - **Approval Workflow** for submitting work for review - **Screenshot Capture** for collecting images to use in documentation - **Audiences** for tailoring content to different reader groups - **Support Agents** when checking how documentation answers common questions Helpful guides: - [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) - [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) ## Project Administrator A Project Administrator handles setup, access, and operational controls for documentation projects in Atloria. This role makes sure teams can get into the right projects, connect outside services, and manage project-level settings. Typical responsibilities include: - Creating new projects - Choosing setup methods - Connecting repositories and related services - Managing project settings and website options - Overseeing access and permissions - Reviewing activity and controls Modules used most often: - **Authentication** for account access and entry points - **Project Onboarding** for new project setup - **Project Management** for dashboards and project settings - **Integrations** for connecting supported Git providers - **Admin Dashboard** for administrative controls - **Audit Trail** for reviewing activity records - **AI Settings** for provider setup, usage review, and prompt management Helpful guides: - [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account) - [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation) - [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding) - [Choosing Between Manual and Connected Project Setup](/choosing-between-manual-and-connected-project-setup) - [Managing Project Settings and Website Options](/managing-project-settings-and-website-options) - [Using the Admin Workspace](/using-the-admin-workspace) - [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions) - [Reviewing Security and Audit Controls](/reviewing-security-and-audit-controls) ## Support Team Lead A Support Team Lead uses Atloria to help customers find answers faster. This role often depends on published documentation and AI-powered help experiences to reduce repeated questions and improve self-service support. Typical responsibilities include: - Reviewing documentation for common support topics - Using AI support agents to answer questions - Checking whether published content is easy to find and understand - Monitoring which content is most useful Modules used most often: - **Support Agents** for creating, managing, and chatting with AI assistants - **Public Documentation Viewer** for reviewing the reader experience - **Documentation Versions** for checking what is currently available - **Enterprise Analytics** for understanding usage and engagement - **Audiences** for confirming the right readers see the right content Helpful guides: - [Analyzing Project Performance and Activity](/analyzing-project-performance-and-activity) - [Managing Project Settings and Website Options](/managing-project-settings-and-website-options) ## Public Documentation Reader A Public Documentation Reader is not usually part of the internal documentation team. This person visits published documentation to learn about a product, compare versions, and read content meant for a specific audience. Typical responsibilities include: - Browsing published documentation - Switching between available versions - Reading content for a specific audience - Finding answers to product or feature questions Modules used most often: - **Public Documentation Viewer** for reading published content - **Version Access Control** when version availability affects what can be viewed - **Audiences** when content changes based on reader type Public readers usually do not need the administrative or project setup areas of Atloria. Their experience is centered on the published documentation itself. ## Which Role Sounds Most Like You? If you mainly manage structure, releases, and publishing, start with the Documentation Manager guides. If you write and maintain pages, the Technical Writer path will feel most familiar. If you set up projects and control access, follow the Project Administrator guides. If your focus is customer help and self-service, look at the Support Team Lead areas. If you are here to read published content, you will spend most of your time in the public documentation experience. ## Your First Day with Atloria Your first day in Atloria should feel simple and productive. This guide walks you through a few easy wins so you can get comfortable quickly, set up your workspace, and see useful results right away. You do not need to learn everything at once. A good first day in Atloria usually looks like this: 1. Sign in and get familiar with where things are 2. Create or open a project 3. Add your first documentation content 4. Review how your team will share and publish work 5. Explore one extra feature that gives you immediate value ## Start by Signing In and Getting Oriented If this is your first time using Atloria, begin by accessing your account and confirming that you can move around the main areas with confidence. A few helpful first steps: - Sign in to your Atloria account - Confirm you can reach your home area - Open the main navigation and notice the difference between project areas and admin areas - Make sure you know how to return to your project list at any time For help with account access and navigation, use these guides: - [Accessing and Registering Your Atloria Account](/accessing-and-registering-your-atloria-account) - [Understanding Account Entry Points and Session Navigation](/understanding-account-entry-points-and-session-navigation) - [Signing In to Atloria and Solving Access Problems](/signing-in-to-atloria-and-solving-access-problems) ### Quick win Your first quick win is simply reaching the right starting point with confidence. If you can sign in, move between your home area and projects, and understand where to begin, you are ready for the rest of your first day. ## Create or Open Your First Project Most work in Atloria starts inside a project. If your team has already created one for you, open it from your project list. If not, create a new project and follow the setup steps. On your first day, focus on these basics: - Give the project a clear name - Choose the setup path that fits your team - Complete the onboarding steps - Open the project home so you can see its main sections If you are not sure whether to start from connected content or set things up yourself, Atloria provides guidance for both paths. Use these guides for deeper help: - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) - [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding) - [Choosing Between Manual and Connected Project Setup](/choosing-between-manual-and-connected-project-setup) - [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) ### Quick win By the end of this step, you should have one project open in Atloria and know where its main controls live. That alone gives you a strong starting point for future work. ## Add Your First Documentation Page Once your project is ready, create or update a page so you can see how documentation work feels in Atloria. For your first page, keep it simple. You might add: - A project overview - A getting started page for teammates - A short process note - A draft page you plan to improve later This first edit helps you learn how content is organized and how your team will build documentation together. For step-by-step help, read: - [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) ### Quick win Your next quick win is publishing your first meaningful draft inside Atloria, even if it is only a short page. A small page is enough to help you understand how your team will create and maintain documentation. ## Review Project Settings and Sharing Basics After you have a project and at least one page, take a few minutes to review the settings that shape how your documentation is presented and managed. On your first day, you do not need to change everything. Just look through the available options so you know where to return later for: - Project details - Website and presentation options - Team-facing controls - Connected services and update behavior Helpful guides: - [Managing Project Settings and Website Options](/managing-project-settings-and-website-options) - [Configuring Project Webhooks and Related Controls](/configuring-project-webhooks-and-related-controls) ### Quick win A simple but valuable first-day win is knowing where your project settings live. Even if you make no changes yet, you will save time later by knowing where to go. ## Explore the Project Dashboard Before your first day ends, spend a few minutes on the project dashboard. This helps you understand the health and activity of your documentation work. Look for things like: - Current project activity - Recent updates - High-level performance information - Areas that may need attention To learn more, see: - [Working with Project Lists and Dashboards](/working-with-project-lists-and-dashboards) - [Analyzing Project Performance and Activity](/analyzing-project-performance-and-activity) ### Quick win This is a great first-day habit: open the dashboard and get a quick sense of what is happening. It helps you stay oriented without needing to dig into every detail. ## If You Are an Admin, Visit the Admin Workspace If your role includes team setup, permissions, or oversight, take time to visit the Atloria admin area. This is especially useful for project administrators and documentation managers. On your first day, focus on awareness rather than full setup. Review where Atloria keeps: - Administrative navigation - User access controls - Security and audit information - High-level activity and usage views Helpful guides: - [Using the Admin Workspace](/using-the-admin-workspace) - [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions) - [Reviewing Security and Audit Controls](/reviewing-security-and-audit-controls) - [Monitoring Administrative Analytics and Activity](/monitoring-administrative-analytics-and-activity) ### Quick win If you are responsible for oversight, your quick win is knowing where to manage people, review activity, and monitor usage in Atloria. ## A Simple First-Day Plan If you want an easy checklist, use this plan: ### In your first 15 minutes - Sign in to Atloria - Confirm you can move between home and project areas - Open your project list ### In your first hour - Create a project or open an existing one - Complete the onboarding steps - Visit the project home - Create your first documentation page ### Before the end of the day - Review project settings - Check the project dashboard - Visit the admin area if your role requires it - Save the guides linked in this article for later use ## What to Learn Next After your first day, the best next step is to go deeper into the area that matches your role. - If you create content, start with [Creating and Editing Documentation Pages](/creating-and-editing-documentation-pages) - If you manage projects, continue with [Managing Project Administration from the Project Home](/managing-project-administration-from-the-project-home) - If you are still setting up, review [Creating Projects and Completing Onboarding](/creating-projects-and-completing-onboarding) - If you oversee access and controls, open [Managing User Access and Administrative Permissions](/managing-user-access-and-administrative-permissions) ## Final Tip A successful first day in Atloria is not about using every feature. It is about getting comfortable, completing a few small tasks, and knowing where to go next. If you can sign in, open a project, create one page, and understand where settings and dashboards live, you have already made strong progress. ## Opening Atloria from the main entry page When you first arrive at Atloria’s public access area, you begin on a page that leads you into one of two account paths: **Sign In** or **Register**. These are the two main actions users use before they can reach any private Atloria workspace, project area, or admin page. If you already have an Atloria account, choose **Sign In**. If this is your first time using Atloria and you do not yet have account details, choose **Register**. This opening step matters because Atloria separates public access pages from the pages that require an account. You can move freely between the public account pages, but you cannot continue into the main Atloria workspace until you complete sign in successfully or finish creating a new account and are allowed into Atloria. The access flow is straightforward: - Start at the main entry page - Choose **Sign In** if you already have login details - Choose **Register** if you need to create an account - Complete the form on the page you selected - Continue into Atloria after successful access In practice, this means you should not try to use the registration form if you already have an account, and you should not use the sign-in form if you have never created one. The two paths are designed to guide you to the correct next screen. [SCREENSHOT: Atloria entry page showing the two main actions, Sign In and Register] After you select one of these options, Atloria opens the matching form page. Choosing **Sign In** takes you to the sign-in form. Choosing **Register** takes you to the account creation form. Both pages act as the front door to Atloria and help direct you into the correct account flow before you reach protected content. ## Choosing between registration and sign in The most important decision at the start is whether you need to **create** an Atloria account or **access** one that already exists. Use **Register** only when you are setting up your Atloria account for the first time. Use **Sign In** when your account already exists and you simply need to enter Atloria again. A quick way to decide: - Choose **Register** if you have never created an Atloria account before - Choose **Sign In** if you already have an email address and password for Atloria - If you are unsure, check whether you have used those same details to enter Atloria before Atloria also provides links between the two forms so you can correct your choice without going back to the main site manually. For example, if you open the registration page and then realize your account already exists, use the link on that page to switch to **Sign In**. In the same way, if you open the sign-in page and discover you do not yet have an account, use the link there to move to **Register**. Before continuing, have the right information ready: | What you need | When you need it | Notes | |---|---|---| | Email address | Register and Sign In | Use the email address tied to your Atloria account | | Password | Sign In | Enter the password you already use | | New password | Register | Create the password you want to use for future sign-ins | | Name | Register | Enter your name during account creation | Making the right choice here helps avoid duplicate accounts. If you already have access, signing in is the correct route. If you do not, registration starts your account setup. If you need more help with sign-in issues later, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). ## Registering a new Atloria account If you are new to Atloria, start from the main access page and select **Register**. This opens the account creation form. On that form, you will be asked to enter your **Name**, **Email**, and **Password**. Fill in each field carefully, since these details are used to create your account and sign you in afterward. Use this process: 1. Open the main Atloria access page. 2. Click **Register**. 3. Enter your **Name**. 4. Enter your **Email**. 5. Enter your **Password**. 6. Submit the registration form. [SCREENSHOT: Registration form showing Name, Email, Password, and the Register action] After you submit the form, Atloria creates your account if the details are accepted. When registration succeeds, Atloria then attempts to sign you in automatically using the same **Email** and **Password** you just entered. If that automatic sign-in succeeds, you are taken directly into the main Atloria workspace area rather than being asked to sign in again. If the account is created but the automatic sign-in does not complete, Atloria shows a message explaining that registration succeeded but login failed, and you should try signing in manually. If registration itself does not go through, Atloria shows an error message on the page so you know the account was not created successfully. This means the expected result after a successful registration is usually immediate entry into Atloria. You should not normally need to repeat your details on a separate sign-in page unless Atloria tells you the account was created but the login step did not finish. If you opened the registration page by mistake, use the page link to switch to **Sign In** instead of starting over. ## Signing in to an existing account If you already have an Atloria account, begin at the main access page and click **Sign In**. This opens the sign-in form, where you enter the same **Email** and **Password** you used when your account was created. Follow these steps: 1. Open the main Atloria access page. 2. Click **Sign In**. 3. Enter your **Email**. 4. Enter your **Password**. 5. Submit the sign-in form. [SCREENSHOT: Sign-in form showing Email, Password, and the Sign In action] When your details are correct, Atloria signs you in and takes you into the main authenticated area. From there, you can continue to your workspace instead of staying on the public access pages. This is the normal result for returning users. If the email address or password does not match an existing account, Atloria displays the message **Invalid email or password** on the sign-in screen. If something unexpected happens during the sign-in attempt, Atloria shows **An error occurred. Please try again.** In either case, you remain on the sign-in page so you can correct the details and try again. If you reach the sign-in page and realize you have never created an account, use the link on that page to switch to **Register**. This is the fastest way to move into the correct account flow without returning to the main entry page. The sign-in page is only for existing accounts. If you use it with details that have not been registered yet, Atloria will not let you continue into the workspace. In that case, move to the registration page and create your account first. ## Understanding where each access path takes you Atloria has two public account paths, and both begin before you enter any private workspace content. The visible screens involved are the main entry page, the **Register** form, and the **Sign In** form. From there, your path depends on whether you are a new user or a returning user. Here is the basic flow for each route: | User type | Starting action | Next screen | Expected result | |---|---|---|---| | New user | **Register** | Registration form | Account is created, then you are typically signed in and taken into Atloria | | Returning user | **Sign In** | Sign-in form | You enter Atloria after successful sign in | | User on wrong page | Form link | Opposite form | You switch between **Register** and **Sign In** without restarting | The public pages are: - The main entry page - The **Register** page - The **Sign In** page The protected area is: - The main Atloria workspace you reach after successful account access This distinction is useful when explaining access to teammates. If someone is still looking at the registration or sign-in form, they are still in the public account-entry part of Atloria. Once they submit valid details and are redirected forward, they have crossed into the authenticated area. For support and onboarding conversations, the easiest comparison is this: - **New users** start with **Register**, complete **Name**, **Email**, and **Password**, and are usually taken straight into Atloria after account creation. - **Returning users** start with **Sign In**, enter **Email** and **Password**, and go directly into Atloria if the credentials are correct. If you want more detail on what happens after you enter Atloria, continue with [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). ## Fixing common account access problems Most account access issues in Atloria come from choosing the wrong form or entering details in the wrong place. Start by checking which page you are on. If you are on **Register** but already have an account, switch to **Sign In** using the link on the page. If you are on **Sign In** but have never created an account, switch to **Register** instead. Use these checks to solve the most common problems: - **You landed on the wrong form** - Use the page link to move between **Register** and **Sign In** - Do not return to the main site unless you want to restart from the beginning - **You cannot get into Atloria after entering details** - Confirm you are using **Sign In** for an existing account - If you are on **Register**, you may be trying to create a second account instead of entering an existing one - **You are not sure where to begin** - Start from the main Atloria entry page - Choose **Register** if no account exists yet - Choose **Sign In** if you already have account details - **You need to confirm what “successful” looks like** - After successful sign in, Atloria takes you into the main workspace - After successful registration, Atloria usually signs you in automatically and takes you into the same authenticated area On the sign-in page, Atloria may show **Invalid email or password** if the credentials do not match an existing account. It may also show **An error occurred. Please try again.** if the sign-in attempt cannot be completed. On the registration page, Atloria shows an error message if account creation does not succeed. [SCREENSHOT: Example account access error message displayed on the sign-in page] If the page keeps you on the public form instead of moving you into Atloria, that usually means the access step did not complete successfully and should be retried on the correct form. ## Overview Atloria gives you a simple entry flow built around two clear choices: **Sign In** for existing users and **Register** for new users. Both options are part of Atloria’s public account access area, which appears before you can reach private workspaces, project pages, or admin screens. The overall experience is designed to guide you into the right path quickly: - The main entry page presents the two account actions - The **Register** page collects **Name**, **Email**, and **Password** - The **Sign In** page collects **Email** and **Password** - Links on each form let you switch to the other form if needed - Successful access moves you into Atloria’s authenticated workspace area For new users, the registration path does more than create an account. After the form is submitted successfully, Atloria attempts to sign the user in automatically. That means many first-time users move directly from the registration form into Atloria without needing a separate sign-in step. Returning users follow the shorter path by opening **Sign In**, entering their existing details, and continuing into Atloria. This structure is especially helpful for onboarding and support teams because the visible access points are easy to explain. If someone has account details already, direct them to **Sign In**. If they do not, direct them to **Register**. If they choose the wrong page, they can switch forms using the link on the screen. [SCREENSHOT: Public account access flow from main entry page to Register or Sign In] The key thing to remember is that the public account pages are only the starting point. You enter the main Atloria workspace only after registration or sign in succeeds. ## Prerequisites Before you try to enter Atloria, make sure you have the details that match the account path you plan to use. Atloria keeps registration and sign-in separate, so having the right information ready will help you complete the correct form without delay. For **Register**, prepare: - Your **Name** - Your **Email** - A **Password** you want to use for your Atloria account For **Sign In**, prepare: - The **Email** already associated with your Atloria account - The **Password** for that account A few simple checks can save time: - If you have never created an Atloria account before, start with **Register** - If you have signed in to Atloria before, start with **Sign In** - If you open the wrong page, use the link on that form to switch instead of restarting - If you expect to enter Atloria immediately after registration, use the same **Email** and **Password** carefully because Atloria uses them again for automatic sign-in You do not need access to any project, admin page, or workspace before completing this step. Those areas stay unavailable until your account access is successful. The only pages you need at this stage are the public account entry page and the two forms: **Register** and **Sign In**. [SCREENSHOT: Side-by-side view of Register and Sign In forms highlighting the required fields] If you are helping another user choose the right starting point, ask one question first: “Do you already have an Atloria account?” That answer determines the correct page immediately. From here, the next helpful topic is [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). ## Opening analytics views for all projects or a single project In Atloria, start from the main signed-in workspace and open the **Admin** area if you want a cross-project view. On the **Admin** screen, look for the **Analytics** card labeled **Usage statistics and insights**. Selecting that card opens **Analytics & Insights**, which is the enterprise-level analytics area for reviewing activity across your documentation work. At the top of the analytics screen, use the page title and surrounding controls to confirm what you are looking at before you read any numbers. When you are working at the enterprise level, the dashboard is meant to summarize activity across projects rather than showing only one project. If you need to focus on a single documentation workspace, switch to that project first and then open its analytics view from the project area. That project-level view is where you review performance for one project instead of the full Atloria workspace. As you move between enterprise and project analytics, pay close attention to the filters shown near the top of the page. Before interpreting any chart, check: - the selected **date range** - the current **project** or **All Projects** selection - any **team** or **contributor** filter that may narrow the results These controls change what every chart and table is showing. A chart that looks low may simply be filtered to one project or one contributor. Use the project switcher to move between **All Projects** and an individual project dashboard when you want to compare broad trends against project-specific results. This is especially useful when a project appears unusually active or unusually quiet and you want to confirm whether that pattern is local or part of a larger trend. [SCREENSHOT: Analytics & Insights screen showing the page header, project selection, and date range controls] ## Reading documentation performance metrics on the main dashboard The main analytics dashboard is easiest to read when you separate reader activity from documentation team activity. In Atloria, top-level metric cards usually summarize the most important numbers for the selected date range. Depending on the view available in your workspace, these cards may include measures such as **page views**, **unique readers**, **search usage**, and documentation activity totals tied to content work. Treat reader-focused metrics and authoring-focused metrics as two different stories: - **Page views** show how often documentation pages were opened - **Unique readers** help you estimate how many different people used the content - **Search usage** shows how often people searched instead of browsing directly - content activity totals reflect work done by your team, such as edits or publishing activity This distinction matters. A project can have strong reading traffic but little recent authoring activity, which may mean the content is stable and heavily used. Another project may show many edits and publishes but limited reader traffic, which can point to a newer documentation set or one that still needs promotion. Look beside each metric card for any comparison against the previous period. Trend indicators help you see whether a number is rising, falling, or staying steady. Always compare these indicators using the same date range. A monthly increase is meaningful only if the card is also set to a monthly comparison. For charts below the summary cards, use the legend to turn series on or off if that option is available, and hover over points or bars to inspect exact values for a day, week, or month. If the dashboard includes a metric selector, switch between available measures to see whether the same time period tells a different story for readers versus contributors. [SCREENSHOT: Main analytics dashboard with KPI cards and a trend chart with hover values] ## Comparing activity trends across projects and teams When you want to understand which documentation areas are growing, slowing down, or being actively maintained, start with the **Projects** filter. In Atloria, this filter lets you narrow the analytics view to one project or compare several projects within the same reporting window. Use the same date range for all compared projects so the results stay meaningful. After selecting the projects you want to review, add a **Team** or **Contributor** filter if your workspace includes those options. This helps you isolate activity from a specific documentation group or from a project that is mainly maintained by one administrator. Filtering this way is useful when you are reviewing ownership, workload, or adoption across teams. Read trend charts by matching the line or bar color to the legend, then scan for three patterns: 1. steady activity over time 2. sudden spikes in creation, updates, or publishing 3. long flat periods with little or no movement Steady activity often points to ongoing maintenance. Spikes usually line up with releases, migrations, or cleanup work. Flat periods can reveal neglected projects or projects that are complete but no longer updated. If Atloria shows a comparison table below the charts, sort it by the column that matches your question. For example: - sort by **views** to find the most-used projects - sort by **edits** to find where the team is actively revising content - sort by **recent activity** to spot projects that may need attention A useful pattern is to compare high views with low edits. That often highlights mature content that many readers rely on. Low views with high edits can indicate active work on content that has not yet reached its audience. [SCREENSHOT: Project comparison view with project filter, contributor filter, and sortable activity table] ## Investigating usage patterns and content engagement To understand whether documentation is actually helping readers, move beyond project totals and look for page-level or article-level breakdowns where available. In Atloria, these views help you identify the documentation that gets the most attention and the content that receives little or no traffic. Start by reviewing the highest-viewed pages, then compare them with low-traffic pages in the same project. High-traffic pages often reveal what readers need most. These may be setup guides, troubleshooting pages, release-related instructions, or frequently referenced technical documentation. Low-traffic pages are not automatically a problem, but they deserve a closer look. They may be hard to find, too specialized, outdated, or no longer relevant. Search-related analytics add another layer. If Atloria shows search usage in the analytics area, use it to understand what readers are trying to find. Repeated search activity can point to strong demand for a topic. If readers search often but engagement stays low, that may suggest content gaps, unclear navigation, or page titles that do not match the words readers use. Time-based patterns are also important. Review traffic by day, week, or month and look for spikes after: - documentation releases - product launches - internal announcements - onboarding pushes Then compare those spikes across projects. If most traffic is concentrated in only one or two projects, your documentation usage may be uneven. If engagement is spread across many projects, that usually indicates broader adoption of Atloria documentation across the organization. Use these patterns together rather than in isolation. A page with high views, high search demand, and repeated traffic spikes is usually a strong candidate for continued improvement. For more project-specific analysis, see [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). ## Using filters and date ranges to answer specific reporting questions Filters are what turn the analytics dashboard from a general summary into a reporting tool. In Atloria, begin with the **date range** control. Use it to match the reporting window to the question you need to answer. For example, choose a custom range for a release period, a quarterly review, or a recent documentation campaign. Keeping the date range aligned with a real event makes the charts much easier to interpret. Once the time period is set, combine it with the other available filters. A few common reporting questions map well to simple filter combinations: | Reporting question | Useful filters | |---|---| | Which project gained the most readers this month? | **Date Range: This Month** + **Project: All Projects** | | Which team was most active during a release window? | **Custom Date Range** + **Team** | | Did one contributor drive most recent publishing activity? | **Date Range** + **Contributor** | | How did one project perform after launch? | **Project** + **Custom Date Range** | When a chart or table looks unexpectedly narrow, check for leftover filters before drawing conclusions. A contributor filter from an earlier review can make enterprise results look incomplete. Reset filters to return to the default analytics view whenever the dashboard stops matching your expectations. If your Atloria workspace includes sharing or export options for analytics results, use them after you have confirmed the filters. This is the best time to save or export because the view reflects the exact scope you want stakeholders to see. If you are preparing broader reporting for administrators, it also helps to compare your findings with the admin workspace guidance in [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). [SCREENSHOT: Analytics filters showing a custom date range and project/team selections] ## Fixing common problems when analytics data looks incomplete or misleading When analytics results do not look right, start with the visible controls on the page instead of assuming the data is wrong. In Atloria, most confusing reports come from scope and timing rather than a broken dashboard. If no data appears in charts, first confirm the **date range**. A very narrow range can remove all visible activity. Next, check whether the dashboard is set to a single project instead of **All Projects**. If you are in a project-level analytics view, remember that only that project’s documentation activity will appear. Also confirm that the project has published documentation available for readers, since unpublished work may not show the same usage patterns. If metrics seem lower than expected, review every active filter. A **Team** or **Contributor** filter can reduce totals dramatically. This is especially common after comparing one group and then forgetting to clear the filter before returning to enterprise reporting. When project totals do not match enterprise totals, verify whether some projects are outside the current scope. Archived projects, excluded projects, or projects not included in the current filter set can make the enterprise view and project rollups look inconsistent. Always compare like with like: same date range, same project scope, same contributor scope. If recent activity appears to be missing, check whether the changes were actually published. Draft edits and published documentation do not represent the same kind of activity. Also allow for a short delay before newly published work appears in analytics. A quick troubleshooting order works well: - confirm the **date range** - confirm **All Projects** or the intended project - clear **Team** and **Contributor** filters - verify the content was **published** - refresh the analytics view and check again If you also need to review admin-side activity and audit-related visibility, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls). ## Overview Atloria gives you two useful ways to analyze documentation performance: an enterprise-level analytics view for cross-project reporting and a project-level analytics view for focused review inside one documentation workspace. This document is about using those views to understand how readers interact with your documentation and how your team is maintaining it over time. The most effective way to work in analytics is to read the dashboard in layers. Start with the top summary cards to get a quick picture of reader traffic and documentation activity. Then move into trend charts to see whether usage is rising, falling, or staying steady across the selected period. After that, narrow the view with project, team, or contributor filters so you can answer a specific question instead of relying on broad totals. As you review results in Atloria, keep these distinctions in mind: - enterprise analytics shows patterns across multiple projects - project analytics focuses on one project’s documentation activity - reader metrics reflect content consumption - authoring metrics reflect content work such as updates and publishing - filters can completely change the meaning of a chart or table This guide focuses on reading the analytics screens that are available in Atloria today, including the **Analytics** area in the **Admin** workspace and project-specific analytics pages. It also explains how to avoid common mistakes, such as comparing filtered project data with enterprise totals or reading a narrow date range as a long-term trend. If you are new to the admin side of Atloria, it helps to be familiar with the navigation described in [Using the Admin Workspace](doc:using-the-admin-workspace). If you already know where analytics lives, the sections above will help you turn the dashboard into a practical reporting tool rather than just a collection of charts. ## Prerequisites Before you start comparing documentation performance in Atloria, make sure you can access the right workspace and that you know which level of reporting you need. You do not need advanced setup knowledge, but you do need enough access to open either the **Admin** analytics area or the analytics view inside a project. It helps to have the following in place: - an Atloria account that can sign in successfully - access to the **Admin** workspace if you need cross-project reporting - access to at least one project if you want project-level analytics - documentation that has been published, so reader activity can be measured - a clear reporting question, such as comparing projects, checking reader growth, or reviewing recent publishing activity You should also be comfortable moving between the main workspace, the **Admin** area, and individual projects. If you need help with account access first, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). Before opening analytics, decide what you want to compare: - **All Projects** if you are reviewing organization-wide documentation performance - a single project if you are checking one documentation workspace - a specific date range if you are measuring a release, campaign, or reporting period - a team or contributor filter if you are reviewing ownership or workload If the **Analytics & Insights** screen in your Atloria workspace is marked as coming soon or has limited content, you may only be able to review part of the reporting workflow right now. In that case, use the available project analytics screens where possible and continue with [Using Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements) when you are ready to turn reporting into action. ## Opening project analytics and choosing the right reporting scope In Atloria, start from your signed-in workspace and open the project you want to review. From there, go to the **Analytics** area for that project. The analytics screen is where you check performance and activity signals before making publishing or maintenance decisions. If your workspace includes a project selector, use it to switch between one project and another without leaving the reporting area. This matters because the same charts can mean very different things depending on whether you are looking at one project or a broader view that combines multiple projects. Before reading any numbers, check the controls at the top of the screen. Look for the active **project selection**, the **date range**, and any visible filters related to activity type or content scope. If you are reviewing a recent release, choose a shorter date range so you can focus on the most recent publishing period. If you want to understand long-term maintenance patterns, switch to a wider range and compare several weeks or months of activity instead of a single burst. A good habit is to pause and confirm exactly what the screen is showing before you interpret the charts: - Which project is selected - Whether you are viewing one project or a broader reporting view - What date range is active - Whether any activity or content filters are narrowing the results [SCREENSHOT: Analytics screen header showing the project selector, date range control, and active filters] If the numbers seem unexpectedly high or low, the first thing to verify is the reporting scope. A workspace-wide view can make a quiet project look busier than it really is, while a single-project view can hide broader team patterns. Keeping the scope consistent is especially important before you compare projects later in your review. ## Reading performance metrics for documentation output At the top of the analytics dashboard, Atloria may show summary cards and charts that help you judge documentation output over the selected period. Read these as a quick snapshot of how much work has been published, how often content has been updated, and whether the project appears to be moving forward or leveling off. These summary values are most useful when you read them together instead of treating any one card as the full story. Start with the main metric cards. Look for values that reflect output volume, update pace, or other project performance signals shown on the dashboard. Then check whether Atloria shows a comparison to the previous period. A positive change can suggest stronger publishing momentum, while a flat or negative change may point to slower delivery, delayed updates, or a project that has entered a maintenance phase. Trend charts help you decide whether a change is meaningful. For example, one strong week of publishing can create a temporary jump, but that does not always mean the project has improved overall. A steadier upward line across several periods is usually a stronger sign than one isolated spike. In the same way, a short dip may not be a problem if the broader trend is stable. Use the dashboard differently depending on your role: | What you are checking | What to focus on in Atloria | |---|---| | Content effectiveness | Published output, update frequency, and whether activity leads to visible documentation progress | | Project health | Overall consistency, recent movement, and whether the project shows regular maintenance or long gaps | | Publishing readiness | Whether recent work is turning into sustained output rather than staying in draft or review cycles | [SCREENSHOT: Analytics summary cards and a trend chart with current-period and previous-period comparison] If a metric rises while the trend line stays uneven, treat that as a signal to look deeper. Strong analytics decisions come from matching the headline numbers with the pattern shown in the chart below them. ## Analyzing activity trends to understand team and content momentum Activity trends show how work moves over time. In Atloria, use these charts to see whether a project is actively maintained, going through a release push, or sitting mostly unchanged. The timeline view is especially helpful because it shows when work happened, not just how much happened in total. Start by scanning the full selected date range. Look for periods where activity rises sharply or falls away. A cluster of edits or publishing events often points to release preparation, a documentation cleanup effort, or a concentrated update cycle. Long quiet stretches can mean the project is stable, but they can also signal that ownership has drifted or that planned updates are not being completed. The chart alone will not tell you which is true, so use it as a prompt to investigate rather than a final answer. If Atloria shows chart legends, hover details, or filter controls, use them to isolate the type of activity you want to inspect. This is useful when a peak looks unusual. A spike driven by publishing events tells a different story than a spike driven by repeated edits with little visible output. Hovering over points in the timeline can help you connect a peak to a specific period and compare it with nearby dates. When you review activity patterns, relate them to real work happening around the project: - Release cycles often create bursts of edits and publishing - Backlog cleanup may produce concentrated maintenance activity - Editorial slowdowns may appear as long flat sections in the chart - Stable projects may show lighter but regular activity instead of dramatic peaks [SCREENSHOT: Activity trend chart with timeline points, legend, and hover details] The most useful question to ask is not “Was there activity?” but “What kind of activity happened, and did it continue?” That helps you distinguish healthy momentum from short-lived bursts that do not improve the project over time. ## Comparing projects to find strong and weak documentation signals To compare projects fairly in Atloria, switch projects with the **project selector** while keeping the same **date range** and any other visible filters unchanged. This gives you a like-for-like comparison. If you change the date range between projects, the dashboard can create a misleading impression, especially when one project is in a release window and another is being viewed across a quieter period. As you move from one project to another, compare both the summary cards and the trend lines. A strong project usually shows a combination of regular activity, visible output, and a pattern that stays steady over time. A weaker project may show declining activity, irregular updates, or long periods with little movement. The goal is not to rank projects by volume alone. A smaller project can still be healthy if it is updated consistently and its output matches its maintenance needs. Pay special attention to mismatches between effort and results. For example, if one project shows a lot of activity but very little publishing progress, that can point to stalled reviews, repeated rework, or maintenance work that is not turning into finished documentation. On the other hand, a project with modest activity and steady output may be operating efficiently. Use comparisons to decide where attention is needed most: 1. Select the first project and note the active date range. 2. Review the main cards and the overall trend line. 3. Switch to the next project without changing the filters. 4. Compare consistency, output, and recent direction. 5. Flag projects with declining trends or heavy effort but weak results. [SCREENSHOT: Project selector in Analytics with the same date range applied across multiple projects] This kind of comparison is most useful when planning editorial support, maintenance reviews, or publishing follow-up. If one project is clearly lagging, you have a stronger basis for prioritizing it than if you looked at activity in isolation. ## Turning analytics into publishing and maintenance decisions The value of project analytics in Atloria is not just seeing charts—it is deciding what to do next. Once you have reviewed performance cards and activity trends, use those signals to choose whether a project needs more publishing effort, scheduled maintenance, or no immediate change. A sustained decline across the dashboard is usually the clearest sign that a project needs attention. If output drops over multiple periods and activity also slows down, review whether the content is becoming outdated, whether ownership is unclear, or whether work is getting stuck before publication. This is a good moment to open the project workspace and inspect recent documentation changes, version progress, or review bottlenecks. Repeated spikes deserve a different response. If Atloria shows bursts of edits or maintenance activity but the project does not gain steady output afterward, the team may be spending time on work that is not reaching completion. In that case, focus on the workflow itself: review cycles, publishing timing, or how maintenance tasks are being prioritized. Healthy projects usually show three signals together: - Stable or gradually improving trend lines - Regular activity across the selected period - Positive or steady period-over-period changes in the summary cards Use those patterns to decide your next move: | Analytics pattern | Likely decision | |---|---| | Declining output and declining activity | Schedule a maintenance review | | High activity with weak publishing results | Investigate stalled work or inefficient review flow | | Stable activity and steady output | Leave the project in steady-state monitoring | | Improving output with regular activity | Support continued publishing momentum | [SCREENSHOT: Analytics dashboard with trend lines and summary cards used to guide project decisions] If you need to act on what you find, pair this review with the project workspace guidance in [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). ## Avoiding common mistakes when interpreting project analytics Project analytics are only useful when you read them carefully. In Atloria, the most common mistakes come from comparing unlike views, overreacting to short-term changes, or ignoring the project’s real operating context. The first mistake is comparing projects with different settings. If one project is shown with a short date range and another with a longer one, the numbers will not represent the same kind of activity. The same problem happens when one view includes extra filters and another does not. Before drawing any conclusion, confirm the active project, date range, and any visible filter controls at the top of the analytics screen. Another common mistake is treating one spike as proof of improvement. A single burst of edits or publishing can happen during a release push, a cleanup sprint, or a one-time correction. Check the periods before and after that spike. If the surrounding timeline is flat, the project may not actually be improving in a sustained way. It is also risky to rely on one summary card by itself. A project can show a strong top-line number while still having weak momentum underneath. Always combine the headline metrics with the trend chart and what you know about the project’s current phase. Low activity is not automatically bad, either. Some projects are complete, stable, or intentionally quiet between releases. Keep these checks in mind while reviewing analytics: - Match date range and filters before comparing projects - Read trend lines alongside summary cards - Check nearby periods before reacting to a spike or drop - Consider whether the project is active, stable, or between release cycles [SCREENSHOT: Analytics controls and chart area highlighting where to verify filters before comparing results] If you need a broader view of administrative reporting outside a single project, see [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Overview Atloria’s project analytics area helps you understand whether documentation work is active, effective, and moving toward publication. The focus of this screen is not just raw activity. It is the relationship between output, timing, and consistency. When you open analytics for a project, you are looking for signals that help you answer practical questions: Is this project being maintained regularly? Are recent efforts turning into published documentation? Is the current pattern healthy enough to leave alone, or does it need intervention? The main parts of the workflow are straightforward. You choose the correct reporting scope, confirm the active date range and filters, review the summary cards, and then read the trend charts for context. After that, you compare projects using the same reporting settings so you can identify stronger and weaker documentation patterns. This gives Documentation Managers and Project Administrators a shared way to discuss project health without relying on guesswork. This guide is especially useful when you are deciding where to spend limited editorial time. A project with steady output and regular activity may only need routine monitoring. A project with repeated bursts and little visible progress may need a closer review. A project with long-term decline may need maintenance planning or publishing support. Use this guide alongside related Atloria workflows when you need to act on what the analytics show: - [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) - [Managing Project Workspaces and Recent Activity](doc:managing-project-workspaces-and-recent-activity) - [Using Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements) [SCREENSHOT: Project analytics page showing summary cards, trend charts, and project/date filters] The sections above walk through how to read the screen carefully so your decisions are based on patterns, not isolated numbers. ## Prerequisites Before you start analyzing project performance in Atloria, make sure you can access the project workspace and open its **Analytics** area. You do not need advanced setup knowledge, but you do need enough access to view the project and move between reporting views if your workspace includes more than one project. You will get the most value from this guide if the following are already true: - You can sign in to Atloria and reach the main workspace - You can open at least one project you are responsible for reviewing - The project already has some documentation activity to analyze - You understand the project’s recent context, such as a release cycle, maintenance push, or quiet period - You can recognize the active **date range** and any visible analytics filters on the screen If you are still getting comfortable with access and navigation, review these guides first: - [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) - [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) - [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces) It also helps to know what kind of decision you are trying to make before you open analytics. For example, you may be checking whether a project needs maintenance, whether publishing activity is improving, or which project should receive editorial attention first. Having that question in mind makes it easier to choose the right date range and compare the right projects. [SCREENSHOT: Project workspace navigation with Analytics available from the project area] From here, continue with [Reading Project Analytics for Documentation Decisions](doc:reading-project-analytics-for-documentation-decisions) to turn these signals into more specific content and release choices. ## Preparing a Web Page for a Clean Screenshot Before you capture anything, make sure the page you want to document is actually showing the final content you want readers to see. In Atloria, screenshot work is most useful when the image matches the exact state of the page a user would recognize in a guide, release note, or support article. Start by opening the target page URL in your browser and watching for redirects. A page may open one address and then forward you to another version of the page, or it may send you to a sign-in screen first. If that happens, stop and decide whether your screenshot should show the public page, the signed-in view, or the login experience. If the page lands on a sign-in form instead of the content, complete sign-in before capturing if your goal is to document the actual page content. Next, clear anything that blocks the page itself. Cookie notices, welcome pop-ups, announcement banners, and modal windows can cover buttons, page titles, or navigation. Dismiss those items so the screenshot shows the real working screen rather than a temporary overlay. Window size matters too. Set your browser to the width you want to use across the whole documentation set. This helps keep side navigation, top bars, tabs, and content panels in the same position from one image to the next. If you change browser width between captures, the layout may shift and make your screenshots look inconsistent. Finally, decide what kind of image you need: - **Visible area capture** works best when the important content is already on screen. - **Full-page capture** is better for long pages, settings screens, or documentation pages that continue below the fold. If the page has sticky headers, floating buttons, or long scrolling sections, check how those elements appear before you capture. [SCREENSHOT: Browser showing a fully loaded page with overlays dismissed and the layout ready for capture] ## Capturing a Screenshot from a URL 1. Open the screenshot capture tool you use for Atloria documentation and locate the **URL** field or address input for page capture. 2. Paste or type the full web page address into that field. Double-check the address before starting so you capture the correct page version, especially if you work across multiple projects, public documentation pages, or signed-in workspaces. 3. Start the capture and wait for the page to finish loading. Do not save the image as soon as the page first appears. Give the page time to render web fonts, charts, tab content, and any sections that load after the main layout appears. If images or panels are still appearing, wait a little longer. 4. Choose the capture type that fits the page: - Use **Visible area** when you only need what is currently on screen. - Use **Full page** when the page continues below the fold and the lower sections matter to the documentation. 5. As soon as the preview appears, inspect it before saving. Look for the page title, main content area, navigation, and any buttons or tabs that readers need to recognize. Make sure nothing important is cut off at the top, bottom, or right edge. 6. If the preview is not right, adjust the page and capture again. It is usually faster to recapture immediately than to discover later that the wrong tab, wrong scroll position, or wrong page state was saved. This review step is especially important when documenting Atloria project pages, admin screens, or public documentation views where labels and layout help users orient themselves quickly. [SCREENSHOT: Screenshot capture tool with a URL entered and a preview of the captured page] ## Saving and Organizing the Screenshot File Once the preview looks correct, save the screenshot right away instead of leaving it in a temporary preview state. If your capture tool offers **Save** or **Download**, use that action after you confirm the image is complete and readable. A clear naming pattern saves time later when you add images to Atloria documentation. Name the file based on what the screenshot actually shows, not when you took it. Good names usually include the page or feature and, if helpful, the workflow step. For example, a name based on a project settings page is easier to find later than a generic file name created by your browser. Use a consistent pattern such as: | What to include | Example style | |---|---| | Feature or page name | project-settings | | Workflow step | step-2 | | View type | public-view or admin-view | Save the image in the project’s intended screenshots or assets folder rather than leaving it in a general downloads folder. This matters when several people work on the same documentation set or when you need to update screenshots during a release cycle. A screenshot stored in the right folder is much easier to reuse, review, and replace. Before you move on, check the saved file itself: - Confirm the file opens correctly. - Check that the image format matches your team’s documentation standard. - Make sure the dimensions are large enough for readers to see labels and controls clearly. - Verify you saved the final version, not an earlier test capture. If you are building a larger screenshot library, this is also a good point to align your file storage approach with [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation). [SCREENSHOT: Saved screenshot files organized in a project assets folder with descriptive file names] ## Checking the Screenshot Before Adding It to Documentation Before placing a screenshot into a documentation page, inspect it as if you were the reader seeing that screen for the first time. A screenshot can look acceptable at a glance but still contain small problems that make instructions harder to follow. Start with the edges of the image. Make sure navigation is not cropped, tab labels are complete, and no dropdown or side panel is cut off halfway. If the screenshot shows a menu, modal, or settings panel, confirm the entire item is visible. Partial interface elements often confuse readers because they cannot tell whether the image is incomplete or the page itself is broken. Next, look for information that should not appear in published documentation. Check the page content and the browser area for account names, email addresses, internal links, or other identifying details. If the screenshot includes signed-in areas of Atloria, review the image carefully before reuse across public or shared documentation. Then compare the screenshot to the current Atloria screen you are documenting. Labels, tabs, and button text can change over time. If the screenshot shows an older layout or outdated wording, replace it before publishing. This is especially important for admin pages, project navigation, and settings screens where readers rely on exact labels. Finally, view the image at the size it will appear in the document. Text that is readable in a full-size image preview may become too small once inserted into a page. Pay close attention to: - Tables - Tabs - Dense settings panels - Side navigation labels - Small action buttons If readers need to zoom in just to recognize the screen, recapture at a better size or crop more tightly around the important area. [SCREENSHOT: Review view highlighting readable labels, full navigation, and no sensitive information] ## Getting Better Results from Repeated Captures When you are capturing several screenshots for the same Atloria guide, consistency matters as much as clarity. A set of screenshots looks more professional and is easier to follow when each image uses the same visual setup. Use the same browser, zoom level, and window width every time. This keeps page headers, side navigation, content panels, and button placement stable across the full documentation set. If one screenshot is captured at a narrow width and the next at a wide width, the layout may shift from stacked sections to side-by-side panels, which makes the guide feel uneven. Before each recapture, refresh the page. This helps remove stale notifications, outdated loading states, and temporary interface changes that may have appeared during earlier work. It is especially useful on pages that include dynamic content, status messages, or widgets that change after the page first loads. You should also clean up the browser environment before capturing: - Close chat widgets if they overlap the page. - Dismiss announcement banners that may appear only sometimes. - Turn off browser extensions that inject icons, pop-ups, or side panels. - Make sure browser zoom has not changed since the last capture. If you are documenting a sequence of steps, keep the same approach for each image. For example, if your first screenshot shows the full browser content area with the page title and left navigation visible, keep that framing style for the rest of the guide unless you intentionally switch to a close-up for detail. For larger documentation efforts, it helps to pair this consistency work with the organization practices in [Organizing Screenshots for Documentation and Releases](doc:organizing-screenshots-for-documentation-and-releases). ## Fixing Common Screenshot Capture Problems 1. If the screenshot shows a blank page, first confirm the URL actually opens in the browser. Then wait longer before capturing again. Some pages display the frame of the page first and load the real content a moment later. Refresh the page and retry once the visible content has fully appeared. 2. If only part of the page is captured, check whether you selected **Visible area** instead of **Full page**. For long pages, the visible option may stop at the current screen height. If the page still captures incorrectly, look for sticky headers, floating buttons, or fixed panels that may interfere with the result. 3. If the screenshot shows a login page, cookie message, or consent banner instead of the content you expected, complete the required action first. Sign in, dismiss the banner, or close the modal, then start the capture again. The final image should show the actual page content, not the step that blocked access to it. 4. If the saved image looks blurry, inspect your browser zoom and display scaling before recapturing. Also check whether the output image is too small for the page you are documenting. A larger, cleaner capture is usually better than trying to reuse a blurry image in a help article. 5. If charts, fonts, or page sections are missing, give the page more time to render and then recapture. This often fixes screenshots taken too early. 6. If repeated captures still vary from one attempt to the next, reset the page state by refreshing the page, closing extra browser overlays, and recapturing with the same window size as your earlier images. If screenshot problems continue across multiple pages, the troubleshooting patterns in [Troubleshooting Screenshot Availability Across Projects and Versions](doc:troubleshooting-screenshot-availability-across-projects-and-versions) can help you standardize your process. ## Overview Capturing screenshots from web pages in Atloria is about more than saving an image of what is on screen. The goal is to produce screenshots that clearly support documentation, match the current interface, and stay consistent across a project or release. A useful screenshot should show the right page state, include the labels and controls readers need to recognize, and avoid distractions such as pop-ups, banners, or incomplete loading. This workflow usually follows four parts: - Prepare the page so the correct content is visible. - Capture either the visible area or the full page. - Save the image with a useful name in the right folder. - Review the image before adding it to documentation. These steps are especially important when you are documenting Atloria project screens, public documentation pages, admin areas, or settings views. Readers often rely on screenshots to confirm they are on the correct page, so even small issues such as clipped tabs, outdated labels, or unreadable text can reduce the value of the guide. If you are new to screenshot work in Atloria, treat each image as part of a larger documentation set rather than a one-off file. Consistent browser width, clean page state, and organized file names make future updates much easier. This becomes even more important when screenshots are reused across versions, reviewed by teammates, or added to public-facing documentation. For broader screenshot management practices, see [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation). The next step in this workflow is [Capturing Website Screenshots for Documentation](doc:capturing-website-screenshots-for-documentation), which builds on these basics for more structured documentation capture work. ## Prerequisites Before you start capturing screenshots from a web page, make sure you have the basics ready so the process goes smoothly. - Access to the page you want to capture in your browser - The correct URL for the page, including any signed-in or public view you intend to document - Permission to view the content if the page requires login - A screenshot capture tool or browser-based capture option - A folder location where your Atloria documentation images should be saved - Enough screen space to set a consistent browser window size It also helps to confirm a few page conditions before you begin: - The page loads successfully without errors - Any required sign-in has already been completed - Cookie notices, pop-ups, and modal dialogs can be dismissed - The content you want to show is available on screen - Your browser zoom is set to the level you plan to use for the full documentation set If you are capturing screenshots as part of a project documentation workflow in Atloria, you should already know which page or feature the image belongs to. That makes it easier to choose the right file name and save location from the start. For users who are still getting familiar with Atloria navigation, these related guides may help before you begin: - [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation) - [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) - [Managing Project Workspaces and Recent Activity](doc:managing-project-workspaces-and-recent-activity) From here, continue with [Capturing Website Screenshots for Documentation](doc:capturing-website-screenshots-for-documentation) to move from basic page capture into documentation-focused website screenshot workflows. ## Starting a Support Chat and Sending Your First Message In Atloria, start from the support agent chat screen for the agent you want to use. The main area of this screen is the conversation panel, where your questions and the agent’s replies appear as separate message entries. Below that, you will see the message composer, where you type your question, and a send action used to submit it. 1. Open the support agent chat screen. 2. Click inside the chat input field at the bottom of the conversation. 3. Type your question in plain language. For example, ask about documentation content, project knowledge, or a support issue you want the agent to answer from available documentation. 4. Use the **Send** action to submit your message. [SCREENSHOT: support agent chat screen showing the conversation panel, message input field, and Send action] After you send a message, Atloria adds your text to the conversation as your own entry. When the support agent replies, that answer appears as a separate entry in the same thread. This makes it easy to see who said what without losing the flow of the conversation. While you wait, expect the chat to show that the reply is still being generated. Depending on the screen state, you may see a loading or in-progress response area before the final answer appears. Wait until the reply finishes before judging the answer or asking a follow-up question, especially if you are using the conversation for knowledge validation. If your message does not appear right away, first check that the chat input still contains your text and that the send action was available when you clicked it. If Atloria shows an error message, correct the issue and send the message again. For account access help before you reach the chat area, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). ## Reviewing Conversation History and Following Ongoing Threads The support chat keeps your discussion together in one ongoing thread, so you can scroll through earlier messages and continue the same conversation without repeating yourself. In the conversation history area, prompts and replies appear in chronological order, with older entries above newer ones. This layout helps you retrace the discussion from the first question through the latest answer. 1. Open the conversation you want to review. 2. Scroll upward through the message list to find earlier questions and replies. 3. Read your previous prompts before sending a follow-up so you do not repeat details the agent has already seen. 4. Continue typing in the same message composer if you want the next question to build on the existing discussion. [SCREENSHOT: conversation history with earlier user questions and later agent replies shown in order] This history is especially useful when you are checking whether an agent answer stays consistent across several follow-up questions. Instead of starting over, you can ask a clarifying question in the same thread and see how the new answer relates to what the agent already said. Each message is shown as its own conversation entry, so you can quickly distinguish your messages from the agent’s responses. If the chat screen shows labels, timestamps, or grouped replies, use those details to confirm the order of events and identify which answer belongs to which question. Keep in mind that the thread preserves context, so the agent may use earlier messages when answering later ones. If you need to compare how the agent answered in a different situation, do not overwrite the current thread with a completely unrelated topic. Review the existing history first, then decide whether to continue here or clear the conversation and begin a separate run. ## Resetting a Conversation When You Need a Fresh Start When a conversation has too much old context, the quickest way to start clean is to use the reset or clear chat control on the support chat screen. This action removes the current conversation from the active view so you can begin a new thread without earlier questions affecting the next response. 1. Open the current support conversation. 2. Find the reset or clear chat control on the chat screen. 3. Select it when you want to remove the current conversation context. 4. If Atloria shows a confirmation prompt or warning, review it carefully and confirm only if you want to proceed. [SCREENSHOT: reset or clear chat control with any confirmation prompt] After a reset, the active conversation area returns to an empty state, and the earlier messages no longer appear in the current view. From there, you can type a new question into the message composer and begin a fresh thread. This is useful when you switch to a different topic, want to test the same question again without prior context, or notice that the conversation has drifted in the wrong direction. Use reset in situations like these: - You asked several follow-up questions and now want an unbiased first answer to a new topic. - The agent is relying on earlier details that are no longer relevant. - You are running a knowledge validation check and want each test conversation to stand on its own. - The thread includes incorrect assumptions and you do not want them carried forward. Treat reset as a deliberate action. If Atloria warns that clearing the conversation cannot be undone, assume the current thread will no longer be available in that active chat view after you confirm. Review anything important before clearing it. If you are unsure whether to reset, compare this thread with your current goal: continue the same topic in the existing conversation, or clear it if you need a truly separate exchange. ## Evaluating Agent Responses During Knowledge Validation When you use Atloria support agents for knowledge validation, focus on each individual reply rather than judging the whole conversation at once. After an agent response appears, look for the response evaluation controls attached to that reply. These may appear as rating actions or helpfulness choices directly alongside or beneath the answer. 1. Send a question and wait for the full agent reply to finish loading. 2. Find the evaluation controls connected to that specific response. 3. Mark the answer based on whether it was helpful, accurate, and suitable for the validation task. 4. If Atloria provides a comment field after a negative or incomplete rating, add details about what was wrong or missing. [SCREENSHOT: agent reply with response rating or validation controls] Use these controls to record the quality of a single answer. This matters when one response in a thread is strong but another is incomplete. By rating the exact reply, you create a more useful review trail for documentation and support quality checks. When deciding how to evaluate a response, look at: - Whether the answer addresses the question you actually asked - Whether the answer stays within the topic of the conversation - Whether important details appear to be missing - Whether the wording is clear enough for the intended audience If Atloria allows follow-up comments, use them to explain the issue in plain language. For example, note that the answer ignored part of the question, mixed two topics together, or gave a response that was too vague to validate documentation quality. Keep comments tied to the visible reply you are rating. That makes later review easier when your team compares multiple conversations and looks for patterns in weak answers. ## Managing Support and Validation Workflows Across Multiple Conversations Support chats in Atloria can serve two different purposes: getting an answer in the moment and testing how well an agent responds based on your documentation. The way you manage conversations should match that goal. For live support interactions, it usually makes sense to continue the same thread so the agent can use the earlier context. For knowledge validation, it is often better to separate test runs so each conversation reflects one scenario clearly. When you are handling several conversations, use the thread history and response ratings together. A documentation manager or team lead can review separate conversations to spot repeated questions, weak answers, or places where the agent consistently misses important details. If several threads show the same gap, that usually points to a documentation issue or a knowledge setup problem rather than a one-time chat mistake. A practical way to decide whether to continue or reset: - Continue the same thread when the next question depends on the previous answer. - Continue when you are clarifying details from the same support issue. - Reset when you are changing topics completely. - Reset when you want to test the same question again without earlier context. - Reset when a previous answer introduced confusion that could affect later replies. [SCREENSHOT: multiple support conversations being reviewed for answer quality and consistency] For validation work, compare conversations side by side in your review process, even if you open them one at a time. Look for patterns such as different wording leading to the same weak answer, or one thread producing a better result because the question was more specific. That comparison helps you improve both the documentation and the way support agents are used. For setup guidance before you begin this kind of review, see [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents). ## Fixing Common Problems with Messages, History, and Ratings Most chat issues in Atloria can be checked directly from the support conversation screen. Start with what is visible: the message field, the send action, the current thread, and the rating controls attached to each reply. If a message does not send: - Make sure your text is still in the chat input field. - Check whether the **Send** action is available or appears disabled. - Look for any visible error message near the conversation or input area. - Try sending again after the screen finishes any in-progress activity. If earlier replies seem to be missing: - Confirm whether the conversation was reset. - Check that you are viewing the correct thread and not a different conversation. - Scroll through the conversation panel to verify whether the messages are simply farther up in the history. If you cannot rate a response: - Wait until the agent reply has fully loaded. - Look directly on the specific response for the evaluation controls. - Make sure you are trying to rate an agent answer, not your own message. If the conversation feels off-topic: - Use the reset or clear chat control to remove the old context. - Start a new thread with a direct question that focuses on one issue. [SCREENSHOT: common chat issues including disabled Send action, missing history after reset, and response rating controls] When troubleshooting, avoid changing several things at once. First confirm whether the problem is with sending, viewing history, or rating a reply. That makes it easier to recover the conversation and continue your work without losing track of what happened. If the issue is related to account access rather than the chat itself, refer to [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). ## Overview Atloria support agent conversations are designed to help you ask questions, review answers, and judge how well those answers match your documentation. On the chat screen, you work mainly with three visible parts: the conversation panel, the message composer, and the send action. As you chat, your messages and the agent’s replies are added to the thread in order, making it easy to follow the discussion from start to finish. This workflow is useful in two common situations: - You need a quick answer from a support agent while working in Atloria. - You want to validate whether the agent gives accurate, useful answers based on your project documentation. The same conversation tools support both uses, but the way you manage the thread changes depending on your goal. For ongoing support, you will usually continue the same conversation so the agent can build on earlier questions. For validation work, you may reset the chat more often so each test starts with a clean context. You can also review earlier exchanges, clear the current conversation when needed, and rate individual answers after they appear. Those ratings help you identify whether a specific response was helpful or whether it needs follow-up. Over time, this gives your team a clearer picture of where support answers are strong and where your documentation may need improvement. [SCREENSHOT: complete support chat view showing conversation history, message entry area, and response evaluation controls] This document focuses on the basics of chatting, reviewing, resetting, and rating. The next document goes deeper into organizing and reviewing stored conversation activity: [Managing Agent Conversations and Chat History](doc:managing-agent-conversations-and-chat-history). ## Prerequisites Before you start chatting with a support agent in Atloria, make sure you can access the workspace where support agents are available and that you are already signed in to your account. If you still need help getting into Atloria, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). You should have: - Access to Atloria with permission to open the support agent chat area - A support agent available to chat with - A question, support scenario, or validation prompt you want to test - Enough context to recognize whether the reply is accurate and useful For knowledge validation work, it also helps to prepare a small set of test questions before you begin. Use questions that reflect real documentation needs, such as asking how a feature works, where a setting is managed, or what steps a user should follow. This makes your ratings more meaningful because you are checking the agent against realistic support and documentation scenarios. If your team is using support agents as part of a documentation review process, decide in advance how you will separate conversations: - Keep one thread for follow-up questions on the same topic - Reset the chat before testing a new scenario - Rate each answer after it appears so you do not forget which reply was strong or weak You do not need administrative tools to complete the tasks in this guide. You only need access to the support chat experience and a clear purpose for the conversation. From here, continue to [Managing Agent Conversations and Chat History](doc:managing-agent-conversations-and-chat-history) to work with stored threads and ongoing review activity. ## Opening AI Settings and Understanding What You Can Control In Atloria, AI settings are managed at the organization level, so the choices you make here apply across your shared workspace rather than only inside one project. Start by opening the admin area, then go to your organization settings and look for the AI settings section. On this screen, you should expect to see separate areas for **Providers**, **Prompt Behavior**, **Usage Visibility**, and **Request History**. These sections work together: the provider section controls which AI service Atloria uses, prompt behavior controls how Atloria frames AI requests, usage visibility controls who can see AI activity details, and request history shows past AI activity in a log-style view. [SCREENSHOT: AI settings page showing Providers, Prompt Behavior, Usage Visibility, and Request History sections] Different team members usually focus on different parts of this page. A **Project Administrator** typically handles the provider connection because that area includes the credentials and default service choices Atloria needs before AI features can work. A **Documentation Manager** usually reviews prompt behavior because those settings influence how consistently Atloria drafts or assists with documentation content. A **Support Team Lead** often checks usage visibility and request history so they can monitor activity, review past requests, and investigate reported issues. Before changing anything, take a moment to identify the controls on the page. Look for: - A provider selector or provider card - Form fields for connection details - Prompt-related settings such as default instructions or behavior options - Visibility switches or access controls for usage and history - A request history table or log with rows of past activity Because these settings are organization-wide, even small changes can affect multiple teams. If you need help understanding how this admin area fits into the broader workspace, see [Using the Admin Workspace](doc:using-the-admin-workspace). ## Preparing Your Organization for AI Configuration Before you begin setup, make sure you can actually edit organization settings in Atloria. If you can open the admin workspace but cannot change fields or save updates in the AI settings area, you may only have view access. You need organization administration access to configure providers, adjust prompt behavior, and control who can see usage and request history. It also helps to gather all provider details before opening the form. The provider setup area may ask for several values, and entering them in one session reduces the chance of saving incomplete settings. Prepare the exact details your team plans to use, including: | Item to prepare | Why it matters | |---|---| | Provider name | Needed to choose the correct option in the provider selector | | API key or credential | Required to connect Atloria to the selected AI service | | Default model | Determines which model Atloria uses for requests | | Endpoint value | Needed if the provider form includes a custom connection address | | Region value | Needed if the provider setup includes location-specific routing | | Organization identifier | Needed if the provider requires organization-level account mapping | You should also decide in advance who can view AI usage and request history. These screens may contain sensitive information about how Atloria is being used, and request history may include prompt and response details depending on what appears in your organization’s settings pages. Many teams give full access to administrators, monitoring access to support leads, and narrower review access to documentation managers. Finally, review any internal rules your organization has for AI prompts, generated content, and request logging. Because these settings affect all projects in Atloria, it is better to align on prompt handling and visibility before you click **Save**. For related admin access guidance, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Setting Up Your AI Provider 1. Open the **AI settings** page in your organization’s admin area and go to the **Providers** section. 2. Find the provider selector and choose the AI provider your organization wants Atloria to use. If more than one provider is available, make sure you select the one your team approved for organization-wide use. 3. Complete every required field shown in the setup form. Depending on what Atloria displays for your provider, this may include: - **API key** - **Model** - **Endpoint** - **Region** - **Organization identifier** 4. Enter each value exactly as provided by your organization or provider account owner. Pay close attention to copied credentials. A single incorrect character can prevent Atloria from connecting successfully. 5. Click **Save** and wait for the page to finish updating. After submission, look for any confirmation message, validation warning, or status indicator on the provider section. If Atloria shows a connected, active, or valid status, your provider details were accepted. If it shows an error, return to the fields and correct the highlighted values before saving again. [SCREENSHOT: Providers section with provider selector and connection fields] You can return to this same section later to update an existing setup. Common reasons to edit the provider configuration include: - Replacing an expired or rotated API key - Changing the default model used by Atloria - Updating endpoint or region values - Switching the organization to a different provider When you update an existing provider, save the changes and check the status again right away. That helps you catch connection problems before users start seeing failed AI actions elsewhere in Atloria. If your organization uses AI heavily across documentation workflows, it is worth coordinating provider changes during a low-activity period so teams are not interrupted. ## Controlling Prompt Behavior for Organization-Wide AI Responses 1. From the **AI settings** page, open the **Prompt Behavior** section. 2. Review the options Atloria shows for how prompts are structured or sent. Depending on your organization’s setup, this area may include default instructions, behavior switches, or other controls that shape how Atloria asks for AI responses. 3. Read each option carefully before changing it. Prompt behavior settings affect how consistently Atloria responds across projects, documentation work, and support-related tasks. A change made here can influence AI-generated drafts, suggested wording, and other responses seen by multiple teams. 4. Adjust the settings based on the kind of output your organization needs: - For more consistent, controlled responses, use stricter instructions and any available behavior limits. - For broader drafting help or more flexible writing support, allow more open-ended behavior where the page provides that option. 5. Click **Save** and note any confirmation message shown on the page. [SCREENSHOT: Prompt Behavior section with default instructions and behavior options] This section is especially important for documentation teams. If your writers want Atloria to produce content in a more uniform style across projects, organization-level prompt behavior is the place to standardize that. It also matters for support workflows. A support team may prefer tighter, more predictable responses so answers stay aligned with approved documentation and internal guidance. A useful way to think about these settings is by balancing consistency and flexibility: - **Stricter settings** are better when your team wants repeatable wording, controlled tone, or narrower response patterns. - **Broader settings** are better when your team wants help brainstorming, drafting, or exploring different wording options. Because this area affects everyone using AI features in Atloria, review prompt changes with the people who rely on AI most often, especially documentation managers and support leads. If you want to compare this with project-level content workflows, see [Configuring AI Settings for Your Organization](doc:configuring-ai-settings-for-your-organization) and [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages). ## Managing Who Can See AI Usage and Request History 1. Open the **AI settings** page and go to the **Usage Visibility** area. 2. Review the available visibility controls. These settings determine whether organization members can open AI usage pages and see consumption details. 3. Set access based on role. A practical pattern is: - **Administrators**: full access to usage and request history - **Support Team Leads**: access to monitor usage and inspect request history - **Documentation Managers**: limited review access where appropriate 4. Next, open the **Request History** visibility controls and decide who should be allowed to inspect past AI requests. If Atloria displays prompts or responses in the history view, be careful not to give broad access unless your organization is comfortable with that level of visibility. 5. Save your changes, then reopen the settings page to confirm the selected visibility options remain in place. The **Usage** area and the **Request History** area serve different purposes. In Atloria, usage usually helps you understand overall activity, while request history helps you inspect individual events. Depending on what your organization’s pages display, the usage area may show: - Request counts - Activity totals - Provider-related usage details - Time-based summaries The request history area may show: - Timestamps - Provider references - Request outcomes - Prompt text - Response text - Status entries [SCREENSHOT: Usage visibility controls and request history access settings] Use the narrowest visibility that still supports your team’s work. Administrators usually need the broadest access because they manage organization-wide settings. Support leads often need monitoring access to investigate issues. Documentation managers may only need enough visibility to review generated output patterns rather than every request detail. For broader admin guidance, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls). ## Reviewing Request History and Usage Details 1. Open the **Request History** section or page in Atloria’s AI settings area. 2. Read the log one row at a time. Each row is typically used to represent one AI request. Focus first on the **timestamp** so you know when the request happened, then check the **provider** reference and the **outcome** or status shown for that entry. 3. If Atloria provides filters, sorting controls, or a date range selector, use them to narrow the list. This is especially helpful when you are reviewing a large number of requests or investigating a specific issue reported by a user. 4. Switch to the **Usage** area when you want a higher-level view. Usage details are useful for spotting increases in activity, confirming that teams are actually using AI after rollout, or noticing unexpected consumption patterns tied to a provider or time period. [SCREENSHOT: Request history table with timestamp, provider, and outcome columns] When you review request history, look for patterns rather than isolated entries. For example: - Several failed requests in the same time window may point to a provider setup problem. - A sudden increase in activity after a rollout may confirm adoption by support or documentation teams. - Repeated requests around the same topic may show where users need better source documentation. Support teams can use request history to match a reported issue with the time it occurred. If a user says an AI action failed or returned an unexpected result, filter the log by date and review entries around that time. Documentation managers can use the same history to review how generated content aligns with expected style or prompt behavior. Usage details are better for trend monitoring, while request history is better for investigating specific events. Used together, they give you both the big picture and the row-by-row detail needed to understand how AI features are being used in Atloria. For more on monitoring activity, see [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history). ## Verifying Your AI Configuration 1. Return to the **Providers** section and confirm the saved provider shows a healthy status, confirmation message, or other successful connection result. If Atloria offers a test action or if your team can run a first live AI action from another screen, use that to confirm the provider is active. 2. Check the **Prompt Behavior** section and verify that your latest settings are still saved. Then compare AI output before and after the change if you have a recent example available. This is the easiest way to confirm that organization-level prompt updates are affecting responses as expected. 3. Review **Usage Visibility** and **Request History** access by signing in with the intended role, or by asking someone with that role to open the same AI settings pages. Confirm that administrators can see what they need, support leads can monitor activity if intended, and documentation managers only see the level of detail you planned. 4. Open **Request History** and make sure new activity appears after a test or live request. If the history is empty, confirm that AI requests have actually been made since the provider was configured. Common issues to check: - **Invalid API credentials**: Reopen the provider form and re-enter the API key exactly. - **Missing provider fields**: Make sure every required field in the provider setup form is completed. - **Empty request history**: Confirm that at least one AI request has been sent after setup. - **Users cannot see usage data**: Recheck the visibility settings and confirm the affected role has the intended access. [SCREENSHOT: Saved provider status and request history after a successful test] Verification is worth doing immediately after setup and again after any provider change, model update, or visibility adjustment. That way, you can catch problems before they affect documentation teams, support workflows, or project users across Atloria. ## Overview AI settings in Atloria give your organization one place to control how AI features are connected, guided, and monitored. The most important areas on the page are **Providers**, **Prompt Behavior**, **Usage Visibility**, and **Request History**. Together, these settings determine which AI service Atloria uses, how requests are shaped, who can review activity, and how past requests are displayed for troubleshooting or oversight. A typical setup flow looks like this: - Open the organization-level **AI settings** page - Choose and save your provider in **Providers** - Review organization-wide instructions in **Prompt Behavior** - Decide who can see activity in **Usage Visibility** - Confirm request logging and review access in **Request History** - Run a test and verify the results These settings are best managed with clear ownership: - **Project Administrators** usually handle provider setup and updates - **Documentation Managers** usually review prompt behavior for consistency - **Support Team Leads** usually monitor usage and request history Because the settings apply across the organization, changes should be made carefully and verified right away. A provider update can affect whether AI actions work at all. A prompt behavior change can alter the tone or consistency of generated content. A visibility change can either help teams investigate issues or expose more detail than intended. If you are continuing your AI setup work, the next most useful guides are: - [Setting Up and Maintaining AI Providers](doc:setting-up-and-maintaining-ai-providers) - [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history) - [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) If you are reviewing AI use from a documentation workflow perspective, see [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) and [Using Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements). ## Checking What You Need Before Connecting a Service Before you click **Connect**, make sure you are starting from the right place in Atloria and using the right account in the external service. In most cases, you will begin from **Settings > Integrations**, where Atloria shows the services you can connect and any services that are already linked. Check these items first: - Make sure you can open **Settings > Integrations** and see connection actions such as **Connect**, **Manage**, **Edit**, or **Reconnect**. If you can view the page but do not see a way to start a connection, your access may be limited. - Identify the service you want from the **Available Integrations** list. This helps you avoid authorizing the wrong provider when several options are listed. - Confirm that you have an active account in the external service. Some services also require approval from an administrator in that service before you can authorize Atloria. - Gather the details you may need during the sign-in window, such as your email address, password, approval prompt, or the correct workspace or account to select after sign-in. - Decide where the connection should apply before you start. Some connections are meant for a broader settings area, while others are used only inside a specific project workflow. Starting in the wrong place can lead to a connection that does not appear where your team expects it. If you are unsure whether you should connect a service from a general settings area or from inside a project, review your project setup first in [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). [SCREENSHOT: Settings > Integrations page showing Available Integrations and Connected Integrations sections] ## Connecting a Supported External Service 1. In Atloria, open **Settings > Integrations**. 2. In the **Available Integrations** area, find the service you want to connect. Review the service name carefully, then click **Connect**. 3. Atloria opens the provider sign-in flow. Depending on the service, this may appear in a pop-up window or take you to a separate authorization page. 4. Sign in with the external account you want Atloria to use. If the provider asks you to choose an account, team, or workspace, select the one that matches the work you want available in Atloria. 5. Review the access request shown by the provider. If the details are correct, approve the connection so Atloria can use that service. 6. Wait for Atloria to return you to the integrations area. After the authorization finishes, the service should move from **Available Integrations** to **Connected Integrations**. 7. Check the initial status shown next to the service. Right after setup, Atloria may show: - **Connected** if the link is ready to use - **Pending** if Atloria is still finishing the first setup or sync - **Needs Attention** if Atloria needs you to review or complete something before the connection can be used If the provider window closes and nothing changes in Atloria, refresh the page and check **Connected Integrations** again before trying a second time. This helps you avoid creating confusion about whether the first connection already succeeded. [SCREENSHOT: Connect button in Available Integrations] [SCREENSHOT: Provider authorization window asking for sign-in and approval] [SCREENSHOT: Connected Integrations list with a newly added service] ## Reviewing Integration Status and Connection Details After a service is connected, use the **Connected Integrations** list as your main checkpoint. This is where Atloria shows whether a connection is healthy and ready for project use. For each connected service, look for these details: | What to check | What it tells you | |---|---| | **Status** | Whether the connection is active or needs action | | **Last synced** | When Atloria last updated information from that service | | **Connected account** or workspace name | Which external account, team, or workspace is linked | Open the service details using **Manage** or a similar action in the integration row. In the details view, review which parts of Atloria are using that connection. This is especially helpful when one service is tied to specific project work rather than every project in your workspace. Common status labels usually mean: - **Connected**: Atloria can use the service normally. - **Expired**: The previous approval is no longer valid and needs to be renewed. - **Error**: Atloria could not complete a recent action or sync with that service. - **Reconnect Required**: The service is no longer authorized and must be connected again before Atloria can continue using it. Also check the scope shown in the integration settings. Some connections apply broadly, while others are limited to selected projects. If a teammate says a connected service is missing inside their project, the first thing to verify is whether that integration is active for all projects or only for certain ones. [SCREENSHOT: Connected Integrations list showing status badges and last synced values] [SCREENSHOT: Integration details panel showing connected account and project scope] ## Updating Access, Reconnecting, or Removing an Integration Connections sometimes need maintenance after the first setup. A password change, a revoked approval, or a change in the external service’s workspace structure can all interrupt a working integration. When that happens, use the action shown in the integration row instead of starting over from **Connect**. If the service is already listed under **Connected Integrations**, look for options such as **Manage**, **Edit**, or **Reconnect**. These actions let you update the existing connection without creating a second copy of the same service. Use these actions when: - The status shows **Expired**, **Error**, or **Reconnect Required** - The linked external account has changed - The selected workspace or team in the provider has been renamed or replaced - Your organization reset access in the external service - You changed your sign-in details and Atloria can no longer use the old authorization When you click **Reconnect**, Atloria sends you through the provider approval flow again. Sign in with the correct external account and confirm access. After you return, check that the same integration entry now shows an updated healthy status. If the connection is no longer needed, open its settings page and use **Disconnect** or **Remove**. Once removed, Atloria stops using that service in related workflows right away. Any project area that depends on that connection may stop showing linked content, sync results, or provider actions until the service is connected again. If you need to change how the service is used rather than remove it completely, use **Edit** or **Manage** first so you can keep the existing connection history and settings where possible. ## Understanding Where Integrations Affect Project Workflows A connected service only becomes useful when you can see where it affects your day-to-day work. In Atloria, those effects usually appear inside project areas rather than only on the **Integrations** page. After connecting a service, look for signs of it in the project screens your team uses. Depending on the connection, Atloria may show: - linked items from the external service - synced content or imported records - provider-specific actions in a project workflow - sync indicators or status messages that show whether outside information is current If a connection becomes unavailable, the experience in those project areas changes. You may still be able to open the project, but actions that depend on the external service can stop updating, linked content may not appear, or Atloria may show a warning that attention is needed. This is why it is important to check both the integration status and the project screen where the connection is supposed to be used. There is also an important difference between connecting a service in **Settings > Integrations** and using that service inside a specific project workflow. The settings connection gives Atloria permission to access the external service. The project workflow is where that permission is actually put to use. A service can be connected in settings but still not appear in a project if it was linked in the wrong scope or not enabled for that project. For project-specific setup decisions, continue with [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls) or [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home), depending on where your team uses external connections. ## Verifying the Connection Is Working 1. Go back to **Settings > Integrations** and find the service in **Connected Integrations**. 2. Confirm the status shows **Connected**. If Atloria also shows a **Last synced** value, wait for it to update after the initial authorization finishes. 3. Open the project area that should use the service. Look for the expected result, such as linked content, imported data, sync activity, or provider-specific actions. 4. If the service appears connected in settings but nothing shows up in the project, check whether the connection was made in the correct workspace or project scope. A healthy connection in the wrong place will not help the project that needs it. 5. If the status shows **Error** or **Reconnect Required**, click **Reconnect** and complete the provider sign-in flow again. Pay close attention to which external account, workspace, or team you select during that step. 6. Return to the same project area and check again for the expected linked content or actions. A successful verification usually means two things are true at the same time: the integration row shows a healthy status, and the project screen that depends on that service shows usable results. If only one of those is true, keep checking the connection scope and the selected external account before removing and reconnecting the service. [SCREENSHOT: Connected integration showing Connected status and updated Last synced] [SCREENSHOT: Project screen showing linked external content or provider action] ## Overview Atloria’s **Integrations** area is where you connect supported external services and keep those connections working over time. The main screens you will use are **Settings > Integrations**, the **Available Integrations** list, the **Connected Integrations** list, and each service’s **Manage**, **Edit**, **Reconnect**, **Disconnect**, or **Remove** actions. The basic workflow is straightforward: - choose a service from **Available Integrations** - click **Connect** - complete the provider sign-in and approval screen - return to Atloria and confirm the service appears under **Connected Integrations** - verify that the related project workflow shows the expected linked content or actions Once connected, the most important things to monitor are the **Status** badge, the **Last synced** value, and the connected account or workspace name. These details help you quickly tell whether Atloria is still using the right external service and whether the connection is healthy enough for project work. You will also use the integrations area for ongoing maintenance. If a provider approval expires or the external account changes, Atloria may show **Expired**, **Error**, or **Reconnect Required**. In those cases, use **Reconnect** or **Manage** on the existing row instead of starting from scratch. This document focuses on the connection and maintenance side of integrations. If you need help deciding which kind of external connection best fits your project workflow, continue next with [Choosing and Maintaining External Connections for Project Workflows](doc:choosing-and-maintaining-external-connections-for-project-workflows). ## Prerequisites Before working with **Settings > Integrations** in Atloria, make sure these basics are in place: - You can sign in to Atloria and open the settings area where **Integrations** is available. - You can see the service you want in the **Available Integrations** list. - You have a valid account in the external service you plan to connect. - You know which external account, team, or workspace should be linked during the provider sign-in step. - You are allowed to approve Atloria’s access request in the external service, or you have the right person available to approve it. - You know whether the connection should support a broad settings-level use or a specific project workflow. - You have access to the project area where you plan to verify the connection after setup. It also helps to check related Atloria guidance before you begin: - For account access questions, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). - For project setup choices, see [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). - For broader admin access and settings responsibilities, see [Using the Admin Workspace](doc:using-the-admin-workspace). If you are ready to move from basic connection steps into deciding which external links should stay active for ongoing project work, the next document is [Choosing and Maintaining External Connections for Project Workflows](doc:choosing-and-maintaining-external-connections-for-project-workflows). ## 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. [SCREENSHOT: Versions list showing multiple documentation versions with their current visibility state] ## 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](doc:validating-version-access-before-sharing-or-export). [SCREENSHOT: Version settings panel with access mode changed to Public and Save button visible] ## 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](doc:managing-version-visibility-and-reader-access). [SCREENSHOT: Versions list with one version marked public and another marked restricted or internal] ## 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. [SCREENSHOT: Version configuration page showing visibility and export options for a single release] ## 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. [SCREENSHOT: Public documentation page with version selector open and export action visible for one version] ## 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](doc:controlling-version-sharing-and-export-readiness) together with [Validating Version Access Before Sharing or Export](doc: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](doc:reviewing-and-approving-documentation-versions) and [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness). The next step in this section is [Managing Version Visibility and Reader Access](doc: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](doc:generating-new-documentation-versions) - [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) - [Reviewing and Approving Documentation Versions](doc: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](doc:managing-version-visibility-and-reader-access) to refine who can read each version after it becomes available. ## Opening the document editor and understanding the page workspace In Atloria, you usually begin from your project’s documentation workspace, where pages are listed by title. To open a page for editing, select the page title or use the **Edit** action if it appears beside the page. When you are creating a brand-new page, Atloria opens the same editing workspace used for existing pages, so you do not need to learn two different screens. Once the editor opens, focus on the main areas of the page: - A **Title** field at the top for the page name - The main **body editor** where you write and format content - A **formatting toolbar** for headings, lists, and links - **Save** controls near the top of the page - A **status** or publishing area that shows whether the page is still a draft or already published [SCREENSHOT: Documentation page editor showing the title field, body editor, toolbar, and save controls] If you opened an existing page, the editor loads the current title and page content so you can revise it directly. If you started a new page, those areas begin empty and are ready for you to fill in. In both cases, the editing flow is the same: update the title, add or revise content, review any page details, and then save. Atloria may also show page details in a side panel or page settings area. This is where you review information such as: | Field | What it controls | |---|---| | **Title** | The page name readers see | | **Slug** | The page’s URL ending or page identifier | | **Status** | Whether the page is draft or published | If a settings panel is available, use it to confirm the page name and URL before you save. This is especially helpful when you are creating a page that must fit into an existing documentation structure. ## Creating a new documentation page To add a page in Atloria, go to the documentation area for your project and click **New Document** or **Create Page**, depending on the label shown in your workspace. Atloria opens a blank editor so you can start writing immediately. 1. Enter the page title in the **Title** field at the top. 2. Check the page identifier or **Slug** if Atloria shows it. 3. Click into the body editor and add your first content. 4. Review any page settings before saving. The page title is important because Atloria may use it to create the page slug automatically. For example, if you enter a clear title, the slug usually follows that wording in a shorter URL-friendly format. If the slug is editable, review it before saving so it matches the page topic and fits your team’s naming style. In the body editor, add the starting content with the toolbar. Common actions include: - Apply **Heading** styles for section titles - Type normal paragraph text for explanations - Use **Bulleted List** or **Numbered List** for steps - Add **Link** formatting for related pages or references [SCREENSHOT: New page editor with a title entered and the formatting toolbar open] If Atloria shows additional page details, complete them before saving. Depending on your workspace, this can include where the page sits in the documentation tree, whether it belongs under a parent page, or whether it should be visible right away. If those controls are present, set them before your first save so the page appears in the correct place. A good first draft includes a clear title, at least one heading, a short opening paragraph, and any key links readers need. That gives you a usable page structure from the start and makes later review easier. ## Editing page content and structure When you return to an existing page in Atloria, the fastest way to update it is to click directly into the body editor and change the text in place. You can revise paragraphs, replace outdated wording, or expand short sections without leaving the page. Keep your heading levels consistent so the page stays easy to scan. For example, use the same heading style for sections at the same level instead of mixing large and small headings randomly. 1. Open the page from the documentation list. 2. Click into the section you want to change. 3. Update the text or formatting. 4. Save your changes and review the result. The formatting toolbar helps you keep the page structured. Use it to create: - **Bulleted lists** for feature summaries - **Numbered lists** for step-by-step instructions - **Links** for related pages and references - **Paragraph text** for explanations between sections If Atloria supports richer content in the editor, you may also be able to insert media or attached items from the same editing area. When those options are available, add them only where they improve the page, such as showing a workflow or supporting a setup step. To reorganize content, move sections carefully. If your editor includes block controls or drag handles, use them to reposition content. If not, cut and paste sections into the correct order. After moving content, scan the headings again to make sure the page still reads in a logical sequence. You may also be able to update page details separately from the main body. In the page settings area, review fields such as **Title**, **Slug**, and **Status**. This is useful when the page needs a better name or a cleaner URL but the main content does not need much rewriting. [SCREENSHOT: Existing page in edit mode with updated headings, lists, and page settings visible] ## Saving changes and managing page states After editing a page in Atloria, use the save controls at the top of the editor to decide whether you are storing work in progress or making it available to readers. The exact buttons may vary, but the workflow centers on **Save**, **Save Draft**, and **Publish** when those actions are available in your workspace. 1. Make your content or metadata changes. 2. Click **Save** or **Save Draft** to keep your work. 3. Use **Publish** when the page is ready for readers. 4. Confirm the page status after the action completes. A draft save keeps your latest edits without necessarily making them visible in the published documentation. This is helpful when you are still writing, waiting for review, or collecting screenshots and links. A published save updates the live version readers can access. If Atloria shows a page **Status**, check it after saving so you know whether the page is still in draft form or already live. After a successful save, Atloria may update the page’s modified time or last-edited information. Use that timestamp to confirm that your latest work was stored. If you are collaborating with other writers, this is also a quick way to see whether the page has changed recently. Watch for signs that your work is not yet saved. Atloria may show unsaved changes through a changed button state, a warning when you try to leave the page, or a publish action that stays unavailable until required fields are complete. If you try to navigate away while edits are still pending, stop and save first. If your workspace includes additional page states such as hidden or archived, treat them as visibility controls rather than editing tools. Draft means still in progress, published means visible to readers, and hidden or archived means the page is not meant to appear in normal navigation. ## Working efficiently while authoring and reviewing pages Good writing in Atloria is not only about the words on the page. It also depends on how quickly you can move between editing, checking structure, and reviewing the final result. The easiest way to work faster is to combine the formatting toolbar with keyboard habits instead of stopping after every sentence to hunt for controls. Use the toolbar for the actions that shape the page most often: - Apply heading styles as soon as you create a new section - Turn loose notes into bulleted or numbered lists - Add links while the related page name is still fresh - Save regularly while you work through larger edits [SCREENSHOT: Editor toolbar with heading, list, and link actions highlighted] A reliable editing pattern helps, especially when several people work on the same documentation set. In Atloria, a simple order works well: 1. Review the page **Title**, **Slug**, and **Status** 2. Update the main body content 3. Save the page 4. Open the rendered or preview view to check spacing, headings, and links Previewing matters because content can look acceptable in the editor but feel uneven once rendered. Check whether headings appear in the right order, lists are spaced correctly, and links open the expected destination. This is one of the easiest ways to catch navigation problems before publishing. If Atloria shows page history, revision details, or a last-edited indicator, use those details before making major changes. They help you see whether someone else updated the page recently and reduce the chance of overlapping edits. When multiple writers share responsibility for a page, review the latest saved state first, then make your changes in one focused pass instead of many small unsaved edits. For broader team review and page organization after writing, continue with [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content). ## Fixing common problems when creating or editing pages Most page editing problems in Atloria come from missing page details, formatting that was applied inconsistently, or confusion between draft and published changes. When something does not look right, start with the visible fields and status indicators in the editor before assuming the content is lost. If a page will not save, check the top of the editor and any page settings panel for missing required information. Common places to review include: - **Title** - **Slug** - Parent page or location, if Atloria asks for it - Any field marked with a validation message Atloria may show an inline warning near the field that needs attention. Correct that field first, then try **Save** again. If formatting looks wrong after publishing, compare the editor content with the rendered page. A section that was meant to be a heading may still be plain paragraph text, or a list may have been typed manually instead of using the list controls. Reapply the correct formatting from the toolbar, save again, and recheck the page. When changes seem to be missing, confirm whether you clicked **Save Draft** instead of **Publish**. A draft save stores your work but may not update the reader-facing page. Check the page **Status** and any modified timestamp to see what was actually saved. If Atloria includes revision history, review the latest saved version there as well. If another writer’s updates are not visible, refresh the page and look again at the last-edited details or revision information. You may be viewing an older saved state, or the other person’s work may still be in draft form rather than published. [SCREENSHOT: Validation message near a required field and page status shown in the editor header] When a page still does not behave as expected, reopen it from the documentation list and verify the title, slug, status, and latest saved content before making further edits. ## Overview Use Atloria’s document editor when you need to create a new documentation page or revise an existing one. The same workspace supports both tasks, so once you know where the **Title** field, body editor, toolbar, and save controls are located, you can move between drafting and updating pages without changing screens. This workflow is centered on a few core actions: - Open a page from the documentation list using its title or **Edit** - Create a new page with **New Document** or **Create Page** - Add and format content with headings, paragraphs, lists, and links - Review page details such as **Title**, **Slug**, and **Status** - Save as draft or publish when the page is ready Atloria separates writing from visibility through page state. That means you can keep unfinished work as a draft, continue refining it, and publish only when the content is ready for readers. This is especially useful when your team is still reviewing wording, checking links, or confirming where the page belongs in the documentation structure. The most effective way to work is to treat each page as both content and navigation. The body editor controls what readers see on the page itself, while fields like **Title** and **Slug** affect how the page is identified and found. Small changes in those fields can make a page much easier to browse later. As you write, save regularly and check the rendered result before publishing. That extra review step helps you catch heading problems, broken list structure, and link issues while the page is still easy to fix. Once you are comfortable creating and editing individual pages, the next skill is arranging them clearly and reviewing how they fit together across the documentation set. ## Prerequisites Before you start creating or editing pages in Atloria, make sure you can already reach the right workspace and open your project’s documentation area. You do not need advanced setup knowledge, but you do need access to the project where the page will live. You should have: - An Atloria account that can sign in successfully - Access to the relevant project workspace - Permission to open documentation pages and use **Edit**, **New Document**, or **Create Page** - A basic understanding of your team’s page naming and structure If you are still getting into Atloria or need help with account access, start with [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). It also helps to know where your project pages are managed. If you need help finding the project workspace first, use [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). Before opening the editor, prepare the content you plan to add: - The page title you want readers to see - The main sections you expect to include - Any links you want to add to related documentation - Any decisions about whether the page should remain a draft or be published If your team already has a documentation structure in place, confirm where the new page belongs before you create it. That will make the title, slug, and placement decisions easier once you are in the editor. The next document in this sequence is [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content), which covers how to arrange pages and review them as part of the larger documentation set. ## Preparing Atloria Documentation for Agent Training Before you create a support agent in Atloria, confirm exactly which documentation it should answer from. The most reliable setup starts with a clearly defined source, such as a specific docs space, a selected category, or a set of published articles that already cover your support topics. If your team manages several projects or documentation areas, narrow the source before you begin so the agent does not pull answers from unrelated content. Focus on published content only. Review the articles you plan to use and make sure they are current, complete, and written for the audience the agent will support. If an article is still being edited, missing steps, or based on an older workflow, update it before adding it to the agent’s knowledge source. This matters most for setup instructions, troubleshooting guides, and account-access articles, where even a small change can lead to incorrect answers. It also helps to define the first support scenarios the agent should cover. Common starting points include: - product how-to questions already documented in Atloria - account setup guidance - troubleshooting flows with clear step-by-step articles - common “where do I find…” questions tied to published documentation Keep ownership clear from the start so the agent stays accurate over time: - **Support Team Lead**: defines how the agent should respond, when it should hand off to a person, and which support situations it should handle - **Documentation Manager**: checks article quality, publishing status, and content coverage - **Project Administrator**: manages workspace access and makes sure the right people can update the agent and its sources [SCREENSHOT: published documentation list showing approved articles or categories selected for agent use] ## Creating a Support Agent 1. In Atloria, open the area where AI support agents are managed, then start the **Create** flow for a new agent. If your team already has several agents, look for the option to add a new one rather than editing an existing entry. 2. Enter a clear **Name** and **Description**. Use wording that helps your team tell agents apart at a glance. For example, your name might reflect the audience or product area, while the description can explain whether the agent is meant for internal support staff or customer-facing help. This becomes especially useful when multiple agents cover different documentation sets. 3. Choose the setup option that uses Atloria documentation as the agent’s main answer source. This is the best choice when you want the agent to respond from your existing articles instead of relying on general-purpose answers. If Atloria asks you to select a documentation collection, space, category, or article group, choose the source you reviewed earlier. 4. Select the documentation set the agent should use. Be deliberate here. If you choose too broad a source, the agent may return answers from unrelated articles. If you choose too narrow a source, it may miss valid answers that exist elsewhere in your published docs. 5. Save the new agent. After saving, review the agent’s status on its details screen or list entry. You should see that the agent has been created and is available for further setup. At this stage, the agent exists, but you should still review its behavior and test its answers before using it in live support work. [SCREENSHOT: create support agent screen with Name, Description, documentation source selection, and Save button] ## Configuring How the Agent Responds 1. Open the new agent’s settings and find the instructions or behavior area. This is where you define how the agent should answer. Write guidance that matches your support style, such as whether responses should be concise, step-based, formal, or friendly. If your team wants the agent to stay tightly aligned to Atloria documentation, make that explicit in the instructions. 2. Decide how strict the agent should be about source material. For support teams, a documentation-first approach usually works best. Configure the agent so it answers from Atloria documentation, avoids unsupported guesses, and declines questions when no matching article exists. If there is a setting for fallback behavior, use it to direct people to human support when the documentation does not cover the issue. 3. Define the response format for common support cases. For example, you may want the agent to: - summarize the steps from a help article - present troubleshooting steps in order - point users to the source article for full details - keep answers focused on documented actions only 4. Review any audience or channel-related settings that affect how the agent is used. An internal support agent may use a more operational tone and assume staff know Atloria navigation. A customer-facing agent should usually be clearer, more guided, and less dependent on internal shorthand. Make sure the selected behavior matches the people who will read the answers. 5. Save your changes and read through the settings one more time. Small wording changes in the instructions can make a noticeable difference in how the agent handles unsupported questions, article summaries, and troubleshooting flows. [SCREENSHOT: agent behavior settings showing instructions, fallback behavior, and response rules] ## Managing Agent Settings and Documentation Sources After the agent is created, return to its settings whenever your support process changes. The most common updates are to the **Name**, **Description**, and behavior instructions. For example, if an agent that started as an internal tool is later used in a customer self-service experience, update its description and response guidance so the purpose is obvious to everyone managing it. Documentation sources also need regular attention. As your team publishes new articles, reorganizes categories, or retires older guidance, review the source list connected to the agent. Add new documentation when a product area expands, remove articles that no longer reflect current workflows, and replace outdated source groups with newer published content. This keeps the agent aligned with what users should actually see in Atloria today. When major article updates are published, refresh the agent’s knowledge source so recent edits are reflected in future answers. This is especially important after: - rewriting setup or onboarding instructions - changing troubleshooting steps - publishing new support articles for recurring issues - removing outdated guidance from a docs space or category Also review who can manage the agent. Access settings should match your team’s responsibilities. In most cases, only the people responsible for support operations, documentation quality, or project administration should be able to change behavior settings or swap documentation sources. Limiting editing access helps prevent accidental changes that could affect live support answers. If your team manages several agents, keep each one clearly scoped. A well-maintained agent usually has a focused purpose, a reviewed source list, and a clear owner who checks it after documentation changes. [SCREENSHOT: support agent settings screen with editable details and documentation source management] ## Using the Agent in Support Workflows Support teams get the most value from an Atloria support agent when they use it for repeatable, documented questions. Instead of rewriting the same answer for every ticket or chat, staff can use the agent to pull from existing Atloria documentation and return a consistent response. This works well for setup steps, navigation questions, standard troubleshooting, and other issues already covered in published articles. Use the agent when the answer should come directly from documentation. Good examples include: - showing a user how to complete a known setup task - walking through a documented troubleshooting sequence - pointing someone to the correct article for a common question - summarizing published instructions in a shorter reply Do not rely on the agent for account-specific decisions, exceptions, or undocumented issues. If a question depends on customer data, special permissions, billing details, or a problem that is not covered in Atloria documentation, route it to a human support person. The agent is strongest when it stays within documented guidance and weakest when it is expected to improvise. Support conversations can also improve your documentation. When the same question appears repeatedly, or when the agent struggles to answer clearly, review the related article. Documentation Managers can use these patterns to spot missing articles, unclear steps, or content gaps. After the article is improved and published, refresh the agent’s source so future answers reflect the update. A simple maintenance loop works well: - support team notices repeated or weak answers - documentation team updates the article - the source is refreshed in the agent settings - support team tests the question again That cycle keeps the agent useful without turning it into a separate knowledge base. ## Testing the Agent Before Rolling It Out 1. Start with real support questions. Use examples from recent tickets, chat transcripts, or common help requests, then ask the agent those same questions. Compare the answers to the published Atloria articles you selected earlier. The response should match the documented steps, stay within scope, and reflect the correct article content rather than adding unsupported guidance. 2. Test questions with different wording. Users rarely ask the same question the same way twice, so try short questions, full-sentence questions, and troubleshooting-style questions. This helps you confirm whether the selected documentation source is broad enough and whether the behavior instructions produce clear, usable replies. 3. Check what happens when no answer exists in the documentation. Ask about an undocumented issue and review the fallback response. The agent should avoid guessing and should instead decline the question or direct the user to human support, depending on how you configured it. 4. Confirm that recent article edits appear after you refresh the source. If you updated a published article, run a before-and-after test using the same question. If the answer still reflects the older content, review whether the correct source was selected and whether the refresh completed. 5. Fix common setup problems before rollout: - wrong docs space, category, or article set selected - outdated published articles still included in the source - behavior instructions too vague or too broad - fallback guidance missing for unsupported questions [SCREENSHOT: test conversation view showing a support question, the agent answer, and the related published article] ## Overview Atloria support agents help teams answer questions from existing documentation instead of writing every response manually. In practice, this means you create an agent, connect it to published documentation, define how it should respond, and test it before using it in support work. The agent is most effective when its knowledge source is limited to current, approved content and its behavior is clearly scoped around documented answers. This guide focuses on the core setup flow for a documentation-backed support agent in Atloria. You prepare the source content, create the agent, configure its response style, manage the connected documentation, and test it with realistic support questions. It also covers how support teams and documentation teams work together so the agent improves over time rather than drifting away from current guidance. Use this guide when you need to: - create a new support agent for internal or customer-facing use - connect an agent to Atloria documentation - control how the agent handles unsupported questions - update the agent after documentation changes - validate the agent before broader rollout A few related areas in Atloria are referenced throughout this process. If you need help with account access before starting, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If you need to review project or workspace access before assigning ownership, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). For broader AI setup decisions, see [Configuring AI Settings for Your Organization](doc:configuring-ai-settings-for-your-organization). The next document in this section is [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup), which goes deeper into organizing sources and maintaining the content behind your agents. ## Prerequisites Before you create a support agent in Atloria, make sure the people involved can access the right areas and that the documentation source is ready to use. You do not need every possible support article in place, but you should have a stable set of published content for the first questions the agent is expected to answer. Check these items before you begin: - You can sign in to Atloria and reach the authenticated workspace. - You have access to the area where support agents are created and managed. - The documentation you want the agent to use is already published. - The selected docs space, category, or article set contains current information. - Someone on the team is responsible for documentation quality. - Someone on the team is responsible for agent behavior and escalation decisions. - Someone with workspace or project administration access can manage permissions if needed. It also helps to prepare a short test set before setup begins. Gather a few real support questions that are already answered in your documentation, along with one or two questions that should not be answered by the agent. These will help you confirm both the normal response behavior and the fallback behavior after setup. If you are still preparing the underlying project documentation, complete that work first so the agent has reliable source material. Depending on your workflow, these guides may help: - [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) - [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) - [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content) If your team is ready to move from basic creation into source organization and workspace-level setup, continue with [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup). ## Preparing to Create a New Project Before you click **New Project**, take a minute to confirm the basic decisions that Atloria will ask for during setup. This makes the onboarding wizard much faster and helps you avoid renaming or reorganizing the project right away. Start from the area where you manage projects, such as your projects list or organization workspace. Make sure you can see the option to create a project. If you do not see a **New Project** button, you may need a workspace or organization role that allows project creation. If account access is still being set up, see [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). Before opening the form, gather the details Atloria uses to create the project: | What to prepare | Why it matters | |---|---| | **Project Name** | This is the name your team sees in project lists and project navigation. | | **Project URL / Slug** | This becomes the project’s address inside Atloria and is easiest to choose correctly at the start. | | **Primary documentation language** | This helps you keep your page structure and writing workflow consistent from the first page onward. | | **Project owner** | Decide who will be responsible for setup decisions, structure changes, and team access. | | **Workspace or organization** | This determines where the project lives and which team members are likely to have access. | You should also decide how the project will begin: - **Blank setup** if you want to build the documentation structure yourself - **Starter template** if you want Atloria to create an initial structure for you - **Imported structure or content path** if you already have documentation to bring in [SCREENSHOT: Project list with the New Project button highlighted] If you are unsure which starting option fits your team, continue with project creation first, then compare setup approaches in [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). ## Creating the Project Record Once you are ready, open the projects area in Atloria and click **New Project**. The project creation form is where you define the basic identity of the project before the onboarding wizard starts. 1. Enter the **Project Name** exactly as your team should see it in project lists, dashboards, and internal navigation. 2. Fill in the **Project URL** or **Slug** field if Atloria asks for it during creation. Choose a short, clear value that matches the project name and will still make sense later. 3. Select the **workspace** or **organization** that should own the project. This choice matters because it affects who can find the project, who can manage it, and which team context it belongs to. 4. Choose the initial **visibility** or access mode shown on the form. If Atloria offers a private option, use it when you want setup work to stay limited to a smaller team. If broader team access is available, use that when the project should be visible to a larger internal group from the start. 5. Review the form, then click **Create Project** or **Save**. After saving, Atloria does not take you to the normal project dashboard right away. Instead, the new project opens into the onboarding flow so you can define the initial documentation setup before contributors start working. This first-load state is important because it is where Atloria creates the project’s starting structure. If you leave the project before finishing onboarding, the project may exist but still need setup choices before it is ready for writing and collaboration. [SCREENSHOT: New Project form showing Project Name, URL/Slug, workspace selection, and visibility options] If you need help finding projects after creation, see [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards). ## Using the Onboarding Wizard to Define Your Documentation Setup After the project record is created, Atloria opens the onboarding wizard. This guided flow helps you choose how the project should start and what kind of documentation structure Atloria should create for you. 1. On the first onboarding screen, choose the project’s starting point. Atloria may offer options such as a **blank structure**, a **starter template**, or an **imported content** path. Select the option that best matches how much structure you already have. 2. Move to the next screen and choose the primary documentation use case or documentation type if Atloria asks for it. This choice helps Atloria shape the initial section layout and starter pages. 3. Continue through each screen, making the required selections. If the **Continue** or **Next** button is unavailable, look for a required option that has not been selected yet. 4. When you reach the summary or review step, read each setup choice carefully before applying it. 5. Click the final action to apply the onboarding choices and build the project’s initial structure. The wizard is designed to help you make decisions in order. A blank setup gives you the most control, but it also means you will need to create the structure yourself. A starter template is useful when you want Atloria to generate a ready-to-edit navigation tree. An imported path is best when you already have content or a structure you plan to bring into the project. Pay close attention to the review screen. This is usually the clearest place to confirm whether you selected the right starting mode, the right documentation type, and the right overall direction for the project. [SCREENSHOT: Onboarding wizard with setup options and Next button] [SCREENSHOT: Onboarding summary screen before applying setup choices] The next document, [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup), goes deeper into how to choose between these setup paths. ## Making the Initial Decisions That Shape Structure The choices you make during onboarding directly affect the first version of your project’s navigation, starter pages, and overall writing flow. Even if you plan to refine the structure later, it helps to understand what Atloria creates for you at this stage. If you choose a **starter template**, Atloria creates an initial navigation tree for the project. That usually means you begin with top-level sections and starter pages instead of an empty workspace. If you choose a **blank structure**, the project starts with much less built in, which is useful when your team already knows exactly how it wants to organize content. If you choose an **imported** path, the first structure is shaped by the content you bring in. As you review the onboarding choices, pay attention to the names of the first sections, categories, or spaces Atloria creates. These names become the starting points for your documentation hierarchy, so choose labels your team will understand immediately. Clear top-level names make it easier for writers, reviewers, and readers to know where content belongs. Your selections can also influence future organization: - **Primary language** affects how consistently your team writes and labels pages - **Documentation type** influences the default structure Atloria creates - **Audience-related choices**, if shown during setup, can shape how you separate content for different readers later Keep the default structure when: - the template already matches your documentation plan - you want to start writing quickly - your team needs a shared starting point before refining details Adjust the structure before inviting contributors when: - top-level section names are unclear - the template creates sections your team will not use - you already know the project needs a different hierarchy [SCREENSHOT: Newly created project showing the first navigation tree and starter pages] If you want to revisit structure planning in more detail, continue later with [Planning Project Structure Before Document Authoring](doc:planning-project-structure-before-document-authoring). ## Configuring Access and Team Participation As soon as onboarding finishes, review who can enter the project and what each person can do. This is easiest to handle before a larger group starts editing pages or reviewing content. 1. Open the project and go to the area for **Settings**, **Team**, **Members**, or project access controls, depending on what is shown in your workspace. 2. Check who currently has access to the project. Confirm that the project owner and any initial administrators are correct. 3. Use the member invite controls to add the first contributors. This may include documentation managers, reviewers, and subject matter experts. 4. Assign each person the permission level that matches their job in the project. Give editing access to people who will create or update content, and use higher-level access only for people who need to manage settings, structure, or publishing decisions. 5. Ask at least one invited user to open the project and confirm they land in the correct project area. The workspace or organization selected during project creation affects access from the beginning. If the project was created in the wrong place, the wrong people may see it, or the right people may not be able to open it at all. That is why access review should happen immediately after onboarding, not later. When checking access, make sure invited users can do more than just open the project. They should also be able to see the documentation structure created during onboarding. If someone is expected to edit content, confirm they can reach the navigation tree and open the starter pages that Atloria created. [SCREENSHOT: Project team or member access screen with invite controls] [SCREENSHOT: Role or permission selection during member invitation] For broader admin tasks related to users and permissions, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Verifying Your Setup Before your team starts writing, take a few minutes to confirm that the new project looks and behaves the way you expected. This final check helps you catch setup mistakes while they are still easy to fix. 1. Return to the project home area and confirm the project opens to the expected dashboard, home page, or navigation view. 2. Review the navigation tree created during onboarding. Make sure the default sections, starter pages, or imported content appear in the correct order and location. 3. Open a few pages to confirm the structure matches the setup choices you made in the wizard. 4. Test access with a user who does not have full administrative rights. Confirm they can see only the project areas appropriate for their role and can edit content only if they were given editing access. 5. If something is wrong, return to the project’s settings and related setup areas to correct it. Common issues to check: - **Incorrect project slug**: update it in the project settings if Atloria allows editing - **Wrong template or starting structure**: review the project structure and adjust sections before content creation begins - **Missing team access**: return to the member invite area and confirm the correct people and roles were added - **Unexpected visibility**: recheck the project’s access or visibility settings This verification step is especially important when the project will be shared with reviewers right away. A quick check now prevents confusion later when pages start moving through authoring, review, and publishing. [SCREENSHOT: Project home or dashboard after onboarding] [SCREENSHOT: Navigation tree with starter sections confirmed] Once the project is opening correctly and the right people can access it, you are ready to decide how the project should continue from its initial setup path in [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). ## Overview Creating a project in Atloria is a two-part process: first you create the project record, and then you complete the onboarding wizard that builds the initial documentation setup. These two steps work together. The project record defines the project name, URL, ownership, and starting access, while onboarding defines the first structure your team will use for writing and review. This stage matters because the first decisions shape how the project appears everywhere else in Atloria. The selected workspace or organization affects ownership and team access. The chosen setup path—such as blank, template-based, or imported—affects the starting navigation tree and the pages your team sees first. The initial visibility choice affects who can find and open the project while it is still being prepared. You should treat onboarding as part of project creation, not as an optional extra step. If you stop after creating the project but before completing onboarding, the project may exist without a clear documentation structure or ready-to-use starting pages. Finishing the wizard gives your team a usable workspace instead of an empty shell. This guide focuses on the first setup pass: creating the project, making the key onboarding choices, reviewing the generated structure, and confirming access for the first contributors. It does not go deep into later project administration, publishing, or advanced setup paths. Those topics are covered in related guides such as [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home) and [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). If you are deciding between a simple manual setup and a more connected setup path, the next step is [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). ## Prerequisites Before you create a project in Atloria, make sure these basics are in place: - You can sign in to Atloria and reach the authenticated workspace area after login - You can access the projects list, project dashboard area, or organization workspace where project creation begins - You have permission to create a project in the workspace or organization you plan to use - You know who should be the initial project owner or lead administrator - You have decided which workspace or organization should contain the project - You have the **Project Name** ready - You have chosen the **Project URL** or **Slug** you want to use - You know the project’s primary documentation language - You have decided whether to begin with a **blank setup**, **starter template**, or **imported content** path - You know which team members should be invited immediately after onboarding It also helps to decide these items before you start: - whether the project should begin as a more restricted project or be visible to a broader internal team - whether contributors need editing access right away or only after the structure is reviewed - whether the default structure created by onboarding should be kept as-is or adjusted before inviting others If you are still setting up your account or having trouble entering Atloria, review [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If your role or workspace access is unclear, check with the people who manage your organization settings in Atloria or review [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings). After these prerequisites are covered, move on to [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup) to decide which onboarding path best fits your new project. ## Understanding how audiences control targeted documentation In Atloria, an **audience** is a reader group you define so your team can organize documentation for the right people. You might use audiences for internal staff, customers, partners, or different user roles inside the same project. Once an audience exists, documentation teams can use it when planning content, organizing pages, and deciding which material belongs to which reader group. The audience setup centers on four properties that appear in the audience configuration form: | Field | What it is used for | |---|---| | **Name** | The label people on your team see when choosing or reviewing an audience | | **Slug** | A short, URL-friendly identifier used to keep the audience distinct and consistent | | **Color** | A visual marker that helps the audience stand out in lists, badges, and targeting controls | | **Icon** | A symbol that gives the audience a quick visual identity | The **Name** is meant for people. It should be easy for writers, reviewers, and project administrators to recognize at a glance. The **Slug** is the stable identifier. It is usually shorter and more standardized than the Name. For example, a Name may be written in a natural style for your team, while the Slug stays compact and consistent for long-term use. Documentation Managers and Project Administrators typically reach audience settings from the authenticated workspace after signing in to Atloria. From there, they work inside the project or documentation configuration area where audience options are maintained alongside other documentation settings. [SCREENSHOT: Audience settings screen showing a list of audiences with Name, Slug, Color, and Icon] If you are still getting familiar with signing in and moving around Atloria, see [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) and [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). ## Creating a new audience When you are ready to add a reader group, open the audience management area in Atloria from your signed-in workspace, then start a new audience using the available **Create** or **Add** action on that screen. The exact button style may vary by workspace, but the action opens a form where you enter the audience details your team will use later in documentation targeting. 1. In the **Name** field, enter the audience label your writers and administrators will immediately understand. Keep it specific enough that nobody has to guess who the audience is for. A clear Name helps when several audiences appear together in the same project. 2. In the **Slug** field, enter a short, stable identifier. Use a simple format that stays readable over time. Because the Slug acts as the audience’s identifier, avoid casual wording that may need to change often. 3. Choose a **Color** that makes the audience easy to spot in lists, badges, or selection controls. If your team already uses several audiences, pick a color that is clearly different from the others. 4. Select an **Icon** that gives the audience a distinct visual marker. This is especially helpful when authors are scanning quickly through targeting options. 5. Review all four fields, then save the audience. [SCREENSHOT: New audience form with Name, Slug, Color, and Icon fields] A strong first setup saves cleanup later. Before you save, check that the **Name** is clear to people, the **Slug** is consistent with your team’s pattern, and the **Color** and **Icon** do not look too similar to another audience already in use. If your team is preparing project-level audience work next, continue with [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). ## Editing names, slugs, colors, and icons Audience details can change over time, especially when a project grows or your documentation team starts serving new reader groups. In Atloria, you can return to the audience management screen, open an existing audience, and update the fields that define how it appears across your documentation workspace. 1. Update the **Name** when the audience label needs to be clearer for authors, reviewers, or project administrators. This is the safest kind of change when the audience itself is still the same group but the wording no longer fits. 2. Edit the **Slug** only after checking how widely that audience is already used. Because the Slug is the audience’s identifier, changing it can affect consistency in targeted documentation work. If the audience is already established, treat slug changes as a deliberate cleanup task rather than a quick rename. 3. Change the **Color** when badges or audience markers are too similar in lists or targeting controls. This is useful when your team adds more audiences and the original color choices no longer stand out. 4. Replace the **Icon** if the current symbol no longer matches the audience’s role or looks too close to another audience icon in the same workspace. 5. Save the updated audience and review how it appears in the audience list. [SCREENSHOT: Edit audience screen with updated Name, Slug, Color, and Icon values] A good rule is to change the **Name** freely when the label needs improvement, but change the **Slug** carefully and less often. If the audience still represents the same reader group, a name refresh is usually enough. If the audience has truly changed meaning, review whether you should update it or create a separate audience instead. For guidance on how audience choices affect page structure and content planning, see [Applying Audiences to Documentation Structure and Content Decisions](doc:applying-audiences-to-documentation-structure-and-content-decisions). ## Organizing audiences for documentation teams and projects Audience setup works best when your team uses a shared pattern. In Atloria, the audience list becomes much easier to manage when every **Name**, **Slug**, **Color**, and **Icon** follows a clear convention. That matters even more when multiple projects, teams, or documentation managers are working in the same workspace. Use **Name** values that are easy to scan in a list. Good audience names usually describe a real reader group, such as an internal team, a customer role, or a partner group. Keep the wording direct and avoid names that are so broad they could apply to several groups at once. If two audience names feel interchangeable, authors may target the wrong one. For **Slug** values, stay consistent across projects. If your team prefers short lowercase identifiers, keep using that style. If you separate words in one way, use the same pattern everywhere. Predictable slugs reduce confusion and help your team recognize whether an audience already exists before creating another one. Color and icon choices should also work as a set, not one by one. When several audiences appear together, similar colors or nearly identical icons slow people down. Choose combinations that remain easy to tell apart in badges, labels, and selection controls. Create a new audience when the reader group is genuinely different and needs its own identity. Update an existing audience when the group is still the same but the label or visual style needs improvement. Creating too many near-duplicate audiences can fragment your documentation and make targeting harder to manage. If you also manage audiences beyond a single project, see [Using Audience Settings Across the Organization](doc:using-audience-settings-across-the-organization). ## Reviewing and maintaining existing audiences As your documentation workspace grows, it helps to review the audience list regularly. In Atloria, the audience list or audience detail view centers on the same core fields used during setup: **Name**, **Slug**, **Color**, and **Icon**. These four values tell you whether each audience is still clear, distinct, and useful for current documentation work. When reviewing existing audiences, look for patterns that create confusion: - Two audiences with nearly the same **Name** - **Slug** values that follow different formatting styles - Colors that look too similar when shown together - Icons that do not clearly distinguish one audience from another - Older audience labels that no longer match the reader group your team serves If an audience still represents an active reader group, you may only need to rename it or refresh its visual styling. If the audience is outdated and no longer belongs in current documentation targeting, it may be time to retire it from active use. Before making that decision, confirm how your team is using it in project documentation so you do not create gaps in audience planning. Ownership matters here. Documentation Managers and Project Administrators should agree on who can create new audiences, who approves naming changes, and who keeps the list clean over time. Without that shared ownership, teams often end up with duplicate reader groups that differ only by spelling, slug style, or color choice. [SCREENSHOT: Audience list view highlighting Name, Slug, Color badge, and Icon columns] If your team also works with broader workspace controls, [Using the Admin Workspace](doc:using-the-admin-workspace) and [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings) can help you align audience maintenance with other governance tasks. ## Common issues when managing audiences and how to fix them Most audience problems in Atloria come from naming conflicts, unclear visual choices, or labels that no longer match the reader group. These issues are usually easy to fix once you review the audience form and compare it with the rest of your audience list. A common problem is a **Slug** that is rejected or conflicts with an existing audience. When that happens, first compare the new slug with the slugs already in your audience list. If another audience already uses the same identifier, adjust the new slug so it is unique. If the slug format looks inconsistent, simplify it and follow the same style your team uses for other audiences. Another issue is an audience that is hard to distinguish in the interface. If authors cannot quickly tell one audience from another in badges or targeting controls, open the audience and change the **Color**, **Icon**, or both. Choose a combination that stands apart from the other audiences already in use. You may also find that the **Name** no longer matches the intended reader group. In that case, update the Name so it reflects how your team currently talks about that audience. After renaming it, check that writers and administrators still use the audience consistently in documentation planning. Use this quick review when troubleshooting: - **Slug problem:** Check for duplicates and simplify the format - **Visual confusion:** Change the **Color** or **Icon** - **Outdated label:** Revise the **Name** - **Too many similar audiences:** Compare existing entries before creating another one [SCREENSHOT: Audience form showing a slug validation message and editable color/icon options] If the issue is not with the audience definition itself but with how it is applied inside a project, the next guide is [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). ## Overview Audiences in Atloria give your documentation team a practical way to define who content is for before you start organizing pages or publishing targeted material. Each audience is built from four visible settings in the audience form: **Name**, **Slug**, **Color**, and **Icon**. Together, these make the audience understandable to people and easy to recognize across the workspace. The most important distinction is between **Name** and **Slug**. The Name is the reader-friendly label your team sees in lists and targeting choices. The Slug is the stable identifier that should remain short, readable, and consistent. **Color** and **Icon** do not change the meaning of the audience, but they make it much easier to scan and select the right one when several reader groups appear together. As you work with audiences, focus on consistency. Clear names reduce mistakes for writers and reviewers. Predictable slugs help avoid duplicates. Distinct colors and icons make the audience list easier to manage. When a reader group changes slightly, update the existing audience. When the group is truly different, create a new one. This guide focused on defining the audience itself. The next step is applying those audience definitions inside a project so documentation teams can use them in real content workflows. Continue with [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). ## Prerequisites Before defining audiences in Atloria, make sure you have the basics in place: - You can sign in to Atloria and reach the authenticated workspace - You have access to the project or documentation configuration area where audience settings are maintained - You are working as a Documentation Manager, Project Administrator, or another role allowed to maintain audience settings - Your team has agreed on the reader groups you want to represent, such as internal users, customers, or partners - You have a simple naming approach for **Name** and **Slug** so new audiences follow the same pattern - You are ready to choose distinct **Color** and **Icon** options that will remain easy to recognize in lists and targeting controls If you still need help getting into Atloria or understanding workspace access, start with [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If your access depends on admin setup, [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) explains how teams control who can work in these areas. ## Opening audit and version records from control pages In Atloria, you can start this work from two places: a **project control page** inside a specific project, or the **enterprise control page** in the admin area. Use the project control page when you want records for one project only. Use the enterprise control page when you need a broader view across teams, projects, or organization-wide activity. On each control page, look for two separate record areas: - an **audit activity** area for action history - a **version records** area for documentation version history These two lists serve different purposes. **Audit records** show who did something, when they did it, and what item was affected. This is the right place when you need an activity trail, such as reviewing changes, approvals, access-related actions, or other tracked events. **Version records** focus on documentation history. Open this list when you need to report on version changes, track revision activity, or review how documentation evolved over time. Before you export anything, make sure you opened the correct list. If you need a timeline of user actions, open the audit activity list. If you need documentation change history, open the version records list. Access also depends on your role. In most teams, a **Project Administrator** can open project-level control pages and review records for that project. A **Documentation Manager** may also work from project pages when preparing documentation history or version-related exports. For broader oversight from the enterprise control page, your account needs access to the admin workspace and its record screens. [SCREENSHOT: Project control page showing the audit activity area and version records area side by side or in separate tabs] If you need help reaching the admin workspace first, see [Using the Admin Workspace](doc:using-the-admin-workspace). ## Reviewing audit activity before exporting Before you click **Export**, spend a moment checking the audit activity list on the control page you opened. This helps you avoid downloading the wrong date range, the wrong project scope, or a list that still has old filters applied. Start by reviewing the visible columns in the audit list. In Atloria, the most important details to verify are: - the **user** who performed the action - the **timestamp** or action date - the **affected item** - the **action** itself These details tell you whether the list matches the audit trail you want to share or archive. For example, if you are preparing a project review, confirm that the affected items belong to the correct project. If you are checking organization-wide oversight, confirm that the list is not limited to one project only. Use the list controls to narrow the results before export. Depending on what is available on the page, this may include sorting, filters, or a date-range selector. Sorting helps you bring the newest or oldest actions to the top. Filters help you focus on a person, item, or action type. A date range is especially useful when you only need activity for a release window, approval period, or monthly report. A quick review like this can prevent incomplete exports. If the list is filtered to one user or one short date range, the export will likely reflect that limited view. If the page shows enterprise-wide activity, the export may include records from multiple projects. Use this table as a simple check before exporting: | What to verify | Why it matters | |---|---| | User | Confirms who performed each action | | Timestamp | Confirms the reporting period | | Affected item | Confirms the correct document, version, or project item | | Action | Confirms the type of event being exported | | Scope | Confirms whether the list is project-only or enterprise-wide | [SCREENSHOT: Audit activity list with user, action, affected item, and timestamp visible] ## Exporting audit records from a project or enterprise view Once the audit activity list shows the records you need, start the export directly from that list. Stay on the same control page where you reviewed the records, then use the **Export** action available on the audit records screen. 1. Open the **audit activity** list from either the project control page or the enterprise control page. 2. Review the current scope shown on the page so you know whether you are exporting a single project view or an enterprise-wide view. 3. Apply any filters, sorting, or date-range settings you want included. 4. Click **Export** from the audit records area. 5. If Atloria shows export choices, select whether to export the **current filtered results** or the **full record set**. 6. Complete the download. The most important decision here is scope. If you start from a project control page, the export should reflect that project-level view. If you start from the enterprise control page, the export should reflect the broader oversight view. Always confirm this before downloading, especially if you plan to share the file with leadership, compliance reviewers, or project owners. If export options appear before download, choose carefully. Exporting the current filtered results is useful when you already narrowed the list to a release period, a team member, or a specific action type. Exporting the full record set is better when you need a complete activity history from the current page scope. After the file downloads, expect it to match the records shown on screen at the time of export. That means the file should reflect: - the control page you used - the current filters - the selected date range - the visible audit scope [SCREENSHOT: Audit activity list with the Export action open and options for current results or full record set] For broader admin context around oversight screens, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls). ## Exporting version records for documentation history When you need documentation change history rather than action tracking, move from the audit activity area to the **version records** area on the same control page. In Atloria, this is the better choice for release notes, revision reporting, and documentation history reviews. 1. Open the project control page or enterprise control page. 2. Switch from **audit activity** to **version records**. 3. Review the version list before exporting. 4. Click **Export** from the version records area. 5. Download the file after confirming any export options shown. Before exporting, check the version-specific details in the list. The most useful fields to review are: | Field | What to confirm | |---|---| | Version identifier | Confirms you are exporting the correct version entries | | Modified item | Confirms which document or content item changed | | Author | Confirms who made or owned the change | | Change date | Confirms the revision period covered by the export | This export is different from an audit export because it focuses on documentation revisions rather than general activity. An audit export answers questions like “who performed this action?” A version export answers questions like “what changed in this documentation version, and when?” Documentation Managers will usually prefer version records when preparing change-history reports, reviewing release readiness, or keeping a record of documentation updates over time. Project Administrators may also use version exports when they need a clean revision history without unrelated activity events. If both lists are available on the same page, pause and confirm which one you are in before clicking **Export**. It is easy to export the wrong record type if you switch between tabs or sections quickly. [SCREENSHOT: Version records area showing version identifier, modified item, author, and change date before export] If your work also includes version review and release decisions, see [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle). ## Choosing the right export for project reporting or enterprise oversight The best export depends on two choices: **where you start** and **what history you need**. In Atloria, the starting page controls the scope, and the record type controls the meaning of the export. Use the **project control page** when you are preparing a report for one project. This is the right place for project leads, Project Administrators, and Documentation Managers who need records tied to a single workspace. Use the **enterprise control page** when you need cross-project oversight, broader audit review, or an organization-level activity picture. Then choose the record type: - Use an **audit export** for action tracking - Use a **version export** for documentation revision history An audit export is better when you need to show who did what and when. This is useful for oversight, approvals, tracked actions, and activity reviews. A version export is better when you need to show how documentation changed over time, which version entries were updated, and who made those changes. Filtered views also matter. If you filter the list before exporting, the file may only include that narrowed set of records. This is helpful when you want a focused report, but it can create problems if someone expects a complete history. Before sharing a file, verify: - whether the page is project-level or enterprise-level - whether filters are active - whether the date range is limited - whether you exported audit activity or version records A few review habits can help avoid incomplete or duplicate exports: - check the page title and section name before exporting - clear old filters if you need a full history - confirm the date range every time - avoid exporting from both project and enterprise views unless you truly need both If you are deciding between export types for release work, [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options) can help with related decisions. ## Fixing missing records, incorrect scope, and export problems If your export does not look right, the cause is usually the current page scope, the selected list, or filters left on from an earlier review. In Atloria, it is worth checking the on-screen list carefully before exporting again. If **audit records are missing**, start with the visible controls on the page: - check whether a filter is active - review the selected date range - confirm whether you are on the **project control page** or the **enterprise control page** A project page will only show project-level activity, so it will not include organization-wide records. If you expected a broader result, move to the enterprise control page and review the audit list there. If **the wrong records were exported**, confirm that you started the export from the correct area. This is a common mistake when both **audit activity** and **version records** are available on the same control page. Audit exports and version exports are not interchangeable, so reopen the correct list and export again. If **you cannot see the Export action**, the issue is usually access. Project Administrators commonly have project-level access, while broader export access may depend on admin workspace permissions. Documentation Managers may have access to version-related exports but not every enterprise-level record view. If the button is missing, compare your role with the page you are trying to use. If **the downloaded file does not match the on-screen list**, refresh the control page first. Then reapply the intended filters, sorting, and date range. After that, review the visible records once more and run the export again. This is especially helpful if you switched between projects, tabs, or admin pages during the same session. [SCREENSHOT: Control page with filters, date range, and Export action highlighted for troubleshooting] For related admin visibility and access topics, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Overview This guide focuses on exporting two types of records in Atloria: **audit activity** and **version records**. You can begin from either a **project control page** or the **enterprise control page**, depending on how broad your report needs to be. The core idea is simple: - open the correct control page - choose the correct record list - review the visible records - export the results you actually need Use **audit activity** when you want a history of actions. This is helpful for oversight, operational reviews, and checking who performed a tracked action. Use **version records** when you want documentation history. This is better for revision reporting, release support, and documenting how content changed over time. This guide also explains how scope affects your export. A project control page gives you a project-specific view. The enterprise control page gives you a broader administrative view. If filters or date ranges are active, they may affect what appears in the downloaded file, so checking the list before export is an important part of the workflow. You will also find troubleshooting help for common problems, including: - missing records - exporting from the wrong list - access to export actions - downloaded files that do not match the screen [SCREENSHOT: Side-by-side example of a project control page and enterprise control page] If you are already comfortable reaching these work areas and just need help with the export process itself, the sections above give the quickest path. In the next document, continue with [Managing Audit Exports and Activity Records](doc:managing-audit-exports-and-activity-records) to work more closely with exported audit files and ongoing record review. ## Prerequisites Before you export audit or version records in Atloria, make sure a few basics are in place. This will help you avoid access issues and prevent incomplete exports. You should have: - access to the **project control page** for the project you want to review, or access to the **enterprise control page** in the admin workspace - a role that allows you to view record lists and use the **Export** action - a clear idea of whether you need **audit activity** or **version records** - the project name, reporting period, or review window you want to export It also helps to know your reporting goal before you begin. For example: - choose **audit activity** for action tracking and oversight - choose **version records** for documentation change history - choose the **project control page** for one project - choose the **enterprise control page** for broader oversight If you are not sure whether your account can reach the necessary pages, review: - [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) - [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) - [Using the Admin Workspace](doc:using-the-admin-workspace) Before exporting, it is also useful to confirm that the records you need are already visible on screen. If the list is empty, too short, or clearly limited to the wrong date range, fix that first rather than exporting and checking later. [SCREENSHOT: Audit or version list ready for export with the correct page scope and date range selected] After these basics are in place, you can move through the export steps in this guide and then continue to [Managing Audit Exports and Activity Records](doc:managing-audit-exports-and-activity-records) for the next stage of audit export work. ## Confirming Which Atloria Pages Can Be Exported In Atloria, export actions are tied to the pages where documentation work is reviewed, versioned, and managed. The most common place to export is a documentation page inside a project workspace, especially when that page has version history, release activity, or review activity attached to it. If you are working from a version-focused view, first confirm that you are on the page that shows the documentation content together with its version information, not just a project list or dashboard. You will usually find export controls in one of these places: - The page toolbar at the top of the documentation page - A **More actions** menu on the page - A related records area that shows linked release, review, or reporting items [SCREENSHOT: documentation page with page toolbar, More actions menu, and related records area highlighted] Page status matters before you export. A documentation version that is still in review may be available for export, but it may only reflect the current review state at that moment. That means reviewer comments, pending decisions, or incomplete sign-off details may still change later. A released version is typically the better choice when you need a stable record for handover, audit support, or final distribution. It also helps to distinguish between two export types: - **Single version export**: exports the selected documentation version only - **Version plus related records export**: exports the page together with linked release, review, and reporting information Choose the first option when you only need the documentation content or version details. Choose the second when you need the full workflow trail around that page, such as approval history, release references, and reporting-linked activity. If you are unsure which one you need, compare your goal with the guidance in [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving). ## Preparing Documentation Versions and Related Records for Export Before you start the export, take a moment to confirm that the page is showing the exact version you want. In Atloria, documentation pages can have multiple versions, so exporting from the wrong version can easily produce outdated content or the wrong release history. Use the version selector or version history area on the page to verify the active version label before opening any export option. Check these page details carefully: - **Title** of the documentation page - **Version label** currently selected - **Release state** shown for that version - Linked **review records** - Linked **release records** - Linked **reporting records**, if your team uses them If the page includes a related records panel, review it before exporting. This is where you can confirm whether the page is connected to the approvals, comments, release entries, or reporting items you expect to include. If a comment thread or release entry is missing from the page view, it will likely be missing from the export as well unless you switch to the correct version or record set first. Permissions also affect what you can export. In practice, users working as Documentation Managers or Project Administrators are the ones most likely to see export actions and the linked workflow data needed for complete exports. If you can open the page but cannot see export options, or you can export the page content but not the related records, your access may be limited for that project or workspace. A quick pre-export review helps avoid redoing the file later: | Check | What to confirm | |---|---| | Version | The correct version is selected | | Status | Review, released, or other visible state matches your need | | Related records | Release, review, and reporting items appear on the page | | Metadata | Title and version label are current and correct | | Access | Export controls and record details are visible to you | If you need more help checking version state before exporting, see [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). ## Exporting a Documentation Version from an Atloria Page 1. Open the documentation page you want to export in Atloria. Make sure you are on the page itself, not only in a project list or summary view. 2. Use the version selector to choose the exact documentation version you need. If the page shows version history, confirm the selected version label before continuing. This is especially important when the page has draft, in-review, and released versions. 3. Go to the page toolbar or open **More actions**. Look for the export option available on that page. In many cases, the export action is grouped with other page-level actions rather than shown inside the document body. 4. When the export dialog opens, choose the export scope for that version. Atloria may offer options such as: - Current version only - Version details with metadata Use **Current version only** when you need the documentation content for sharing or reference. Use **Version details with metadata** when you also need identifying information such as the page title, version label, or release state. 5. Review the output format shown in the export dialog. Select the format offered on that screen, then check the file name or naming pattern before you confirm the download. 6. Click the export or download confirmation button to generate the file. [SCREENSHOT: export dialog showing selected version, export scope, output format, and file name] If the page contains several versions, it is worth reopening the version selector one last time before you confirm. Many export mistakes happen because users stay on the right page but leave the wrong version active. For teams that manage frequent releases, that small check prevents confusion during review, handover, and audit work. If your goal is broader than a single version file, continue with the related-record options described in [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records). ## Including Release, Review, and Reporting Records in the Export 1. Start from the documentation page and open the export action from the page toolbar or **More actions**. 2. In the export dialog, choose the option that includes related records. Avoid options that export only the page body or version content if you need workflow evidence along with the documentation. 3. Add the linked release records when you need the export to show how the page was tied to a release. Look for release-related selections that capture details such as: - Release identifier - Release status - Associated version reference 4. Include review workflow records if you need approval and feedback history. On pages with review activity, this can include: - Reviewer assignments - Review decisions - Comment history tied to the page or selected version 5. Add reporting records when your team uses reporting or audit-linked entries connected to the page. This helps preserve the broader workflow context, not just the documentation itself. 6. Confirm the final export scope before downloading. If the dialog separates content export from workflow export, make sure both are selected when needed. [SCREENSHOT: export options with related release, review, and reporting records selected] This type of export is especially useful when the file will be reviewed outside Atloria. A documentation-only export may show what was written, but it will not always show who reviewed it, whether it was approved, or how it was tracked in release and reporting work. Including linked records gives the recipient a fuller picture of the page’s lifecycle. If you are preparing material for sign-off, audits, or stakeholder review, check that the page already displays the linked records you expect. Atloria can only export the records associated with that page and selected version. If a release, review, or reporting item is not linked correctly, it may not appear in the output. ## Choosing the Right Export Scope for Audit and Handover Needs The right export scope depends on why you are exporting the page. In Atloria, you can keep the export narrow and focused on one documentation version, or broaden it to include the workflow history around that version. Choosing carefully keeps the file useful without making it harder to review. A **current page version** export is best when you need the latest approved or working copy of the documentation itself. This is often enough for quick sharing, internal reference, or content review. A **historical version** export is more useful when you need to preserve what the page looked like at a specific point in time, such as a prior release or earlier review milestone. A **version plus related workflow records** export is the stronger choice when context matters. Documentation Managers often need this broader export for compliance reviews, sign-off tracking, or release evidence because it preserves the review and release trail together with the page. Project Administrators may also need the broader option when preparing project audits, migration packages, or stakeholder handovers that must show not only the content, but also how that content moved through review and release steps. Here is a simple way to choose: | Export scope | Best used for | |---|---| | Current version only | Sharing the latest page content | | Historical version | Preserving an earlier state of the page | | Version with metadata | Identifying the exact exported version clearly | | Version plus related records | Audit, handover, approvals, and workflow tracking | The tradeoff is straightforward: - Smaller exports are easier to share and review quickly - Broader exports preserve more context, but can include more detail than every reader needs If your recipient needs proof of review, release, or reporting activity, do not rely on a content-only export. If they only need the page text and version identity, keep the export focused. For more decision help, see [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving). ## Fixing Missing Versions, Incomplete Records, and Export Failures If the version you expect does not appear in the version selector or export dialog, first confirm that you are on the correct documentation page. Then reopen the version history and check whether the version is available in that page’s visible list. If you recently switched projects or pages, it is easy to start an export from the wrong location. Also verify whether the version is still in review, already released, or otherwise filtered in the current view. When an export finishes but leaves out release, review, or reporting records, the most common cause is export scope. Reopen the export dialog and make sure you selected the option that includes related records, not only the page content. Then compare the export settings with the related records shown on the page. If a release entry, reviewer decision, or reporting item is not visible on the page, it may not be linked to the selected version you are exporting. Permission issues can look different depending on your role. You might see the page but not the export action, or you might be able to export the documentation content while related workflow details remain unavailable. In that case, compare what you can see with what a Documentation Manager or Project Administrator is expected to access in that workspace. If the export action is blocked for you, ask someone with the appropriate project or administrative access to confirm the page settings and record visibility. For failed or partial downloads: - Retry the export from the page toolbar or **More actions** - Recheck the selected version - Reconfirm the output format shown in the export dialog - Make sure the related record set you need is selected - Try the export again after reopening the page [SCREENSHOT: export dialog reopened after a failed download, with version and related record options checked] If the issue is really about readiness rather than the export itself, use [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions) to confirm the page and its linked records are complete before trying again. ## Overview Atloria’s export options help you take a documentation page and turn it into a shareable record that matches the work completed around it. Depending on the page and the version you choose, you can export just the documentation content, the version details, or the page together with release, review, and reporting records. That makes exports useful for more than simple file sharing. They also support audit preparation, release tracking, approval evidence, and project handovers. This document focuses on page-level exports from documentation workspaces where version history and linked records matter. The key decision is not just whether to export, but what to include. A single-version export is usually enough when someone only needs the content. A broader export that includes related records is better when the recipient needs to understand how the page moved through review, release, or reporting steps. As you work through exports in Atloria, pay attention to three things: - The exact version selected on the page - The page status, especially whether it is still in review or already released - Whether related release, review, and reporting records are included in the export scope Those checks prevent the most common mistakes, such as exporting the wrong version or sending a file that lacks approval history. If you are already comfortable with version and release workflows, this guide gives you the practical steps for turning those records into export files. If you need help deciding which export type fits your goal, pair this guide with [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving). ## Prerequisites Before exporting documentation and related records in Atloria, make sure these basics are in place: - You can sign in to Atloria and open the relevant project workspace - You can access the documentation page you want to export - The page has the version history or version selector needed to choose the correct version - Any release, review, or reporting records you want included are already linked to that page - You can see the export action in the page toolbar or **More actions** menu It also helps to confirm your role before you begin. Documentation Managers and Project Administrators are the users most likely to have access to both export actions and the related workflow details needed for complete exports. If you can open the page but cannot see linked review or release information, your export may be limited to the page content only. Before starting, review these items on the page: - The current **Title** - The selected **Version label** - The visible release or review state - The related records panel, if shown - Any comments, approvals, or reporting entries you expect to preserve If you are new to Atloria account access or need help getting into the right workspace first, see [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). The next step in this Export Center sequence is [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records), which focuses on handling exports as part of repeatable documentation processes rather than one page at a time. ## Checking access before you generate a version Before you start, open Atloria and go to the project where you want to create the new documentation version. Use the project workspace navigation to find the **Versions** area. If you can open the project but do not see **Versions** in the project navigation, or you can open the version list but do not see a **New Version** or **Generate Version** action, your account may not have the right level of access for version creation. In that case, ask a Project Administrator to review your project permissions. On the **Versions** page, check that you are in the correct documentation project and looking at the right version list. This matters when your team manages several projects or multiple release tracks. Confirm the project name shown in the workspace header and review the existing version entries so you know where the new version will be added. If your team already uses naming patterns for releases, drafts, or milestones, identify the version label you plan to use before opening the creation form. You should also make sure the source material you expect Atloria to use is available in the project. If your team generates versions from current project content, connected source material, or an existing version, confirm that content is already present and visible in the project workspace. Missing source content can delay generation or cause the new version to be incomplete. A quick access check usually includes: - Opening the correct project workspace - Finding the **Versions** section in project navigation - Confirming you can see **New Version** or **Generate Version** - Reviewing the current version list for the correct project - Verifying the source content you want to generate from is available [SCREENSHOT: Project workspace with the Versions section highlighted in the left navigation] ## Starting a new documentation version 1. In Atloria, open the correct project and select **Versions** from the project navigation. 2. On the **Versions** page, click **New Version** or **Generate Version**. Atloria opens the version creation form. 3. In the version form, enter the version name or label. Use the exact naming format your team expects, because this label will appear in the version list, comparison views, and review steps later. If your team tracks releases by milestone or release number, make sure the label clearly distinguishes this version from earlier ones. 4. Choose the source Atloria should use for generation. Depending on how your project is set up, this may be the latest project content, an existing version, or the current published documentation. Review the source choice carefully before you continue, especially if you are creating a version for release review rather than a working draft. 5. Submit the form to start generation. After you confirm, Atloria returns you to the version list or updates the page so the new version appears as a new entry. 6. Find the new row in the **Versions** list and confirm that it shows an early processing state rather than a final review state. Right after submission, the version may appear with a status that indicates it has been created and is waiting to begin, or that generation has already started. At this point, the important check is simple: the version should now exist in the list with the name you entered and a processing status. If the version does not appear, refresh the page once and check the list again before starting another one. [SCREENSHOT: Versions page showing the Generate Version button and the version creation form] ## Following generation progress in the version list 1. Stay on the **Versions** page after you submit the new version. Atloria shows progress directly in the version list, usually in the row for the version you just created. 2. Look for the status badge in that row. This is the fastest way to tell whether the version is still waiting, actively generating, or ready for review. If the list also shows a progress indicator or a **Last updated** value, use those details to confirm that work is still moving forward. 3. Click the version entry to open its details page if you want a closer view. The version details screen is the best place to watch generation activity when you need more than the list view gives you. It can also help you confirm whether Atloria is still processing content or has stopped because of an issue. 4. While generation is running, expect some actions to remain unavailable. A version that is still being built is not yet ready for comparison, review, or sharing. If buttons for those tasks are missing or inactive, that usually means Atloria is still processing the version. 5. Watch for page updates. In some workspaces, the version status may update on its own. If the status does not change after a reasonable wait, reload the page and check the row again. A manual refresh is also useful if you have the version details page open in one tab and the version list open in another. When you monitor progress, focus on these items in the version row or details view: - Status badge - Progress display, if shown - Last updated time - Availability of review or comparison actions [SCREENSHOT: Version list row with status badge and updated time visible] ## Understanding version status changes As soon as you create a version, Atloria adds it to the **Versions** list and begins moving it through a visible status flow. The exact wording may vary slightly by workspace, but the pattern is consistent: the version starts in an early waiting state, moves into active generation, and then finishes in a state that signals it is ready for review. A **Queued** or **Pending** status means the version record has already been created, but Atloria has not started building the content yet. You should still see the version in the list with its name and creation details. This status is normal immediately after submission, especially if other generation work is already underway. A **Generating** or **In Progress** status means Atloria is actively building the version. During this stage, the version exists, but the output is not final. You may be able to open the version details page, but you should expect generation indicators, temporary warnings, or limited actions until processing is complete. A **Ready**, **Completed**, or review-ready status means the version has finished generating and is available for the next step in the release workflow. Once the version reaches this state, you can usually open it, inspect the generated content, compare it with another version, and begin review-related work. Use the status badge as your main guide: | Status shown in Atloria | What it means for you | What to do next | |---|---|---| | Queued / Pending | The version exists and is waiting to start | Wait and refresh the list if needed | | Generating / In Progress | Atloria is building the version | Monitor progress and avoid review actions for now | | Ready / Completed | Generation is finished | Open the version and begin review checks | If you want a broader view of how these states fit into the full release cycle, see [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness). ## Confirming that the version is ready for review 1. Return to the **Versions** page and locate the version you generated. Check the status badge first. It should show a final ready state such as **Ready** or **Completed**, not **Queued**, **Pending**, or **Generating**. 2. Open the version details page by selecting the version entry. Review the page for any remaining generation notices. A review-ready version should open without active processing indicators, warning banners about generation still running, or other signs that the content is unfinished. 3. Confirm that the generated content can be opened normally. If the version details page lets you move into the content itself, make sure the pages load as expected and that you are not blocked by a processing message. 4. Check whether review-related actions are now available. A finished version should make it possible to continue with tasks such as opening the version, sharing it with reviewers, or comparing it with another version. If those actions are still unavailable, refresh the page and verify the status again. 5. Review the version metadata shown on the record. At minimum, confirm the version name matches what you intended to create and that the creation time is correct. If Atloria shows a completion time or updated time, use that to confirm generation has fully finished. A review-ready version should give you confidence in four areas: - The status badge shows the final ready state - The version details page opens without processing warnings - Review and comparison actions are available - The version record shows the expected name and timing details Once those checks look right, continue with [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness). [SCREENSHOT: Version details page showing a completed status and available review actions] ## Fixing problems when a version does not finish generating If a version stays in **Queued**, **Pending**, or **Generating** longer than expected, start with the version list and version details page. Check whether the **Last updated** time is changing. If the time remains unchanged after repeated refreshes, Atloria may no longer be actively processing that version. Refresh the page once, then reopen the version details view to see whether the status changes there. A failed generation is usually easiest to spot from the version’s status badge or from a message on the version details page. If Atloria shows an error message, read it closely and compare it with the source you selected when you created the version. Problems often come from missing source content, choosing the wrong base version, or not having the required access to complete the action. Use this approach when something goes wrong: - If the version is still updating, wait and keep watching the status - If the version shows a failure or error state, do not assume it will recover on its own - If the source content was missing or incorrect, fix that first before trying again - If you cannot see generation actions anymore, ask a Project Administrator to review your access and the project setup Retry generation when the issue appears temporary and the source content is available. If the original version record is clearly unusable, create a replacement version with the correct source and naming details. After you retry or create a replacement, return to the **Versions** list and confirm the new entry follows the normal flow: it should appear in the list, show an early processing status, and then move forward through the usual generation states. If you need help deciding whether to retry or replace the version, the follow-up guide [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results) covers the monitoring side in more detail. ## Overview Generating a new documentation version in Atloria is the starting point for release review work. You use the **Versions** area inside a project workspace to create a separate version record, choose the source content Atloria should build from, and then monitor that version until it reaches a review-ready state. The main screens involved are the project workspace, the **Versions** list, the version creation form, and the version details page. The basic flow is straightforward: - Open the correct project - Go to **Versions** - Click **New Version** or **Generate Version** - Enter the version label - Choose the source content - Submit the form - Watch the status change until the version is ready What matters most during this process is reading the status correctly. A newly created version may appear immediately, but that does not mean it is ready to review. Atloria first creates the version entry, then processes the content, and only after that makes review actions available. The status badge and version details page are your main tools for understanding where the version stands. This guide focuses on creating the version and confirming that generation finishes successfully. It does not cover detailed comparison or approval work after the version is ready. For the broader release workflow around version lists, statuses, and release decisions, see [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). If you are already signed in and working inside the right project, you can move through this process quickly. The key is to verify the project, source, and status at each step so the version you generate is the one your team actually intends to review. ## Prerequisites Before you generate a version in Atloria, make sure the project and your access are ready. You do not need to complete advanced setup on the same screen, but a few checks prevent failed or confusing version runs. Use this checklist before you click **New Version** or **Generate Version**: - You can sign in to Atloria and open the project workspace - The project already exists and contains the documentation content you want to generate from - You can see the **Versions** section in the project navigation - You can access the **New Version** or **Generate Version** action - You know which source content or existing version should be used as the base - You have the version name or label your team wants to use If you are still getting into the project or setting it up for the first time, these guides may help first: - [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) - [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces) - [Managing Project Version Workspaces](doc:managing-project-version-workspaces) If you cannot find the version controls, the issue is usually one of these: - You are in the wrong project - Your account does not have permission to create versions - The project content needed for generation is not available yet In those cases, stop before creating duplicate attempts. Confirm the project name in the workspace header, review the existing version list, and ask a Project Administrator for help if the **Versions** area or generation action is missing. After these prerequisites are in place, you are ready to create a version and then move on to [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness). ## Opening a documentation version and understanding available actions In Atloria, documentation version work usually starts from the project area where version records are listed. Open your project, go to the documentation versions area, and select the version you want to work on. When you open a version page, that page becomes the main workspace for release-cycle tasks. Instead of moving between unrelated screens, you use the version page to launch the actions tied to that specific release. [SCREENSHOT: Documentation versions list with one version selected] On the version page, look for actions related to: - **Generate** or refresh version content - **Compare** this version with another version - **Review** the generated documentation - **Release readiness** or readiness checks - **Screenshots** for version-specific image updates - **Export** options for release deliverables These actions matter because each one depends on the current version you have open. If you start from the wrong version page, you may compare, review, or export the wrong release. Different team members usually focus on different actions: - **Documentation Managers** use **Compare**, **Review**, and **Release readiness** to decide whether a version can move toward publication. - **Project Administrators** usually handle actions that depend on project setup, connected sources, or release-sensitive settings, especially when generation or export results do not match expectations. - **Technical Writers** spend most of their time in **Review** and **Screenshots**, checking that pages, wording, and visuals match the intended release. Treat the version page as the control center for the release cycle. A common flow is to open the version, generate or refresh content, compare it with an earlier version, review the results, update screenshots if needed, and only then move to export. If you need help understanding the broader project workspace around versions, see [Managing Project Version Workspaces](doc:managing-project-version-workspaces). ## Generating and refreshing version content Use the **Generate** action on the version page whenever you need Atloria to create or refresh the documentation output for that version. This is usually the first major step after opening a version, especially if the release includes new features, updated screens, changed wording, or newly connected source material. 1. Open the version you want to update. 2. Click **Generate**. 3. Confirm the action if Atloria asks you to proceed. 4. Stay on the version page and watch for progress updates, status changes, or a recent activity timestamp. [SCREENSHOT: Version page showing the Generate action and generation status] When you regenerate a version, Atloria refreshes the documentation output tied to that version. From a user perspective, that means the version’s generated pages and related release content are brought up to date based on the latest available project information. If your team has made changes since the last run, regeneration helps make sure those changes appear before review. Rerun generation during the release cycle when: - source content has changed - documentation pages were updated - screenshots or release details need to align with newer content - comparison results look out of date - reviewers report missing or stale information After generation starts, look for visible signals on the version page such as an in-progress state, a refreshed status, or an updated “last generated” style timestamp. These indicators help you confirm that the version has been rebuilt recently enough for review and export work. Generation affects everything that comes after it. If you compare versions before refreshing content, your comparison may miss recent changes. If you review too early, you may approve outdated material. If you export before regeneration finishes, your deliverables may not reflect the latest version state. For a deeper walkthrough focused only on creating new version output, see [Generating New Documentation Versions](doc:generating-new-documentation-versions). ## Comparing versions to review release changes The **Compare** action helps you check what changed between one documentation version and another. This is one of the most useful tools on the version page because it turns a general “something changed” feeling into a clear release review task. Instead of manually opening pages side by side, you can compare the selected version against an earlier or alternate version and inspect the differences. 1. Open the version page for the release you are preparing. 2. Click **Compare**. 3. Choose the target version you want to compare against. 4. Review the comparison results for added, removed, or changed content. [SCREENSHOT: Compare view with current version and target version selectors] Use the comparison view to confirm whether release updates are actually reflected in the documentation. Pay close attention to: - newly added sections for new features - removed content that should no longer appear - changed wording that reflects updated behavior - UI-related content that should match recent screen changes - documentation edits that may affect release notes, training, or support material This step is especially helpful when multiple people have worked on the same release. A Documentation Manager can use the comparison results to decide whether the version is complete enough for formal review. A Technical Writer can use the same results to spot missing explanations, inconsistent terminology, or pages that still reflect the previous release. Comparison is most valuable at three points in the cycle: - **After regeneration**, to confirm the latest output is present - **Before review is completed**, so reviewers know what changed - **During release readiness checks**, to verify that the release scope matches the documentation scope If the comparison shows missing updates, return to the version page and run **Generate** again before moving forward. If you want a more focused guide to using comparison views, see [Working with Version Comparison Views](doc:working-with-version-comparison-views). ## Reviewing content and checking release readiness Once a version has been generated and compared, move to the review-related actions on the version page. This is where your team decides whether the content is complete, accurate, and suitable for release. In Atloria, review is not just proofreading. It is the point where content quality and release timing come together. 1. Open the version page. 2. Start the available **Review** action or open the review area tied to that version. 3. Check the generated content for accuracy, completeness, and release alignment. 4. Look for readiness signals on the version page before deciding whether the version can move forward. [SCREENSHOT: Version page showing review status and release readiness indicators] During review, Technical Writers usually focus on whether the documentation reads clearly and matches the intended user experience. They check that pages are present, instructions make sense, and release-specific updates are included. Project Administrators often help validate details that depend on project configuration or connected content, especially when a page appears incomplete or does not match the current setup. Documentation Managers typically use the review outcome to make the release decision. Signals that a version is likely ready include: - the latest generation has completed - comparison results reflect the expected release changes - review work has been completed without unresolved issues - screenshots and supporting materials are current - no visible blockers remain on the version page Signals that a version is still blocked include: - outdated generated content - missing release changes in comparison results - incomplete review work - screenshots that no longer match the interface - export preparation started before review was finished If review reveals problems, update the content, regenerate the version, and repeat the comparison if needed. That loop is normal during active release work. For a deeper look at approval and decision-making, see [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) and [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness). ## Managing screenshots for a version Screenshots often become the last thing teams notice and the first thing readers question. On the version page, use the screenshot-related action to review or refresh the images tied to that release. This is especially important when the release includes visible interface changes, renamed buttons, updated navigation, or new page layouts. 1. Open the version you are preparing. 2. Select the screenshot-related action from the version page. 3. Review the images associated with that version. 4. Refresh or replace screenshots that no longer match the current content. [SCREENSHOT: Version page with screenshot action and image review area] Update screenshots when: - the interface changed since the previous version - generated content now describes a different screen flow - comparison results show UI-related changes - reviewers flag mismatched images during content review Screenshot maintenance is not separate from release readiness. If the text says one thing and the image shows another, the version is not truly ready. Technical Writers usually catch these issues first during review, but Documentation Managers often use screenshot completeness as part of the final release decision. There is also a practical reason to handle screenshots before export. Exported deliverables should reflect the same version state that was reviewed and approved. If screenshots are outdated when you export, your release package may include correct text with incorrect visuals. That creates confusion for reviewers, customers, and internal teams using the exported material. A good pattern is to refresh screenshots after generation and before final review sign-off. If you update screenshots because of major UI changes, it is worth revisiting the version review once more to make sure the written instructions still match the new images. For more detailed screenshot workflows, see [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) and [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release). ## Exporting version outputs and resolving common release-cycle issues Use the export-related action on the version page when the version has already been generated, reviewed, and checked for release readiness. Export is the final packaging step for the selected version, so it should happen only after the version page shows the release in its latest approved state. 1. Open the version page for the release you want to deliver. 2. Confirm that the latest generation has completed. 3. Verify that review and readiness work are complete. 4. Click the export-related action for that version. 5. Produce the release deliverable from the current version state. [SCREENSHOT: Version page showing export action after review completion] Before exporting, confirm that the version you are looking at is the same one your team reviewed. Then check for signs that the content is current: - the most recent generation finished successfully - comparison results match the intended release changes - screenshots reflect the latest interface - no review blockers remain visible A common issue is a mismatch between what the comparison view showed and what appears in the exported output. When that happens, the safest fix is to return to the version page, run **Generate** again, and then repeat the comparison before exporting. This helps ensure the export is based on the latest version content rather than an earlier build. Another common blocker is outdated screenshots. If the export includes old visuals, refresh the screenshots first and make sure the version still passes review. Incomplete review work is another reason to pause. If a version has not been fully reviewed, exporting too early can spread unfinished content to stakeholders. Documentation Managers usually own the final export decision, while Project Administrators may step in when export results do not reflect the expected project state. If you need more detail on export controls and validation, see [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options) and [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). ## Overview Managing a documentation version in Atloria is a release-cycle workflow, not a single action. The version page brings together the tasks your team uses to move a release from draft output to a shareable deliverable. From that page, you can generate fresh content, compare it with another version, review the results, check release readiness, update screenshots, and export the final output. The most important idea is sequence. A version usually moves through these stages: - open the correct version page - generate or refresh the version content - compare it against another version to confirm release changes - review the content for accuracy and completeness - update screenshots if the interface changed - export only after the version is clearly ready Each action supports the next one. Generation creates the latest output. Comparison shows what changed. Review confirms whether those changes are correct. Screenshot updates make sure visuals match the written guidance. Export turns that reviewed version into a release deliverable. This workflow also helps different roles stay aligned: - **Technical Writers** focus on content quality and screenshot accuracy - **Documentation Managers** use comparison, review, and readiness signals to decide whether the version can move forward - **Project Administrators** help resolve issues tied to setup, connected content, or release-sensitive behavior If your team skips steps or performs them out of order, problems usually appear later as mismatched exports, missing release updates, or screenshots that no longer fit the text. Keeping work centered on the version page reduces that risk and gives everyone a shared release record for the selected documentation version. The next document in this series is [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). ## Prerequisites Before you manage a documentation version across the release cycle in Atloria, make sure you have the right access and enough project context to work from the version page confidently. You should have: - an Atloria account and an active sign-in session - access to the project that contains the documentation version - permission to open project workspaces and version pages - a version already available in the documentation versions list - enough familiarity with the project’s release scope to recognize expected changes It also helps if the following are already in place: - the project setup is complete - the documentation content for the release has been updated - any connected project sources or release inputs your team relies on are current - reviewers know which version is being prepared for release If you are still getting started with account access, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If you need to understand how projects are organized before working with versions, see [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). For the smoothest release-cycle work, gather these inputs before you begin: - the version you are preparing - the earlier version you may want to compare against - any updated screenshots that reflect interface changes - reviewer feedback or release notes your team is using to validate the version Without these basics, you can still open a version page, but you may not be able to complete generation, comparison, review, or export in a meaningful order. The next step is [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). ## Opening the project settings workspace To work with project-level settings in Atloria, start by opening the project you want to manage from the main project area. These settings are meant for people who can administer that specific project, so you should have **Project Administrator** access or an equivalent permission level that allows you to change configuration. If you can open the project but do not see a **Settings** option in the project navigation, your access level may be limited to content work rather than project administration. 1. Open the target project from your project list or dashboard. 2. In the project navigation, select **Settings**. 3. Review the settings groups available on that screen before making changes. [SCREENSHOT: Project navigation with the Settings option highlighted] It helps to separate project settings from the Admin workspace. The Admin area is used for broader organization-wide tasks such as user access, analytics, and security review. Project settings only affect the documentation workspace you currently have open. If you need help with organization-wide controls, use [Using the Admin Workspace](doc:using-the-admin-workspace) or [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings). In this guide, you will work across three main groups of options: - **General project configuration** for the project’s core details - **Website options** for branding and public presentation - **Public delivery controls** for access and release behavior Some changes appear right away after you save them, especially updates tied to project labels and administrative views. Other changes may not be visible on the published documentation site until the next publish action, site refresh, or content sync. When you update website-facing settings, always plan to verify the live result after saving so you can tell whether the change was immediate or still waiting on a publish-related step. ## Configuring core project details The first settings area to review is the project’s core information. These details help your team identify the workspace inside Atloria and can also affect how the project is labeled in project lists, headers, and other internal views. Open the general project settings section and look for fields related to the project name, description, and identifying label. 1. In **Settings**, open the general project details section. 2. Update the **Project Name** so it matches the documentation set your team recognizes. 3. Edit the internal description if your team uses it to explain the project’s purpose, audience, or scope. 4. Review the project identifier or slug field if Atloria shows one for distinguishing the workspace. 5. Set the default language, locale, or regional options if those controls are available. 6. Click **Save**. [SCREENSHOT: General project settings with name, description, identifier, and language options] These fields usually serve different purposes, so it is worth checking each one carefully: | Setting | What it affects | |---|---| | **Project Name** | How the project appears in headers, lists, and internal navigation | | **Description** | Internal context for contributors and administrators | | **Identifier / Slug** | A distinct label used to separate this project from others | | **Default Language / Locale** | Dates, labels, and region-specific presentation | If Atloria includes visibility defaults for contributors, review who can view draft content and who can manage configuration. Keep in mind that these are project-level working rules, not public website settings. They shape how your internal team works inside the project. After saving, return to the project header or project list and confirm that the updated name and other visible metadata appear as expected. If the project title changes immediately in the workspace but not on the public site, that usually means the internal project record updated right away while the website-facing view still needs a publish-related refresh. ## Setting up website identity and public presentation Once the core project details are in place, move to the website settings area to control how the documentation appears to readers outside your editing team. This is where you define the public-facing identity of the project rather than the internal workspace label used by contributors. 1. In the project **Settings** screen, open the website-related section. 2. Enter the **Site Title** that should appear to readers on the published documentation site. 3. Add or update the **Public Description** so visitors understand what the documentation covers. 4. Review any branding text fields shown in the website settings panel. 5. Upload or replace website assets such as the logo, favicon, or other brand images. 6. Save your changes before moving to URL or homepage options. [SCREENSHOT: Website settings panel showing site title, public description, and branding assets] Use the internal project name and the public site title deliberately. In many teams, they are similar, but they do not always need to match. For example, the internal project name may help contributors distinguish workspaces, while the public site title should be clear to customers, partners, or other readers. Next, review the delivery location for the site. If Atloria shows a **Public URL**, **Custom Domain**, or **Site Path** field, confirm that it points to the address where this documentation should be available. Be careful when changing these values, because they affect where readers will find the site. You should also check homepage or landing-page options. If Atloria lets you choose which page, collection, or navigation entry acts as the public starting point, make sure the selected content is the one you want visitors to see first. This is especially important if your project contains multiple sections or audience-specific content paths. After saving, the branding and identity changes may be visible in previews right away, while domain or delivery changes may take longer to appear depending on how the site is published. ## Controlling navigation, indexing, and reader-facing options Website settings are not limited to branding. They also shape how readers move through your documentation and what information is visible around the content itself. In the website options area, look for controls related to navigation, search, indexing, and page details. 1. Open the navigation and reader experience section inside **Settings**. 2. Decide whether sections, categories, or the page tree should appear in the website menu. 3. Review search-related options and save the choices that match how discoverable the site should be. 4. Check reader-facing options such as footer links, support references, or update details shown on pages. 5. Save the changes and preview the site menu. [SCREENSHOT: Website options for navigation, search, and page display settings] These options usually affect the published reading experience in several ways: - **Navigation visibility** controls whether readers can browse by section or rely on direct links and search. - **Search and indexing settings** affect whether pages can be found inside the documentation site and, where allowed, by external search engines. - **Footer and support references** give readers extra context or a way to continue their journey. - **Update metadata visibility** determines whether published pages show information such as recent update details. This part of the settings screen changes how the site feels to readers without changing how your team writes and edits content inside Atloria. Your page structure, authoring workflow, and review process stay the same; what changes is how much of that structure is exposed on the public-facing site. If your team is planning audience-specific navigation or more advanced content organization, keep those broader decisions aligned with your project structure. For related planning guidance, see [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation) and [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences). ## Managing publication and access behavior After you finish the visual and navigation settings, review how the documentation site should be exposed to readers. In Atloria, publication and access controls determine whether the website is openly available, limited to certain readers, or kept out of view until the content is ready. 1. In the project **Settings** area, open the publication or access section. 2. Choose whether the website should be **public**, **restricted**, or **hidden**. 3. Review controls that exclude drafts, unpublished pages, or internal-only content from the website. 4. Check whether audience-based access, sign-in requirements, or password-style protection is available for this project. 5. Click **Save** and test the result in a browser window. [SCREENSHOT: Publication and access settings showing visibility choices and content exclusion options] A useful way to think about these choices is: | Access mode | What readers experience | |---|---| | **Public** | Visitors can open the published documentation without special access | | **Restricted** | Only approved or signed-in readers can view the site or certain content | | **Hidden** | The site is not meant for general viewing until release is ready | Also review what content is allowed to appear on the website. If Atloria provides options to exclude drafts, unpublished pages, or internal-only sections, use them carefully before release. These controls help separate active team work from reader-ready documentation. If your project uses audience access rules, those settings can further shape who sees what after publication. This is especially important when one project serves multiple reader groups. For deeper guidance on audience behavior, use [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access). Once saved, compare the site in two ways: as a signed-in team member and as a visitor who is not signed in. That side-by-side check is the quickest way to confirm whether the selected access mode is behaving as intended. ## Verifying the website configuration After saving project and website settings, take time to verify the result before sharing the documentation link with others. A quick review inside the project is not enough on its own. You should check both the preview and the published site experience. 1. Open the project’s website preview if it is available from the settings or project area. 2. Confirm the **Site Title**, logo, homepage, and navigation match the values you saved. 3. Open the public URL or custom domain in a separate browser tab. 4. Test the site again in an anonymous or private browser window. 5. Check search behavior, menu visibility, and page access for both signed-in and anonymous viewing. 6. If something looks wrong, return to **Settings**, adjust the option, and save again. [SCREENSHOT: Published documentation preview with title, logo, navigation, and homepage visible] During verification, focus on the details readers notice first: - The correct project is loading at the expected public address - The homepage opens to the intended landing page - Navigation shows the right sections and hides anything that should stay out of view - Search behaves as expected for published content - Restricted material is not visible to anonymous visitors If a change does not appear right away, the issue may not be the setting itself. In Atloria, some website updates can wait for a republish, a content sync, a cache refresh, or domain propagation before they become visible everywhere. If the project workspace shows the new values but the live site still shows older ones, test again after the next publish-related update. For a broader release check before sharing documentation externally, pair this review with [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release). ## Overview Project settings in Atloria bring together the controls that define how a documentation workspace is identified internally and how it appears when published to readers. The most important distinction to keep in mind is that some options are for your team’s day-to-day work inside the project, while others shape the public documentation site. The project settings workspace typically covers three practical areas: - **Core project details** such as the project name, description, and identifying labels - **Website options** such as site title, branding assets, homepage choice, and navigation behavior - **Publication and access controls** such as whether the site is public, restricted, or hidden These settings matter because they affect both contributor experience and reader experience. A clear project name helps your team find the right workspace. A well-defined site title and homepage help readers understand where they are as soon as the documentation opens. Navigation, search, and indexing settings influence how easily visitors can browse or discover content. Access controls help make sure unfinished or internal material does not appear before you are ready. You should also expect different timing for different changes. Internal labels often update immediately in project lists and headers after you click **Save**. Website-facing changes may appear in preview first and then reach the live site after a publish step or refresh cycle. If you are still getting familiar with project navigation before changing settings, review [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). The next step in this project settings sequence is [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). ## Prerequisites Before you change project settings in Atloria, make sure the project and your access are ready for administrative updates. These checks help you avoid saving changes in the wrong workspace or expecting public results before the project is prepared. - You can sign in to Atloria and open the correct project from your dashboard or project list. - Your account has **Project Administrator** access, or another permission level that allows changes in the project **Settings** area. - The project already exists and has enough setup completed for website-related options to make sense, such as a defined documentation structure or homepage content. - You know whether you are changing internal project details, public website presentation, or release visibility. - You have the branding materials you plan to use, such as the logo or favicon, if those upload options are available in the website settings. - You know which public address, custom domain, or site path the project should use, if Atloria shows those fields. - You are ready to test the result in both a signed-in session and an anonymous browser window after saving. A few preparation steps are especially helpful before editing: - Confirm the exact project name and public site title your team wants to use. - Decide which page or section should act as the homepage. - Agree on whether the site should be public, restricted, or hidden during setup. - Identify any drafts or internal-only content that must stay off the published site. If you still need to create the project or finish onboarding, start with [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) or [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). The next document in this sequence is [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). ## Preparing Your Workspace for Screenshot Capture Before you take any screenshot in Atloria, make sure you are working in the right place. If you are updating an existing documentation version, open that version first and confirm you are not editing a different project or release. If your screenshot is meant for an admin guide, open the matching admin area such as **Admin**, **Analytics & Insights**, or **Security & Audit**. If it belongs to a project guide, open the exact project workspace, page, or setup screen that the instructions describe. This avoids publishing an image from the wrong area of Atloria. Next, open the exact screen state you want readers to see. For example, if your instructions mention the **Login** page, show the page with the **Email** and **Password** fields visible. If you are documenting account creation, open the registration screen with the **Name**, **Email**, and **Password** fields on display. If the page should show a result after signing in, capture the destination screen only after the correct page has loaded. Keep your browser view consistent across related images. Use the same zoom level, similar window width, and the same visible navigation whenever possible. If one screenshot shows the left navigation and another hides it, the page can feel inconsistent to readers. Try to keep page titles, section headers, and active menu items visible so the reader can tell where they are in Atloria. Before capturing, clean up anything that should not appear in published documentation: - Close unrelated browser tabs - Hide pop-up notifications - Remove personal bookmarks from view if possible - Avoid showing temporary test names that do not belong in documentation - Check for environment markers that could confuse readers [SCREENSHOT: Atloria page prepared for capture with the correct workspace, visible page title, and clean browser window] ## Capturing Screenshots That Match the Documented Workflow When you capture a screenshot, show the exact moment the written step describes. If the instruction tells the reader to open **Analytics & Insights**, the image should show that page header and its visible content. If the instruction tells the reader to review **Security & Audit**, the screenshot should show that screen, not a different admin card or a later result. The closer the image matches the sentence beside it, the easier the page is to follow. 1. Open the screen the step refers to and wait until the page is fully loaded. 2. Make sure the key visual cues are visible, such as the page title, active menu item, form fields, dialog box, or status message. 3. Capture the whole area the reader needs to understand the step. In many cases, that means including the page heading and the section where the action happens. 4. If one image cannot show the full action clearly, take more than one screenshot for the sequence. Use focused images for important actions. A full-page image works well when readers need orientation, such as seeing the **Admin** area or a project workspace. A tighter image works better when the reader needs to notice a specific control, such as the **Email** field on the sign-in page, the **Password** field on the registration page, or a “coming soon” notice on a feature page. Re-capture screenshots whenever Atloria’s labels, buttons, or layout change. If a page title has been renamed, a card moved, or a section redesigned, do not keep an older image just because it is available. Readers compare the screenshot to the live screen, and even small differences can make them hesitate. For longer procedures, use sequential captures: 1. The starting screen 2. The action in progress 3. The result after the action [SCREENSHOT: Example sequence showing a user moving from the Login page to the main Atloria workspace] ## Saving and Naming Screenshot Files for Versioned Documentation A clear file-saving routine makes screenshot updates much easier, especially when the same page is revised across multiple documentation versions. Save each screenshot in the asset location your team already uses for that page or version. Keep screenshots close to the documentation they support so reviewers can tell which image belongs to which topic. If your team separates assets by project, version, or document section, follow that structure consistently instead of creating one-off folders. Use file names that describe what the image shows. Good names help reviewers understand the screenshot before opening it and make replacement work faster later. Include three pieces of information in the name: | Include in the file name | Example purpose | |---|---| | Page or topic | login, admin-dashboard, analytics | | Screen or action | form-visible, users-card, security-notice | | Version or release marker | v1, v2, april-update | A name such as `login-form-visible-v2` is much easier to manage than a generic name like `image1` or `screenshot-final-final`. Keep new screenshots separate from replacement screenshots when you are preparing a review. If one image updates an existing step and another adds a brand-new step, reviewers should be able to tell the difference quickly. This is especially helpful when a page update includes both rewritten text and refreshed visuals. It also helps to keep two copies when your team uses cropping or annotations: - The original full capture - The publication-ready image used on the page The original capture is useful when you need to adjust the crop later without taking the screenshot again. This saves time when the text changes but the screen itself is still current. [SCREENSHOT: Example screenshot folder showing organized names by topic, action, and version] ## Reviewing Screenshots Before Adding Them to a Page Before you place a screenshot into a documentation page, compare it directly with the wording on the page. The labels in the image should match the labels in the instructions. If the page says readers should click **Analytics & Insights**, the screenshot should show that exact title. If the instructions mention **Security & Audit**, the image should not show a different heading or an older label. This quick comparison catches many common problems before review. 1. Read the instruction beside the screenshot location. 2. Open the image and confirm the visible page title, menu name, field labels, and buttons match the text. 3. Check that the screenshot shows the correct point in the workflow. 4. Review the image at the size readers will likely see on the page. Timing matters as much as labels. A screenshot taken too early or too late can confuse the reader. For example, if the text explains what appears after a successful sign-in, the image should show the destination workspace, not the login form. If the text explains a page before the user takes action, the image should not show a later result. Look carefully for information that should not be published. Remove or obscure anything that does not belong in shared documentation, including: - Personal names if they are not intended for documentation - Temporary records created only for testing - Internal environment markers - Private project details - Data that does not match the example workflow Finally, check readability. After cropping or resizing, text in menus, cards, dialogs, and table headers should still be easy to read. If readers must zoom in heavily to understand the image, capture it again with better framing. [SCREENSHOT: Review comparison between page instructions and a screenshot showing matching labels and screen state] ## Adding Screenshots to Documentation and Change Workflows Place each screenshot as close as possible to the step it supports. Readers should not need to scroll far to match the written instruction with the image. If a screenshot explains how to sign in, place it beside the step that mentions the **Email** and **Password** fields. If it supports an admin task, place it near the step where the reader opens **Admin**, chooses a card such as **Users & Permissions**, or reviews a page like **Analytics & Insights**. 1. Open the documentation page you are updating. 2. Find the step where the screenshot adds clarity. 3. Insert the image immediately before or after that step. 4. Preview the page to confirm the image size and placement make sense in the flow. 5. Save the page and include the screenshot in the same update as the related text changes. Add a useful caption or alt text when your team’s page format supports it. Describe the exact screen or action shown, not a vague phrase. For example, identify the image as the **Login** page with **Email** and **Password** fields visible, or the **Analytics & Insights** page showing its current notice. This helps both reviewers and readers understand why the image is there. When you revise an existing page, make sure the new screenshot replaces the old one in the current documentation version. Do not leave older image references in place if the page text has already been updated. A page with current wording and outdated visuals is harder to trust than a page with no screenshot at all. Keep screenshot changes inside the same review or version workflow as the text update. That way, approvers can check the wording and the visual evidence together. This is especially important when a release changes navigation, page names, or workflow order. For related guidance on version work, see [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle). ## Fixing Common Screenshot Problems The most common screenshot problem is an image that no longer matches the current Atloria interface. This often happens after a release changes navigation labels, page headers, or card names. If a screenshot shows an older layout than the one readers now see, replace it rather than trying to explain the difference in the text. A fresh image is usually clearer than a note about a past design. Another frequent issue is poor image quality. If the screenshot looks blurry, too small, or cropped so tightly that readers cannot see where they are, take it again. A good screenshot should make field labels, headings, and action areas readable without guesswork. This matters most on pages with multiple cards, side navigation, or notices that depend on visible context. Use this table to match the problem to the likely fix: | Problem | What to check | What to do | |---|---|---| | Outdated page layout | Page title, menu labels, card names | Re-capture the current Atloria screen | | Blurry or unreadable text | Browser zoom, image scaling, crop size | Capture again with clearer framing | | Sensitive information visible | Names, records, environment details | Remove, mask, or replace the image | | Broken image on the page | Asset name, file location, version update | Re-link the correct file and save again | If an image does not appear in the page preview or version review, check whether the file was renamed, moved, or left out of the same update as the page content. Broken references are often caused by a mismatch between the image name used in the page and the actual saved file name. If screenshots are missing across versions or shared workflows, the next guide goes deeper into library-level organization: [Managing Enterprise Screenshot Libraries](doc:managing-enterprise-screenshot-libraries). ## Overview Managing screenshots in Atloria means more than taking a picture of a screen. You are creating visual proof that a page, button, form, or workflow looks the way your documentation says it does. Good screenshots help readers confirm they are on the right page, especially in areas such as **Login**, **Register**, **Admin**, **Analytics & Insights**, and **Security & Audit**. Poor screenshots do the opposite: they make current instructions look outdated even when the text is correct. This guide focuses on the full screenshot workflow inside documentation work: preparing the right Atloria workspace, capturing the correct screen state, saving files in a way that supports versioned documentation, reviewing images for accuracy, and adding them to the same change process as the text update. It also covers common problems such as outdated navigation, unreadable crops, and broken image references. Use this guide when you are: - Updating a documentation page after an Atloria interface change - Adding screenshots to a new how-to page - Refreshing visuals for a new documentation version - Reviewing whether screenshots still match the current release - Fixing image issues before approval or publishing If you need help with the basics of signing in or creating an account before working in Atloria, see [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account). If you need broader project context before updating documentation pages, [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) is a useful companion. ## Prerequisites Before you start updating screenshots for a documentation page in Atloria, make sure you have access to the workspace and content area where the change belongs. You do not need advanced setup knowledge, but you do need to be able to open the correct project, documentation version, or admin area that the screenshot will represent. If you cannot reach the right page, your screenshot may show the wrong context or an incomplete workflow. Have the following ready before you begin: - Access to the correct Atloria account and workspace - Permission to open the page or area you are documenting - The documentation page or draft that will receive the screenshot - A clear understanding of which workflow moment needs to be shown - A browser window prepared for clean, consistent captures It also helps to know whether you are documenting a public-facing workflow or an internal workspace view. For example, a screenshot of the **Login** page, **Register** page, or a project workspace should be captured differently from an admin-only view such as **Analytics & Insights** or **Security & Audit**. Open the exact destination before you capture anything. If you are working as part of a version update, confirm which release or draft is active so your images match the same review cycle as the text. For guidance on related page editing work, see [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages). If you are troubleshooting sign-in before you can reach the right screen, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). ## Opening the administrative user management pages To work with user access in Atloria, start by signing in with an account that can open the **Admin** workspace. If you are not signed in yet, go to the **Login** page, enter your **Email** and **Password**, and click **Sign In**. If the details are incorrect, Atloria shows the message **Invalid email or password**. If sign-in succeeds, Atloria opens the main authenticated area. From there, open the **Admin** area and look for the **Users & Permissions** card. This card is the entry point for reviewing people, roles, and access decisions. The card label and description make it clear that this is where you manage users, roles, and access control. Click **Users & Permissions** to open the user management pages. On the user management screen, focus on the main working areas: - A **user list** or table showing existing accounts - A **search field** for finding a specific person - **Filter controls** that help narrow the list - A **role** or **access** column that shows each person’s current level - A per-user **action menu** or row action that opens more details These are the controls you will use most often when reviewing or changing access. This area is usually used by people who already have administrative responsibility in Atloria. In most teams, that means: - A **Project Administrator** who decides who can manage projects, settings, or team access - A **Documentation Manager** who reviews who should maintain documentation content and related workspaces If you need a broader tour of the admin area before making changes, see [Using the Admin Workspace](doc:using-the-admin-workspace). [SCREENSHOT: Admin workspace showing the Users & Permissions card] ## Reviewing users and understanding their current access Once you are on the user management page, begin with the search and list tools before opening any record. The search field is the fastest way to find one person in a long list. Enter the person’s **name**, **email address**, or **username** if that option appears in your Atloria workspace. As you type, review the matching rows in the user table and confirm you have the correct person before opening their record. If the list is still too broad, use the available filters. Depending on what your Atloria workspace shows, you may be able to narrow the table by: - **Status** - **Role** - **Administrative access** - Other access-related categories shown on the page These filters are especially useful when you are reviewing all administrators, all documentation-focused users, or only active accounts. After locating the correct person, open their user record from the list. This usually happens by clicking the row, the person’s name, or an action option in that row. On the user details page, review the visible profile and access information carefully. Look for fields, labels, badges, or sections that show: | What to review | What it tells you | |---|---| | Profile details | Confirms you are editing the right person | | Assigned role | Shows the main access level currently applied | | Administrative setting | Indicates whether the user has elevated rights | | Permission-related settings | Clarifies what management tasks the user can perform | Use these details to decide whether the person has standard access, broader administrative responsibility, or a documentation-focused role. If you are comparing this with broader admin responsibilities, [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings) can help you understand where those permissions are used. [SCREENSHOT: User list with search, filters, and role column] ## Interpreting administrative responsibilities before changing permissions Before you change anyone’s access, pause on the user details page and decide what that person actually needs to do in Atloria. The most important distinction is between **general access** and **administrative permissions**. General access lets someone sign in and work in the areas already available to them. Administrative permissions go further and can allow someone to manage other users, review broader workspace information, or change settings that affect more than their own work. A **Project Administrator** is usually the right choice when the person needs to make decisions that affect project setup, project-level controls, or team access around project work. A **Documentation Manager** is a better fit when the person’s main responsibility is maintaining documentation content, reviewing documentation structure, or helping keep published information accurate without taking on wider administrative control. When you review the user’s current role or access fields, think about the effect of increasing that access. A higher level may give the person broader visibility into records, more control over team settings, or the ability to change access for others. That is why the user management pages should be treated as a decision point, not just a form to update quickly. Use simple decision criteria before approving a change: - Does the user need to manage people, settings, or project administration? - Does the user only need to maintain documentation content? - Does the requested role give more visibility than the person actually needs? - Is someone else already assigned to the same administrative responsibility? Reviewing these questions first helps avoid unnecessary overlap in admin responsibilities. For related guidance on role decisions, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls) and [Using the Admin Workspace](doc:using-the-admin-workspace). ## Updating roles and permission-related settings for a user When you are ready to make a change, stay on the individual user details page and use the visible role or access controls there. In Atloria, this is the safest place to update a person’s permissions because you can review their current details and the new setting in the same view. 1. Open the user’s record from the **Users & Permissions** page. 2. Find the editable **Role**, **Administrative access**, or similar access assignment control shown on the page. 3. Select the new role or updated access level that matches the person’s responsibilities. 4. If Atloria shows a confirmation step, review the change carefully and confirm it. 5. Click **Save** to store the update. After saving, do not leave the page immediately. First, verify that the updated values now appear in the user details view. Check the same field you changed and make sure the new role, badge, or access label is visible. If the page includes multiple access-related sections, confirm the change appears consistently across those sections. Next, return to the main user list. Find the same person again using the search field if needed, and confirm the updated access level appears in the table. Depending on your Atloria workspace, this may show in: - The **Role** column - An **Access** badge - An **Admin** indicator - Another permission-related label in the row This final check matters because it confirms the update is reflected both in the full record and in the list view used by other administrators. If your team also manages broader admin settings, [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings) is a useful companion reference. [SCREENSHOT: User details page with editable role or access setting and Save button] ## Handling common permission decisions across administrator and documentation roles Most access requests fall into a few repeat patterns, and the user management pages in Atloria give you enough information to choose the right outcome if you review the visible role and access fields carefully. If someone needs to manage projects, make decisions that affect project setup, or help control who can work in project areas, that request usually points to **Project Administrator** access. If someone mainly writes, organizes, or maintains documentation and does not need broader control over users or settings, **Documentation Manager** is usually the better fit. When a person only needs to view project or content records, keep them at **standard access** unless the user details page clearly shows that a higher role is required for the tasks they must perform. Before assigning any elevated role, review the person’s current record first. Do not assume a new request means they need another layer of access. A user may already have enough permissions through an existing role shown in the details page or user table. Adding more responsibility than necessary can create overlap, especially if several people already hold administrative rights. Use this decision guide while reviewing the visible fields on the user page: | Request | Best access outcome | |---|---| | Manage project-level decisions and broader team actions | Project Administrator | | Maintain documentation content and related documentation work | Documentation Manager | | View records without changing administrative settings | Standard access | Keep this checklist in mind before you save: - Review the user’s current **Role** or **Access** field first - Match the role to the person’s actual day-to-day work - Avoid assigning elevated access just for visibility - Check whether another administrator already covers the same responsibility - Save only after the selected role clearly matches the request For more role-specific context, see [Using the Admin Workspace](doc:using-the-admin-workspace) and [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings). ## Fixing common issues when access changes do not behave as expected If a user search or permission update does not behave the way you expect, start with the controls visible on the user management pages before assuming the change failed. When a user does not appear in search results, first check the search term. Try the person’s full name, then their email address, and then any username shown in your Atloria workspace. If the person still does not appear, clear any active filters. A **Status**, **Role**, or **Administrative access** filter can hide valid results even when the search term is correct. Also confirm you are working in the correct administrative area for your current scope. If you changed a role and do not see the update after clicking **Save**, refresh the user details page and check the same access field again. Then return to the user list and confirm the updated role appears there as well. Looking in both places helps you tell the difference between a display delay and a change that did not apply. If you cannot edit a user at all, review your own access. In Atloria, not every signed-in person can manage other users. If the page does not show editable role controls or you cannot save changes, your current account may not have enough administrative rights for user management. If a user still cannot perform the tasks they need after an access change, compare the assigned role on their record with the responsibility they were meant to receive. For example: - If they need broader project control, confirm they were given **Project Administrator** - If they only need documentation maintenance access, confirm they were assigned **Documentation Manager** - If they only needed visibility, confirm no broader role was expected For related admin troubleshooting, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls) and [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Overview Managing user access in Atloria centers on one main workflow: open the **Admin** area, go to **Users & Permissions**, review the person’s current record, decide whether their responsibilities call for standard access or elevated access, and then save the updated role if needed. The user list helps you work quickly with search, filters, and role indicators, while the individual user page gives you the detail needed to make a careful permission decision. The most important thing to watch is the difference between users who need broad administrative control and users who only need documentation-focused responsibility. In practice, this often means choosing between a **Project Administrator** role and a **Documentation Manager** role. The correct choice depends on what the person must do in Atloria, not simply on how often they use it. As you work through access reviews, keep your attention on the visible fields and labels in the user pages: - The **user table** for quick comparison across accounts - The **search** and **filter** controls for narrowing the list - The **Role** or **Access** values shown in each record - The **Save** action used to confirm updates This area is especially useful during onboarding, team changes, and periodic access reviews. It is also the right place to confirm whether someone already has enough responsibility before adding more. If you need broader admin context around how these permissions fit into the rest of Atloria, continue with [Using the Admin Workspace](doc:using-the-admin-workspace) or [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings). ## Prerequisites Before you start changing user access in Atloria, make sure a few basics are in place. These checks help you avoid opening the wrong area or making permission decisions without enough context. - You can sign in to Atloria with a valid **Email** and **Password** - Your account can open the **Admin** workspace - You can access the **Users & Permissions** area from the admin page - You know which person’s access you need to review or update - You understand whether the request is for standard access, **Project Administrator**, or **Documentation Manager** responsibilities It also helps to gather the reason for the request before you open the user record. For example, you may be responding to a new team member setup, a change in project ownership, or a request for documentation maintenance access. Having that reason in mind makes it easier to choose the correct role when you reach the editable access fields. Before saving any change, confirm you can answer these questions from the user management pages: - Is this the correct user record? - What role does the person have now? - Does the requested access match their actual work in Atloria? - Would the new role give broader control than necessary? If you are not yet comfortable moving through Atloria’s sign-in and admin entry points, review [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) and [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). If you need help deciding how admin permissions fit into the wider workspace, [Using the Admin Workspace](doc:using-the-admin-workspace) is the best next reference. ## Opening analytics from the admin area To reach Atloria’s administrative monitoring screens, start from the signed-in workspace and open the **Admin** area. This area is intended for people who manage Atloria beyond a single project, such as organization administrators, Project Administrators, and Documentation Managers with admin-level access. On the main **Admin** screen, look for the card labeled **Analytics**. The card includes the description **Usage statistics and insights**, which helps confirm you are opening the correct section rather than a project-specific dashboard or a document workspace. 1. Sign in to Atloria with an account that can open the **Admin** area. 2. Open **Admin** from the main navigation. 3. On the **Admin** screen, find the **Analytics** card. 4. Click **Analytics** to open **Analytics & Insights**. At the top of the page, you will see the heading **Analytics & Insights** with the subtitle **Usage statistics and performance metrics**. This is the admin-level monitoring area for reviewing activity across Atloria, not just within one project. Depending on what is available in your environment, this screen is where you would expect to review date controls, summary cards, charts, and activity listings that help you monitor usage patterns and recent changes. [SCREENSHOT: Admin screen showing the Analytics card and the Analytics & Insights page header] If you usually work inside project pages such as documents, versions, or project settings, this screen will feel different. Project screens focus on one workspace at a time. The **Analytics & Insights** area is meant for broader monitoring, so administrators can look across teams and projects instead of checking each project separately. If you need help finding the **Admin** workspace first, see [Using the Admin Workspace](doc:using-the-admin-workspace). ## Reading platform activity at a glance When you open **Analytics & Insights**, begin with the top section of the page. In Atloria, this area is designed to give administrators a quick read on overall usage and performance trends before they drill into details. The most important items to look for are the summary cards and any chart area tied to the selected time period. These top-level visuals help you answer simple questions quickly: Is usage active? Has activity increased recently? Are there any obvious drops or spikes? 1. Open **Admin > Analytics**. 2. Look first at the summary area near the top of **Analytics & Insights**. 3. Check the current date range or reporting window if one is shown. 4. Review the totals and any visible trend direction before opening detailed views. 5. Compare the chart pattern with the summary totals to judge whether the change is brief or sustained. Use the totals and trend signals together rather than reading one item in isolation. For example, a high total paired with a short spike can mean a burst of activity during a release or review period. A steady chart with consistent totals usually points to regular adoption. A flat or low-activity period may suggest that teams are inactive, between releases, or not using a feature as often as expected. High-level signals that are especially useful include: - Noticeable increases in usage over a recent period - Long flat periods with little or no activity - Sudden spikes that stand out from earlier dates - Totals that remain high across multiple periods instead of one short burst If your team reports on Atloria usage regularly, keep the same date window each time you review the page. That makes it easier to spot meaningful changes instead of reacting to normal daily variation. ## Analyzing usage patterns across Atloria After the top-level review, narrow your focus to understand where activity is coming from. In Atloria, the admin analytics area is intended to support broader usage analysis, so look for filters, grouped chart segments, legends, or tables that break activity into smaller parts. These controls help you move from “What is happening overall?” to “Which area is driving the change?” 1. Open **Admin > Analytics**. 2. Set the date range you want to review. 3. Apply any available filters, such as project-related scope or other admin-level groupings. 4. Read the chart segments or grouped totals to see which areas account for the most activity. 5. Use any table or legend below the chart to compare high-usage and low-usage areas side by side. When you compare segments, focus on relative weight rather than just raw totals. A large section in a chart or a repeated high count in a table usually points to the busiest area of work. Smaller segments may show underused areas, newer teams, or parts of Atloria that only a few users visit. If the page includes grouped metrics, read them in the context of the selected date range so you do not compare one short period with a longer one by mistake. Different admin roles often use the same analytics view for different questions: - **Documentation Managers** often look for patterns tied to documentation work, such as whether teams are actively using document-related areas. - **Project Administrators** often focus on broader operational usage across multiple projects or workspaces. - **Organization administrators** may use the same charts to identify adoption differences between teams. [SCREENSHOT: Analytics page with filters, chart segments, and a legend or table showing usage distribution] If you need project-level context after spotting a pattern here, continue in the relevant project workspace rather than trying to answer every question from the admin view alone. ## Investigating recent administrative activity Analytics totals are useful for spotting patterns, but activity listings are what help you investigate what actually happened. In Atloria, use the activity-focused area of the admin workspace to review recent actions and narrow down a specific time window or event type. This is especially helpful when you need to understand whether a spike in usage reflects normal work, a release cycle, a burst of document updates, or a cluster of administrative changes. 1. Open **Admin** and go to the analytics or activity-focused view available to you. 2. Find the recent activity list, event table, or similar activity panel. 3. Set the date range to the period you want to investigate. 4. Apply any available filters or search options to narrow the list. 5. Scan the newest entries first to identify the most recent actions. 6. Open an individual entry if Atloria lets you view more detail. As you review the list, pay attention to three things: when the action happened, what kind of action it was, and whether it appears to match the trend you saw in the charts. If a chart shows a sudden increase, the activity list may reveal a cluster of related actions during the same period. If a table looks unexpectedly quiet, the activity list can confirm whether there was truly little activity or whether your filters are too narrow. Useful ways to narrow the list include: - Choosing a shorter date window - Filtering to a specific type of activity - Searching for a related item or area, if search is available - Reviewing only the newest entries first If Atloria opens a detail view for an activity entry, use it to inspect the related item, the person who performed the action, or the event details shown on screen. For broader audit review, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls). ## Using analytics to support operational decisions Admin analytics are most useful when you turn what you see into a repeatable review habit. In Atloria, the **Analytics & Insights** area helps administrators move beyond one-time checking and into ongoing operational monitoring. Instead of only opening analytics when something seems wrong, use the same views on a regular schedule to track adoption, workload, and unusual changes. 1. Choose a standard review window, such as the same recent period each time you check analytics. 2. Compare current totals and charts with an earlier period using the date range control. 3. Note whether activity is growing, staying steady, or declining. 4. Check the recent activity list when a spike or drop stands out. 5. Match unusual changes with visible work in Atloria, such as project updates, documentation work, or release-related activity. 6. Share the most relevant findings with the right audience inside your team. A practical way to use these screens is to separate monitoring by role: | Role | Most useful view | What to look for | |---|---|---| | Project Administrator | Summary metrics, grouped usage, recent activity | Cross-project workload, adoption changes, unusual operational activity | | Documentation Manager | Usage patterns tied to documentation work | Engagement with documentation-related areas, active versus quiet periods | | Organization administrator | High-level analytics and activity review | Overall health, broad usage trends, team-level differences | Use recurring comparisons to avoid overreacting to one busy day. A short spike may line up with a release, a publishing push, or a concentrated review cycle. A longer decline across repeated date ranges may point to reduced adoption or a pause in project work. If you need to connect admin findings with project-level details, continue with [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). ## Resolving missing or confusing analytics data If cards, charts, or activity tables look empty or inconsistent, start with the visible controls on the page before assuming data is missing. In Atloria, reporting screens are usually shaped by the selected date range and any filters currently applied. A narrow date window, the wrong scope, or an inactive filter can make a healthy workspace appear empty. Check these items first: - The selected date range is not too narrow - Any project or grouped filter is set to the scope you expect - You are looking at the correct admin screen rather than a project-specific page - Your account can access the **Admin** area and the **Analytics** section - The page has been refreshed after recent activity If totals seem incorrect, compare the summary cards with the chart and the activity list. When all three disagree, a filter or date mismatch is often the cause. For example, a chart may reflect one period while the activity table is narrowed further by an additional filter. Clear filters one at a time and watch which result changes. That is often the fastest way to find the setting causing confusion. 1. Recheck the date range shown on the analytics page. 2. Clear or adjust filters that limit the results. 3. Confirm you are in **Admin > Analytics**. 4. Refresh the page if recent work is not yet visible. 5. Reopen the view and compare the summary area with the activity list again. At the moment, Atloria’s **Analytics & Insights** page is presented as a coming-soon area, so some environments may show the page header without full reporting content. If you can open the page but do not see working charts or tables yet, that can be expected in the current release rather than a problem with your account. ## Overview Atloria includes an **Admin** workspace for people who need visibility beyond a single project. Within that area, the **Analytics** section is labeled **Analytics & Insights** and is intended for reviewing **Usage statistics and performance metrics**. This is the place administrators look for cross-platform monitoring rather than project-by-project checking. It is especially relevant when you want to understand overall usage patterns, compare recent activity periods, or investigate changes that affect multiple teams. From the current interface, you can identify the analytics area by its dedicated **Analytics** card in the **Admin** screen and the **Analytics & Insights** page header after opening it. The screen is positioned as an administrative reporting space, separate from project workspaces such as documents, versions, and project settings. That distinction matters because project pages answer local questions about one workspace, while the admin analytics area is meant to support broader operational review. The current release also indicates that this area is still being introduced. If you open **Analytics & Insights**, you may see a coming-soon style message rather than a fully populated reporting workspace. Even so, the navigation path and page naming already establish where administrators will go to monitor usage and performance metrics as the feature becomes available. This document focuses on how to approach that admin analytics area: how to open it, what kinds of information to expect there, how to interpret summary signals and recent activity, and what to check when results appear empty or unclear. For related admin tasks, you may also want [Using the Admin Workspace](doc:using-the-admin-workspace) and [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings). ## Prerequisites Before you try to monitor analytics or recent activity in Atloria, make sure the following conditions are met: - You can sign in to Atloria successfully. - Your account can open the **Admin** area. - You can see the **Analytics** card inside the **Admin** workspace. - You understand whether you need a cross-platform admin view or a project-specific view. - You know the date period you want to review so you can interpret totals consistently. A few practical checks help avoid confusion before you begin: - If you cannot reach the **Admin** area at all, review your access with an administrator who manages users and permissions. - If you only need information for one project, a project workspace may be more useful than the admin analytics area. - If you are comparing usage over time, decide on a consistent reporting window before you start. - If you expect to investigate recent changes, be ready to review both summary metrics and activity listings together. Atloria’s current analytics page may appear as a placeholder in some environments. That means you can still confirm the correct navigation path and screen name, but the charts, metrics, or activity details may not yet be fully available. If that is what you see, it does not necessarily mean anything is wrong with your account. If you need help getting into Atloria before using the admin area, start with [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). ## Opening the AI usage dashboard and understanding what it measures In Atloria, start from the authenticated workspace and open the **Admin** area. On the main **Admin** screen, look for the **Analytics** card and open it to reach **Analytics & Insights**. This screen is presented as the place for **Usage statistics and performance metrics**, so it is the natural starting point when you want a high-level view of AI activity across your organization. [SCREENSHOT: Admin screen showing the Analytics card] 1. Open **Admin** from the main workspace navigation. 2. Select **Analytics**. 3. Review the **Analytics & Insights** header to confirm you are in the reporting area. 4. Look for summary sections that show overall activity for the selected period, such as total requests, usage totals, and recent activity when available. When you work with AI usage reporting, it helps to separate two kinds of information: - **Dashboard totals and charts** show the big picture for a selected time period. - **Request history** shows one AI interaction at a time. Use the dashboard when you want to answer questions like: - Which team is using Atloria AI features most? - Did usage increase this week? - Which workspace or feature is driving the largest share of activity? Open request history when you need to inspect a specific interaction, such as a failed request, an unusually expensive request, or a response that looked incorrect. If a date range picker is available on your AI usage screen, changing it updates the totals and charts together. Common presets usually include: - **Today** - **Last 7 days** - **Current month** These presets are useful for different review habits. **Today** helps with live monitoring, **Last 7 days** helps spot short-term changes, and **Current month** helps with budget and team reporting. Stay on the dashboard when you need trends and totals. Move into request history when you need evidence behind those numbers. ## Filtering usage data to review teams, users, and time periods Filtering is what turns a broad AI usage report into something you can act on. In Atloria, once you are in the reporting area, use the filter controls shown on the page to narrow the results to the people, projects, or time periods you want to review. Depending on your access level, you may be able to filter by team, project, user, model, or request status. 1. Open the AI usage reporting area from **Admin**. 2. Set the **Date range** first so every total and chart reflects the same period. 3. Apply a team, project, or user filter to reduce the results to the group you want to review. 4. If available, add a model or status filter to focus on a specific type of AI request. 5. Review the updated totals, charts, and lists after each filter change. A good habit is to change one filter at a time. That makes it easier to understand why the numbers changed. For example, if overall usage looks high, switch from **Current month** to **Last 7 days** and then narrow the view to one team. This helps you tell the difference between a normal monthly total and a short-term spike. Search fields are especially useful when a support lead needs to isolate one person’s activity. Enter the user’s name or email in the search box, then combine that with the date range to find the exact period in question. If Atloria offers saved filter combinations in your workspace, use them for recurring reviews such as: - Weekly team usage review - Monthly cost review - Recent failed requests - Activity for one project workspace Sorting helps when the list is long. Sort by: - **Highest usage** to find cost drivers - **Most requests** to find heavy activity - **Latest activity** to investigate a recent issue Use filters for comparison as well. Review one time window, note the totals, then switch to another window and compare the trend chart or grouped totals. This is often the fastest way to spot unusual growth or a sudden drop in request volume. ## Inspecting request history for prompts, responses, and outcomes When the dashboard tells you something changed, request history helps you find out why. In Atloria, open the request history list from the AI usage area and review the records line by line. This view is meant for auditing and troubleshooting, so it focuses on individual interactions instead of overall totals. [SCREENSHOT: Request history list with columns for time, user, status, and usage] 1. Open the AI usage area from **Admin**. 2. Switch from the summary view to the **Request history** list. 3. Use the search box or filters to narrow the list before opening individual records. 4. Click a request row to open its detail panel or detail page. 5. Review the prompt, response, status, timing, and usage values for that request. The request list commonly includes fields like these: | Field | What it helps you verify | |---|---| | **Timestamp** | When the request happened | | **User** | Who submitted or triggered it | | **Model** | Which AI option handled the request | | **Feature** | Where in Atloria the request came from | | **Status** | Whether it succeeded or failed | | **Duration** | How long it took | | **Cost** or **Token usage** | How much usage the request consumed | Once you open a request, focus on three parts of the record: - The **submitted prompt** - The **generated response** - The request details around it, such as status, time, and feature source Status values matter during investigations: - **Success** means the request completed normally. - **Error** means it failed and needs review. - **Timeout** means it took too long and did not finish in time. - **Blocked** means it was stopped by a rule or restriction. - **Retried** means Atloria attempted the request again after a problem. Use pagination when the list spans many pages, especially for busy teams. If you cannot find a request quickly, combine search, date range, and status filters before moving through pages manually. That approach is much faster than scanning the full history. ## Using history records to manage cost, quality, and oversight AI usage records are most valuable when you use them to make decisions. In Atloria, request history is not just a log of past activity. It helps administrators and team leads control spending, improve output quality, and maintain accountability across teams and workspaces. 1. Start with the dashboard to identify a spike, trend, or unusually active group. 2. Open request history for the same date range and filters. 3. Sort or filter by the highest cost, highest usage, or repeated failures. 4. Open individual records that stand out. 5. Use those records to decide whether the issue is cost-related, quality-related, or operational. For cost review, look at per-request usage values such as **Cost** or **Token usage**, along with the **Model** and **Feature** columns. Expensive patterns often appear as repeated high-usage requests, a sudden increase from one team, or a workflow that uses a more costly model more often than expected. That is the point where an administrator may decide to tighten usage rules or review AI settings with the team responsible. For quality review, open the request details and compare the **prompt** with the **response**. Team leads often look for: - Repeated retries for the same task - Low-quality or off-topic responses - Prompts that are too vague to produce reliable results - Misuse patterns, such as unnecessary repeated generation For oversight, the most important fields are **Timestamp**, **User**, **Team**, **Feature**, and **Status**. Together, these create an activity trail that shows who did what and when. That makes request history useful during internal reviews, support follow-up, and audit preparation. Use aggregate dashboard trends for planning questions, such as whether usage is growing month over month. Use individual request records when you need to understand a specific incident, review one user’s activity, or confirm what happened during a support case. ## Exporting and sharing usage records for reporting and audits When you need to report on AI activity outside the screen, use the export option from the usage dashboard or request history view. In Atloria, exports are most useful after you have already narrowed the data to the exact scope you want. That way, the file matches what you are reviewing on screen and does not include unrelated records. 1. Open the AI usage dashboard or **Request history**. 2. Apply the exact **Date range**, team, project, user, model, and status filters you need. 3. Confirm the visible totals or list count before exporting. 4. Select the **Export** action. 5. Download the file and review the first few rows to confirm it matches the filtered view. Before exporting, preserve the current filter state as carefully as possible. If Atloria provides visible filter chips, selected dropdown values, or a saved view, verify those settings before you click **Export**. This is especially important for finance reviews and audit requests, where a small filter difference can change the totals significantly. For most reporting needs, include fields like these in the export: | Field | Why it matters | |---|---| | **User** | Identifies who triggered the request | | **Team** | Groups activity for management review | | **Model** | Shows which AI option was used | | **Timestamp** | Places the activity in time | | **Status** | Distinguishes successful and failed requests | | **Cost** or **Token usage** | Supports budget and usage analysis | | **Feature** | Shows where in Atloria the request originated | Be careful when sharing exports that include **prompt** and **response** content. Those records may contain sensitive operational details or customer-related text. Share only the fields needed for the review. For example: - Finance usually needs usage totals, timestamps, teams, and cost-related values. - Support teams often need status, duration, feature, and selected prompt or response examples. - Compliance reviews may need user, timestamp, status, and full activity scope. If you need broader administrative reporting, see [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Resolving common issues when usage totals or request logs do not look right If AI usage numbers or request logs seem wrong in Atloria, the cause is usually a filter mismatch, a scope issue, or a visibility setting. Start by checking what is selected on screen before assuming the underlying activity is missing. 1. Recheck the **Date range** and make sure it matches the period you intend to review. 2. Confirm the team, project, workspace, or user filters currently applied. 3. Verify whether the view includes all models and all statuses, or only a subset. 4. Compare the dashboard view and the request history view using the same filters. 5. If needed, repeat the search with broader filters to rule out an overly narrow view. If totals seem too high or too low, the first thing to inspect is the date filter. A **Current month** view can look much larger than **Last 7 days**, even when activity is normal. Next, check whether you are looking at all teams or just one workspace. A model filter can also change the numbers sharply if only one AI option is included. If a request appears to be missing from history, work through these checks: - Confirm you are searching under the correct user or team scope - Remove extra search terms and try a broader search - Check additional pages in the list - Review whether the request may have failed before a full record was saved If prompt or response details are not visible, the issue may be related to access level or content visibility rules. In that case, check whether your role allows you to view full request content, or whether those details are limited in your organization’s AI review process. If an export does not match the dashboard, compare these items before exporting again: - **Date range** - Team or user filters - Model and status filters - Time zone used for the report - Current sort or grouping choices For related administrative review areas, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls). ## Overview This document focuses on how to monitor AI activity in Atloria from a reporting and oversight perspective. The main tasks covered here are opening the **Admin** reporting area, reviewing high-level usage information, narrowing results with filters, inspecting individual request records, and exporting the results for reporting or audit work. The most important idea is the difference between summary reporting and request-level inspection. Use the dashboard view when you need totals, trends, or comparisons across time periods, teams, or workspaces. Use **Request history** when you need to understand one interaction in detail, such as a failed request, an expensive request, or a response that needs quality review. This guide is especially useful for people who oversee AI usage rather than create AI content directly, including: - Administrators reviewing organization-wide activity - Team leads checking usage patterns for their teams - Support leads investigating failed or unusual requests - Operations reviewers preparing usage reports or audit evidence In Atloria, the reporting workflow usually follows a simple pattern: 1. Open the reporting area from **Admin**. 2. Set the date range. 3. Apply filters for the team, project, user, or status you want to review. 4. Read the totals and trends. 5. Open request history for the records behind those numbers. 6. Export the filtered results if you need to share them. Because the **Analytics & Insights** area is currently positioned as the place for usage statistics and performance metrics, you should treat it as the starting point for AI usage monitoring. If you need broader admin navigation help before working in this area, read [Using the Admin Workspace](doc:using-the-admin-workspace). The next document in this section is [Managing AI Usage and Request History](doc:managing-ai-usage-and-request-history), which continues from monitoring into day-to-day control and follow-up actions. ## Prerequisites Before you monitor AI usage and request history in Atloria, make sure you have the right access and enough context to interpret what you are seeing. - You must be able to sign in to Atloria and reach the authenticated workspace. - You need access to the **Admin** area or another management view that exposes AI usage reporting. - You should know which team, project, or workspace you are responsible for reviewing. - You should have a clear reporting period in mind, such as **Today**, **Last 7 days**, or **Current month**. - You should understand whether you are looking for a trend, a specific incident, or a user-level activity trail. It also helps to know what kind of review you are performing: - **Cost review** focuses on usage totals, model choice, and per-request cost or token values. - **Quality review** focuses on prompts, responses, retries, and failed outcomes. - **Operational oversight** focuses on timestamps, users, teams, and request status. If you are new to Atloria account access or need help getting into the workspace first, use these related guides: - [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) - [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) - [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation) If you expect to review administrative reporting regularly, you may also want to be familiar with: - [Using the Admin Workspace](doc:using-the-admin-workspace) - [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) - [Configuring AI Settings for Your Organization](doc:configuring-ai-settings-for-your-organization) When these prerequisites are in place, you can move through AI usage monitoring quickly and interpret the results with much more confidence. ## Preparing the workspace and creating a new project To start a publishing workflow in Atloria, make sure the right people can access the project with the right level of control. For this process, you typically need three roles in place: - **Project Administrator** to create the project and manage setup choices - **Documentation Manager** to control review and release decisions - **Technical Writer** to create and update documentation pages 1. Sign in to Atloria and open the main dashboard. If you need help getting into your account first, see [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account). 2. Click **New Project** to open the project setup flow. 3. Enter the basic project details. Atloria’s setup asks for the project name and the public site address details used for the documentation site, including the site URL or slug. Choose these carefully because they shape how readers will identify the published documentation. 4. Set the project’s starting visibility to a non-public option so your team can build and review content before launch. 5. Continue through the setup choices for the documentation site. Select the site template Atloria provides for documentation, choose the default language, and confirm who owns the workspace. 6. Finish creating the project to open its workspace. After the project opens, go to the project settings area and add your team members. Assign permissions based on what each person needs to do: - Writers should be able to create and edit documents - Reviewers should be able to review release candidates - Documentation Managers should be able to approve versions and publish them [SCREENSHOT: New Project setup screen showing project name, site URL or slug, visibility, template, language, and ownership options] If you want more detail on project creation choices before you begin, use [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) and [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). ## Onboarding your team and configuring project settings Once the project exists, use the onboarding flow to make sure everyone understands where work happens. Atloria introduces the main areas you will use during publishing: the **project dashboard**, **content library**, **review queue**, and **release controls**. Move through each screen so your team can recognize where to draft content, where to review versions, and where to publish the final site. 1. Open the new project and complete the onboarding prompts shown in the workspace. 2. Review the **project dashboard** first. This is where you track overall project activity and move into the main publishing areas. 3. Open the **content library** to confirm where pages will be created and organized. 4. Open the **review queue** so reviewers know where release candidates appear when they are ready for sign-off. 5. Open the **release controls** area so Documentation Managers can identify where version publishing happens. Next, configure the project settings that affect the public documentation experience. In the project settings area, update the items that shape the site readers will see: - **Site title** - **Branding assets** - **Navigation structure** - **Default review rules** These settings matter early because they affect both internal previews and the final public site. If your navigation structure is incomplete or your branding is missing, reviewers may approve content that still looks unfinished. Then confirm access by role. Technical Writers should be able to create and edit documents, while Documentation Managers should be able to approve versions and trigger releases. If your organization uses separate reviewer access, confirm those users can reach the review queue without having publishing controls. Before launch, verify the project is still limited to draft-only or internal access. Open the project preview and confirm the content is visible internally without being exposed publicly. [SCREENSHOT: Project workspace showing dashboard, content library, review queue, release controls, and project settings] For a deeper look at project settings and administration, see [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options) and [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). ## Authoring documentation and organizing content With the workspace ready, begin building the documentation in the project content area. This is where Technical Writers create the pages that will appear on the public site after release. Each page should be created with a clear title, a clean document slug, and the correct placement in the navigation tree. 1. Open the project’s **content library**. 2. Click the option to create a new document or page. 3. Enter the **page title** exactly as you want readers to see it in navigation and on the page itself. 4. Set the **document slug** so the page has a readable address in the documentation site. 5. Choose where the page belongs in the site navigation tree before you start writing. Inside the editor, draft the page content and save your work as you go. Saving in the project workspace keeps the content available to your team without making it public. This is important: draft content in the editor is not the same as released content on the public site. Writers can continue improving pages while the public site still shows the currently released version. As your page count grows, organize related documents into the right hierarchy. Group setup pages together, place task-based guides under the correct section, and make sure parent and child pages reflect how readers will browse the published site. A strong navigation structure makes version review much easier because reviewers can check the release as a reader would experience it. Watch each document’s status as it moves from early drafting toward review readiness. Pages should be complete, saved, and placed correctly before you include them in a release candidate. [SCREENSHOT: Content library with document list, page title, slug, status, and navigation placement options] For more detailed editing guidance, use [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) and [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content). ## Generating versions and preparing a release candidate When the draft content is ready for a formal release check, create a documentation version from the current project content. In Atloria, a version captures a release candidate based on what is in the project workspace at that moment. This lets your team review a stable snapshot instead of reviewing pages that keep changing. 1. Open the project workspace and go to the version or release area. 2. Use the version generation controls to create a new documentation version. 3. Enter a version name or label that clearly identifies the release candidate. 4. Confirm the generation action so Atloria builds the version from the current project content. Choose labels that help reviewers quickly understand what they are looking at. For example, the version name should distinguish a release candidate from ongoing draft work. This becomes especially important when several versions are under discussion at the same time. After generation, review the version details carefully. Confirm which documents were included and compare the version content to the draft workspace. The key difference is that the generated version is frozen for review, while the live draft workspace can still change as writers continue editing. If a writer updates a page after the version is generated, that update will not appear in the release candidate until you generate a new version. Use the version preview before sending anything for approval. Open the preview and check: - Navigation order - Page rendering - Included pages - Overall release scope This is the best time to catch missing pages, broken structure, or content that was not ready to be frozen into the release candidate. [SCREENSHOT: Version generation screen with version name, included content summary, and preview option] If you need more detail on version workflows, see [Generating New Documentation Versions](doc:generating-new-documentation-versions), [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle), and [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness). ## Reviewing content and approving it for publication Once the release candidate looks correct in preview, move it into the review workflow. Atloria’s review process helps Documentation Managers and designated reviewers evaluate the exact version that may be published, rather than checking draft pages one by one in the editor. 1. Open the generated version in the versions area. 2. Send the version into the **review** stage using the review action available on that version. 3. Ask the assigned reviewers and Documentation Managers to open the version from the **review queue**. 4. Review feedback, update source documents where needed, and generate a replacement version if the changes affect release content. 5. Use the approval controls only after all required reviewers have completed sign-off. During review, keep in mind that feedback may point to individual documents, navigation labels, or metadata shown in the version preview. If a reviewer finds a problem, return to the source content in the project workspace, make the correction there, save the page, and then generate a new version. Do not assume draft edits automatically update the version already under review. Before final approval, check that the version reflects the full release exactly as intended. Reviewers should confirm: - The final document set is complete - Page titles and navigation labels are correct - The version metadata is accurate - The public-facing structure matches expectations Only mark the version as ready for release when required reviewers have signed off. This approval step is what separates a review candidate from a publishable release. [SCREENSHOT: Review queue showing a version in review, reviewer feedback, approval status, and release readiness controls] For more on review decisions and approvals, see [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions), [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals), and [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review). ## Publishing the site and confirming the public release After approval is complete, publish the version from the project’s release controls. This is the step that makes the approved documentation available to external readers. 1. Open the project dashboard or version release area. 2. Select the approved version you want to publish. 3. Use the **publish** action in the release controls. 4. Confirm the release so Atloria makes that version the active public documentation site. As soon as the release finishes, verify the project’s visibility. If the project was previously limited to internal or draft access, confirm it now reflects the intended public state. Then open the public site address and review the live documentation as an outside reader would see it. Check the public site carefully: - Confirm the released version label is the active one - Browse the navigation to make sure sections appear in the right order - Open several document pages to confirm the correct content is live - Check the landing page behavior to make sure readers arrive at the expected starting page It is also important to confirm what did **not** go live. Any unpublished draft changes made after the approved version was generated should remain hidden from the public site. If your team continues editing in the workspace after release, those edits stay in draft until they are included in a future version and published separately. [SCREENSHOT: Release controls showing the approved version selected for publishing and a public site preview after release] For related guidance on visibility and public access, see [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options), [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access), and [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation). ## Fixing common issues during review and release Most release problems in Atloria come from permissions, version timing, or publishing the wrong version. When something does not behave as expected, start by checking the exact screen where the workflow stopped. 1. **A reviewer cannot approve a version** Open the version and confirm it is actually in the **review** stage. If it is still a draft version, approval actions may not be available. Then check the reviewer’s access in the project settings area. The person may have document editing access without having permission to participate in review or approval. 2. **A document is missing from the release candidate** Return to the project workspace and open the content library. Confirm the page was saved before the version was generated. Then review the generated version’s included content to make sure the page was part of that release candidate. If the page was added or updated afterward, generate a new version. 3. **The site is still not public after publishing** Check the project visibility setting first. Then confirm the public site address details were configured correctly during project setup or in project settings. Finally, make sure the version you published was the approved version intended for release, not an older or incomplete version. 4. **Public pages show outdated content** Compare the live site with the latest draft in the content library. In many cases, the newer draft was never regenerated into a version. In other cases, the wrong active version is still selected in the release controls. [SCREENSHOT: Troubleshooting view comparing draft content, version status, approval state, and active published version] If you need more help with permissions, settings, or release validation, use [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions), [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export), and [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness). ## Overview Publishing in Atloria follows a clear sequence: create the project, configure the site, invite the right contributors, write and organize content, generate a version, complete review, approve the release candidate, and publish the approved version to the public documentation site. The most important thing to remember is that Atloria separates **draft workspace content** from **generated versions**. Writers can keep working in the content library while reviewers evaluate a frozen release candidate, and only an approved published version becomes visible to external readers. Across this workflow, a few screens matter most: - **New Project** for project creation - **Project settings** for site title, branding, navigation, visibility, and team access - **Content library** and the editor for page creation and organization - **Review queue** for release evaluation - **Release controls** for version publishing - **Public site** for final verification after launch This guide focused on the full path from setup to public release. If you want to coordinate the handoff between writers, reviewers, and release owners in more detail, continue with [Coordinating Project Publishing From Draft to Public Release](doc:coordinating-project-publishing-from-draft-to-public-release). ## Understanding What Appears in Published API and Technical Docs In Atloria, published technical documentation usually separates reference content into two reader-facing page types: **API reference pages** and **technical reference pages**. You can usually tell which one you are reading by looking at the page title, the left-hand navigation group, and the labels shown near the top of the page. An **API reference page** is built around a specific endpoint. In the sidebar, these pages are often grouped with other API operations, and the page title usually includes a request label such as **GET /resource** or **POST /resource**. Near the top of the page, you may also see details that help you identify the operation quickly, such as the request method, the endpoint path, and notes about authentication or status. A **technical reference page** is broader. Instead of focusing on one request, it explains a technical concept, shared object, schema, or entity used across the documentation. In the sidebar, these pages usually appear under a technical or reference section rather than under a list of endpoint operations. Their titles are more likely to be object names, concept names, or reference topics. When you open an API reference page, expect to see details such as: | Section | What you can read there | Why it matters | |---|---|---| | Endpoint header | Request method and path | Confirms the exact operation | | Authentication details | Whether sign-in or credentials are needed | Helps you know access requirements | | Parameters | Path, query, or header inputs | Shows what you must send | | Request body | Fields and example payloads | Helps you format your request | | Responses | Example results and status codes | Shows what comes back | On a technical reference page, you are more likely to see: - Entity or object definitions - Field descriptions - Relationships between objects - Rules or constraints - Supporting notes that explain how the documented concept behaves [SCREENSHOT: Published documentation showing an API endpoint page in the sidebar next to a technical reference page] ## Navigating API Reference Pages by Endpoint To read an API endpoint page in Atloria, start with the documentation sidebar and open the API group that matches the area you want to inspect. Inside that group, each page is usually listed by a method-and-path label, such as **GET /projects**, **POST /documents**, or **DELETE /versions/{id}**. This naming pattern helps you spot the difference between pages that work with the same resource but perform different actions. Once you open an endpoint page, begin at the header. This top section usually gives you the clearest summary of the operation. Look for the operation title, the request path, and any visible labels that indicate whether the endpoint requires authentication or has a special status such as deprecation. If several pages have similar names, this header is the fastest way to confirm you are on the right one. Next, move to the **Parameters** section. This is where Atloria shows the values that can be sent as part of the request. Pay attention to where each value belongs: | Parameter area | What to check | What it tells you | |---|---|---| | Path parameters | Required markers and example values | Which values must appear in the URL | | Query parameters | Optional filters, defaults, and allowed values | How to narrow or sort results | | Header parameters | Required headers and accepted values | Extra information needed with the request | If the page includes a **Request Body** section, compare the field list with the example payload shown on the page. Then review the **Responses** area. This section often includes response examples, schema tables, and separate blocks for different status codes. Reading these together helps you understand not only the successful result, but also what different outcomes may look like. [SCREENSHOT: API endpoint page with endpoint header, Parameters section, Request Body, and Responses] ## Reading Entity and Schema Details API pages in Atloria often link to schema or object references. These linked pages are useful when you need to understand the structure of the data shown in a request or response. If an endpoint returns a named object, open that linked reference to inspect the full field list instead of relying only on the short example shown on the endpoint page. Start with the object name at the top of the page. Then review the field table carefully. A good schema page usually shows each field’s name, data type, whether the field is required, and a description of what the field means. Some fields also include format hints, which help you interpret values correctly. Use this reading order when reviewing a field table: | What to look at | Why it matters | |---|---| | Field name | Identifies the exact property | | Data type | Shows whether the value is text, number, object, array, or another format | | Required status | Tells you whether the field must be present | | Description | Explains the purpose of the field | | Format hint | Clarifies special formats such as date-time or UUID | You may also see nullable markers, nested properties, or expandable sections for child objects. These are especially important when a field contains another object or a list of objects. Follow links to related entities when you need to understand how one object connects to another. This is often the easiest way to trace parent-child structures and reusable components shared across multiple endpoints. Examples are just as important as field tables. A schema definition tells you the rules, while an example object shows how those rules appear in a real response. Compare the two side by side to see which fields are always present, which are optional, and how nested arrays are arranged. [SCREENSHOT: Schema page showing object name, field table, nested properties, and example response] ## Using Technical Reference Pages to Understand System Concepts Not every important detail in Atloria belongs on an endpoint page. When you need context that goes beyond a single request, open a technical reference page. These pages are designed to explain concepts, shared entities, lifecycle rules, and other reference material that supports the API documentation. A technical reference page is especially useful when you are trying to answer questions like: - What does this entity represent across the product? - How do related records connect to each other? - Are there limits, constraints, or compatibility notes I need to know? - Which operations work with this concept? These pages often use structured sections rather than a simple request-and-response layout. Look for headings that break the topic into clear parts, such as field definitions, relationships, processing rules, or limitations. If the page includes diagrams, tables, or linked references, use them to build a fuller picture of how the documented concept fits into the rest of the published docs. Cross-links are particularly helpful here. A technical reference page may link back to the API pages that create, update, list, or retrieve the entity being described. That lets you move from understanding the concept to finding the exact operation that works with it. If you are reading about a shared object, follow those links to see where it appears in actual requests and responses. Also check for notes that apply only to specific versions or documentation contexts. Some technical reference pages include version-specific notes, compatibility details, or terminology mappings that explain why one page uses a different label than another. Those notes can save time when you are comparing pages across a project workspace and a published documentation view. For more detail on project-side browsing, continue with [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). ## Finding the Right Page Faster When a documentation set grows, finding the right reference page quickly becomes just as important as reading it. In Atloria, the fastest results usually come from using exact terms instead of broad topic words. Search for the endpoint path, the object name, or a field name you already know. For example, a precise path or object label is usually more effective than a general search for a product area. If you are browsing instead of searching, use the left-hand navigation groups. This works especially well when several pages share the same resource name but differ by request method. A list that includes **GET**, **POST**, **PUT**, or **DELETE** labels makes it easier to compare related operations without opening unrelated pages. Once you are on a page, use in-page navigation tools to jump directly to the section you need. Depending on the page layout, Atloria may show a table of contents or anchor links for major sections. | Navigation aid | Best use | |---|---| | Search results | Find exact paths, object names, or field names | | Sidebar groups | Browse related endpoints or reference topics | | In-page links | Jump to Parameters, Request Body, Responses, or Fields | | Breadcrumbs | Confirm where the page sits in the documentation structure | Breadcrumbs and sidebar position are also useful for page identification. If you are unsure whether you opened an endpoint page or a broader technical reference page, check where the page sits in the sidebar and how it is labeled in the breadcrumb trail. An endpoint page usually appears inside an API group and includes a method-and-path title, while a technical reference page usually sits under a broader reference section and uses a concept or object name as the title. [SCREENSHOT: Published docs with sidebar, breadcrumbs, search results, and in-page table of contents] ## Reference: What Information to Expect on Each Page Type Use the page layout in Atloria as a quick clue for what kind of information you should expect. API endpoint pages, schema pages, and broader technical reference pages each present information differently, even when they are closely related. If you know what normally appears on each page type, you can scan faster and avoid missing important details. ### API endpoint page An API endpoint page is centered on one operation. It usually includes: | Item | What you will usually see | |---|---| | Operation title | A readable name for the endpoint | | Request method | Labels such as GET, POST, PUT, or DELETE | | Path | The endpoint URL path | | Authentication details | Whether sign-in or credentials are required | | Parameter tables | Path, query, and header inputs | | Request body | Field definitions and example payloads | | Response details | Response schema, examples, and status codes | ### Entity or schema page A schema page focuses on the shape of an object used in requests or responses. It commonly includes: - Object name - Field list - Data types - Required flags - Nested properties - Related objects or reusable models - Example object values ### Technical reference page A technical reference page explains a concept or shared reference topic. It often includes: | Item | What you will usually see | |---|---| | Concept description | A plain-language explanation of the topic | | Definitions | Fields, components, or related terms | | Relationship notes | How the topic connects to other objects | | Constraints | Limits, rules, or compatibility notes | | Version notes | Differences tied to a release or documentation version | | Related links | Links to endpoint pages or supporting references | Across all page types, Atloria may also provide navigation aids such as the sidebar, breadcrumbs, search result labels, and an in-page table of contents. These elements help you confirm what you are reading before you spend time on the details. ## Overview Published reference content in Atloria is easiest to read when you first identify the page type, then use the page structure to focus on the details that matter. API endpoint pages are best for understanding a single operation: what path it uses, which inputs it accepts, what the request body should contain, and what responses may come back. Schema pages help you inspect the exact shape of request and response objects. Technical reference pages give you the broader context behind those objects, including relationships, rules, and shared concepts. A practical reading pattern is: 1. Confirm the page type from the title, sidebar group, and breadcrumb trail. 2. On endpoint pages, scan the header, parameters, request body, and responses. 3. Open linked schema pages when you need field-level detail. 4. Use technical reference pages when you need concept-level explanation or relationship context. 5. Use search, sidebar groups, and in-page links to move quickly between related pages. This approach is especially helpful when you are reviewing published documentation before writing internal notes, checking release content, or comparing how a concept appears across multiple pages. In Atloria, the published documentation view is designed to support both quick scanning and deeper reference reading, so it is worth using the navigation tools instead of relying only on page-by-page browsing. If you also work inside project workspaces, the next useful step is learning how similar technical reference content is organized before publication. Continue with [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). ## Prerequisites You do not need any setup steps inside Atloria to use this guide effectively, but a few basics will make the pages easier to read. Before you start, make sure you have: - Access to a published documentation site in Atloria - A page that includes API reference or technical reference content - A general idea of what you are looking for, such as an endpoint path, an object name, or a field name It also helps if you are already comfortable with the basic published documentation layout, especially the left-hand navigation and page search. If you need help getting oriented in Atloria first, review [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) or [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page). You do **not** need to know how to create projects, connect repositories, or manage admin settings to read published reference pages. This guide is focused only on how to recognize page types, move through the published reference structure, and interpret the information shown on each page. If your goal is to compare published reference pages with project-side technical docs, keep this guide open as a reading baseline and then continue to [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). ## Understanding the version review workflow In Atloria, version review usually starts in the **Versions** list inside a project workspace. Each version appears with a status badge that shows where it is in the review cycle. The main statuses you will work with are **Draft**, **In Review**, **Approved**, **Rejected**, and **Released**. A version in **Draft** is still being prepared. When someone clicks **Request review** on the version details page, the status changes to **In Review**. After a reviewer makes a decision, the version changes to **Approved** or **Rejected**. Once an approved version is published or finalized for release, it moves to **Released**. The main screens for this workflow are the **Versions** list, the **version details** page, the **Review status** badge, and the decision actions such as **Request review**, **Approve version**, and **Reject version**. The **Versions** list helps you scan multiple versions at once, while the version details page gives you the full review record for one version. Different team members usually handle different parts of the process: - **Technical Writer** prepares the version content, updates the change summary, and requests review. - **Documentation Manager** checks quality, confirms readiness, and may approve or reject the version. - **Project Administrator** may step in to review, approve, or manage release readiness depending on project permissions. On the version details page, reviewers typically look for the **version number or version name**, the **change summary**, any **release notes**, the current **review status**, reviewer **comments**, and the **approval history**. They use that information to decide whether the version is ready to move forward or needs more work. [SCREENSHOT: Version details page showing status badge, change summary, comments, and approval history] ## Preparing a version and requesting review Before you ask anyone to review a version in Atloria, open the project’s **Versions** list and select the version you want to send forward. On the version details page, first check the status badge near the top of the screen. It should show **Draft**. If the version is already **In Review**, **Approved**, or **Released**, you are no longer in the initial request stage and should review the current status before making changes. Reviewers need enough context to understand what changed, so complete the key version details before you click **Request review**. In practice, that means checking the version name and filling in the summary information that explains what this version includes. The most important fields are usually the version label itself, the **change summary**, and the **release notes**. If those areas are incomplete, reviewers may not have enough information to make a decision, and Atloria may prevent you from sending the version for review. Use this checklist on the version details page before submitting: | Field or area | What to confirm | |---|---| | **Version name** | Clearly identifies the version being reviewed | | **Change summary** | Explains what was added, updated, or removed | | **Release notes** | Gives reviewers release context and highlights important changes | | **Status badge** | Shows **Draft** before review is requested | When everything is ready, click **Request review**. If Atloria shows a review request dialog, confirm the assigned reviewers and add helpful notes in the **reviewer comments** field. Use that space to point out sections that need special attention or explain what changed since the last draft. After you submit the request, confirm that the status changes to **In Review** and that a new entry appears in the activity or history area with your name, the time of the request, and the updated status. [SCREENSHOT: Request review dialog with reviewer selection and reviewer comments field] ## Checking review progress and reviewer feedback Once a version is under review, the fastest place to check progress is the project’s **Versions** list. The **Review status** badge lets you quickly see whether a version is still **In Review**, has been **Approved**, or has been **Rejected**. This is especially useful when several versions are moving through review at the same time. For a full picture, open the version details page. That page usually shows the current status near the top and includes the review conversation below it. Look through the **comments** area and the **approval history** to see what each reviewer has said and whether anyone still needs to respond. If Atloria shows pending reviewer assignments, use that list to tell whether the version is waiting on a specific person or whether all required decisions have already been recorded. When you need to sort through many versions, use the available status filters or tabs in the versions area. These help you focus on: - versions waiting for action in **In Review** - versions already marked **Approved** - versions marked **Rejected** and ready for revision The approval history is the most reliable place to understand what happened during review. Each entry helps answer three basic questions: - **Who** reviewed the version - **What** decision they made - **When** that decision was recorded Keep in mind that comments and decisions are not always the same thing. A reviewer may leave feedback without formally approving or rejecting the version. In that case, the version can remain **In Review** even though new comments appear. If you are unsure whether review is complete, rely on the recorded decision and the status badge rather than comments alone. [SCREENSHOT: Versions list filtered by review status with Approved, In Review, and Rejected badges] ## Approving or rejecting a documentation version If you are assigned to make a review decision, open the version from the **Versions** list and confirm that its status is **In Review**. On the version details page, look for the decision controls. In Atloria, these actions appear as **Approve version** and **Reject version**. Before choosing either option, review the version information carefully, including the **change summary**, **release notes**, existing **review comments**, and the **approval history** so far. When you click **Approve version**, Atloria may prompt you to enter a decision comment. Use that comment to explain why the version is ready. A short note is often enough if the version meets expectations, but you can also mention any conditions already satisfied, such as completed edits or reviewed release notes. When you click **Reject version**, add a clear explanation of what needs to change. The most helpful rejection comments point to the exact issue, such as missing release details, incomplete documentation updates, or content that still needs correction. This gives the writer a clear path for revision before the next review cycle. After you submit your decision, Atloria updates the version record in two places: 1. The **status badge** changes to reflect the decision, such as **Approved** or **Rejected**. 2. A new entry appears in the **approval history** with your name, decision, comment, and timestamp. An **Approved** version is generally considered ready to move toward release, subject to any remaining release checks in the project. A **Rejected** version does not move forward. Instead, it returns to an editable state, typically **Draft**, so the writer can update the content and request review again later. [SCREENSHOT: Decision panel showing Approve version and Reject version actions with comment box] ## Managing revisions after a rejection or review change request When a version is rejected or sent back with requested changes, start on the version details page rather than editing immediately. Read the reviewer feedback in the **comments** area and the **decision history** so you understand exactly what needs to be fixed. If more than one reviewer responded, compare their notes carefully and look for repeated concerns. Those repeated comments usually point to the highest-priority changes. Before making updates, check the status badge. The version should return to **Draft** or another editable status before you revise it. If the version still shows **In Review**, look for whether reviewers only added comments without recording a final decision. In that case, you may need to wait for a formal rejection or ask the reviewer to complete the decision step before you continue. As you revise the version, update more than just the main content when needed. Reviewers often rely on the summary fields to understand what changed since the last review. Revisit these areas: - the documentation content itself - the **change summary** - the **release notes** - any reviewer-facing notes that explain what was corrected After you finish the updates, request review again from the version details page. In the **reviewer comments** field, explain what changed since the previous cycle. Keep that note specific. For example, mention that you updated release notes, corrected missing sections, or addressed comments from a named reviewer. This saves reviewers time because they can focus on the revised areas instead of rechecking the entire version from scratch. If you expect another detailed review round, the version history becomes especially important. Use it to confirm that the new request is recorded with the updated timestamp and that the status changes back to **In Review**. ## Resolving common review and approval issues Most review problems in Atloria come down to status, missing information, or permissions. If **Request review** is unavailable, first open the version details page and check the status badge. The version usually needs to be in **Draft** before you can send it for review. Then confirm that the key fields are filled in, especially the **version name**, **change summary**, and any **release notes** required for your team’s process. If one of those areas is incomplete, Atloria may keep the review action unavailable until the version is ready. If you cannot see **Approve version** or **Reject version**, the most likely cause is access level. Those decision actions are typically limited to assigned reviewers, documentation managers, or project administrators with review authority. If you can open the version but do not see the decision controls, compare your access with another reviewer or check with the person who manages project permissions. For related admin areas, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). Another common point of confusion is a version that stays **In Review** even after feedback appears. In many cases, that means reviewers added comments but did not submit a formal decision. Comments alone do not always change the status. Open the **approval history** and look for a recorded **Approved** or **Rejected** entry. If there is no decision entry, the review is still open. If a version is **Approved** but still cannot move to release, review the version details page for anything still incomplete. Common blockers include missing **release notes**, unresolved required comments, or project-level release restrictions that must be cleared before the version can be finalized. If you need help with broader release preparation, continue with [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review). ## Overview Use Atloria’s version review workflow when a documentation version is ready for formal feedback and a decision. The process begins in the **Versions** list, where you open a version and confirm it is still in **Draft**. From the version details page, you complete the key review context—especially the **version name**, **change summary**, and **release notes**—and then click **Request review** to move the version into **In Review**. From there, reviewers use the same version details page to inspect the content context, read reviewer notes, and record a decision with **Approve version** or **Reject version**. Atloria tracks each action in the version’s history so your team can see who requested review, who responded, what decision was made, and when that happened. The status badge in both the **Versions** list and the version details page gives you the quickest way to understand whether a version is still pending, approved for the next stage, or returned for revision. This workflow is most useful when your team needs a clear handoff between writing, review, and release preparation. Writers can submit a version with enough context for reviewers to evaluate it properly. Reviewers can leave comments and make formal decisions without losing the timeline of what happened. Managers and administrators can monitor progress across multiple versions by filtering the list for **In Review**, **Approved**, or **Rejected** items. If you are already comfortable working with version lists and comparisons, this guide focuses on the actual review decision stage. For broader version management before review begins, see [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness). ## Prerequisites Before you start reviewing or approving versions in Atloria, make sure these basics are in place: - You can sign in and open the correct project workspace. If you need help getting into Atloria, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). - The project already has at least one documentation version in the **Versions** list. - The version you want to submit is in **Draft** if you are requesting review for the first time. - The version details page includes enough review context, especially the **version name**, **change summary**, and **release notes**. - You have the right level of access for your task: - **Technical Writer** to prepare the version and request review - **Documentation Manager** to review readiness and make approval decisions - **Project Administrator** to manage review access or release-related controls - Reviewers are identified before you send the request, so the review dialog can be completed without delay. - If the version was previously rejected, you have already reviewed the earlier comments and updated the version before resubmitting it. It also helps to be familiar with the project’s version workspace before starting this process. If you need a refresher on finding versions, reading statuses, or opening a version record, see [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) and [Managing Project Version Workspaces](doc:managing-project-version-workspaces). The next step in this workflow is [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals), which goes deeper into how decision records are handled after review begins. ## Opening the Security Area and Understanding What You Can Review In Atloria, the **Security & Audit** area is available from the **Admin** workspace. Open the main signed-in area, go to **Admin**, and then select **Security & Audit**. The page opens with a clear header labeled **Security & Audit** and supporting text that describes it as the place for **security logs and audit trail management**. This tells you that the screen is meant for review and investigation rather than day-to-day content editing. The page is presented as an administrative review screen. From the information currently shown in the interface, this area is focused on viewing security-related information rather than changing settings directly on the same page. In other words, you should expect to inspect records, logs, and activity history here, not manage project content or edit documentation. If you need broader administrative navigation, see [Using the Admin Workspace](doc:using-the-admin-workspace). When you open **Security & Audit**, look first at the page title and the main content panel beneath it. Atloria uses this screen to surface audit-related information for administrators. Based on the page labeling, the types of information associated with this area include: - Audit trail records - Security logs - Sensitive activity history - Administrative review information Because this is an audit-focused screen, the most important details to look for are the people involved, the action that occurred, and when it happened. In audit views, these details are typically presented together so you can understand the sequence of events quickly. [SCREENSHOT: Security & Audit page in the Admin workspace showing the page header and main review area] At the moment, the visible interface emphasizes that this area is for monitoring and audit review. If you are looking for user or permission management actions, start from the other cards in **Admin**, such as **Users & Permissions**, and return to **Security & Audit** when you need to review what happened afterward. ## Reviewing Audit Logs and Security Events From the **Admin** workspace, open **Security & Audit** to review security-related activity. This page is labeled for **security logs and audit trail management**, so it is the right place to look when you need to check whether an important action took place and who performed it. When Atloria presents an audit log or event history list, read each record as a short summary of one action. The most useful details to identify in each row are usually: | What to look for | Why it matters | |---|---| | **Event type** | Tells you what kind of action happened | | **User** or **actor** | Shows who performed the action | | **Date** and **time** | Helps you place the event in sequence | | **Affected item** | Shows what project, setting, or record was involved | | **Status** or **result** | Indicates whether the action succeeded or failed | Start by scanning the most recent entries first. If the list includes filtering controls, narrow the results to the activity you are investigating. Common review patterns include checking a specific day, focusing on one person, or isolating a type of event such as access activity or administrative changes. If Atloria lets you open a single event, select the record to view its full details. The detail view is where you confirm exactly what changed, which item was affected, and whether the action completed successfully. This is especially helpful when a short row in the list only gives you a summary. [SCREENSHOT: Audit log list with event rows showing action, actor, time, affected item, and result] Use this screen as a fact-checking tool. Rather than relying on memory or chat messages, review the event list directly and compare the event time, the person involved, and the action recorded in Atloria. ## Checking Sensitive Activity and Access Changes The **Security & Audit** area is especially useful when you need to review actions that could affect access, trust, or administrative control. In Atloria, this includes activity such as permission-related changes, role updates, sign-in activity, and important configuration changes when those records are shown in the audit trail. When you review sensitive activity, focus on three questions: 1. **Who performed the action?** Check the actor or user listed on the event. 2. **What was affected?** Look for the target user, project, setting, or other affected item. 3. **Did it succeed?** Use the status or result shown in the record. If a record involves access changes, compare the person who made the change with the person or item that was changed. For example, one person may update another user’s access, or an administrator may change a project-level setting. Reading both the actor and the affected item together helps you avoid misreading the event. For login-related or access-related records, pay close attention to result indicators. A successful action and a denied or failed attempt can look similar at a glance unless you check the status carefully. If Atloria shows badges, labels, or result text, use those markers to separate normal activity from attempts that did not complete. A timeline or recent activity list is also helpful when you are looking for unusual patterns. Several similar changes in a short period, repeated access attempts, or multiple permission-related updates close together may deserve a closer look. [SCREENSHOT: Security event details highlighting actor, affected user or item, and success or failure status] If you need to confirm whether an access-related change was expected, compare the event timing with known team activity, such as onboarding, role updates, or project administration work described in [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Using Filters, Search, and Event Details to Investigate Activity When you are investigating a specific issue in **Security & Audit**, the fastest approach is to narrow the event list before opening individual records. In Atloria, start with the search box or filter controls if they are available on the audit screen. Search for a person’s name, a resource name, or a known action so you are not reviewing unrelated entries. A good investigation usually follows this order: 1. Set the **time range** to the period when the activity likely happened. 2. Apply a **user** or **actor** filter if you know who may have performed the action. 3. Add an **event type**, **category**, or **severity** filter if the list is too broad. 4. Sort by **most recent** activity to bring the latest records to the top. 5. Open the matching event to inspect the full detail view. Changing the time window is especially important. If you only review today’s activity, you may miss the earlier event that explains the current issue. Expand the date range when needed so you can compare recent actions with earlier changes. Once you find a likely match, open the event details. The summary row may only show the action name and time, while the detail panel can include supporting information such as the source of the action, session-related context, changed values, or other identifying details. That extra context is what helps you decide whether the activity was expected or unusual. [SCREENSHOT: Security & Audit filters and an opened event detail panel] If you are comparing several related events, keep the list sorted in a consistent way while you open records one by one. That makes it easier to follow the sequence of changes and spot the first event that triggered the rest. ## Understanding What Security Information Is Available in the UI In Atloria, the **Security & Audit** page is designed to show review information directly in the interface. The page title and description make clear that administrators use it for **security logs** and **audit trail management**. That means the UI is intended to help you inspect what happened, when it happened, and who was involved. The kinds of security information administrators can review in the interface include: - Audit events - Security-related activity history - Access-related records - Permission or role-related changes when they are captured in the audit trail - Sensitive configuration updates when those records are surfaced on the page Across audit-style records, the most useful fields are usually the same even when the event types differ: | Common field | What it tells you | |---|---| | **Timestamp** | When the action happened | | **Actor** | Who performed the action | | **Action** | What happened | | **Target** | Which user, project, or item was affected | | **Source** | Where the action came from, when shown | | **Result** | Whether the action succeeded, failed, or was denied | It is also important to separate **current settings** from **historical records**. A settings screen shows the current state of access or configuration. The **Security & Audit** area, by contrast, is about past activity and review history. If you want to see who changed something, use the audit view. If you want to change the current setup, move to the relevant administration screen instead. The visible Atloria interface for this page currently presents **Security & Audit** as a review destination. If you need broader reporting or usage trends, compare it with **Analytics & Insights**, which is a separate area in **Admin** and is currently marked as coming soon. For related administrative context, see [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Resolving Common Gaps When Reviewing Security Activity If the **Security & Audit** area does not show what you expect, the issue is often related to scope, filters, or where the action was recorded. Start by checking the screen carefully before assuming the event is missing. - **No events appear in the audit list** - Check the selected date range first. - Clear any active filters that may be hiding results. - Confirm you are in the correct administrative area and reviewing the right workspace. - Refresh the page and reopen **Security & Audit** if the list looks incomplete. - **A specific user action is missing** - Look for a different event category if the screen separates access activity from settings changes. - Search by the user’s name and then search again by the affected item. - Expand the time range in case the action happened earlier than expected. - Check whether the action belongs in another administrative area, such as **Users & Permissions**, with the audit trail only showing the recorded result afterward. - **Event details seem incomplete** - Open the individual event instead of relying on the summary row. - Review whether the list view is only showing a short description. - Compare multiple related events to piece together the full sequence. - **You cannot open the Security section** - Confirm that your account has the administrative access needed to use **Security & Audit**. - If you can reach **Admin** but not this page, your permissions may be limited to other administrative sections. [SCREENSHOT: Empty or filtered Security & Audit state with filter controls visible] When you still cannot find the activity you need, cross-check the related administrative workflow. For example, a permission update may be easier to understand after reviewing the user management steps in [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Overview - **Security & Audit** is the Atloria admin area for reviewing security logs and audit trail information. - You reach it from the **Admin** workspace after signing in. - The page is presented as a review screen, with a header labeled **Security & Audit** and supporting text about **security logs and audit trail management**. - Use this area when you need to confirm: - who performed an action - what item or setting was affected - when the action happened - whether the action succeeded or failed - This screen is best suited for investigation and verification, not for making routine content changes. - When available, focus on audit details such as: - event type - actor - timestamp - affected item - result or status - For broader administrative navigation, use the other cards in **Admin**, including: - **Users & Permissions** - **Organizations** - **Documents** - **Projects** - **Analytics** - If you need to understand the full admin navigation before reviewing audit records, read [Using the Admin Workspace](doc:using-the-admin-workspace). - If your goal is to inspect permission-related changes specifically, pair this screen with [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Prerequisites - You must be able to sign in to Atloria. - Your account must have access to the **Admin** workspace. - To open **Security & Audit**, you need the appropriate administrative permissions for audit-related review. - Before you start, it helps to know: - the approximate date and time of the activity you want to review - the name of the person involved, if known - the project, setting, or item that may have been affected - If you are investigating a permission or access issue, gather any related details from the team first so you can search the audit records more quickly. - For sign-in help, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). - If you are unsure whether you have the right level of access, review [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings) or [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Opening the AI Providers Settings Before you change any AI provider settings in Atloria, make sure you have **Project Administrator** access for the workspace you are managing. AI provider settings affect how AI-powered features work across the project, so this is not something regular contributors should change casually in a shared documentation workspace. In Atloria, open your project or administration area and go to the screen where **AI provider settings** are managed. If your team also uses broader AI controls, you may want to review related guidance in [Configuring AI Settings for Your Organization](doc:configuring-ai-settings-for-your-organization) and [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings). Once you reach the AI provider screen, look for three main parts of the page: - A **provider list** showing the AI providers already configured - A **settings form** where you can view or edit provider details - Action controls such as **Import**, **Export**, and **Reset** [SCREENSHOT: AI Providers settings page showing the provider list, settings form, and Import, Export, and Reset actions] Take a moment to review what is already there before you add or change anything. This matters most when several administrators share responsibility for the same project. A provider may already be active, a previous import may have added multiple entries, or someone may have adjusted connection details for a specific documentation workflow. If you skip this review, you can easily overwrite a working setup with incomplete details. Start by checking the provider list, then open the current entry and read through the visible fields before making edits. That quick review helps you understand whether you are updating an existing setup, replacing an older one, or preparing to add another provider alongside the current one. ## Reviewing Current Provider Configuration On the AI Providers screen, begin with the **current provider list**. This list shows which provider entries already exist in the project. If your team has tested more than one AI service, you may see several entries instead of just one. Review each visible entry name carefully so you do not create a duplicate with slightly different details. After selecting a provider, inspect the fields shown in the settings area. Atloria may display details such as the provider name, a connection address such as a **base URL** or **endpoint**, model-related options, and authentication values. If any credential fields are hidden or masked, that usually means a value is already stored. Treat masked values as a sign that the provider was previously configured, even if you cannot see the full value on screen. Use the current configuration view to answer these questions before editing: - Which providers are already available? - Which one appears to be the active or default choice for AI features? - Do the visible values look like a standard setup, a custom setup, or an imported configuration? - Have recent changes already been made by another administrator? A quick review is especially helpful after an **Import** or **Reset** action. Imported settings may add or replace several provider entries at once, while a reset may remove custom values and return fields to a simpler state. If you are unsure whether the current setup is intentional, compare what you see on screen with your team’s expected provider list before saving any changes. [SCREENSHOT: Selected provider entry with visible fields such as provider name, base URL, model options, and masked credentials] If you need a broader understanding of how AI features are being used in your workspace, related documents such as [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history) and [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) can help you connect provider settings to day-to-day use. ## Configuring and Updating AI Providers Once you have reviewed the current setup, you can update an existing provider or add another one from the AI Providers page. 1. Open the **AI Providers** settings screen and select an existing provider from the list, or choose the option to add a new provider if one is available on the page. 2. In the provider form, enter or update the fields shown by Atloria. These typically include the **provider name or identifier**, connection details such as a **base URL** or **endpoint**, model-related settings, and any credential fields required for access. 3. Review each field before saving. Pay close attention to connection details and credential entries, since small mistakes in these fields can stop AI features from working correctly. 4. Click **Save** to apply your changes. 5. Watch for the page to reflect the update. In Atloria, this may appear as the updated provider remaining in the list, the edited values reappearing when you reopen the entry, or the intended provider showing as the selected option. [SCREENSHOT: Editing a provider entry and clicking Save] If your project needs more than one AI backend, repeat the same process for each provider entry. For example, your team may keep one provider for general documentation generation and another for testing or specialized workflows. The important part is keeping each entry clearly named so administrators can tell them apart in the list. When updating an existing provider, avoid changing several entries at once unless you are working from a verified configuration. It is easier to confirm one successful change at a time than to troubleshoot multiple edits later. If your workspace relies heavily on AI-generated content, you may also want to review [Setting Up and Maintaining AI Providers](doc:setting-up-and-maintaining-ai-providers) alongside [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking) to keep provider setup aligned with how your team uses AI across projects. ## Importing and Exporting Provider Settings Atloria includes **Import** and **Export** actions on the AI configuration screen so administrators can move provider settings more safely than retyping every field by hand. 1. Open the **AI Providers** settings page. 2. Click **Import** to load provider settings from a saved configuration file or settings payload. 3. After the import finishes, review the page immediately. Check the provider list, confirm the expected entries appear, and verify which provider is now active or selected by default. 4. Open each imported provider entry and inspect important fields such as the provider name, connection details, and any masked credential fields. 5. If everything looks correct, keep the imported configuration. If not, compare it with a known-good export before making manual corrections. Import is useful when you are setting up a similar project, restoring a previous configuration, or applying a standard provider setup across multiple workspaces. It can also save time when several providers need to be added together. To create a backup, use **Export** from the same screen. 1. Click **Export** on the AI Providers page. 2. Save the exported configuration in your team’s approved storage location. 3. Use that export when you need a backup, when you are preparing to reset the current setup, or when another project needs the same provider configuration. [SCREENSHOT: Import and Export actions on the AI Providers screen] Export is usually safer than manual copy-and-paste when your setup includes multiple providers or several detailed fields. A manual copy can miss hidden values, default selections, or small connection details. An export gives you a cleaner baseline to restore from later. If you are moving settings between projects, pair this process with the guidance in [Connecting and Managing External Integrations](doc:connecting-and-managing-external-integrations) when your AI setup depends on related connected tools. ## Resetting AI Configuration Safely The **Reset** action on the AI Providers screen is meant for situations where you need to clear out a broken, outdated, or unwanted configuration. Because reset can affect the full AI provider setup shown on that page, use it carefully in shared projects. 1. Open the **AI Providers** settings screen and locate **Reset**. 2. Before clicking it, use **Export** to create a backup of the current configuration. 3. Confirm with your team that no one is actively updating provider settings at the same time. 4. Click **Reset** and complete any confirmation step Atloria shows. 5. After the reset finishes, review the provider list and settings form to confirm the result. Depending on how your workspace is configured, reset may return the page to default values, remove custom provider entries, or clear settings that were previously imported. The exact result should be visible on the screen after the action completes. For example, you may see fewer provider entries, blank fields, or a default provider state instead of your earlier custom setup. [SCREENSHOT: Reset action with confirmation prompt on the AI Providers page] The safest time to use reset is when you already have an exported backup and you know the current configuration should no longer be used. If you are troubleshooting a single provider, try reviewing and updating that entry first instead of resetting everything. After a reset, do not assume the page is ready for use until you verify the visible values. Open the remaining provider entries, if any, and check whether the intended default still exists. If the reset removed a working setup, you can usually recover more quickly by importing your last exported configuration than by rebuilding each provider manually. ## Verifying Your Setup After saving, importing, or resetting AI provider settings, take a few minutes to confirm that Atloria is showing the configuration you intended. 1. Return to the **AI Providers** screen and check the provider list. 2. Confirm that the correct provider appears in the list and is marked as the active or selected option if your project uses a default provider. 3. Reopen the provider entry you just changed and make sure the values still appear as expected. 4. Review required fields for anything incomplete, especially connection details, model-related settings, and credential fields. 5. If you recently imported settings, compare the imported entries with an exported baseline if something looks different. This verification step matters because some problems are easy to miss during editing. A provider may save with a missing field, a connection address may be entered incorrectly, or an import may overwrite a value you expected to keep. Reopening the screen helps you catch those issues before your team notices AI features behaving differently. Common things to look for include: - A provider entry is missing from the list - The wrong provider appears to be selected - A required field is blank - A connection value does not match your approved setup - Credential fields no longer appear stored after an import or reset [SCREENSHOT: Verified provider list with the intended default provider selected] If imported settings do not behave as expected, compare the current entries against a previously exported configuration. That side-by-side check is often the fastest way to spot mismatched values. For related setup checks, you may also want to review [Configuring AI Settings for Your Organization](doc:configuring-ai-settings-for-your-organization) and [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history) to confirm the provider changes support the AI features your team relies on. ## Overview Use the **AI Providers** settings in Atloria when you need to control which AI services are available to a project and how those services are configured. This screen is most relevant for project administrators who manage documentation generation, AI support agents, or other AI-assisted workflows inside a shared workspace. The AI Providers area is built around a few core tasks: - Reviewing the current list of configured providers - Opening a provider entry to inspect or update its details - Saving changes to an existing provider or adding another one - Importing a saved configuration into the current project - Exporting the current configuration for backup or reuse - Resetting the provider setup when you need to clear custom changes Most teams use this screen during initial workspace setup, when moving a known-good AI configuration into another project, or when troubleshooting a provider that is no longer behaving as expected. It is also helpful after a team handoff, since the provider list and settings form let you quickly see whether the project is using a standard setup or a custom one. Because these settings can affect multiple AI features across the project, always review the current configuration before making changes. In Atloria, a small update to the selected provider, connection details, or imported settings can change how documentation and AI-assisted tools behave for everyone in the workspace. [SCREENSHOT: Full AI Providers page in Atloria] If your team is working across several AI-related areas, this guide fits alongside [Configuring AI Settings for Your Organization](doc:configuring-ai-settings-for-your-organization), [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents), and [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history). Those documents help you connect provider setup with the rest of your AI workflow in Atloria. ## Prerequisites Before you update AI providers in Atloria, make sure the following conditions are in place. These checks help you avoid accidental changes, incomplete setups, or lost configuration details. - You have **Project Administrator** access for the workspace where the provider settings are managed. - You can open the **AI Providers** settings page in the project or administration area. - You know whether you are updating an existing provider, adding a new one, importing a saved configuration, or resetting the current setup. - You have the provider details your team intends to use, such as the provider name, connection information, model-related values, and any required credentials. - If you plan to use **Import**, you already have the saved configuration file or settings payload available. - If you plan to use **Reset**, you have exported the current configuration first so you can restore it if needed. It also helps to confirm who else manages AI settings in the same workspace. In shared projects, another administrator may already be editing the same provider entries or may have recently changed the default provider. A quick check with your team can prevent duplicated work or overwritten settings. Before making major changes, review related Atloria guidance if your provider setup connects to broader AI or admin workflows: - [Configuring AI Settings for Your Organization](doc:configuring-ai-settings-for-your-organization) - [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings) - [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history) [SCREENSHOT: AI Providers page access from the project or admin area] If any of these items are missing, gather them before you start. Having the correct access, the right provider details, and a current export makes provider maintenance much easier and reduces the chance of interrupting AI features your team already depends on. ## Opening the Atloria Sign In Page Start on the Atloria public site and look for the **Sign in** button in the top navigation. Selecting **Sign in** opens the dedicated login screen. You can confirm that you are on the correct page by checking for the **Email** field, the **Password** field, and the main **Sign in** button. These are the key items used to access your Atloria account. The sign in screen is separate from the rest of Atloria. The public site is where visitors can learn about Atloria and browse public-facing information. The sign in page is the access point for account holders. After you log in successfully, Atloria takes you into the authenticated workspace, where you see the main app layout used for projects, documents, admin areas, and other team features. In some cases, you may not open the sign in page directly. If you try to open a protected Atloria page before logging in, Atloria may send you to the sign in screen automatically. This usually happens when you open a saved bookmark, a shared internal link, or a browser tab from an earlier session that has expired. When that happens, simply sign in from the **Email** and **Password** fields shown on screen. If you are unsure where you are, use these visual checks: - **Public site:** marketing-style pages and top navigation - **Sign in page:** **Email**, **Password**, and **Sign in** - **Authenticated workspace:** app navigation such as a sidebar, header, or account menu [SCREENSHOT: Atloria sign in page showing the Email field, Password field, and Sign in button] If you do not yet have an account, use the registration option described in [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account). ## Signing In with Your Atloria Account On the Atloria sign in screen, enter your account details into the two required fields: | Field | What to enter | |---|---| | **Email** | The email address you used when your Atloria account was created | | **Password** | Your current Atloria password | After entering both values, click **Sign in**. Atloria checks your details and briefly keeps you on the login screen while it validates access. If your details are correct, the page changes automatically and takes you into Atloria. You should no longer see the **Email** and **Password** fields once sign in is complete. A successful sign in usually looks like this: - The sign in screen disappears - Atloria opens the main workspace - You see authenticated navigation, such as the app sidebar, page header, or your user menu - You can move into areas like projects, documents, settings, or admin pages based on your access If the email address or password is not accepted, Atloria shows the message **Invalid email or password** on the sign in screen. Re-enter both fields carefully before trying again. Atloria is designed to keep you signed in after a successful login so you can continue working without entering your password on every page. Over time, your session may expire, especially if you have been away from Atloria for a while. When that happens, opening a protected page sends you back to the sign in screen so you can log in again. [SCREENSHOT: Completed sign in flow showing the transition from the login screen into the Atloria workspace] If you are still having trouble entering Atloria, the troubleshooting steps in [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation) can help you identify whether you are on the correct screen. ## Returning to the Application After Login After you sign in, Atloria usually returns you to the page you originally tried to open. For example, if you selected a direct link to a project page, an admin area, or another protected screen, Atloria may first show the sign in page and then send you back to that same destination after your credentials are accepted. In other cases, Atloria may open the main workspace instead of the exact page you expected. This can happen when you sign in from the public site rather than from a protected link. When that happens, Atloria sends you to the default authenticated area, where you can continue from the main navigation. To confirm that login finished successfully, look for signs that you are back inside Atloria’s workspace: - A left sidebar with app sections - A page header instead of the login form - Your user profile menu or account menu - Workspace pages such as projects, documents, settings, or admin options If you expected a specific screen but landed on the main home area instead, use the sidebar or header navigation to reopen the page you need. This is often the quickest way to continue working. If Atloria accepts your credentials but the browser appears to stay on the sign in page, try these checks: - Wait a moment to see whether the page finishes loading - Refresh the browser tab once - Open the destination again from the main Atloria workspace if you can see the sidebar or header - Sign in again if the login form is still visible and no workspace navigation appears [SCREENSHOT: Authenticated Atloria workspace showing sidebar or header navigation after login] For a broader explanation of how Atloria moves between public pages, login pages, and signed-in workspaces, see [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). ## Resetting Your Password When You Cannot Sign In If your current password no longer works, use the **Forgot password** link on the Atloria sign in page. This option is for cases where the **Password** field value is no longer valid and you need to create a new one before you can log in again. Start by opening the sign in screen and selecting **Forgot password**. Atloria then asks for your account email address. Enter the same email you normally use in the **Email** field when signing in, and submit the reset request. Make sure the address is correct before sending it, because the reset instructions are tied to that account. After submitting the request, check your email inbox for the password reset message from Atloria. Open that message and select the reset link. The link takes you back into Atloria so you can set a new password. On the reset screen, enter your new password, confirm it if prompted, and save the change. Once the password update is complete, return to the Atloria sign in page and log in again with: - Your existing account email address - Your newly created password If you do not receive the reset email right away, wait a few minutes and then check again before submitting another request. Also make sure you are using the same email address that is registered to your Atloria account. [SCREENSHOT: Password reset request screen with email field and submit action] [SCREENSHOT: Password reset screen for entering and confirming a new password] If you are creating a new account instead of recovering an existing one, follow [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account). ## Fixing Common Access and Navigation Problems Most sign in problems in Atloria fall into a few common patterns. Start with the message or behavior you see on screen, then use the matching fix below. If Atloria shows **Invalid email or password**, check both fields carefully: - Confirm the **Email** field contains the correct account address - Re-enter the **Password** field slowly to catch typing mistakes - Try again using the same **Sign in** button on the login screen If your login appears to succeed but you still cannot open the page you wanted, the issue may be access to that area rather than the sign in itself. In that case: - Open the main Atloria workspace - Use the normal sidebar or header navigation - Try opening the page again from inside Atloria - If the area still does not open, your account may not have permission for that workspace For permission-related issues, the best next step is to review your assigned access with an administrator. Related guidance is available in [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). If you seem stuck in a sign in loop, where Atloria keeps returning you to the login page: - Refresh the browser - Close the tab and open the sign in page again in a new tab - Clear stale session data in your browser, then try again - Sign in once more and wait for the workspace to load fully If you are unsure whether login completed, look for workspace elements that only appear after sign in, such as the application header, left sidebar, or your profile menu. If those items are visible, you are inside the authenticated Atloria workspace even if the page is not the one you expected. [SCREENSHOT: Example of authenticated Atloria workspace with sidebar, header, and user menu visible] ## Overview This guide focuses on the parts of Atloria you use when access starts or fails: the public entry point, the sign in screen, the password recovery flow, and the return to the authenticated workspace. The most important screen to recognize is the login page with the **Email** field, **Password** field, and **Sign in** button. If those items are visible, you are at the correct place to enter your account details. Atloria separates public browsing from signed-in work. That difference matters when you are troubleshooting. The public site is where you may see general Atloria information and the top navigation with **Sign in**. The authenticated workspace is where you work with projects, documents, admin tools, and team content. If you are trying to open a protected page without an active session, Atloria may redirect you to the sign in page first. This document also covers what happens after a successful login. In many cases, Atloria returns you to the page you originally tried to open. In other cases, it opens the main workspace instead. You can confirm success by checking for workspace navigation such as a sidebar, page header, or user menu. Use this page when you need help with any of these situations: - Opening the correct Atloria sign in page - Entering your email address and password - Getting back into Atloria after login - Recovering access through **Forgot password** - Resolving repeated login failures or confusing redirects For account creation, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account). For admin-related access questions after login, see [Using the Admin Workspace](doc:using-the-admin-workspace). ## Prerequisites Before you try to sign in to Atloria, make sure you have the basic items needed to complete the login screen and reach the correct workspace. This helps avoid unnecessary retries on the **Sign in** page. You should have: - An active Atloria account - The email address registered to that account - Your current password - Access to your email inbox if you may need to use **Forgot password** - A browser tab open to the Atloria public site or the Atloria sign in page It also helps to know what you are trying to open after login. If you are following a direct link to a project, document area, admin screen, or another protected workspace, Atloria may redirect you to sign in first and then return you to that destination. If you are starting from the public site instead, Atloria may send you to the main signed-in workspace after login. Before troubleshooting, check these simple points: - You are entering your details on the screen that shows **Email**, **Password**, and **Sign in** - You are using the correct email address for your Atloria account - You are not confusing the public site with the signed-in workspace - You know whether you need a password reset or a permission review If you can sign in but cannot reach a specific area, the issue may be related to your assigned access rather than your password. In that case, keep the page name or workspace name handy so you can retry it from the main navigation or discuss it with your Atloria administrator. Permission-related guidance is covered in [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Step-by-Step Instructions 1. Open the Atloria public site and click **Sign in** in the top navigation. If you were trying to open a protected Atloria page, you may already be redirected to the login screen automatically. 2. Confirm that you are on the correct page by checking for the **Email** field, **Password** field, and the main **Sign in** button. 3. Enter your registered email address in **Email**. 4. Enter your current account password in **Password**. 5. Click **Sign in** and wait for Atloria to process your login. Do not close the tab while the page is changing. 6. After the page updates, confirm that you are inside the authenticated Atloria workspace by looking for the app sidebar, page header, or your user menu. 7. If Atloria returns you to the page you originally tried to open, continue working there. If Atloria opens the main workspace instead, use the navigation to reopen the project, document area, or admin page you need. 8. If you see **Invalid email or password**, recheck both fields and try again. 9. If you cannot remember your password, select **Forgot password** on the sign in page, enter your account email address, submit the request, and follow the reset link from your email to create a new password. 10. Return to the sign in page and log in again with your updated password. 11. If Atloria keeps sending you back to the login screen, refresh the browser, open the sign in page again in a new tab, and try once more. 12. If login succeeds but a specific page still does not open, use the main Atloria navigation to retry that area. If it remains unavailable, review your access with your administrator. [SCREENSHOT: Full sign in flow from public site to login page to authenticated Atloria workspace] ## Opening the parsing workspace and preparing your upload In Atloria, start from your project workspace and open the **Code Parsing Workspace** area used for code upload and analysis. If you are entering from a project home screen, first make sure you are in the correct project before you begin. This matters because uploaded files and parsing results stay tied to the project workspace where you add them. Look for the upload entry points on the parsing screen. Depending on what you want to analyze, Atloria may let you add source material through an **Upload** action for files, a folder or archive import option, and a snippet area for pasted code. Before you click anything, decide what kind of source you are bringing in: - A single source file when you want to inspect one file on its own - A compressed project archive when you want Atloria to preserve folders and file relationships - A short pasted snippet when you only need quick analysis of a small section of code If you are uploading multiple files, organize them first so the folder structure is clear. When Atloria shows a workspace tree or file list, that structure helps you move between related files and understand how pieces fit together. A clean upload also makes later documentation work easier because filenames and paths stay recognizable. Check any visible controls at the top or side of the workspace before starting. In some project setups, you may see a project selector, language choice, parser choice, or a documentation-related context setting. Match those options to the source material you plan to upload so the parsing results are easier to review. [SCREENSHOT: Code Parsing Workspace showing upload options, project selection, and workspace file tree] ## Uploading files, folders, and archives into the workspace Once you are in the **Code Parsing Workspace**, use the main **Upload** action to add your source files. If you are working with one file, choose that file from your computer and wait for it to appear in the workspace file list or tree. After the upload finishes, confirm that the filename is visible in the left-side navigator or main file area before moving on to parsing. For a larger codebase, use the folder or archive upload option if it is available on your screen. This is the better choice when your documentation depends on related files being kept together. After the import completes, review the workspace tree and make sure nested folders are still shown in the correct order. You should be able to expand folders and see the same path layout you expect from the original source material. 1. Open the **Code Parsing Workspace** in the correct project. 2. Click **Upload**. 3. Select either an individual file, a folder import option, or a compressed archive. 4. Wait for the upload progress indicator or status message to finish. 5. Check the workspace tree to confirm the uploaded items appear in the expected location. As files are added, watch for progress indicators, status badges, or completion messages. These help you tell the difference between a file that is still being processed and one that is ready for parsing. If you upload more than once into the same project area, review the file list carefully. When Atloria shows duplicate names, pay attention to any replacement prompt or updated entry in the workspace so you do not accidentally work from the wrong version. [SCREENSHOT: Upload dialog with a visible progress indicator and completed files listed in the workspace tree] ## Pasting and parsing code snippets for quick analysis When you do not need to upload a full file or project archive, use the snippet input area in the **Code Parsing Workspace**. This is the fastest option for testing a small block of code, checking how Atloria reads a configuration fragment, or reviewing one focused section before adding larger source material. Open the snippet area or paste dialog and place your code into the text box. Keep the snippet focused and complete enough to make sense on its own. For example, if you only paste part of a block without the surrounding lines it depends on, the parsing result may be incomplete. A slightly larger snippet often gives better results than a fragment that starts or ends in the middle of a structure. Before you run the parse action, choose the matching language or parser option if Atloria shows one. This step is important because the same text can be interpreted differently depending on the selected language. If the language setting does not match the pasted content, the result may miss important structures or show only partial output. 1. Open the snippet input area in the workspace. 2. Paste the code block you want to inspect. 3. Select the matching language or parser option. 4. Click **Parse**. 5. Review the result and decide whether to keep or discard it. Snippet parsing is useful when you only need to inspect one focused piece of source material instead of a full project tree. After reviewing the result, save it if you want to return to it during documentation work. If the snippet was only for a quick check, discard it so the workspace stays tidy and easier to navigate. [SCREENSHOT: Snippet input panel with pasted code, language selection, and Parse button] ## Running parsing and reading the results in the workspace After your files or snippets are in place, start parsing from the workspace controls. In Atloria, this usually begins with a visible **Parse** action on the current file, snippet, or uploaded source area. Once you start, watch the status flow as the item moves from uploaded content to parsed output. A progress state, processing badge, or completion message helps confirm when the results are ready to inspect. When parsing finishes, use the workspace panels to move through the output. Atloria may show a file tree on one side, the source content in a main panel, and a results or detail panel beside it. This layout is especially helpful when you want to compare the original source with the extracted structures Atloria found during parsing. 1. Select the uploaded file, folder entry, or snippet you want to analyze. 2. Click **Parse** from the workspace controls. 3. Wait for the processing status to change to a completed state. 4. Open the parsed result in the result pane or detail panel. 5. Move between files in the workspace tree to review related output. As you read the results, focus on the parts most useful for technical documentation. Depending on what Atloria displays, this may include file-level structures, named items, grouped definitions, comments, or configuration sections. If the workspace shows a breakdown view, use it to understand how a file is organized before you start writing or generating documentation from it. This stage is not just about confirming that parsing worked. It is where you decide whether the uploaded source gives enough detail for documentation tasks such as reference pages, technical summaries, or structured explanations. [SCREENSHOT: Parsed workspace view showing source content beside extracted structures and details] ## Reviewing parsed output for documentation-ready details Before you rely on parsed results for documentation, compare what Atloria shows with the original source layout. Start with the basics: filenames, folder paths, and the visible hierarchy in the workspace tree. If those do not match the source material you uploaded, the documentation you create later may be harder to organize or verify. Next, inspect the extracted details that writers usually need. In Atloria, this may appear as named structures, signatures, relationships between items, comments, or configuration definitions. Review these carefully and check whether the parser captured the important parts of the source instead of only a partial outline. If a file should contain several major sections but only one appears in the results, that is a sign to review the upload or parse settings again. Look closely at any comments, inline descriptions, or metadata surfaced in the result view. These details are often the most helpful starting point for technical documentation because they explain intent, expected behavior, or usage context. If Atloria provides a preview or inspection view, use it to judge whether the parsed output is clear enough to support documentation generation without heavy cleanup. A good parsed result usually has these qualities: - The file and folder names match the original source - The visible hierarchy is easy to follow - Key structures are listed clearly - Comments or descriptive text appear where expected - Related items are grouped in a way that makes sense for documentation If the result looks complete and readable, you are in a strong position to use it in later documentation workflows such as reference review or content generation. [SCREENSHOT: Parsed result detail view highlighting filenames, extracted structures, and comments] ## Common issues when uploads or parsing results do not look right If an upload finishes but nothing appears in the workspace tree, first confirm that you are still in the correct project workspace. In Atloria, uploads belong to the project area where you added them, so switching views can make it seem like files disappeared. Refresh the current project view and check the file tree again before uploading a second time. When snippet parsing returns incomplete results, the most common cause is a mismatch between the pasted code and the selected language or parser option. Reopen the snippet area, verify the language choice, and make sure the pasted block includes enough surrounding context. A very short fragment may not give Atloria enough information to show a useful structure. Archive uploads can also look wrong if the original archive is arranged unexpectedly. If folder relationships seem to be missing, review the imported tree and compare it with the source archive on your computer. If Atloria expands nested directories differently than you expected, recheck the archive contents before uploading again. If parsed output is missing important symbols, comments, or relationships, try these checks: - Re-run parsing on the original file rather than an edited copy - Confirm you selected the correct language or parser option - Review whether the source file may be incomplete or malformed - Compare the parsed result with the source view to see exactly what is missing A missing detail does not always mean the upload failed. Sometimes the source itself lacks enough context for Atloria to extract everything cleanly. When that happens, use a fuller file, a better-organized archive, or a more complete snippet and run parsing again. [SCREENSHOT: Workspace showing an upload completed state alongside a partial or incomplete parsing result] ## Overview The **Code Parsing Workspace** in Atloria gives you a place to bring in source material, run parsing, and inspect the results before using them in technical documentation work. You can work with full files, larger project uploads, or quick pasted snippets depending on how much source material you need to review. This workflow is most useful when you want to: - Analyze code before creating technical documentation - Check file structure and relationships inside a project - Review extracted details such as named structures, comments, and configuration sections - Test a small snippet without uploading a full codebase The main screens and actions in this workflow are straightforward: | Workspace area | What you use it for | |---|---| | **Upload** | Add files, folders, or archives to the workspace | | **Snippet input** | Paste a short block of code for quick parsing | | **Parse** | Start analysis on uploaded content or a pasted snippet | | **Workspace tree** | Browse files and folders after upload | | **Result pane** | Review parsed output and extracted details | As you work, keep your goal in mind. If you only need to inspect one small section, the snippet area is usually enough. If you need relationships across multiple files, upload a structured set of files or an archive so Atloria can preserve the project layout. The better your source material is organized at the start, the easier it is to review and reuse the parsed output later. For a broader view of supported parsing coverage before you upload, see [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage). ## Prerequisites Before you upload anything into the **Code Parsing Workspace**, make sure you have the right project open in Atloria and the source material ready in a format you can review easily. This helps avoid duplicate uploads, misplaced files, and parsing results attached to the wrong project. You should have: - Access to the Atloria project where you want to work - Source material ready as one of the following: - an individual code file - a compressed project archive - a short code snippet for pasting - A basic understanding of which language your source uses so you can choose the right parsing option if Atloria asks for it - Source files organized clearly enough that folder names and file paths still make sense after upload It also helps to decide in advance what kind of result you need. Use a single file when you are checking one source file in isolation. Use an archive or grouped upload when documentation depends on file relationships. Use a snippet when you want a quick answer without adding a larger project set to the workspace. Before starting, verify these practical points: - You are signed in and already inside the correct project workspace - The files you plan to upload are the versions you actually want documented - Any archive you use has a folder structure worth preserving - Your snippet is complete enough to be understood on its own If you need help getting into Atloria or reaching the right project area first, see [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) and [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). The next step is [Managing Code Parsing Workspace Sessions](doc:managing-code-parsing-workspace-sessions). ## Opening the published docs and understanding the page layout When you open published documentation in Atloria, the reading experience is built around three main areas on the page. On the left, you will usually see the **sidebar navigation**. In the center, you will see the **document page** itself, including the page title and article content. On the right, you may see a **table of contents** that lists the headings inside the current page. [SCREENSHOT: Published documentation page showing the left sidebar, main article area, and right-side table of contents] The center content area is the easiest place to confirm where you are. At the top of the article, look for the **document title**. This title tells you which page is open. As you scroll, the section headings inside the article help you understand how the page is organized. Longer pages often use multiple heading levels, which makes it easier to scan before reading in detail. The left sidebar shows the broader documentation structure. This is where Atloria lists categories and individual pages that readers can open. The currently open page is typically highlighted in the sidebar, which helps you confirm that the article on screen matches the navigation item you selected. If you are unsure whether you opened the right page, check both the highlighted sidebar item and the title at the top of the article. This public view is meant for reading, not editing. You are browsing content that has already been organized and published by the documentation team. That means you can focus on moving through categories, opening pages, and using headings to find information quickly, without seeing editing tools or setup controls. ## Browsing categories from the sidebar The **left sidebar** is your main tool for moving through published documentation in Atloria. It usually contains top-level categories, and some of those categories include nested pages underneath them. If you want to explore a topic area, start here rather than scrolling through one long page. Category entries and page links usually serve different purposes. A category represents a section of the documentation, while a page link opens a specific article. When a category contains more content underneath it, you may need to **expand** it to reveal the child pages. If a category is already open, you can often **collapse** it again to reduce clutter and focus on the section you are using. [SCREENSHOT: Sidebar with one category expanded to show nested documentation pages] As you browse, pay attention to the active path in the sidebar. If a page is open inside a category, Atloria highlights the current page so you can see where it sits in the overall structure. This is especially helpful when several pages have similar names. Instead of relying only on the page title, use the sidebar to understand the page’s location inside the larger documentation set. A good way to browse is: 1. Look for the top-level category that matches your topic. 2. Expand that category if you do not yet see the page you need. 3. Review the child pages listed underneath it. 4. Click the page title you want to read. This keeps you inside the same navigation context. You do not need to jump back to a separate home page every time you want to move to another article. The sidebar stays available while you read, so you can continue exploring nearby content without losing your place in the documentation structure. ## Opening document pages and moving between related articles To open an article, click any **document link** in the left sidebar. Atloria loads that page in the main reading area, where you can read the full article without leaving the published documentation view. Once the page opens, check the **title at the top of the article** to confirm you selected the correct document. The page title is your first confirmation point, but it is not the only one. You can also use the article’s heading structure and the sidebar position together. For example, if the title looks familiar but you are not sure it is the right version of the topic, look at the highlighted item in the sidebar and the surrounding pages in the same category. This gives you context for how the article fits into the rest of the documentation. If you want to move to a related article, you usually do not need to return to a separate index page. Instead, stay in the same sidebar category and click a nearby page. This is often the fastest way to move between related topics, such as introductory pages, setup instructions, and follow-up reading in the same section. A practical reading flow looks like this: 1. Open a page from the sidebar. 2. Confirm the page using the title and sidebar highlight. 3. Read the article or scan its headings. 4. Return to the sidebar and choose a nearby page in the same category if you need the next topic. Atloria’s published documentation is easier to browse when pages are arranged in a logical order. Documentation teams can place related pages together so readers naturally move from one article to the next. As a reader, that means the pages listed above and below the one you are viewing are often the most relevant next places to look. ## Using the table of contents to jump within a page When a document page is long enough to include several sections, Atloria may show a **table of contents** on the right side of the screen. This panel lists the headings from the current page and lets you jump directly to the section you want. Instead of scrolling through the entire article, you can click a heading in the table of contents and move straight to that part of the page. [SCREENSHOT: Right-side table of contents with multiple section links and one active section highlighted] The table of contents is built from the headings used inside the document. That means it reflects the actual structure of the article. If a page has clear section headings, the table of contents becomes a quick map of the content. Before reading in full, scan the heading list to see whether the page includes setup steps, explanations, examples, or reference details. As you scroll through the page, Atloria can highlight the heading that matches your current position. This active heading indicator helps you keep track of where you are, especially in long articles with many sections. If you pause reading and return later, the highlighted heading makes it easier to reorient yourself. Use the table of contents when you want to: - Jump to a specific section immediately - Review the structure of a long article before reading - Return to an earlier section without scrolling back manually - Confirm whether the page covers the topic you need If you overshoot a section or decide to revisit something earlier, simply click another heading in the table of contents. This is usually faster and more precise than dragging the page up and down, especially when the article contains multiple subsections. ## Reading efficiently across long documentation pages Long documentation pages are easier to use when you combine the **sidebar** and the **table of contents** instead of relying on scrolling alone. Start with the sidebar to choose the right category and page. Once the page is open, use the table of contents to move directly to the section that matches your task. This approach is especially helpful when page names are similar. Two documents may sound alike, but their sidebar location tells you which topic area they belong to. For example, a page under one category may explain a reader-facing task, while a similarly named page in another category may cover a different workflow. Checking both the page title and its sidebar location helps you avoid reading the wrong article. When you open a long page, do not feel you need to read from top to bottom immediately. Instead, scan the table of contents first and look for the section type you need: - **Setup sections** if you are trying to complete a task - **Concept sections** if you need background before acting - **Reference sections** if you are checking a detail quickly You can then jump straight to the most useful part of the page and return to earlier sections only if needed. This saves time and makes Atloria’s published documentation easier to use during real work. For documentation teams, clear navigation matters just as much as clear writing. Distinct category names and specific page titles help public readers tell pages apart quickly. If readers often open the wrong article first, the issue is usually not the amount of content but how similarly named pages appear in the sidebar and heading structure. ## Fixing common navigation problems If you cannot find the page you expect in Atloria’s published documentation, the first thing to check is the **left sidebar**. A page may be hidden because its parent category is collapsed. Expand the category and look again before assuming the page is missing. If the **table of contents** does not appear, or only shows a few items, the current page may not include enough section headings to build a fuller in-page navigation list. In that case, rely on the article title, visible headings in the content area, and the sidebar location to move around. The page may still contain the information you need even if the right-side navigation is minimal. When you lose your place while reading, use the two built-in orientation markers: - The **highlighted page** in the left sidebar shows which article is open - The **active heading** in the table of contents shows where you are inside that article These two indicators work well together. The sidebar tells you your place in the documentation structure, while the table of contents tells you your place inside the page itself. Common fixes include: 1. Expand collapsed categories in the sidebar. 2. Confirm the page title at the top of the article. 3. Check the highlighted sidebar item to verify the current page. 4. Use the table of contents to jump back to the section you were reading. If readers regularly struggle to browse published documentation, the documentation team may need to improve category nesting, page order, or heading structure. Better category names and clearer section headings make the public reading experience much easier to follow. ## Overview Atloria’s public documentation view is designed to help readers move through published content without needing editing access or project-level tools. The main navigation pattern is simple: use the **left sidebar** to choose a category or page, read the article in the **center content area**, and use the **right-side table of contents** to move within longer pages. The sidebar gives you the full reading structure for the published docs. It shows how topics are grouped and where the current page sits in relation to surrounding articles. This is useful when you are exploring a subject for the first time or when you want to move through a set of related pages in order. The highlighted current page helps you stay oriented. The main article area is where you confirm the page you opened. The **document title** at the top tells you exactly which article is on screen, and the section headings break the content into readable parts. On longer pages, the table of contents adds a second layer of navigation by listing those headings so you can jump directly to the section you need. Together, these three areas support different reading styles: - Browsing by topic through the sidebar - Reading one article in full from the content area - Skimming or jumping within a page through the table of contents If you are new to Atloria’s published docs, focus on recognizing these layout areas first. Once you know how to use the sidebar and heading structure together, it becomes much easier to find the right page quickly and move through related content without getting lost. ## Prerequisites Before you start browsing published documentation in Atloria, make sure you have the basics needed for a smooth reading experience: - Access to an Atloria **published documentation site** - A page layout that shows the **left sidebar** and, on longer pages, the **right-side table of contents** - At least one published category or document page available to open You do not need editing access, project setup access, or admin permissions to follow this guide. This is a public-reader workflow focused on reading and navigating published content. If you need help signing in or creating an account for other parts of Atloria, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). It also helps to be familiar with a few page elements before you begin: - **Sidebar navigation** for categories and page links - **Document title** at the top of the article - **Section headings** inside the page - **Table of contents** for in-page jumps when available If you are reading as part of a larger documentation journey, you do not need to complete any setup steps first. You can begin directly from any published page and use the sidebar to explore from there. For the next topic in this Reader Navigation series, continue with [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content). ## Opening the Admin Workspace and Understanding the Layout In Atloria, the **Admin** workspace is available after you sign in and enter the main authenticated area. If your account has administrator access, you can open the admin area from the main app navigation and land on a dashboard that groups management tools into clear sections. If you do not see **Admin**, your account likely does not have the required permissions for administrative pages. The Admin workspace is designed for configuration and oversight rather than writing or reviewing documentation. Instead of project content, version pages, or document editing tools, you see management entries such as **Users & Permissions**, **Organizations**, **Documents**, **Projects**, and **Analytics**. These entries appear as dashboard cards with a title, short description, and a summary number such as total users, organizations, documents, or active projects. Selecting a card opens the related management screen. At the top of each admin page, Atloria shows a page header with the screen title and a short description. For example, the analytics area displays **Analytics & Insights**, while the security area displays **Security & Audit**. This header helps confirm where you are before you make changes. The main content area changes based on the section you open. Some pages show management lists or settings, while others currently show a “coming soon” message. Atloria keeps these pages inside the same signed-in workspace layout, so moving between admin sections feels consistent with the rest of the app. [SCREENSHOT: Admin workspace dashboard showing cards for Users & Permissions, Organizations, Documents, Projects, and Analytics] If you are new to Atloria navigation, see [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). For broader admin tasks after you arrive here, continue with [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings). ## Managing Users from the Admin Workspace From the Admin workspace, open user management by selecting **Users & Permissions**. This is the main entry point for reviewing who has access to Atloria and what level of control each person has. The card appears alongside other admin options, making it easy to return to related management areas after you finish user updates. Once you are on the user management screen, look for the account list and any search or filtering tools available there. Use the search field to find a person by name or email address, or use filters if you need to narrow the list by role, status, or another visible category. After you locate the correct person, open their record to review and update their details. 1. Open **Admin** from the main app navigation. 2. Select **Users & Permissions**. 3. Use the user list to find the account you want to review. 4. Open the person’s record. 5. Update the available details, such as role or account status. 6. Save your changes if the page includes a **Save** button. Common user management work in Atloria includes: - Reviewing profile details - Updating access roles - Changing whether an account is active - Confirming who should have administrative access After you finish, use the left-side navigation, the browser back button, or the Admin dashboard link to return to the main Admin workspace. Atloria keeps user controls grouped with other administrative areas so you can move directly from **Users & Permissions** to **Security & Audit**, **Analytics & Insights**, or organization settings without leaving the admin context. For a deeper walkthrough of user roles and access decisions, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Accessing Security Pages and Reviewing Administrative Controls To review security-related settings, open the **Security** area from the Admin workspace navigation. In Atloria, this section is labeled **Security & Audit** and is intended for administrators who need visibility into security-related activity and access controls. The page header clearly identifies the screen and includes a short description focused on security logs and audit trail management. When you enter this area, expect security pages to center on administrative controls rather than everyday project work. Depending on what is available in your Atloria environment, these pages may include settings or views related to sign-in behavior, access policies, permission controls, and audit-focused activity records. The purpose of this area is to help administrators review who can access Atloria, how administrative actions are tracked, and where sensitive changes can be monitored. The security area uses the same overall admin layout as other management screens: - A left-side navigation area for moving between admin sections - A page header showing the current screen name - A main content panel for settings, logs, or notices - In some cases, page-specific tabs or sections inside the security screen At the moment, the **Security & Audit** page may show a notice that the feature is still being prepared. Even so, the page location and title make it clear where security review and audit-related tools belong inside the Admin workspace. Be careful when changing any security setting in Atloria. Updates in this area can affect: - How people sign in - Which users can see admin pages - What actions are available to different roles - Whether other users can access specific workspaces [SCREENSHOT: Security & Audit page header and main content area] For more detail on audit-related administration, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls). ## Viewing Analytics and Monitoring Administrative Activity To open administrative reporting, go to **Admin** and select **Analytics**. In Atloria, this page is titled **Analytics & Insights** and is described as a place for usage statistics and performance metrics. It sits alongside the other admin dashboard cards, so it is easy to reach when you want to check adoption, activity, or overall workspace usage. The analytics screen follows the same structure as other admin pages. At the top, you see a clear page header with the **Analytics & Insights** title. Below that, the main content panel is reserved for charts, summary information, and reporting tools. In the current version, this page may display a “coming soon” message instead of full reports. Even so, this is the correct place to look for administrative analytics in Atloria. When analytics features are available, administrators typically use this area to review: - Usage trends across Atloria - Activity levels in shared workspaces - High-level operational metrics - Summary counts that help confirm adoption Common analytics page elements may include: - Summary cards - Charts or graphs - Date range controls - Filters for narrowing results - Activity sections that highlight recent changes These reporting views are especially useful when you need to confirm that teams are actively using Atloria, check whether documentation work is growing, or identify where more support may be needed. Project administrators can use analytics to monitor engagement, while documentation managers can use the same area to understand how broadly Atloria is being used across teams. [SCREENSHOT: Analytics & Insights page with header and reporting area] If you need project-specific reporting rather than admin-wide reporting, see [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). For broader admin reporting guidance, see [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Finding AI Settings and Understanding What Administrators Can Configure AI-related settings are part of Atloria’s broader administrative controls, but they may not appear as a card on the main Admin dashboard shown to every administrator. In practice, AI configuration is usually reached through the administrative navigation or related settings areas available to your account. If your organization has AI features enabled, look for entries connected to AI settings, provider setup, usage controls, or support agent configuration. When you open AI settings in Atloria, expect the pages to focus on configuration choices rather than document editing. Depending on what your organization uses, administrators may see options related to: - Turning AI features on or off - Choosing or maintaining AI providers - Controlling usage limits or request behavior - Managing workspace-level AI availability - Configuring AI support agent access AI settings often connect closely with other admin areas. For example: - **Users & Permissions** helps determine who can access AI-powered features - **Security & Audit** helps administrators review how sensitive features are governed - Organization settings may control whether AI is available across teams or only in selected workspaces Watch for standard settings controls such as toggles, selection lists, and **Save** actions. In Atloria, a change is not always applied the moment you select an option. If the page includes **Save**, click it before leaving. If you are testing access changes, refresh the affected screen or ask another permitted user to confirm the result. Because AI settings can affect multiple teams, make changes carefully and confirm you are working in the correct administrative area before saving. For detailed AI setup guidance, see [Configuring AI Settings for Your Organization](doc:configuring-ai-settings-for-your-organization) and [Setting Up and Maintaining AI Providers](doc:setting-up-and-maintaining-ai-providers). ## Common Issues When Navigating the Admin Workspace If the **Admin** workspace is missing, the most common cause is account access. In Atloria, admin pages are only shown to people with the right administrative role or workspace permissions. Start by confirming that you are signed in with the correct account. If you recently received admin access, sign out and sign back in so the navigation can refresh. In some Atloria environments, certain admin features may also be limited by plan, environment, or rollout status. If you can open **Admin** but do not see **Users & Permissions**, **Security & Audit**, **Analytics & Insights**, or AI-related settings, check whether those pages are available in your workspace. Some sections may be hidden because: - Your account has partial admin rights - The feature is not enabled in your Atloria environment - The page is still being introduced and is not fully available yet When changes you make are not visible to other people, look for a **Save** button before leaving the page. Many admin screens require an explicit save action. After saving, refresh the page you changed and, if needed, ask the other user to refresh their own screen. Also confirm that you updated the correct workspace or organization area, especially if you manage more than one team in Atloria. If navigation feels inconsistent, pay attention to where you are in the interface: - The left-side admin navigation keeps you inside the broader Admin workspace - The page header tells you which management area is open - Some pages may include their own tabs or internal sections - Returning to the Admin dashboard can help reorient you if you feel lost [SCREENSHOT: Admin page showing left navigation, page header, and a selected management section] If sign-in problems are blocking access, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). ## Overview The Admin workspace in Atloria is the central place for platform-level management. It is built for administrators who need to oversee access, review configuration areas, and move between high-level management screens without entering individual project workspaces. Instead of focusing on document authoring, version review, or publishing tasks, the Admin workspace groups together controls that affect people, organizations, reporting, and other shared settings. From the main Admin dashboard, you can open cards such as **Users & Permissions**, **Organizations**, **Documents**, **Projects**, and **Analytics**. Each card includes a short description and a summary value, which helps you quickly understand what the section covers before opening it. Once inside a section, Atloria keeps a consistent layout with a page header and a main content area so you can move between admin screens with less confusion. The most important thing to remember is that the Admin workspace is for oversight and configuration: - Use **Users & Permissions** to manage access - Use **Security & Audit** to review security-focused controls and audit-related areas - Use **Analytics & Insights** to monitor usage and activity when reporting is available - Use AI-related settings areas to control how AI features are enabled and governed If you spend most of your time in project documentation, the Admin workspace will feel different because it is organized around management decisions rather than content creation. That separation helps keep administrative work clear and reduces the chance of mixing platform settings with project-level tasks. For related guidance, see [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings) and [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards). ## Prerequisites Before you use the Admin workspace in Atloria, make sure the following are true: - You can sign in to Atloria successfully - Your account has administrator access or another role that includes admin workspace visibility - You are entering the main signed-in area of Atloria, not just the public documentation view - The admin features you need, such as **Users & Permissions**, **Security & Audit**, **Analytics & Insights**, or AI settings, are available in your Atloria environment It also helps to know what kind of task you are trying to complete before you open the Admin workspace. Different areas support different kinds of work: - Access changes belong in **Users & Permissions** - Security review belongs in **Security & Audit** - Reporting belongs in **Analytics & Insights** - AI configuration belongs in the available AI-related settings pages If you are helping manage a team, gather the details you need before making changes. For example, know which user account you need to update, which workspace or organization you are working in, and whether the change affects only your own access or other people’s access as well. This is especially important when adjusting permissions or AI availability. You should also be comfortable moving through Atloria’s signed-in navigation. If you are still getting familiar with account access and entry points, read [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) and [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation) before making administrative changes. ## Understanding How Audience-Specific Public Views Work When a project in Atloria is published with audience targeting, readers can open the public documentation site and view content that matches a selected audience. The public experience stays focused on reading and navigation: readers arrive on a public page, use the page header controls, and browse a sidebar and page body that reflect the current audience view. This means the same documentation site can present different guidance to different readers without forcing them to sort through unrelated pages. A key part of this experience is the audience selector in the public documentation view. When it is available, readers use it to switch between audience options. After a new audience is selected, the visible content updates to match that choice. Readers may notice changes in the left navigation, the sections shown inside the page, and the related links that appear around the content. Content meant for the selected audience stays visible, while content assigned to other audiences is hidden from that view. Default public content remains available more broadly. Shared pages and shared sections continue to appear regardless of which audience is selected. Audience-targeted content is more specific and only appears when the matching audience is active. If no audience is selected, readers typically see the default public experience, which is the broadest view available on the published site. From a reader’s point of view, the workflow is simple: open the public documentation URL, check the selected audience in the page controls, browse the filtered sidebar, read the page body, and follow links that stay aligned with that audience context. [SCREENSHOT: Public documentation page showing the audience selector, left navigation, and page content area] ## Switching to the Right Audience View as a Reader 1. Open the published documentation site in Atloria and look near the top of the page for the audience selector. This control appears in the public reading experience when more than one audience view is available. If you are reviewing content for a specific reader group, confirm the current selection before you start reading. 2. Click the audience selector and choose the audience you want to view. After you make a selection, the page updates to match that audience. Depending on the page, you may see the content refresh immediately or reload into the selected view. Stay on the same page after switching so you can compare what changed. 3. Review the page body carefully. Audience-specific sections, notes, or callouts should now match the selected audience. You may also notice that some content disappears. That is expected when those sections belong to a different audience. Focus on whether the visible instructions, examples, and supporting details fit the audience you chose. 4. Check the navigation menu on the left side of the page. The available pages and section links should now reflect the same audience context. If the audience view is working correctly, the navigation should guide you only to pages that are relevant for that reader group. 5. Continue browsing by using the sidebar, related links, or in-page links. As you move through the public documentation, the audience context should stay in place so you do not have to reselect it on every page. [SCREENSHOT: Audience selector opened with multiple audience options visible] ## Recognizing What Changes Between Audience Views Audience views in Atloria can change more than just a single paragraph on a page. Depending on how the documentation team has prepared the public site, readers may see different section blocks, notes, supporting guidance, and related reading paths after switching audiences. In some cases, the page title may stay the same while the content inside the page changes. In other cases, the navigation itself may shift so that one audience sees a focused set of pages while another sees a broader or different path through the documentation. The left navigation is one of the clearest places to spot these differences. Child pages that matter to one audience may appear only when that audience is selected. Related article links can also change, helping readers stay within a path that fits their role or use case. This keeps the public site easier to browse because readers are not distracted by pages that do not apply to them. Shared content still remains visible. If a page section is meant for everyone, it continues to appear across all audience views. Only the content that has been targeted to a specific audience changes when readers switch. This mix of shared and audience-specific content is what makes the public documentation feel consistent while still being tailored. Common reader cues include: - The selected audience label in the audience selector - A changed or filtered left navigation tree - Different section blocks or callouts in the page body - Audience-specific banner text or page messaging - Related links that shift to audience-relevant pages When reviewing a page, use these cues together rather than relying on just one visible change. ## Checking Audience Visibility Before Publishing Changes Before you test the public documentation experience, make sure the content you want to review has actually been prepared for audience-based visibility. In Atloria, audience views only make sense when the relevant pages or page sections have been assigned to the correct audiences. If a page is still shared with everyone, switching the audience in the public view may not produce any visible change. Start by confirming that the documentation has been published to its public destination. Audience filtering is best checked in the public reading experience, not only inside the editing workspace. If the latest changes have not been published, the public site may still show an older version of the content and navigation. That can make it look like audience targeting is broken when the issue is simply that the public site has not been updated yet. Next, verify that the audiences you plan to test are available in the audience selector. If you expect to review multiple reader experiences, each target audience should appear as a selectable option in the public documentation header or page controls. If one is missing, you will not be able to validate that view from the public side. It also helps to prepare a simple review list before testing. Include: - Pages that should appear for each audience - Pages that should stay hidden for each audience - Section blocks or callouts that should change - Related links that should update - Navigation items that should remain shared If you need help setting up audiences before this stage, review [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). ## Validating the Public Experience for Each Audience 1. Open the same public page for each available audience and compare what appears on screen. Start with a page that you know contains audience-specific content. Check the page body, the left navigation, and any related links shown nearby. Compare each view against your expected audience plan so you can quickly spot missing or extra content. 2. Test direct page access by opening links to pages that should only matter to one audience. Then switch to a different audience and confirm that restricted sections or audience-specific paths do not appear where they should be hidden. This is especially useful for checking whether a page is truly filtered in the public experience rather than only hidden from the sidebar. 3. Move through the documentation using normal reader actions. Click sidebar items, follow breadcrumbs if they are available, and use in-page links to open related content. As you browse, confirm that the audience context stays consistent. The navigation and page content should continue to reflect the same audience without unexpectedly showing content from another view. 4. Repeat your checks in an incognito window or a signed-out browser session. This helps you verify the public-facing experience as an external reader would see it. It is a useful final check because editing access or saved session state can sometimes make internal testing feel different from the published view. For a broader review process after switching is working correctly, continue with [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation). ## Fixing Mismatched or Missing Audience Content If the public page does not behave as expected, start with the most visible sign: the audience selector. When the selector does not appear, there may not be multiple public audience views available for that site, or the published documentation may not currently expose audience choices. In that case, first confirm that the project has audience views prepared and published. When the wrong content appears after switching audiences, review the audience assignment on the affected page or section in Atloria. A page can remain visible to everyone if it was left as shared content, and a section can stay hidden if it was assigned to a different audience than intended. If only part of a page looks wrong, focus on the specific content block or note that should change between audiences. Missing navigation links usually point to visibility settings on child pages or sidebar entries. If one audience cannot see a page in the left navigation, check whether that page is included in that audience’s public view. Also confirm whether the page should be shared content instead of audience-specific content. If you have updated content but the public site still shows the old version, publish the latest changes again and reload the public page. Then switch audiences one more time to confirm the updated content appears. Use this quick troubleshooting table when reviewing issues: | What you see | What to check | |---|---| | No audience selector | Whether multiple audience views are available in the public site | | Wrong page content | Audience assignment on the page or section | | Missing sidebar links | Audience visibility for child pages or navigation items | | Old content after changes | Whether the latest documentation was published and the page was reloaded | ## Overview Public audience views in Atloria let one published documentation site serve different reader groups without creating separate public sites for each one. Readers open the same public documentation experience, then use the audience selector to view the version of the content that fits them best. Once an audience is selected, Atloria updates the visible page content, left navigation, and related links so readers stay on a path that matches their needs. This is most useful when your team maintains shared documentation with a mix of common guidance and audience-specific instructions. Shared content stays available across all views, while targeted sections only appear for the matching audience. As a result, readers can move through the public site with less noise and fewer irrelevant pages. When you review audience views, focus on three things: - Whether the correct audience options appear in the selector - Whether the page body changes as expected for each audience - Whether the navigation and links stay aligned with the selected audience This document focuses on the public reading experience and the validation steps that help you confirm it is working correctly. If you need to build the audience structure first, start with [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation). If you want help browsing public docs more generally, see [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) and [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content). The next step is [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences). ## Prerequisites Before you review public documentation by audience in Atloria, make sure these basics are already in place: - You have a published documentation site to open in a public browser view - The project already includes at least one configured audience, and ideally more than one if you want to test switching - The pages or page sections you want to review have been prepared with the correct audience visibility - The latest documentation changes have been published so the public site reflects current content - You know which pages, sections, and navigation items should appear for each audience you plan to test It also helps to have a simple audience review plan ready before you begin. For example, list one or two representative pages for each audience, note any sections that should be shared across all views, and identify any pages that should disappear from navigation when a different audience is selected. This makes it much easier to tell whether the public experience is behaving correctly. If you are still setting up the audience structure, review these related guides first: - [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) - [Managing Audience Settings Across the Organization](doc:managing-audience-settings-across-the-organization) - [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation) - [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences) If your goal is to validate the published site from a reader’s point of view, use a signed-out browser session or an incognito window during testing. That gives you a cleaner view of what external readers will actually see. ## Opening the language and parser coverage view To review language support in Atloria, start from the signed-in workspace and open the area where you work with technical documentation or code parsing. If you are still getting familiar with account access and workspace entry, see [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) and [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). 1. Sign in with your **Email** and **Password** on the login screen, then select **Log in**. 2. After Atloria opens your main workspace, go to the project or parsing area used for technical documentation work. 3. Open the screen that shows the **Supported Languages** list or support matrix for parsing. 4. If the page includes tabs or filters, switch to the view that shows all available language entries before narrowing the list. On this screen, focus on the main regions that help you evaluate support quickly: - A **language name** area that lists each programming language. - A **framework** or **ecosystem** area that shows related technologies under that language. - A **parser status** area that tells you whether Atloria can process that language or framework. - A **coverage** area that shows how complete the support is. Some workspaces may also include a **Search** field near the top of the list, along with tabs or filter chips for views such as all entries, parser-ready items, or partial support results. These controls help you reduce a long list to only the entries that matter for your project. [SCREENSHOT: Supported Languages screen showing the search box, language list, parser status badges, and coverage column] If you do not see the language support view yet, you may need to enter the code parsing workspace first. For that workflow, use [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace). ## Reviewing which languages and frameworks are supported Once the **Supported Languages** screen is open, use the list to confirm whether Atloria recognizes the language and framework combination used in your project. This is especially important when your repository includes both a base language and one or more framework layers. 1. Look down the language list to find the programming language you plan to document. 2. Use the **Search** field to narrow the table if the list is long. 3. Check the framework or ecosystem labels shown on the same row or in related rows. 4. Review the support badge or label beside each entry before deciding what content to upload or parse. The search box is the fastest way to confirm support for common languages such as **Python**, **JavaScript**, **TypeScript**, **Java**, or **Go**. After you type a language name, review the matching rows carefully. In Atloria, a language may appear with several framework-specific entries, and those entries may not all have the same support level. For example, a base language can appear separately from framework coverage. That means you may see support for the language itself, while a framework built on top of it has a different status. When framework tags or labels appear, use them to tell the difference between general language support and support for a specific stack. Watch for support badges such as: - **Fully supported** for broad, reliable parsing coverage - **Partially supported** when only some structures are recognized - **Not available** when Atloria does not currently support that entry These labels help you avoid assuming that support for one row applies to every related framework. If your project includes several technologies, compare each row instead of checking only the top-level language name. [SCREENSHOT: Search field filtering the Supported Languages table for a language and showing framework-specific rows] For a deeper comparison of language and framework fit, continue with [Evaluating Language and Framework Support in Atloria](doc:evaluating-language-and-framework-support-in-atloria). ## Checking parser availability before uploading or indexing content Before you upload source material or start a parsing job, confirm that the language or framework you want to use has a parser available in Atloria. This step helps you avoid spending time on files that Atloria cannot process well yet. 1. Find your language or framework in the **Supported Languages** list. 2. Look at the **Parser** column or status badge on that row. 3. Open the row details, expandable panel, or side panel if more information is available. 4. Review any parser notes before choosing files or repositories for ingestion. The parser status is the most direct signal for readiness. Depending on the entry, Atloria may show a status such as: - **Available** if the parser is ready to use - **Unavailable** if parsing is not currently offered - **Beta** if support exists but may still be developing - **Limited** if only part of the language or framework is handled When you can open a row for more detail, look for parser-specific notes. These details may explain which file types are recognized or whether support applies only to certain framework patterns. If your project includes several candidate repositories, compare parser availability across them before deciding what to process first. This is especially useful for mixed-language projects. One repository may include a language with strong parser support and another with only limited support. In that case, start with the source that has the clearest **Available** status so your technical documentation results are more predictable. [SCREENSHOT: Expanded language row showing parser status, notes, and supported file details] If you are preparing to bring code into Atloria next, the related workflow is covered in [Uploading and Parsing Code for Documentation Workflows](doc:uploading-and-parsing-code-for-documentation-workflows). ## Understanding coverage indicators and support depth Parser availability tells you whether Atloria can process a language at all, but the **Coverage** field tells you how much Atloria is likely to recognize once parsing begins. This is where you judge support depth, not just support presence. 1. Find the **Coverage** column or coverage label for your selected language or framework. 2. Check whether coverage is shown as a label, percentage, or both. 3. Compare language-level coverage with framework-level coverage if Atloria shows them separately. 4. Read any notes attached to the coverage result before finalizing your source choice. Coverage may be shown with labels such as **Full coverage**, **Partial coverage**, **Experimental coverage**, or **No coverage**. Treat these as practical guidance for documentation planning: - **Full coverage** usually means Atloria recognizes most expected structures for that entry. - **Partial coverage** means some parts may parse correctly while others may be skipped. - **Experimental coverage** suggests support is still developing and results may vary. - **No coverage** means you should not rely on parsing for that entry. If Atloria shows separate values for the language and its framework, read both. A language may have strong base support while the related framework has narrower recognition. That difference matters when your repository depends heavily on framework conventions rather than plain source files. Coverage notes are just as important as the headline label. They can point out known gaps, such as unsupported syntax, limited metadata extraction, or missing framework conventions. Those notes help explain why a project might parse only part of what you expect. [SCREENSHOT: Coverage column with labels such as Full, Partial, and Experimental, plus expanded notes] For more detail on interpreting these support levels, see [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility). ## Comparing support details to choose the right source material After you review language names, framework tags, parser status, and coverage, use that information to decide what source material should go into Atloria first. This comparison step is useful when a project contains source code, generated reference material, and framework-specific files side by side. 1. Compare the rows for each language and framework used in your project. 2. Prioritize entries with an **Available** parser and stronger coverage. 3. Decide whether to start with source code, generated docs, or framework files based on the support details shown. 4. Note any weak areas before your team begins a broader documentation rollout. A simple comparison often reveals which content will give you the best results. If one language shows a ready parser and high coverage while another shows limited or experimental support, start with the stronger option. That gives your team a more reliable first pass for technical documentation. Use all three signals together: - **Framework tags** tell you whether support applies to your actual stack - **Parser status** tells you whether Atloria can process it now - **Coverage details** tell you how complete the results are likely to be This matters most in mixed-language repositories. A project may include one well-supported language and another with low coverage. In that situation, you may decide to parse only the stronger portion first, then handle the weaker area through existing documentation pages or manual authoring in Atloria. It also helps to record unsupported or low-confidence entries early. Documentation managers, project owners, and admins can then adjust scope, choose a different source set, or delay certain parsing tasks until support improves. [SCREENSHOT: Side-by-side comparison of several language rows with parser and coverage differences] If you are planning documentation work across a project, pair this review with [Using Code Parsing Results to Support Technical Docs](doc:using-code-parsing-results-to-support-technical-docs). ## Resolving missing languages, unavailable parsers, and low coverage results If you cannot find the language you expected, or the support level looks weaker than planned, use the controls on the **Supported Languages** screen to confirm what Atloria is actually showing before you escalate the issue. 1. Enter the language name again in the **Search** field and check the spelling. 2. Clear any active filters, chips, or tabs that may be hiding entries. 3. Reopen the language row and review the parser and coverage notes. 4. Capture the visible details if you need to raise the issue with your Atloria owner or support contact. When a language does not appear at all, the most common causes are a narrow filter or a search term that does not match the listed name. Reset the view to show all entries, then search again. If the language still does not appear, Atloria may not currently list support for it. If the parser status shows **Unavailable**, do not assume the entire language family is unsupported. Check whether support is limited to certain frameworks or file types. A related row may still be usable for part of your project. If coverage is lower than expected, open the notes and look for explanations such as: - unsupported syntax - experimental parser status - framework-specific limitations - reduced metadata extraction When the page still leaves questions unanswered, take screenshots of the exact row, the parser badge, and the coverage details. That gives your internal Atloria owner or support team the context they need to review the issue accurately. [SCREENSHOT: Language row with unavailable parser badge and visible coverage notes] For related admin-side review of activity and controls, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls) and [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Overview Atloria’s **Supported Languages** view helps you answer one practical question before you begin technical documentation work: *Will this source material parse well enough to use?* Instead of uploading code and discovering problems later, you can review language entries, framework labels, parser status, and coverage indicators in one place. Use this screen when you are deciding whether to process a repository, compare two possible source sets, or confirm whether a framework is supported separately from its base language. The most helpful parts of the page are usually the **Search** field, the language list, the **Parser** status area, and the **Coverage** details. Together, these show both readiness and depth of support. Keep these distinctions in mind while reviewing the list: - A language can be listed even if a specific framework under it has different support. - A parser can be available while coverage is still partial. - Coverage notes may explain gaps that are not obvious from the badge alone. - Mixed-language projects should be checked row by row, not assumed from one top-level match. This screen is especially useful before workflows such as code upload, technical reference generation, or project planning for documentation rollout. If your team depends on parsed output, reviewing support first can help you choose better source material and avoid rework. For the broader parsing workflow after this review, see [Managing Code Parsing Workspace Sessions](doc:managing-code-parsing-workspace-sessions) and [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage). The next step in this section is [Evaluating Language and Framework Support in Atloria](doc:evaluating-language-and-framework-support-in-atloria). ## Prerequisites Before using the **Supported Languages** view in Atloria, make sure you have the basic access and context needed to interpret the results correctly. - You can sign in to Atloria with your **Email** and **Password**. - You can reach the authenticated workspace after login. - You have access to the project area, technical documentation area, or code parsing workspace where the language support list is shown. - You know the main languages or frameworks used in the repository or documentation source you plan to review. - You are able to compare your project stack with the entries shown in the **Supported Languages** list. It also helps to gather a short list of what you want to verify before opening the page, such as: - the primary programming language - any major framework used by the project - whether you need parser-ready support now or are only checking future fit - whether your repository includes multiple languages If you are new to Atloria navigation, review [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). If you have not yet connected this review to a parsing workflow, [Using Code Parsing to Support Technical Documentation](doc:using-code-parsing-to-support-technical-documentation) gives the larger context. You do not need to upload code before checking support. In most cases, it is better to review parser availability and coverage first, then decide what content to bring into Atloria. ## Finding projects from the project list In Atloria, the main starting point for project browsing is the **Projects** area. This screen is designed to help you scan available projects before you open any one of them. Instead of dropping you straight into editing work, Atloria first shows a project list where you can review project names and decide which dashboard you want to open. 1. Open **Projects** from the main navigation. 2. Look through the project list for the project you want to review. 3. Use the visible project details in each row or card to confirm you have the right one. 4. Click the project name or select the project entry to open its dashboard. Each project entry is meant to give you quick context at a glance. Depending on what is shown in your view, you may see the **project name**, a **status indicator**, ownership or team information, and a **last updated** signal. These details help you tell similar projects apart without opening them one by one. If several teams work in Atloria, this is especially useful when multiple projects have related names. When the list is long, use the **search box** to narrow results by project name. If filter controls are available, use them to focus on projects by state, such as active or completed work. Sort options are helpful when you want to bring the most recently updated projects to the top. That makes it easier to spot projects that are currently moving versus projects that have been quiet. Selecting a project from this list opens the project’s dashboard first. That dashboard is the overview screen for the project. It lets you review status, activity, and navigation options before you move into detailed workspaces such as documentation, versions, or other project areas. [SCREENSHOT: Project list showing project names, status indicators, search, filters, and sort options] ## Reading project status before opening a dashboard Before you open a project, Atloria helps you judge its condition from the project list itself. The most important clues are the visible **status badges**, **progress signals**, and other summary markers shown beside each project. These indicators are there so you can decide where to focus your attention without opening every dashboard. Projects that are moving normally may show a status that suggests active progress or healthy activity. Others may appear completed, inactive, or in a state that suggests they need attention. If your team uses project dashboards for documentation planning and release coordination, these list-level signals are useful for spotting projects that may need review first. Use the visible status information in this way: 1. Scan the **status badge** beside each project name. 2. Check for any **progress** or **completion** signal shown in the same row or card. 3. Review any visible **last updated** information to see whether work is current. 4. Open the dashboards for projects that look delayed, inactive, or unusually quiet. You may also see milestone-style information such as due-date or completion-related signals in the list or in the dashboard header after opening the project. These are especially helpful when you are comparing several projects at once. A project with a recent update and a healthy-looking status usually needs less immediate attention than one with an older update and a warning-style status marker. For Documentation Managers and Project Administrators, this summary view is a practical triage tool. Instead of opening every project, you can identify which dashboards deserve a closer look based on visible status and activity. That saves time and keeps your attention on projects that are still active, nearing completion, or showing signs that they may be stalled. [SCREENSHOT: Project list with different status badges and recent activity indicators highlighted] ## Opening a project dashboard and understanding what it shows When you click a project in the **Projects** list, Atloria opens that project’s dashboard. This dashboard is the project home screen. It gives you a high-level summary before you move into detailed work. If you are reviewing project health, checking recent changes, or deciding where to go next, this is the screen to use first. 1. Open **Projects** from the main navigation. 2. Select the project you want to review. 3. Wait for the project dashboard to load. 4. Start at the top of the page and review the header and summary information. 5. Use the dashboard sections to decide whether you need to stay in overview mode or open a workspace. At the top of the dashboard, look for the **project header**. This area typically confirms which project you opened and may also show status-related information. Just below that, you can expect a summary area that helps you understand the current state of the project without opening every section individually. The dashboard is meant to surface the most useful overview information in one place. Depending on the project, this can include status, recent activity, assigned work, deadlines, and signs of team participation. These sections help you answer practical questions quickly: Is the project active? Has anything changed recently? Do I need to review documentation work, version work, or another project area? The dashboard also acts as a navigation hub. From here, you can move into project-specific tabs, panels, or linked areas when you are ready to do more than monitor. That makes the dashboard the best place to begin when you want context first and action second. [SCREENSHOT: Project dashboard showing the header, summary area, recent activity, and navigation tabs] ## Moving from the dashboard into project-specific workspaces After reviewing the dashboard, you can move into the project’s working areas. In Atloria, the dashboard is for overview and coordination, while project-specific workspaces are where you actually manage content and project activity. The exact destinations depend on what is available for that project, but the dashboard is the place where those entry points begin. 1. Open the project dashboard from **Projects**. 2. Review the visible tabs, links, or action buttons on the dashboard. 3. Select the workspace you need, such as documentation-related areas, project administration areas, or other linked project sections. 4. Confirm that the project context stays the same after the new screen opens. 5. Use the workspace for detailed work, then return to the dashboard when you need another overview. A key benefit of dashboard-based navigation is that Atloria keeps you inside the current project context. You do not need to go back to the project list and reselect the project every time you switch from one area to another. That makes it easier to move between overview, editing, review, and setup work without losing your place. It also helps to understand the difference between the dashboard and a workspace. Stay on the **dashboard** when you want to monitor status, scan recent activity, or decide what needs attention. Open a **workspace** when you need to make changes, review detailed records, or manage project content directly. For many teams, common next clicks from the dashboard include project administration, documentation areas, version-related work, and technical documentation sections. If you want a closer look at what appears inside the project home after you enter it, continue with [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). [SCREENSHOT: Project dashboard with tabs or links leading into project-specific workspaces] ## Using dashboards to monitor multiple projects efficiently When you manage more than one project, the fastest approach is to combine the **Projects** list with each project’s dashboard instead of opening every workspace. Atloria gives you enough visible information at both levels to decide where your attention is needed. Start with the project list and narrow it before opening anything. Search for a project by name when you already know what you need. Use filters to reduce the list to active or completed projects, and use sorting to bring recently updated work to the top. This helps you create a short review list instead of scanning every project manually. Once you open a dashboard, focus on the summary sections rather than drilling into every area right away. The dashboard is useful for checking whether the project is moving, whether there has been recent activity, and whether the visible status still matches your expectations. If the summary looks current and healthy, you may not need to go any deeper. If the dashboard looks quiet, incomplete, or out of date, that is your signal to open a more detailed workspace. A practical review pattern looks like this: 1. Filter the **Projects** list to the projects you want to monitor. 2. Compare visible **status** and **last updated** signals in the list. 3. Open only the dashboards that show warning signs, inactivity, or recent changes that need review. 4. Use the dashboard summary and recent activity areas to confirm whether action is required. 5. Move into a workspace only when the dashboard suggests follow-up work is needed. This approach is especially helpful for Documentation Managers, project leads, and administrators who need to keep several projects moving without spending time inside every project area every day. ## Common issues when browsing projects and opening dashboards If you cannot find a project or a dashboard does not show what you expect, the issue is often related to the current view rather than the project itself. Start by checking the visible controls on the screen before assuming something is missing. If a project does not appear in the **Projects** list, review the items below: - Clear or adjust the **search box** if you entered a project name. - Check any active **filters** that may be hiding completed or inactive projects. - Change the **sort order** if the project may be lower in the list than expected. - Look for whether the project belongs to a state such as inactive or completed that is not currently shown. If the dashboard opens but expected information is missing, look at the project’s visible activity and summary areas. Some projects may not show much if there have been no recent updates, no assigned work, or no current dashboard content to display. In that case, the dashboard may be accurate even if it looks sparse. If you cannot move from the dashboard into a project workspace, check whether the tab, link, or action button is available on that project. Some projects may not show every workspace entry point, and your access level may also affect what you can open. If the status shown in the project list does not seem to match the dashboard, refresh the page and compare again. Summary indicators may not always appear identical if one area has updated more recently than another. If the difference remains, review recent activity on the dashboard first, since that often gives the clearest picture of current movement. [SCREENSHOT: Project list and dashboard with search, filters, and status areas called out for troubleshooting] ## Overview This guide focuses on the first layer of project navigation in Atloria: finding a project, reading its visible status, opening its dashboard, and deciding whether to stay at the overview level or move into a workspace. The goal is not to teach every project feature at once, but to help you use the **Projects** area and each project dashboard as your main control points for day-to-day project review. The **Projects** list is where you browse all available projects. It helps you identify the right project by name and compare visible status and update signals before opening anything. This is the best place to search, filter, and sort when you need to work across multiple projects or quickly locate one project in a long list. The **project dashboard** is the next step after selection. It acts as the project home screen, giving you a summary of the project and a set of navigation options that lead to more detailed workspaces. That makes it useful for both quick monitoring and deeper follow-up. Instead of jumping directly into detailed records, you can pause at the dashboard to understand the current state of the project first. If you are new to Atloria project navigation, this guide gives you the foundation for the rest of the Project Management section. Later documents build on this starting point by showing what you can do after you arrive at the project home and how to move through project-specific areas with more confidence. The next document in this sequence is [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). ## Prerequisites Before you work with project lists and dashboards in Atloria, make sure the following basics are in place: - You can sign in to Atloria successfully. - You have access to the authenticated workspace where the **Projects** area is available. - At least one project is available for you to open. - You understand basic account access and sign-in steps if you need help getting into Atloria. If you have not signed in yet, start with [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). It also helps to know what kind of work you are trying to do before you open a project. For example: - If you want to review project setup and controls, you will likely use the project dashboard to reach administration areas. - If you want to work on documentation content, the dashboard will be your entry point into documentation-related spaces. - If you want to monitor several projects, you will spend more time in the **Projects** list using search, filters, and status indicators. You do not need advanced setup knowledge to use this guide. You only need access to Atloria, visibility into the **Projects** area, and permission to open the projects relevant to your role. If your menu options or project visibility look different from what is described here, your organization may have limited access based on role or team membership. ## Comparing Connected and Manual Project Setup During Onboarding When you create a project in Atloria during onboarding, you typically choose between two setup paths: a **connected** setup that links the project to an external source, or a **manual** setup where you enter the project details yourself. If you need a refresher on getting to the onboarding flow, see [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding). A **connected** setup is the better fit when your team already has a project, account, or source record in another connected workspace and you want Atloria to start from that existing information. In the onboarding flow, this option lets you pick an available connection, browse or search for the external record, and review imported details before you create the project. The imported values can include the **project name**, related **client or account details**, and other source information shown in the onboarding review step. This helps reduce re-entry and keeps the new Atloria project aligned with the record your team already uses elsewhere. A **manual** setup is the better fit when you want to start with a clean project inside Atloria. In this path, the onboarding form depends on what you type into the setup fields instead of pulling values from a connected source. You enter the core project details directly, choose the internal owner, and set the initial configuration values that should apply from day one. Use this decision guide when choosing: | Setup choice | Best when | What you manage during onboarding | |---|---|---| | Connected setup | Another tool already holds the main project record | Review imported values and confirm the link | | Manual setup | Atloria should be the starting point for the project | Enter project details and defaults yourself | Choose **connected setup** if an external record is already your team’s source of truth or if you expect the project to stay linked. Choose **manual setup** if you do not need that relationship, if the outside record is incomplete, or if you want full control over the starting configuration inside Atloria. ## Checking What You Need Before Choosing a Setup Method Before you decide which setup path to use, make sure you have the right access and the right project information ready. This avoids stopping midway through onboarding and helps you create the project correctly the first time. For a **connected** setup, you need access to a usable connection in Atloria and enough permission to browse the external records available through that connection. During onboarding, Atloria may ask you to complete an authentication step before you can search for the project or account you want to link. If you cannot see the connection, cannot open its records, or cannot finish the sign-in step, the connected option may not be available to you yet. For a **manual** setup, gather the project details you want to enter directly into the onboarding form. At minimum, be ready with the project name and the person who should own or manage it in Atloria. You should also know any internal preferences or defaults your team expects to use from the start, especially if those values would normally come from a connected source. Use this checklist before choosing: - For connected setup, confirm: - A connection is available in Atloria - You can browse or search the external account or project record - You can complete any required sign-in or authorization step - The external record contains the details you want Atloria to use - For manual setup, confirm: - You know the project name - You know who should own the project internally - You know the default preferences or tracking choices your team expects - You are ready to enter any details that will not be imported automatically Avoid connected setup when the source record is incomplete, when you do not have access to the connection, or when you do not want Atloria tied to that outside record. On the other hand, manual setup can create extra follow-up work if you later need to recreate client relationships, add mappings, or re-enter project attributes that a connected setup could have brought in during onboarding. ## Setting Up a Project from a Connected Integration If your team already tracks the project in a connected source, use the connected setup path during onboarding so Atloria can start with the existing record instead of a blank form. 1. Open the project creation flow in onboarding and choose the option for a **connected** or integration-based setup. [SCREENSHOT: Project onboarding screen showing manual and connected setup choices] 2. Select the connection you want to use. If more than one connection is available, choose the one that contains the correct external account or project record. 3. Browse or search for the external record you want to link. Depending on what is available in the connection, you may be choosing an account, a client record, or a project record. 4. Review the imported values before you create the project. Focus on the details Atloria has prefilled from the connected source, such as the **project name**, related **client or account information**, and any other source details shown in the review step. 5. Confirm the project creation to create the Atloria project from the linked record. After the project is created, Atloria uses the imported values as the starting point for the new project. Some project details remain editable in the project settings after creation, especially internal values such as the display name, assignments, and optional configuration choices. If the project stays linked to the connected source, the linked relationship continues to matter for future updates and mapping decisions, so review those values carefully before confirming. Connected setup is especially useful when you want consistency between Atloria and the external record your team already trusts. It reduces manual entry, but it also means you should pay close attention to the review screen so the project starts with the correct linked source and the right imported details. ## Creating a Project Manually When You Need Full Control Choose the manual setup path when you want to define the project directly in Atloria instead of pulling details from a connected source. This is the best option when the project is new, when no connection is available, or when you want to avoid creating an ongoing link during onboarding. 1. In the onboarding project creation flow, choose the **manual** setup option instead of selecting a connection. 2. Enter the required project details in the creation form. At minimum, this includes the **project name** and the other setup fields shown on the screen for administrator-managed defaults. 3. Choose the internal owner and set the starting values that your team wants Atloria to use from the beginning. Because no external source is filling in the form for you, this is where you define the project’s internal categorization and project-specific preferences. 4. Review the form carefully before saving. Manual setup depends entirely on what you enter here, so it is worth checking names, assignments, and default choices before you create the project. 5. Create the project to finish onboarding. [SCREENSHOT: Manual project setup form with project name, owner, and default settings] The main advantage of manual setup is control. You decide exactly how the project starts, and you are not limited by the quality or structure of an outside record. This is useful when the project should be managed only inside Atloria or when the external information is not ready yet. The tradeoff is that anything a connected setup would have brought in automatically must be added later by hand. If you eventually want to connect the project to another source, add mappings, or import related data, you will do that after onboarding from the project’s settings and related setup areas. Manual setup works well when you want a clean starting point, but it requires a little more attention up front. ## Adjusting Project Details After the Project Is Created After onboarding, you can still review and update project information from the project’s settings areas. This is useful whether you started with a connected setup or a manual setup, because the first version of the project often needs small corrections before the rest of the team begins working in it. Open the project from your project list, then go to the project details and related setup areas for that project. If the project uses a connection, also review the integration or mapping area linked to that project so you can confirm the external record is attached correctly and make any follow-up changes that are available there. These are the kinds of values you can typically review and adjust after creation: | Area to review | Common updates after onboarding | |---|---| | Project details | Display name and other visible project information | | Internal assignments | Owner and team-related assignments | | Optional configuration | Default preferences and project-specific settings | | Connected setup areas | Linked source record and related mapping choices | For **connected projects**, post-creation work usually focuses on checking imported values, correcting anything that came in incorrectly, and confirming the linked source is the right one. If you need to change how the project is connected, do that from the project’s connection or mapping settings rather than trying to rebuild the project from scratch. For **manual projects**, follow-up work usually means filling in anything you skipped during onboarding and adding any connection or mapping later if the project eventually needs one. Because there is no external source to backfill missing values, manual projects should be reviewed more carefully after creation. Common adjustments include correcting imported names, filling in missing project details, updating internal ownership, and setting defaults before writers, reviewers, or administrators begin using the project regularly. ## Verifying Your Setup Once the project is created, take a few minutes to confirm everything looks right before your team starts using it. This final check is especially helpful because setup issues are easier to fix immediately after onboarding than after documents, versions, or approvals have already been added. Start in the **project list** and confirm the project appears with the expected name. If your team uses ownership or assignment details in the list or project summary, make sure those values match what you selected during onboarding. If Atloria shows any visual sign that the project was created from a connected source, confirm that it matches the setup path you intended to use. Then open the project and review the main project details. Check that the project opens normally and that the settings screens load without errors or missing information. If you see warnings about incomplete configuration, missing mappings, or unfinished setup, resolve those items before moving on. Use the right verification approach for your setup type: - For connected projects: - Confirm the connection is active - Confirm the linked external record is the correct one - Check that imported values match the source record you selected - Review any mapping or linked setup area for missing items - For manual projects: - Confirm all required fields were saved - Check that the owner and defaults are correct - Review project details for anything left blank - Make sure no expected values were skipped during form entry [SCREENSHOT: Project details screen after creation showing project name, owner, and connection status] If the project opens cleanly, shows the right details, and does not display setup warnings, you are in a good position to continue. The next step is learning how to revisit and manage these setup choices over time in [Managing Project Setup Decisions After Onboarding](doc:managing-project-setup-decisions-after-onboarding). ## Overview This guide focuses on one decision in Atloria’s onboarding flow: whether to create a project from a connected source or enter the project details manually. Both options create a project you can continue working with, but they lead to different setup work during and after onboarding. A connected setup is designed for teams that already have a project or account record elsewhere and want Atloria to begin with that existing information. During onboarding, you select a connection, choose the external record, and review the values Atloria imports before you confirm creation. This path is useful when another workspace already holds the information your team considers authoritative. A manual setup is designed for teams that want to start directly in Atloria. Instead of selecting an outside record, you complete the onboarding form yourself and set the project’s initial details, ownership, and defaults by hand. This path is useful when no connection is available, when the outside information is incomplete, or when you want the project to begin with an internal-only configuration. This guide shows you how to compare the two choices, prepare the information each one requires, create the project using either path, and verify the result afterward. It does not repeat the full onboarding walkthrough from [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding); instead, it helps you make the setup choice inside that flow with more confidence. If you are the person responsible for creating or administering projects, use this guide to decide which setup method will save time now without creating avoidable cleanup later. ## Prerequisites Before you work through this setup decision in Atloria, make sure you are ready to create a project and that you have the information needed for the setup path you plan to use. You should already have access to Atloria and be able to reach the project onboarding flow. If you have not done that yet, start with [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding). This guide assumes you are already at the point where Atloria asks how you want to create the project. Have these basics ready before you begin: - Access to the project creation flow in Atloria - A clear decision about whether the project should start from an external source or from a clean manual setup - The project name and internal ownership details you want to use - Any project defaults or preferences your team expects to set during onboarding If you plan to use a connected setup, also make sure you have: - An available connection in Atloria - Permission to browse or search the external records in that connection - The ability to complete any sign-in or authorization step required during onboarding - Confidence that the external record contains the details you want Atloria to use If you plan to use manual setup, make sure you are prepared to enter all important values yourself, because Atloria will not import missing details from an outside source later in the onboarding form. This preparation is usually enough to move through the setup choice without interruption and create a project that is ready for the next stage of configuration. ## Introduction After you generate a new documentation version in Atloria, the next job is deciding whether that output is ready to move forward. This is where version comparison becomes useful. Instead of relying on memory or scanning pages one by one, you use the version workspace to look at what changed, what still needs attention, and whether the generated content is in a good enough state for review. In Atloria, version work happens inside your project area. From there, you can move between project pages, version lists, analytics views, and related project tools. When you open a version comparison view, the goal is practical: identify meaningful differences, confirm that expected updates appeared, and spot anything that looks incomplete before you send the version into the next stage. This guide focuses on the user-facing workflow for comparing generated output and judging release readiness. It does not repeat how to create a version in the first place. If you need that part, go back to [Generating New Documentation Versions](doc:generating-new-documentation-versions). As you work through comparison, pay attention to visible changes in document content, structure, and project-level signals that help you decide whether the version should stay in progress or move toward review. [SCREENSHOT: version list in a project workspace with a selected generated version ready for comparison] ## Overview In Atloria, comparing version output usually starts from the project workspace where your documentation versions are listed. From that list, you open the version you want to inspect and compare it against an earlier version or the current working baseline. The comparison view helps you answer three questions: - What changed? - Are the changes complete and expected? - Is this version ready for formal review? Atloria also includes related project areas that support this decision. For example, project analytics pages are available from project navigation, and the Admin workspace includes **Analytics & Insights** and **Security & Audit** areas. In the current interface, both of those admin pages show a “coming soon” style notice rather than detailed comparison tools, so your release-readiness decision should stay centered on the version workspace and the visible documentation output. If your team uses screenshots, public documentation previews, or audience-specific content, those checks may also be part of readiness. The comparison step is not only about finding differences between two versions. It is also about confirming that the generated version still matches the structure, wording, and intended scope of your project documentation. A good comparison session usually includes opening the version, reviewing changed pages, checking whether important sections are present, and deciding whether the version is ready to send into the review flow. If you want a broader understanding of statuses and release stages, see [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness). If you want more detail on comparison screens specifically, see [Working with Version Comparison Views](doc:working-with-version-comparison-views). ## Steps Use this workflow when you want to compare a newly generated version and decide whether it is ready for review. 1. Open your project in Atloria and go to the version list for that project. 2. Select the newly generated version you want to inspect. 3. Open the comparison view and choose the version you want to compare against, such as the previous version or current baseline. 4. Review visible differences in page content, structure, and any changed sections. 5. Open important pages directly to confirm the generated output reads correctly in context. 6. Check related items that affect release readiness, such as screenshots, audience-specific pages, or public-facing content if your team uses them. 7. Decide whether the version should remain in progress for more work or move into the review stage. While doing this, focus on the changes that matter most to readers. A version can show many small edits, but the real question is whether the documentation is accurate, complete, and ready for other people to review. If you need help managing statuses after the comparison, Atloria’s version workflow documents cover that next step in more detail. [SCREENSHOT: comparison view showing two versions side by side or a list of changed pages] ## Summary Comparing version output in Atloria is the checkpoint between generation and review. You use the project’s version workspace to open a generated version, compare it with an earlier version, and inspect the visible differences that matter for release decisions. The most useful comparisons are not just about counting edits. They help you verify whether the generated output is complete, readable, and aligned with what your team expected to change. Keep your decision grounded in what you can see on the screen: changed pages, updated sections, document structure, and any related content that affects the reader experience. If a version still has missing sections, unclear wording, or changes that do not match the release scope, keep it in progress and continue refining it. If the output looks complete and the changes are understandable, you can move it into the next review step with more confidence. Atloria also includes admin areas such as **Analytics & Insights** and **Security & Audit**, but those pages are currently presented as future-ready spaces rather than active comparison tools. For release-readiness decisions, stay focused on the project version workspace and the documentation output itself. The next document in this workflow is [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results), which explains how to track generation activity and work with the results list after comparison. ## Prerequisites Before you compare version output in Atloria, make sure you already have the basics in place: - You can sign in to Atloria with your **Email** and **Password** on the login screen. - You have access to the project where the version was generated. - At least one generated documentation version exists in that project. - You have an earlier version, baseline, or current project content available to compare against. - You understand the generation workflow from [Generating New Documentation Versions](doc:generating-new-documentation-versions). If you are new to Atloria access, you may first need the sign-in and account guides: - [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) - [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) You may also find it helpful to be familiar with these project areas before starting: - The project dashboard or project home - The version list for the project - Any page where your team reviews generated documentation - Related project tabs such as analytics or webhooks, if your team uses them for project tracking If you are an administrator, the **Admin** area includes cards such as **Users & Permissions**, **Organizations**, **Documents**, **Projects**, and **Analytics**. Those sections help with broader workspace management, but they are not required to compare a version for release readiness. The key requirement is simple: you need a generated version and a place in the project where you can view and compare it. Without both, you cannot make a reliable readiness decision. ## Step-by-Step Instructions 1. Sign in to Atloria using your **Email** and **Password** on the login page. If your details are incorrect, Atloria shows the message **Invalid email or password**. If something unexpected happens during sign-in, you may see **An error occurred. Please try again.** 2. After signing in, open the main workspace and go to the project that contains the generated documentation version. If you just created the version, continue from the project workflow you used in [Generating New Documentation Versions](doc:generating-new-documentation-versions). 3. In the project, open the version list or version workspace and select the newly generated version. Look for the version you want to evaluate before review or publishing. 4. Start a comparison against the most relevant earlier version. In most cases, this will be the previous release version or the current working version your team has been using. [SCREENSHOT: selecting a generated version and choosing a comparison target] 5. Review the changed output carefully. Focus on page titles, section order, visible content changes, and whether important documentation areas appear complete. Open changed pages directly when a summary view is not enough. 6. Check whether the generated output matches the release scope. If your team expected updates in certain documents, confirm those updates are present. If unexpected pages changed, inspect them before moving on. 7. If your project includes screenshots, public documentation, or audience-specific content, open those related areas and confirm the version still looks ready for readers. 8. Decide what to do next: - Keep the version in progress if the output still needs edits or clarification. - Move it forward for review if the visible content looks complete and accurate. For a deeper comparison workflow after this first pass, continue with [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). ## Key Features Atloria gives you several visible workspace elements that support version comparison and release-readiness decisions. | Feature or screen | What you use it for | What to look for | |---|---|---| | Project version list | Open generated versions and choose which one to inspect | Recent versions, naming, and which version should be compared | | Version comparison view | Review differences between two versions | Changed pages, updated sections, and unexpected edits | | Project workspace navigation | Move between documentation, project tools, and related tabs | Quick access to supporting checks during review | | Admin dashboard cards | Open broader management areas such as **Analytics** or **Projects** | Useful for workspace context, but not the main place for version comparison | | **Analytics & Insights** page | View analytics area from the admin workspace | Currently presented as a placeholder rather than a detailed reporting screen | | **Security & Audit** page | View audit-related area from the admin workspace | Currently presented as a placeholder rather than a full audit review screen | The most important feature for this task is the version comparison view inside the project. That is where you judge whether the generated output is usable. The surrounding navigation matters because release readiness often depends on more than one screen. You may need to move from the version list into individual documents, then back to the project workspace, and sometimes into related project pages. If your team works with approvals, audience settings, or publishing controls, those features come after comparison. At this stage, Atloria helps you inspect the output and make a clear decision about whether the version is ready to proceed. [SCREENSHOT: project workspace navigation highlighting versions and related project areas] ## Tips & Best Practices - Compare against the most meaningful earlier version. If you choose the wrong baseline, the change list can be harder to interpret. - Start with high-impact pages first. Open the documents your readers depend on most before spending time on small wording changes. - Do not rely only on a change summary. If a page looks important, open it and read the content in full context. - Watch for missing sections as well as changed sections. A version can look clean in comparison but still be incomplete when you open the page itself. - If the generated output includes unexpected changes, pause before sending it into review. It is easier to correct issues before reviewers begin commenting. - Use project-level context when deciding readiness. If your team also maintains screenshots, audience-specific content, or public documentation views, check those areas before marking the version ready. - Keep comparison and approval as separate decisions. A version may show the right changes but still need wording cleanup before formal review. - If you need help with statuses, review decisions, or approval handoff, use the related guides: - [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) - [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals) - [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review) When you finish comparing the output and have a sense of whether it is ready, the next useful step is tracking the generation activity itself in [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results). ## Opening the project settings that control webhooks and automation In Atloria, start from the **Projects** area and open the project you want to update. If you have already worked through [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options), return to that same project workspace rather than starting a new setup flow. From the project workspace, open the project’s **Settings** area, where Atloria groups together the controls that affect how the project behaves. 1. Open **Projects** and select the project you want to manage. 2. In the project workspace, go to **Settings**. 3. Look for the section that contains webhook and automation-related controls. On this page, Atloria may group these settings into areas for: - webhook configuration - project behavior toggles - connected workflow controls 4. Check whether the fields and toggles are editable. If you can only view the page and cannot change values or use **Save**, you likely do not have project administrator access. 5. Before making changes, review the current values so you know what is already active. [SCREENSHOT: Project workspace with the Settings area open and webhook-related controls highlighted] Some changes on this page take effect as soon as you click **Save**. For example, turning a project-level control on or off usually changes project behavior right away. Webhook event settings work a little differently: once saved, they affect future project activity that matches the selected events. They do not resend older activity automatically. If your team uses connected workflows outside Atloria, pause before editing anything you do not recognize. A small change in the project’s webhook or automation settings can change whether external tools receive updates from this project. When in doubt, compare the current settings with your team’s expected workflow before saving. ## Entering webhook endpoints and delivery settings Once you are in the correct **Settings** area, find the webhook configuration panel. This is where you tell Atloria where to send project event updates. The most important field is the webhook destination field, where you enter the endpoint used to receive outbound updates from Atloria. 1. In the webhook settings panel, click into the endpoint field and enter the destination URL. 2. Complete any security-related fields shown on the form. Depending on what your Atloria workspace displays, this may include a secret or token field used to secure deliveries. 3. Review the event selection area and choose which project events should trigger a delivery. Atloria may show these as checkboxes, a selectable list, or a multi-select control. 4. Confirm that every required field has a value before saving. 5. Click **Save**. [SCREENSHOT: Webhook settings form showing endpoint field, security field, event selection controls, and Save button] As you fill out the form, pay attention to inline messages under the fields. Atloria may stop you from saving if the endpoint format is invalid, if a required security field is empty, or if the same endpoint has already been added in a way that creates a duplicate entry. These messages usually appear directly next to the field that needs attention, which makes it easier to correct the problem without leaving the page. If the page offers multiple event choices, select only the events your connected workflow actually needs. Sending too many event types can make downstream tools harder to manage. After saving, stay on the page long enough to confirm that the form no longer shows warnings and that the saved values appear in the webhook list or details area. ## Adjusting project controls that affect connected workflows Webhook settings are only part of the picture. In the same **Settings** area, Atloria may also show project-level toggles and selectors that control whether automated updates are allowed, limited, or suppressed. These controls matter because a saved webhook endpoint will only receive updates when the project’s behavior settings allow those updates to be sent. 1. Review the toggles and selectors shown near the webhook settings. 2. Identify which controls affect outbound activity, connected workflows, or project automation. 3. Check each control’s current state before changing it. 4. Update the controls that match the workflow you want this project to follow. 5. Click **Save** if the page requires confirmation for the change to take effect. [SCREENSHOT: Project settings page showing automation-related toggles next to webhook controls] Atloria usually makes the state of each control visible in the page itself. An active control may appear switched on, highlighted, or marked as enabled. A disabled control may appear dimmed or switched off. If a setting cannot be changed, it may appear read-only. Some controls may not affect project behavior until you click **Save**, so watch for unsaved-change indicators before leaving the page. These project controls directly affect downstream behavior. For example, if a project-level automation toggle is turned off, Atloria may stop sending updates even though the webhook endpoint and event selections are still saved. If a control is active, project actions that match your selected events can continue to trigger external notifications or connected workflows. Because of that relationship, always review both parts together: - the webhook entry itself - the project-level controls that allow or restrict automated delivery If your team reports that an integration stopped receiving updates, this settings page is the first place to check. ## Managing existing webhook configurations safely You do not need to remove and recreate a webhook every time something changes. In Atloria, you can return to the project’s **Settings** page and update the existing webhook entry directly. This is the safest approach when you only need to change the endpoint, rotate a secret or token, or adjust which events trigger deliveries. 1. Open the project’s **Settings** page and locate the saved webhook entry. 2. Select the existing webhook configuration you want to update. 3. Edit the fields that need to change, such as the endpoint, security value, or selected events. 4. Click **Save** to keep the existing configuration and apply the new values. 5. Review the saved entry to confirm the changes appear correctly. [SCREENSHOT: Existing webhook entry open in edit mode with endpoint and event options visible] If you need to pause deliveries without losing the setup, use the available toggle or status control instead of deleting the webhook. A disable or off state is useful when you are troubleshooting, changing connected tools, or waiting for another team to finish setup. Later, you can return to the same entry and re-enable it. When removal is necessary, use the delete or remove action shown for that webhook entry. Atloria may show a confirmation dialog or warning before completing the removal. Read that message carefully, especially if the page indicates the action is irreversible. Once removed, the project will no longer send future deliveries through that configuration. After any change, check how the page displays the saved webhook. Atloria may show: - a status badge - an enabled or disabled state - updated field values - a last-updated detail These on-screen details help you confirm which configuration is currently active before you leave the page. ## Reviewing validation messages and permission-related limits When Atloria does not let you save a webhook configuration, the reason is usually visible on the page. The webhook form depends on required fields, and Atloria uses inline validation messages to point out exactly what needs to be fixed. Start by checking the fields that are essential for saving. | Field or control | What to check | |---|---| | Endpoint | Must contain a valid destination URL | | Secret or token field | Must be completed if Atloria marks it as required | | Event selection | Must include the project events needed for delivery | [SCREENSHOT: Validation messages shown under webhook fields after a failed save attempt] Common validation states include an invalid URL format, a missing required value, or a warning that the same endpoint already exists. If Atloria rejects a value, the message usually appears directly below or beside the field. Correct that field first, then try **Save** again. Permissions also affect what you can do on this page. Users without project administrator access may see the settings but find that fields are read-only, toggles cannot be changed, or the **Save** button is unavailable. In some cases, Atloria may hide certain controls entirely. If you expected to edit the page but cannot, compare what you see with another administrator or ask someone with project administration rights to confirm your access level. Also pay attention to edit behavior: - **Save** commits your changes - **Cancel** discards the edits currently on the form - unsaved-change indicators mean you have changed something but have not committed it yet If you navigate away before saving, your edits may be lost. It is worth pausing for a final review before leaving the page. ## Testing the configuration After saving the webhook settings, verify that the configuration works before you rely on it for live project activity. The simplest way to test it is to perform a project action that matches one of the events you selected in the webhook settings. This confirms both the webhook entry and the related project controls are working together. 1. Save the webhook configuration and stay on the project’s **Settings** page if possible. 2. Trigger a project action that matches one of the selected events. 3. Return to the webhook area and look for any delivery status, test result, or recent activity feedback shown on the page. 4. If Atloria offers a test delivery action, use it to confirm the endpoint is reachable. 5. Review the result and make changes if the delivery does not succeed. [SCREENSHOT: Webhook settings page showing saved configuration and delivery status or test feedback] If updates are not arriving, re-check the same items in this order: - the endpoint URL - the secret or token field - the selected events - any project-level automation toggle that could block outbound delivery A webhook can look complete but still fail if one of those settings does not match the connected workflow. For example, the endpoint may be saved correctly, but no delivery will happen if the event you tested was not selected or if outbound activity is turned off at the project level. If **Save** fails before you can test anything, read the field-level messages carefully. Atloria usually points to the exact problem. Also confirm that you have permission to edit project settings. A permission limit can look like a broken save process when the real issue is that the page is view-only for your account. ## Overview This page in Atloria is for project administrators who need to control how a project sends automated updates to connected tools. The main work happens inside the project’s **Settings** area, where webhook configuration and related project behavior controls appear together. That layout matters because webhook delivery is not just about entering an endpoint. The project’s automation settings also determine whether Atloria actually sends outbound updates when project activity occurs. Use this settings page when you need to: - add a webhook destination for project event delivery - secure deliveries with a secret or token field if shown - choose which project events trigger outbound updates - pause, re-enable, edit, or remove an existing webhook - review validation messages before saving changes This guide focuses only on the controls relevant to webhook setup and connected workflow behavior. It does not repeat the broader project settings and website options covered in [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). If you need help with general project setup, branding, or website-facing options, use that guide first and then return here to finish the automation-related settings. As you work through this page, pay close attention to what Atloria shows after each change. Saved values, status badges, disabled controls, and inline warnings all help you confirm whether the configuration is active and whether your account is allowed to change it. For teams that depend on external notifications or automated follow-up actions, these details are important because a single toggle or missing field can change how the project behaves outside Atloria. ## Prerequisites Before you update webhook settings in Atloria, make sure the project and your access are ready. This page is easiest to complete when you already know which project should send updates and which external destination should receive them. You should have the following in place: - access to the correct project from the **Projects** list - permission to open the project’s **Settings** area - project administrator rights if you need to edit fields, toggles, or use **Save** - the destination endpoint value you plan to enter in the webhook settings - any required secret or token value if your team uses secured webhook delivery - a clear idea of which project events should trigger outbound updates It also helps to have already completed the earlier project settings work described in [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). That earlier setup gives you the right project context before you start changing automation-related controls. If you are preparing to test the webhook after saving, make sure you can perform at least one project action that matches the events you select. Without a matching project action, it is harder to confirm whether the webhook is working as expected. Finally, if your team uses connected workflows heavily, review the current settings before editing them. Existing webhook entries, enabled toggles, and selected events may already support live processes. Careful review helps you avoid interrupting notifications or automation that other users depend on. For the next part of project setup, continue with [Configuring Project Identity and Delivery Options](doc:configuring-project-identity-and-delivery-options). ## Opening the project home and identifying administrator tools If you already know how to move around Atloria’s project list from [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards), the next step is opening a specific project and using its home area as your control center. From the project selector or project list, choose the project you want to manage. Atloria opens that project inside the main workspace, where the project home becomes the starting point for administrative work and documentation work. At the top of the project home, look for the project header. This area typically gives you the project name and the main navigation options available inside that project. From here, administrators use the project home to move into the areas that matter most for setup and oversight: - **Onboarding** - **Project settings** - **Analytics** - **Versions** - **Audit records** - **Technical documentation tools** [SCREENSHOT: project home header with the main project navigation options highlighted] These areas serve different purposes. **Onboarding** helps you finish setup tasks. **Project settings** is where you maintain project details and access-related controls. **Analytics** helps you review usage and performance trends. **Versions** lets you inspect release organization and current documentation status. **Audit records** shows a history of important changes. **Technical documentation tools** let you continue into the documentation side of the same project without switching context. Not every person who can open a project will have the same level of control. A **project administrator** usually handles setup, access, and governance decisions. A **documentation manager** may work in the same project home but focus more on versions, documentation structure, and publishing-related tasks. When both roles use the same project, the project home helps them stay aligned because they are working from the same project context, even if they use different tabs and actions. Use the project home whenever you need to confirm project readiness, review change history, or move from administration into documentation maintenance without losing your place. ## Completing onboarding tasks from the project home The **Onboarding** area is the first stop when a project is new or when major setup changes need to be reviewed. Open the project home, then select **Onboarding** to see the setup progress for that project. Atloria uses this area to show the tasks that still need attention before the project is fully ready for ongoing documentation work. Inside onboarding, look for checklist-style items or progress indicators that show what has already been completed and what is still incomplete. These items help you verify whether the project has the basic information and controls needed for a stable documentation workflow. Administrators should use this area to confirm setup work such as: 1. Reviewing the project’s core details 2. Confirming access-related setup 3. Checking documentation readiness before active use [SCREENSHOT: onboarding area with setup checklist and completion status indicators] The project home also helps you spot incomplete work without opening every section one by one. If onboarding is not finished, status indicators on the home area make that visible at a glance. This is useful when you are responsible for several projects and need to quickly identify which ones still need administrative attention. Revisit onboarding when the project changes in a meaningful way. Common examples include: - A change in project ownership - A new team or environment being added - A shift in how documentation is created, reviewed, or published - A restart of setup after earlier work was left incomplete Onboarding is not only for first-time setup. It is also a practical review tool when a project’s structure or responsibilities change. If documentation managers report that publishing, version work, or technical documentation tasks are blocked, checking onboarding can help you confirm whether the project still meets the required setup expectations. When the onboarding area shows that all required items are complete, you can move into settings, versions, and documentation work with more confidence that the project foundation is in place. ## Updating project settings and access-related configuration From the project home, open **Project settings** whenever you need to update the project’s administrative details. This area is where you review the configuration categories available for that project and make changes that affect how the project is managed in Atloria. Start by checking the core project information shown in settings. This is the best place to confirm that the project details still match how the team is using the project. When you update project information in settings, those changes are reflected back in the project home, helping everyone see the current project identity and status from the main workspace. [SCREENSHOT: project settings screen with project information and access-related sections] Project administrators should also review any project-level controls related to access and membership. Depending on what is available in your project, this can include: - Who can enter the project - Which team members can manage project configuration - Which users are limited to documentation work - Other project-level controls tied to access or oversight These changes should be made carefully because they affect who can work inside the project and what they can do once they are there. If you are adjusting permissions or member access, confirm the impact before saving so you do not accidentally remove access needed for version work, reviews, or publishing preparation. Some settings updates should be coordinated with documentation managers. In particular, talk through changes that could affect: - Documentation structure - Version workflows - Publishing readiness - Technical documentation maintenance - Team responsibilities inside the project For example, if you change project access or reorganize who manages the project, documentation managers may need to adjust review steps or confirm that the right people still have access to versions and documentation tools. Use the project home after saving changes to verify that the project still presents the expected navigation and that the team can continue working without interruption. If you need broader administrative guidance beyond a single project, see [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings) and [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Reviewing analytics and version activity from the home area The project home gives administrators a quick path into both **Analytics** and **Versions**, which are often reviewed together. Open **Analytics** from the project home when you want to understand how the project is performing from a usage and activity standpoint. In Atloria, the analytics area is labeled **Analytics & Insights** and is intended for usage statistics and performance metrics. [SCREENSHOT: Analytics & Insights screen opened from the project home] If the analytics area is available but not yet active in your workspace, you may see a coming-soon style message rather than detailed charts. Even so, the project home still treats analytics as a dedicated administrative area, and it remains the place you will return to when usage reporting is available for your project. Next, move into **Versions** from the same project home to review release history and the current state of your documentation versions. This is where administrators and documentation managers can inspect whether a version is current, in progress, or no longer the main release being used by readers. Analytics and versions are most useful when you compare them together: 1. Open **Versions** to identify the version you believe is active. 2. Open **Analytics** to review whether that version is actually being used as expected. 3. Compare recent publishing activity with usage patterns before making release decisions. This review pattern helps with practical decisions such as: - Checking whether a newly published update is being adopted - Deciding whether an older version can be archived - Confirming whether a low-usage version still needs to remain available - Reviewing whether documentation activity matches release expectations If you are preparing to make changes to version organization, review the version workspace first, then use analytics to support the decision rather than relying on assumptions. For deeper version guidance, continue with [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). ## Using audit records to track administrative changes When something changes in a project and you need to know what happened, open **Audit records** from the project home. This area is for tracing actions, not measuring usage. It helps administrators review the history of important project events and understand who made a change, when it happened, and what part of the project was affected. In the audit view, review each entry for the key details that help with investigation: | Audit detail | What to look for | |---|---| | **Timestamp** | When the change happened | | **Actor** | Who performed the action | | **Event or action** | What type of change was made | | **Affected area** | Which project area was involved, such as settings, access, or versions | [SCREENSHOT: audit records list showing timestamps, users, and event descriptions] Use audit records to review administrative events such as: - Changes to project settings - Access or membership updates - Version-related actions - Other documentation-related administrative changes This is especially helpful when a project starts behaving differently than expected. For example, if a team member reports that access changed, a version status looks different, or a project setting no longer matches prior decisions, the audit trail helps you verify whether the change was intentional and who made it. Audit records are different from analytics. Choose **Audit records** when you need accountability and change tracing. Choose **Analytics** when you need usage trends or performance patterns. If you are trying to answer “Who changed this?” or “When did this start?”, use audit records first. If you are trying to answer “Are people using this?” or “Did activity increase after release?”, use analytics instead. For broader audit and security review practices, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls) and [Managing Audit Exports and Activity Records](doc:managing-audit-exports-and-activity-records). ## Working with technical documentation tools from the project home The project home is not only for administration. It also acts as the bridge into the project’s documentation work. From the same project context, you can move from setup and oversight into **technical documentation tools** without going back to the project list or switching to another workspace first. This matters most for documentation managers and project administrators who work closely together. A documentation manager may begin on the project home to confirm the project’s current state, then move into version work or technical documentation views. An administrator may start in settings or audit records, then open the documentation side of the project to confirm that the project is ready for editing, review, or publishing-related work. [SCREENSHOT: project home with links to versions, analytics, and technical documentation tools] Common handoffs from administration into documentation work include: 1. Checking **Project settings** before editing or publishing documentation 2. Opening **Versions** to confirm the correct release structure 3. Moving into technical documentation tools to continue content work in the same project 4. Returning to **Audit records** if a documentation-related change needs to be traced This workflow is useful because it keeps governance tasks and documentation tasks connected. Instead of treating project administration and technical documentation as separate activities, Atloria lets you manage both from the project home. That makes it easier to confirm readiness before work begins and easier to investigate problems if something changes later. Use the project home as your central workspace whenever you need to balance project configuration with documentation maintenance. Start there to confirm the project is correctly set up, move into versions to check release structure, and then continue into the technical documentation area for the actual content work. The next document, [Exploring Technical Documentation Inside a Project](doc:exploring-technical-documentation-inside-a-project), walks through that documentation side in more detail. ## Overview Use the project home in Atloria as the main entry point for project administration. It brings together the areas administrators and documentation managers use most often, including **Onboarding**, **Project settings**, **Analytics**, **Versions**, **Audit records**, and the project’s **technical documentation tools**. Instead of opening separate workspaces for each task, you can stay inside one project and move directly to the area you need. The project home is especially useful when you need to combine governance work with day-to-day documentation support. For example, you might open onboarding to confirm setup progress, move to settings to adjust project details, check versions to review release status, and then open technical documentation tools to continue content work. If something looks wrong after a change, audit records help you trace what happened. Keep these points in mind: - Use **Onboarding** to track setup completion and revisit project readiness after major changes. - Use **Project settings** for project details and access-related configuration. - Use **Analytics** to review usage and performance trends when available. - Use **Versions** to inspect release organization and current documentation status. - Use **Audit records** to investigate who changed something and when. - Use the project home as the handoff point between administrative work and documentation maintenance. [SCREENSHOT: complete project home showing the main administrative and documentation areas] If you need help getting back to the right project before starting, return to [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards). ## Prerequisites Before you manage a project from the project home, make sure you can open the project and that your role includes the areas you need to use. Some people may be able to view a project but not change settings or review administrative records. You should have: - Access to sign in to Atloria - Permission to open the target project - A role that allows project administration, or a documentation management role if you are handling versions and documentation tasks - A project that already exists in the project list or project selector It also helps if you already know how to: - Open a project from the project list - Recognize the main dashboard and project navigation - Switch between project areas without losing your place If you have not done that yet, read [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) first. You may also want the right people available before making changes in the project home: - A project administrator for settings and access decisions - A documentation manager for version and content coordination - Team members who can confirm whether a change affects publishing or documentation workflows If you cannot see **Project settings**, **Analytics**, **Audit records**, or other project home options mentioned in this guide, your current role may not include those areas. In that case, ask a project administrator or organization administrator to confirm your access. If you are still getting into Atloria for the first time, start with [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). ## Opening a document and understanding its review modes In Atloria, start from your project’s documentation area and open the page you want to review from the docs list. When the document opens, use the top area of the page to orient yourself before making any changes. This header is where you typically confirm the document title first, then check any visible status information and the most recent update details. If you are reviewing a page that has already been worked on by others, this top section helps you confirm that you are looking at the right document before you begin. As you move through the page, Atloria presents the same content in two different working styles: an editable writing view and a read-only reader view. In the editable view, you work directly in the document and use writing controls to update headings, paragraphs, lists, and other content blocks. In the read-only view, those editing controls are replaced by a cleaner reading layout so you can judge the page the way a reader will experience it. This is especially useful after you have already learned the writing basics in [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages). Use the document actions at the top of the page to switch between **Edit** and **View** or **Preview**, depending on the labels shown in your workspace. When you switch modes, the content itself stays recognizable. You should still see the page title, section headings, body text, and other visible document details, but the editing tools no longer appear in the read-only layout. [SCREENSHOT: Document page showing the top header with title, status, last updated details, and Edit/View actions] A good habit is to open a page in read-only mode first, scan the structure, then return to **Edit** only after you know what needs attention. That keeps your review focused on the reader experience instead of only the writing canvas. ## Reviewing document details before making changes Before you change the main body of a page, review the document details that control how the page is identified and found in Atloria. Open the document settings area, details panel, or sidebar attached to the page and inspect the visible fields. The most important items to confirm are usually the **Title**, **Slug**, and **Description** or summary text if those fields are available on the page. These details affect how the document appears in lists, navigation, and published views, so they should match the page content before you start revising the body. If Atloria shows ownership details, also check the visible author or owner information. This helps when you need to confirm who last worked on the page or who is responsible for its accuracy. For teams managing many pages across one project, this step prevents updates from being made to the wrong document or to a page that belongs to another content owner. You should also review any organization fields used to place the page correctly for readers. Depending on what your workspace shows, this can include items such as collection, category, tags, or audience-related settings. These fields are not just labels. They influence how readers discover the page and how the content fits into the rest of the documentation set. A quick review checklist for the details area: | Field or detail | What to confirm | |---|---| | Title | Matches the page topic and reader intent | | Slug | Clearly reflects the page name | | Description | Summarizes the page accurately | | Author or owner | Shows the correct content owner | | Collection, category, tags, or audience | Places the page in the right location for discovery | Also look for visible state indicators such as **Draft**, **Published**, or signs that the page has changed since it was last published. If the page includes linked assets, references, screenshots, or embedded content blocks, confirm they are still current before editing the main text. [SCREENSHOT: Document details panel showing title, slug, description, and organizational fields] ## Comparing changes and checking what was updated When you need to understand what changed, open the document history, revision list, or compare view from the document’s review actions. This view is useful when a page has been updated over time and you want to inspect the current draft against an earlier saved version. Instead of reading the entire page line by line, you can focus on the exact sections that were added, removed, or rewritten. In Atloria’s compare view, look for visual highlights that separate different kinds of edits. Added content is usually shown as new text, removed content appears as deleted text, and modified content appears where wording has changed between versions. Review these highlights carefully in both the main body and the document details. A page can look similar at first glance while still having important changes in the title, description, or organizational settings. Use comparison for more than paragraph edits. It is especially helpful when someone has: - renamed the page - updated the summary - changed section order - revised headings - adjusted tags, category placement, or audience-related details Choose your comparison point based on the review goal. Compare against the last published version when you want to answer, “What will readers see as different if we publish this now?” Compare against the most recent draft revision when you want to answer, “What changed since the last round of internal editing?” Those are two different review questions, and using the wrong baseline can make the changes look larger or smaller than they really are. [SCREENSHOT: Compare view showing highlighted additions, removals, and modified text] If a page is under active team review, it helps to compare before making your own edits. That way, you avoid undoing someone else’s work or reorganizing a section that was already intentionally updated. ## Organizing content so readers can scan and navigate it A well-organized page is easier to review and much easier to use after publishing. In Atloria, start by checking the heading structure across the document. Long pages should be broken into clear sections with consistent heading levels so the outline or table of contents can present the page in a useful way. If a page jumps between heading styles or uses headings only for visual emphasis, readers may struggle to scan it and navigation links may become unclear. As you review the body, group related information into sections that reflect how someone actually uses the page. Instead of leaving large blocks of uninterrupted text, separate content into short paragraphs, bulleted lists, numbered steps where needed, callouts, or other content blocks available in the editor. This makes the page easier to scan in both the editing view and the published-style reader view. Place the most important information first. For task-based pages, move the action a reader needs most toward the top. Supporting explanations, exceptions, and background details can come later. For reference-style pages, keep labels and section names specific so readers can jump directly to what they need. Check these items while reorganizing: - section headings clearly describe the content below them - link text tells readers where the link goes - anchor headings are meaningful when shown in a table of contents - related instructions stay together instead of being split across the page - repeated information is consolidated into one clear section [SCREENSHOT: Document editor showing a long page reorganized into headings, lists, and clearly separated sections] If you are cleaning up a page after writing, avoid changing everything at once. First improve the structure, then review wording. That makes it easier to compare revisions later and easier for teammates to understand what kind of update was made. ## Switching between editing and read-only views to validate the reader experience After reorganizing a page, switch out of the editor and open the read-only or preview view to confirm that the page works well for readers. This step matters because a page that feels clear inside the editing canvas can still look uneven once Atloria displays it in its reader layout. Use the top document actions to move from **Edit** to **View** or **Preview**, then read the page from top to bottom as if you were seeing it for the first time. Focus first on structure. Confirm that headings break the page into sensible sections and that lists appear as expected. If the page includes tables, images, screenshots, or embedded content, check that each item displays cleanly and sits in the right place relative to the surrounding text. A section that looked fine while editing may feel too long, too crowded, or out of order in the read-only view. Navigation is the next thing to test. If the page includes a table of contents, in-page anchors, or linked references, click through them and make sure they lead to the correct section. Headings should be distinct enough that navigation labels are meaningful on their own. If multiple sections have vague names, the reader view will expose that problem quickly. Use this review cycle: 1. Open the page in **Edit** and reorganize the content. 2. Switch to **View** or **Preview**. 3. Scan headings, lists, tables, images, and links. 4. Test navigation elements such as anchors or section links. 5. Return to **Edit** and correct anything that feels unclear. [SCREENSHOT: Same document shown in read-only view with headings, content blocks, and reader navigation] Move back and forth between the two modes as needed. Short review loops are usually more effective than making a long series of edits and checking the reader view only at the end. ## Fixing common review and organization issues If the compare view is confusing, the most common cause is the wrong comparison point. Open the revision list again and confirm which saved version or published version you selected. If you compare the current draft to an unrelated earlier revision, the page may appear to have far more changes than it actually does. When your goal is release review, compare against the last published version. When your goal is internal editing review, compare against the latest draft revision instead. Another common issue appears when the page looks organized in the editor but not in the read-only view. This usually happens when heading levels are inconsistent or when text that should be separate sections is still grouped into one block. Return to **Edit** and check whether headings are being used consistently from one section to the next. Also review lists, callouts, and other content blocks to make sure they are formatted as distinct elements rather than pasted in as plain text. If document details such as **Title**, **Description**, or tags seem to be missing, reopen the document settings panel or details sidebar and verify that the information was actually saved. Sometimes the issue is not that the field is unavailable, but that the latest edits were not stored before switching views. Re-enter the values if needed, save your changes, and then reopen the page to confirm they remain in place. You may also run into problems switching between modes. Typical causes include: - unsaved changes prompting you to confirm before leaving the editor - read-only access that prevents editing - limited permissions that hide certain actions - restricted access to published-style viewing in a shared review workflow If mode switching is blocked, save first and try again. If the **Edit** action or review actions are unavailable, compare your access with a teammate who can edit the same page, or review your role in the project workspace. [SCREENSHOT: Unsaved changes prompt or disabled mode-switching action on a document page] ## Overview This guide focuses on the review side of document work in Atloria rather than the writing basics. You use these steps after a page already exists and you need to check its details, inspect changes, improve structure, and confirm how it appears to readers. The main workflow is simple: open the document, review its visible details, compare revisions when needed, reorganize the content for clarity, and switch into a read-only view to validate the final reading experience. The most important idea is that a strong document is not only well written in the editor. It also needs clear metadata, a sensible structure, and a reader-friendly layout outside the editing screen. That is why this guide combines document details, revision review, and content organization into one process. In practice, these tasks support each other. A title change may require a new section heading. A structural rewrite may need a compare check. A clean editor layout still needs to be tested in preview. Use this guide when you need to: - review a page before making updates - understand what changed between revisions - reorganize long content into clearer sections - confirm that the reader view matches your intent - fix issues with metadata, formatting, or mode switching If you still need help with writing directly in the page, return to [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages). The next step after this guide is [Managing Project Content from Drafts to Published Pages](doc:managing-project-content-from-drafts-to-published-pages), which covers how reviewed content moves forward toward publication. ## Prerequisites Before you work through this review process in Atloria, make sure a few basics are already in place. This guide assumes you are not starting from a blank page. You should already have access to a project workspace and at least one existing documentation page that you can open from the docs list. If you need help creating or editing page content first, use [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) before continuing here. You will get the most value from this guide if the document already contains enough content to review in context. A page with headings, body text, and some document details is easier to organize than a nearly empty draft. If your team uses review rounds, it also helps to have at least one earlier saved revision or a published version available so you can use the compare view meaningfully. Before you begin, confirm the following: - you can open the correct project and reach its documentation list - you can open an existing document page - you can access **Edit** and **View** or **Preview** actions for that page - the page has visible details such as title and description if your workspace uses them - there is enough existing content to review for structure and readability - if revision comparison is part of your task, the page has earlier saved work or a published version to compare against If some actions are missing, your access level may limit what you can do on that page. In that case, continue with the parts of the guide that are available to you, such as read-only review, and coordinate with a teammate for editing or revision comparison access. ## Starting from Public Pages and Choosing an Account Entry Point Before you enter your workspace in Atloria, you begin on a **public page**. From there, the main account entry points are the **Sign in** screen and the **Create account** screen. If you already have access, choose **Sign in**. If you are new to Atloria and need your own login, choose **Create account**. The registration screen asks for **Name**, **Email**, and **Password**, while the sign-in screen asks for **Email** and **Password**. [SCREENSHOT: Public page header showing account access links such as Sign in and Create account] Atloria separates pages into two groups: - **Public pages**, which you can open without signing in - **Account-only pages**, which require an active session If you try to open an account-only area without being signed in, Atloria sends you to the **Sign in** screen first. After you sign in successfully, Atloria takes you into the account area. In the current flow shown here, a successful sign-in sends you to the main authenticated area at **/app**, which is the starting point for the dashboard-style workspace. Choose **Create account** when you do not yet have login details and Atloria allows self-registration. After registration, Atloria signs you in automatically and opens the account area. Choose **Sign in** when your account already exists, including cases where an administrator has already created access for you or invited you to join. In those cases, you do not need to register again unless you have been specifically told to create a new account. If you need help with the basics of reaching these screens or creating your first login, see [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account). ## Signing In and Establishing an Authenticated Session On the **Sign in** screen, enter your **Email** and **Password**, then select the **Sign in** button. While Atloria is checking your details, the page enters a loading state so you know your request is being processed. If your details are correct, Atloria signs you in and opens the main account area. [SCREENSHOT: Sign in screen with Email field, Password field, Sign in button, and error message area] The sign-in screen in this flow includes these user-facing elements: - **Email** field - **Password** field - **Sign in** button - An **error message area** when sign-in fails If the email and password do not match an account, Atloria shows the message **Invalid email or password**. If something goes wrong during the sign-in process for another reason, Atloria shows **An error occurred. Please try again.** No separate **Forgot password** option or single sign-on option is shown in the available screen details here, so users should expect a standard email-and-password sign-in flow. After a successful sign-in, Atloria creates your active session and changes what you can open. Account-only pages under the authenticated workspace become available, and Atloria redirects you into the main account area at **/app**. That redirect is immediate, so you do not need to select another button after sign-in succeeds. If you are registering instead of signing in, the **Create account** screen collects **Name**, **Email**, and **Password**. When registration succeeds, Atloria attempts to sign you in automatically using the same email and password. If the account is created but the automatic sign-in does not complete, Atloria shows this message: **Registration successful, but login failed. Please try logging in.** For help with sign-in errors, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). ## Arriving in the Account Area After Access Is Granted Once Atloria accepts your sign-in, you are taken into the authenticated workspace at **/app**. This is the point where the interface changes from public access to account access. Instead of public entry screens, you now see the dashboard-style layout used for signed-in pages. [SCREENSHOT: Main authenticated workspace after sign-in, showing dashboard layout and navigation] The exact first page depends on where you were sent after authentication, but the shared layout for signed-in users is consistent. In this authenticated area, Atloria wraps pages in a dashboard layout, which means you should expect account navigation and workspace structure that are not available before login. From the available screens in this context, one clear destination inside the account area is the **Admin** workspace. The **Admin** page includes cards linking to: - **Users & Permissions** - **Organizations** - **Documents** - **Projects** - **Analytics** Each card includes a short description and a small stat, such as **Total Users**, **Organizations**, **Total Docs**, or **Active Projects**. This tells you that once you are signed in, Atloria can present role-based work areas rather than a single flat menu. Some pages also have clear signed-in headers, such as: - **Analytics & Insights** - **Security & Audit** These headings confirm that you are inside protected account areas rather than public pages. In practice, what you see first may depend on your role, your organization access, or the link you used to enter Atloria. A standard user may land in a general workspace or project area, while an administrator may move directly into broader management screens such as **Users & Permissions**, **Organizations**, or **Security & Audit**. If you want a fuller tour of the administrative workspace after you arrive, see [Using the Admin Workspace](doc:using-the-admin-workspace). ## Moving Between Account Screens Without Losing Context Inside the authenticated workspace, you move between pages using account navigation rather than public links. Based on the available screens, Atloria supports movement between major areas such as **Admin**, **Projects**, **Documents**, **Organizations**, **Analytics**, and project-specific pages like **Analytics** and **Webhooks** inside an individual project. [SCREENSHOT: Authenticated navigation showing links to Admin, Projects, Documents, and project-level pages] A few navigation patterns are visible in the current flow: - **Top-level account areas** open inside the signed-in dashboard layout - **Admin cards** act as shortcuts to management screens - **Project-specific pages** open within the context of a selected project That project context matters. For example, project pages such as **Analytics** and **Webhooks** are tied to a specific project, so when you open those pages, Atloria keeps you inside that project’s workspace instead of sending you back to a general home page. This helps you move between related pages without losing track of which project you are working in. If you open a bookmarked account page while you already have an active session, Atloria should take you straight to that page instead of asking you to sign in again. If the page belongs to a specific project, organization, or admin area, your access still depends on whether your current account can open that area. When moving around, use the navigation that appears inside the signed-in layout whenever possible. That keeps you in the correct workspace and reduces the chance of landing on a page that does not match your current role or project. For a deeper look at project-level movement, see [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). ## Handling Redirects, Access Checks, and Session Boundaries Atloria makes a few important decisions each time you open an account-only page. The outcome depends on two things: whether you are signed in, and whether your account is allowed to open that specific area. The main routing outcomes are: - **You have a valid session and the right access**: Atloria opens the page - **You are not signed in**: Atloria sends you to **Sign in** - **You are signed in but do not have permission**: Atloria prevents access to that page This is the difference between **sign-in status** and **page permission**. Sign-in status answers, “Are you logged in?” Permission answers, “Are you allowed to open this screen?” For example, you may be able to sign in successfully but still be unable to open **Users & Permissions**, **Organizations**, **Analytics**, or **Security & Audit** if those areas are limited to administrators or specific members. When your session ends, Atloria treats you like a signed-out user again. Common session boundary events include: - **Manual sign-out** - **An expired session** - **Access being removed** - **Opening a protected link from outside Atloria without an active session** In those cases, Atloria routes you back through the sign-in flow before allowing access to protected pages. If the page is available after you sign in and your account still has permission, you can continue into the workspace. If not, you may be redirected to a safer destination such as the main account area instead of the page you originally tried to open. Some protected pages are also role-sensitive. A direct link may work for one user and fail for another, even if both can sign in. For more on permission-based access after login, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Fixing Common Problems When Users Cannot Reach the Right Account Screen If Atloria does not take you to the page you expect, start by matching the problem to what you see on screen. Most access issues fall into a small number of patterns. If Atloria sends you back to **Sign in** after you just logged in, check these points: - Make sure you saw a successful sign-in rather than an error such as **Invalid email or password** - Try opening the main account area again after sign-in - If the page keeps returning to **Sign in**, your session may not be staying active in the browser If you land on the wrong page after authentication, compare what happened with the normal post-login behavior in this flow: - Successful sign-in sends you to the main authenticated area at **/app** - Successful registration also signs you in and then opens **/app** - If you expected a different destination, the page may require a different role, project membership, or a specific saved link If you can sign in but cannot open a specific account page, the most likely cause is access level. Check whether the page belongs to an admin-only area such as: - **Users & Permissions** - **Organizations** - **Analytics** - **Security & Audit** If a bookmarked account page opens as an error or blank state, test whether the problem is tied to the link itself or to your session: - Open the same page after signing in fresh - Try entering through the main account area first - Confirm that the page still exists and belongs to a workspace you can access When the problem is specifically related to sign-in behavior, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If the issue is about admin-only pages, continue with [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls) or [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity), depending on the screen you are trying to reach. ## Overview Atloria has a clear split between **public pages** and **authenticated account areas**. Public pages are where you begin, using **Sign in** if you already have access or **Create account** if you need to register. Once Atloria confirms your details, it opens the signed-in workspace and makes account-only navigation available. The key points to remember are: - **Sign in** uses **Email** and **Password** - **Create account** uses **Name**, **Email**, and **Password** - Successful sign-in redirects you to the main account area at **/app** - Successful registration also signs you in automatically and then opens **/app** - Protected pages require both an active session and the right permission level Inside the account area, Atloria uses a dashboard-style layout for signed-in pages. From there, users can move into workspace areas such as **Projects**, **Documents**, and, where allowed, admin pages like **Users & Permissions**, **Organizations**, **Analytics**, and **Security & Audit**. Project-specific pages such as **Analytics** and **Webhooks** keep you inside the selected project context. This document focuses on how Atloria moves you between entry points, sign-in, redirects, and protected pages. For the first part of the account access journey, including reaching the login and registration screens, return to [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account). ## Prerequisites Before the navigation patterns in this guide will make sense in your own Atloria workspace, you should already have a basic account entry path available to you. That usually means one of these situations: - You already have an Atloria account and can use the **Sign in** screen - You can use the **Create account** screen to register - An administrator or team owner has already arranged your access You should also be familiar with the basic account access screens covered in [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account), especially: - How to reach the **Sign in** page - When to use **Create account** - Which fields appear during registration - What a successful account setup looks like To follow the account navigation examples in this guide, it helps if you can already do the following: - Enter your **Email** and **Password** on the sign-in screen - Recognize common sign-in messages such as **Invalid email or password** - Open the main signed-in workspace after login - Identify whether a page belongs to a general workspace, a project area, or an admin area If your next task is to work inside the signed-in workspace rather than just reach it, the best follow-on guide is [Using the Admin Workspace](doc:using-the-admin-workspace) for administrative navigation or [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) for day-to-day project access. ## Opening the technical documentation area from a project From your project workspace in **Atloria**, open the current project and use the project navigation to enter its **technical documentation** area. This section belongs to the project you are already viewing, so the pages you open here reflect only that project’s generated reference content. If you switch to a different project first, the technical documentation area will show that other project’s API and reference pages instead. When the technical documentation area opens, look for the main landing content on the page. You will typically see a **project documentation overview**, along with navigation options that lead deeper into generated reference sections such as **API documentation** and **entity reference pages**. These links help you move from a high-level view of what has been generated into more detailed technical pages without leaving the project. This project-level entry point is useful when you want to confirm what technical documentation exists for the current project before reviewing details. It keeps your work grounded in the same project context you used on the project home and related project screens covered in [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). As you enter this area, expect access to depend on your role in the project or organization. In practice, **Documentation Managers**, **Project Administrators**, and **Technical Writers** are the people most likely to use this section because it supports documentation review and technical content validation. If the project opens normally but this area is not available, your access may be limited to other project screens. [SCREENSHOT: Project workspace navigation with the technical documentation entry highlighted] ## Using the project documentation overview page The **project documentation overview** page is the starting point for generated technical content inside a project. Use it when you want a quick picture of what Atloria has already produced for this project before opening detailed reference pages. Instead of dropping you directly into a single endpoint or entity page, the overview helps you understand the available documentation areas at a glance. On this page, look for sections, links, or cards that point to the project’s **API documentation** and **entity-specific reference pages**. These entry points act like a table of contents for the project’s technical material. If you are checking coverage, this is usually the best place to begin because it shows which parts of the project’s technical documentation are available and ready to inspect. The overview is especially helpful when you are comparing what should exist in the project with what has actually been generated. A **Technical Writer** might use it to decide where to start reviewing. A **Project Administrator** might use it to confirm that the project contains the expected technical sections before sharing the workspace with others. A **Documentation Manager** might use it to spot missing areas quickly. As you move into deeper pages, keep the overview in mind as your return point. If you open an API page or an entity page and want to reorient yourself, use the project documentation navigation to go back to the **overview**. Returning there is the easiest way to switch from one reference area to another without losing track of the current project. [SCREENSHOT: Project documentation overview page showing links to API and entity reference sections] ## Browsing generated API documentation To open the project’s **API documentation**, start from the **project documentation overview** and select the **API** link, card, or navigation item. This takes you into the generated API reference for the current project. Because this area stays inside the same project workspace, the API pages you see are tied to that project rather than to your organization as a whole. Within the API section, generated pages are organized so you can browse the project’s available operations in a structured way. Depending on the project content, you may see the reference grouped by **endpoint areas**, **operations**, or related sections of the API. This layout helps you scan the available material instead of opening pages one by one without context. On an API reference page, focus on the details that help you understand how the endpoint behaves. Typical items to inspect include: - **Endpoint path** - **Supported methods** - **Request details** - **Response details** - Related generated reference information shown on the page These pages are useful when you need to confirm what the generated technical documentation says about a specific API operation. A writer may review the request and response sections before drafting user-facing guidance. An administrator may use the same page to verify that the project’s generated reference looks complete. When you want to move around, use the in-page navigation and project documentation links. You can go back to the **project documentation overview** to choose another section, or move across to a related **entity reference page** if you need to inspect the underlying project structure connected to what you are reading in the API documentation. [SCREENSHOT: API documentation page with endpoint path, methods, request details, and response details visible] ## Exploring entity-specific reference pages Entity-specific reference pages let you inspect the project’s generated documentation for a particular project-defined resource. You can reach one of these pages either from the **project documentation overview** or by following a related link from the **API documentation** area. This is helpful when an API page points you toward a specific entity and you want to understand that item in more detail. On an entity page, look for the main reference details presented for that item. These pages typically show information such as: - The **entity name** - Its **fields** - Its **relationships** - Other generated technical details included for that entity This view is useful because it gathers the project’s structural information into a single page inside the documentation area. A **Technical Writer** can use it to understand what fields should be described in supporting documentation. A **Project Administrator** can use it to confirm that the generated reference reflects the project structure they expect to see. In both cases, the work stays inside the project’s documentation section, so there is no need to jump out to unrelated project screens. As you review one entity page, use the project documentation navigation controls to move to another. This may be through links in the surrounding navigation, links on the page itself, or a return to the **overview** before selecting a different entity. That makes it easier to compare related entities and check whether the generated reference is complete across the project. [SCREENSHOT: Entity reference page showing entity name, fields, and relationships] ## Moving between overview, API, and entity pages efficiently Inside a project, the main browsing flow is straightforward: **project documentation overview → API reference → entity-specific reference pages**. In Atloria, this flow works best when you treat the overview as your home base, then move into API or entity pages only when you need more detail. That approach helps you stay oriented, especially in projects with a larger amount of generated technical content. Several navigation elements can help you keep your place while moving between sections: - **Sidebar links** for switching between documentation areas - **Breadcrumbs** that show where the current page sits inside the project - **Page headers** that confirm whether you are in the overview, API, or an entity page - **Back-to-overview** actions or equivalent navigation links Different roles often browse in different patterns. Common examples include: - **Documentation Managers** starting on the **overview** to check what technical coverage exists for the project - **Technical Writers** opening **API reference pages** to inspect endpoint paths, methods, requests, and responses - **Project Administrators** using **entity pages** to validate fields and relationships for project structures The important point is that the **project context stays preserved** while you move. If you entered technical documentation from a specific project, the overview, API pages, and entity pages all remain tied to that same project. You do not need to reselect the project each time you switch sections. If you feel lost, return to the **overview** and continue from there. This browsing pattern also prepares you for the workspace-level navigation covered next in [Managing Project Workspaces and Recent Activity](doc:managing-project-workspaces-and-recent-activity). ## Fixing common problems when technical documentation pages are missing or incomplete If the **technical documentation** entry point does not appear in the project navigation, first confirm that you are inside the correct project workspace. Since this area is project-specific, opening a different project may show different documentation options. If the project is correct and the navigation item is still missing, your role may not include access to the project’s generated technical documentation. If the **overview page** opens but the **API** or **entity reference** sections are empty, treat that as a content availability issue rather than a navigation problem. The overview may be available even when detailed generated reference content has not been produced or is not currently visible for that project. In that case, compare what you expected to see with what is actually listed on the overview page. When links between the **overview**, **API**, and **entity pages** do not match the project you expected, check that you started from the right project before entering the technical documentation area. Because Atloria scopes this content to the current project, the most common reason for unexpected reference content is that you are browsing inside a different project than intended. If you can open the project itself but not the generated technical documentation area, the issue is usually related to access rather than the project being unavailable. This can affect users who can work in some project screens but do not have permission to open technical reference content. Useful checks include: - Confirm the **current project name** before opening technical documentation - Return to the **project documentation overview** to verify what sections are available - Use project navigation instead of browser history when switching between sections - If access still seems limited, compare your available options with those used by **Documentation Managers**, **Project Administrators**, or **Technical Writers** [SCREENSHOT: Project documentation area with empty or unavailable API/entity sections] ## Overview Use the project’s **technical documentation** area when you need to review generated reference content without leaving the current project workspace. In Atloria, this area is designed for browsing technical material that belongs to one project at a time, which makes it easier to validate coverage and inspect details in context. The main parts you work with are: - The **project documentation overview** as the starting page - The **API documentation** section for generated endpoint and operation details - The **entity reference pages** for project-specific structures, fields, and relationships A practical way to use these pages is to begin on the **overview**, confirm what has been generated, then open the **API** or **entity** sections based on what you need to review. If you are checking high-level coverage, stay on the overview longer. If you need field-level or request-level detail, move into the deeper reference pages. Keep these points in mind while browsing: - The content is **scoped to the current project** - Navigation inside the documentation area helps you move between overview and detailed pages - Returning to the **overview** is the easiest way to reorient yourself - Access to these pages may differ by project role If you need more detail on reading technical reference content itself, continue with related guides such as [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages) and [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation). ## Prerequisites Before using the project’s technical documentation area in **Atloria**, make sure you already know how to open and work inside a project workspace. This guide assumes you can reach the correct project and use its main navigation. If you need help with that first, review [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). You should also have the right kind of access for the project. This guide is most relevant for users working in roles such as: - **Documentation Managers** - **Project Administrators** - **Technical Writers** These users are the most likely to see and use generated technical documentation inside a project. If your project workspace opens but the technical documentation area is not available, your current permissions may not include it. To follow the tasks in this guide successfully, you should be able to: - Open the intended **project workspace** - Use the project navigation to find documentation-related sections - Recognize the **overview**, **API**, and **entity** areas once they appear - Stay within the same project while moving between technical pages It also helps if the project already contains generated technical documentation. If the overview page appears but detailed sections are empty, the project may not yet have visible API or entity reference content to browse. The next guide in this sequence is [Managing Project Workspaces and Recent Activity](doc:managing-project-workspaces-and-recent-activity), which builds on this project-level navigation and shows how to move through the wider workspace more confidently. ## Reviewing the settings that shape agent replies In Atloria, start from the support agent area for the project or workspace where the agent is already set up. If you still need to connect the agent to the right workspace or knowledge sources, use [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup) before changing reply behavior. Open the agent’s settings and look for the behavior options that control how the agent answers. These settings are the ones to review before you change anything customer-facing, because they affect the style and confidence of every reply the agent gives in the places where it is enabled. Focus on these kinds of behavior choices when you review the current setup: - Whether replies should be brief and direct or more detailed and explanatory - Whether the agent should stay tightly grounded in your documentation - Whether the agent should answer broadly or defer when the available documentation is limited - Whether the reply style matches your support team’s tone Before you make changes, compare the current settings as a group instead of adjusting one option in isolation. A concise reply style can work well when your documentation is strong and easy to search, but it can feel abrupt if customers usually need step-by-step help. A more detailed style can be useful for onboarding or troubleshooting, but only if the linked documentation is complete enough to support those answers. [SCREENSHOT: Support agent settings screen showing behavior options for reply style, answer scope, and documentation-backed responses] As you review the screen, check whether the current behavior matches the support experience you want customers to have. If the team expects the agent to answer only from published guidance, keep the documentation-focused settings tighter. If the team wants more conversational help in mature documentation areas, you can allow a broader answer style, but only after confirming the content is accurate and current. ## Setting where agents are available to customers After reviewing reply behavior, decide exactly where the support agent should appear. In Atloria, availability should be limited to the support surfaces where the agent has the right documentation and the right audience. This prevents customers from seeing the agent in places where it cannot help confidently. 1. Open the support agent settings for the agent you want to update. 2. Find the availability or placement section that controls where the agent is shown. 3. Select the support surfaces where the agent should be active, such as documentation-assisted entry points, support-facing areas, or other enabled customer help locations in Atloria. 4. Review any workspace, project, or team assignment options and make sure the agent is only attached to the intended areas. 5. Check any routing or visibility choices that affect whether customers go directly to the agent, directly to a human team, or through a mixed handoff flow. 6. Click **Save** and return to the relevant support areas to confirm the agent appears only where you selected. Use narrow availability when you are testing a new agent or when the documentation only covers one product area. Use broader availability only when the support content is mature across all assigned projects or teams. A few checks help prevent accidental overexposure: - Confirm the correct workspace is selected before saving - Review project assignments if multiple documentation sets exist - Check team-level visibility if different support groups handle different topics - Reopen the settings after saving to verify the selected locations stayed in place [SCREENSHOT: Availability settings showing selected support surfaces and project or workspace assignments] If customers should still be able to reach a person quickly, review the handoff choices carefully. The best setup is usually one where the agent appears in the right places, answers within documented scope, and leaves a clear path to human support when needed. ## Aligning agent behavior with your documentation The most important rule when configuring a support agent in Atloria is simple: the agent should only be as confident as your documentation allows. If your help content is detailed, current, and well organized, the agent can usually answer more directly. If your content is incomplete, outdated, or still being reorganized, the agent should be more cautious. Start by comparing the agent’s behavior settings with the actual state of the documentation it uses. Ask whether the linked content covers the topics customers are most likely to ask about. If the answer is no, tighten the behavior settings so the agent stays closer to documented guidance and defers more often when the answer is unclear. This alignment matters most in these situations: - **Strong documentation coverage:** You can allow more complete and confident answers because the agent has reliable material to work from. - **Partial documentation coverage:** Keep replies narrower and encourage deferral when the answer is not clearly supported. - **Outdated documentation:** Reduce answer scope until the content is reviewed and updated. - **New product areas:** Limit the agent to basic, documented questions until the knowledge base matures. A practical review process works better than one-time setup. After a major documentation update, support leads and project administrators should revisit the agent settings and ask: - Did new pages expand the topics the agent can safely answer? - Were any old pages removed or replaced? - Do current replies still match the published guidance? - Should the agent be more detailed, or more cautious, than before? [SCREENSHOT: Agent settings beside project documentation pages used to review answer scope] If the documentation changes significantly, treat behavior settings as part of the release work. Review them after major edits, version updates, or audience changes. That keeps the support experience aligned with what customers can actually read in Atloria, instead of letting the agent drift beyond the documented truth. ## Configuring team-level rules for support goals Different support teams often need different agent behavior. In Atloria, the settings for a support agent should reflect the kind of conversations that team handles. A team focused on onboarding may want more guided, explanatory replies. A team handling sensitive account or billing questions may want faster escalation and less agent-led interpretation. A technical support team may need the agent to stay tightly tied to documentation and defer quickly when the answer is uncertain. 1. Open the support agent settings for the team, workspace, or assigned support area you want to review. 2. Identify the behavior choices that affect reply style, answer scope, and fallback handling. 3. Match those settings to the team’s support goal. For example, use more guided replies for onboarding and stricter documentation-backed replies for technical troubleshooting. 4. Review the escalation or fallback options and decide when the agent should stop answering and hand the conversation to a person. 5. Apply the same standards across similar projects or queues so customers get a consistent experience. 6. Save the changes and document who approved them if the update affects live customer support. A simple way to keep teams aligned is to define shared rules such as: | Support area | Preferred behavior | Fallback approach | |---|---|---| | Onboarding | More detailed, guided answers | Hand off when questions go beyond setup guidance | | Technical support | Documentation-first answers | Defer when the answer is not clearly documented | | Billing or account help | Narrower, cautious answers | Route to a human team quickly | [SCREENSHOT: Team-specific support agent settings showing behavior and fallback choices] It is also important to decide who can change these settings. In many teams, project administrators review documentation fit, while support leads approve customer-facing behavior changes. Keeping that approval path clear helps prevent one team from changing reply style or escalation behavior in ways that affect customers unexpectedly. ## Testing how agents respond after configuration changes After you change behavior or availability settings, test the agent before leaving the new configuration in place for customers. In Atloria, testing should happen in every support surface where the agent is enabled, not just in one location. An agent can appear correctly in one area and still be misconfigured in another if assignments or routing were set too broadly. 1. Open each support surface where the agent is supposed to appear. 2. Confirm the agent is visible only in those selected locations and does not appear in unrelated projects, workspaces, or support areas. 3. Start a few test conversations using common customer questions. 4. Check whether the replies match the selected behavior, including tone, level of detail, and how closely the answer stays tied to documentation. 5. Ask at least one question that is outside the documented scope. 6. Confirm the agent defers, stops short, or routes the conversation according to the fallback settings you chose. 7. Share the test results with support leads and project administrators before treating the updated setup as ready for customers. Use a mix of test questions: - A straightforward question covered clearly in your documentation - A question that needs a step-by-step answer - A question from a weak or incomplete documentation area - A question that should trigger a handoff to a human team [SCREENSHOT: Test conversation showing an in-scope answer and an out-of-scope fallback response] When you review the results, look for consistency. The agent should sound like the support team, stay within documented guidance, and behave the same way across all enabled entry points. If one test surface behaves differently, go back to the availability and behavior settings before rolling the change out more broadly. ## Fixing common configuration problems Most support agent issues in Atloria come from one of four areas: availability, reply behavior, documentation quality, or fallback setup. When something feels off, check those areas in that order instead of changing multiple settings at once. If the agent is answering in the wrong channel, project, or workspace, reopen the availability settings first. Review every selected support surface and confirm the correct workspace, project, or team assignment is applied. If the agent appears somewhere unexpected, the availability scope is usually too broad. If the replies do not match your support standards, go back to the behavior settings. Check whether the current setup is allowing answers that are too broad, too detailed, or not closely tied to documentation. A mismatch in tone or answer style usually means the reply behavior was configured for a different support goal than the one your team actually follows. If the answers feel weak or inconsistent, inspect the documentation the agent depends on. The issue may not be the agent settings at all. If the linked documentation is outdated, incomplete, or uneven across topics, the agent will struggle to answer consistently. In that case, update the content first, then retest the same questions. If customers are not being handed off correctly, review the fallback or escalation choices and test again with clearly out-of-scope questions. The agent should not continue improvising when the topic is outside documented guidance. Use this quick troubleshooting view: - **Wrong location:** Recheck availability selections and assignments - **Wrong answer style:** Review tone, detail level, and answer scope settings - **Weak answers:** Confirm the documentation is current and broad enough - **No proper handoff:** Recheck fallback behavior and retest outside documented topics [SCREENSHOT: Support agent settings screen highlighting availability, behavior, and fallback sections] If the problem started after a recent documentation update, compare the current setup with the latest published content before making more changes. That often reveals whether the issue is configuration drift or documentation drift. ## Overview This document focuses on the settings in Atloria that control how support agents behave and where they are available. The goal is not just to turn an agent on, but to make sure it answers in a way that fits your documentation, your support model, and the customer experience you want to provide. The key areas you should review are: - Reply behavior, including tone, level of detail, and how tightly answers stay grounded in documentation - Availability, including which support surfaces, projects, workspaces, or teams can use the agent - Fallback handling, including when the agent should defer or hand the conversation to a person - Ongoing review, especially after documentation updates or support workflow changes This guide assumes the support agent already exists and has been connected to the right workspace and knowledge sources. If that setup is still in progress, use [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) and [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup) first. [SCREENSHOT: Support agent configuration area in Atloria] Use this guide when you need to tighten an agent that is answering too broadly, expand an agent into the right support areas, or standardize behavior across teams. The most effective configurations are the ones that reflect the real quality of your documentation and the real handoff expectations of your support organization. ## Prerequisites Before you change support agent behavior or availability in Atloria, make sure the basic setup is already in place. This helps you avoid testing behavior settings on an agent that is missing the documentation or assignments it needs. You should have: - Access to the support agent settings for the relevant project, workspace, or support area - An existing support agent that has already been created in Atloria - The correct documentation or knowledge sources already linked to that agent - A clear understanding of which team, project, or customer-facing area the agent is meant to support - Agreement from the relevant support lead or project administrator if the change affects live customer interactions It also helps to prepare a short set of test questions before you begin. Include a few questions that are clearly covered by your documentation and at least one that is outside the documented scope. That makes it easier to confirm whether the updated behavior and fallback settings are working as expected. If you still need to set up the agent itself or connect its knowledge sources, start with: - [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) - [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup) After you finish configuring behavior and availability, the next step is [Embedding and Operating Support Agents in Documentation Experiences](doc:embedding-and-operating-support-agents-in-documentation-experiences), which covers how the agent is presented and used in customer-facing documentation flows. ## Opening the language and framework support catalog To start evaluating support in Atloria, open the area where your team reviews code parsing readiness and supported technologies. If you already worked through [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage), return to the same supported languages or parser coverage view and use it as your starting point. This is the screen where Atloria lists the languages and frameworks it can recognize for documentation and code analysis work. [SCREENSHOT: supported languages or parser coverage catalog showing language and framework entries] When you open the catalog, focus on the information shown in each row. Atloria’s support view is most useful when you read it as a comparison list rather than a simple directory. Look for details such as: | What to check | Why it matters | |---|---| | **Language name** | Confirms whether the base programming language is listed | | **Framework name** | Shows whether Atloria recognizes a framework separately from the language itself | | **Support status** | Helps you judge readiness for real project use | | **Parser availability** | Indicates whether Atloria can analyze that technology | | **Notes or limitations** | Explains important restrictions before you upload code | Use any search box, filter choices, or category controls on the page to narrow the list to the technologies your repositories actually use. For example, if your team works with only a few languages, filtering the catalog makes it easier to compare support without scanning the full list. Pay close attention to whether an entry is listed as a language only or as a language plus a specific framework. That difference matters. A language entry usually tells you Atloria can work with general source files in that language. A separate framework entry suggests Atloria may also understand framework-specific patterns, conventions, or file organization. If you only see the language and not the framework, treat that as base-level support rather than full framework-aware coverage. ## Reading support status and parser coverage details Once you have the right entries on screen, the next step is to interpret the labels Atloria shows for each one. The support status tells you how confidently you can rely on that language or framework in a real documentation workflow. A label such as **fully supported** usually indicates the strongest level of readiness. **Partially supported** suggests Atloria can analyze some parts of the codebase but may miss framework-specific details or certain file patterns. **Preview** usually means the feature is available for testing but should be validated carefully before broad rollout. **Unsupported** means you should not expect dependable parsing results for that technology. Parser coverage is the other key detail. In Atloria, parser coverage tells you how much of a repository Atloria can understand for documentation and analysis purposes. Depending on the entry, this may include source code structure, inline comments, configuration files, or framework-specific conventions. Coverage is not just about whether Atloria can open files. It is about whether Atloria can read them in a meaningful way and turn them into useful documentation inputs. As you review each entry, look for indicators that describe the scope of coverage, such as: - Supported file types - Recognized syntax patterns - Framework conventions - Repository artifacts included in analysis - Notes about unsupported cases [SCREENSHOT: support entry with status label, parser coverage details, and limitation notes] The limitation notes are especially important. If Atloria shows that a language is supported but also notes incomplete framework handling, limited syntax recognition, or missing support for certain repository artifacts, treat that as a planning signal. You may still get useful indexing or partial documentation extraction, but the results may not be complete enough for deeper technical documentation. Read those notes carefully before deciding that a language is ready for production use in your team. ## Checking whether your repositories match supported technologies After reviewing the catalog, compare it directly against the repositories your team wants to bring into Atloria. Start with the languages used across those repositories and verify that each one appears in the supported technologies list. If a language is missing entirely, that repository should be treated as out of scope until support is added. Next, check the frameworks your teams rely on. Some frameworks appear as separate entries in the support catalog, while others may not be listed on their own. If your framework is listed separately, review its support status and parser coverage independently. If it is not listed, do not assume framework-level support just because the base language appears. In that case, Atloria may still recognize the source files, but it may not understand framework-specific structure well enough for richer documentation output. It also helps to compare the repository’s actual file patterns with what the catalog describes. Review whether the supported entry mentions the file extensions, project structure, or configuration formats your codebase uses. This is especially useful when your repositories depend on convention-heavy layouts or configuration-driven behavior. Use a simple review checklist while comparing your repositories: 1. List the main language used in each repository. 2. Check whether that language appears in Atloria’s support catalog. 3. Look for any separate framework entry tied to that repository. 4. Review the parser coverage details for matching file types and project patterns. 5. Note any gaps, such as missing framework entries, unlisted file types, or unclear version coverage. If you find a mismatch, write it down before rollout planning. Common gaps include a framework variant that is not listed, a newer language version than the one shown in the catalog, or repository files that fall outside the supported parser scope. Capturing those gaps early makes later testing much more focused. ## Assessing support for documentation extraction and code analysis A supported language is only useful if the available parser coverage matches your documentation goals. In Atloria, this means looking beyond the support label and asking what kind of output you actually need. If your team wants repository indexing only, partial support may be enough. If you need detailed technical documentation generated from source code, you should expect much stronger parser coverage. Start by matching Atloria’s coverage to the kind of information your team expects to extract. For example, you may need Atloria to identify code structure, pick up inline comments, recognize routes or components, or follow configuration-driven behavior. If the support catalog shows only limited structural parsing, Atloria may still help organize repository content, but the generated documentation may not reflect the deeper relationships your team expects. This is where partial support needs careful interpretation. Partial parser support can still be valuable when you want Atloria to: - Index repositories for browsing - Recognize basic source files - Support limited technical reference generation - Provide a starting point for manual documentation work However, partial support may fall short when you need: - Complete source-to-document traceability - Strong framework-aware documentation output - Consistent extraction across all repository areas - Reliable analysis of convention-based project structure Different roles will judge fit differently: - **Project Administrators** usually focus on whether Atloria can cover enough repositories to support rollout. - **Documentation Managers** usually care whether the extracted content is complete enough to reduce manual writing effort. - **Technical Writers** usually look for traceability between source material and the documentation they publish. [SCREENSHOT: parser coverage details being reviewed against repository documentation goals] When you evaluate fit, think in terms of outcomes, not just availability. A parser marked as available may still be too limited for your team’s documentation standards. The best choice is the one that supports the level of detail your workflow depends on. ## Comparing multiple languages and frameworks for rollout planning If your organization works across several repositories, compare all relevant languages and frameworks side by side before deciding how broadly to use Atloria. This is especially important when one team uses a well-supported stack and another relies on a framework with only partial or preview coverage. A side-by-side review helps you avoid treating all repositories as equally ready. Start by creating a shortlist of the languages and frameworks your teams actively use. Then review each one in Atloria’s support catalog and group them by support level. The goal is to identify which technologies are ready for immediate use and which ones should stay in a smaller evaluation phase. A practical way to sort your rollout plan is: 1. Put **fully supported** languages and frameworks at the top of your list for initial rollout. 2. Place **partially supported** entries into a limited evaluation group. 3. Treat **preview** entries as test candidates rather than standard team choices. 4. Exclude **unsupported** technologies from your first rollout plan. This comparison is most useful when you tie it to business decisions. If a repository needs both code analysis and documentation generation, prioritize technologies with strong parser coverage. If a repository only needs lighter indexing or reference support, a partially supported language may still be acceptable for a pilot. You can also use the comparison to decide scope: - **Organization-wide rollout** makes sense when most team stacks are fully supported. - **Selected repository rollout** is safer when support is strong for only part of your technology mix. - **Evaluation-only rollout** is the better choice when many key stacks are marked partial or preview. [SCREENSHOT: side-by-side review of multiple supported languages and frameworks] This review gives you a realistic adoption picture. Instead of asking whether Atloria supports code parsing in general, you are deciding whether Atloria supports *your* mix of languages and frameworks well enough for production documentation work. ## Resolving common gaps in support evaluation Support reviews often become unclear when the catalog looks promising but your repository details do not line up perfectly. In Atloria, the best way to resolve that uncertainty is to go back to the support entry and read it more narrowly. If a language appears supported but your framework is missing, first check whether Atloria lists frameworks separately from base-language parsing. A listed language does not automatically mean Atloria understands the framework conventions built on top of it. In that situation, treat the repository as language-supported but framework-unconfirmed until you verify otherwise. If parser coverage looks available but important repository files are not mentioned, review the coverage details for supported file types, syntax scope, and limitation notes. Atloria may support core source files while excluding configuration files, generated artifacts, or framework-specific folders that matter to your documentation process. Another common issue is version mismatch. If your team uses a newer language or framework version than the one shown in the catalog, do not assume the same support applies. Record that difference as a rollout risk and keep the repository in evaluation status until you confirm the match. When support status is unclear for documentation work, separate code recognition from documentation extraction. Atloria may be able to read code structure without extracting the documentation artifacts your team expects. That distinction matters when your goal is not just analysis, but publishable technical documentation. Use these checks to resolve uncertainty: - Confirm whether the framework has its own entry - Compare your repository file types to the coverage notes - Check whether the listed support appears to match your version - Review whether the entry describes documentation extraction, not just code parsing If questions remain after reviewing the catalog, keep the repository in a limited test group rather than including it in a broad rollout. That gives your team a safer way to validate real results before making Atloria part of standard documentation operations. ## Overview - This document helps you judge whether Atloria’s supported languages and frameworks align with the repositories your team wants to analyze. - You will use the supported languages or parser coverage catalog to review: - **Language entries** - **Framework entries** - **Support status** - **Parser coverage** - **Limitation notes** - The goal is not just to confirm that a language appears in Atloria, but to decide whether the available coverage is strong enough for your documentation workflow. - This evaluation is most useful when you are planning: - Project onboarding - Code parsing workspace use - Documentation generation - Multi-team rollout decisions - If you need help locating the catalog itself, refer back to [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage). Use this guide when you need to answer practical questions such as: - Can Atloria work with the languages in our repositories? - Does Atloria recognize our framework separately from the base language? - Is parser coverage deep enough for technical documentation, not just indexing? - Which repositories are ready for rollout now, and which should stay in evaluation? This guide focuses on reading and comparing what Atloria shows in its support listings. It does not repeat the earlier walkthrough for finding that screen, and it does not go deep into parser compatibility rules. The next document, [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility), covers that in more detail. ## Prerequisites - You should already know how to open the supported languages or parser coverage area in Atloria. If not, use [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage) first. - Have a basic list of the repositories, languages, and frameworks your team wants to evaluate. - Be ready to compare Atloria’s catalog against real repository characteristics, including: - Main programming language - Framework or stack choice - Common file types - Project structure patterns - Any known version differences - This guide is most useful for users involved in project setup, documentation planning, or rollout decisions, especially: - Project Administrators - Documentation Managers - Technical Writers Before you begin, it helps to gather a short internal checklist for each repository you plan to review: - Repository name - Primary language - Framework used, if any - Important file formats - Whether you need indexing only or deeper documentation extraction You do not need advanced technical knowledge to use this guide, but you do need enough familiarity with your team’s repositories to recognize the language and framework names Atloria shows in the support catalog. If your team is evaluating Atloria for broader adoption, keep notes as you review each support entry so you can compare repositories consistently. For the next step in this learning path, continue with [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility). ## Opening the audit activity view for a project In Atloria, start from the main workspace after you sign in. Open the project you want to review, then go to the project area where activity, audit history, or related administrative records are available. If you need help getting back to the right project workspace first, use [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) or [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). 1. Open the correct project from your project list or dashboard. 2. Check the project name at the top of the page before reviewing any records. 3. Move to the area that shows project activity or audit history. 4. Look for the main list of recorded events. When the audit activity view is open, focus on the columns and labels shown in the list. In most audit-style views, you will be looking for details such as the date and time of the event, the person who performed it, the action that happened, and the related item affected by that action. These details help you confirm that you are reviewing the right project history before you export anything. [SCREENSHOT: Project workspace with the audit or activity area open and the project name visible at the top] If your role in Atloria includes broader administrative access, you may see more detail in each row or additional actions in the toolbar, including export options. If you do not see an **Export** button or cannot open some activity details, that usually means your current access level does not include those controls. In that case, confirm your permissions with someone who manages user access in Atloria, or review [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Reviewing activity records to find the events you need Once you are in the project’s audit activity view, read the list from newest to oldest or oldest to newest, depending on how the screen is arranged. This helps you reconstruct what happened during a release, review period, or approval cycle without jumping between unrelated records. 1. Start by scanning the full list to understand the overall sequence of changes. 2. Narrow the list using any available filters, such as date range, user, event type, or related item. 3. Use the search box if you need to find a specific person, action, or record reference. 4. Open a single activity entry when you need more detail than the list view shows. If you are investigating a specific issue, filtering first usually gives you a cleaner export later. For example, if you only need records tied to a review period, set the date range before you search. If you are checking who changed a document or version status, filter by the person or by the action label shown in the activity list. This is especially helpful when a project has a long history and the list contains many routine updates. Look closely at the wording used in each row. The action label often tells you whether the event relates to creation, editing, approval, publishing, access, or another project change. The related item reference helps you connect that row to the document, version, or project record involved. [SCREENSHOT: Audit activity list with filters, search, and several rows showing date, user, action, and related item] If you already know how to create exports, avoid repeating the full export setup from [Exporting Audit and Version Records](doc:exporting-audit-and-version-records). Here, the goal is to refine the activity list first so the exported file contains only the records you actually need. ## Interpreting audit record details for compliance and review After you open an individual activity record, use the detail view to confirm exactly what happened. This is where Atloria becomes most useful for compliance review, internal checks, and release follow-up, because the detail view gives context that may not be visible in the main list. The most important fields to read are usually the event time, the user who performed the action, the action itself, and the related project item. Together, these fields answer four practical questions: **when** it happened, **who** did it, **what** they did, and **what it affected**. | Field to review | What it tells you | |---|---| | Date and time | When the event happened | | User | Who performed the action | | Action or event | What change or activity occurred | | Related item | Which project record, document, or version was affected | Use these details to separate routine activity from entries that matter for formal review. Routine updates may include ordinary edits or expected workflow steps. Audit-significant entries are the ones you may need to retain, explain, or follow up on, such as status changes, approval-related actions, publishing changes, or unexpected access activity. If the record includes a linked reference, open that related item to verify the underlying source. For example, an activity row may point you back to a document, a version, or another project record. This is useful when you need to prove that the audit entry matches a real change in the project workspace rather than relying only on the summary text in the activity list. [SCREENSHOT: Individual audit record detail showing date, user, action, and related item information] When you review details this way, you can tell whether the entry reflects creation, modification, a status update, or access-related activity. That distinction matters when you prepare records for compliance or internal review. ## Exporting the audit records you selected After you have narrowed the activity list to the records you need, use the export controls in the audit or activity area. In Atloria, it is best to filter first and export second, because this reduces cleanup work and makes the exported file easier to review. 1. Apply the date, user, event, or related-item filters that match your review purpose. 2. Check the visible list to confirm it contains the right records. 3. Click the **Export** action in the toolbar or activity area. 4. If Atloria offers more than one export scope, choose the option that matches your current review. 5. Open the exported file and confirm the expected records are included. Some export actions may use the current filtered list, while others may include a broader set of project activity. If Atloria presents a choice, select the scope carefully. For a focused compliance request, use the filtered results. For a broader internal review, use the larger project activity range if that option is available. Before you send or store the export, spot-check the output. Make sure it includes the key information you need for review: - Date or timestamp - User - Action or event - Related item or record reference [SCREENSHOT: Audit activity toolbar with filters applied and the Export action highlighted] If the exported file does not match what you expected, return to the activity list and confirm whether your filters were still active when you started the export. This is the most common reason an export contains too many or too few rows. For a broader comparison of export types in Atloria, see [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving). ## Using exported audit data for documentation and operational follow-up An audit export is most useful when you can connect each row back to real project activity in Atloria. After exporting, compare the file with the project’s activity list, version history, approval records, or related document changes so your team can use it as evidence rather than just as a raw report. You may use exported audit data in several ways: - Attach it to an internal review or retention process - Support a release check when someone asks who changed what and when - Investigate unusual project activity - Keep a consistent record for recurring compliance requests When you review the exported rows, look for entries that need follow-up. Examples include unexpected changes during a review window, actions that appear without the expected approval step, or activity from a user you did not expect to be involved. In those cases, use the related item reference in the export to go back into the project workspace and confirm the current state of the document, version, or project record. It also helps to organize exports in a repeatable way. Group them by project, by review period, or by audit purpose so future requests are easier to answer. If your team regularly handles release evidence, approval checks, or retention reviews, consistent naming and storage practices will save time when someone requests the same type of records again. [SCREENSHOT: Exported audit file open beside the project activity list for comparison] Because audit exports may include user names and project details, handle the file according to your organization’s internal access rules. Only share it with the people who need it for review, approval, or compliance work. If your team also reviews security-related activity, pair this process with [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls). ## Fixing common problems with missing records or incomplete exports If the audit list or export does not look right, start with the project and filters before assuming the records are missing. In Atloria, most audit export issues come from viewing the wrong project, leaving an old filter in place, or exporting a different scope than expected. 1. Recheck the project name at the top of the page. 2. Review any active date filters, user filters, and event filters. 3. Compare the visible list with what you expected to export. 4. Try opening a few individual records to confirm the details are present. 5. Run the export again after correcting the filters or scope. If no expected activity appears, make sure you are in the correct project workspace. Then clear or adjust the date range and event-type filters. A narrow filter can hide valid records without making it obvious that the list is incomplete. If some details are missing from individual entries, your role may not include access to full record information or linked item details. This can also affect whether you see an **Export** action at all. When that happens, check with an Atloria administrator who manages access and permissions. If the export contains too many rows, the export may have included the full project activity instead of only the filtered list. If it contains too few rows, one or more filters may still be active. Always compare the exported result with the on-screen list before sharing the file. [SCREENSHOT: Audit activity view showing active filters and an export result that needs to be checked] For broader admin-side visibility into access and reporting areas, see [Using the Admin Workspace](doc:using-the-admin-workspace) and [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Overview - In Atloria, project audit activity helps you review who did what, when it happened, and which project item was affected. - The most reliable workflow is: open the correct project, review the activity list, narrow the results with filters, inspect important entries, and then export only the records you need. - Audit records are especially useful for compliance reviews, release checks, approval follow-up, and investigating unexpected project changes. - The main details to verify before exporting are the date and time, the user, the action label, and the related item reference. - If you already need the basic export flow, refer back to [Exporting Audit and Version Records](doc:exporting-audit-and-version-records). This guide focuses on managing the activity list and interpreting the records before and after export. - Export results are easier to use when you organize them consistently by project, review period, or audit purpose. - If records appear incomplete, first check the selected project, active filters, and whether your role allows full audit visibility and export access. [SCREENSHOT: Audit activity page showing a filtered list ready for export] This guide fits best when you are actively reviewing project history and need a practical way to turn that history into a usable export for internal review or retention work. ## Prerequisites - You can sign in to Atloria and open the project workspace you need to review. If needed, see [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 know which project you need to review and can confirm its name before checking activity records. - You have access to the project’s activity or audit area. - If you need to export records, your role must include access to the **Export** action in that area. - You should already understand the basic export process from [Exporting Audit and Version Records](doc:exporting-audit-and-version-records), since this guide builds on that workflow instead of repeating it. - It helps to know the review period, user, event type, or related item you are looking for before you start filtering the activity list. - If your work involves administrative review across teams or organizations, you may also need the access described in [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings) or [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). For the next step in this audit export workflow, continue with [Managing Audit Record Exports for Compliance](doc:managing-audit-record-exports-for-compliance). ## Opening the Code Parsing Workspace and Understanding the Session Layout In Atloria, the Code Parsing Workspace is organized around a single working session. A session is the place where you collect the code you want to analyze, run parsing, and review the structured results without losing your progress. If you already uploaded code in the previous step, continue from [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace) and open that same workspace entry from your recent project activity or session list. When you open the workspace, look for these main areas: - **Upload panel** for adding code files - **Snippet input area** for pasting smaller pieces of code - **Parse** or **Start Parsing** action controls - **Results pane** where parsed structure appears - **Session list** or **recent workspace entries** for reopening earlier work A workspace session usually includes: - Uploaded source files - Pasted code snippets - Parsing results tied to each item - Structured output you can use while planning documentation coverage [SCREENSHOT: Code Parsing Workspace showing upload panel, snippet area, parse button, results pane, and session list] Different team members often use different parts of the same screen: - **Technical Writers** usually spend most of their time in the **results pane**, reviewing the structure of files and snippets to understand what should be documented. - **Documentation Managers** often move between the **session list** and **results pane** to compare sessions and check whether related source material has been parsed consistently. - **Project Administrators** are more likely to review **recent workspace entries** and existing sessions to see what has already been processed and what still needs attention. To begin fresh, open the workspace and start a **new session** by adding files or a snippet. To continue earlier work, select an existing session from the **session list** or from **recent workspace** entries. Reopening a session brings back its attached inputs and any results already generated, which is useful when documentation work spans multiple reviews. ## Adding Source Material to a Workspace Session A workspace session only becomes useful after you add the code you want Atloria to parse. In the Code Parsing Workspace, you can add source material in two main ways: upload files or paste a snippet. Use file upload when you want to review complete source files, and use the snippet area when you only need to inspect a smaller section. 1. In the **upload panel**, click the file picker to choose one or more code files from your device, or drag files into the drop area if that option is shown. 2. Wait for the files to appear in the **session contents list**. 3. If you only need to analyze a small section, click into the **snippet input area** and paste the code directly there. 4. Add the snippet to the current session so it appears alongside uploaded files. 5. Review the **session queue** or **input summary** before you start parsing. Atloria separates uploaded files from pasted snippets in the session so you can tell them apart quickly. In the session contents area, look for details such as: - **File names** for uploaded items - **Snippet labels** or a snippet entry name for pasted content - A **source type indicator** showing whether the item came from a file upload or the snippet editor This distinction matters when you return to a session later. A full file usually gives you broader structure, while a snippet may only show the portion you pasted. Before clicking **Parse** or **Start Parsing**, confirm that the correct items are attached to the current session. Check the selected files, review any snippet entries, and make sure the session queue matches the documentation task you are working on. If you are comparing related code areas, keep them in the same session. If you are working on a separate feature or release topic, create a different session so the results stay easier to review. [SCREENSHOT: Session contents list showing uploaded files and a pasted snippet with different source labels] ## Starting Parsing and Monitoring Session Progress Once your files or snippets are attached to the session, start the analysis from the workspace controls. In most cases, you will use the **Parse** or **Start Parsing** button shown near the session inputs or above the results area. Atloria then begins processing the items currently included in that session. 1. Review the selected files and snippets in the **session queue** or **input summary**. 2. Click **Parse** or **Start Parsing**. 3. Watch the status shown beside each item or in the **results header**. 4. Wait until the item status changes to a finished state before opening the result. 5. If one item does not complete, return to that specific entry in the session list and review its status separately. During processing, Atloria may show visible states such as: - **Queued** when an item is waiting to begin - **Parsing** while Atloria is actively analyzing it - **Completed** when results are ready - **Failed** if Atloria could not finish that item These status labels help you tell whether parsing covered everything in the session or only part of it. If all attached items show a finished state, the session ran for the full set. If only one file or snippet shows a completed result while others remain queued or failed, you know the session needs more review before you use it for documentation work. The **results pane** usually starts filling in automatically as items finish. You do not need to create a separate review record first. The session remains saved so you can leave the workspace and come back later without losing the uploaded files, pasted snippets, or completed results. [SCREENSHOT: Parsing in progress with item-level statuses such as queued, parsing, completed, and failed] This saved-session behavior is especially useful when multiple people review the same material over time. A writer can start parsing, a manager can reopen the session later, and both can refer to the same structured output when planning documentation coverage. ## Reviewing Parsed Results for Documentation Work After parsing finishes, use the **results pane** to inspect the structure Atloria found in each file or snippet. This is where the workspace becomes useful for documentation planning. Instead of reading raw code line by line, you can review a structured view of the important parts Atloria detected. The results view may show items such as: - **Modules** - **Classes** - **Functions** - **Methods** - Other code elements identified from the uploaded file or pasted snippet [SCREENSHOT: Parsed results pane showing structured code elements for one selected input] If your session contains more than one source item, switch between them using the **session list**, **contents list**, or the selected item area in the workspace. Choose one file or snippet at a time to load its specific result. This makes it easier to compare a full file with a smaller pasted snippet, or to review related files side by side within the same session. For **Technical Writers**, the parsed structure helps answer practical documentation questions: - Which parts of this feature need their own headings? - Which items look like API components or reference topics? - Which code areas suggest user-facing behavior that should be explained in a guide? For **Documentation Managers**, the same results support consistency checks across related files. If one file shows a rich structure and a related file produces only limited output, that may signal a gap in what has been uploaded, selected, or reviewed. Managers can use the session to verify whether source coverage is broad enough before assigning writing work. Use the parsed output as a map, not as finished documentation. It helps you identify what exists, how pieces are grouped, and where you may need deeper review. If you need broader coverage decisions after this step, continue to [Using Code Parsing to Support Technical Documentation](doc:using-code-parsing-to-support-technical-documentation). ## Using Workspace Sessions to Support Documentation Tasks A code parsing session in Atloria works best when you treat it as a research space for a specific documentation goal. Instead of mixing every file into one long-running session, organize sessions around the work you are actually doing. That makes the results easier to revisit, compare, and share with the rest of your team. You can keep separate sessions for different documentation efforts, such as: - **Feature-level analysis** when you need to understand one product area before writing a user guide - **API reference preparation** when you want to review structured code elements that may become reference topics - **Release documentation review** when you are checking what changed across a set of source files In practice, the workflow usually looks like this: 1. Add the files or snippets related to one documentation objective. 2. Run parsing for that focused set of inputs. 3. Review the structured results in the **results pane**. 4. Use the output to decide what needs coverage in guides, inventories, or reference pages. 5. Return to the same session later if the writing or review work continues. For **Technical Writers**, this helps move from raw source material to a clearer list of components, behaviors, or reference items that should appear in documentation. For **Documentation Managers**, saved sessions make it easier to check whether teams are reviewing the right source material before drafting or approving content. For **Project Administrators**, retained sessions provide a repeatable record of what was parsed and when, which can support internal review habits and more consistent documentation workflows. Common deliverables supported by these sessions include: - Feature guides - Component inventories - Technical reference pages - Release review notes based on parsed source structure Because sessions stay available for later review, they also help teams avoid repeating the same upload and parsing work every time a documentation task resumes. ## Common Issues and How to Fix Them Most workspace problems in Atloria come from the current session not containing the expected input, or from reviewing the wrong item after parsing finishes. Start by checking the **session contents list**, **selected item**, and **results pane** before repeating the whole process. If an **uploaded file does not appear** in the session contents list: - Return to the **upload panel** and confirm the upload finished - Make sure the file was added to the **current workspace session**, not a different one - Refresh your view by reopening the session from the **session list** or **recent workspace entries** - Check whether the file name appears lower in the contents list if multiple items were added If the **Parse** action is unavailable or nothing starts when you click it: - Confirm that at least one **file** or **snippet** is present in the workspace - Check that the item is included in the current **input summary** or **session queue** - Make sure you are still inside the active session you intended to use - Reopen the session and verify the source material is still attached If the **results pane is empty after parsing**: - Look at the item-level status and confirm the file or snippet actually finished processing - Open the specific file or snippet from the **session list** instead of relying on the default selection - Check whether another item in the session is currently selected - Reopen the session if needed and load the result again If a **snippet parses differently from an uploaded file**: - Compare the exact code pasted into the **snippet input area** with the version contained in the uploaded file - Check whether the snippet includes only part of the code while the uploaded file includes surrounding structure - Review each result separately so you do not assume both inputs should produce the same structure These checks usually resolve session-level issues without needing to rebuild the workspace from scratch. ## Overview This page focuses on how to manage ongoing work inside Atloria’s Code Parsing Workspace after you begin using it. A workspace session is the container for everything related to one parsing task: the files you upload, the snippets you paste, the parsing run itself, and the structured results you review afterward. Managing sessions well makes it easier to return to earlier work, compare related inputs, and keep documentation research organized. This guide is most useful when you already know how to add code to the workspace and trigger an initial parsing run. If you need that setup first, use [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace). Here, the focus is on session layout, adding and confirming inputs, monitoring progress, reopening saved sessions, and using results for documentation planning. You will work with these parts of the workspace throughout the guide: - **Upload panel** for source files - **Snippet input area** for pasted code - **Parse** or **Start Parsing** controls - **Results pane** for structured output - **Session list** or **recent workspace entries** for reopening saved work This guide also explains how different roles use the same workspace in different ways. **Technical Writers** typically review parsed structure to decide what to document. **Documentation Managers** use sessions to check completeness and consistency across related files. **Project Administrators** may use saved sessions to keep team workflows organized and easier to revisit. If your goal is to turn parsed results into actual documentation decisions and coverage plans, the next step after this page is [Using Code Parsing to Support Technical Documentation](doc:using-code-parsing-to-support-technical-documentation). ## Prerequisites Before you manage workspace sessions in Atloria, make sure you already have access to the project area where the Code Parsing Workspace is available and that you can open the workspace successfully. This guide assumes you are past the initial sign-in and project navigation steps and are ready to work inside an existing documentation workflow. You should already be comfortable with: - Opening the relevant project workspace in Atloria - Accessing the **Code Parsing Workspace** - Uploading code files or pasting a snippet at least once - Running an initial parse and recognizing where results appear If you have not done those steps yet, start with [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace). That guide covers the first-time flow. This page builds on it by showing how to continue, reopen, and organize that work across multiple sessions. It also helps to have one of the following ready before you begin: - A set of source files for a feature you need to document - A smaller code snippet you want to inspect on its own - A clear documentation goal, such as reviewing a feature area, preparing reference content, or checking release-related source material This guide is especially relevant for: - **Technical Writers** reviewing parsed structure before drafting content - **Documentation Managers** checking consistency across related source material - **Project Administrators** overseeing repeatable workspace usage across a team You do not need to prepare publishing settings, approval steps, or public documentation pages before using workspace sessions. The only requirement is that you have source material ready and can open the parsing workspace where those files or snippets can be added and reviewed. ## Finding Where Atloria Stores Screenshots If you already know how to capture and attach images from [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation), the next step is knowing where those images belong so your team can find and reuse them later. In Atloria documentation work, screenshot libraries are usually separated by purpose. Teams commonly keep a **shared screenshot library** for images reused across multiple guides, **product-area folders** for images tied to a specific part of Atloria, and **page-level asset folders** for one-off images that only support a single documentation page. This structure helps writers avoid storing the same image in several places. A typical library layout uses folder names that show the image stage clearly: - **raw** for original captures taken directly from Atloria - **edited** for cleaned-up versions after cropping and review - **final** for approved images ready to place in published documentation These folder names make it easy to tell whether an image is still being prepared or is safe to reuse in live content. Writers also rely on clear filenames instead of opening every image one by one. A good filename usually includes: - the Atloria area, such as **login**, **admin**, **projects**, or **analytics** - the page or workflow name, such as **sign-in**, **user-list**, or **project-dashboard** - the visible screen state, such as **empty**, **filled**, **error**, **success**, or **coming-soon** For example, a filename might distinguish a **Login** screen with an error message from the same screen in its normal state. That matters when you need the exact image showing **Invalid email or password** instead of a blank form. As a rule, place screenshots in the shared library when they show reusable screens such as **Login**, **Register**, **Admin**, **Analytics & Insights**, or **Security & Audit**. Keep images in a page-level folder when they only make sense for one narrow procedure or one release note. [SCREENSHOT: Example screenshot library showing shared, product-area, and page-level folders with raw, edited, and final subfolders] ## Capturing and Preparing Screenshots for Reuse When you capture screenshots for the enterprise library, use an approved Atloria environment that matches the interface your readers will actually see. This is especially important for screens with visible labels such as **Login**, **Register**, **Analytics & Insights**, **Security & Audit**, and the **Admin** workspace cards like **Users & Permissions**, **Organizations**, **Documents**, **Projects**, and **Analytics**. If button text or menu names differ from published documentation, the screenshot becomes harder to reuse. Start with a clean screen state before you capture. Make sure page headers, tabs, cards, and primary buttons are visible. For example, on the **Login** page, keep the **email** and **password** fields visible along with any sign-in error message if that state is what you need. On the **Register** page, keep the **name**, **email**, and **password** fields visible. On the **Analytics & Insights** and **Security & Audit** pages, include the page title and the centered “coming soon” notice if that is the current documented view. After capture, edit the image so it is ready for reuse: 1. Crop out browser chrome and anything outside the Atloria page. 2. Remove or blur sensitive account details if any names, email addresses, or organization details appear. 3. Keep the important UI structure intact, including page titles, navigation labels, cards, form labels, table headings, and primary action areas. 4. Save the cleaned image in the shared library using a filename that includes the Atloria area, workflow, and screen variant. 5. Store the original in **raw**, the cleaned version in **edited**, and the approved version in **final**. When replacing an older screenshot, add the new image as a tracked replacement in the correct folder instead of dropping it into an unrelated location. That way, teams can still trace which image was used before and what changed. [SCREENSHOT: Edited screenshot example showing a clean Atloria page with header, labels, and action areas preserved] ## Reusing Existing Images Across Documentation Pages Before taking a new screenshot, search the existing library first. In most teams, the fastest way to do this is by checking the shared screenshot library for the Atloria area, workflow name, and filename tags. If you need an image of the **Login** page, the **Register** page, the **Admin** dashboard, or the **Analytics & Insights** screen, look for those exact terms in the library before creating another capture. Once you find a possible match, confirm that the screenshot still reflects the current Atloria interface. Look closely at visible markers such as: - page titles like **Analytics & Insights** or **Security & Audit** - card names such as **Users & Permissions**, **Organizations**, **Documents**, **Projects**, and **Analytics** - form labels such as **name**, **email**, and **password** - status or notice text such as **Invalid email or password** or a “coming soon” message - menu paths and tabs that help readers recognize where they are If those markers match the current documentation, reuse the image. If they do not, create a replacement instead of forcing an outdated screenshot into a new guide. Choose a **shared asset** when the same image supports multiple pages, such as a standard **Login** screen or a common **Admin** workspace view. Use a **page-specific folder** when the image is tightly tied to one procedure, one release, or one unusual state that other pages are unlikely to reference. Keep references consistent wherever the image appears. Use the same image name in page content, the same wording in the caption, and matching alt text that describes the visible Atloria screen. Consistency makes later updates much easier because your team can trace one shared image across many guides. [SCREENSHOT: Search results in a screenshot library filtered by product area and workflow name] ## Keeping Screenshot Libraries Organized Across Teams A shared screenshot library only stays useful if each team knows what it owns. In Atloria documentation work, this usually means separating enterprise-wide assets from team-managed assets so writers do not accidentally replace images outside their area. A practical ownership model looks like this: - **Technical Writers** maintain reusable screenshots for guides and procedures, especially common screens such as **Login**, **Register**, project pages, and documentation workflows. - **Documentation Managers** review naming, folder placement, and approval status for images that will be reused across multiple guides. - **Project Administrators** help confirm screenshots for project-specific or admin-facing areas such as **Users & Permissions**, **Organizations**, **Analytics & Insights**, and **Security & Audit**. Teams should track a small set of metadata for every screenshot so anyone can understand what it is and whether it is safe to use. | Metadata | What to record | |---|---| | Product area | The Atloria area shown, such as Login, Admin, Projects, or Analytics | | Workflow | The task the image supports, such as signing in or reviewing admin cards | | Capture date | When the screenshot was taken | | Owner | The person or team responsible for keeping it current | | Review status | Whether the image is draft, reviewed, approved, or archived | Review checkpoints matter just as much as folder structure. Before adding or replacing an image, confirm the filename follows team standards, the crop is consistent, and the visible labels match the current Atloria screen. During regular maintenance, look for duplicate images with different names, outdated UI states, and screenshots stored in the wrong folder stage such as **final** when they are still under review. [SCREENSHOT: Shared library view with folders, ownership notes, and review status columns] ## Managing Updates When the Atloria Interface Changes When Atloria’s interface changes, screenshot updates can affect more than one guide. A renamed card on the **Admin** page, a changed form layout on **Register**, or updated wording on **Analytics & Insights** can ripple across procedures, release notes, and training content. That is why shared assets need to be reviewed first whenever a visible screen changes. Start by identifying which screenshots are reused in multiple places. Shared images often include common screens such as **Login**, **Register**, the **Admin** dashboard, and placeholder pages like **Analytics & Insights** or **Security & Audit**. If one of these screens changes, check every guide that references the shared asset before you replace it. Use this update process: 1. Compare the current Atloria screen to the existing approved screenshot. 2. Note what changed, such as page titles, card names, button labels, form fields, or notice text. 3. Capture a new image that matches the current interface. 4. Save the replacement in the correct library location, keeping the expected naming pattern and reference trail intact. 5. Update any documentation pages, captions, and alt text that describe the old screen state. 6. Record which guides, procedures, or release-related pages were affected. Try to preserve established file paths or agreed library locations whenever possible. Even if your team tracks updates manually, keeping replacements in the expected location reduces confusion and lowers the chance of broken image references. Coordination matters most when changes affect navigation or shared admin screens. Writers may notice the content impact first, while administrators may confirm whether the new labels and layouts are final. Record review notes with each update so the next person can see why the screenshot changed and which pages were checked. [SCREENSHOT: Before-and-after comparison of an Atloria screen showing updated labels and replacement image tracking] ## Fixing Common Problems with Screenshot Libraries Most screenshot library problems come down to four issues: missing images, duplicate images, outdated screenshots, and access problems. You can usually solve each one by checking filenames, folder placement, and the visible Atloria screen details. If an image is missing from a documentation page, first check whether the file was moved, renamed, or placed in the wrong folder. A screenshot that used to live in **final** may have been moved into **edited** during a cleanup, or its filename may have changed from one workflow label to another. Compare the page reference with the current library entry and restore the expected location or update the page to point to the approved file. Duplicate screenshots are another common issue. You may find two images showing the same **Login** page, the same **Register** form, or the same **Admin** card layout with slightly different filenames or crop sizes. When that happens: - keep the version with the clearest crop and correct naming - confirm which one is already referenced in documentation - archive the extra copy instead of leaving both active - note the preferred asset so future writers reuse the same file Outdated screenshots are easier to spot when you compare visible labels. If the image shows an old card name, old menu wording, or a screen state that no longer appears in Atloria, mark it for replacement. This is especially important for admin-facing pages and any screen with notice text or status messaging. Access issues usually appear when contributors can view documentation pages but cannot upload to shared screenshot folders or review existing assets. In that case, ask the person who manages your team’s Atloria workspace or documentation storage rules to confirm your access level and folder ownership boundaries. Do not work around the problem by uploading approved shared assets into random page folders, because that creates more duplicates later. [SCREENSHOT: Example of duplicate and outdated screenshots flagged for cleanup in a shared library] ## Overview Managing an enterprise screenshot library in Atloria is less about storing images and more about making sure the right screenshot is easy to find, easy to trust, and easy to update. The library works best when teams separate reusable screenshots from one-off page images, follow a clear naming pattern, and keep each file in the correct stage folder such as **raw**, **edited**, or **final**. For day-to-day documentation work, focus on three decisions each time you handle a screenshot: - **Where should it live?** Put reusable Atloria screens in the shared library and one-off images in page-level folders. - **How should it be named?** Include the Atloria area, the workflow, and the visible screen state so the image is recognizable without opening it. - **Who maintains it?** Make ownership clear so updates do not stall when the interface changes. This matters most for screens that appear across many guides, such as **Login**, **Register**, the **Admin** dashboard, and admin pages like **Analytics & Insights** and **Security & Audit**. If those shared screens are stored and labeled consistently, writers can reuse them with confidence and replace them quickly when Atloria changes. If your team is still building these habits, start by cleaning up the most reused folders first. Standardize filenames, archive duplicates, and confirm which images are approved for documentation. That gives you a reliable base library before you expand into more detailed organization by product area or release cycle. ## Prerequisites Before you manage an enterprise screenshot library for Atloria, make sure you already have the basics from [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation). This guide assumes you are no longer learning how to add a screenshot to a page and are now focusing on reuse, ownership, and long-term maintenance. You should have: - access to the Atloria documentation workspace or the shared location your team uses for screenshot storage - permission to view the folders used for **raw**, **edited**, and **final** images - a clear understanding of the Atloria areas your team documents, such as **Login**, **Register**, **Admin**, **Projects**, **Analytics & Insights**, and **Security & Audit** - a team naming pattern for screenshots that includes the product area, workflow, and screen state - an agreed review process for approving, replacing, archiving, or deleting shared images It also helps if you can recognize the visible parts of the Atloria interface that make a screenshot reusable, including: - page titles - form labels - menu names - cards and tabs - error messages and notice states - primary action buttons If you are working with shared admin-facing screenshots, confirm who approves those images before you add them to the enterprise library. Some teams ask Technical Writers to prepare the image and Documentation Managers or Project Administrators to confirm that labels and screen states are current. The next step is [Organizing Screenshots for Documentation and Releases](doc:organizing-screenshots-for-documentation-and-releases), which covers how to structure screenshot work across active documentation updates and release cycles. ## Understanding What You Can Export from Documentation Records In Atloria, you can start an export from two places on a documentation record: the **Export** action in the record toolbar and the version-specific export option in the **Versions** panel or **Version History** area. These two entry points look similar, but they serve different purposes. Use the **Export** action on the main documentation record page when you want the record exactly as it appears now. This export reflects the current title, the latest body content, and the details shown on the record screen at the time you generate the file. That usually includes the visible record information such as status, owner, last updated details, and other metadata fields shown alongside the content. If the export options include approval details or related governance information, those are tied to what is currently shown for that record. Use the export option from **Versions** or **Version History** when you need a saved point in time rather than the live record. This is the better choice when you must preserve a specific milestone, such as a reviewed draft, an approved version, or a release-ready snapshot. A version export is based on the selected saved version, not on any edits made after that version was created. Common export results fall into two broad groups: - **Portable files for sharing** - Useful for reviewers, stakeholders, or teams outside Atloria - Best when someone needs a readable copy of the documentation record - **Fixed snapshots for audit retention** - Useful for governance, approval evidence, and historical reference - Best when you need to preserve exactly what was approved or reviewed at a specific time [SCREENSHOT: Documentation record page showing the main Export action and the Versions panel] If you need a refresher on basic export actions before choosing a workflow, see [Exporting Documentation and Related Records](doc:exporting-documentation-and-related-records). ## Choosing Between Exporting a Version and Exporting a Full Record The most important export decision in Atloria is whether you need the **current record** or a **specific saved version**. That choice affects what your recipients see and how reliable the file is for review, approval, or retention. Choose a **version export** when the exact saved state matters. In the **Version History** list, each version represents a point-in-time snapshot. Exporting from that list is the right option when you need an immutable record of what existed at a milestone. This is especially useful for approved versions, sign-off packages, pre-release drafts sent for formal review, or any case where the file must match a documented governance event. Choose a **full record export** from the record toolbar when people need the latest working state. This is helpful for operational sharing, internal collaboration, or handoffs where the most recent edits and current metadata matter more than historical preservation. Because this export reflects the live record page, it may include changes made after the last saved version in the history list. The governance difference is straightforward: | Export choice | Best for | What it preserves | |---|---|---| | **Version export** | Approval milestones, audit evidence, release checkpoints | A fixed snapshot tied to a specific version | | **Full record export** | Current collaboration, operational sharing, active handoffs | The latest visible state of the documentation record | | **Either option with metadata included** | Review packages and context sharing | Content plus selected record details and approval context | Common team decisions usually look like this: - **Documentation Managers** - Export approved versions for formal review packages - Export pre-release drafts from **Version History** when feedback must reference a stable snapshot - **Project Administrators** - Export the current record when sharing the latest working content across teams - Export a specific version when responding to archive or compliance requests When in doubt, ask one question before clicking **Export**: “Do recipients need the latest page, or the exact version that was reviewed or approved?” ## Exporting the Right Content for Sharing and Review When you are preparing an export for sharing, start on the documentation record itself and confirm that the page reflects the right state before you generate anything. Check the visible record details first, especially the **status**, **owner**, and **last updated** information. If the record is still being edited or has changed since the last review, exporting too early can send the wrong content to reviewers. 1. Open the documentation record you want to share. 2. Review the record header and details area for the current **status**, **owner**, and **last updated** information. 3. Read through the title and body content to make sure the page matches what your audience should receive. 4. Click **Export** in the record toolbar. 5. In the export choices, select the option that matches your need: 1. Export the **current record** if recipients need the latest visible content. 2. Switch to the version-based option if recipients need a locked snapshot instead. 6. In the export dialog, review any options related to included content, such as: 1. **Metadata fields** 2. **Approval information** 3. **Linked context** shown in the export settings 7. Generate the export. 8. Open the file and confirm it contains the right content for the intended audience. Different audiences usually need different export choices: - **Internal collaborators** - Often need the latest current record - May benefit from included metadata and approval details for context - **External reviewers** - Usually need a stable version snapshot - Often need approval or review context included if they are validating readiness - **Project stakeholders** - May only need a clean shareable copy of the current record or latest approved version [SCREENSHOT: Export dialog showing options to include metadata, approval information, and linked context] If the export will be used in a formal review cycle, align it with your version and approval process described in [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions). ## Exporting Specific Versions for Audit and Governance Needs For audit, retention, and governance work, the safest export is usually a specific saved version from the **Versions** panel or **Version History** tab. This avoids confusion between the live record and the exact state that was approved, reviewed, or marked ready for release. 1. Open the documentation record in Atloria. 2. Go to the **Versions** panel or **Version History** tab. 3. Scan the list for the exact version you need. Use the visible details to identify it, such as: 1. **Version number** 2. **Timestamp** 3. **Approval state** 4. Select the version that matches the governance event you need to preserve. 5. Confirm that the selected version lines up with the event you are documenting, such as: 1. Approval 2. Sign-off 3. Release readiness 6. Start the export from that version entry. 7. Review any available options for including metadata or approval-related details. 8. Generate the file and save it in the location your team uses for audit or retention records. Before you export, compare the version details with the reason for the request. For example, if someone asks for the approved documentation snapshot, do not assume the most recent version is the approved one. Look at the version list and verify the approval state directly. A newer draft may exist after the approved milestone, and exporting that newer draft could create a governance problem. A version export is especially useful when you need to show: - What content was approved at a specific time - Which version was used for release readiness review - What documentation was shared during a formal sign-off step - What snapshot should be kept for retention purposes [SCREENSHOT: Version History list with version number, timestamp, approval state, and export option] For related guidance on checking whether a version is ready before you export it, continue with [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). ## Managing Export Decisions Across Teams and Projects Export workflows work best when teams agree on who exports what, when they do it, and how exported files are stored. In Atloria, this matters because the same documentation record can be shared for day-to-day collaboration, formal review, release preparation, and audit retention. Without a shared approach, teams can end up circulating different files for the same record. A practical split of responsibilities is: - **Documentation Managers** - Export approved versions from **Version History** for formal review, release checkpoints, and archived milestones - Use version-based exports when the file must match a stable approval state - **Project Administrators** - Export the current record from the main **Export** action for operational sharing and cross-team coordination - Handle broader project-level requests where the latest visible record is needed It also helps to standardize file naming. Use a naming pattern that includes the details people already recognize on the record screen: - Record title - Version number, when applicable - Project name - Export date This makes it easier to tell whether a file is a live-record export or a version snapshot. It also reduces the risk of someone sharing an outdated draft because the file name clearly identifies the source. Coordinate exports with the status shown on the documentation record. If the record is still under review, avoid sending it out as though it were final. If a version has been approved, prefer exporting that approved version rather than the live record, especially when the file will move outside the immediate project team. To reduce governance risk across projects: - Avoid exporting multiple drafts unless there is a clear reason - Keep one agreed storage location for authoritative exports - Record which audience received which exported snapshot - Match the shared file to the status and version visible in Atloria at the time of export This becomes even more important when teams are also managing approvals and visibility controls, as covered in [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options). ## Fixing Common Export Problems Most export issues in Atloria come from three causes: the export action is not available, the wrong content was exported, or the file is missing important context such as approval details. Start by checking what screen you are on and whether you are exporting from the main record or from **Version History**. If the **Export** option is unavailable on the record toolbar, check these points first: - You are on the correct documentation record page - Your project role or permissions allow export actions - The record is in a state where export is allowed - You are not expecting a version export from the main toolbar when it is only available from **Versions** or **Version History** If the exported file contains the wrong content, the most common reason is that the live record was exported instead of a saved version. Compare the file against the record page and the **Version History** list. If the wording, status, or details do not match the milestone you expected, return to **Version History**, select the correct version by version number, timestamp, or approval state, and export again. If approval or governance details are missing, reopen the export dialog and review the available inclusion options. Look for settings related to: - **Metadata fields** - **Approval information** - **Linked context** If those details are optional, regenerate the export with the needed items selected. When teams are using inconsistent copies of the same record, the problem is usually process-related rather than screen-related. Check whether people are: - Using different version selections - Saving files with unclear names - Storing exports in different locations - Sharing current-record exports when a fixed version snapshot was required [SCREENSHOT: Export dialog with content inclusion options highlighted] If the issue appears to be access-related rather than export-related, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) or [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Overview This guide focuses on how to manage export decisions from documentation records in Atloria, especially when you need to choose between exporting the live record and exporting a saved version from **Version History**. The key workflow is not just clicking **Export**. It is making sure the file matches the purpose of the request. You will usually work from one of two places: - The **Export** action on the documentation record page - The export option attached to a specific entry in **Versions** or **Version History** Those two choices support different outcomes. A toolbar export gives you the current record as it appears on screen, including the latest visible content and record details. A version export gives you a fixed snapshot tied to a selected version number, timestamp, or approval state. That distinction matters when you are preparing files for external review, internal handoff, approval evidence, or audit retention. This guide also covers the practical side of export workflows across teams. You will see when it makes sense for Documentation Managers to distribute approved version snapshots and when Project Administrators may share the current record for operational work. It also explains how to avoid common mistakes, such as exporting the latest draft when the request was actually for an approved milestone. If you need the basic steps for creating an export file before managing broader workflow decisions, refer back to [Exporting Documentation and Related Records](doc:exporting-documentation-and-related-records). The sections here build on that foundation and focus on choosing the right export path, preserving governance context, and keeping teams aligned on which exported file is the authoritative one. ## Prerequisites Before you manage export workflows in Atloria, make sure you have access to the documentation record and can view the parts of the record that affect export decisions. You do not need advanced setup, but you do need enough access to open the record, review its details, and use the available export actions. You should have the following in place: - Access to the relevant project workspace in Atloria - Permission to open the documentation record you want to export - Permission to use the **Export** action or version-level export options - Access to the **Versions** panel or **Version History** if you need a saved snapshot - A clear reason for the export, such as review, sharing, archive, or audit retention Before starting, it is also helpful to confirm the record details that appear on screen: - **Status** - **Owner** - **Last updated** - Current title and body content - Version details such as version number, timestamp, and approval state when exporting from **Version History** If your team uses approvals or formal release checkpoints, make sure you know whether the request is for: - The latest current record - A reviewed draft - An approved version - A release-ready snapshot That decision affects where you start the export and what file you should distribute. If you are unsure whether the record should be shared as-is or exported from a specific saved version, review your team’s approval workflow first in [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). The next guide in this Export Center sequence is [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving). ## Opening a project home page and identifying the main tabs When you open a project in Atloria, the project home page keeps all major project work in one place. At the top of the page, look for the project header. This area shows the current **project name** and gives you the project-level context you should confirm before making any changes. If you recently worked through project workspaces and recent activity, this page builds on that same project-centered workflow described in [Managing Project Workspaces and Recent Activity](doc:managing-project-workspaces-and-recent-activity). Below the header, use the tab bar to move between the main project areas. Depending on your access, you may see tabs for: - **Administration** - **Analytics** - **Versions** - **Technical Documentation** - **Audit** or another audit-related area The selected tab is visually highlighted, and the main content area below it updates to match that tab. You stay inside the same project while switching tabs, so you do not need to go back to the project list each time you want to review a different area. [SCREENSHOT: Project home page showing the project name in the header and the tab bar with one tab highlighted] These tabs are typically used by different roles: | Tab | Typical user | What they do here | |---|---|---| | **Administration** | Project Administrator | Update project setup and management options | | **Analytics** | Project Administrator, Documentation Manager | Review project activity and performance information | | **Versions** | Documentation Manager | Check version history and release progress | | **Technical Documentation** | Documentation Manager | Open and review project-linked documentation | | **Audit** | Project Administrator | Review project activity records and traceability | Before you click into any tab, confirm the project name in the header. That quick check helps you avoid reviewing or editing the wrong project. ## Managing project administration from the home page Use the **Administration** tab when you need to change project-level setup rather than review content. From the project home page, click **Administration** in the tab bar. The content panel switches to project management controls tied to the project shown in the header. This area is where a Project Administrator typically works with project configuration details. Depending on your access, you may use this tab to: - update project settings - maintain project metadata - review project-level management options - open related setup areas connected to the current project Because this tab stays inside the project home page, it is useful when you need to make a change and then immediately check another project area, such as **Versions** or **Technical Documentation**. After you finish an update, return to the tab bar at the top of the page and click the next tab you want to review. You do not need to reopen the project. Permission-sensitive controls may appear only for users with Project Administrator access. If another user opens the same **Administration** tab, they may see fewer actions or no editable controls at all. For example, a Documentation Manager may be able to view project context but not change administrative settings. [SCREENSHOT: Administration tab on a project home page with project settings and management options visible] If you need more detailed guidance on project setup tasks inside this area, continue with the project administration workflow in [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). Use this tab for project setup and management changes; use other tabs when your goal is monitoring, reviewing versions, or working with documentation. ## Reviewing project analytics and version history The **Analytics** and **Versions** tabs support two different kinds of project review. One helps you monitor the project, and the other helps you confirm release and documentation progress. To check project metrics, click the **Analytics** tab from the project home page. This tab is for reading project information rather than changing settings. In Atloria, analytics views focus on monitoring and summary information tied to the current project. You may use this area to review project metrics, reporting panels, or other read-only insight screens that help you understand activity and performance without editing project setup. This makes **Analytics** different from **Administration**. In **Administration**, you change project details. In **Analytics**, you review what is happening in the project and use that information to guide decisions. Next, click the **Versions** tab to inspect the project’s version-related records. Documentation Managers often use this tab to confirm which version is current before editing documentation, preparing a review, or checking release readiness. In this area, look for version entries, release-related records, or revision history connected to the project you opened. A practical way to use these tabs together is: 1. Open **Analytics** to review the current project’s activity or summary information. 2. Switch to **Versions** to confirm the latest project iteration. 3. Verify which version should be updated or reviewed before moving into documentation work. [SCREENSHOT: Project home page with the Analytics tab selected, showing summary panels] [SCREENSHOT: Project home page with the Versions tab selected, showing version entries or release history] If you need deeper help with version-specific tasks after confirming the right entry, continue with [Managing Project Version Workspaces](doc:managing-project-version-workspaces) or [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). ## Working with technical documentation linked to the project Click the **Technical Documentation** tab when you want to open documentation records connected to the current project. This tab keeps you inside the project workspace while shifting the content panel to documentation-related items, which is especially useful when you need to compare project context with the documentation set you are reviewing. Inside this tab, look for the documentation list or navigation area that shows existing technical documentation items for the selected project. From there, open the item you want to review. Depending on the page layout, Atloria may show a list of documentation records first and then a detail view after you select one. The key point is that the documentation you open from this tab remains tied to the project shown in the header. Documentation Managers commonly move back and forth between **Versions** and **Technical Documentation**. That workflow helps you verify that you are reviewing or editing the correct documentation set for the right project version. A simple pattern is: 1. Open **Versions** and confirm the current or target version. 2. Click **Technical Documentation**. 3. Open the documentation item linked to that project. 4. Review the content with the project name and version context in mind. [SCREENSHOT: Technical Documentation tab showing a list of project-linked documentation items] If you need more help understanding the documentation area itself, see [Exploring Technical Documentation Inside a Project](doc:exploring-technical-documentation-inside-a-project). If your next step is editing pages rather than locating them, continue with [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages). When switching between tabs, always recheck the project name in the header before making changes. That is the fastest way to stay in the correct project while moving between project operations and documentation work. ## Checking audit-related areas from the same project workspace Use the **Audit** tab, or the audit-related section available from the project home page, when you need traceability rather than setup controls. This area is for reviewing project activity records and other accountability-focused information tied to the current project. From the project home page, click the audit-related tab in the same tab bar you use for **Administration**, **Analytics**, **Versions**, and **Technical Documentation**. The page content changes, but the project context remains the same. That means you can review project-specific audit information without manually searching for the project again. This area is typically used by a Project Administrator when they need to check: - project activity records - review-related artifacts - compliance-oriented project information - traceable history connected to actions taken in the project Use the audit area instead of **Administration** when your goal is to inspect what happened, not to change settings. For example, if you want to verify whether a project action was recorded or review the history around a project process, the audit-related tab is the better place to start. If you need to update project details, go back to **Administration** instead. [SCREENSHOT: Audit-related project tab showing project-specific activity records or review history] Because this area stays scoped to the current project, it helps reduce mistakes during review. You can switch from **Versions** or **Technical Documentation** into the audit area and keep the same project selected throughout the process. For broader audit guidance beyond the project home page, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls). ## Fixing common navigation and access issues across project home tabs If something looks wrong while moving between project home tabs, start by checking the project header and the tab bar before making any changes. Most issues come from access limits or from working in a different project than expected. ### A tab is missing If you do not see **Administration**, **Versions**, **Technical Documentation**, or an audit-related tab, your account may not have access to that area for the current project. Check with a Project Administrator if you expected to see: - **Administration** or audit-related tabs for project oversight work - **Versions** or **Technical Documentation** for documentation and release work In Atloria, some tabs appear only when your role includes the right project permissions. ### The wrong project content appears If the content under a tab does not match what you expected, look at the **project name** in the header first. This is especially important before changing settings in **Administration** or opening content in **Technical Documentation**. If the wrong project is open, return to your project list and reopen the correct project. ### Analytics or audit content does not load correctly If the **Analytics** or audit-related panel does not appear as expected: 1. Refresh the project home page. 2. Wait for the page to reload fully. 3. Click the tab again to reopen that project-scoped view. This often restores the correct panel for the current project. ### You cannot edit settings or documentation If you can open a tab but cannot make changes, your role may be view-only for that project. Typically: - **Project Administrator** access is needed for administrative changes - **Documentation Manager** access is needed for documentation and version work For related access guidance, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Overview This page in Atloria brings several project operations together under one project header so you can move between setup, monitoring, release work, documentation, and audit review without losing project context. The main value of the project home tabs is that each tab changes the working area while keeping the same project selected. The most important tabs to recognize are: - **Administration** for project setup and management options - **Analytics** for project monitoring and summary information - **Versions** for version history and release-related records - **Technical Documentation** for project-linked documentation items - **Audit** or an audit-related area for project traceability Different roles usually focus on different tabs. A **Project Administrator** spends more time in **Administration** and audit-related areas, while a **Documentation Manager** usually works most often in **Versions** and **Technical Documentation**. **Analytics** can support either role because it helps both monitoring and planning. A good working habit is to treat the project header as your anchor. Before switching tabs, opening documentation, or changing settings, confirm the project name. Then use the tab bar to move to the exact area you need. This reduces the risk of editing the wrong project or reviewing the wrong version. [SCREENSHOT: Full project home page with the header, tab bar, and content area labeled] If you want to go deeper into how the project workspace connects to other linked areas after using these tabs, continue with [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). ## Prerequisites Before using project home tabs effectively in Atloria, make sure the following are already in place: - You can sign in and open your project workspace successfully. If needed, review [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). - You already know how to find and open a project from the project list or dashboard. If not, use [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards). - You are familiar with the recent activity and workspace context for the project, as covered in [Managing Project Workspaces and Recent Activity](doc:managing-project-workspaces-and-recent-activity). - You have the correct project role for the work you need to do. Use this quick role guide before you begin: | If you need to... | Typical access needed | |---|---| | Change project setup or review audit-related records | **Project Administrator** | | Review versions or open technical documentation | **Documentation Manager** | | Monitor project metrics | Project access to **Analytics** | You should also have a specific project ready to open. Since the tabs work inside the current project, they are most useful when you already know which project you want to review. If you plan to work with documentation after checking versions, it also helps to know the project’s current release stage. That way, when you open **Versions** and **Technical Documentation**, you can quickly confirm that you are reviewing the right documentation set for the right project state. ## Opening the project list and understanding what each project card shows In Atloria, the **Projects** area is the starting point for moving between project workspaces. If you already know how the broader dashboard is organized from [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards), this is where that list becomes your day-to-day workspace launcher. When you open **Projects**, you see a list of project cards. Each card represents one project workspace you can access. The most important thing to look for first is the **project name**, because that is the main label you use to confirm you are opening the right workspace. Alongside the name, the card also shows a **status indicator** so you can quickly tell whether the project is active, completed, or otherwise not in a state for current work. This helps you avoid opening projects that are no longer part of your current priorities. Many project cards also include **recent activity** cues. These cues help you judge whether work is happening now or whether a project has been quiet. If you are scanning several projects at once, recent activity is often the fastest way to spot where your attention is needed. Clicking a project card opens that project’s **home page**, which is the main workspace hub for daily work. Think of the card as both a summary and a shortcut. Different roles usually scan the list in different ways: - **Documentation Managers** often look first at status and recent activity to decide where follow-up is needed. - **Project Administrators** usually check which projects are active and which workspace needs coordination. - **Technical Writers** often start with the project name so they can open the assigned workspace quickly and continue work. [SCREENSHOT: Projects list showing multiple project cards with project name, status, and recent activity] ## Finding the right project with search, filters, and sorting When the **Projects** list contains many workspaces, use the list tools before opening anything. Atloria’s project list is designed to help you narrow the view so you can find one workspace quickly or review a smaller group of projects with similar status. Start with the **search field** at the top of the project list. Enter the **project name** to locate a workspace directly. If the list shows other identifying details, you can also use those visible details to help confirm you found the right project. Search is especially useful for Technical Writers who already know which project they need and want to skip portfolio scanning. Next, use the available **filters** to reduce the list. Filters are helpful when you want to focus on projects by **status** or **ownership**. For example, a Documentation Manager may filter for active workspaces to review what needs attention now, while a Project Administrator may narrow the list to projects under a certain owner or responsibility area. Sorting changes the order of the cards. Use **sort by recent activity** when you want the newest updates at the top. Use a **name-based sort** when you want a predictable alphabetical list for easier lookup. Switching between these views is useful when you move between two common tasks: 1. Reviewing the portfolio for current activity. 2. Opening one specific project workspace. If the list starts feeling too narrow or confusing, clear your filters and return to the full project list before starting a new task. This is the easiest way to reset your view and avoid missing a workspace because an older filter is still active. - Use **Search** when you know the project name. - Use **Filters** when you want to review a subset of projects. - Use **Sort** when the right projects are present but not appearing in the order you expect. [SCREENSHOT: Project list toolbar with search, filters, and sort options] ## Reviewing status and recent activity before opening a workspace Before you click into a project, take a moment to read the information shown directly on the project card. In Atloria, this quick review helps you decide whether you need to open the workspace now or whether the card already gives you enough context to move on. The **status indicator** is your first checkpoint. It tells you whether the project is currently active, completed, or in another state that affects whether work is expected. If a project is not active, you may not need to open it unless you are checking history, confirming completion, or reviewing something specific. For managers and administrators, this saves time because you can skip projects that are clearly outside the current work cycle. The next thing to review is **recent activity**. Activity cues help you spot projects that were updated recently and identify where collaboration is happening. If several projects have similar status, recent activity often tells you which one deserves attention first. A project with fresh activity may need review, coordination, or follow-up, while a quiet project may not require immediate action. Use the card alone when you need fast triage: - You want to see which projects are active. - You want to identify which projects were updated recently. - You are deciding where to focus first without opening every workspace. Open the **project home page** when the card is not enough: - The project status needs closer review. - Recent activity suggests work is happening, but you need more detail. - You need to continue work, check updates, or confirm the current project context. For Documentation Managers and Project Administrators, this card-level review is especially useful during daily check-ins. Instead of opening every project, you can use status and activity together to decide which workspaces need immediate attention and which can wait. [SCREENSHOT: Close-up of a project card highlighting status and recent activity details] ## Opening the project home page and moving into daily project work Once you find the right project card, click it to open the project’s **home page**. In Atloria, the project home page is the main hub for that workspace. It brings together the project title, current status, and activity context so you can confirm where you are before you continue with your work. The first thing to check on the home page is the **project title**. This is the quickest way to confirm that you opened the correct workspace. Next, review the visible **status** and any **activity context** shown on the page. This helps you understand whether the project is active, what has changed recently, and whether you are stepping into current work or reviewing a quieter workspace. From the project home page, you can move into the areas used for daily work. Depending on your role, that may include reviewing current items, checking updates, or continuing assigned tasks already in progress. If you recently worked in technical documentation, you can connect this page with what you saw in [Exploring Technical Documentation Inside a Project](doc:exploring-technical-documentation-inside-a-project), but the home page is where you first reorient yourself before moving deeper. Use this basic workflow: 1. Open **Projects**. 2. Find the right project card. 3. Click the card to open the **project home page**. 4. Confirm the **project title** and **status**. 5. Move into the project area where you need to continue work. When you need to switch to another workspace, return to the **Projects** list and choose the next project card. This is especially useful when comparing several projects, checking updates across multiple teams, or moving between assigned writing tasks. [SCREENSHOT: Project home page showing project title, status, and workspace entry points] ## Using project views differently by role People use the same project list and project home page in different ways depending on their responsibilities. In Atloria, the difference is usually not the screen itself, but how you scan it and what you decide to open. A **Documentation Manager** usually works at the portfolio level first. That means starting in the **Projects** list, sorting by **recent activity**, and scanning project cards for status changes or signs that work is moving. Instead of opening every workspace, the manager often opens only the project home pages that show active work, recent updates, or a status that needs attention. This keeps the review focused on projects that need decisions or follow-up. A **Project Administrator** also begins with the project list, but often pays closer attention to **status** and **ownership-related cues** shown in the list. The goal is to monitor progress and move quickly into the correct workspace when coordination is needed. If a project card suggests active work or a change in status, the administrator can open the project home page and continue into the relevant project area for action. A **Technical Writer** usually takes a more direct path. Instead of scanning the full portfolio, the writer often uses **Search** to find the assigned project by name, opens the **project home page**, and checks **recent activity** to understand what changed since the last session. This makes it easier to resume in-progress work without reviewing unrelated projects. A simple way to separate the two levels of work is: | Where you work | Best used for | |---|---| | **Projects list** | Finding workspaces, scanning status, reviewing recent activity across many projects | | **Project home page** | Confirming project context, checking current updates, and continuing project-specific work | If your task is “Which project needs attention?”, stay in the list first. If your task is “What do I need to do inside this project?”, open the home page. ## Common issues when locating projects or interpreting activity If you cannot find the project you need, start with the simplest checks in the **Projects** list. In many cases, the project is there, but the current search, filter, or sort setting is hiding it or moving it lower in the list. If a project does not appear, first review the **search field**. A partial or incorrect project name can narrow the list too much. Clear the search and try again with the exact project name if you know it. If the list is still missing the project, remove any active **filters**. A status or ownership filter may be excluding the workspace you expect to see. If the project still does not appear after clearing search and filters, the most likely explanation is that you do not currently have access to that workspace. If the wrong projects appear first, check the current **sort order**. A list sorted by name will look very different from one sorted by recent activity. Switch the sort setting to match your goal: - Use **recent activity** when you want the newest updates first. - Use **name** when you want easier lookup by project title. Sometimes **recent activity** on a card is not enough to make a decision. If the activity cue feels too brief or unclear, open the **project home page** and review the fuller project context there before deciding what action to take. If you open the wrong workspace, do not continue based on assumption. Check the **project title** on the home page immediately. If it is not the project you intended, return to **Projects**, refine your search or filters, and open the correct card. [SCREENSHOT: Project list with search cleared, filters reset, and sort menu open] ## Overview This guide focuses on one practical goal: using the **Projects** list and the **project home page** to move quickly between workspaces and understand where attention is needed. In Atloria, these two views work together. The project list gives you a broad view across all available workspaces, while each project home page gives you the context needed to continue work inside one project. The **project list** is best for scanning. It helps you compare project cards by **project name**, **status**, and **recent activity** without opening each workspace one by one. This is especially useful when you are reviewing multiple projects, checking which workspaces are active, or deciding where to focus first. Search, filters, and sorting make that review faster by narrowing the list to the projects that matter for the task at hand. The **project home page** is best for action. Once you open a project card, the home page becomes the workspace hub where you confirm the **project title**, review the current **status**, and use visible activity context to continue daily work. From there, you can move into the project areas that support writing, review, coordination, or follow-up. This guide does not repeat the deeper technical documentation browsing covered in [Exploring Technical Documentation Inside a Project](doc:exploring-technical-documentation-inside-a-project). Instead, it stays focused on the transition between portfolio-level scanning and workspace-level work. The key idea is simple: - Use the **Projects** list to decide **where** to work. - Use the **project home page** to decide **what** to do next. That distinction helps Documentation Managers, Project Administrators, and Technical Writers all use the same Atloria screens efficiently, even when their daily priorities are different. ## Prerequisites Before you use the workflow in this guide, make sure the following are true in Atloria: - You can sign in to your Atloria account and reach the main dashboard. If you need help with access, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). - You already have access to at least one project workspace that appears in the **Projects** area. - You understand the basic dashboard and project list layout covered in [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards). - You are ready to work from the **Projects** list into a specific **project home page**. - If you plan to continue documentation work after opening a workspace, it helps to already be familiar with [Exploring Technical Documentation Inside a Project](doc:exploring-technical-documentation-inside-a-project). You do not need any special setup to follow this guide beyond normal project access. The main requirement is that the project you want to open is visible in your **Projects** list. If it is missing, use the troubleshooting steps in **Common issues when locating projects or interpreting activity** to check search, filters, sorting, and workspace access. This guide is most useful when you are doing one of these common tasks: - Finding an assigned project quickly - Reviewing which projects are active - Checking which workspaces show recent activity - Opening the correct project home page before continuing work - Switching between multiple project workspaces during the day After you are comfortable moving between the project list and the project home page, continue with [Managing Project Operations Across Project Home Tabs](doc:managing-project-operations-across-project-home-tabs) to work more effectively inside each project workspace. ## Opening the support agent workspace and understanding what appears there In Atloria, you work with support agent setup from the authenticated workspace after signing in. If you need help getting into your account or moving around the signed-in areas, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) and [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). After you enter the main workspace, support-related setup is handled as part of your project and administration flow rather than from the public documentation view. Team leads and project administrators typically move through the signed-in dashboard, open the relevant project, and then use the support agent areas connected to that project’s documentation setup. From there, you can review the support agent workspace, open individual agent records, and move into behavior or knowledge-related settings without leaving the broader project context. The workspace separates day-to-day support agent use from setup work. In practice, this means the people responsible for configuration open screens where they can inspect agent details, review linked documentation sources, and adjust how an agent should respond. The people who maintain documentation usually focus on the knowledge source side, while support team leads focus on the agent itself and project administrators handle access or broader project settings. Look for these main workspace areas as you move through the support setup flow: - The project workspace where the support agent belongs - The agent list or agent management view - The individual agent details screen - The knowledge source area where documentation is connected - The behavior settings area for response configuration [SCREENSHOT: Signed-in Atloria workspace showing project navigation and the support agent management area] This document focuses on organizing the workspace and connecting knowledge. If you still need to create the agent itself, start with [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents). ## Reviewing how support agents are organized Support agents are easiest to manage when you start from the list view that shows the agents already available in a project. In Atloria, this management view is where support team leads check which agents exist before opening one to review its setup. Instead of changing behavior or knowledge sources from memory, use the list first so you are always working on the correct agent. From the agent list, open each record to confirm the basics before making changes. The key details visible from this kind of screen are the agent name, the project it belongs to, and the entry points that take you into its settings. This helps you distinguish one support agent from another when a project has more than one agent or when several projects are being maintained at the same time. A practical review flow looks like this: 1. Open the signed-in workspace and go to the project that contains the support agent. 2. Open the support agent management area for that project. 3. Review the list of existing agents and identify the one you want to update by name. 4. Select the agent to open its details. 5. Use the available settings links or tabs to move into behavior or knowledge setup. When you inspect an agent record, pay attention to whether you are editing the correct project context. This matters most for teams that maintain multiple documentation sets, because the wrong project selection can lead to the wrong knowledge being attached later. Use the agent management view for these common tasks: - Add a new support agent - Open an existing agent - Check which project the agent belongs to - Move into behavior settings - Move into documentation knowledge settings [SCREENSHOT: Support agent list showing multiple agents with names and links to open details] If you are cleaning up existing setup, review each agent one by one before changing its behavior. That makes it much easier to keep workspace ownership clear between team leads, documentation managers, and administrators. ## Configuring agent behavior from the UI Once you open an individual support agent, use its settings area to review how that agent is expected to respond in its assigned workspace. In Atloria, support team leads usually handle this part because behavior settings affect the quality and consistency of answers users receive. Start from the selected agent’s details screen and open the behavior-related settings available there. These controls are where you adjust how the agent operates for that specific support setup. Because behavior settings are tied to the selected agent, always confirm the agent name before making changes. A typical update flow is: 1. Open the project’s support agent list. 2. Select the agent you want to edit. 3. Open the behavior settings area from the agent details screen. 4. Review the available fields and switches that control how the agent responds. 5. Update the settings that need to change. 6. Click **Save** to apply the new behavior configuration. After you save, stay on the page long enough to confirm the change was accepted. If Atloria shows the updated values in the agent settings screen, that is your first check that the update was stored correctly. If you leave the page too quickly or switch to another tab without saving, your changes may not be applied. Use individual agent settings when: - One agent needs a different response style from others - A specific project needs its own support approach - You are testing a change on a single agent before using it more broadly Use project-level setup when: - Multiple agents in the same project should follow the same baseline behavior - A project administrator is maintaining shared support rules - You want consistency across the whole project workspace [SCREENSHOT: Agent details screen with behavior settings and Save button] For teams with shared ownership, let support team leads adjust the agent’s response setup, while project administrators manage broader defaults that affect the whole project. The next document, [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability), goes deeper into those behavior choices. ## Connecting documentation knowledge sources for support agents A support agent is only as useful as the documentation it can rely on. In Atloria, documentation managers usually maintain this part of the setup by opening the knowledge source area connected to the support agent or project workspace and selecting the documentation that should be available to that agent. Begin from the support agent workspace or the selected agent’s details screen, then open the knowledge or documentation source section. This is the area where you connect approved documentation so the agent can answer questions using the right project content. If your team manages several documentation sets, review the project name carefully before attaching anything. Use this process to connect documentation knowledge: 1. Open the correct project and select the support agent you want to update. 2. Go to the knowledge source or documentation source area. 3. Review the documentation currently attached to the agent or workspace. 4. Add or select the documentation sources that should be used. 5. Remove any sources that are outdated or no longer approved. 6. Click **Save** to keep the updated knowledge configuration. Documentation managers should include sources that are current, reviewed, and relevant to the support experience. If a source is old, incomplete, or tied to the wrong project, it can lead to poor answers. For that reason, it is better to keep the source list focused than to attach every available document without review. When deciding what to include, check whether the source is: - Part of the correct project - Current enough for active support use - Intended for the same audience the agent serves - Still approved for team use After saving, reopen the knowledge source area and confirm the selected documentation is still listed. That quick check helps catch cases where a source was not actually attached. [SCREENSHOT: Knowledge source settings showing selected documentation attached to a support agent] If your team also manages project documentation structure, related guidance in [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking) can help you keep source selection consistent. ## Managing access and ownership for workspace configuration Support agent setup works best when each person owns a clear part of the workflow. In Atloria, the most common split is simple: support team leads manage agent behavior, documentation managers maintain knowledge sources, and project administrators control access and project-wide setup. This division matters because not every signed-in user should be changing every part of the support workspace. Some tasks affect only one agent, while others affect the whole project. If too many people edit the same settings without coordination, it becomes difficult to tell why an agent’s answers changed or why a documentation source disappeared. Use the following ownership model as a working guide: | Role | Typical responsibilities | |---|---| | Support Team Lead | Open agent records, review assigned agents, update behavior settings, verify agent responses | | Documentation Manager | Curate documentation sources, add or remove approved knowledge, keep source content current | | Project Administrator | Control project access, manage broader project setup, handle higher-level support configuration | Tasks that usually require elevated access include: - Editing project-level support setup - Changing broader workspace settings - Managing who can access the project - Updating configuration that affects more than one agent Tasks that are often handled as routine maintenance include: - Opening an existing agent - Reviewing its current settings - Updating the attached documentation sources - Testing whether the agent uses the expected content To avoid conflicting changes, agree on a simple handoff. For example, the documentation manager updates the source list first, then the support team lead tests the agent, and the project administrator only steps in when access or project-wide settings need to change. [SCREENSHOT: Project workspace showing support setup areas used by team leads, documentation managers, and administrators] If you need a broader view of project ownership and workspace responsibilities, see [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). ## Verifying the workspace and knowledge configuration After you save changes, verify the setup before your team relies on the support agent. In Atloria, this means checking three things in the workspace: the correct agent is selected, the latest settings are visible, and the right documentation sources are attached. Start by reopening the agent details screen. Confirm that the agent name matches the one you intended to update and that the behavior settings still show your latest changes. Then move to the knowledge source area and make sure the selected documentation is listed there. If the source list looks incomplete, return to the previous screen and check whether the last update was saved. Use this verification flow: 1. Reopen the support agent from the project’s agent list. 2. Review the behavior settings and confirm the latest values are visible. 3. Open the knowledge source area and check that the expected documentation is attached. 4. Test the agent from the workspace using a question that should be answered from the selected documentation. 5. Compare the response with the documentation you intended the agent to use. If the answer looks wrong, check these common causes: - You edited the wrong support agent - The latest changes were not saved - The documentation source was not attached - The source belongs to a different project - You do not have permission to complete the update A quick test question is often the fastest way to catch a setup problem. Ask about a topic that appears clearly in the attached documentation. If the answer does not reflect that content, return to the knowledge source settings and review the attached sources again. [SCREENSHOT: Support agent workspace showing agent details, knowledge sources, and a test conversation area] Once the workspace and knowledge setup look correct, continue with [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability) to refine when the agent is available and how it should respond in live use. ## Overview This document covers the day-to-day setup work that happens after a support agent has already been created in Atloria. The focus here is the workspace used to manage that agent inside a project: where to find the agent, how to review its settings, how to connect documentation knowledge, and how to confirm the setup is working as expected. The most important idea is that support agent management in Atloria is tied to project context. Team leads, documentation managers, and project administrators all work from the signed-in workspace, but they do not usually change the same things. Support team leads focus on the selected agent and its behavior settings. Documentation managers decide which documentation sources should be available to the agent. Project administrators handle access and broader project-level setup. You will use the support workspace to: - Open the correct project - Review the list of existing support agents - Open an individual agent’s details - Adjust behavior settings for that agent - Attach or remove documentation knowledge sources - Verify that the agent uses the expected content This guide does not repeat the steps for creating a support agent from scratch. If you still need to add the agent itself, go back to [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents). It also does not go deeply into advanced behavior options or availability rules, because those are covered next in [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability). [SCREENSHOT: Atloria project workspace with support agent management, settings, and knowledge areas highlighted] Use this guide when you need to keep an existing support agent aligned with the right project content and make sure the people responsible for setup are working in the correct part of Atloria. ## Prerequisites Before you work on support agent workspaces and knowledge setup in Atloria, make sure the basic project and account pieces are already in place. This helps you avoid getting partway through the setup only to find that the agent, project, or documentation source is missing. You should have the following ready: - An Atloria account that can sign in to the authenticated workspace - Access to the project where the support agent belongs - At least one existing support agent to review or update - Documentation content already available in the project - The appropriate role for the task you need to complete The role split matters: - **Support Team Lead**: updates agent behavior and verifies responses - **Documentation Manager**: maintains the documentation sources used by the agent - **Project Administrator**: manages project access and broader project-level setup It also helps to confirm these conditions before you begin: - You can open the project workspace without access errors - You can see the support agent management area for that project - The documentation you want to attach is already present in Atloria - You know which agent should use which documentation set If any of those pieces are missing, use these related guides first: - [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) - [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) - [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) - [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) [SCREENSHOT: Project selected in Atloria with support agent area available in the signed-in workspace] With those items in place, you can move through the support workspace confidently and make changes without guessing which project, agent, or documentation source should be connected. ## Opening the project documentation workspace In Atloria, start from your project workspace and open the area where generated technical documentation is available for that project. This is the browsing space you use to read the generated reference pages, move through sections, and confirm how Atloria has organized the project’s technical content. If you already reviewed the basics of reading reference pages, use [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages) as your companion for page-level reading patterns. Here, the focus is on moving around inside the project workspace itself. When the documentation area opens, look for four main regions on the screen: - The **overview page** in the main content area when you first arrive - The **left-hand navigation tree** for moving between sections - The **content pane** where the selected page opens - The **breadcrumb trail** near the top of the page so you can see where you are [SCREENSHOT: project documentation workspace showing the left navigation tree, overview page, content pane, and breadcrumb trail] If your project has more than one generated output, version, or branch-based documentation view, first confirm which one you are looking at before you begin review work. Use the version or build selector shown in the project workspace, if available, and make sure it matches the release, branch, or generated documentation set you intend to review. This matters when you are checking whether a page is missing, outdated, or newly added. Different team members use this same workspace in slightly different ways: - **Documentation Managers** review structure, completeness, and release readiness - **Technical Writers** confirm names, descriptions, and internal linking before editing related content - **Project Administrators** validate that the generated documentation appears in the right project context and is available to the right people Even though the purpose differs, everyone starts in the same place: the project’s generated documentation area, with the navigation tree on the left and the selected page open in the main pane. ## Moving between overview pages, API sections, and entity details The easiest way to browse generated technical documentation in Atloria is to begin on the **overview page**. This page acts as your starting map. Depending on the project, it may show top-level sections such as API groups, modules, or an index of entities. Use this page when you want a quick sense of what Atloria generated for the current project before opening individual detail pages. 1. Open the project’s generated documentation area. 2. Review the overview page in the main content pane. 3. Look for top-level section links, cards, or index tables that represent the main documentation groups. 4. Click a section name to open that part of the reference. 5. Use the **left-hand navigation tree** to expand deeper levels and jump to a specific page. As you move beyond the overview, the navigation tree becomes the fastest way to browse. Expand a section to reveal the pages underneath it. You may see grouped pages for endpoints, schemas, models, or other generated reference items. Click any item in the tree to open its page in the content pane. You can also move forward from inside the page itself. Overview cards and index tables often link directly to a detail page. For example, you might open a section page first, then select a linked entity page from an index list in the content area. This is useful when you want to scan a group before deciding which page deserves closer review. When you need to step back, use the **breadcrumbs** at the top of the page. They let you return from a detail page to its parent section, and then back to the project-level overview, without collapsing your place in the navigation tree. [SCREENSHOT: overview page with section cards and a navigation tree expanded to show detail pages] This combination—overview page, navigation tree, in-page links, and breadcrumbs—gives you a reliable way to move from broad structure to detailed reference and back again. ## Using page navigation tools to stay oriented while browsing When you are deep inside generated documentation, staying oriented matters as much as opening the right page. Atloria gives you several visual cues that help you confirm where you are and what is currently selected. Start with the **breadcrumb trail** at the top of the page. Read it from left to right to understand the page hierarchy. In most cases, it shows a path similar to project documentation overview, then a section, then the current detail page. If you open a deep page from a link or from search, the breadcrumbs are the quickest way to understand how that page fits into the larger structure. On long pages, look for a **table of contents** or **in-page anchor links**, if they are shown. These links help you jump to major headings without scrolling through the entire page. They are especially useful on API and entity pages that contain several sections. Common heading areas may include: - Endpoints - Parameters - Request fields - Response fields - Examples - Related items The **left-hand navigation tree** also helps you stay grounded. Watch for these visual signals: - The currently open page is usually highlighted or selected - Parent sections may remain expanded while you browse child pages - Active headings on the page may be marked in the in-page navigation area If you move through several pages and want to retrace your steps, use your browser’s **Back** and **Forward** buttons. In Atloria, this is a practical way to compare nearby pages or return to a previously opened detail page without rebuilding your path from the overview. [SCREENSHOT: breadcrumb trail above a detail page with an in-page table of contents and highlighted navigation item] Use these tools together. The breadcrumb trail tells you the page’s place in the hierarchy, the navigation tree shows what else is nearby, and in-page links help you move through long reference pages without losing focus. ## Reviewing entity and API details during documentation work Generated technical documentation is most useful when you treat it as a review workspace, not just a reading view. In Atloria, open detail pages to verify that the generated reference matches the structure and terminology you expect before you publish or revise related documentation. On an **entity detail page**, review the generated metadata carefully. Depending on the page, you may see: - **Field names** - **Data types** - **Required** markers - **Descriptions** - Links to **related entities** These details help you confirm whether the page is complete and whether the naming is understandable for your documentation audience. If a field list looks thin, a description is missing, or related items are not linked, that is a useful signal for follow-up during documentation review. On an **API section page**, look for the main reference elements that support endpoint review. These may include: - Endpoint paths - HTTP methods - Parameter tables - Request schema details - Response schema details - Status code information Use the section page and the related detail pages together. Start with the overview or index listing to see what Atloria says exists in that section, then open the individual pages to verify the details. This side-by-side mental check helps you catch problems such as incomplete grouping, missing descriptions, or pages that exist in the index but do not contain enough information. [SCREENSHOT: API detail page showing endpoint path, method, parameters, request details, and response details] This browsing workflow is especially helpful during writing and review. Technical Writers can confirm terminology before drafting supporting content. Documentation Managers can validate structure and internal consistency. Project Administrators can check that the generated output is complete enough for broader review. If the overview suggests a section should exist but the detail page is sparse or missing key information, that is a clear sign to investigate the project’s generated documentation output before release. ## Finding the right documentation page quickly When a project contains many generated pages, opening the right one quickly becomes part of the job. In Atloria, the fastest route depends on whether you already know the exact item you want or whether you need to scan the structure first. If project documentation search is available in your workspace, use it when you know a specific name or fragment. Search works best when you enter a precise term such as: - An endpoint name - An entity name - A field label - Part of a path This is usually faster than expanding every section in the left-hand navigation tree, especially in larger projects. Once the result opens, use the breadcrumb trail to understand where that page belongs in the project’s generated documentation. If you are less certain about the exact page, start from an **overview index page** instead. Overview pages are better for scanning all modules, API groups, or entities in one place. They help you compare nearby items before opening a detail page. This is often the better choice during review work, because it lets you see whether something is missing from the list before you drill into individual pages. Deep links can also drop you directly onto an entity page without showing the surrounding context first. When that happens, use: - The **breadcrumbs** to move up one level - The **parent section link**, if shown on the page - The **left-hand navigation tree** to see related pages nearby [SCREENSHOT: search field or search results inside project documentation, with breadcrumbs visible above the opened result] A good pattern is to search when you know the target, use overview pages when you need to scan the structure, and rely on breadcrumbs when you land deep in the hierarchy and need to rebuild context quickly. ## Fixing common browsing problems inside project documentation If the generated documentation does not look right in Atloria, start by checking what you are viewing before assuming the content is wrong. Many browsing issues come from opening the wrong project output, an outdated generated set, or a page that has not refreshed after recent changes. If the **navigation tree is missing sections**, first confirm that documentation generation finished for the project and that you are viewing the correct build, branch, or version. A missing section may simply mean you are looking at an older generated output. Compare the current view with the expected project version before reporting a content problem. If an **entity detail page is missing expected fields or relationships**, go back to the parent overview or index page and compare what is listed there with what appears on the detail page. This helps you tell the difference between a browsing issue and incomplete generated content. If the item appears in the index but the page itself is sparse, the generated output may need attention. If **links between section pages and detail pages do not open correctly**, refresh the documentation view and try again. If the problem started after recent project changes, verify that the project documentation was regenerated so the links reflect the latest output. If someone **cannot access the documentation area at all**, check whether they have the right project-level access. In practice, this usually affects team members who should be working in the documentation space, such as Documentation Managers, Technical Writers, or Project Administrators, but do not currently have the needed permissions. Use this quick reference when troubleshooting: | Problem | What to check | What to do next | |---|---|---| | Missing sections in the navigation tree | Current build, version, or branch | Switch to the correct output and reload the page | | Sparse entity detail page | Parent overview or index listing | Compare the listing with the detail page to confirm incomplete output | | Broken links between pages | Recent documentation changes | Refresh the view and confirm documentation was regenerated | | No access to documentation area | Project-level permissions | Review access for the affected user’s role | ## Overview This guide focuses on how to browse generated technical documentation inside a project in Atloria. The main goal is not to explain how to read a single reference page in isolation, but how to move through the project documentation workspace efficiently while reviewing structure, completeness, and internal linking. Inside a project, you typically work across three connected page types: - A **documentation overview page** that shows the top-level structure - **API or section pages** that group related reference content - **Entity detail pages** that show the specific fields, parameters, descriptions, and related items for one generated reference item The key navigation tools that support this workflow are the **left-hand navigation tree**, the **content pane**, and the **breadcrumb trail**. On longer pages, a **table of contents** or **in-page anchor links** can help you move between headings without losing your place. Together, these controls make it easier to review generated output during documentation work. This browsing workflow is useful for several kinds of users in Atloria: - **Documentation Managers** checking structure and release readiness - **Technical Writers** confirming names, descriptions, and page relationships - **Project Administrators** validating that the correct generated output is visible in the project You will get the most value from this workspace when you use it actively: start from the overview, drill into section pages, open detail pages, and then move back up with breadcrumbs to confirm that the documentation is grouped clearly and linked correctly. The next document, [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views), builds on this by showing how the same reference content is used across internal project views and published documentation views. ## Prerequisites Before you work through this browsing workflow in Atloria, make sure the basics below are already in place: - You can sign in to Atloria and open the correct project workspace - The project already has generated technical documentation available to browse - You have access to the project documentation area as a Documentation Manager, Technical Writer, Project Administrator, or another role with equivalent project access - You know which project version, branch, or generated output you are supposed to review - You are already familiar with the basic layout of API and technical reference pages from [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages) It also helps to know what kind of review you are doing before you begin. For example: - If you are checking **structure**, you will spend more time on overview pages and the navigation tree - If you are checking **terminology or completeness**, you will spend more time on entity detail pages - If you are checking **internal linking**, you will move frequently between overview pages, section pages, and detail pages using breadcrumbs and in-page links If your project contains multiple generated outputs, confirm the correct one before starting. Many review mistakes happen when someone opens the right project but the wrong documentation version. You do not need to edit content to follow this guide. The steps here are about browsing, locating, and reviewing generated documentation inside the project workspace so you can support writing, validation, and release review work more confidently. ## Opening a project’s version lists and understanding what each status means In Atloria, version work happens inside a specific project, so start by opening the project you want to review. From the main workspace, go to the project area and open its version list. Before you click into any version, check the project name shown in the page header so you know you are looking at the correct project. This matters when several projects use similar version names. Use the version list as your release tracking view. Each row represents one version and helps you scan the project’s progress at a glance. Look across the row for the version name, the creation date, and the status badge. Those three items tell you what the version is, when it was created, and how far it has moved through the documentation workflow. The status badge is the quickest way to understand what you can do next: - **Draft** or another early editing state means the version is still being prepared. - **In progress** means content work is still active and the version is not yet ready for formal review. - **Review-ready** or a similar review state means the version can be opened for checking and approval work. - **Released** or **Published** means the version has moved beyond review and is being treated as a completed release state. These badges help Documentation Managers and Project Administrators separate versions that still need writing or cleanup from versions that are ready for review decisions. If you already worked through release-cycle planning in [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle), this page is where that planning becomes visible day to day. [SCREENSHOT: Project version list showing version name, creation date, and status badge] ## Reviewing version details and moving between status-driven workflows Once you find the version you want, open its row to move from the list into the version’s detail page. This page gives you a closer view of that version’s current state and is the best place to confirm whether the version is still being prepared, already under review, or close to release. 1. Open the project’s version list. 2. Find the version by its name and status badge. 3. Click the version row to open its detail page. 4. Review the status shown near the top of the page. 5. Check any available output and review actions before deciding your next step. The version detail page is where status starts to control your workflow. If the version is still in a draft or active editing state, you should treat it as work in progress. In that case, comparison results may be incomplete, and review activity may not yet be useful. If the version has moved into a review-ready state, the page becomes a launch point for formal checking and release decisions. Technical Writers can use this page to answer a simple question before sharing anything: “Is this version ready for someone else to review?” If the status still shows active preparation, continue editing or wait for the version to advance. If the status shows review readiness, you can move into review and comparison work with more confidence. Status also affects downstream tasks. A version that is still being prepared is usually not a reliable release candidate. A version that has reached review-ready status is much more useful for side-by-side comparison, approval discussions, and release tracking. When you use the detail page first, you reduce the chance of comparing unfinished work or sending reviewers to the wrong version. [SCREENSHOT: Version detail page with status area and available actions] ## Opening review pages for a version and checking review readiness The review page is the handoff point between preparing content and asking others to evaluate it. You can usually reach it from the version list or from the version detail page, but before opening it, confirm that the version status supports review. If the version is still being edited, sending someone to review it too early can create confusion and unnecessary feedback. 1. Open the project’s version list. 2. Locate the version you want to review. 3. Check the status badge in the row or on the detail page. 4. If the status shows a review-ready stage, select the review action. 5. On the review page, confirm the version label and project context in the header. 6. Inspect the rendered output and any visible review context before sharing it with others. On the review page, focus on the elements that support release decisions. First, verify that the page clearly shows the correct version. Next, read through the rendered output rather than relying only on the version name. This helps you confirm that the content matches the intended release stage. If the page includes review context or visible indicators tied to the version, use them to make sure reviewers are looking at the right material. Documentation Managers often use this page as the formal checkpoint before approval tracking begins. Instead of reviewing scattered draft pages, they can send stakeholders to one version-specific review view. That makes it easier to align comments, confirm completeness, and decide whether the version is ready to move forward. If the review option is not available, return to the version status first. In most cases, the version has not advanced far enough in the workflow yet. It is better to resolve that status issue before asking for review. [SCREENSHOT: Review page showing version label, project header, and rendered output] ## Comparing outputs between versions to see what changed Comparing versions helps you answer a practical question: what changed between one release stage and another? In Atloria, use the compare action from the version list or the version detail page when you need to inspect changes before review, approval, or release planning. 1. Open the project’s version list. 2. Identify the first version you want to use as the starting point. 3. Select the compare action. 4. Choose the second version you want to compare against. 5. Open the comparison view. 6. Confirm the source version and target version shown at the top of the page. 7. Review the differences, paying attention to added, removed, and changed content. Always pause on the comparison header before reading the results. If the wrong source and target versions are selected, the page may still show valid differences, but they will not answer the question you intended to ask. The version names in the comparison header are your final check that the diff reflects the correct release progression. Use the comparison view to focus on meaningful output changes. Look for: - New sections added for the upcoming release - Removed sections that may affect existing readers - Updated wording that changes instructions or product behavior - Differences large enough to affect release notes or approval decisions A common pattern is to compare a draft or in-progress version against the latest released version when you want to measure how much has changed since the last public release. Another useful pattern is comparing two review-ready versions in the same project when you need to understand which one is the stronger release candidate. In both cases, the compare view gives you evidence for release decisions instead of relying on memory or informal notes. [SCREENSHOT: Version comparison page with source version, target version, and highlighted changes] ## Using statuses and comparisons to track release readiness across a project Version lists become much more useful when you read statuses and comparisons together. The status column tells you where each version sits in the workflow, while the comparison view tells you whether the content changes match what you expected for the release. 1. Open the project’s version list and scan the status column. 2. Separate versions into three groups: still being prepared, awaiting review, and likely release candidates. 3. Open the versions that appear closest to release. 4. Compare those versions against the latest released version or another review-ready version. 5. Use both the status badge and the comparison results to decide whether the version is ready to move forward. When you scan the list, look for versions that remain in preparation longer than expected. Those versions may be blocked, incomplete, or simply waiting for someone to finish content updates. Versions in a review-ready state deserve closer attention because they are the most likely candidates for release decisions. Versions already marked as released or published give you a baseline for comparison. Project Administrators can use one project’s version list to monitor several active release tracks at once. If one version is still in progress while another is ready for review, the list helps you spot where work is moving and where it has stalled. Documentation Managers can then open the review page to judge content quality and open the compare view to judge release completeness. This combination is especially helpful when a version looks ready based on status alone but the comparison results show missing sections or unexpected removals. In that situation, the status may say “ready,” but the output still needs attention. Using both views together gives you a more accurate picture of release readiness than either one on its own. ## Fixing common problems when statuses, reviews, or comparisons do not look right When something feels off in the version workflow, start with the visible context on the screen: project name, version label, status badge, and the action you expected to use. Most problems come from opening the wrong version, checking the wrong project, or trying to review a version that is still too early in the workflow. If the **Review** option is missing: - Open the version detail page. - Check the current status near the top of the page. - If the version is still in **Draft** or **In progress**, treat that as the reason the review action is not available yet. - Return after the version reaches a review-ready state. If the comparison page shows unexpected differences: - Reopen the compare action from the version list or detail page. - Confirm you selected the intended source version and target version. - Check the comparison header before reading the results. - If the version names are not the ones you expected, start the comparison again. If a version seems to be in the wrong release stage: - Open the version detail page for that version. - Review the current status shown there rather than relying only on memory. - Confirm whether the workflow step that marks the version as ready has actually been completed. - If the status still does not match the work already done, pause review or sharing until the version state is corrected. If teammates are reviewing the wrong version: - Ask them to check the project name in the header. - Ask them to confirm the version label on the review page or comparison page. - Compare that label with the version row in the project’s version list before continuing. [SCREENSHOT: Version detail page highlighting project name, version label, and status badge] ## Overview - This guide focuses on how to work with a project’s version list in Atloria after versions already exist. - You use the version list to identify each version by its name, creation date, and status badge. - Status badges help you quickly tell whether a version is still being edited, ready for review, or already treated as released or published. - From the version list or a version’s detail page, you can open review pages and comparison views. - Review pages help you confirm that a version is ready for formal checking and approval work. - Comparison views help you see what changed between two versions so you can support release decisions with visible output differences. - This guide does not repeat version planning basics covered in [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle). - Use this guide when you need to: - monitor multiple versions inside one project - confirm whether a version is ready for review - compare release candidates against earlier versions - spot versions that appear stalled before release ## Prerequisites - You can sign in to Atloria and open the main authenticated workspace. - You have access to at least one project that includes documentation versions. - The project already contains version entries in its version list. - You can open the project workspace and view version-related pages. - If you need help getting into Atloria or moving through account screens, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) and [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). - If you need help finding the right project before working with versions, see [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards). - If you need a broader explanation of how versions fit into the release cycle, review [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle). For the next step in this workflow, continue with [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness). ## Opening the version review page and confirming you can act on it If you already know how to open a version and start a review from [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions), the next step is making sure you can actually record a decision. 1. In Atloria, open your project and go to the version list where documentation versions are shown. 2. Select the version you want to review to open its details page. 3. Look for the **Review** action on the version page and open it. 4. At the top of the review page, confirm you are looking at the correct version by checking the visible version details, such as the version name and any revision label shown on the page. 5. Check the current review state before doing anything else. If the page shows that the version is already **Approved**, **Rejected**, or no longer waiting for review, you may not be able to submit a new decision. 6. Review the release context shown on the page. If the version is tied to a release or publication target, make sure it matches the release you intend to approve. Before you continue, confirm that your access level allows you to make a final decision. In Atloria, **Documentation Managers** and **Project Administrators** can finalize approval decisions. **Technical Writers** may be able to add comments, respond to feedback, or prepare updates, but may not see the final **Approve** or **Reject** buttons. The review page also gives you the context you need for a safe decision. Check the reviewer area for assigned reviewers, and look for any visible release or publication information connected to this version. [SCREENSHOT: Version review page showing the version name, review status, reviewer list, and Review action] If the page does not show a pending review, or if the decision buttons are missing, stop here and confirm the version’s current state and your access before proceeding. ## Checking review status, reviewers, and pending decision details Once you are on the review page, read the status area carefully before making any decision. This section tells you whether the version is still waiting for review or whether something is already blocking approval. 1. Find the review status panel or status indicator near the top of the page. 2. Read the current state shown there. In Atloria, you may see outcomes such as **awaiting review**, **approved**, **rejected**, or a state that indicates the review cannot move forward because feedback is still unresolved. 3. Open or scan the reviewer section to see who has already responded and who is still pending. 4. Check whether all required approvers have completed their review or whether the version is still waiting on one or more people. 5. Review the activity history or decision history area for earlier actions on this version. The reviewer area is especially important when more than one person is involved. A version may look nearly complete, but still remain pending because another required reviewer has not responded. If Atloria shows approval progress, use that area to confirm whether your decision will complete the review or only record your own response. The history area helps you avoid repeating earlier issues. Look for timestamped updates, earlier approval attempts, and any rejection notes already attached to the version. If someone previously rejected the version, read the reason before approving it. You should also review any linked comments, change requests, or unresolved discussions shown on the page. A version that still has open feedback may not be ready for final approval even if most reviewers have responded. Use this section as your review checkpoint: - **Status** tells you where the version stands now - **Reviewers** tell you who has acted and who is still pending - **History** tells you what happened earlier - **Comments** tell you what still needs attention [SCREENSHOT: Review status panel with reviewer responses, pending approvals, and decision history] ## Reviewing changes before approving the version A review decision should be based on the actual changes in the version, not only the status panel. Before you click **Approve** or **Reject**, open the changes view and inspect what was added, removed, or updated. 1. From the version review page, open the comparison view or changes view for the version. 2. Review the list of changed pages to see which pages were added, edited, or removed. 3. Open individual pages that matter most for the release and check the content directly. 4. Look for page-level indicators that show unresolved comments, validation issues, or other items still needing attention. 5. Use the comment tools or feedback controls to ask for clarification if a page is unclear but does not require a full rejection yet. When you review the changed content, pay attention to both content and structure. A version may include rewritten instructions, new pages, removed sections, or updates to version details and related information. If the page list highlights problem areas, use those markers to focus your review first. Unresolved comments and failed checks are strong signs that the version still needs work. If you find a small issue that can be clarified quickly, leave a comment instead of rejecting the entire version immediately. This is especially useful when the overall version is close to ready and the writer only needs to answer a question or adjust one section. Inline comments and discussion threads help keep the review moving without losing context. Before approving, confirm that the version is complete enough for its release stage. In practice, that means checking: - the changed pages are present and readable - important feedback has been addressed - required reviewers are participating - the version appears ready for publication based on the indicators shown on the page [SCREENSHOT: Version changes view showing added, edited, and removed pages with comment indicators] If the comparison view still shows unresolved issues on key pages, hold your decision until those items are addressed. ## Approving or rejecting the version review decision When your review is complete, use the decision controls on the review page to record the outcome clearly. Atloria treats **Approve** and **Reject** as formal review decisions, so choose the one that matches the current state of the version. 1. On the version review page, click **Approve** if the version meets the review requirements and the required feedback has been resolved. 2. Click **Reject** if the version still needs additional work before it can move forward. 3. If Atloria shows a comment or notes field during the decision step, enter a clear explanation before submitting. 4. Submit the decision and wait for the page to refresh or update the status. When you approve a version, Atloria records your decision in the reviewer record and updates the review status shown on the page. If your approval is the final required one, the version may move to a release-ready state or show that review is complete. If other required approvers are still pending, your approval is saved, but the overall review may remain in progress until those people respond. When you reject a version, explain why in direct, useful language. Focus on the specific issue that prevented approval, such as unresolved comments, missing content, or changes that are not ready for publication. A short but clear rejection reason makes it easier for the writer or project lead to fix the right problem quickly. After submission, check the page again to confirm: - your decision appears in the reviewer section - the status indicator has updated - the history area shows your action - any approval count or required-approver progress has changed [SCREENSHOT: Approval decision dialog with Approve, Reject, and comment field] If the version does not become fully approved right away, that usually means Atloria is still waiting for additional required reviewers or another release condition has not been met. ## Coordinating release decisions after review is complete An approved review does not always mean the version can be released immediately. After the review is complete, use the version page to confirm whether the version is truly ready to move forward. 1. Return to the version details page after the review decision is recorded. 2. Check the final review status and any release readiness indicators shown for the version. 3. Confirm whether all required approvers have completed their decisions. 4. Review any remaining blockers, unresolved feedback, or project-level conditions that still prevent release. 5. Record or confirm the final decision in the version record so other team members can see why the version is moving forward, delayed, or sent back for updates. In Atloria, release coordination often involves more than one role. **Documentation Managers** may confirm content readiness, **Project Administrators** may provide the final sign-off needed for release, and **Technical Writers** may still need to address late feedback. Use the reviewer outcomes and visible status indicators on the version page to keep everyone aligned. If the version has mixed outcomes, do not rush it into release. For example, one reviewer may have approved while another left unresolved concerns. Late comments can also appear after most reviewers have already approved. In those cases, use the version record and comment history to decide whether the version should wait, be updated, or be reviewed again. A good final record should make the decision easy to trace later. Anyone opening the version should be able to understand: - whether it was approved or delayed - who approved it - whether any blockers remained - why it was returned for revision, if applicable [SCREENSHOT: Version details page showing final review status, release readiness, and reviewer outcomes] This keeps the release team from guessing and helps avoid confusion when the version is handed off for publication. ## Fixing common problems with review decisions and approvals If a review decision does not behave the way you expect, start by checking the visible status and reviewer information on the page. Most approval issues come from version state, permissions, or incomplete reviewer progress. - **Approve** or **Reject** is unavailable Open the version review page and check whether the version is still in a reviewable state. If the page already shows a final decision or the review is closed, the decision buttons may be hidden. Also confirm your role. In Atloria, final decisions are typically available to **Documentation Managers** and **Project Administrators**, while **Technical Writers** may only be able to comment or prepare updates. - The version still shows **Pending** after your decision Check the reviewer list to see whether other required approvers are still pending. Your own approval may have been saved correctly, but the overall review stays open until everyone required has responded. Also look in the history area to confirm your decision appears there. - A release cannot proceed after approval Return to the version page and look for unresolved comments, blocked review indicators, or missing sign-off from another required reviewer. A version can be approved by one reviewer and still not be release-ready if Atloria shows outstanding blockers. - A rejected version does not move back to the expected stage Review the updated version status on the version page and check whether the writer has reopened or updated the version since the rejection. If the page still shows the old state, refresh the version details and confirm the rejection was recorded in the history. [SCREENSHOT: Review page with disabled decision buttons and visible status indicators] If the issue is not on the review page itself, compare the version status, reviewer list, and history together. Those three areas usually show exactly why the version is still pending, blocked, or unable to move forward. ## Overview Managing review decisions in Atloria means doing more than clicking **Approve** or **Reject**. You need to confirm that the version is still open for review, check who else is involved, inspect the actual content changes, and make sure the final decision matches the version’s release readiness. This workflow usually starts from the version list and continues into the version details page and the review page. From there, the key areas to watch are: - the **review status** indicator - the **reviewer** section - the **decision history** or activity area - the **changes** or comparison view - the final **Approve** and **Reject** actions A careful review decision helps the whole team. It tells writers whether their updates are ready, shows project leads whether required approvals are complete, and gives the release team a clear record of what happened. That matters most when several people are reviewing the same version or when a version is close to publication. Use this guide when you need to: - confirm whether you can submit a decision - understand why a version is still pending - review changed pages before deciding - record an approval or rejection with useful notes - verify whether the version is ready for release after review If you need help opening the review flow itself or understanding the earlier review steps, go back to [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions). This guide focuses on the decision stage and what to check before and after that decision is recorded. ## Prerequisites Before you manage a version review decision in Atloria, make sure the version and your access are ready for review work. - You can sign in to Atloria and open the project that contains the documentation version you need to review. - You can access the version list and open the selected version’s details page. - The version is already in a review stage or shows a review action that lets you open the review page. - You understand the earlier review flow covered in [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions). - Your role allows the action you need to take: - **Documentation Managers** can finalize review decisions - **Project Administrators** can finalize review decisions - **Technical Writers** may be limited to comments, feedback, or update preparation depending on project permissions - The version includes enough visible review information for a decision, such as status, reviewer assignments, and changed content. - Any pages or comments you need to inspect are available from the version review or comparison view. It also helps to confirm a few practical details before you start: - You know which version name or revision you are reviewing - You know whether the version is tied to a specific release or publication target - You know whether other reviewers are expected to approve before the version can move forward If you are preparing for the next part of the workflow, continue with [Understanding Review Statuses Comments and Next Steps](doc:understanding-review-statuses-comments-and-next-steps). ## 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](doc: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**. [SCREENSHOT: Version details page with the version settings panel highlighted] 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. | Version state | What readers experience | Common use | |---|---|---| | **Public** | The version is available to public readers and is intended to be openly readable | Released documentation | | **Restricted** | Access is limited, so some readers may be blocked while approved reviewers or internal users can still work with it | Stakeholder review or controlled preview | | **Hidden** | The version is not intended for reader discovery and should stay out of public-facing areas | Drafts and in-progress work | 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. [SCREENSHOT: Public documentation page showing the version dropdown and left-side navigation] 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](doc: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. [SCREENSHOT: Side-by-side check of version settings and public documentation view] 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](doc: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](doc: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](doc: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. ## Following a version from draft to release candidate In Atloria, the **Versions** area is where your team tracks each documentation release from early work to publish-ready status. A version usually begins as a new entry in the version list, where its **version name**, **release label**, and **project** help everyone understand what release it belongs to. If your team is working on more than one release at the same time, these details are what separate an in-progress update from a version that is nearly ready to go live. While a version is still being built, teams typically treat it as a **working draft**. On the version list and version detail page, people look for clear signals that show whether the release is still in progress or ready for a decision. Those signals usually include: - whether the version is still in a **draft** or working state - whether it has been moved into a **review-ready** state - whether it is already the **published** version - whether required content appears complete - whether screenshots have been updated for the release - whether access and visibility settings match the intended audience The version detail page is where Documentation Managers and Project Administrators usually confirm these readiness signals before moving forward. They use the page to review the version’s identifying information, check whether the release is meant for internal work or public readers, and verify that the version belongs to the correct project. [SCREENSHOT: Versions list showing multiple versions with status indicators, version names, and project association] If you already worked through version statuses and list behavior in [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons), use that as your reference for reading the list itself. Here, the main point is understanding the lifecycle: a version starts as a draft, moves through review and readiness checks, and becomes a release candidate only after content, screenshots, and visibility settings all support publication. ## Creating and organizing versions for an upcoming release To prepare for an upcoming release, start in the **Versions** screen and use the **new version** action to create a fresh version record. When you create it, Atloria uses the identifying details you enter—especially the **version name** and the related **project**—to place that release in the correct workspace. These details matter most when several releases are active at once, such as a maintenance update and a larger upcoming release. A **fresh version** is usually the right choice when you are documenting a new release cycle and want a separate place to prepare content without disturbing what readers already see. Teams often create a new version when they need to preserve the currently published release while building the next one in parallel. If your team is continuing from an earlier release, you may also work from an existing version so prior published content remains available for reference while the next release is updated. Once the version appears in the list, organize it so the intended release candidate is easy to spot. Teams usually scan the list by: - **release sequence**, to see which version is older or newer - **draft state**, to find versions still being edited - **publish state**, to identify which version is currently live - **project association**, to avoid mixing releases across projects On the version detail page, review any editable settings available right after creation. Depending on what your team uses, this may include the version title, internal notes, and visibility-related settings that affect who can access the release later. It is best to confirm these details early so reviewers are not comparing or approving the wrong version. [SCREENSHOT: New version action from the Versions screen and the version detail page with identifying fields] For broader release planning across multiple versions, refer back to [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle). ## Reviewing changes and comparing versions before approval Before approving a release, teams need to see exactly what changed. In Atloria, that usually means opening the version’s comparison controls and checking the current draft against the previously published version. This comparison view helps reviewers focus on release-impacting differences instead of manually opening every page one by one. When reviewers compare versions, they usually look for a few specific signals: - **added pages** that must be included in the release - **updated pages** where product behavior or instructions changed - **updated screenshots** that reflect the current interface - **changed access restrictions** that may affect who can read the content - **missing release-critical content** that should appear in the new version but does not The most effective review flow usually moves between three places: the **version detail page**, the **page list**, and the **comparison view**. Reviewers start on the version detail page to confirm they are checking the correct release. From there, they open the page list to inspect individual pages that were updated, then return to the comparison results to make sure no important differences were overlooked. This comparison step is especially useful when the release candidate looks complete at first glance but may still contain hidden gaps. A page may have been updated without its screenshot being refreshed, or a section may have been removed by mistake. By surfacing these differences clearly, comparison gives Documentation Managers and Project Administrators stronger confidence that the release matches the actual product state. [SCREENSHOT: Version comparison view showing differences between the current draft and the previously published version] If you need a deeper walkthrough of reading comparison results, the next document, [Working with Version Comparison Views](doc:working-with-version-comparison-views), focuses on that screen in more detail. ## Checking access control and screenshots for release readiness A version is not truly release-ready until the right people can see it and the visuals match the product. In Atloria, that means checking both **version access settings** and the screenshots used on pages before you publish. Start with the version’s visibility and access settings on the version detail page. Reviewers use these settings to confirm whether the version is meant for all readers, a limited audience, or a restricted group. If the version is intended for a specific audience, make sure the selected visibility matches that plan before release. A version with complete content can still fail a release check if the wrong audience will see it—or if the intended audience will not see it at all. Then review screenshots connected to the pages in that version. This matters most after interface changes, renamed buttons, updated navigation, or redesigned screens. Teams often open the affected pages and confirm that each image still matches the current product experience. Outdated screenshots can create confusion even when the written instructions are correct. Common release blockers in this stage include: - screenshots that still show the previous interface - pages that were updated but their images were not - visibility settings that expose the version too broadly - restricted settings that prevent the intended readers from opening the release Documentation Managers usually confirm page-level readiness by checking the version’s content and screenshots together, while Project Administrators often verify that access settings align with the release plan. Both checks happen before any publish decision is made. [SCREENSHOT: Version detail page showing visibility settings and linked page content with screenshots] For more on visibility decisions, see [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access). For screenshot workflows, use [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release). ## Deciding when to publish or hold a version The publish decision happens on the version detail page, after the team has finished its readiness checks. Before selecting the publish action, reviewers usually confirm that the version content is complete, comparison results have been reviewed, screenshots are current, and visibility settings are correct for the intended audience. In practice, teams usually work with three release states: - **Draft**: the version is still being edited and should not be treated as final - **Ready for review**: the version is stable enough for formal checking and release discussion - **Published**: the version becomes the active release readers will use Keeping a version in **Draft** is the right choice when pages are still changing, screenshots are incomplete, or comparison results still show unresolved gaps. Moving it into a review-ready state signals that the release candidate is ready for decision-making, even if final approval has not happened yet. Publishing should happen only when both documentation quality and access settings are confirmed. When a newer version is published, the previously published version does not lose its value. Teams often keep earlier releases available as historical records for comparison, reference, or rollback planning. That preserved release history is especially helpful when readers still need access to older documentation or when the team must verify what changed between releases. The final decision is usually coordinated between Documentation Managers and Project Administrators. Documentation Managers confirm that the pages, screenshots, and release notes are accurate. Project Administrators confirm timing, visibility, and whether the release should become the active version for readers. [SCREENSHOT: Version detail page with publish action and status indicators for draft, review-ready, and published states] If your team also uses formal review decisions, pair this process with [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). ## Resolving common release-readiness problems When a version will not move forward, the fastest way to solve it is to check the same readiness signals your team uses before publishing. In Atloria, most release problems fall into a few repeatable patterns. If a version cannot be published because review items are incomplete, open the version detail page and then check the comparison results. Look for missing pages, unfinished updates, or content that changed in draft but was not fully prepared for release. After that, review screenshots on the affected pages and confirm there are no visual gaps. A release may appear complete in the version list but still be blocked by unfinished page updates or outdated images. If readers cannot access the new version after release, start with the version’s **visibility** and access settings. Confirm that the correct audience or restricted access option is selected and that the intended release was actually marked as the active published version. This is especially important when several versions have similar names. If the release candidate looks inconsistent compared with the previous version, open the comparison view again and review the differences carefully. Teams often discover: - pages that were expected but never added - screenshots that still belong to an older release - changed access settings that hide important content - accidental regressions where useful content was removed When the team is unsure which version should ship, return to the version list and compare the **version name**, **release label**, **publish state**, and any review indicators shown there. These details usually reveal which version is the intended release candidate and which one is still a work-in-progress draft. [SCREENSHOT: Versions list with multiple similar releases, showing status and publish indicators] If the issue is mainly about deciding between two releases, use [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions) alongside your version review workflow. ## Overview In Atloria, **release readiness** is the point where a documentation version has moved beyond editing and can be trusted as the reader-facing release. The work does not happen in one screen only. Teams usually move between the **Versions** list, the **version detail page**, the **comparison view**, and the related page content to confirm that the release is complete. A typical release-readiness review brings together several checks: - the version is clearly identified by **version name**, **release label**, and **project** - the version is no longer just a working draft - content changes have been reviewed against the previous published version - screenshots reflect the current product experience - visibility and access settings match the intended audience - the correct version is ready to become the active published release This document focuses on how those checks fit together as one lifecycle. It does not repeat the detailed list-management guidance from [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). Instead, it helps you understand how teams decide whether a version is still in progress, ready for review, or ready to publish. That distinction matters most when multiple releases are active at once. Without clear version metadata and status signals, teams can easily review the wrong release or publish a version that still has incomplete screenshots or incorrect visibility settings. Using the version list and detail page together helps avoid that confusion and gives everyone a shared view of release progress. [SCREENSHOT: Atloria Versions area showing list view on the left and a selected version detail page] ## Prerequisites Before working through release readiness in Atloria, make sure you can already open the correct **project** and access its **Versions** area. You should also be comfortable reading the version list and recognizing the basic status and comparison indicators shown there. If you need a refresher on that screen, use [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). You will get the most value from this workflow if the following are already in place: - you have access to the project where the version is being prepared - at least one documentation version already exists in the **Versions** list - there is a current draft or release candidate to review - your team has updated the relevant pages for the release - any screenshots tied to changed pages are available for checking - you can open the version detail page and any available comparison controls It also helps if your team has already agreed on who is making the release decision. In many teams, Documentation Managers review page completeness and screenshots, while Project Administrators confirm timing and visibility. Even if one person handles both tasks, it is important to know who is responsible for the final publish decision. If your team is still setting up version workspaces or preparing the release structure itself, read [Managing Project Version Workspaces](doc:managing-project-version-workspaces) before continuing. If you are ready to focus on the actual difference-checking process between versions, continue next with [Working with Version Comparison Views](doc:working-with-version-comparison-views). ## Matching your goal to the right export option In Atloria, the **Export** or **Share** action is most useful when you start with a clear outcome in mind. The three export choices covered here are **shareable link**, **PDF export**, and **archive package**. Each one fits a different kind of work. Use a **shareable link** when the main goal is easy viewing in a browser. This is usually the best choice for external readers, quick stakeholder review, or anyone who needs to open documentation without handling attachments. A link is especially helpful when you want recipients to move through navigation, open related pages, and review content in a more natural reading experience. Choose a **PDF export** when you need a fixed file that looks the same for everyone. This works well for approval discussions, sign-off records, and point-in-time release documentation. Because the content is downloaded as a file, reviewers can save it, forward it, or attach it to release records without depending on a live browser view. Pick an **archive package** when you need a broader preservation copy rather than a quick reading format. This option is better for long-term retention, release snapshots, or cases where you want to keep a larger documentation set together as a record. A simple way to decide is: | Your goal | Best export choice | Why | |---|---|---| | External sharing | Shareable link | Easy browser access | | Internal review | Shareable link or PDF export | Link for live review, PDF for fixed review | | Release record retention | PDF export | Stable point-in-time file | | Long-term archive | Archive package | Preserves a larger snapshot | If you already know how to start exports in Atloria, use [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records) for the workflow details. This guide focuses on choosing the right output before you send or store it. ## Sharing documentation with people outside your workspace When you need to send documentation to people who are not working inside your Atloria workspace, start from the page, document set, or published version you want to share, then use **Share** or **Export** to choose an external-facing result. For most cases, a **shareable link** is the easiest option because the recipient can open it in a browser instead of downloading and managing a file. A shareable link is usually better than an attachment when: - You want fast review with minimal back-and-forth - The recipient needs to browse multiple pages - You want the content to feel like a finished documentation experience - You expect feedback based on what appears in the browser Before sending anything, confirm the scope of what you are sharing. In Atloria, that may be: - The **current page** - A **selected document set** - The **current published version** That choice matters. A single page is useful for focused review. A selected set works better when several related pages need to be read together. A full published version is the better choice when external readers need the same structure and navigation as a complete release. Check the result before you send it: - Open the exported link yourself - Confirm the page title and navigation look correct - Review visible branding - Make sure images and tables load properly - Verify any version label or release information shown on the page [SCREENSHOT: Share or Export menu showing link-based sharing choices] Be careful not to copy a workspace page directly from your browser if your goal is external sharing. Use Atloria’s **Share** or **Export** action so the recipient gets the intended public-facing result rather than a link that expects workspace access. ## Preserving release records for audits or long-term storage When your goal is retention rather than review, choose an export that captures a stable record of the release. In Atloria, that usually means a **PDF export** for a fixed document record or an **archive package** for a broader release snapshot. A **PDF export** is the better choice when you need a point-in-time copy of approved documentation. Because it is a fixed file, it is useful for approval packets, release records, and audit support. If someone opens the same PDF later, they are reviewing the same captured content rather than a page that may have changed since publication. An **archive package** is more suitable when the release record includes more than one page or when you want to preserve a larger documentation set together. This is the stronger option for long-term storage because it is designed around keeping a broader snapshot instead of a single reading copy. What makes an export suitable for archiving: - It reflects the approved release content - It is not dependent on later edits in the live workspace - It preserves stable formatting or a stable package of files - It can be stored alongside release and approval records Project Administrators often organize archived exports using naming and storage patterns that match release tracking. Common approaches include: - Grouping by **release number** - Grouping by **publication date** - Grouping by **approval milestone** For example, if your team approves documentation at a release checkpoint, export the approved version immediately after sign-off and store it with the same release label used in your version and approval process. If the release includes a full documentation set, use an archive package instead of exporting only one page as a PDF. [SCREENSHOT: Export options for a documentation version, highlighting PDF and archive choices] If your team also exports audit-related records, see [Exporting Audit and Version Records](doc:exporting-audit-and-version-records) for the related recordkeeping workflow. ## Preparing exports for internal review and sign-off For internal review, start from the document page, release notes set, or published version that needs feedback. In Atloria, use the **Export** option from the page toolbar or collection toolbar, then choose the format that matches how your reviewers prefer to work. 1. Open the content that needs review. This might be a single documentation page, a section group, or the current published set for a version. 2. Click **Export** or **Share** in the toolbar. 3. Choose the output that fits the review style: - **Shareable link** for browser-based review and quick collaboration - **PDF export** for fixed review, annotation, or sign-off records 4. Set the export scope carefully: - **Current page** for focused review - **Section group** when several related pages should be reviewed together - **Published set** when reviewers need the full release context 5. Generate the export. 6. Open the result before sending it to reviewers. During that final check, look closely at the parts reviewers are most likely to comment on: - Headings and page order - Tables and formatting - Images and screenshots - Version labels - Release notes details - Navigation, if you are using a shareable link [SCREENSHOT: Export menu from a document or release notes view] The best choice depends on whether review content should stay live. If your team is still making edits and wants reviewers to see the latest published content, a shareable link is usually the better fit. If the review must stay fixed for approval, use a PDF export instead. For the broader version review process before export, refer to [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) and [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options). ## Comparing export formats before you decide Before you click **Export**, it helps to compare formats side by side. In Atloria, the right choice usually comes down to whether you need easy access, a fixed record, or a larger preserved snapshot. | Export format | Best for | Main strengths | Main tradeoffs | |---|---|---|---| | Shareable link | External review, quick browser access, collaborative reading | Easy to distribute, opens in a browser, supports navigation through published content, useful for current published material | Content may change after the link is sent if the published content is updated | | PDF export | Sign-off, approval records, offline review, attachments | Fixed layout, easy to save and attach, useful for point-in-time review, works offline | Becomes outdated after edits or later publication changes | | Archive package | Retention, compliance, larger release snapshots | Preserves a broader documentation set, better for long-term storage, useful for release preservation | Less convenient for quick reading or casual review | A **shareable link** is strongest when convenience matters most. It reduces friction because recipients can open the content immediately and review it in a browser. It is a good fit for external stakeholders and fast-moving review cycles. A **PDF export** is strongest when consistency matters most. Everyone sees the same file, which makes it easier to use in approval discussions and recordkeeping. An **archive package** is strongest when completeness matters most. If your team needs to preserve a release snapshot rather than simply read it, this is the better option. When you are unsure, ask one question first: “Do recipients need the latest browsable content, a fixed file, or a preserved release snapshot?” That answer usually points directly to the right export format. ## Avoiding common export mistakes Most export problems in Atloria come from choosing the wrong link, the wrong scope, or the wrong version. A quick check before sending or storing the export can prevent rework later. One common issue is that recipients cannot open what you sent. This often happens when a browser address from inside the workspace is copied instead of using Atloria’s **Share** or **Export** action. If the recipient is outside your workspace, send a proper **shareable link** rather than a workspace-only page link. Another frequent problem is missing content in the exported file. If pages, sections, or release notes are missing, go back to the export menu and review the selected scope. Make sure you chose the correct level: - **Current page** - **Section group** - **Published set** If the archive does not match the approved release, confirm that you exported the correct published version or release snapshot. This matters most when several versions are close together or when approvals were completed recently. Always open the version you intend to preserve before generating the export. Reviewers may also comment on outdated content when a fixed file was sent too early. If edits are still happening and reviewers should see updates, use a **shareable link** instead of a PDF. If the content must stay frozen for sign-off, use the PDF and make it clear that review should happen against that file. A practical pre-send check includes: - Open the export yourself - Confirm the version label - Verify the page or set included - Check images, tables, and headings - Make sure the format matches the purpose If export decisions are tied to version access, [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export) is a helpful companion guide. ## Overview This guide helps you choose between Atloria’s main export outcomes based on the job you need to complete. The focus is not on how to start an export step by step, but on how to decide whether a **shareable link**, **PDF export**, or **archive package** is the best fit for sharing, review, or retention. Use this guide when you need to answer questions like: - Should I send a link or a file? - Do reviewers need a live browser view or a fixed copy? - What should I keep for release records? - Which export is safest for long-term storage? The guidance is organized around common documentation tasks: - Sharing documentation with people outside your workspace - Preserving approved release records - Preparing exports for internal review and sign-off - Comparing export formats before sending or storing them - Avoiding mistakes that lead to broken access or incomplete records This document assumes you already know the basic export workflow in Atloria. If you need help finding the **Export** or **Share** action and generating the output itself, read [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records) first. Because export choices affect review quality and recordkeeping, it is worth matching the format to the purpose every time. A browser-based link is excellent for easy access, a PDF is better for fixed review and approval records, and an archive package is better for preserving a broader release snapshot. The next guide in this Export Center sequence is [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions), which walks through the checks to make before you generate and distribute an export. ## Prerequisites Before using the guidance in this document, make sure the content you plan to export is already available in Atloria and that you can open the page, document set, or version you want to share. You should have: - Access to the relevant project workspace in Atloria - A documentation page, release notes set, or published version ready to export - Permission to use the **Share** or **Export** action where that content appears - A clear purpose for the export, such as external sharing, internal review, or archive retention It also helps if you already know: - Which version or release should be used - Whether recipients need browser access or a downloaded file - Whether you are sending one page, a selected set, or a full published version - Whether the export is for review, approval, or long-term storage If you are still preparing the content itself, these related guides may be more useful first: - [Exporting Documentation and Related Records](doc:exporting-documentation-and-related-records) - [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records) - [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options) For release-based exports, make sure you can identify the correct approved version before generating a PDF or archive package. For external sharing, confirm that the content is ready to be seen outside your workspace and that the exported result should reflect the current page, a selected document set, or the current published version. ## Understanding how screenshot folders map to active docs and releases In Atloria, screenshot organization works best when you treat **current draft content** and **published release content** as two separate working areas. Your active document screenshots belong to the page you are still editing in the project workspace. These images change as the draft changes. Release screenshots belong to a specific published documentation version and should stay fixed, even after the draft page is updated later. A simple structure keeps this clear: - One folder for the document itself, using the document slug or page name - Inside that, an **active** area for current work - Separate folders for release versions such as **v1.0**, **v2.3**, or another release label your team uses For example, a page about settings might have one document folder, then an **active** set for the current draft and release folders for each published version. This prevents a new screenshot from replacing an older image that still belongs to a live version of the docs. File names should describe the exact screen or step shown. Good examples include: - `settings-overview.png` - `create-user-dialog.png` - `api-token-step-3.png` These names make it easier to match an image to a heading, a task, or a step in the document editor. If a page has several screenshots, consistent naming also helps reviewers spot missing images quickly. Use the **active document folder** when you are still writing, revising, or reviewing a page. Once that page is being finalized for a release, copy the approved screenshots into the **release-specific folder** that matches the version being published. If the published page must continue to show the older interface, leave those release screenshots in place and update only the active set. [SCREENSHOT: Example screenshot library showing one document folder with an active folder and separate release folders such as v1.0 and v2.3] ## Setting up a screenshot library for a new document When you start a new page in Atloria, create a screenshot folder that matches that document alone. Use the page slug or the document title so screenshots for one guide never get mixed into another. If you already organize documentation by project, keep the screenshot folder inside the same project area so writers and reviewers can find it without searching across unrelated content. For a straightforward page, one folder may be enough at first. If the page covers several parts of the product, add subfolders based on the workflows readers will see. Common groups include: - `onboarding` - `settings` - `reports` - `admin-console` This is especially useful for longer guides where one page includes multiple tasks, such as opening a menu, completing a form, and reviewing a confirmation screen. Grouping by workflow keeps the library readable and reduces the chance of inserting the wrong image into the wrong section. Save your first captures with names that describe the exact interface state, not just the screen name. For example: | Screenshot name | What it helps identify | |---|---| | `draft-editor-toolbar.png` | The editor toolbar while the page is still being edited | | `publish-confirmation-modal.png` | The confirmation window shown before publishing | | `version-status-badge.png` | A page or version status label used in the workflow | These names are much more useful than generic file names such as `image1.png` or `screenshot-final.png`. It also helps to note which product version produced the images. If your team tracks release numbers in the document workspace, keep that release label with the screenshot set so reviewers can confirm the images match the correct UI. This becomes important when a page moves from draft work into version review. If you need a broader setup pattern for shared assets across teams, use this guide together with [Managing Enterprise Screenshot Libraries](doc:managing-enterprise-screenshot-libraries). [SCREENSHOT: New screenshot folder for a document with subfolders for onboarding, settings, and admin-console] ## Reviewing image coverage against the page content Before a page is approved, compare the document content with the screenshots you have saved. In Atloria, the easiest way to do this is to review the page heading by heading and check whether each important task or screen state has a matching image. You do not need a screenshot for every sentence, but the main UI moments in the guide should be visible somewhere in the page. Look closely at sections that describe actions in the interface. If the text tells the reader to open a menu, complete a form, confirm a dialog, or check a status badge, there should usually be a screenshot that supports that step. Useful image targets often include: - Navigation menus - Dialog boxes - Form fields - Status badges - Confirmation messages - Empty states - Warning banners - Completed workflow screens A heading-by-heading review helps you spot gaps quickly. For example, a guide may explain how to publish a documentation version and mention a confirmation message, but the screenshot set may only show the page before publishing. That is a coverage gap. Another common gap is when the document mentions an empty-state view or a warning banner, but no image shows that state. You should also check for outdated images. A screenshot is outdated if the visible labels no longer match the current draft. Common signs include: - Button text has changed - A menu item has moved - Panel layout looks different - A badge or status label uses a new name - The page path described in the text no longer matches the image Mark these files clearly in your review notes or move them out of the working set so they are not inserted by mistake. This review is especially important before version approval, because once a screenshot is tied to a release, it should match the published wording and workflow exactly. [SCREENSHOT: Document editor beside a screenshot folder list, showing a reviewer checking headings against image files] ## Keeping release screenshots aligned with published versions The key handoff point in Atloria is when a draft page stops being edited for the current release and moves into final version review. At that stage, the screenshots used in the page should be treated as frozen for that release. Copy those approved images into the folder for the exact release label, such as **v1.0** or **v2.3**, so the published version always points to the correct visual set. This matters because active documentation keeps changing. A writer may update button labels, replace steps, or capture a redesigned screen for the next release. If those newer files overwrite the images used by a published version, readers of the older release may see screenshots that no longer match the text on the page. Release-specific folders solve that problem. Each published version keeps its own screenshot set, even if several versions of the same document remain available to readers. That means: - The active folder can continue to change - Older published versions keep their original images - Reviewers can compare one release at a time without confusion - Teams avoid breaking live documentation when preparing the next update Before finalizing a version, run one last check across three items: 1. The published page text 2. The release number 3. The screenshot set stored for that release All three should match. If the page says a reader should click **Publish**, the screenshot should show **Publish**, not an older label. If the version being released is **v2.3**, the page should not still be drawing images from the active draft set or from **v2.2**. This release check is especially important for pages that stay live across several versions. Keeping each release folder intact gives your team a reliable visual history of what readers actually saw at publication time. [SCREENSHOT: Release review view showing a document version label and its matching release screenshot folder] ## Managing updates when the interface changes When Atloria’s interface changes, review the screenshot set before you update the document text. Even small changes can make an image misleading. Common examples include renamed buttons, moved navigation items, redesigned forms, or updated confirmation windows. If readers see one label in the screenshot and another in the instructions, confidence drops immediately. Start by identifying exactly what changed on the page. Then compare those changes against the screenshots already used in the guide. If only one part of the workflow changed, replace only the affected files. For example, if the save confirmation window has a new layout but the rest of the page still looks the same, keep the unchanged screenshots and update only the image for that confirmation step. This saves time and preserves the parts of the guide that are still accurate. When the workflow itself changes, a partial update is usually not enough. If the published version shows a process that no longer matches the current product behavior, create a new screenshot set for the next release rather than editing the older release files. That keeps the published release accurate while allowing the active draft to move forward. As you update, clean out duplicate and obsolete files. These are often the source of mistakes during editing. Watch for: - Older copies with nearly identical names - Generic file names that do not show which step they belong to - Draft captures that were replaced but never removed - Images saved in the wrong document or release folder A tidy library makes it much easier for writers to choose the right image in the document editor. If your team supports multiple versions at once, keeping old release folders untouched and updating only the active set is the safest pattern. [SCREENSHOT: Screenshot folder showing updated files for one workflow step while older release folders remain unchanged] ## Fixing common screenshot organization problems A few screenshot problems show up again and again in Atloria, and most of them come from unclear folder structure or vague file names. The fastest way to fix them is to trace the image back to the document page, the release it belongs to, and the exact UI state it is supposed to show. If a **published page shows the wrong UI version**, first check whether the page is using images from the active document folder instead of the release-specific folder. This usually happens after a draft is updated for a newer release. Move the published page back to the correct release image set, then confirm the release label and screenshot folder match. If **writers cannot tell which screenshot matches a section**, rename the files so the screen state is obvious. A file named `step2-final-new.png` does not help anyone. A name like `publish-confirmation-modal.png` or `settings-navigation-menu.png` makes the correct placement much clearer. If **multiple teams overwrite each other’s images**, separate the files by both document slug and release label before anyone updates them. Shared screenshot areas become risky when different pages or versions use the same generic file names. A clear document folder, plus release folders inside it, usually solves this. If **image coverage is inconsistent across a guide**, run a heading-by-heading review. Compare each section in the page with the available screenshots and look for missing images in key moments such as: - Opening a menu - Completing a form - Seeing a warning - Reaching a success message - Viewing an empty or first-use screen This kind of review is often enough to reveal whether the problem is missing captures, outdated files, or screenshots saved in the wrong place. If screenshots still seem unavailable or mismatched across versions, continue with [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). ## Overview This guide focuses on how to keep screenshot files organized so they stay accurate in both active documentation and published releases in Atloria. The main idea is simple: do not treat all screenshots as one shared pile. Instead, organize them by document, then separate current draft images from release-specific images. The most reliable structure uses: - A folder for each document - An **active** area for in-progress work - A separate folder for each published release label Within those folders, use descriptive file names that match the exact screen state shown in the page. Names such as `create-user-dialog.png` or `api-token-step-3.png` are much easier to review than generic names. For longer guides, subfolders based on workflows or page areas can make the library easier to scan. This guide also explains how to review screenshot coverage against the page itself. That means checking whether the document’s headings, steps, menus, forms, and confirmation states are actually illustrated. It also covers how to spot outdated images when labels, layouts, or menu paths change. Most importantly, it shows how to preserve screenshots for published versions without blocking updates to the active draft. That separation is what lets teams support multiple documentation versions at the same time. If you have already worked through [Managing Enterprise Screenshot Libraries](doc:managing-enterprise-screenshot-libraries), this guide takes the next step by showing how to organize screenshot sets at the document and release level. ## Prerequisites Before you organize screenshots for a document or release in Atloria, make sure you already have the basic pieces in place. You do not need a complex setup, but you do need enough structure to keep images tied to the right page and version. You should have: - Access to the project workspace where the documentation page is being edited - A document or page that already has a clear title or slug - A screenshot set that belongs to that document, even if it is still incomplete - A release label or version name if the page is being prepared for publication - A way to review the current draft page beside its screenshot files It also helps if you already know whether the page is still in active editing or is close to release review. That decision affects where the screenshots should live. Draft images should stay in the active area until the page is ready to freeze for a version. Once the page is being finalized, move or copy the approved images into the release-specific folder. If your team shares screenshots across many projects or departments, review [Managing Enterprise Screenshot Libraries](doc:managing-enterprise-screenshot-libraries) first so your document-level organization fits the larger library structure. If you are still capturing images rather than organizing them, [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) is the better starting point. After your document folders, release labels, and file naming approach are in place, you can move on to cross-project coordination in [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). ## Confirming the version is ready for release review In Atloria, start from your project workspace and open the **Versions** area, then select the version you plan to send for final release review. Before you do anything else, make sure you are looking at the correct release candidate. Check the version name, any visible status label, and the surrounding version details so you do not prepare the wrong version by mistake. If your team works with several active versions at once, this quick check prevents comments and approvals from being attached to the wrong release. Once you are on the version record, review the overall readiness details shown on that screen. Look for checklist-style fields or status indicators tied to **content completeness**, **screenshot coverage**, **comparison status**, and **visibility**. These are the main signals reviewers will rely on when deciding whether the version is ready for signoff. If one of these areas still shows as incomplete, open that section from the version and finish it before requesting approval. You should also confirm that the content included in this version is no longer sitting in an unfinished state. A version that still contains pages marked as draft, in progress, blocked, or waiting for review is usually not ready for final release review. If you recently worked through comments and status updates, use [Understanding Review Statuses Comments and Next Steps](doc:understanding-review-statuses-comments-and-next-steps) as your reference instead of repeating that review here. Finally, make sure the actions you need are available on the version screen. If you do not see the button or menu option used to move the version forward, you may not have permission to submit it for final signoff. In that case, stop before making other changes and confirm who on your team is responsible for the final submission. [SCREENSHOT: Version details screen showing version name, current status, readiness fields, and final review action] ## Checking that all required content is complete From the version record, open the content list linked to that version and scan every page included in the release. This is where you confirm that the version contains the full set of documentation promised for the release, not just the pages that were recently edited. Pay close attention to status labels next to each item. If any page still appears as **Draft**, **In Progress**, **Blocked**, **Rejected**, or otherwise unfinished, it needs attention before the version can move into final review. Use the list to spot gaps that are easy to miss during day-to-day editing. Missing pages often show up as expected topics that are not present at all, while incomplete work usually appears as pages without a completed review state or without a clear owner. If Atloria shows ownership or assignment details in the version content list, verify that every required page has someone responsible for it. Unowned pages are a common reason release review stalls. As you review the included pages, confirm that the version contains the document types your team expects for that release. Depending on your project, that may include updated feature pages, setup instructions, release notes, or supporting guidance for changed workflows. The key point is consistency: if the release introduces something new or changes an existing workflow, the matching documentation should already be present in the version. When you find a gap, fix it from the version view instead of pushing the version ahead and hoping reviewers will catch it later. Open the affected page, complete the missing work, and return to the version list to verify the status has updated. If you need a broader refresher on how versions are organized across the release cycle, see [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle). [SCREENSHOT: Version content list with page titles, status labels, and ownership details] ## Reviewing screenshots and visual updates If your version includes pages that rely on interface images, open the screenshot review area connected to the version and look for any pages marked as needing new or refreshed visuals. This is especially important when the release changes navigation, button labels, page layouts, or visible controls. A page can be textually correct and still be misleading if the screenshot shows an older screen. Review each flagged page with the current Atloria content side by side. Check whether the screenshot still matches what readers will actually see. Focus on practical details such as updated menu names, changed section titles, renamed buttons, and any visible panels or tabs that have moved. If a guide tells readers to click a specific control, the image should show that same control clearly. When the wording or layout no longer matches, replace the image before marking the page as ready. Also confirm that every page expected to include a screenshot actually has one attached or linked in the version. Missing visuals are easy to overlook when the text is complete, so use the screenshot-required markers in the version review area as your source of truth. If a page is flagged for a screenshot and no image is present, treat that as an incomplete item. Only mark screenshot review as complete when outdated images have been replaced and all required visuals are present. Do not use the completion marker as a reminder to come back later; approvers will assume that a completed screenshot check means the visual review is finished. If your team manages screenshots across multiple releases, [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release) can help you verify that nothing is missing. [SCREENSHOT: Screenshot review area showing pages that need updated visuals and completion status] ## Validating comparisons and change tracking Before sending a version for final release review, open the comparison view for the current version and compare it with the previous released version. This step helps you confirm that Atloria is showing the release changes clearly and that the documentation matches what actually changed. Reviewers often rely on this view to understand the scope of the release without opening every page one by one. As you move through the comparison, check how each topic is labeled. Changed pages should be easy to recognize as **new**, **updated**, **unchanged**, or **removed**. Make sure those labels match your expectations. For example, a newly added feature page should not appear unchanged, and a page that was intentionally retired should not still look active in the release package. If the comparison view highlights something unexpected, open the related page and confirm whether the content or version assignment needs correction. This is also the point where you verify that major product changes have matching documentation updates. If the release includes a visible workflow change, new setup option, or updated navigation path, the comparison should show corresponding page updates. When an expected change is missing, it usually means one of two things: the documentation was not updated, or the page was updated outside the target version and is not included correctly. After you finish the review, update the comparison-related fields or completion markers on the version record so approvers can see that the release delta has already been checked. That visible confirmation saves time during signoff and reduces back-and-forth questions about what changed. For a deeper walkthrough of comparison work, refer to [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). [SCREENSHOT: Version comparison view showing new, updated, unchanged, and removed topics] ## Deciding what will be visible at release Final release review is not only about what is written; it is also about what readers will actually be able to see when the version goes live. On the version record, review the visibility settings for each included page and confirm whether it should be **published**, **hidden**, or **deferred** from the release. This is where you make sure the release scope matches the real product scope. Start by checking for pages that should not be part of the public or reader-facing release yet. Draft-only material, internal notes, and content tied to unfinished features should be excluded before final signoff. If a page describes a feature that is still delayed, keep that page hidden rather than letting it slip into the release package by accident. The same applies to content that is still under internal review even if the rest of the version is ready. Then look at the version as a whole. The version-level visibility decision should match the intended audience and release plan. If the release is meant for a specific audience, confirm that the included pages and their visibility choices support that scope. A mismatch between page-level settings and version-level release intent can create confusion during publishing and review. This is also a good moment to double-check that no internal-only content remains visible simply because it was copied forward from an earlier version. Reviewers expect the final release candidate to reflect deliberate choices, not leftovers from previous work. If you need more detail on access and visibility controls, see [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export). [SCREENSHOT: Version visibility settings showing page-level publish, hide, and defer options] ## Submitting the version for final signoff and fixing common blockers When all readiness areas are complete, return to the version record and use the available version action to request **final review** or **signoff**. Before clicking it, do one last pass over the visible checklist items on the page. If **content completeness**, **screenshot review**, **comparison review**, or **visibility** still shows as incomplete, Atloria may block submission or send the version forward with obvious gaps that approvers will reject. If the submission action is unavailable or fails, check the version record for the most common blockers: - **Incomplete content** in the version content list - **Missing or outdated screenshots** on pages marked as requiring visuals - **Unfinished comparison review** between the current and previous release - **Unset visibility decisions** for pages or the version itself Fix these issues directly from the linked areas on the version screen, then return and try the submission again. Keeping all corrections tied to the version record makes it easier for the team to follow what changed before resubmission. If approvers send the version back, open the version comments and review notes attached to the record. Focus on the flagged pages or unresolved release concerns, make the requested updates, and then resubmit the same version once the issues are cleared. You do not need to restart the entire review process if the feedback is limited to a few pages, but you should make sure the status and checklist fields reflect the updated state before sending it forward again. After submission, confirm that the version status changes to the expected **final review** or **approval** state. That status change is the clearest sign that the version is now in the signoff queue and visible to the rest of the team. The next step is [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions). [SCREENSHOT: Version record showing final review action, checklist completion, comments, and updated review status] ## Overview Preparing a version for final release review in Atloria means checking the version record from a release perspective rather than an editing perspective. At this stage, you are no longer asking whether a single page looks good on its own. You are confirming that the full version is complete, visually current, properly compared against the last release, and set up with the right visibility before approvers are asked to sign off. The core areas to review are: - **Version identity** — confirm you opened the correct release candidate - **Content completeness** — make sure all required pages are present and finished - **Screenshot coverage** — replace outdated visuals and confirm required images exist - **Comparison status** — verify what changed since the previous release - **Visibility decisions** — ensure only the right pages will be visible at release - **Submission readiness** — confirm the version can move into final review without blockers This preparation work is important because approvers usually expect a version in final review to be nearly release-ready. If obvious issues remain, the review cycle slows down and comments become harder to track. A clean version record with completed review fields gives everyone the same picture of release readiness. You do not need to repeat the earlier review-status work covered in [Understanding Review Statuses Comments and Next Steps](doc:understanding-review-statuses-comments-and-next-steps). Instead, use this stage to pull those earlier checks together into one final release candidate review. Think of the version record as your control center: if the content list, screenshot review, comparison view, visibility settings, and status actions all line up, the version is ready to move forward. ## Prerequisites Before you prepare a version for final release review in Atloria, make sure the basic release work is already in place. This task assumes you are working with an existing version inside a project workspace and that the version already contains the pages intended for the release. If the version is still being assembled or generated, finish that work first. You should already have: - Access to the correct **project workspace** - A target entry in the **Versions** area - A version that is far enough along to be treated as a release candidate - Content pages added to the version and reviewed by the people responsible for them - Updated screenshots available for any pages that require visuals - A previous released version available for comparison, if your team uses release-to-release comparisons - Permission to change the version status or submit it for review It also helps if you are already comfortable moving between the version record and related areas such as page lists, screenshot review, and comparison screens. If you need help finding your way around project and version navigation, use [Managing Project Version Workspaces](doc:managing-project-version-workspaces) and [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) before continuing. If your team uses formal approvals, make sure you know who the final approvers are and what level of completion they expect before a version enters signoff. Atloria can show the version status and review actions clearly, but it is still your job to ensure the release candidate is complete enough that those actions make sense. A version that still has open gaps, hidden uncertainty, or missing release decisions is not ready for final review. ## Recognizing What an Entity Detail Page Is Showing In Atloria, an **entity detail page** is the page for one specific documented item. Instead of showing a long list of items, it focuses on a single entry and brings its key details together in one place. At the top of the page, you typically see the **page title** with the entity name, followed by a short summary or definition. Around that main content, readers often rely on the **breadcrumb trail**, the **left navigation tree**, and the **in-page table of contents** to understand where they are and what else is nearby. An entity detail page is different from an index or listing page. A listing page helps you browse many entries at once, while a detail page helps you understand one entry deeply. If you arrive from a search result or from the sidebar, the page header usually confirms that you are looking at the right item right away. Common things readers may find on these pages include: - **API resources** - **Configuration objects** - **Commands** - **Fields** - **Glossary terms** - **Classes or similar documented code items** The page title usually signals what is being described, especially when it appears with visible labels such as: - **Type** - **Defined in** - **Related entities** - **Last updated** These labels help readers decide quickly whether the page answers their question. For example, if you need a field definition, the **Type** label can confirm that the page is about a field rather than a command or resource. If you want to know where the item belongs, **Defined in** or a similar label gives that context without making you read the whole page first. [SCREENSHOT: Entity detail page showing the page title, breadcrumb trail, left navigation, summary block, and metadata labels] If you already know how Atloria presents reference pages in different views, this page builds on [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views) and focuses specifically on what to look for once you open an individual entity page. ## Reading Definitions, Metadata, and Page Structure The fastest way to read an entity detail page in Atloria is to start at the top definition block. This area usually gives you the most important context before you scroll. Look first for the **summary sentence**, which should explain what the item is and why it matters. Near that summary, you may also see an **entity kind** label such as **Type** or **Kind**, along with a source-related field like **Defined in** or **Module**. Together, these visible labels help you confirm whether you are reading about the right item and where it belongs in the broader documentation set. Below that opening block, Atloria may show structured metadata that answers practical questions quickly. Useful labels can include: - **Required** - **Default value** - **Format** - **Deprecated** - **Version introduced** These details matter because they change how you interpret the page. A **Required** label tells you the item must be provided. A **Default value** tells you what happens if nothing is entered. **Deprecated** warns that the item may still exist but should not be used for new work. **Version introduced** helps readers understand when the item became available. Many entity pages also separate content into clear sections or tabs, such as: - **Description** - **Parameters** - **Returns** - **Examples** - **Notes** This structure makes the page easier to scan. **Description** explains meaning. **Parameters** and **Returns** answer input and output questions. **Examples** show usage. **Notes** often capture exceptions, edge cases, or special behavior. When you need to share a very specific part of the page, Atloria’s heading links make that easier. A link attached to a section heading or field heading lets you point someone directly to a property, parameter, or definition instead of sending them to the top of a long page. [SCREENSHOT: Top section of an entity detail page with summary, Type, Defined in, and section links for Description, Parameters, Returns, and Examples] ## Following Relationships Between Related Entities Entity detail pages in Atloria become much more useful when you treat them as connected pages rather than isolated entries. Many pages include relationship areas such as **Related entities**, **See also**, **Parent**, **Child**, **Implements**, **Extends**, or **References**. These labels help you move from one definition to another without guessing which page to open next. For example, if you are reading about a configuration object and one of its fields points to another documented item, the field type may be clickable. Selecting that linked type takes you directly to the detail page for that referenced item. The same pattern often appears in **Parameters** and **Properties** tables, where a linked type name helps you follow the data from one page to another. Relationship labels are especially helpful because they explain *how* items are connected, not just that they are connected. Readers can often tell the difference between: - A parent item and its child items - A resource and the schema it returns - A command and the configuration object it depends on - A documented item and other pages that expand on the same topic This saves time. Instead of opening several pages at random, you can choose the next page based on the relationship label shown on screen. To keep your place while moving between pages, use the **breadcrumb trail** at the top and the **left navigation tree** alongside the content. The breadcrumb trail shows the current page in context, while the sidebar helps you see nearby entries in the same section. If you came from a linked page, a visible back action in your browser or navigation flow also helps you return without losing context. [SCREENSHOT: Related entities section with linked items and a breadcrumb trail showing the current page location] If you need a broader refresher on navigating technical sections before drilling into individual pages, see [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). ## Using Detail Pages to Answer Reader Questions Quickly In Atloria, the best entity detail pages are designed for quick answers. Readers often arrive with one specific question, and the page layout helps them find the answer without reading everything from top to bottom. Different page areas support different kinds of questions. Use these page elements as shortcuts: - **Summary block** for “What is this?” - **Type** or **Kind** label for “What sort of thing is this?” - **Defined in** or **Module** for “Where does this belong?” - **Parameters** for “What inputs does it accept?” - **Returns** for “What does it give back?” - **Properties** or field tables for “What values are available?” - **Examples** for “How is it used?” - **Notes** for exceptions, warnings, or special handling Readers in public documentation often scan badges and labels before they read full paragraphs. A visible **Deprecated**, **Experimental**, or **Required** label can change how they use the information immediately. For example, if a field is marked **Required**, they know they cannot skip it. If something is marked **Deprecated**, they know to look for a newer option before copying the example. Atloria also helps readers land directly on the right page. They may arrive from **search results**, the **sidebar navigation**, or an **in-page link** from another reference page. That direct access matters because readers using reference content usually want a precise answer, not a guided tutorial. Concise field descriptions and clear cross-links reduce support questions because readers can confirm meaning on their own. If a parameter name links to another page and the definition sentence explains its purpose clearly, the reader does not need to leave Atloria to ask what it means. [SCREENSHOT: Entity page with badges such as Required or Deprecated, plus Parameters and Examples sections visible] ## Authoring Entity Detail Pages That Stay Consistent When you create or maintain entity detail pages in Atloria, consistency matters as much as accuracy. Readers move between many reference pages in one session, so repeated structure and naming help them stay oriented. Start with a stable **page title** and identifier so the page header, internal references, and linked mentions all point to the same item in the same way. If the title changes too often or appears differently across pages, readers may think they are looking at separate items. The opening definition sentence should match the visible metadata on the page. If the page shows **Type** or **Kind**, make sure the summary describes the item in the same terms. A page labeled as a command should read like a command definition. A page labeled as a field should read like a field definition. This alignment helps readers trust what they see at the top of the page. A predictable section order also improves readability. In Atloria, keep structured sections in a consistent pattern, such as: - **Description** - **Properties** or **Parameters** - **Relationships** - **Examples** - **Version notes** This order lets readers know where to look every time they open a similar page. It also makes the **in-page table of contents** more useful because the same kinds of headings appear in the same order across the documentation set. Relationship links should be explicit and clearly labeled. Use visible section names such as: - **Related entities** - **Parent type** - **Returned by** - **See also** These labels remove guesswork. Instead of forcing readers to infer connections from body text, you show those connections in a dedicated area that is easy to scan. [SCREENSHOT: Well-structured entity detail page with consistent heading order and a clearly labeled Related entities section] ## Avoiding Common Problems in Entity Detail Pages A small mismatch on an entity detail page can make the whole page harder to trust. In Atloria, one of the most common problems is disagreement between the **page title**, the **Type** label, and the opening description. If the title suggests one kind of item but the summary describes another, readers have to stop and figure out what they are actually reading. Fix this by checking that the header, metadata labels, and first sentence all describe the same thing. Another common issue is a broken reading path. Readers often depend on **Related entities**, **See also**, and linked type names to continue exploring. When those sections are empty, missing, or not linked, the page becomes a dead end. Review these areas carefully: - **Related entities** with no useful links - **See also** sections that are present but empty - Type names in **Parameters** or **Properties** that appear as plain text instead of links - Breadcrumbs or sidebar placement that make the page feel disconnected from nearby content Low-value definitions also create confusion. A weak summary often repeats the entity name without explaining purpose. For example, a definition that only restates the title does not help the reader understand inputs, outputs, or constraints. A better opening sentence should explain what the item does or why someone would use it. Finally, watch for stale metadata. Labels such as **Version introduced**, **Deprecated**, **Defined in**, and **Last updated** can become misleading if they are not reviewed regularly. When those labels no longer match the current documentation, readers may follow outdated guidance or assume the page is unreliable. [SCREENSHOT: Entity detail page highlighting mismatched title and Type label, empty See also section, and outdated metadata fields] ## Overview Entity detail pages in Atloria are the places where technical reference content becomes most useful to readers. Instead of browsing a list of entries, readers open one page to understand one documented item in context. The strongest pages combine a clear **page title**, a short definition, structured metadata, and visible links to related items. That combination helps both documentation teams and readers move quickly through technical material without losing context. When you review or write these pages, focus on the parts readers use first: - The **page header** for the entity name - The **summary sentence** for a plain-language definition - Metadata such as **Type**, **Defined in**, **Required**, **Deprecated**, and **Version introduced** - Structured sections like **Description**, **Parameters**, **Returns**, **Examples**, and **Notes** - Navigation aids such as the **breadcrumb trail**, **left navigation tree**, and **in-page table of contents** - Relationship areas such as **Related entities** and **See also** These page elements work together. The header confirms what the page is about, metadata explains status and context, and relationship links help readers continue to the next relevant page. This is especially important in Atloria when readers arrive from search, sidebar navigation, or cross-links inside a technical documentation set. If you are maintaining reference content, treat entity pages as part of a connected network rather than standalone articles. Consistent titles, reliable metadata, and strong relationship links make the whole technical documentation area easier to use. If you are reading rather than authoring, scan the top block first, then jump to the section that matches your question. ## Prerequisites Before this topic is useful, you should already be comfortable moving around Atloria’s technical documentation areas and opening API reference pages from project or published views. This page assumes you can already recognize the main reading surfaces and want help interpreting the content inside an individual entity page. You will get the most value from this guide if you already know how to use: - The **left navigation tree** to open reference entries - The **breadcrumb trail** to understand where a page sits in the documentation structure - **Search results** to jump directly to a specific technical page - The **in-page table of contents** to move between sections on a long page It also helps if you have already read: - [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages) - [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views) Those guides explain how readers reach reference content and how the reading experience differs across views. This guide stays focused on the individual entity page itself: what the labels mean, how to read metadata, and how to follow related links. If you are working inside a project workspace, familiarity with broader technical browsing patterns is also helpful. For that context, use [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). For the next topic, continue with [Reading Published API and Technical Documentation](doc:reading-published-api-and-technical-documentation). ## Reading parser coverage counts in the repository view In Atloria, parser coverage is most useful when you read it directly in the **repository analysis** or **code parsing workspace** view, where Atloria shows how much of a repository it can actually understand. Look for the area that summarizes **files scanned**, **supported files**, and any **coverage percentage** shown for the repository. The **files scanned** total tells you how many files Atloria reviewed during analysis. The **supported files** total shows how many of those files match a parser Atloria can use for structure extraction and documentation-related analysis. [SCREENSHOT: repository analysis view showing files scanned, supported files, and parser coverage percentage] When Atloria breaks coverage down by language or file type, read those labels as parser families rather than one-extension-per-row. A single count may represent several related file extensions grouped together under one language or parser heading. This helps you understand the real coverage of a codebase without manually checking every extension. As you review the counts, separate them into three practical groups: - **Fully parsed files**: files Atloria clearly recognizes and can analyze with strong confidence - **Partially recognized files**: files Atloria detects, but where extraction may be incomplete - **Excluded or unsupported files**: files Atloria scanned but could not parse because no matching parser is available The coverage percentage is the fastest way to judge whether parsing-based features are likely to be useful. A high percentage usually means Atloria can analyze most of the repository’s meaningful source files. A lower percentage does not always mean poor fit, though. If the unsupported portion is mostly generated output, archived code, or non-source assets, the repository may still be a strong candidate. If you need a refresher on where to find language support details before reviewing coverage, see [Evaluating Language and Framework Support in Atloria](doc:evaluating-language-and-framework-support-in-atloria). ## Checking which frameworks and stacks Atloria can parse After you review file coverage, open the **framework** or **stack compatibility** area in Atloria to see which technologies were detected in the repository. This view helps you compare what Atloria found against the files your team expects to be present, such as package manifests, lockfiles, or build-related configuration files that usually signal a specific framework or stack. [SCREENSHOT: framework compatibility section showing detected technologies and support states] Use this part of the screen to answer two separate questions: - Did Atloria **detect the framework or stack** your repository uses? - Does Atloria show that framework as **supported**, **limited support**, or **unavailable**? Those states matter because a repository can contain a supported language while still having only partial framework coverage. For example, Atloria may recognize the underlying language files but provide weaker support for framework-specific templates, component formats, or project conventions. In that case, language coverage may look healthy while framework compatibility is only partial. This is especially important for mixed stacks. A repository may include: - frontend files with one framework - backend source in another language - shared configuration files - template or component files tied to a specific stack In Atloria, compare those areas side by side instead of treating the repository as one uniform codebase. Strong support in backend files does not automatically mean the frontend templates are equally covered, and the reverse is also true. Framework detection is also a good way to confirm whether Atloria is likely to include more than plain source files. If the compatibility area reflects the framework your team uses, that is a good sign that related component files, template files, and configuration files may be included in parsing coverage. If the framework is missing or marked with limited support, check the file-level counts more carefully before relying on parsing results. ## Understanding support indicators before you rely on parsing features Support indicators in Atloria are the quick signals that tell you how confidently Atloria can work with a language, framework, or file pattern. You may see these as **badges**, **status labels**, or availability markers in the repository analysis view, supported languages area, or parsing workspace. Read them as quality indicators, not just yes-or-no availability. In practical terms, these statuses usually fall into three working categories: - **Supported**: Atloria can reliably recognize and analyze the files - **Limited support**: Atloria can detect some structure, but results may be incomplete - **Unavailable**: Atloria does not currently parse that file type or framework in a meaningful way [SCREENSHOT: support badges beside detected languages and frameworks] These indicators matter because they affect downstream work in Atloria. Lower support can reduce the quality of: - extracted structure in technical documentation views - linking between code elements and generated reference material - completeness of AI-generated documentation based on parsed code - confidence in repository-wide analysis results A supported language can still produce gaps if the repository uses uncommon conventions. Watch for situations where the language itself is recognized, but the repository includes: - **custom file extensions** - **generated source files** - **embedded templates** - **unusual folder layouts** In those cases, Atloria may show support at the language level while still missing important files in practice. That is why support indicators should always be read together with parser counts and framework detection. Use the indicator details to decide whether a repository is ready for everyday documentation work or better suited for a smaller evaluation. If the core files your team depends on are marked **supported**, Atloria is usually ready for broader use. If key areas are marked **limited support** or **unavailable**, treat the repository as a pilot candidate until you confirm the output quality in real project work. ## Judging fit for monorepos and mixed-language codebases Monorepos and mixed-language repositories need a more careful review because a single overall coverage percentage can hide major differences between packages, apps, or services. In Atloria, look beyond the top-level parser summary and compare coverage across the parts of the workspace that matter most to your team. [SCREENSHOT: repository parsing view with multiple packages or services showing different coverage levels] Start by checking whether parser coverage is spread across the repository or concentrated in only one area. In a monorepo, Atloria may show strong support for one app while another package has much lower coverage. That difference matters if the low-coverage area contains the code your documentation team actually needs. Pay close attention to whether these areas appear in the totals or seem to be omitted: - **shared libraries** - **infrastructure folders** - **generated directories** - **archived modules** - **vendor or dependency folders** If unsupported counts are coming mostly from generated or third-party content, that may not be a real problem. If the unsupported counts come from shared libraries or business-critical services, the fit is weaker even when the overall percentage looks acceptable. Mixed-language codebases should be judged by business value, not just by average coverage. Compare high-coverage and low-coverage areas and ask whether Atloria covers the parts that drive your documentation goals. For example, partial stack compatibility may be perfectly acceptable if only one team needs parsing-based documentation for a specific service or app. This is where Atloria works best as a decision tool. Instead of asking, “Is the whole repository supported?” ask, “Are the important packages, services, and documentation targets supported well enough?” That approach gives a much more realistic answer for large workspaces with different technologies under one repository. ## Deciding when parser coverage is good enough for your team The right coverage threshold in Atloria depends on what your team wants to do with parsing results. A repository does not need perfect support to be useful, but it does need enough support in the right places. When you review parser coverage, combine three signals instead of relying on one number alone: - **coverage percentage** - **number of unsupported files** - **presence of limited-support frameworks or file types** A practical decision matrix can help: - **Strong fit**: core repositories show high supported-file coverage, and the most important source folders are clearly recognized - **Conditional fit**: overall coverage is acceptable, but critical folders or frameworks show partial support - **Poor fit**: key source files remain unparsed, or Atloria mainly supports secondary parts of the repository Different roles may judge the same repository differently. **Project Administrators** often focus on rollout readiness across teams and whether Atloria can support repeatable parsing workflows at scale. **Technical Writers** may care more about whether Atloria can extract enough structure from the code areas used to build documentation pages, reference material, or AI-generated drafts. [SCREENSHOT: parser coverage summary with supported, limited, and unsupported areas highlighted] When you make a decision, document the exceptions so the team does not misread the numbers later. Unsupported files may include: - **vendor code** - **build artifacts** - **generated output** - **archived modules** - **non-source assets** Those files can inflate unsupported totals without affecting real documentation work. In Atloria, coverage is “good enough” when the unsupported portion does not block the workflows your team actually plans to use. If the important code is covered and the gaps are mostly low-value files, the repository is usually ready to move forward. ## Investigating low coverage and misleading compatibility signals If parser coverage in Atloria looks lower than expected, do not assume the repository is unsupported right away. First, verify that the repository analysis included the branch, folders, and file types your team intended to review. Low totals can happen when the scan did not include the part of the repository where the main source files live. Next, compare the compatibility indicators with the actual repository contents. If a framework appears as **unavailable**, check whether the repository includes the usual detection files Atloria would rely on, such as manifest files, lockfiles, or build-related configuration files. If those files are missing, renamed, or not committed, Atloria may not identify the framework correctly even when the source code is present. [SCREENSHOT: repository analysis screen showing low coverage with framework status details] When support indicators conflict with what your team expects, inspect patterns that often reduce recognition: - **custom file extensions** - **embedded templates inside nonstandard files** - **generated source** - **uncommon project layouts** - **framework files stored outside typical folders** These cases can make a repository look less compatible than it really is. On the other hand, totals can also look better or worse than they should if the scan includes large excluded areas. Review whether these are affecting the numbers: - **vendored dependencies** - **build outputs** - **generated directories** - **temporary or archived folders** A useful habit in Atloria is to compare the top-level compatibility status with the file-level parser counts. If the framework looks supported but the file counts are unexpectedly low, the repository may use conventions Atloria only partially recognizes. If the framework looks unavailable but file-level coverage is still strong, Atloria may be parsing the underlying language even without full framework detection. In either case, use both views together before making a rollout decision. ## Overview This document helps you interpret the parser-related signals Atloria shows when you review a repository in the **code parsing workspace** or related repository analysis views. The goal is not just to see whether a language appears on a supported list, but to decide whether your actual codebase is a good match for parsing-based features such as technical structure extraction, linked reference content, and documentation generation. The most important areas to review in Atloria are: - **parser coverage counts** - **coverage percentages** - **framework or stack compatibility indicators** - **support badges showing supported, limited support, or unavailable states** Taken together, these signals help you answer a practical question: can Atloria meaningfully analyze the parts of the repository your team cares about? This guide focuses on how to read those signals in real repositories, especially when you are dealing with: - mixed frontend and backend stacks - monorepos with multiple packages or services - repositories that include generated code or vendor content - frameworks that may be recognized differently from their underlying language files If you have already reviewed the broader language and framework support lists, this guide builds on that work rather than repeating it. For that earlier step, see [Evaluating Language and Framework Support in Atloria](doc:evaluating-language-and-framework-support-in-atloria). Use this page when you need to decide whether parsing coverage is strong enough for production documentation workflows, only suitable for a pilot, or too incomplete for the repository you want to analyze. The sections below show how to read the counts, interpret support indicators, and avoid common mistakes when compatibility signals are misleading. ## Prerequisites Before using this guidance in Atloria, make sure you already have access to a repository or project area where parsing results are visible. You should be able to open the **repository analysis** or **code parsing workspace** view and see parser-related summaries, file counts, or framework detection results. If those areas are not yet available in your project, you may need to complete repository setup first. This guide assumes you have already done the earlier support review covered in [Evaluating Language and Framework Support in Atloria](doc:evaluating-language-and-framework-support-in-atloria). That earlier document helps you understand what Atloria supports in general. This document is the next step: checking whether your specific repository matches that support well enough to rely on parsing-based features. It also helps if you know the basic shape of the repository you are reviewing, including: - the main languages used in the project - the frameworks your team expects Atloria to detect - whether the repository is a single app or a monorepo - which folders contain the business-critical source files - whether the repository includes generated output, dependencies, or archived modules You do not need deep technical knowledge to use this guide, but you do need enough familiarity with your project to recognize whether Atloria’s counts and compatibility indicators line up with what your team expects to see. If you are ready to go deeper after this page, continue with [Understanding Supported Languages Frameworks and Parser Availability](doc:understanding-supported-languages-frameworks-and-parser-availability), which looks more closely at how language support, framework recognition, and parser availability relate to each other. ## Orienting Yourself on the Project Home Page When you open a project in **Atloria**, start by checking the parts of the screen that stay consistent as you move around. These elements help you confirm that you are still working inside the same project and not in a different workspace or a broader admin area. Look for these **project context markers** on the page: - **Project name** in the page header - **Breadcrumb trail** showing where you are inside the project - **Workspace switcher** if your project connects to other workspaces - **Primary navigation tabs or links** for areas such as **Documents**, **Versions**, **Analytics**, **Technical Documentation**, **Onboarding**, and **Settings** These project-level navigation links are important because they keep you inside the current project. When you open **Documents** or **Versions** from the project navigation, Atloria carries the same project context forward instead of sending you back to a general dashboard. The project home page also acts as a hub for related work. Depending on your project setup, you may see links or cards that take you to: - **Documents** for writing and organizing content - **Versions** for release and review work - **Analytics** for project performance and usage information - **Technical Documentation** for reference-style content tied to the project - **Onboarding** for setup tasks and guided project preparation - **Settings** for project-specific configuration If Atloria shows a **linked workspace** indicator, treat it as a sign that the next screen may belong to a connected area rather than the exact page group you are currently browsing. This matters when you want to review related content without accidentally editing in the wrong place. A useful rule is simple: - **Project-scoped navigation** affects the current project only - **Global navigation** can take you out of the current project context [SCREENSHOT: Project home page showing the project name, breadcrumb trail, workspace switcher, and navigation links for Documents, Versions, Analytics, Technical Documentation, Onboarding, and Settings] For broader project-home behavior, see [Managing Project Operations Across Project Home Tabs](doc:managing-project-operations-across-project-home-tabs). ## Moving Between Documents, Versions, and Analytics Without Losing Project Context A common navigation path in Atloria is moving from **Documents** to **Versions** to **Analytics** while staying inside the same project. The key is to use the project’s own navigation links instead of returning to a global dashboard each time. From the project home page, open **Documents** using the project navigation. Once the page loads, confirm the active project by checking: - The **project title** in the header - The **breadcrumb trail** - Any visible **workspace label** - The fact that you arrived there from the project navigation rather than a general list When you switch from **Documents** to **Versions**, use the project tab, sidebar link, or project navigation menu that appears within the same project area. This keeps version history tied to the active project. You should still see the same project name and a breadcrumb path that shows you are inside that project’s version area, not in a separate unrelated workspace. Next, open **Analytics** from the same project navigation. Atloria keeps the project context visible through shared markers such as: - The same **project title** - The selected **workspace** - A breadcrumb path that still points back to the current project On the **Analytics & Insights** page, you may see a page header and a notice that the area is not yet fully available. Even so, the page remains part of the same project journey if you opened it from project navigation. To return to the project overview without losing your place, use: - The **breadcrumb** link for the project - The project’s own **navigation tabs** - Your browser’s **Back** button if you just moved from one project section to another Avoid using a top-level global menu when you only want to move between project sections. That can take you out of the current project and force you to reselect it. [SCREENSHOT: Documents page with project title and breadcrumb visible, followed by the same project context on Versions and Analytics] ## Opening Technical Documentation and Onboarding from a Project From the project page, you can also open **Technical Documentation** and **Onboarding** without breaking the connection to the current project. These areas may feel different from **Documents** or **Versions**, so it helps to watch the page title, breadcrumb, and workspace label closely. When you open **Technical Documentation** from a project, Atloria presents it as a project-linked documentation area. It is still connected to the project you came from, but it may look more like a dedicated reference workspace than a general project overview page. To confirm you are in the right place, check for: - A **page title** that clearly indicates technical or reference content - A **breadcrumb** that still traces back to the project - A visible **workspace label** if the technical content is shown in a linked workspace This is especially useful when you are moving between project planning and reference material. If you already reviewed the technical content structure in [Exploring Technical Documentation Inside a Project](doc:exploring-technical-documentation-inside-a-project), use that guide for the content itself and use this page to stay oriented while moving between areas. Opening **Onboarding** from the same project keeps setup work tied to that project as well. In Atloria, onboarding is where guided setup tasks and project preparation steps remain associated with the active project rather than becoming a separate unrelated task list. Watch for these cues: - The **project name** still appears in the header or breadcrumb - The **Onboarding** page title makes it clear you are in setup-related work - The navigation path still gives you a way back to the project home page The main difference between **Technical Documentation** and **Onboarding** is usually the purpose shown in the page title and navigation labels: - **Technical Documentation** focuses on project-linked reference content - **Onboarding** focuses on setup tasks and guided preparation To return, use the **breadcrumb**, the **workspace switcher**, or the project navigation menu. These options are safer than jumping out through a global menu. [SCREENSHOT: Technical Documentation page opened from a project, with breadcrumb back to the project] [SCREENSHOT: Onboarding page showing project-linked setup flow and return path] ## Using Linked Workspaces to Reach Related Content In Atloria, a **linked workspace** is a connected area that belongs to related work but is not always the same as simply opening another page inside the current project section. Understanding that difference helps you avoid editing or reviewing content in the wrong place. A normal project navigation move might take you from **Documents** to **Versions** while keeping everything in the same project workspace. A linked workspace move usually means Atloria is taking you to a connected area with its own page structure, while still preserving the relationship to the project you started from. You may encounter linked workspace entry points in places such as: - A **workspace switcher** - A **linked resource** card on the project page - A contextual link to **Technical Documentation** - A related area such as **Onboarding**, **Analytics**, or another connected workspace view - Cross-project or cross-workspace references shown in navigation Before you continue working, look for signs that you crossed into a linked workspace: - A changed **workspace label** - A breadcrumb that includes the source project - A visible relationship label showing the page is connected to the project - A page title that reflects a specialized workspace rather than the main project home Atloria helps preserve context by keeping the project relationship visible. Even when the page layout changes, you should still be able to tell which project the workspace belongs to and how to return. Stay in the **current project workspace** when you want to: - Write or organize project content - Review project versions - Move between standard project tabs Open a **linked workspace** when you need to: - Review related technical reference material - Complete setup tasks in **Onboarding** - View connected analytics or supporting content that lives in its own workspace structure If you are unsure, pause before editing and confirm the **project name**, **workspace label**, and **breadcrumb** first. ## Managing Project Settings Without Breaking Navigation Flow Open **Settings** from the project navigation when you need to change options for the current project. Using the project’s own **Settings** link is the easiest way to avoid changing something at the wrong level. Inside project settings, Atloria may group project-specific controls into panels related to areas such as: - **Access** - **Integrations** - **Documentation preferences** - **Linked workspace configuration** These settings belong to the active project, so always verify the page context before making changes. The most reliable checks are: - The **project name** in the header - The **breadcrumb** path - The selected **workspace** - The fact that you entered **Settings** from the current project navigation This matters most for teams that work across several projects. If two projects have similar names or connected workspaces, the header and breadcrumb are your quickest confirmation that you are editing the correct one. After updating a setting, you do not need to restart from a dashboard. Move back to operational pages by using the same project navigation links for **Documents**, **Versions**, or **Analytics**. This keeps your project context intact and saves time. Keep in mind that some settings areas may be **permission-sensitive**. In practice, that means: - **Project Administrators** may be able to open and change more settings - **Documentation Managers** or **Technical Writers** may only be able to view some settings or may not see certain options at all If a settings panel is missing, it may be hidden based on your role rather than removed from the project. For broader setup details, see [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home) and [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). [SCREENSHOT: Project Settings page with project name, breadcrumb, and links back to Documents and Analytics] ## Fixing Common Navigation Problems Across Projects and Workspaces Most navigation mistakes in Atloria come from moving too quickly between project pages, linked workspaces, and top-level navigation. When something looks wrong, check the visible context before you make edits. If you open a page and the project context seems wrong, verify these items first: - The **project name** in the header - The **breadcrumb** path - The selected **workspace** - The page title, such as **Documents**, **Versions**, **Analytics & Insights**, **Technical Documentation**, **Onboarding**, or **Settings** If a linked page opens in an unexpected workspace, look for a **workspace switcher** or a **linked workspace** label. That usually tells you whether you are still in the current project workspace or viewing a connected area. If the workspace name changed, use the breadcrumb or switcher to return before editing anything. If you cannot find **Documents**, **Versions**, **Analytics**, **Technical Documentation**, **Onboarding**, or **Settings**, the cause is often one of these: - You are in the wrong project - You are in a linked workspace with a different menu - Your role does not include access to that area - The navigation item is hidden for your current permissions When returning to the project overview causes you to lose your place, use navigation that preserves context: - Click the **breadcrumb** back to the project - Use the project’s own **tabs** or navigation links - Use the browser **Back** button if you just moved from one project section to another Try not to jump out through a global menu unless you truly want to leave the project. Global navigation is useful for switching to another major area, but it is the most common reason users lose the active project selection. If you need a broader view of project-level oversight after you are comfortable moving between these areas, continue with [Managing Project Portfolio and Operational Oversight](doc:managing-project-portfolio-and-operational-oversight). ## Overview This guide focuses on one practical skill: staying oriented while moving through a project in **Atloria**. Instead of treating **Documents**, **Versions**, **Analytics**, **Technical Documentation**, **Onboarding**, and **Settings** as isolated destinations, Atloria presents them as connected parts of the same project workspace. The most important idea is to rely on the screen elements that preserve context: - **Project name** - **Breadcrumb trail** - **Workspace switcher** - **Project navigation links** - **Page titles** that show which project area you are in You use these cues to answer simple but important questions before taking action: - Am I still in the same project? - Am I in the main project workspace or a linked workspace? - Will this change affect only this project? - Can I return to the project home page without starting over? This guide does not repeat the detailed behavior of each project tab. For that, use [Managing Project Operations Across Project Home Tabs](doc:managing-project-operations-across-project-home-tabs). Instead, the focus here is how those tabs and linked workspaces connect so you can move confidently between them. You also saw that some pages, such as **Analytics & Insights** or **Security & Audit**, may appear as dedicated screens with their own headers. Even when a page has a different visual emphasis, the breadcrumb, project title, and workspace label help you confirm whether it still belongs to the same project journey. Use this guide whenever you need to move between project work areas without losing track of scope, permissions, or the path back to your project home page. ## Prerequisites Before the navigation patterns in this guide will make sense, you should already be comfortable opening a project and recognizing the main project workspace in **Atloria**. You will get the most value from this guide if the following are already true: - You can sign in to Atloria and reach your main workspace - You can open a project from the project list or dashboard - You have access to at least some project sections such as **Documents**, **Versions**, or **Settings** - You understand the basic project home layout from earlier project management guides Helpful background reading includes: - [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) - [Managing Project Workspaces and Recent Activity](doc:managing-project-workspaces-and-recent-activity) - [Managing Project Operations Across Project Home Tabs](doc:managing-project-operations-across-project-home-tabs) You do **not** need access to every project area mentioned in this guide. Some teams will not see every navigation item, and some roles may have view-only access in places like **Settings** or **Analytics**. That is normal in Atloria. Before you begin, make sure you can identify these on screen: - The **project name** - The **breadcrumb** - The **workspace switcher**, if your project uses linked workspaces - The project navigation links for the sections available to your role If one of those items is missing, you may be in the wrong workspace or using a role with limited access. In that case, it is best to confirm your current project and visible navigation before following the workflows in this guide. ## Recognizing What Each Review Status Means In Atloria, the current review result is typically shown as a **status badge** on the version review screen, along with a **review summary** area that helps you understand where the version stands. When you open a documentation version that has been sent for review, look for the label that shows whether it is **Pending Review**, **Changes Requested**, **Approved**, or **Rejected**. That badge gives you the quickest read on what should happen next. Each status means something different: - **Pending Review** means the version has been submitted and is waiting for reviewer action. - **Changes Requested** means a reviewer has looked at the version and wants updates before it can move forward. - **Approved** means the version passed review and can continue to the next release step, depending on your team’s process. - **Rejected** means the version should not move forward in its current form and usually needs a more substantial restart or rework before review begins again. The most important difference is between **Approved** and **Rejected**: - With **Approved**, the version is considered accepted for the current review stage. - With **Rejected**, the version is not accepted, and your team should treat it as blocked until the issues behind the rejection are understood and addressed. You can usually confirm the latest decision in the **review summary** and then scroll to the **review history** or **activity timeline** to see how the status changed over time. That history is useful when several people are involved. It helps you trace: - who submitted the version - who reviewed it - what decision was made - when that decision happened If you need a refresher on how decisions are made in the first place, see [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). [SCREENSHOT: Version review screen showing the status badge, review summary, and activity timeline] ## Reading Reviewer Comments and Decision Notes After a review decision is made, Atloria may show feedback in more than one place. Start by opening the **comments panel** on the version or document review screen. This is where you can read ongoing discussion, follow comment threads, and see whether a reviewer pointed to a specific section that needs attention. If the review includes **inline annotations**, open the marked section in the content area and read the note attached to that exact passage. For broader feedback, check the **review details** or **review summary** area for the final decision note. It helps to separate two kinds of feedback: - **General comments** are used for discussion, suggestions, and section-by-section feedback. - **Decision notes** are attached to the actual review outcome, such as **Approved**, **Changes Requested**, or **Rejected**. Reviewers often use comments to call out issues such as: - missing product or feature details - unclear instructions - style or wording problems - factual corrections - sections that need stronger screenshots or examples - content that does not match the intended audience When you read comment threads, pay attention to whether they are still open or already resolved. In practice, this usually means: - **Unresolved comments** still need a reply, an edit, or reviewer confirmation. - **Resolved comments** have already been handled and usually do not need more action unless the reviewer reopens the discussion. If Atloria shows **@mentions**, use them to spot comments directed specifically to you or another teammate. That is especially useful when several authors and reviewers are working in the same version. Before making edits, compare the detailed comments with the final decision note. A version may contain many small suggestions, but the decision note usually tells you which issues are required before the version can move forward. [SCREENSHOT: Comments panel with open threads, resolved threads, and a decision note in the review summary] ## Deciding What to Do After an Approval When a version shows **Approved**, do not assume the work is completely finished. First, confirm the approval in the **status badge** and **review summary**. Then check whether your team requires more than one reviewer. If Atloria shows multiple review decisions or a shared review summary, make sure all required reviewers have completed their part before you move the version ahead. Next, read any final notes attached to the approval. An approval can still include follow-up items such as: - minor copy edits - title or metadata cleanup - screenshot replacement - audience checks - final publishing verification These notes do not usually block approval, but they may still need to be completed before release. If your team tracks release readiness separately from review approval, use the approved result as a signal to move the version into the next stage your team uses, such as **Ready to Publish** or **Scheduled**. The exact label depends on your content workflow, but the key point is that **Approved** means the review stage has been passed. You should also review the **activity timeline** or **history** area so the sign-off is clearly visible. This record helps documentation managers and project leads confirm that the version received formal approval and shows: - who approved it - when the approval happened - whether any final notes were added If the version is approved but you still need to prepare it for release, the next step is usually not another round of editing. Instead, you move into release preparation tasks. That handoff becomes easier when the approval note, comment resolution, and status history are all complete and easy to read. [SCREENSHOT: Approved version with review summary, reviewer sign-off, and next-stage status option] ## Revising a Document After Changes Are Requested or Rejected If the status badge shows **Changes Requested** or **Rejected**, start by identifying which of those two outcomes you are dealing with. They both stop the version from moving forward, but they usually mean different levels of rework. Use **Changes Requested** when the version is still on the right track but needs updates before approval. In that case, open the **comments panel**, review any **inline annotations**, and read the **decision note** in the review summary. Build a revision checklist from what reviewers flagged, focusing first on items that clearly block approval, such as missing sections, incorrect instructions, or unsupported claims. Use **Rejected** as a stronger signal that the current submission should not continue in its present form. A rejection often points to a bigger problem, such as the wrong scope, the wrong document type, or a draft that is too incomplete for review. Read the rejection note carefully before editing so you do not spend time polishing a version that needs a more fundamental rewrite. As you revise the draft in Atloria, work through the feedback methodically: - update the affected content - correct the sections named in comments - reply in comment threads where clarification is needed - resolve threads once the issue has been fixed - double-check that previously flagged sections now match reviewer expectations After the updates are complete, make sure you **resubmit the version for review**. Saving changes alone does not mean the review has restarted. If the original workflow included a **Submit for Review** action or similar review control, use that same submission path again so reviewers can see the version is ready for another pass. [SCREENSHOT: Version with Changes Requested status, comment threads, and the review submission control] ## Coordinating Reviewer and Author Responsibilities A smooth review cycle in Atloria depends on reviewers and authors using the right actions at the right time. On the review screen, reviewers are responsible for making the decision that best matches the state of the version. That usually includes: - leaving comments in the **comments panel** - adding **inline annotations** to specific sections - choosing **Changes Requested** when the version is close but not ready - choosing **Approved** when the version meets expectations - choosing **Rejected** when the submission should not continue as submitted Authors have a different set of follow-up responsibilities. Once feedback appears, the author should: - read the **review summary** and final decision note - respond to open comment threads - revise the draft content - resolve comments that have been addressed - resubmit the version for review when updates are complete - advance approved content into the next release stage when all approvals are in place For documentation managers, the focus is usually broader. Instead of looking at one version at a time, they monitor review progress across many items using the **review queue**, **status filters**, or **activity tracking** views. These views help them spot bottlenecks, such as versions stuck in **Pending Review** or drafts that remain in **Changes Requested** without being resubmitted. Choosing between **Changes Requested** and **Rejected** matters. Teams usually use **Changes Requested** when the draft is valid but needs correction. **Rejected** is more appropriate when the submission is fundamentally unsuitable, such as: - the wrong document was submitted - the content is out of scope - the draft is too incomplete for meaningful review - the version does not match the intended release Clear use of these decisions keeps the review queue easier to manage and prevents confusion for authors. ## Handling Common Review Outcome Problems Sometimes the status and the actual workflow do not seem to match. When that happens in Atloria, start with the visible review details rather than guessing. If the version shows **Approved** but does not move forward, check whether there are still additional required reviewers who have not completed their decision. Also review the **review summary** and **activity timeline** for signs that approval happened in one part of the workflow, but another required step is still waiting. A single approval does not always mean the entire review process is finished. If comments are present but the outcome is unclear, compare the detailed feedback in the **comments panel** with the final note attached to the review decision. Inline comments may include suggestions, questions, or optional edits, while the **decision note** usually tells you the official result. When the two seem inconsistent, rely on the visible status badge first and then use the final decision note to understand the reviewer’s intent. If an author updates the draft but the status still shows **Changes Requested**, the most common reason is that the version was edited but not formally resubmitted. Open the review controls and make sure the version was sent back through the review action, not just saved in the editor. If a reviewer used **Rejected** without enough explanation, open the **activity history** and all related comment threads to gather context. Look for: - earlier comments that explain the concern - unresolved threads tied to major issues - a short rejection note that needs to be interpreted alongside prior feedback If the reason is still unclear, pause before restarting review. It is better to clarify the rejection through the existing discussion than to submit another version that repeats the same problem. [SCREENSHOT: Review screen showing status, comments, decision note, and activity history together] ## Overview In Atloria, understanding review outcomes is less about memorizing labels and more about reading the full review picture on the version screen. The **status badge** tells you the current state, the **review summary** explains the latest decision, and the **comments panel** shows the detailed discussion behind that result. When you use those three areas together, it becomes much easier to decide whether to move forward, revise the draft, or restart the submission. The main review outcomes you will see are: - **Pending Review** - **Changes Requested** - **Approved** - **Rejected** Each one points to a different next step. **Approved** means the version can continue into the next release stage. **Changes Requested** means the draft should be updated and sent back for review. **Rejected** means the current submission should not continue without more substantial correction or repositioning. The **activity timeline** helps confirm who made the decision and when, which is especially useful when multiple reviewers are involved. This guide focuses on interpreting those outcomes after review has already happened. If you need help with the decision process itself, use [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals) for the earlier part of the workflow. Once you are comfortable reading statuses, comments, and decision notes, the next step is preparing an approved version for release readiness. Continue with [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review). ## Prerequisites Before using the review details in Atloria, make sure you already have access to a documentation version that has been submitted into the review workflow. This guide assumes you can open the version review screen and see the main review areas, such as the **status badge**, **review summary**, **comments panel**, and **activity history**. You will get the most value from this guide if the following are already true: - you can open the relevant project and documentation version - the version has already been submitted for review - at least one reviewer decision, comment, or note is visible - you understand the basic review flow used by your team It also helps if you have already worked through [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) and [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). Those guides explain how reviews are initiated and how reviewers record decisions. This guide picks up after that point and focuses on how to interpret what happened and what to do next. If you are an author, be ready to edit the draft, respond to comments, and resubmit the version when needed. If you are a reviewer or documentation manager, be ready to read the review summary, compare comments with the final decision, and confirm whether the version should advance or return to editing. [SCREENSHOT: Version review page with the main review areas labeled for first-time users] ## Defining the documentation signals you will track Before you start ranking documentation work, decide exactly which signals you will review in Atloria and keep that list stable from one review cycle to the next. If you already worked through [Analyzing Documentation Performance Across Projects](doc:analyzing-documentation-performance-across-projects), use the same project and reporting views here so your comparisons stay consistent. In Atloria, focus on a small set of signals that clearly support content decisions: | Signal | What to look for | What it usually helps you decide | |---|---|---| | Pageviews | Pages visited often | Which pages affect the most readers | | Unique visitors | How many different readers reached a page | Whether demand is broad or concentrated | | Average time on page | Very short or unusually long reading time | Whether readers are skimming, getting stuck, or reading deeply | | Exit rate | Readers leaving after a page | Whether a page may be ending the journey too early | | Search queries | Repeated words and phrases | Which topics readers expect to find | | Zero-result searches | Searches with no matching page | Which topics or terms are missing | Do not mix every page type into one list. Separate onboarding guides, troubleshooting articles, release notes, and reference content before you compare them. A short visit on a release note may be normal, while the same pattern on a setup guide may point to a problem. When you open your analytics view, confirm three things before you record any findings: - The date range, such as the last 7 days or last 30 days - Any traffic filters you are using - The content group or project area you are reviewing [SCREENSHOT: Analytics view showing date range, filters, and grouped documentation content] Keeping these settings the same each week or month makes your priority list more trustworthy. Otherwise, a page can appear to improve or decline simply because you changed the reporting window or compared different content groups. ## Finding where readers struggle in the docs journey Once your signals are defined, use them to find where readers lose momentum. In Atloria, start with the pages that bring readers in. Top landing pages often reveal the first place someone tries to solve a problem, whether they arrived from a search engine, a product link, or a support response. Look closely at landing pages that combine high traffic with weak engagement. A page that attracts many visits but shows short reading time or quick exits may not be answering the question the title promised. This is especially important for task-based pages, where readers usually expect a direct set of steps and a clear result. Site search behavior gives you another strong clue. Review repeated searches, alternate spellings, and searches that return no results. These patterns often point to one of three issues: - The topic does not exist yet - The page exists, but the title uses different wording - Navigation labels do not match the language readers use For example, if readers repeatedly search for the same phrase after landing on a popular overview page, that overview page may need clearer links to the next task or troubleshooting article. Support activity helps confirm whether the documentation gap is real. Compare common support topics with the pages readers visit before contacting support. If a topic receives both heavy documentation traffic and frequent support requests, that page deserves attention even if its pageviews alone do not make it your top item. [SCREENSHOT: Report showing top landing pages, engagement metrics, and search terms side by side] As you review, group findings by journey stage rather than by page alone. A reader may land on an overview, search for a setup term, then open a troubleshooting page. When several weak signals appear across that path, you have found a documentation journey that likely needs improvement. ## Turning analytics patterns into a content priority list After you identify weak spots, turn them into a ranked list that your team can act on. In Atloria, avoid sorting pages by pageviews alone. A page with moderate traffic can still deserve urgent work if it affects a critical workflow, drives support volume, or has not been updated in a long time. A simple priority matrix works well when you combine four factors: | Factor | What to consider | |---|---| | Traffic volume | How many readers the page affects | | Support impact | Whether the topic still generates support requests | | Content freshness | How old the page is and whether the interface has changed | | Business importance | Whether the page supports onboarding, setup, publishing, or another key workflow | Use these patterns to decide what kind of work each page needs: - **Rewrite** pages when you see high visits, high exits, and continued support demand on the same topic. - **Expand** pages when readers stay on the page but continue searching for related terms, which usually means the content is helpful but incomplete. - **Consolidate** pages when several low-traffic articles compete for the same search phrase or cover the same workflow in fragments. This approach helps you avoid spending time on pages that are merely popular. Instead, you focus on pages where better content can improve reader outcomes. [SCREENSHOT: Documentation priority list with impact level, traffic, support volume, and recommended action] When you build the list, add one clear reason beside each page. For example: “High-traffic onboarding page with short engagement and repeated follow-up searches” is much more useful than “Needs update.” That wording makes it easier for writers, support leads, and project owners to agree on why the page belongs near the top of the backlog. ## Improving pages based on the signals you found Once you have a priority list, update each page based on the specific signal that triggered it. In Atloria, the most effective improvements usually start with language. If internal search reports show that readers use a different phrase than your page title or heading, rename the page and section headings to match the wording readers already use. For pages with quick exits after readers arrive from product links or support responses, review the page structure first. Make sure the page includes: - A title that matches the task - Clear step-by-step instructions - Any required setup or conditions before the task starts - The expected result at the end of the task If readers spend time on a page and then search again, the page may need expansion rather than a rewrite. Add the next logical step, a troubleshooting section, or links to related reference pages. This is especially useful for overview pages that introduce a feature but do not yet guide readers to the exact screen or action they need next. Cross-linking is another high-value fix. Add links between overview pages, troubleshooting articles, and reference content that readers commonly open in sequence. This reduces the need for repeated searching and helps readers move through the documentation more naturally. Also review screenshots and interface wording on high-traffic pages with weak engagement. If button labels, menu names, or screen titles have changed in Atloria, readers may leave because the instructions no longer match what they see. [SCREENSHOT: Documentation page showing updated title, clearer headings, related links, and refreshed screenshot] Treat every edit as a response to a measured problem. That keeps your updates focused and makes it easier to check later whether the change actually improved the page. ## Sharing analytics-backed priorities with writers and support teams A priority list only becomes useful when other teams can review it quickly and understand why each item matters. In Atloria, create a shared reporting view that brings the most important signals together in one place. Keep it simple enough that a writer, support lead, or admin can scan it without opening several separate reports. A practical shared view should include: | Column | Why it matters | |---|---| | Page or topic | Identifies the content to update | | Owner | Shows who is responsible | | Last updated | Highlights stale content | | Pageviews | Shows reader demand | | Search demand | Confirms what readers are trying to find | | Related support volume | Shows customer impact | | Priority level | Helps teams agree on order | Use a common label set such as **High-impact**, **Medium-impact**, and **Maintenance**. These labels are easier to discuss than raw numbers alone, especially when different teams care about different outcomes. A support lead may focus on ticket volume, while a writer may focus on content age and clarity. For each proposed change, include the metric you expect to improve. Examples include: - Reduce zero-result searches for a missing topic - Lower exits on a setup page - Increase engagement on a troubleshooting article - Reduce support requests tied to a known issue [SCREENSHOT: Shared documentation priority report with owner, impact level, and expected outcome] Review this list on a regular schedule with the people who manage documentation, support, and project priorities. A fixed weekly or monthly review works better than ad hoc updates because urgent customer pain points can be added quickly, while lower-impact maintenance work stays visible without taking over the queue. ## Checking whether your documentation changes improved outcomes After you publish an update, return to the same Atloria analytics view you used during planning and compare the results against your earlier baseline. Use the same date range style, filters, and content grouping so the before-and-after comparison is fair. For each updated page, check whether the signals moved in the direction you expected: - Did exits decrease? - Did time on page become healthier for that page type? - Did repeated searches or refinements drop? - Did related support requests decline? - Did readers continue to the next page more often? Be careful with misleading changes. Traffic spikes caused by a release announcement, a support campaign, or a seasonal event can make a page look better or worse than it really is. URL changes can also break comparisons if the old page and new page are not being reviewed together. If engagement improves but support demand does not change, the page may still be missing the real issue readers contact support about. In that case, compare the updated page with recent support topics and check whether the article covers the exact workflow support is handling. If traffic drops sharply after an update, do not assume the page became less useful. First verify that the page can still be found through search, internal links, and any product or help links that previously sent readers there. [SCREENSHOT: Before-and-after analytics comparison for an updated documentation page] A good review cycle ends with a decision, not just a measurement. Mark each page as successful, needs another revision, or needs a broader content change. The next document, [Managing Enterprise Analytics for Documentation Programs](doc:managing-enterprise-analytics-for-documentation-programs), shows how to scale this process across larger documentation teams and multiple projects. ## Overview This guide shows how to use Atloria analytics to decide which documentation pages should be updated first. The goal is not to collect every available number. Instead, you use a focused set of signals to find pages that attract readers, fail to answer questions, or continue to generate support demand even after people visit the docs. The workflow in this guide follows a practical sequence: 1. Define the signals you will track consistently. 2. Review landing pages, search behavior, and support patterns to find friction. 3. Turn those findings into a ranked content priority list. 4. Update pages based on the specific issue the data revealed. 5. Share the priorities with writers and support teams. 6. Measure whether the changes improved outcomes. This document builds on [Analyzing Documentation Performance Across Projects](doc:analyzing-documentation-performance-across-projects). That earlier guide focuses on reading performance across projects. Here, the focus is narrower: deciding what to rewrite, expand, consolidate, or relabel inside your documentation backlog. Use this guide when you already have documentation traffic and want to make better editorial decisions with it. It is especially useful when your team needs to choose between several possible updates, such as improving onboarding guides, expanding troubleshooting coverage, or cleaning up duplicate content around the same workflow. In Atloria, this work is most effective when you compare analytics with real reader behavior, including internal search terms and support activity. That combination helps you move beyond “most visited pages” and identify which content changes are most likely to improve customer outcomes. ## Prerequisites Before you use this workflow in Atloria, make sure you have access to the reporting areas and content views needed to compare documentation performance. You do not need every admin feature, but you do need enough visibility to review page activity and connect it to real documentation work. Prepare the following before you begin: - Access to the relevant analytics view for the project or documentation area you want to review - A clear date range you plan to use consistently, such as weekly or monthly reporting - A content grouping approach, such as onboarding guides, troubleshooting pages, release notes, or reference content - Access to internal search reporting, including repeated searches and zero-result searches if available in your reporting setup - A way to review related support trends, such as topic tags, case categories, or another shared support summary - A current list of documentation pages, topics, or owners so you can assign follow-up work It also helps to know which pages are tied to important workflows in Atloria, such as project onboarding, publishing, approvals, analytics, or support agent setup. Those pages may deserve higher priority even if they do not have the highest traffic. If you are still getting familiar with Atloria navigation or reporting areas, review [Using the Admin Workspace](doc:using-the-admin-workspace) and [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). If your focus is project-level performance rather than cross-project reporting, [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity) can help you frame the right comparisons before you build your priority list. ## Understanding where API reference pages appear In Atloria, the same API reference page can appear in two places: inside a project workspace and in published documentation. The content is meant to describe the same endpoint, but the reason you open it is different in each view. Inside the **project view**, API reference pages are part of your working documentation. This is where technical writers and documentation managers review structure, check wording, and confirm that each endpoint page is complete before release. You usually reach these pages while browsing technical documentation within a project, as covered in [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). In this view, you are checking whether the page is ready to be shared publicly. In the **published view**, the page is presented for readers who need to understand how an endpoint works. Public readers use it to look up request details, required fields, authentication rules, and response formats. They are not reviewing draft quality—they are trying to find answers quickly. No matter which view you open, the page usually has the same main reading areas: - A **left navigation** or sidebar for moving between API sections and endpoint pages - An **endpoint heading** that names the operation - A **method badge** such as **GET**, **POST**, **PUT**, **PATCH**, or **DELETE** - The **request path** - **Parameters** details - A **Request Body** section - **Responses** with status codes and examples - **Authentication** details when access is required [SCREENSHOT: API reference page showing sidebar, endpoint title, method badge, path, parameters, request body, responses, and authentication sections] The biggest difference is context. In the project workspace, you read with a reviewer’s eye. In published documentation, you read like an end user trying to complete a task or confirm how an API call behaves. ## Finding the right endpoint in project and published navigation When you need a specific endpoint in Atloria, start with the navigation panel and work from the section level down to the individual operation page. API reference pages are usually grouped so you can browse by topic rather than scanning one long list. In the **project view**, use the project’s technical documentation navigation to move through the API reference structure. Open the relevant section, then continue through any nested groups until you see the endpoint title you need. This is useful when you are reviewing whether endpoints are filed under the right section names and whether the structure makes sense before publishing. In the **published view**, readers use the public documentation sidebar or table of contents in the same general way. The goal is usually faster: find the right operation, open it, and read only the details needed for the current task. If the sidebar includes multiple groups with similar names, pay close attention to the endpoint title instead of relying on section names alone. To confirm that you opened the correct page, check these items at the top of the endpoint page: 1. Read the **endpoint title**. 2. Check the **method badge** such as **GET** or **POST**. 3. Compare the **request path** shown beside or below the method. 4. Make sure the page purpose matches what you were looking for, such as retrieving data, creating a record, updating a record, or deleting one. Long API reference pages can be easier to scan if Atloria shows in-page links or section anchors. Use those links to jump directly to areas such as: - **Parameters** - **Request Body** - **Responses** - **Authentication** - **Examples** [SCREENSHOT: Sidebar navigation with an API group expanded and one endpoint page selected] If you are reviewing structure rather than just reading content, compare how the page is labeled in the project navigation and how it appears in the published sidebar. That helps you catch confusing titles before readers see them. ## Reading endpoint details and understanding what they mean The fastest way to understand an API reference page in Atloria is to read it from the top down: method and path first, then inputs, then outputs. Start with the **method** and **path** line. The method badge tells you what kind of action the endpoint performs at a glance: - **GET** usually means retrieve information - **POST** usually means create something new - **PUT** usually means replace existing data - **PATCH** usually means update part of existing data - **DELETE** usually means remove something The **path** tells you where the request is sent. If the path includes a variable segment, that usually means part of the path must be filled in with a specific value. Next, read the **Parameters** section carefully. Separate the parameters by where they belong: | Parameter location | What it means | |---|---| | Path parameters | Values included directly in the path | | Query parameters | Values added to refine or filter the request | | Header parameters | Values passed in request headers | | Required or optional | Whether the request can work without that field | When you move to **Request Body**, look for the field list and any example payload. Focus on: - **Field names** - **Data types** - **Required markers** - **Nested objects** - **Example values** If the request body includes grouped fields or nested sections, read from the top level first and then drill into the nested object details. Finally, review the **Responses** section. Match each **status code** to its meaning and example. Common patterns include: - **200** for a successful read or update - **201** for a successful creation - **400** for an invalid request - **401** for an authentication problem - **404** when the requested item cannot be found [SCREENSHOT: Endpoint page with method badge, path, parameter table, request body schema, and response examples highlighted] Reading in this order helps you answer the most common questions quickly: what this endpoint does, what you must send, and what you should expect back. ## Using API reference pages to answer common reader questions Most people open an API reference page in Atloria because they need one specific answer. Instead of reading every section, go straight to the part of the page that matches the question you are trying to solve. If you need to know whether an endpoint requires sign-in or a token, open the **Authentication** section first. Look for a security label, an authorization requirement, or a note that explains what kind of authenticated access is expected. If the page shows an **Authorization** header requirement, treat that as essential information before reviewing anything else. If you need to know which values must be included, check both **Parameters** and **Request Body**. Required items are usually marked clearly. Do not assume that a field is optional just because it appears in an example. The required indicator in the table or schema is the more reliable guide. If your question is “What do I get back when this works?”, go to the main success response in the **Responses** section. In many pages, that will be the first successful status code shown. Read the status code, then compare the schema and example body so you understand both the structure and the sample output. If you are troubleshooting a failed request, compare the documented error responses. Focus on status codes such as: - **400** for invalid input - **401** for missing or invalid authentication - **404** for a missing resource The response example or description often explains what kind of problem that status code represents. A practical reading pattern is: 1. Open **Authentication** to confirm access requirements. 2. Review **Parameters** and **Request Body** for required inputs. 3. Read the primary success response. 4. Scan error responses for likely failure cases. [SCREENSHOT: API reference page with Authentication, required fields, success response, and error responses marked] This approach is especially useful in published documentation, where readers usually want a direct answer rather than a full page review. ## Reviewing API reference pages before publishing them Before an API reference page goes live in Atloria, review it in the project workspace as if you were a public reader seeing it for the first time. The goal is not just to confirm that the page exists, but to make sure it is understandable without extra explanation. Begin at the top of the page. Check that the **endpoint title** is clear, the **method badge** is visible, and the **request path** is correct. If the title is vague or the path does not match the page purpose, readers may select the wrong endpoint even when the navigation is technically correct. Then move through the main sections and confirm that each one is present and readable: - **Parameters** should show where each value belongs and whether it is required - **Request Body** should include field details and examples when a body is needed - **Responses** should include success and error status codes - **Examples** should be easy to scan - **Authentication** should be visible when access is required After checking the project page, preview the same content in its **published layout**. This matters because a page that looks complete in the project workspace may be harder to read once it appears in the public documentation sidebar. Confirm that navigation labels are clear, section anchors jump to the right place, and schema tables remain readable. Use the project view to catch quality issues such as: - Missing descriptions - Incomplete field details - Inconsistent naming between title, path, and navigation - Response examples that do not match the documented response structure [SCREENSHOT: Project view and published preview of the same API reference page shown side by side] If you are doing a broader release check, this review fits well alongside your version and publishing workflow in Atloria. The key question is simple: can an outside reader understand this endpoint page without needing internal context? ## Fixing common problems when pages are hard to read or navigate When an API reference page in Atloria feels confusing, the problem is usually one of four things: the page is hard to find, the request is unclear, the published layout behaves differently, or the response details are too vague. If readers cannot find an endpoint, start with the **sidebar label** and the section where the page appears. An endpoint may be grouped under an unexpected heading, or its title may not match the wording readers expect. Compare the navigation label in the project workspace with the published sidebar. If one is less clear than the other, that is often the source of the confusion. If the request itself is hard to understand, inspect the **Parameters** and **Request Body** sections together. Make sure required fields are clearly marked and that each parameter appears in the correct location. A path value should not be explained like a query value, and a request body example should support the field list rather than introduce unexplained fields. If the published page looks different from what you reviewed internally, compare these elements between the project view and the published view: - Sidebar placement - Section anchor behavior - Table readability - Schema formatting - Example block layout When public readers misread responses, the issue is often in the **Responses** section. Expand status code descriptions where possible, and check that the example body matches the documented schema. If a **200** response example shows fields that are not described anywhere, readers may assume those fields are always present even when they are not. [SCREENSHOT: API reference page with a confusing response section and a corrected version] If navigation is the main problem, return to the browsing patterns described in [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). If the page is visible but still difficult to interpret, the next step is usually to examine the entity-level details that sit behind the endpoint documentation. ## Overview API reference pages in Atloria are used in both internal project workspaces and published documentation, but readers approach them differently depending on where they are. In a project workspace, teams review endpoint pages for completeness, naming, and publish readiness. In published documentation, readers use those same pages to find request details, authentication requirements, and response examples quickly. Across both views, the page structure stays familiar. Readers work with the **left navigation**, the **endpoint title**, the **method badge**, the **request path**, and sections such as **Parameters**, **Request Body**, **Responses**, **Authentication**, and **Examples**. Once you know where those sections are, it becomes much easier to scan a page instead of reading every line. This guide focused on practical reading tasks: - Finding the correct endpoint from the navigation - Confirming the page by checking the method and path - Reading parameters and request body fields correctly - Matching status codes to success and error outcomes - Reviewing pages in the project workspace before publishing - Comparing project and published views when something looks wrong The most useful habit is to read with a purpose. If you need access details, go to **Authentication**. If you need required inputs, check **Parameters** and **Request Body**. If you need expected results, read the main success response first and then compare error responses. [SCREENSHOT: Complete API reference page with the main reading areas labeled] For a closer look at how individual reference items are presented once you open them, continue with [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation). ## Prerequisites Before using this guide, it helps to already be comfortable moving through technical documentation in Atloria. If you have not done that yet, read [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects) first. That guide explains how to move through project documentation structure so you can reach API reference sections more easily. You should also have access to at least one of these Atloria views: - A **project workspace** where technical documentation is available - A **published documentation view** for a project that has already been released This guide is most useful for people working in one of these roles: - **Technical Writers** reviewing endpoint pages before publication - **Documentation Managers** checking whether API pages are ready for external readers - **Public Documentation Readers** looking up endpoint details in published docs To follow the tasks in this guide, you should be able to recognize these page elements when they appear: - **Sidebar** or left navigation - **Endpoint title** - **Method badge** - **Request path** - **Parameters** - **Request Body** - **Responses** - **Authentication** - **Examples** You do not need editing instructions or setup steps to use this guide. The focus here is on reading and reviewing API reference pages as they appear on screen in Atloria, not on creating the underlying content. [SCREENSHOT: Project documentation sidebar with an API reference section expanded] ## Understanding What the Parsing Workspace Extracts from Your Codebase In Atloria, the parsing workspace turns a connected code source into a browsable map that documentation teams can use while writing and reviewing technical content. After a parse finishes, you can review the selected repository source, confirm the parse status, and open the indexed structure that Atloria built from the files it scanned. This workspace is where you check whether the codebase has been read successfully before you rely on it for documentation work. The indexed results usually include the file structure and the named items Atloria can recognize inside those files. Depending on the repository content, that can include modules, classes, functions, exported items, parameters, return details, imports, inheritance links, and relationships between files. When comments or docstrings are present in the source, those may also appear as part of the parsed context and can help you understand intended behavior faster. For documentation work, some parsed details are especially valuable: - Exact symbol names - Function signatures - Parameter names - Return values or type details - Imported dependencies - Inheritance chains - Inline comments or docstrings when available These details help you avoid guessing. Instead of paraphrasing from memory or from an outdated note, you can verify the current implementation directly in the parsing workspace. That improves API reference accuracy, makes feature explanations more precise, and shortens onboarding time for new writers or project contributors. If you already know how to start and manage a parsing session, use that workflow as your starting point and then return here to interpret the results in a documentation context. For session-level tasks, see [Managing Code Parsing Workspace Sessions](doc:managing-code-parsing-workspace-sessions). [SCREENSHOT: Parsing workspace showing repository selection, parse status, file tree, and symbol details panel] ## Preparing a Repository So Parsed Results Are Useful for Documentation Useful parsed results start with the repository content you choose to work from. In Atloria, the best documentation outcomes come from a repository source that includes the real source files your team documents, a stable folder structure, and the language-specific files Atloria can index. If the connected source is incomplete, outdated, or missing important folders, the parsing workspace may still finish successfully but provide only partial value for writers. Before running parsing work for documentation, a Project Administrator should make sure the docs team is using the correct repository connection, the correct branch, and the correct workspace source. Those choices matter because the parsing workspace reflects the code that was actually selected. If your published docs describe one release but the parsing workspace points to another branch, your reference pages can drift quickly. Repository content that improves documentation value includes: - Complete source files for the feature area you are documenting - Consistent folder and module organization - Clear exported items that represent public behavior - Meaningful names for files and symbols - Maintained comments or docstrings where the team expects technical explanation You can confirm that the repository is ready by checking the parsed workspace after indexing completes. Look for the key files your team relies on, then verify that major exported items and important feature entry points appear in the results. If a feature spans several folders, make sure those relationships are visible in the indexed structure rather than isolated into disconnected fragments. This preparation step is not about making the repository perfect. It is about making sure the parsing workspace reflects enough of the real project to support writing decisions. If major files, exports, or feature areas are missing, fix the source selection before using the parsed results in documentation. ## Using Parsed Symbols to Write More Accurate Technical Pages When you are updating a technical page in Atloria, start with the documentation topic and then locate the related entry point in the parsing workspace. For example, if you are documenting sign-in, registration, analytics, webhooks, or project administration, open the parsed file structure and look for the screen or feature area that matches that topic. From there, review the named items Atloria extracted so you can confirm the exact terms used in the codebase before you update the page. The most practical way to work is to move from topic to symbol, then from symbol to related files. Use the parsed details to verify exact names, available inputs, expected outputs, and any linked items that help explain the feature. This is especially useful when you are writing procedural pages, internal technical notes, or reference content that must match the current product behavior closely. A simple working pattern looks like this: 1. Open the parsing workspace and select the repository source tied to the project you are documenting. 2. Find the file or feature area related to your page topic. 3. Open the extracted symbols and confirm the exact names, parameter lists, and return details shown in the workspace. 4. Follow linked references between files to see what other parts of the feature are involved. 5. Update your documentation page using the verified names and relationships instead of older notes or assumptions. As you trace related items, turn those internal relationships into reader-facing explanations. For example, instead of writing that a feature “does several checks,” describe the visible flow in plain language: a user action opens a screen, the input is checked, and then the next step sends the request to the part of the product that completes the task. The parsing workspace gives you the evidence to write that explanation accurately, while your documentation translates it into language readers can follow. [SCREENSHOT: Parsed symbol view with a selected feature file, extracted names, and linked references to related files] ## Improving Reference Documentation with Parsed Code Data Parsed code data is especially valuable when you maintain technical reference pages in Atloria. In the parsing workspace, you can review exact names, arguments, defaults, and type-related details before you update a reference page. That reduces the risk of publishing a page with outdated parameter names, missing options, or descriptions that no longer match the current codebase. For reference work, focus on the details Atloria extracts consistently: - Publicly exposed names - Argument or parameter lists - Default values when shown - Return details - Imported dependencies - Parent-child relationships between related items These details help you build cleaner reference sections because you are documenting what is actually present in the parsed workspace, not what a previous version of the docs said. They also help you explain where shared behavior comes from. If several items rely on the same imported dependency or inherit behavior from a shared parent, you can document that once in the right place instead of repeating partial explanations across multiple pages. Documentation Managers can also use the parsing workspace as a coverage check. Compare the list of exported or visible items in the parsed structure with the reference pages already published in Atloria. If an exported module or public method appears in the workspace but has no matching reference page, that gap is a clear signal that your documentation set is incomplete. A repeatable review cycle works well here: 1. Open the current parsed workspace for the active repository source. 2. Compare major exported items against your published reference pages. 3. Flag missing pages, outdated names, and mismatched arguments. 4. Update the affected pages in Atloria. 5. Recheck the parsed workspace before final review or release. This kind of side-by-side review is one of the fastest ways to catch drift after code changes, especially in projects where releases move faster than manual documentation updates. ## Using Parsed Code to Build Shared Understanding Across Teams The parsing workspace is not only for writers. In Atloria, it also gives administrators, reviewers, and subject-matter contributors a shared view of how a project is organized. Instead of reading every source file manually, new team members can open the parsed file map and symbol list to understand the project’s shape, major feature areas, and where important behavior lives. This is especially helpful when a project has grown over time. A parsed workspace can show module boundaries, linked files, and parent-child relationships in a way that is easier to scan than raw source code. Writers can use that structure to draft internal architecture notes, feature summaries, and reference outlines. Administrators can use the same view to confirm which repository area supports a feature before assigning documentation work or reviewing scope. Common ways teams use the parsed workspace together include: - Identifying the main implementation area for a feature - Confirming which files belong to a workflow - Aligning on feature terminology before editing docs - Checking whether a behavior is shared or feature-specific - Replacing outdated wiki assumptions with current parsed evidence When teams disagree about where a feature starts or which part of the repository is authoritative, the parsed workspace helps settle that quickly. Follow the symbol definitions and related references until you reach the implementation entry point that clearly owns the behavior. That gives everyone the same starting point for documentation updates. This shared review approach is also useful during onboarding. A new writer can open the parsed workspace alongside project pages in Atloria and connect feature names in the docs to the actual repository structure. That shortens ramp-up time and makes collaboration with engineers and administrators more focused because everyone is looking at the same current source map rather than separate notes. ## Fixing Gaps Between Parsed Code and Published Documentation When parsed results and published documentation do not line up, start in the parsing workspace before editing any pages. In Atloria, first confirm that the correct repository source is connected, the expected branch is selected, and the parse has completed successfully. If the workspace is pointing to the wrong source or an older branch, the mismatch may come from source selection rather than from bad documentation. If expected files or symbols are missing, check the indexed structure carefully. Look for the feature area in the file tree, then confirm whether the key exported items appear in the parsed results. If they do not, the parser may not have had the right source content to work with, or the repository selection may not match the code your team intended to document. When a published reference page looks wrong, compare it directly against the current parsed details: - Exact names - Parameter lists - Exported members - Return details - Related dependencies This side-by-side check makes drift easy to spot. A page may still describe an older name, omit a new argument, or reference behavior that has moved into another file. Update the documentation to match the current parsed workspace rather than relying on memory or older review comments. Sometimes the parsed structure itself is difficult to interpret. In that case, look for naming issues, inconsistent organization, or missing comments and docstrings in the source files. Even when the parse succeeds, unclear names can make documentation work slower and more error-prone. Use that finding as a discussion point with the project team. If there is disagreement about feature behavior, use the parsed relationships and implementation entry points as the source of truth for the next documentation revision. That gives writers, reviewers, and administrators a concrete basis for updates and reduces the chance of repeating outdated explanations in future releases. [SCREENSHOT: Comparison workflow showing parsed symbol details beside a published technical documentation page in Atloria] ## Overview Use the parsing workspace in Atloria as a documentation support tool, not just a repository scan result. Its main value is that it gives your team a current, structured view of the code behind a project so you can write technical pages with fewer assumptions and fewer mismatches. Across the workflow, the parsing workspace helps you: - Review the repository source that was indexed - Confirm parse completion before using results - Browse files and extracted symbols - Verify exact names and relationships - Check whether reference coverage is complete - Resolve disagreements using the current parsed structure This document focuses on how to turn parsed results into better technical documentation. It does not repeat the session setup process covered in [Managing Code Parsing Workspace Sessions](doc:managing-code-parsing-workspace-sessions). Instead, it assumes you already know how to open and manage a parsing session and need guidance on using the results in day-to-day writing, review, and collaboration work. In practice, the parsing workspace supports several documentation outcomes at once. It improves API and technical reference accuracy, helps writers explain feature behavior more clearly, supports onboarding for new contributors, and gives cross-functional teams a shared place to verify terminology and scope. That makes it useful for Technical Writers, Documentation Managers, Project Administrators, and anyone reviewing technical content tied to active repository changes. If your team maintains project documentation, internal technical notes, or published reference pages in Atloria, the parsing workspace should become part of your normal review cycle whenever code changes are expected to affect documentation. ## Prerequisites Before using the parsing workspace to support technical documentation in Atloria, make sure these conditions are in place: - You can access the project and its code parsing workspace - A repository source has already been connected for the project - A parsing session has been run or is available to review - You know which branch or repository source your documentation should match - You have permission to review or update the related documentation pages in Atloria It also helps if you already have: - A specific documentation topic to verify - A list of feature areas or reference pages that may need updates - Familiarity with your team’s current terminology for the project - Access to the latest published or draft technical pages for comparison If you still need to upload code or start a new parsing workflow, use [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace) or the session guidance in [Managing Code Parsing Workspace Sessions](doc:managing-code-parsing-workspace-sessions) first. The next step in this sequence is [Uploading and Parsing Code for Documentation Workflows](doc:uploading-and-parsing-code-for-documentation-workflows), which focuses on preparing and running parsing work specifically for documentation use. ## Checking that the version is complete before export 1. In Atloria, open your project and go to the **Versions** list. Select the documentation version you plan to export. Start at the version header and confirm the basic details match what you expect: the version **title**, its current **status**, and the **last updated** information. If the title or timing looks wrong, stop here and confirm you are validating the correct version before moving into export checks. 2. Review the version’s content list page by page. Make sure every required page for that release is included, especially core documentation, release notes, feature pages, and any supporting reference content your team expects to ship together. If you know a page should be part of this version but you do not see it in the list, treat that as an export issue and correct it before continuing. [SCREENSHOT: Version details screen showing the version header and content list] 3. Look closely for pages still marked as **Draft**, unpublished, or otherwise incomplete. A version can look nearly finished while still containing one or two pages that are not ready for readers. Check for any page labels, badges, or warning markers that indicate missing content, incomplete sections, or unresolved placeholders. 4. Use the version’s completeness indicators, if shown on the version screen, to verify that the full documentation set is present. These indicators are especially helpful for spotting missing release notes, absent supporting references, or pages that were created but not fully prepared for release. 5. Before you leave the version screen, review any warnings or validation badges. Pay attention to messages about incomplete content, unpublished pages, or unresolved placeholders. These are often the fastest way to catch issues that would otherwise lead to an incomplete export package. If you need help choosing the right export type after validation, refer back to [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving). ## Confirming approval and release context 1. Open the same version record and check the approval area or workflow panel. Confirm the version is in the correct approval state for export. If Atloria shows that the version is still waiting for review, still in editorial review, or pending final approval, do not treat it as export-ready yet. The export should reflect an approved release, not a draft still moving through review. 2. Verify that all required reviewers or approvers have completed their sign-off. If your team uses multiple review stages, check that none of them are still open. A version may appear polished, but if the workflow panel still shows a pending decision, the export may not represent the final agreed content. 3. Review the release context attached to the version. Confirm the **release date**, **release notes**, and any related product or project version details shown on the version screen. These details matter because they shape the release narrative that travels with the exported documentation. If the release date is missing or the release notes are not attached to the same version, readers may receive an export without the context they need. 4. Check that the version is not missing its changelog or release-summary content. If Atloria displays release-summary content separately from the main page list, confirm it is present and linked to the version you are exporting. [SCREENSHOT: Version workflow or approval panel with approval state and release details] 5. If anything in the approval or release context looks incomplete, fix it before running the final export check. Export validation is much easier when the version record clearly shows that review is complete and the release details are already in place. For a deeper look at version approvals before export, see [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) and [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review). ## Verifying audience visibility and access settings 1. From the version page, open the **Visibility**, **Access**, or audience-related settings for that version. Confirm the selected audience matches the purpose of the export. For example, make sure the version is set for the correct audience such as **Internal**, **Customer**, or **Public**. If the wrong audience is selected, the export may leave out pages your intended readers need. 2. Review any inherited restrictions across the version’s page structure. A parent page may appear available while one or more child pages are hidden because of audience rules or page-level visibility settings. Expand the page tree, if available, and check that child pages are visible to the same audience as the rest of the version. 3. If your team uses role-based access, confirm that the content set matches who should receive the export. Check whether Documentation Managers, Project Administrators, or external readers would see the same pages you expect to include. This helps you catch cases where content is visible during authoring but hidden in the final export because of permission rules. 4. Look for pages excluded because they are unpublished, filtered by audience, or restricted by visibility settings. Those exclusions are not always mistakes, but they should always be intentional. If a page is missing from the export audience, decide whether it should stay excluded or be updated before export. [SCREENSHOT: Version visibility or audience settings with selected audience and page restrictions] 5. When you finish this review, confirm that the export audience and the visible content set match each other. If you are exporting for customer delivery, the version should reflect exactly what customer readers are allowed to see—no more and no less. If you need more detail on access checks before sharing, use [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export) and [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options). ## Reviewing export blockers and missing content 1. On the version page, review any validation messages, warning banners, or issue lists related to export readiness. Focus on problems such as broken links, empty sections, unresolved references, or pages missing required details. These issues often do not block normal editing, but they can reduce the quality or completeness of the exported package. 2. Check for missing assets that should travel with the documentation. Review pages that rely on images, attachments, downloadable files, or embedded media. If a page references supporting material that is not available, the export may technically complete while still being unusable for readers. Open any flagged pages and confirm the needed assets are attached and visible. 3. Review page-level details that affect whether content appears in the export. Pay special attention to: | What to check | Why it matters | |---|---| | **Version assignment** | A page not linked to the target version may be left out of the export | | **Publish state** | Draft or unpublished pages may not appear in exported output | | **Navigation placement** | Pages outside the intended structure can be missed or appear out of order | | **Audience setting** | Restricted pages may be excluded for the selected export audience | 4. Identify pages that are visible while authoring but still excluded from export because of filters, archive state, or missing version linkage. This is a common source of confusion: if you can open a page in Atloria, that does not always mean it belongs in the export package. 5. Resolve blockers as you find them instead of waiting until the end. It is much easier to fix a broken link or missing attachment while you are already on the affected page. [SCREENSHOT: Validation messages or issue list highlighting broken links, missing assets, and excluded pages] ## Running a final export-readiness check 1. Return to the version page and use the **export readiness** or **pre-export validation** action, if available. Run this check only after you have reviewed completeness, approvals, release context, and audience visibility. The goal is to confirm that all the pieces work together, not just that each one looks acceptable on its own. 2. Review the readiness results panel carefully. Look for pass or fail results covering: - completeness of the version content - approval status - audience visibility - release notes or release context - missing pages or blocked content 3. Open each linked issue directly from the results panel and fix it at the source. If the check points to a page, open that page and correct the problem there. If it points to version settings, update the version record before rerunning the check. [SCREENSHOT: Export readiness results panel with pass/fail items and linked issues] 4. Run the validation again after each round of fixes. Keep repeating this until the version shows that it is ready for export. Do not assume that fixing one issue clears the rest; a second run often reveals related problems that were hidden by the first blocking item. 5. Once the version shows ready, record the final validated state. Confirm the approval timing shown on the version and note that the version is now exportable. This gives your team a clear handoff point before anyone starts the actual export workflow. The actual export process is covered next in [Managing Export Center Workflows](doc:managing-export-center-workflows). ## Fixing common issues that prevent export When a version looks ready but still fails export validation, the problem is usually tied to one of a few repeat issues in Atloria. - **The version looks complete, but validation still fails** Check for hidden child pages under an approved parent page. Also review required page details such as version assignment, publish state, and any other required page information shown on the page settings. A single unpublished child page can keep the version from passing validation. - **Approved content is missing from the export** Open each affected page and confirm it is assigned to the same documentation version you are exporting. Then check the page’s audience or visibility settings. A page can be approved and visible to editors but still excluded from the export because it is linked to a different version or hidden from the selected audience. - **Release notes are not included** Open the release notes page and verify it belongs to the target version. Also confirm it is not excluded by export filters or visibility settings. If the release notes exist elsewhere in the project but are not linked to this version, they will not be packaged with the export. - **Validation reports unresolved references** Review the flagged pages for broken internal links, unfinished placeholder text, missing attachments, or references to content that no longer exists. Fix each issue on the page itself, save your changes, and rerun the readiness check. - **Pages appear in authoring but not in export results** Check whether those pages are archived, unpublished, outside the selected audience, or missing from the version’s navigation structure. [SCREENSHOT: Example of a page settings view showing version, publish state, and audience options] If you keep seeing visibility-related problems, [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness) can help you narrow down the cause. ## Overview Validating export readiness in Atloria means confirming that a documentation version is truly ready to leave the project workspace as a complete, approved, audience-correct package. This is more than checking whether pages exist. You are verifying that the selected version includes the right content, carries the correct release context, matches the intended audience, and has no hidden blockers that would cause missing pages or incomplete exports. This step usually happens after you have already decided what kind of export you need. If you have not made that decision yet, use [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving) first. Once the export type is clear, readiness validation helps you avoid common problems such as shipping draft pages, leaving out release notes, exporting the wrong audience view, or missing attachments and linked content. In practice, you will work from the **Versions** area inside a project, open the target version, and review several parts of the version record: the header details, content list, approval state, release information, visibility settings, and any validation messages. Atloria may also provide an export-readiness or pre-export check that gathers these issues into one results panel. [SCREENSHOT: Documentation version screen in Atloria with header, content list, approval panel, and validation area] Use this guide when a version is close to release and you need confidence that the export will match what reviewers, customers, or internal teams are supposed to receive. The next document, [Managing Export Center Workflows](doc:managing-export-center-workflows), picks up from this validated state and walks through the export handoff itself. ## Prerequisites Before you validate export readiness in Atloria, make sure you have the following in place: - Access to the correct project and its **Versions** list - A target documentation version that already exists - Permission to view the version’s content, approval details, and visibility settings - Required documentation pages already added to the version - Release notes or release-summary content prepared, if your team includes them in exports - Reviewer or approver decisions completed, or close enough to completion that you can confirm final status - Any important images, attachments, or supporting files already uploaded to the relevant pages It also helps if you have already reviewed how your team plans to use the export. That way, when you check audience visibility and included content, you can compare the version against a clear purpose such as internal review, customer delivery, or archiving. If that decision is still unclear, go back to [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving). Keep these practical checks in mind before you start: - Open the exact version you intend to export, not just the latest version in the list - Confirm the version title and status before reviewing page details - Be ready to open individual pages to fix publish state, audience, or missing content issues - Expect to rerun the readiness check after making corrections - Coordinate with reviewers if the approval panel still shows pending sign-off If your team manages visibility carefully across versions, [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export) is a useful companion while you work through these checks. ## Confirming what version you are about to share or export Before you test access, make sure you are looking at the correct version record in Atloria. Open your project, go to the documentation versions area, and select the version you plan to share or send through an export workflow. On the version details page, check the version name or number shown in the page header, then confirm the title and current status shown on the same screen. If your team keeps several versions open at once, this quick check helps you avoid validating the wrong release. Pay close attention to the version status. A version marked as draft, in review, approved, published, or archived can behave differently when you try to share it or include it in an export process. If you already worked through visibility setup in [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access), use that as your baseline and focus here on confirming the final state of the exact version in front of you. Next, review the version’s visibility area. Look for the section that shows whether access is controlled by audience settings, reader restrictions, or public availability. You want to confirm the current access mode before you test links, previews, or export options. A version that is visible only to selected readers should not be validated the same way as a version intended for public documentation. It also helps to decide the destination before you continue. In practice, most checks fall into one of these paths: | Destination | What to confirm first | |---|---| | Internal readers | Audience and reader visibility | | External readers | Public or limited-access settings | | Public link | Public visibility and published state | | Export workflow | Export eligibility and included content | [SCREENSHOT: Version details page showing version title, version identifier, status, and visibility section] ## Checking audience targeting and reader visibility rules Once you have the correct version open, move to the area where Atloria shows visibility or audience settings for that version. Review every audience, team, group, or role currently assigned. Do not assume the settings are correct because a previous version used the same audience. Even small differences between versions can change who can open the content. Compare the assigned audience list with the people who are actually meant to receive the version. For example, if the version is meant for internal contributors only, make sure it is not also available to broader public readers. If it is meant for a customer-facing release, confirm the intended audience is included and any internal-only audience is excluded. This is especially important when a version is being prepared for public sharing or export, because the wrong audience setting can expose content too widely or block the right readers entirely. Also review whether the version inherits restrictions from a higher level in Atloria, such as the project or another parent area that controls access. A version can look correctly configured on its own screen but still be limited by broader visibility rules. If the version is unexpectedly hidden, inherited restrictions are one of the first things to check. Finally, verify the public access state. If Atloria shows that public access is disabled, limited, or enabled, make sure that setting matches your intended use. For example: - **Disabled** fits internal-only review. - **Limited** fits controlled sharing with selected readers. - **Enabled** fits public documentation access. [SCREENSHOT: Visibility or Audience settings panel showing assigned audiences and public access state] If anything looks unfamiliar, stop here and correct the audience setup before you test with reader accounts. Access validation is only useful when the underlying visibility rules match the release plan. ## Testing access as the readers who will receive the version After reviewing the settings, test the version from the reader’s point of view. In Atloria, use any available preview or reader-view option on the version screen to see how the content appears outside the editing context. The goal is not just to confirm the page opens, but to confirm the right people can discover and use it the same way they will after sharing. 1. Open the version in preview or reader view. 2. Check the page title, navigation, and visible content sections. 3. Confirm the version appears as expected for the intended audience. 4. Repeat the test with representative reader accounts if your team uses different access levels. 5. Try both normal navigation and a direct link to the version. When possible, test with real examples from each audience you plan to support. That may include an internal contributor, a project administrator, or an external viewer. You do not need to test every single person individually, but you should test enough account types to confirm the visibility rules behave correctly across roles. Do not rely on only one entry point. A version may be hidden from navigation but still open from a copied link, or it may appear in search but not in the expected menu. Check all of the following if they are available in your Atloria workspace: - Search results - Navigation lists - Version lists - Direct-link access Just as important, test the blocked experience. Readers who should not have access should see the expected restricted or access-denied result. If a restricted account can still open a bookmarked link, your visibility setup is not ready. [SCREENSHOT: Reader preview of a version with navigation and page content visible] ## Verifying the version is ready for public sharing or export workflows Before you click any share or export action, open the share dialog or export panel for the version and confirm that Atloria allows the action you intend to use. If the option is unavailable, that usually means the version does not yet meet one or more release conditions. Check the current status shown on the version page and compare it with your team’s release process. 1. Open the version’s **Share** or **Export** area. 2. Confirm the intended action is available. 3. Review the version status and approval state. 4. Check whether required metadata is complete. 5. Verify included content before sending or exporting. For public sharing, confirm the version is in the right state for external access. If your team requires approval before public release, make sure that approval is already recorded. For export workflows, verify that any required labels, version details, or release information used in exported output are complete on the version record before you continue. Also review everything the version depends on. A version may look correct on screen while still containing attachments, embedded items, or linked pages that are not available to the same audience. If exported output is part of your workflow, confirm those items are included correctly and will not disappear for the recipient. Use this final check before proceeding: | Item to verify | What to look for | |---|---| | Share option | Available for the current version | | Status | Matches your release stage | | Approval | Completed if required | | Metadata | Filled in where needed | | Attachments and linked content | Accessible or included in export | [SCREENSHOT: Share or Export panel showing available actions for the selected version] This is the point where you confirm not only that the version can be shared, but that it will reach the right audience in the right form. ## Recording and approving the final access check A final access check is much easier to trust when it is documented. After testing the version in Atloria, record the result in the version’s review notes, approval area, or whichever release-tracking space your team uses. Keep the record tied to the exact version so anyone reviewing the release later can see what was checked and when. Include the details that matter for future review. At minimum, note the version name or number, the audiences you confirmed, the reader account types you tested, and the date of the check. If your team uses approval markers or release statuses, update them at the same time so the version clearly shows that access validation is complete. A useful record usually includes: - The exact version reviewed - The intended audience or sharing target - Which reader views were tested - Whether direct-link access was checked - Whether restricted readers were blocked correctly - The date of validation - The name of the person who performed the check If Atloria supports comments or sign-off notes in your version workflow, add a short note describing the outcome. Keep it specific, such as confirming that the published version was visible to the intended audience and hidden from non-target readers. Avoid vague notes like “looks good,” which do not help during later audits or release reviews. Screenshots can also help. Capture the visibility settings, audience assignments, and at least one successful reader-view test. If your team needs release evidence, these images make it easier to show that the version was checked before sharing or export. [SCREENSHOT: Version review area with status, notes, and approval markers] A repeatable record keeps each release consistent and reduces confusion when multiple people handle approvals. ## Fixing visibility problems before sharing or exporting If your validation check uncovers a problem, fix it before sending the version anywhere. The safest approach is to return to the version details page, review the visibility settings again, and correct the issue at the source rather than trying to work around it with a copied link or manual explanation. When the version is not visible to the intended audience, first recheck the assigned audiences and any broader project-level restrictions that may still be limiting access. Also confirm the version is in the right status. A draft or archived version may not be available in the same way as a published version, even if the audience settings look correct. If readers can open a direct link but cannot find the version in search or navigation, review how the version is listed. In Atloria, visibility is not always the same as discoverability. A version may technically be accessible while still missing from the places readers expect to browse. Check the navigation placement, listing behavior, and whether the version is appearing in the correct version or documentation lists. If the public share or export action is unavailable, open the version again and confirm it meets the required conditions. Common blockers include the wrong status, missing approval, or missing release details needed for the selected workflow. If your role does not have access to the action, you may also need someone with the right permissions to complete the step. If exported output is missing content, review every attachment, embedded item, and linked page included in the version. Missing content often points to one of two issues: - The item is not available to the same audience as the version - The item is not being included in the export result [SCREENSHOT: Version settings area highlighting visibility, status, and share/export availability] Do not move forward until the version behaves correctly for both allowed and blocked readers. A clean validation result is more important than rushing the release. ## Overview This guide focuses on the final checks you perform in Atloria before sharing a documentation version with readers or using that version in an export workflow. It assumes you have already set up the intended visibility and audience rules and now need to confirm that those settings work in practice. If you still need to configure the access rules themselves, return to [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) before continuing. The validation process in Atloria centers on four things: - Confirming you selected the correct version - Reviewing audience and visibility settings - Testing the version as real readers will experience it - Verifying the version is eligible for sharing or export This is an important step because version access is not just about whether a page opens. A version can be visible in one place and hidden in another, or available to the wrong audience through a direct link. It can also appear ready for export while still containing linked content that recipients cannot access. By checking the version from multiple angles, you reduce the risk of sending incomplete, restricted, or overly broad documentation to the wrong audience. You will also use this guide to create a clear record of the final access review. That record is useful for approvals, release coordination, and later audit or governance checks. In teams where several people work on documentation versions, a documented validation step helps everyone understand whether a version is truly ready to leave the project workspace. [SCREENSHOT: Documentation version page in Atloria with status, visibility, and share actions visible] After you complete these checks, the next step is [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness), where you move from validation into the actual sharing and export decision process. ## Prerequisites Before you start this validation process in Atloria, make sure the version is far enough along in the release cycle to be meaningfully checked. You do not need every downstream action completed, but you should have enough information on the version screen to confirm visibility, audience targeting, and sharing readiness. You should have the following in place: - Access to the project and the version you plan to validate - A version that already has its visibility or audience settings configured - Enough permission in Atloria to open the version details page and view sharing or export options - A clear understanding of who the version is intended for, such as internal readers, selected external readers, or public readers - At least one test account or representative reader type to use during access checks, if your team validates with separate accounts It also helps if the version already has its current status assigned, such as draft, approved, published, or archived, because that status affects what you can validate. If your team uses approvals, review notes, or release sign-off steps, have those areas ready so you can record the result immediately after testing. Before beginning, confirm these supporting items as well: | Needed before validation | Why it matters | |---|---| | Correct version selected | Prevents checking the wrong release | | Audience settings already defined | Gives you real access rules to test | | Reader targets identified | Lets you compare expected vs actual visibility | | Share or export goal decided | Changes which checks you need to perform | If any of these pieces are missing, pause and complete them first. Validation works best when you are checking a real release candidate rather than an unfinished version setup. ## Opening a version comparison page To work with a comparison view in Atloria, start in the **Versions** area for the project or document set you are reviewing. You should be able to open both in-progress and approved versions from the version list. If you cannot see the version you need, stop there and confirm that your account can view versions that are still under review as well as versions that have already been approved. 1. Open the project in Atloria and go to the **Versions** list. 2. Find the version you want to review. Use the visible version label and any status badge shown in the list to make sure you are opening the correct release candidate. 3. Open that version, then choose the **Compare** action from the version page. 4. On the comparison page, use the version selectors to choose: - the **baseline** version, which is the version you are comparing from - the **target** version, which is the version you are reviewing 5. Confirm that the selected versions match the review you intend to perform before you start reading changes. [SCREENSHOT: Version list with a selected version and the Compare action highlighted] The comparison page is only useful if the selected versions reflect the real review scenario. In most release reviews, the baseline should be the last approved version, and the target should be the new version under review. If you compare two drafts, you may still see useful differences, but that view may not be appropriate for a final approval decision. Pay attention to the status badges shown near each selected version. A version marked as **Draft** may still be changing. A version marked as **Approved** is usually the better baseline for release review. If the page shows that you are comparing a draft against another draft, treat the results as a working review rather than final approval evidence. For background on how those statuses affect release readiness, refer to [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness). ## Reading the differences between two versions Once the comparison page opens, focus first on how Atloria marks changes. The page is designed to help you spot what was added, removed, or edited without rereading every page from top to bottom. Look for highlighted text, change markers beside sections, and any visual labels that show whether content is new, deleted, or modified. In many comparisons, Atloria presents content in two panes so you can read the earlier version and the newer version side by side. This layout is best when you need to understand wording changes in context, such as a revised instruction, a renamed heading, or an updated note. In other cases, the page may present a more compact change view that groups edits together. Use whichever layout is available on the page to answer a simple question: what changed, and does that change affect meaning? The comparison header is also important. Before reviewing the body of the page, check the visible version details shown at the top. These commonly include the version name or number, the current approval status, and the most recent update details. If Atloria shows who last edited the version or when it was modified, use that information to understand whether a change is recent and whether it may have happened after an earlier review. When reading a changed section, separate content changes from presentation-only changes. A changed heading, paragraph, link, or embedded asset usually points to a meaningful documentation update. By contrast, a small formatting adjustment may not affect release readiness. If the comparison highlights a whole block, read the actual text inside that block before deciding how important the change is. [SCREENSHOT: Comparison page showing highlighted additions, removals, and edited sections] ## Checking changed pages and sections before approval Before approving a version, narrow your review to the pages that actually changed. In Atloria, this usually means using the comparison navigation or any **changed only** option available on the comparison page. That keeps your attention on pages that differ from the selected baseline instead of forcing you to scan the full document set. 1. Turn on the view that shows **changed pages only** if that option is available. 2. Use the page list or comparison navigation panel to open each changed page one by one. 3. On each page, review the section-level markers to find changed headings, body text, tables, links, and media. 4. Compare those sections against the baseline version and confirm that the update is complete. 5. Repeat until every changed page in the navigation has been checked. [SCREENSHOT: Comparison navigation panel listing only changed pages] This review is especially important for release-specific content. Check pages that usually change during a release, such as release notes, setup instructions, policy or process pages, and reference content. If your team maintains technical or reference-heavy documentation in Atloria, make sure those pages reflect the intended release scope and do not contain partial updates. As you move through changed pages, watch for unintended removals. A deleted navigation entry, a missing cross-link, or a removed content block can be easy to overlook in a broad review. Give extra attention to sections that require approval, pages that are frequently reused across versions, and content that readers depend on to move through the documentation correctly. If a page appears in the changed list but the update looks incomplete, do not rely on the version summary alone. Open the page and inspect the marked sections directly. The goal is not just to confirm that something changed, but to confirm that the right material changed and that nothing essential disappeared. ## Using comparison results to support release decisions A comparison page is most useful when you treat it as review evidence, not just a reading tool. Start with the change summary at the top of the comparison page, if one is shown. A small, focused set of updates may support a quick approval decision. A large number of changed pages, especially across core documentation areas, may signal that the version needs a deeper review before anyone signs off. When you evaluate readiness, combine three things on the screen: the visible differences, the version status, and any reviewer comments attached to the version workflow. A version may look complete in the comparison view, but if the status still shows **Draft** or if review feedback is unresolved, it may not be ready for approval. In the same way, a version with only a few changes still needs those changes to match the release plan. Use the comparison to confirm that expected updates are present. For example, if the release should include updated release notes, revised setup steps, and changes to linked pages, verify each of those items in the comparison before making a decision. If one of those expected updates is missing, the version may need revision even if the rest of the content looks correct. During review meetings or approval discussions, make sure everyone is looking at the same comparison. Share the comparison page directly inside Atloria or reference it during the discussion so Documentation Managers, Technical Writers, and Project Administrators are reviewing the same baseline and target versions. That avoids confusion caused by people comparing different drafts. For related guidance on broader comparison and release evaluation, see [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions) and [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions). ## Comparing versions efficiently across review cycles As review cycles repeat, efficiency matters. In Atloria, the fastest way to get a reliable final review is usually to compare the current version against the last **Approved** version rather than against another draft. That gives you a clean view of what will actually change for readers if the new version is released. 1. Set the baseline to the most recent **Approved** version. 2. Set the target to the version currently under review. 3. Turn on page filters or changed-only navigation so unchanged pages drop out of view. 4. Review section markers on each changed page instead of rereading the full document set. 5. Check version details such as modified date and editor information before final sign-off. This approach helps you catch late edits. If a version was reviewed earlier and then updated again, the modified date and visible editor details can show that the content changed after the previous review round. When that happens, revisit the affected pages instead of assuming the earlier review still covers the current version. For large document sets, move page by page through the changed navigation rather than scrolling through the entire comparison. This is especially useful when the release touches many areas but only a few sections on each page. Section markers let you jump directly to the changed content and decide whether the update is acceptable. If a change has a high impact, such as a rewritten workflow, a removed navigation path, or a major release note update, capture a screenshot for discussion or direct teammates to the exact comparison page in Atloria. [SCREENSHOT: High-impact difference highlighted in a comparison view for review discussion] The next step in this workflow is [Managing Project Version Workspaces](doc:managing-project-version-workspaces), where you will work with the broader space around each version rather than the comparison view alone. ## Fixing common problems in version comparison views If a comparison page is not showing what you expect, start with the version selectors at the top of the page. Many comparison problems come from reviewing the wrong pair of versions rather than from missing content. 1. If no differences appear, check whether the baseline and target selectors are set to the same version. 2. If expected pages are missing, confirm that those pages were included in the target version you selected. 3. If you cannot complete an approval-related action, check the version status badge and confirm that the version is not still in **Draft**. 4. If the page is difficult to read, switch to the available comparison layout or use the changed-pages navigation to review one page at a time. If a page you expected to review does not appear in the comparison, return to the version details and confirm that the page is part of that version’s release scope. A page that was not included in the target version will not appear as a changed item, even if you expected it to be updated. If approval decisions are unavailable from the workflow around the comparison page, look at the visible status first. Atloria may allow you to compare versions that are still being prepared, but those comparisons do not always support final review actions. You may also need the right review or approval access before decision controls appear. When the difference view feels too dense, avoid scanning the whole page at once. Open the changed-items list, select one page, and review the marked sections in order. This is often the easiest way to separate meaningful content edits from small formatting changes. For help with status-related blockers, return to [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness). For approval-specific follow-up, see [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up). ## Overview Version comparison views in Atloria help you answer a specific review question: what changed between one documentation version and another, and are those changes ready to move forward? You use this page when a version is being reviewed for approval, when a release candidate needs validation against the last approved version, or when teammates need a shared view of edits across pages. The comparison page is centered on two selected versions: a baseline and a target. Atloria then highlights the differences between them so you can review changed pages, inspect section-level edits, and confirm whether the new version includes the updates expected for the release. This is especially useful when a version contains many pages and only some of them changed. A comparison view is not the same as a full version workspace. It is a focused review screen for examining differences. If you need to understand how statuses move through the release cycle, use [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness). If you need to work with the broader version area after comparison, the next document in this sequence is [Managing Project Version Workspaces](doc:managing-project-version-workspaces). Use comparison views when you need to: - review changed pages against an approved baseline - confirm that release notes and related updates are present - spot unintended removals before approval - support approval discussions with visible evidence - check whether late edits were introduced after an earlier review [SCREENSHOT: Version comparison page showing baseline selector, target selector, and changed page navigation] ## Prerequisites Before you start comparing versions in Atloria, make sure the basic review conditions are already in place. Comparison views are most useful when the version list is organized and the release stage is already understood. You should have: - access to the project and its **Versions** area - permission to open the versions you need to compare, including versions that are still under review and versions that are already approved - at least two available versions to compare - a clear understanding of which version should be the baseline and which should be the target - enough familiarity with the release stage to know whether the comparison is for working review or final approval It also helps if you already know the version statuses used by your team. If you are unsure when to compare a draft to an approved version, review [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) before continuing. Use this quick check before opening the comparison page: | What to confirm | Why it matters | |---|---| | The correct project is open | Version lists are project-specific | | The baseline version is identified | This gives you a reliable reference point | | The target version is identified | This is the version you are evaluating | | The version status is visible | Status affects whether the comparison supports approval | | The release scope is known | You can verify whether expected pages changed | If you are still preparing the version itself rather than reviewing its differences, start with [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) or [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). ## Opening a Published Documentation Site When you open a published Atloria documentation site, you are in a public reading view rather than an editing workspace. You do not need to sign in just to browse published pages. The screen is built for reading, so the main things to look for are the page title, the navigation areas, and the article content itself. Most published documentation views in Atloria are easy to recognize because the page is arranged around a few clear reading regions: - A **top navigation area** for moving between major sections - A **left-side navigation menu** or category list for browsing pages in the current section - A **main content area** where the full article appears - A **breadcrumb trail**, when available, showing where the current page sits in the structure A published site may first open on a landing page. A landing page usually introduces the documentation set and helps you choose where to start. It may contain a large title, short introductory text, and links into major sections. An individual documentation page is different: it focuses on one topic and shows the full article with headings and sections. Use the page title and opening paragraph to confirm you are in the right place. If you see article-style content, section headings, and public navigation menus, you are likely in the published documentation view. If you were expecting to read documentation but instead see project setup, admin areas, or editing tools, you are not on the public reading side. [SCREENSHOT: Published Atloria documentation page showing top navigation, left-side page list, breadcrumb trail, and main article content] If you need a refresher on basic public browsing before choosing pages in more detail, see [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content). ## Moving Through Categories and Navigation Menus The fastest way to browse a published Atloria site is usually the left-side navigation. This area groups pages into sections so you can move from broad topics to more specific ones without opening every page one by one. 1. Start with the **left navigation menu** and look for section names that match your goal. These might represent broad topic areas such as getting started, project work, publishing, or reader help. 2. If a section contains subtopics, expand that group to reveal the pages underneath it. This helps you narrow the list before opening an article. 3. Collapse groups that are not relevant so the menu becomes easier to scan. 4. Click a page title to open it in the main content area. 5. If the site includes several major published areas, use the **top navigation links** to switch between them before returning to the left-side menu. As you move around, pay attention to visual cues that show your current location. Atloria commonly highlights the page you are reading in the navigation menu. The parent category may also appear active or expanded, which helps you understand the section you are currently inside. This is especially useful when several pages have similar names. For example, a page listed under a setup section usually serves a different purpose than a page with a similar title under a troubleshooting or policy section. The category around the page title gives you important context before you even open it. When the menu feels crowded, do not try to read every title at once. Focus first on the category labels, then on the smaller list of pages inside the section that looks most relevant. That approach is usually faster than scanning the entire navigation tree from top to bottom. [SCREENSHOT: Left-side navigation with one category expanded, one collapsed, and the current page highlighted] ## Choosing the Right Page to Read Finding the right page in Atloria is mostly about matching your task to the page title and its place in the documentation structure. Before opening several pages at random, compare the titles in the navigation menu and look for wording that matches what you are trying to do. 1. Read the **page titles** in the current category and look for direct task language. Titles that begin with words like “Creating,” “Managing,” “Using,” or “Reviewing” are often task-focused pages. 2. Use the **category name** to judge the page’s purpose. Pages near the top of a section are often introductory, while lower or nested pages are more specific. 3. Open the page that seems closest to your goal. 4. Scan the **page heading**, the first paragraph, and the visible section headings. 5. If the page is too broad, too advanced, or about a different workflow, return to the navigation menu and choose a nearby page in the same section. This quick scan saves time. In many cases, the opening paragraph tells you whether the page is about setup, day-to-day use, administration, or published reading. The section headings help even more. If you are looking for instructions and the page only shows background information, move on quickly. Breadcrumbs are also helpful here. If the breadcrumb path shows that the page sits under the wrong branch, you can tell immediately that you may have landed in a related but different topic. For example, a page under a broad reader section may not answer the same question as a page under a project-specific section. A good habit is to compare three things together before settling on a page: - The **page title** - The **category or parent section** - The **visible section headings** inside the article When all three line up with your task, you have probably found the right page. ## Orienting Yourself While Reading a Page Once you open a page, staying oriented matters just as much as finding it. Atloria gives you several clues that help you understand where you are in the documentation and how the current article relates to the rest of the site. 1. Check the **page title** at the top of the article to confirm the topic. 2. Look at the **breadcrumb trail**, if shown, to see the path from the broader section to the current page. 3. Glance at the **left navigation menu** and note which page is highlighted and which category is expanded. 4. Use the article’s **section headings** to understand how the content is organized before reading every paragraph. 5. If a **table of contents** or heading list appears on the page, use it to jump directly to the section you need. These elements work best together. The page title tells you what you are reading now. The breadcrumb trail tells you how you got there. The highlighted navigation item shows what sits next to it in the same section. When all three point to the same topic branch, you can read with confidence that you are in the right place. For long pages, do not rely only on scrolling. Instead, pause at the heading structure. Headings break the article into smaller tasks or concepts, so you can skip directly to the part that answers your question. This is especially helpful when a page covers both basic and advanced material. If the article turns out to be too broad, use the side navigation to move to a neighboring page in the same category. If it is too advanced, go up one level through the breadcrumb trail or choose a more introductory page nearby. [SCREENSHOT: Documentation page with breadcrumb trail above the title and a table of contents or visible section headings] ## Using Search and Page Context to Find Answers Faster When browsing by category is too slow, use the search field if the published Atloria site provides one. Search works best when you enter the exact feature name, a clear task phrase, or the page title you expect to find. 1. Click the **search field** and enter a specific term. 2. Start with the most obvious wording, such as a feature name or task name. 3. Review the **search results list** and compare the page titles. 4. Use the short surrounding text shown with each result to tell similar pages apart. 5. Open the most likely result and confirm it by checking the page heading, category placement, and nearby navigation items. Search results are most useful when you read them in context. A familiar title alone is not always enough, especially if several pages use similar words such as “managing,” “using,” or “reviewing.” The surrounding text often reveals whether the page is about setup, navigation, permissions, publishing, or another workflow. If your first search returns too many results, make the wording more specific. Instead of searching for a broad word like “version,” try a phrase such as “version visibility” or “review status.” If you know the exact wording used in Atloria’s navigation or page titles, use that wording in the search box. You can also combine search with navigation. After opening a result, check the left-side menu to see what related pages sit above and below it. Sometimes the result gets you close, and a neighboring page in the same section turns out to be a better match. This approach is often faster than repeating new searches over and over, especially when you already know the general topic area but need the exact page. ## When You Cannot Find the Page You Need Sometimes the issue is not that the page is missing, but that you are looking in the wrong published site area or following the wrong topic branch. When that happens, use the visible page context in Atloria to reset your path instead of continuing to click deeper at random. - Check the **site title** and the **top-level navigation labels** first. These help confirm that you are browsing the correct published documentation set. - Look at the **breadcrumb trail** to see whether the current page belongs to the topic branch you expected. - Review the **highlighted page** and its surrounding items in the left navigation. Related pages are often grouped together under the same parent section. - Try a nearby category if the page is not where you expected. Some task pages are filed under a broader section rather than under the exact feature name you had in mind. - Use both **navigation browsing** and **search**. Some readers find pages faster by scanning categories, while others find them faster by entering the page title or task phrase. If a link opens an unexpected page, do not start over from the beginning right away. First, use the breadcrumb trail to move up one level, then review the expanded category in the side navigation. That usually shows whether you are close to the right page or in the wrong section entirely. It also helps to compare the current page’s title with the titles around it. If the neighboring pages all focus on a different kind of task, switch categories rather than continuing in the same branch. When you need a broader understanding of how public sections are organized before drilling into individual pages, continue with [Managing Reader Navigation in Published Documentation](doc:managing-reader-navigation-in-published-documentation). ## Overview This guide focuses on the public reading experience in Atloria and shows how to move from opening a published documentation site to identifying the exact page you need. The main idea is simple: use the visible reading tools on the page together instead of relying on only one of them. Key parts of the published reading view include: - The **top navigation** for moving between major published areas - The **left-side navigation** for browsing categories and page lists - The **main article area** for reading the selected page - The **breadcrumb trail** for understanding where the page sits in the documentation structure - The **search field**, when available, for finding pages by title, feature, or task This document does not repeat the basics of public browsing already covered in [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content). Instead, it focuses on what to do after you have reached a published documentation site and need to choose the right page quickly. Use this guide when you want to: - Tell the difference between a landing page and a full article page - Browse categories without getting lost in a long navigation tree - Confirm whether a page matches your task before reading the whole article - Stay oriented inside long pages using headings, breadcrumbs, and highlighted navigation - Recover when a link or search result takes you to the wrong place The most effective reading pattern in Atloria is to combine title, category, and page structure. If the page title matches your task, the category matches your topic, and the section headings match your question, you are usually on the right page. ## Prerequisites Before using the steps in this guide, make sure the following are true: - You have access to a **published Atloria documentation site** - You can open the site in your browser and view public pages - You want to **read documentation**, not edit project content or manage internal workspace settings - You are comfortable using common page elements such as menus, links, and search fields You do not need to sign in just to browse published documentation. This guide is written for readers using the public documentation view. It helps if you already know one of the following: - The general topic you want to read about - A feature name used in Atloria documentation - A task phrase that matches what you are trying to do - Part of the page title you expect to find If you are still learning how public navigation works at a basic level, review [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content) first. That guide explains how public-facing navigation behaves when documentation is organized for different reader groups. You may also find this guide easier to follow when the published site includes these visible elements: | Page element | Why it helps | |---|---| | Top navigation | Lets you switch between major published sections | | Left-side navigation | Shows categories and page groupings | | Breadcrumb trail | Helps you understand the current page’s location | | Search field | Speeds up page discovery when browsing is too slow | If one of these elements is not shown on a particular published site, you can still use the same approach by relying on the page title, nearby navigation items, and section headings inside the article. ## Opening the screenshot tool and preparing a capture session If you already know how to capture from a live page, use this guide to focus on the documentation workflow around website-based captures. For the earlier browser capture flow, see [Capturing Screenshots from Web Pages](doc:capturing-screenshots-from-web-pages). In Atloria, start from the screenshot capture area used for documentation work. On this screen, look for the main working parts before you begin: - a **URL** input field where you enter the page address - a capture button such as **Generate Capture** - a results or preview area where the image appears after processing [SCREENSHOT: Website screenshot capture screen showing the URL field, capture button, and preview area] Before you enter anything, decide exactly what page you are documenting. This matters because the screenshot should match the page your readers will actually see. If the page is public, make sure the public version is the one you want to show. If the page depends on being signed in, confirm that your browser session is already on the correct account and that the right screen is open in that session. It also helps to confirm the page is stable. Avoid capturing pages that still show draft content, temporary notices, or unfinished layout changes. If you are documenting a released feature, open the final page first and check that the text, menus, and visible actions are correct. Choose the purpose of the capture set before generating images. In most documentation work, you will usually be aiming for one of these: - a full-page reference image - a focused image for a feature explanation - a sequence of screenshots for step-by-step instructions Making that decision early helps you judge whether the result area shows the right amount of content and whether you need another capture. ## Entering the website URL and starting the capture 1. Click inside the **URL** field on the screenshot capture screen. 2. Paste or type the full website address for the page you want to capture. If the address needs the full format, include the protocol, such as `https://`, so Atloria opens the exact page you expect. 3. Read through the address once before you continue. Small mistakes often lead to the wrong screenshot. Pay close attention to: - missing page sections after the main domain - the wrong environment, such as a staging page instead of the live page - extra query details that change what appears on the page - copied links that open a filtered or temporary state 4. When the address looks correct, click **Generate Capture**. 5. Watch the screen after you start the capture. Atloria should show an in-progress state while it loads the page and creates the image. Wait for that process to finish before deciding whether anything went wrong. [SCREENSHOT: URL entered in the field with the Generate Capture button highlighted] If the page takes a moment to appear, that does not always mean the capture failed. Some pages need extra time to load visible content. What matters is whether the preview area updates and eventually shows the finished result. This is also the best time to confirm you are capturing the right version of the page. If you notice the address points to a test page, a preview page, or a link with temporary state information, stop and correct it before generating another image. That saves time later when you begin saving and organizing approved screenshots for your documentation set. ## Reviewing the generated screenshot results 1. Go to the preview or results area as soon as Atloria finishes the capture. 2. Check that the screenshot shows the correct page. Start with the obvious details: - page title or heading - visible navigation - main content area - buttons, tabs, or panels you expected to appear 3. Look at what is included in the image. Decide whether the result matches your documentation goal: - For a reference image, confirm the full page is visible. - For a task image, confirm the important controls are readable. - For a feature callout, confirm the relevant section is clearly present and not buried in unrelated content. 4. Review the page state carefully. Watch for banners, pop-up messages, cookie notices, open menus, or modal windows that may distract readers or make the screenshot outdated quickly. 5. If Atloria shows more than one result, compare them before saving. You may see repeated attempts or refreshed outputs. Keep the version that best matches the screen you want readers to recognize. [SCREENSHOT: Generated screenshot preview with the results area visible] A good preview should feel familiar to anyone who later visits that page. If the image shows the wrong account context, an unexpected navigation state, or content that is still loading, it is better to rerun the capture than to fix the problem later in your guide. If the result is close but not quite right, return to the source page first. Clean up the page state, close anything temporary, and then generate the capture again. That usually produces a better documentation image than trying to work around a poor source capture. ## Saving screenshot files for documentation work 1. In the results area, find the control used to keep the image. Depending on the screen, this may appear as **Save**, **Download**, or another export-style action next to the generated screenshot. 2. Click that control and store the file in a location you can find easily while writing. If you are working on a specific guide or release, save it directly into that folder instead of a general downloads location. 3. Give the file a clear name before you move on. Avoid generic names that make later review difficult. A useful filename usually describes the product area and the page shown, such as a feature name plus the screen name. 4. Open the saved image outside Atloria and compare it with the preview. Make sure the file matches what you saw in the results area and that the image opens normally. 5. Place the file into an organized folder structure that fits your documentation workflow. A simple folder approach works well for most teams: - by guide - by feature area - by release or version - by approved versus draft images [SCREENSHOT: Saved screenshot file being downloaded from the results area] Clear naming becomes especially important when several people write or review the same documentation set. A filename that reflects the page topic is much easier to reuse than a default image name. If you manage screenshots across multiple projects in Atloria, keep your saved files grouped in the same way your documentation is grouped. That makes it easier to match a screenshot to the correct page later, especially when you are preparing version-specific content or reviewing images before publishing. ## Preparing captured images for documentation pages 1. Open the saved screenshot in your usual image editing tool. 2. Crop the image so the important part of the screen stands out. Keep enough surrounding area for readers to understand where they are, but remove empty space or unrelated sections that do not support the step. 3. Remove anything that should not appear in published documentation. Common examples include: - browser bars and tabs - personal account details - temporary alerts or notices - unrelated pop-ups or overlays 4. Check the size and shape of the image against other screenshots in the same guide. When screenshots use similar dimensions and framing, the page feels more consistent and easier to follow. 5. Rename the final image file so it matches the topic or task in your documentation page. [SCREENSHOT: Cropped documentation image focused on the relevant page area] When you prepare screenshots for Atloria documentation, think about what the reader needs to recognize immediately. If the image supports a step about clicking a specific button, that button should be easy to spot. If the image introduces a full screen, keep enough of the page layout visible so readers can orient themselves. Consistency matters more than perfect precision. If one screenshot is tightly cropped and the next includes the full browser window, the guide can feel uneven. Try to use the same style throughout a page or section so readers can move from one step to the next without reinterpreting each image. ## Common issues and how to fix them If a capture does not look right, start with the simplest explanation: the page address or page state may not match what you intended. - **The capture shows the wrong page** - Recheck the **URL** field for missing page sections or the wrong domain. - Make sure you did not paste a link that redirects somewhere else. - Confirm you are using the correct live, preview, or project-specific page. - **The screenshot is blank or incomplete** - Open the target page directly in your browser and make sure it loads fully. - Check whether important page content appears only after the page finishes rendering. - If the page still looks unfinished, wait until the visible content is stable and try **Generate Capture** again. - **The saved file does not match the preview** - Return to the results area and confirm the preview has fully updated. - Generate the capture again, then save it one more time. - Open the new file immediately after saving so you can verify it before continuing. - **The image is not suitable for documentation** - Close overlays, banners, or temporary messages on the source page. - Navigate to the exact screen you want readers to see. - Rerun the capture after cleaning up the page state. [SCREENSHOT: Example of a poor capture with an overlay or wrong page state] If you continue having trouble, compare the source page and the preview side by side. In most cases, the issue becomes obvious once you check the page address, the visible screen state, and whether the capture finished updating before you saved it. ## Overview This workflow in Atloria is for creating documentation-ready screenshots from a website address rather than capturing a page manually as you browse. You enter a page address in the **URL** field, start the process with **Generate Capture**, review the image in the results area, and then save the file for use in your documentation. This approach is most useful when you want repeatable, page-based screenshots for guides, release notes, feature walkthroughs, or public documentation pages. It works especially well when you need a clean image of a known page and want to confirm the result before downloading it. The overall flow is straightforward: - open the screenshot capture screen - enter the correct website address - generate the screenshot - review the preview carefully - save the image file - prepare the image for placement in a documentation page Because documentation images often stay visible for a long time, accuracy matters more than speed. A screenshot should reflect the exact page, the correct navigation state, and the version of the content your readers are expected to use. That is why Atloria’s preview area is an important part of the process: it lets you confirm the image before you save and distribute it. This guide focuses on website-based capture and the immediate steps that follow it. It does not repeat the earlier browser capture basics covered in [Capturing Screenshots from Web Pages](doc:capturing-screenshots-from-web-pages). After you finish generating and checking your images, continue to [Saving and Organizing Captured Screenshots](doc:saving-and-organizing-captured-screenshots) for the next part of the workflow. ## Prerequisites Before you start capturing website screenshots in Atloria, make sure a few basics are already in place. This will help you avoid redoing captures later. - You can sign in to Atloria and reach the screenshot capture area. - You know the exact page you want to document. - You have the correct website address for that page. - The page is fully loaded, published, and visually stable. - If the page depends on being signed in, your browser session is already using the correct account and access level. - You know the purpose of the screenshot, such as a full-page reference image, a focused feature image, or a step-by-step illustration. It is also helpful to prepare for file handling before you begin: - choose the folder where you will save the image - decide on a naming style for the file - know which guide, feature, or release the screenshot belongs to If you are working with a team, align on what should appear in the image before you generate it. For example, decide whether navigation menus, banners, or modal windows should be visible. That avoids situations where one reviewer expects a clean page while another expects the full working context. A quick final check can save time: open the source page once in your browser and confirm that the visible content matches what you want readers to see in the finished documentation. If anything looks temporary, incomplete, or personal to your account, correct that first and then return to the **URL** field in Atloria to begin the capture. ## 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. ## Understanding How Screenshot Workflows Span Enterprise, Projects, and Versions In Atloria, screenshot work does not live in just one place. Teams usually work across three connected layers: the enterprise screenshot library, project-level screenshot collections, and documentation versions inside each project. The enterprise library is where broadly reusable, approved screenshots are kept for shared use. Project screenshot collections hold images that belong to one project workspace. Version-specific screenshot use matters when a page for one release needs a different image than another release, even if both pages cover the same feature. A typical workflow starts when you open the screenshot workflow area and create or upload a screenshot for a specific project and documentation version. During that process, you add details that help other writers find and trust the image later. After upload, the screenshot moves into review, where a reviewer checks whether the image matches the current interface, version, locale, and page context. Once approved, the screenshot can be inserted into documentation pages and reused where appropriate. If the interface changes later, a replacement screenshot can be linked so the older image stays available for older versions while the newer one becomes current. Ownership depends on where the screenshot is saved and how it is approved. An enterprise-approved screenshot may be reused across multiple projects if the screen is identical. A project-owned screenshot is usually tied to that project’s content and release cycle. If a version introduces a changed layout, wording, or navigation path, that version may need a new capture instead of reusing the existing one. The most useful fields to keep accurate are: | Field | What it helps you track | |---|---| | Product area | Which part of Atloria the screenshot shows | | Project | Which project workspace uses the image | | Version | Which documentation release the image matches | | Locale | Which language or regional variant appears in the screenshot | | Status | Whether the image is pending review, approved, rejected, or superseded | | Replacement history | Which newer or older screenshot is linked to this one | If you need naming and library basics first, review [Organizing Screenshots for Documentation and Releases](doc:organizing-screenshots-for-documentation-and-releases). ## Capturing and Storing Screenshots for the Right Project Version When you capture or upload a screenshot in Atloria, start by choosing the correct context before you add the image. This is the step that keeps screenshots tied to the right documentation set instead of becoming hard-to-find files later. In the screenshot workflow screen, select the enterprise context if the image is meant for broad reuse, then choose the project workspace and the documentation version that the image belongs to. If you skip this and upload first, you increase the chance that the screenshot ends up in the wrong library or appears in the wrong search results. 1. Open the screenshot workflow area from your project workspace or screenshot library. 2. Select the target enterprise library or project collection. 3. Choose the correct project. 4. Choose the documentation version the screenshot should support. 5. Add the screenshot or start the capture process. 6. Fill in the asset details before saving. 7. Confirm the screenshot is stored under the selected project and version. [SCREENSHOT: Screenshot upload or capture screen showing enterprise, project, and version selectors] As you save the screenshot, record the details writers rely on later: - **Screen name** - **Feature area** - **Locale** - **Viewport** or **resolution** - Whether the image is **new** or a **replacement** for an existing screenshot Use clear, consistent titles so the screenshot is reusable later. Good labels usually combine the screen name, UI area, release number, and platform or viewport. The goal is not to make the title long, but to make it searchable. If your team documents multiple releases at once, version labeling is especially important because the same page title may exist in more than one release. Before leaving the screen, verify that the screenshot is attached to the selected project/version pair. If it is saved only at the enterprise level when it should be version-bound, writers may accidentally reuse it in the wrong release. ## Reviewing, Approving, and Replacing Screenshot Assets After a screenshot is uploaded, the next step is review. In Atloria, review status is what tells writers whether an image is ready to use, still waiting for approval, or should no longer appear in active documentation. The most common status flow is **Pending review**, **Approved**, **Rejected**, and **Superseded**. These labels are important because search results and page editors often depend on them when writers look for usable screenshots. 1. Open the screenshot record from the library or project collection. 2. Check the image against the intended project, version, locale, and screen name. 3. Compare it with the screenshot currently used in the published or active documentation version. 4. Update the **Status** field based on the review decision. 5. Add reviewer comments explaining the decision. 6. If the image replaces an older screenshot, link it as the replacement and mark the older image as **Superseded**. [SCREENSHOT: Screenshot detail view showing status, reviewer comments, and replacement history] When you compare a new screenshot with the current one, focus on what a reader would notice: changed labels, moved buttons, updated navigation, different page states, or language changes. If the screen is the same and only the file is newer, replacing the existing asset may be the right choice. If the screenshot only applies to one release, keep it version-specific instead of replacing the shared image. Reviewer comments matter because they explain why a screenshot was approved or rejected. Use the comments area to note issues such as outdated navigation, incorrect locale, wrong viewport, missing page state, or a mismatch with the current release. Those notes help the next writer avoid repeating the same mistake. Replacement history is just as important as the current status. Writers need to see which screenshot is current for the active version and which older screenshots remain archived for earlier documentation. That history makes it possible to update new docs without breaking older published versions that still rely on the earlier image. ## Reusing Approved Screenshots Across Projects and Documentation Versions Atloria makes screenshot reuse practical only when writers can quickly tell which images are safe to reuse. The best way to do that is by searching the screenshot library with filters instead of browsing manually. When you open the library, narrow the list by **Project**, **Version**, **Feature area**, and **Approval status**. If your team works in more than one language, include **Locale** in your search before you reuse anything. A screenshot can usually be reused across projects when it has already been approved at the enterprise level and the screen is visually identical in each project. This works well for shared Atloria interface areas that do not change by project. A project-specific variant is better when the screen includes project names, project settings, release-specific labels, or content that only exists in one workspace. A version fork is the right choice when one release introduces visible UI changes but older documentation still needs the previous image. When you reuse a screenshot, keep it linked to its original asset record rather than treating it like an unrelated copy. That source link helps everyone see whether the original image has been updated, deprecated, or replaced. If the source screenshot is later marked **Superseded**, writers using dependent pages can spot that change and decide whether their page also needs an update. [SCREENSHOT: Screenshot library search with filters for project, version, feature area, locale, and approval status] Before reusing any image, check three things carefully: - **Version compatibility**: the screenshot must match the release your page describes - **Locale**: labels and interface language must match the audience version - **UI changes**: even small layout or navigation changes can make a reused screenshot misleading Reusing screenshots saves time, but only when the image still matches the page exactly. If there is any doubt, create a version-specific screenshot instead of forcing reuse. ## Keeping Screenshot Libraries Organized for Writers and Managers A screenshot library only stays useful if teams fill in the same core fields every time. In Atloria, writers and managers should standardize the details that make screenshots searchable, reviewable, and safe to reuse. At minimum, every screenshot record should include a clear **Title**, **Project**, **Version**, **Locale**, **Status**, **Owner**, **Last reviewed date**, and **Source page**. When these fields are missing or inconsistent, approved screenshots become difficult to find and duplicate uploads become more common. | Field | Why it matters | |---|---| | Title | Helps writers identify the screenshot quickly | | Project | Separates project-owned images from shared assets | | Version | Prevents reuse across the wrong release | | Locale | Avoids mixing screenshots from different languages | | Status | Shows whether the image is ready for use | | Owner | Clarifies who should update or review the image | | Last reviewed date | Helps teams spot stale screenshots | | Source page | Shows where the screenshot is used | Library structure also matters. Keep enterprise-wide screenshots in a shared library for reusable, approved assets. Keep project-maintained screenshots in project collections so release-specific images stay close to the pages they support. This separation makes it easier to search confidently and reduces accidental reuse of project-only images in unrelated workspaces. Good governance usually includes: - Regular duplicate checks before approving new screenshots - Scheduled reviews of older screenshots using **Last reviewed date** - Marking replaced screenshots as **Superseded** instead of leaving them active - Removing retired screenshots from active documentation use while keeping their history for older versions Permission levels should also be clear. Technical Writers typically upload screenshots, add metadata, insert approved images into pages, and request replacements. Documentation Managers usually handle final approval decisions, replacement confirmation, cleanup of duplicates, and deletion of records that should no longer remain in the active library. If your team also works in the Admin area, see [Using the Admin Workspace](doc:using-the-admin-workspace) for broader workspace management context. ## Fixing Common Problems with Missing, Outdated, or Misassigned Screenshots When a screenshot seems to be missing in Atloria, start with search filters. Many “missing” screenshots are simply hidden because the current filters do not match the asset record. In the screenshot library, check **Project**, **Version**, **Locale**, and **Approval status** first. A screenshot marked **Pending review** or saved under a different version will not appear where you expect if your search is limited to approved assets for the current release. If a screenshot was saved to the wrong project or enterprise context, open the screenshot record and review its ownership details. Confirm whether it belongs in the enterprise library for shared reuse or inside a specific project collection. Also check that the screenshot is linked to the intended documentation version. Misassigned ownership is one of the main reasons writers reuse the wrong image or fail to find the right one later. Outdated screenshots can continue appearing in pages when the replacement chain is incomplete. If a newer screenshot exists but the older one still shows in documentation, verify three things: - The newer image is linked as the replacement - The older image is marked **Superseded** - The page is referencing the current approved screenshot rather than the archived one [SCREENSHOT: Screenshot record showing ownership, version, status, and replacement link fields] Duplicate screenshots are another common issue, especially when several writers capture the same UI state. Before publishing a new screenshot, compare its metadata with existing approved assets. Look at the **Title**, **Project**, **Version**, **Locale**, **Status**, and review history. If an approved screenshot already covers the same screen and release, reuse it instead of adding another copy. If the images look similar but one includes updated labels or layout changes, document that difference in the comments and keep the records clearly separated. For deeper troubleshooting around search, reuse, and availability, continue with [Troubleshooting Screenshot Availability Across Projects and Versions](doc:troubleshooting-screenshot-availability-across-projects-and-versions). ## Overview This guide focuses on how screenshot work moves through Atloria when multiple projects, releases, and shared libraries are involved. Instead of treating screenshots as one-off uploads, Atloria organizes them as managed documentation assets. That means each screenshot can belong to an enterprise library, a project collection, or a specific documentation version, and each image can carry review status, ownership, and replacement history. You will use this workflow when your team needs to: - capture screenshots for a specific release - reuse approved screenshots across projects - review and approve screenshots before writers place them in pages - replace older screenshots without losing history for previous versions - keep screenshot libraries clean enough for teams to search confidently This document does not repeat the naming and release-organization basics already covered in [Organizing Screenshots for Documentation and Releases](doc:organizing-screenshots-for-documentation-and-releases). Instead, it builds on that foundation by showing how screenshots move between shared enterprise use, project-specific use, and version-bound documentation work. The main areas covered here are: - choosing the correct project and version before capture or upload - saving screenshots with the right metadata - moving screenshots through review and approval statuses - replacing outdated screenshots while preserving archived assets - reusing approved screenshots safely across projects and versions - correcting common problems such as missing, outdated, duplicate, or misassigned screenshots If you manage documentation across several teams, this workflow helps you keep screenshot decisions visible. Writers can see whether an image is approved, managers can track what replaced it, and reviewers can tell whether a screenshot is safe to reuse in another release. The result is a cleaner screenshot library and fewer mistakes in published documentation. ## Prerequisites Before you work through screenshot workflows across projects and versions in Atloria, make sure you already have access to the parts of the workspace where screenshots are managed and reviewed. You do not need every administrative permission, but you do need the ability to open the relevant project workspace, view screenshot libraries, and work with documentation versions. You should have: - An Atloria account that can sign in and open your team workspace - Access to at least one project where documentation versions are already available - Permission to upload screenshots or start a screenshot capture - Permission to view screenshot details such as status, project, version, and locale - Access to documentation pages where approved screenshots are inserted - A basic understanding of how your team organizes screenshot names and release labels It also helps if you are already familiar with: - project navigation and workspace structure - documentation versions and release-specific content - screenshot organization practices from [Organizing Screenshots for Documentation and Releases](doc:organizing-screenshots-for-documentation-and-releases) - basic screenshot capture work from [Capturing Screenshots from Web Pages](doc:capturing-screenshots-from-web-pages) or [Capturing Website Screenshots for Documentation](doc:capturing-website-screenshots-for-documentation) If you are responsible for approvals or library cleanup, you should also be able to update screenshot status fields and review replacement history. Teams that separate writer and manager responsibilities may limit approval and deletion actions to documentation managers, while writers focus on upload, tagging, and page insertion. The next document in this section, [Using Enterprise Screenshot Libraries for Documentation Teams](doc:using-enterprise-screenshot-libraries-for-documentation-teams), goes deeper into how shared screenshot libraries support team-wide reuse and governance. ## Defining the audiences and the entry points they need Start by listing the reader groups your published documentation needs to serve inside Atloria. In most teams, that means separate experiences for groups such as customers, partners, developers, and internal administrators. If you already reviewed how readers switch between public audience views, use that as your starting point and continue from [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience) rather than rebuilding the same map from scratch. For each audience, define the first page they should reach when they enter your public documentation. In practice, this usually means deciding which landing page is linked from the public homepage, which top-level navigation item should appear for that audience, and which guides should be featured first. In Atloria, this planning works best when you write down the exact reader entry points you expect to publish, such as: - A homepage card that sends readers to an audience landing page - A top navigation label for that audience - A landing page with featured guides and quick links - A search starting point shaped around that audience’s language - Related guide links that keep readers in the same content path For each landing page, decide what a reader should see above the fold. Keep this concrete. Plan the opening copy, the first featured guides, the quick links, and the main call to action. For example, one audience may need “Start here” setup guides first, while another needs reference material or policy pages first. Also separate shared content from audience-only content. Some pages should appear in more than one audience path, while others should only appear in a single navigation experience. Write that distinction down before publishing so your team knows which pages belong everywhere and which pages should stay limited to a specific audience path. [SCREENSHOT: audience planning notes showing reader groups, landing pages, and shared versus audience-only pages] ## Designing audience-specific navigation and content paths Once you know who each audience is, plan how they move through the published documentation in Atloria. This means deciding the top navigation labels, the sidebar section names, the order of sections, and the landing page hierarchy for each audience. The goal is simple: when a reader enters through an audience landing page, every next click should feel like it belongs to that same experience. Begin with the labels readers will actually see. Choose top navigation names that match the audience’s language, not your internal team language. Then group pages in the sidebar based on tasks. A customer audience might need setup, day-to-day usage, and troubleshooting. A developer audience might need getting started, API or reference reading, and integration guides. Keep the section order aligned with what that audience usually does first. As you plan each content path, trace the reader journey from the landing page into deeper content: 1. Open the audience landing page plan. 2. List the first guides or links readers should click. 3. Map where those links lead next. 4. Check that related guides continue the same audience path. 5. Confirm shared pages still make sense when opened from that audience view. You should also decide how pages are placed into the correct audience experience. In Atloria, that usually means agreeing on page labels, navigation group names, and published placement rules before the page goes live. Shared pages need extra attention. If the same page appears in multiple audience experiences, plan how it should appear in each one so the breadcrumbs, sidebar grouping, and surrounding links still feel correct. A useful test is to ask: if a reader opens this page from the audience landing page, will the next visible links keep them moving forward, or will they suddenly feel dropped into a different section? If the answer is unclear, adjust the navigation grouping before publishing. [SCREENSHOT: published documentation structure with audience landing page, sidebar groups, and related links] ## Reviewing page ownership, visibility, and publishing rules Audience-specific experiences work best when your team is clear about who owns each part of the published view. In Atloria, decide this before pages are updated so navigation changes, landing page edits, and publishing decisions do not stall at release time. You do not need a complex process, but you do need named responsibility for the parts readers will see. At minimum, assign ownership in these areas: | Area to own | What to decide | |---|---| | Audience landing pages | Who updates the opening copy, featured guides, and quick links | | Navigation structure | Who approves top navigation labels, sidebar groups, and section order | | Shared pages | Who decides whether a page appears in multiple audience paths | | Publishing decisions | Who confirms a page is ready to be visible publicly | | Review signoff | Who checks that the page fits the intended audience before release | Next, define visibility rules. Your team should know which pages are public now, which pages are still drafts, and which audience entry pages are meant to be discoverable immediately after publishing. This is especially important for new landing pages. A page can be published but still be hard to find if it is missing from the homepage, top navigation, or related guide links. Before publishing, create a short release check for every new or updated page. Confirm that the page has the correct audience assignment, appears in the right navigation group, includes working internal links, and can be found through the intended public path. If your team uses separate writers and reviewers, project administrators should also confirm that the right people can edit, review, and publish the pages tied to each audience experience. For broader permission setup, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) and [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). [SCREENSHOT: project publishing workflow with page ownership and review responsibilities] ## Building a review workflow for audience fit After the structure is planned, review each page as if you were the intended reader. In Atloria, this step is where audience planning becomes practical. A page may be accurate and well written, but still feel wrong if it uses unfamiliar terms, assumes too much background knowledge, or appears under the wrong navigation path. Review pages one audience at a time. Open the landing page for that audience, then move through the featured guides, sidebar sections, and related links exactly as a real reader would. Watch for wording that belongs to another audience. For example, a page written for experienced technical readers may confuse customers if it opens with reference-heavy language instead of a task-based explanation. Use a consistent review checklist so every page is checked the same way: - Does the page use terms this audience would expect? - Does it assume the right level of prior knowledge? - Is the page placed in the correct sidebar group? - Do breadcrumbs match the intended audience path? - Do related links keep the reader in the same experience? - Is the call to action right for this audience? - Is the audience label correct? - Can the page be discovered from the landing page or search terms this audience would use? Landing pages need an extra pass. Check that the featured content is truly the best starting point for that reader group, not just the newest content or the pages your team worked on most recently. Quick links should lead to common tasks, and any featured guides should reflect the order readers are likely to follow. If your team reviews content in stages, separate content review from audience-fit review. First confirm the page itself is ready, then confirm it belongs in the planned audience experience. That second check often catches misplaced links, confusing labels, and weak landing page choices before readers ever see them. [SCREENSHOT: audience review session showing landing page, breadcrumbs, sidebar, and related links] ## Testing the published audience experiences Once the pages are published, test the live experience from the same public entry points your readers will use. In Atloria, this means opening each audience landing page, checking the visible navigation, and following the main links without relying on private project knowledge. If the experience only makes sense to the team that built it, it still needs work. Test each audience separately: 1. Open the public entry point for that audience. 2. Confirm the correct landing page appears first. 3. Check the top navigation labels and sidebar groups. 4. Open the featured guides and quick links. 5. Follow related links and breadcrumbs through several pages. 6. Run searches using terms that audience would naturally type. 7. Repeat the same checks on desktop and mobile layouts. Search testing is especially important. Use audience-specific language, not internal wording. A customer may search for setup or troubleshooting, while a developer may search for API details or integration steps. The expected pages should appear quickly, and unrelated audience content should not dominate the results. Shared pages deserve special attention. Open them from more than one audience path and verify they still feel correctly placed. The breadcrumb trail, nearby links, and surrounding navigation should support the reader’s current path, even when the page itself is shared. Also test direct page links. If someone lands on a page from search or a shared link, the surrounding navigation should still help them understand where they are. Finally, check mobile layouts. Audience-specific navigation often looks clear on desktop but becomes harder to follow on smaller screens. Make sure landing pages, top-level links, and section groupings remain easy to use after publishing. [SCREENSHOT: public documentation testing across audience landing page, search results, and mobile navigation] ## Fixing common problems with audience-specific experiences Most audience issues in Atloria come from placement, labeling, or discoverability rather than the page content itself. When something feels off in the published experience, start by checking the visible page setup before rewriting the content. If a page appears under the wrong audience, review the audience label, the navigation group it was placed in, and where it was published. A page can be written correctly but still show up in the wrong experience if it was assigned to the wrong section or linked from the wrong landing page. Also check related guides that point into it, because those links may be pulling readers across audience boundaries. If readers land on the right page but see the wrong surrounding navigation, focus on shared page behavior. Confirm that the page is being reached from the intended audience entry path and that the breadcrumb trail and sidebar grouping match that route. Shared pages often need careful placement so they make sense in more than one audience experience. If search results mix audiences in unhelpful ways, improve the wording on key landing pages and high-value guides. Use the terms that audience actually searches for in page titles, headings, and introductory copy. Also make sure the most important audience landing page is prominent in public navigation so readers have a clear starting point when search results are broad. If a new audience landing page is published but hard to discover, check these areas first: - Homepage links or cards - Top-level navigation placement - Internal links from related guides - Featured links from existing audience pages - Search wording on the landing page itself When you fix one issue, retest the full path rather than only the single page. A corrected landing page is not enough if the sidebar, breadcrumbs, or related links still send readers into the wrong audience experience. [SCREENSHOT: troubleshooting an audience page with navigation placement, breadcrumb trail, and search visibility checks] ## Overview Planning audience-specific documentation experiences in Atloria means deciding what each reader group should see first, how they move through the published site, and which pages belong only to them versus which pages are shared. This is not just a content exercise. It is a publishing and navigation decision that affects landing pages, homepage links, top navigation, sidebar structure, breadcrumbs, related guides, and public search behavior. A strong audience plan usually includes: - A clear list of reader groups - A defined landing page for each audience - Featured guides and quick links for each starting page - Navigation groups that match audience tasks - Rules for shared pages versus audience-only pages - Review ownership and publishing signoff - Live testing of search, links, and mobile navigation In Atloria, this work is most effective when you connect audience planning to the public reading experience. Readers should not have to decode your internal content structure. They should arrive on a landing page that matches their role, see links that fit their goals, and move through guides without slipping into the wrong path. If your team is still shaping audience definitions, review [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Applying Audiences to Documentation Structure and Content Decisions](doc:applying-audiences-to-documentation-structure-and-content-decisions). If you need help with the public browsing side, [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content) is a useful companion. The next step is to inspect the actual published pages and confirm the planned experience works in practice: [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation). ## Prerequisites Before planning audience-specific documentation experiences in Atloria, make sure the basic audience and publishing pieces already exist. You do not need every page fully written, but you should have enough structure in place to make useful planning decisions about entry points, navigation, and visibility. Prepare these items first: - Access to the project workspace where the documentation will be managed - Existing public documentation or a planned published structure - Defined audience groups for the project - Draft or published landing pages, guides, or section outlines for those audiences - A team decision on who can edit, review, and publish public documentation - Agreement on which content is shared across audiences and which content is audience-specific It also helps if you have already reviewed how public audience views behave from a reader’s perspective. If not, start with [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience). For audience setup work inside the project, [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation) provides the foundation you need before planning the published experience. If your team is still organizing the underlying content, these related guides may help before you continue: - [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) - [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content) - [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences) You should also be ready to test the public side after planning. That means having at least one audience landing page, a visible navigation path, and enough linked pages to follow a realistic reader journey. Without those pieces, it is difficult to confirm whether the audience experience actually works once published. ## Preparing audience-specific content before you publish Before you start publishing for specific audiences in Atloria, make sure the page already exists in your project’s documentation workspace and that the draft content is complete enough to review. This is the point to confirm the title, body content, linked pages, and any screenshots or supporting references are already in place. If the page still needs major edits, finish those first in the documentation editor so you are not trying to solve content and audience setup at the same time. Next, decide which reader groups need different experiences. In most teams, that means separating content for customers, internal teams, or partner readers. If your project uses named audiences, review those audience labels before you begin assigning visibility. If your team uses rules instead of simple labels, confirm the right audience options are available on the page you plan to publish. You want to avoid creating a page structure that assumes an audience exists when that audience has not been set up in the project or organization settings. It also helps to review the surrounding content, not just the page itself. Check whether parent pages, child pages, and navigation items should be shared across all readers or limited to the same audience. A page can be correct on its own but still create a confusing experience if nearby content is visible to the wrong group. Finally, confirm you can complete the full workflow in Atloria. You need access to edit pages, use preview, switch between audience views, and publish changes. If any of those options are missing from the project workspace or admin areas, resolve that before moving forward. [SCREENSHOT: Documentation page open in Atloria with draft content and audience options visible] ## Assigning the right audience to each piece of content Once the page content is ready, open that page in the Atloria editor and look for the audience targeting control used in your project. This is where you define who should see the content. Depending on how your team works, you may be assigning visibility to the entire page or applying audience settings to smaller sections inside the page. Use the audience names exactly as your team has defined them so your published experience stays consistent across pages and versions. 1. Open the page you want to target in the documentation editor. 2. Find the audience setting for the page or the section you want to control. 3. Select the correct audience for that content, such as customer, internal, or partner-facing material. 4. Review the rest of the page for shared sections that should remain visible to everyone. 5. Save the draft before leaving the editor. Be careful when similar audience names exist. For example, if your project has multiple customer-related audiences, make sure you choose the one that matches the intended reader journey. A small mismatch here can cause the wrong page to appear in navigation or hide content from the people who need it. Keep naming and assignment patterns consistent across related pages so readers do not get one experience on a parent page and a different one on a child page. After saving, stay on the page long enough to confirm the audience choice remains selected. If the audience setting disappears or resets after saving, do not move on to preview yet. Save again or recheck the page settings until the assignment is clearly stored in the draft. [SCREENSHOT: Audience setting in the Atloria editor showing a selected reader group] ## Building and reviewing audience views in preview After assigning audiences, switch to preview in Atloria and review the page as each audience would see it. This is one of the most important checks in the workflow because it shows whether the page actually behaves the way your team intended. Use the audience switcher, preview mode, or any available reader-view option in the project workspace to load the same page from each audience perspective. 1. Open preview for the page you just updated. 2. Select the first audience in the audience switcher. 3. Review the full page, including headings, body sections, screenshots, links, and any embedded references. 4. Change to the next audience and repeat the same review. 5. Continue until every configured audience has been checked. As you compare views, focus on what changes and what stays shared. Audience-specific sections should appear only for the intended readers, while common instructions should remain visible across all relevant views. If a section appears for everyone when it should be restricted, return to the editor and check that section’s audience setting. If a section disappears for all audiences, confirm it was not accidentally limited too narrowly. Do not stop at the page body. Review the page title in context, nearby navigation labels, linked child pages, and any buttons or references that lead readers deeper into the documentation set. A page may look correct in isolation but still expose restricted material through a visible link or navigation item. If your page includes links to related content, open those links in preview too and confirm they respect the same audience rules. Repeat this process for every audience before you request approval or publish. For related guidance on planning audience structure before this step, see [Applying Audiences to Documentation Structure and Content Decisions](doc:applying-audiences-to-documentation-structure-and-content-decisions). [SCREENSHOT: Preview mode with an audience switcher showing different reader views] ## Validating the published experience for each reader group Preview is useful, but you also need to validate the full reading experience the way real readers will use it. In Atloria, that means checking more than one page at a time. Open the documentation as each audience and move through the same navigation path a reader would follow, including parent pages, child pages, and linked references. This helps you catch issues that are easy to miss when reviewing a single page in isolation. 1. Open the documentation view for one audience. 2. Start from the navigation menu or collection where readers normally enter the content. 3. Open the targeted page and confirm the page loads correctly. 4. Review in-page sections to make sure only the intended content is visible. 5. Follow child pages, related links, and nearby navigation items. 6. Repeat the same checks for each remaining audience. Pay close attention to where audience-targeted pages appear. A page might be hidden correctly in the body but still show up in navigation, search results, or a collection list for the wrong readers. If your documentation set includes grouped navigation, confirm the audience-specific page appears only in the correct menu path. If a reader does not belong to any matching audience, check what they see instead. The fallback experience should not expose partial content, empty sections, or links that lead nowhere. This is also the stage to coordinate sign-off. In most Atloria teams, the Technical Writer confirms the wording and page structure, the Documentation Manager confirms the publishing plan and audience coverage, and the Project Administrator confirms the project settings and access behavior support the intended release. If your team separates these responsibilities, complete that review before publishing live content. For broader audience setup guidance, refer to [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). ## Publishing audience-targeted documentation safely When validation is complete, open the publish workflow in Atloria and make sure you are publishing the correct draft. This is the moment to confirm the latest edits, audience assignments, and approved content are all included together. If your team works with multiple versions or staged releases, double-check that you are in the right project version before you publish. Publishing the wrong version can make it look like audience targeting failed when the real issue is that an older draft went live. 1. Open the page or version you are ready to release. 2. Start the publish action from the project workspace. 3. Confirm the selected content includes the latest audience-targeted updates. 4. If Atloria shows more than one publish target or version, choose the correct one. 5. Complete the publish action and watch for the status to change to live or published. 6. Reopen the live page immediately and test it again by audience. After publishing, do not assume the live result matches preview exactly. Open the live documentation view and repeat a quick audience check on the page, its navigation placement, and its related links. If your team publishes a group of pages together, spot-check the most important entry pages and one or two child pages for each audience. This is especially important when shared navigation includes a mix of public and audience-specific content. If Atloria shows publishing status changes such as draft, pending review, or live, wait until the page clearly shows the live state before doing final checks. If the status does not update, pause and confirm the publish action finished successfully before telling others the content is available. ## Fixing audience mismatches after release If a page goes live with the wrong audience behavior, start by checking the page’s own audience setting in Atloria. A common issue is that the page was saved with the wrong audience label or left visible to a broader group than intended. Open the page in the editor, review the audience selection, and compare it with the audience used on related parent and child pages. If the page inherits visibility from surrounding content, check those nearby items as well so you are not fixing only one part of the problem. When audience-specific sections fail to appear, inspect the affected content block rather than the whole page first. The page itself may be assigned correctly while an individual section was never tagged for the intended audience. After correcting the section, save the draft and publish again. If the preview looks right but the live page still shows the old result, confirm that the latest draft was actually republished and that you updated the correct live version. Broken navigation is another common release issue. Readers may be able to open a page directly but lose their path through the documentation because menu items, collections, or linked pages were not given matching audience visibility. Review the navigation path from the reader’s point of entry and make sure each step in that path is available to the same audience. Use this table to narrow down the problem quickly: | Problem you see | What to check in Atloria | Likely fix | |---|---|---| | Wrong audience can see the page | Page audience setting and parent page visibility | Correct the page audience and republish | | Section is missing for the right audience | Section-level audience assignment | Update the section audience and republish | | Navigation path is broken | Menu, collection, and linked page visibility | Align visibility across connected content | | Preview is correct but live is wrong | Published version or publish target | Publish the latest draft to the correct live destination | If you need to review how audience views should behave for readers, see [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience). ## Overview Audience-targeted publishing in Atloria lets you release one documentation set to multiple reader groups without forcing every reader to see the same pages, sections, or navigation. Instead of maintaining separate copies of similar content, you can keep shared material together and control which audience sees specific instructions, links, or related pages. This is especially useful when your project serves internal teams, customers, and partner readers at the same time. The publishing workflow has four main parts: - Prepare the page and confirm the right audiences already exist - Assign audience visibility to the page or specific sections - Review each audience view in preview and in the broader reading flow - Publish the approved draft and verify the live result In Atloria, audience-targeted publishing is not only about hiding or showing text. It also affects how readers move through the documentation. A page may need the right audience setting, but so do its parent pages, child pages, and navigation entries. That is why this guide focuses on both content visibility and the reader journey. Use this guide when you already have audience definitions in place and are ready to publish content to those groups. If you still need to create or organize audiences, start with [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) or [Managing Audience Settings Across the Organization](doc:managing-audience-settings-across-the-organization). If your focus is on page creation rather than publishing, [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) is the better starting point. The next document in this workflow is [Validating Audience Targeted Publishing](doc:validating-audience-targeted-publishing), which focuses on checking the published result in more detail before broader release. ## Prerequisites Before you publish documentation for specific audiences in Atloria, make sure these items are already in place: - You can sign in to Atloria and open the correct project workspace - The page or pages you want to publish already exist in the documentation editor - Your draft content is saved and ready for audience review - The project already has the audience groups you need, such as customer, internal, or partner readers - You have access to edit content, use preview, and publish changes - Any related parent pages, child pages, or navigation items are available for review - Your team has agreed on which audience should see each page or section It is also helpful to confirm these supporting conditions before you begin: - The current project version is the one you intend to publish - Linked pages and related references are already written and saved - Any screenshots used on the page are in place and display correctly - Reviewers know who is responsible for content approval, audience validation, and final publishing If you are missing access to the project workspace or need help getting into Atloria, use [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). If the audience groups themselves are not ready yet, complete that setup first with [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). After these prerequisites are in place, continue to [Validating Audience Targeted Publishing](doc:validating-audience-targeted-publishing) to test the published experience for each reader group. ## Finding Public Technical Documentation from the Docs Home Page When you open a published Atloria documentation site, start with the public navigation that is visible on the docs home page. This is the safest place to begin because it shows only published content meant for readers. You are not looking at project-only editing screens here. Instead, you are using the same public-facing documentation experience that customers, partners, or support teams would see after documentation has been released. From the docs home page, readers usually begin in one of three places: - The main documentation navigation for standard help and setup pages - A link or section labeled for API or technical documentation - A technical category that groups generated reference material with related guides If your question is broad, such as how a workflow works or which setup steps come first, begin with a standard documentation page. These pages are written in a more explanatory style and usually help you understand the task before you look at field-by-field details. If your question is specific, such as what a request needs or what a response returns, go to the API or technical reference area. Published pages differ from internal project views because public readers only see released, shareable material. That means the navigation, headings, and links are focused on reading, not editing or managing documentation versions. You can move through categories, open published guides, and follow links into reference pages without seeing workspace-only controls. This guide covers two reading modes inside published Atloria documentation: - Browsing standard documentation pages for explanations and workflow guidance - Opening generated API and technical reference pages for exact operation and schema details [SCREENSHOT: Public docs home page showing main navigation, technical documentation section, and API/reference entry point] ## Moving Between Standard Docs Pages and Generated API Reference A common reading pattern in published Atloria documentation is to start on a hand-written technical page and then open a generated reference page when you need exact details. This works well because the technical page gives you the purpose and workflow, while the generated page gives you the precise request and response information. For example, you might open a technical guide first to understand an integration flow, setup order, or expected outcome. While reading, look for links that point to API reference or technical reference content. These links usually take you to a more structured page focused on a single operation or a related schema. The layout on these pages often feels more rigid and data-heavy because it is designed for exact lookup rather than narrative reading. On generated reference pages, expect to see content such as: - An operation name - A request method and path - Parameter lists - Request body details - Response structures - Linked schemas or reusable definitions By contrast, standard technical pages usually explain: - When to use a feature or workflow - Why one approach is preferred over another - How multiple steps fit together - Which related guides to read next When you want to move back out of a detailed reference page, use the published navigation around the page. Breadcrumbs help you return to the parent section. Side navigation helps you jump to nearby topics in the same documentation area. In-page links often connect related guides and reference sections without forcing you to start over from the docs home page. If you need a refresher on how reference pages are structured before reading them in public view, see [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation). [SCREENSHOT: Published technical guide with a link into API reference and visible breadcrumbs for returning to the parent section] ## Reading API Documentation Effectively When you open a published API reference page in Atloria, read it in a consistent order. This helps you avoid missing a required field or misunderstanding what the operation does. Start at the top of the page and work downward through the structured sections. A practical reading order is: 1. Read the operation name to confirm you are on the exact action you need. 2. Check the request method and path so you know what kind of call the page describes. 3. Review any authentication notes before looking at the payload. 4. Inspect parameters and identify which ones are required. 5. Read the request body section if the operation accepts submitted data. 6. Finish with the response examples to see what comes back. As you review fields, pay close attention to the labels and formatting cues on the page. Published reference pages typically distinguish required and optional values clearly. They may also show data types, allowed values, and nested structures. Use this table as a reading checklist: | What to inspect | What to look for | |---|---| | Required fields | Which values must be included for the request to work | | Optional fields | Which values are available but not always needed | | Data type | Whether a field expects text, numbers, true/false values, lists, or grouped objects | | Allowed values | Whether a field accepts only specific choices | | Nested objects | Whether a field contains sub-fields you also need to complete | Example requests and example responses are especially useful when you are validating payload shape. If you are implementing a call, compare your planned request to the example. If you are troubleshooting a support issue, compare the returned data to the example response to see whether a field is missing, empty, or formatted differently than expected. Also watch for cues that point to related material, such as linked schemas, shared models, or nearby operations. These links help you understand how one operation connects to others without leaving the published documentation area. ## Using Technical Pages to Understand Context Around the API Published API reference is useful for exact details, but it does not always answer the bigger questions behind an integration or workflow. When you need context, leave the operation page and open a technical guide. In Atloria, technical pages are where you learn the order of work, the reason a step matters, and how related tasks connect. Use a technical page when you need help with questions like these: - Which step comes first in a workflow? - What needs to be prepared before using an API call? - When should one approach be used instead of another? - How do several actions fit together in a complete process? Technical pages usually provide information that generated reference pages do not. Instead of focusing only on fields and structures, they explain the surrounding task. You may find conceptual notes, setup guidance, sequence-based instructions, and links to related documentation areas. This is especially helpful when you are new to a topic and do not yet know which operation page to open. Support-oriented readers also benefit from starting with technical pages. If someone asks why a process behaves a certain way, or when a particular action should be used, the answer is often easier to find in a guide than in a reference page. Once the context is clear, you can follow the guide’s links into the published API reference to confirm the exact request details. This back-and-forth is normal in Atloria’s published documentation. A guide helps you understand the workflow. A reference page helps you confirm the exact operation. Cross-links between the two let you move from concept to implementation without losing your place. If you want a broader introduction to reading reference-style material before switching between page types, see [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages). [SCREENSHOT: Technical documentation page with explanatory content and a linked API/reference section] ## Locating the Right Information for Support and Implementation Questions When you are trying to answer a question quickly in published Atloria documentation, the fastest approach is to match the question type to the right page type. This saves time and helps you avoid reading a long guide when you only need one field name, or opening a reference page when you really need workflow context. Use published API reference pages when the question is about exact details, such as: - Which operation handles a specific action - The name of a parameter - Whether a field is required - What a response field means - How a schema is structured Use standard technical documentation when the question is about process and decision-making, such as: - The order of steps in a workflow - What must be set up first - Which integration path to choose - How several calls or actions work together - Why a task is performed a certain way You can usually confirm which kind of page you are reading by checking the page heading, layout, and link patterns. Generated reference pages tend to have tightly structured sections, field tables, and example payloads. Authored guides usually have descriptive headings, narrative explanations, and links to related tasks. When a support question spans both areas, do not start a new search right away. Instead: 1. Open the most relevant published guide or reference page you already found. 2. Use the page heading and section labels to confirm whether it is a guide or a reference page. 3. Follow embedded links on that page to move to the matching content type. 4. Use the linked page to validate the final answer. This approach is especially useful when you need to answer a customer or teammate quickly. Following published links keeps you inside the correct documentation path and reduces the chance of landing on a similar but less relevant topic. ## Resolving Common Navigation and Reading Issues Sometimes you land on the right published documentation area in Atloria but the page itself is not the right level of detail. The fix is usually simple once you recognize whether you are on a guide page or a generated reference page. If you open a highly technical reference page and it feels too narrow or too detailed, move upward in the published structure. Use breadcrumbs near the top of the page to return to the parent section. If side navigation is available, use it to open the broader technical guide that sits above the operation page. This is the fastest way to regain context without leaving the documentation area. If you have the opposite problem and a page explains the topic well but does not show the exact request fields you need, look for links labeled as API, reference, or related technical content. These links usually take you directly to the generated page with the operation details, parameter lists, and response examples. When similar topics appear in more than one place, compare the page format before deciding which one to use: - A conceptual guide usually has descriptive headings and explanatory text - A generated reference page usually has structured field sections and example payloads - A section landing page usually helps you choose between several related topics If you need to share an answer with someone else, link to the most specific published page available. For field-level questions, share the exact operation or schema page. For workflow questions, share the guide that explains the process. This makes the answer easier to verify and reduces follow-up confusion. For more on how published and project views compare when reading reference content, see [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views). [SCREENSHOT: Published reference page with breadcrumbs, side navigation, and a related guide link highlighted] ## Overview Published API and technical documentation in Atloria is designed for reading, not editing. As a public reader, you move through released documentation using visible navigation, page headings, breadcrumbs, side menus, and links between guides and reference pages. The main goal is to help you find the right level of detail for the question you are trying to answer. There are two main page types to recognize: - Standard technical pages, which explain workflows, setup order, and implementation context - Generated API or technical reference pages, which show exact operation details, request fields, response structures, and related schemas The most effective reading pattern is usually to begin with the page type that matches your question. If you need context, start with a guide. If you need exact field-level detail, start with a reference page. From there, use embedded links to move between the two. This is especially helpful for support work, implementation planning, and troubleshooting published documentation with other teams. A few cues make navigation easier: - Public navigation helps you browse only released content - Breadcrumbs help you move back to a broader section - Side navigation helps you compare nearby topics - In-page links help you jump directly to related guides or reference details If you already understand how individual detail pages are laid out, this guide helps you apply that reading approach in the public documentation experience. For the next step, continue with [Exploring API Reference Sections Inside Projects](doc:exploring-api-reference-sections-inside-projects) to see how similar reference material is accessed from within a project workspace. ## Prerequisites Before using this guide, it helps to have a few basics in place so the page types and navigation patterns are easier to recognize. You should already be comfortable with: - Opening published documentation and browsing public-facing pages - Recognizing the difference between a general guide and a detailed reference page - Reading headings, navigation menus, and breadcrumbs to understand where you are in the docs This guide assumes you have already read [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation). That earlier guide explains how detailed technical pages are organized, so this document focuses on how to read those pages once they are published and linked from public documentation. It is also helpful if you can identify the kind of answer you are looking for before you begin: - For workflow or setup questions, plan to start with a technical guide - For field, request, response, or schema questions, plan to start with API reference - For mixed questions, expect to move between both page types using embedded links You do not need access to Atloria’s internal project workspace for this guide. Everything here is about the published reading experience: the pages, categories, and links available to public readers after documentation has been released. ## Opening a parsed code result and locating the readiness signals After you upload code and run parsing, open the saved result from your project’s Code Parsing workspace or from the connected repository view. If you need the upload steps, use [Uploading and Parsing Code for Documentation Workflows](doc:uploading-and-parsing-code-for-documentation-workflows). On the parsed result screen, start at the header area before opening any detailed panels. This is where Atloria shows the analysis name, the repository or source name, and the branch or revision label tied to that run. Use those labels first to make sure you are not reviewing an older snapshot or the wrong branch. Next, look for the parse status indicator. Only review coverage after the result shows that parsing finished. If the status still shows that the run is in progress, queued, or incomplete, the files list, symbol list, and reference links may not represent the final result. The parse timestamp is equally important. When teams parse code more than once, the timestamp helps you confirm which run matches the version of the code you plan to document. Once you confirm the correct snapshot, scan the main analysis panels. In Atloria, the most important areas for this review are the parsed file list, the symbols area, and any references or dependencies panel shown with the result. Coverage indicators beside the result tell you whether Atloria detected files, symbols, and cross-links between them. Those indicators are your first readiness signal: a result that shows files but little or no symbol or reference coverage usually needs closer inspection before you rely on it for technical writing. [SCREENSHOT: Parsed code result header showing repository name, branch label, parse status, timestamp, and coverage indicators] ## Inspecting files, symbols, and extracted structure Once you have the correct parsed result open, move into the file tree or parsed file list. Your goal here is simple: confirm that Atloria included the source areas you expected to document. Look for the main folders that matter to your project, such as app folders, shared code folders, integration areas, or documentation-related source directories. If an expected folder is missing from the file list, that is an early sign that your review may be incomplete. After checking the file list, open the symbols panel. This view should show the named items Atloria extracted from the code. Depending on the codebase, you may see recognizable items such as classes, functions, methods, interfaces, or modules. You do not need to judge every item. Instead, spot-check a few important files and confirm that the symbols shown in Atloria match what you would expect from those files. If a major file appears in the file list but shows very few named items, the structural extraction may be weak. Open a few symbol detail views and inspect the information Atloria provides. Useful signals include the symbol name, where it appears in the source, and whether it is grouped under a parent item or shown with child items beneath it. Those relationships help you judge whether Atloria understood the structure of the file instead of only listing isolated names. A practical review pattern is to compare two or three high-value files against the parsed output. Check whether major items are present, whether grouped items are nested sensibly, and whether any names appear collapsed together in a confusing way. If you notice missing items or oddly grouped results in several important files, treat the parse as only partially reliable. [SCREENSHOT: Parsed file list beside the symbols panel with one file expanded to show extracted structure] ## Reviewing references and dependency links After confirming that files and symbols were extracted, review whether Atloria captured relationships between them. Open the references or usages view for a symbol that you already know is used in more than one place. Good candidates are shared utilities, project-wide configuration items, reusable UI pieces, or common business logic. In a healthy parse result, these items should not appear isolated. You should see inbound and outbound links that help you understand where the item is used and what it depends on. Next, inspect the dependency area for the parsed result. This may show links between files, modules, packages, or other grouped parts of the codebase. You are not trying to validate every connection. Instead, look for meaningful patterns. For example, if one area of the project clearly relies on another, Atloria should show some visible relationship between them. When the dependency view is empty or unusually thin for a large codebase, that often means the parser captured structure but not enough cross-file context. It also helps to open a symbol with known cross-file behavior and verify that related links appear. If you expect usage from other files, inherited behavior, imported dependencies, or implementation relationships, those should be visible in the references area when parsing is strong. Missing links do not always mean the parse failed completely, but repeated gaps reduce confidence. Watch for broken patterns such as: - empty usage lists for widely reused items - missing links between obviously related files - unresolved imports or disconnected dependencies - symbols that appear in the list but have no surrounding context When these patterns show up across several important areas, Atloria may still help with high-level structure, but it may not be strong enough for detailed behavior tracing. [SCREENSHOT: Symbol detail view with references, usages, and dependency links visible] ## Interpreting coverage indicators for documentation readiness Coverage indicators in Atloria help you decide whether a parsed result is ready for documentation work or only useful as a partial reference. Start by separating two kinds of coverage in your review. The first is structural coverage: whether Atloria detected the expected files and extracted named items from them. The second is reference coverage: whether Atloria also connected those items through usages, dependencies, and other relationship links. A result with strong file and symbol coverage but weak reference coverage can still be useful for some writing tasks. For example, it may support navigation, page outlines, component inventories, or high-level API summaries. By contrast, if you need to explain how a workflow moves across multiple files or how one part of the code triggers another, low reference coverage is a serious limitation. As you review the indicators, pay attention to warnings that suggest likely documentation gaps. These may include low-coverage notices, unsupported-file markers, or unknown-language labels. Those signals tell you where Atloria may have skipped extraction or produced only partial results. If those warnings appear in critical folders, you should avoid treating the parse as a complete source of truth. Use the coverage view to decide what kind of documentation the result can support: | Documentation goal | Coverage you should look for | |---|---| | Architecture pages | Strong file coverage, clear structure, visible dependencies | | API overviews | Strong symbol coverage, recognizable naming, stable grouping | | Workflow documentation | Strong references, cross-file links, meaningful dependency paths | A parsed result does not need perfect coverage to be useful. It does need enough visible structure and linking to support the kind of page you plan to write without forcing constant manual verification. ## Deciding whether the parsed output can support your documentation work The best way to judge a parsed result is to compare it directly to your documentation goal. If you are drafting a high-level architecture page, focus on whether Atloria shows the major folders, major named items, and broad dependency relationships. If you are preparing API overviews, check whether the symbols list is complete enough to identify the public-facing surface of the code. If you are documenting a feature workflow, you need stronger references so you can follow behavior across multiple files with confidence. Use three signals together when making that decision: 1. **Symbol completeness** — Do the important files show the main named items you expect? 2. **Dependency visibility** — Can you see meaningful links between major areas of the codebase? 3. **Reference density** — Do important symbols show enough usages and related links to trace behavior? Partial parsing can still be useful. For example, if Atloria captured top-level project structure and major named items, you may be able to draft navigation pages, architecture summaries, or documentation outlines even when deeper cross-file references are incomplete. On the other hand, if your work depends on exact behavior tracing, sparse references should push you toward a narrower scope or a fresh parse. It is also worth recording your review findings in a simple, repeatable way for your team. Note which folders look complete, which areas show weak coverage, and which documentation tasks are safe to start now. That gives writers, reviewers, and project owners a shared understanding of what the parsed result can support today and what still needs attention before drafting begins. [SCREENSHOT: Coverage summary with notes or review comments captured beside the parsed result] ## Handling common gaps in parsing results When parsing results look incomplete, start with the most visible gap and work backward from there. If expected files are missing, first confirm that you opened the right repository source and the correct branch or revision label. In Atloria, a parsed result is tied to a specific snapshot, so reviewing the wrong branch can easily look like a parsing problem when it is really a scope problem. Also check whether the upload or parsing setup excluded folders that contain important source files. If the files are present but the symbols look thin or incomplete, the issue may be limited to extraction quality rather than repository scope. Pay attention to unsupported-language markers or unknown-file indicators in the result. Generated files and files with parsing problems can also reduce the amount of structure Atloria can show. In that case, the file list may look complete while the symbols panel still feels sparse. When references or dependencies are weaker than expected, review whether the project structure is broad enough to require more context than the current parse captured. Multi-package repositories, shared libraries, and imported project settings can all affect how well cross-file links appear in the result. If those relationships are central to your documentation task, weak links are a sign to pause before drafting detailed workflow content. If coverage remains low after these checks, choose one of three practical responses: - re-run parsing on the correct branch or a cleaner source snapshot - narrow the documentation scope to areas with stronger coverage - supplement the parsed result with manual review in the source files That decision should match the urgency and type of documentation you are producing. For broad summaries, partial coverage may be enough. For technical reference pages, workflow tracing, or dependency-heavy explanations, it is usually better to improve the parse first. ## Overview This page helps you review a completed code parsing result in Atloria and decide whether it is reliable enough to support technical documentation. The focus is not on running a parse. Instead, it is on reading the result you already have and checking whether the extracted files, symbols, references, and dependency links are strong enough for the kind of documentation you want to write. You will use the parsed result screen to answer a few practical questions: - Did Atloria finish parsing the correct repository snapshot? - Were the expected files and folders included? - Do the extracted symbols look complete and recognizable? - Are references and dependency links present where you would expect them? - Is the overall coverage strong enough for architecture, API, or workflow documentation? This review matters because not every parsed result is equally useful. Some runs are excellent for high-level structure but weak for cross-file tracing. Others may capture the right files but miss important named items in key areas. By checking readiness signals before drafting, you can avoid writing documentation from an incomplete or misleading analysis snapshot. This guide assumes you already know how to upload code and start parsing in Atloria. If you need that workflow, return to [Uploading and Parsing Code for Documentation Workflows](doc:uploading-and-parsing-code-for-documentation-workflows). If you need help managing repeated runs or switching between parsing sessions, see [Managing Code Parsing Workspace Sessions](doc:managing-code-parsing-workspace-sessions). The next document in this sequence is [Using Code Parsing Results to Support Technical Docs](doc:using-code-parsing-results-to-support-technical-docs), which focuses on turning a reviewed parse into practical writing work. ## Prerequisites Before you review parsed code coverage in Atloria, make sure the following are already in place: - You can sign in to Atloria and open the project workspace that contains the code parsing result. - A code parsing run has already been completed for the repository or uploaded source you want to review. - You know which repository, branch, or revision you intend to document so you can verify the correct snapshot in the parsed result header. - You have a clear documentation goal, such as an architecture page, API overview, feature workflow, or technical reference section. - You are familiar with the earlier setup steps covered in [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace) or [Uploading and Parsing Code for Documentation Workflows](doc:uploading-and-parsing-code-for-documentation-workflows). It also helps to have a short list of high-value files or folders ready before you begin. That makes it easier to spot-check whether Atloria extracted the parts of the codebase that matter most to your documentation work. Use this review when: - you need to confirm whether a parse is trustworthy before drafting - you want to compare multiple parsing runs and choose the strongest one - your team needs to understand where documentation can begin immediately - you suspect missing files, weak references, or incomplete dependency mapping If your goal is not review but active writing, continue to [Using Code Parsing Results to Support Technical Docs](doc:using-code-parsing-results-to-support-technical-docs) after you complete the checks in this guide. ## Opening the code parsing workspace and understanding what you can upload In Atloria, open your project workspace and go to the **Code Parsing Workspace** from the technical documentation area. If you already worked through [Using Code Parsing to Support Technical Documentation](doc:using-code-parsing-to-support-technical-documentation), this is the point where you move from planning to actually adding source material and running a parse. When the workspace opens, focus on four main areas: - the **upload area**, where you add source files - the **snippet input area**, where you paste code directly - the **parse run status** area, where you watch progress - the **results area**, where Atloria shows the parsed output you can use in documentation Use **Upload** when you want Atloria to examine real project files together. This is the better choice when you need a broader picture, such as understanding a feature across several files, tracing related screens, or reviewing how a project section is organized. File uploads usually give you more context, which helps when you are writing feature explanations, technical reference pages, or workflow descriptions. Use the **snippet** option when you only need to inspect one focused piece of code. This works well for quick research, such as checking a single screen, a small configuration block, or one reusable UI element before writing about it. A pasted snippet is faster to test, but it may show less surrounding context than a full file upload. The parsed output helps you turn source material into documentation-ready inputs. In practice, that means you can use the workspace to discover project sections, identify screen names and relationships, and review implementation details before drafting user guides or technical pages. [SCREENSHOT: Code Parsing Workspace showing upload area, snippet box, run controls, status area, and parsed results panel] ## Preparing files and snippets before you start a parsing run Before you click **Parse**, take a minute to prepare the source material you plan to add. Clean inputs make the results easier to review and more useful when you start writing documentation. If you are uploading files, choose the files or folders that match the documentation task in front of you. For example: - For a feature walkthrough, select the files tied to that feature’s screens and related pages - For a technical reference draft, include the files that define the feature structure and supporting pieces - For broader discovery, upload a small group of related files instead of an entire codebase at once Try to avoid uploading a large unrelated set of files just because they are available. In Atloria, narrower and more intentional uploads usually make the results panel easier to read. If you are pasting a snippet, include enough surrounding code for Atloria to understand what it is looking at. A few isolated lines often produce weak results. A better snippet usually includes the full block you want to study, along with nearby declarations or setup that explains how that block fits into the page or feature. Choose your input method based on your goal: | Documentation goal | Better input choice | Why | |---|---|---| | Feature discovery | Related file upload | Gives broader context across screens and sections | | API or technical explanation | Focused file upload or larger snippet | Preserves structure and nearby definitions | | Quick clarification | Snippet paste | Fast for checking one specific area | Also confirm that you can access the project workspace and save shared work in the parsing area. If your team uses shared documentation workflows, make sure you are working in the correct project before uploading files so other writers and reviewers can find the same parsing results later. ## Uploading source files or pasting code snippets Once your source material is ready, add it to the **Code Parsing Workspace** using either the file upload option or the snippet box. ### Uploading files 1. In the workspace, click the **Upload** control. 2. Select the source files you want to analyze. 3. Wait for the files to appear in the pending input list or preview area. 4. Review the file names before you continue. After the upload finishes, confirm that every file you selected is visible in the workspace. If a file is missing, add it again before starting the parse. This quick check helps you avoid running analysis on an incomplete set. ### Pasting a snippet 1. Click into the **snippet input** area. 2. Paste the code you want Atloria to analyze. 3. Review the pasted content in the preview area. 4. Make sure the snippet starts and ends in the right place. Snippet review matters. If you only paste the middle of a larger block, the results may be incomplete. When possible, include the full section you want to document so the preview reflects the real boundaries of that code. If you notice a mistake before parsing, update the inputs right away. In the workspace, you can remove the wrong file, replace an outdated version, or clear and re-paste the snippet. It is better to fix the input list first than to sort through confusing results later. Use the preview as your last checkpoint. Confirm: - the correct files are listed - the snippet contains the intended section - the source material matches the feature or workflow you are documenting [SCREENSHOT: Workspace preview showing uploaded files in a pending list and a pasted snippet ready for parsing] ## Starting a parsing run and monitoring its progress After you confirm the files or snippet in the workspace, start the analysis from the main action controls. 1. Review the pending inputs one more time in the workspace preview. 2. Click the **Parse** action to begin the run. 3. Watch the run status area as Atloria processes the source material. 4. Wait until the status changes to a completed state before opening the results. During the run, Atloria moves through visible status stages such as **queued**, **in progress**, and **completed**. These labels help you understand whether your request is waiting, actively being processed, or ready for review. If you are working with multiple files, the run may take longer than a small snippet, so the status area is the best place to check progress instead of guessing whether the workspace has stalled. While parsing runs, Atloria prepares structured output you can reuse in documentation work. The goal is not just to display raw code again, but to organize what was found so you can review feature structure, identify important sections, and gather accurate details before writing. If you change the source material after a run, start a new parse so the results match the latest version. For example, re-run parsing when: - you replaced a file with a newer copy - you expanded a snippet to include missing context - you narrowed the upload to a smaller feature area - your documentation scope changed and you added more related files Do not rely on older results if the input has changed. In Atloria, the parsed output reflects the material included in that specific run, so refreshing the run is the safest way to keep your documentation research accurate. [SCREENSHOT: Parse run status area showing queued, in progress, and completed states] ## Reviewing parsed results for documentation work When the run finishes, open the **parsed results** area and review what Atloria extracted from your files or snippet. This is where the workspace becomes most useful for documentation planning. Look first for the main structure Atloria discovered. Depending on what you uploaded, the results may help you identify: - the overall file organization - important named sections within the source - related screens or reusable parts - content that can support technical reference writing For documentation work, use the results panel as a research view rather than a final draft. You are looking for accurate clues about how a feature is organized and what deserves explanation. This is especially helpful when you need to describe a workflow, explain how a screen fits into a larger project area, or confirm the names of visible sections before writing. Full-file uploads usually provide deeper context than snippets. A broader upload can reveal how one screen connects to another, or how a feature is grouped across several files. Snippet parsing is still useful, but the results may be narrower because Atloria only sees the selected block. If the output feels too thin, that is often a sign that you need more surrounding source material. As you review results, capture the findings that matter most to your draft, such as: - the names of user-facing screens - the order of steps in a workflow - the relationship between a page and its supporting sections - wording you want to validate before publishing documentation This is also a good point to compare what you expected to find with what Atloria actually surfaced. If the results do not support your documentation goal, adjust the inputs and run parsing again rather than forcing weak findings into your draft. ## Using parsing output in your documentation workflow The parsed output becomes most valuable when you turn it into a writing plan. In Atloria, use the results to connect source material to the documentation sections you need to create or improve. Start by mapping the parsed structure to your planned documentation. For example, if the results show a login screen, registration screen, admin area, analytics page, and security page, you can use that structure to decide whether you need separate help articles, a workflow guide, or a reference page for each area. This keeps your documentation aligned with the actual product experience instead of relying on assumptions. Parsed results are also useful for validating terminology. Before you write, compare your draft language with the names and labels surfaced in the workspace. This helps you describe screens consistently and avoid mixing internal wording with what users actually see in Atloria. When several people contribute to the same project, keep the parsing work tied to the shared workspace so others can review the same source-backed findings. This is especially helpful when writers, project leads, and administrators all need to agree on feature boundaries or confirm which screens belong in a documentation set. Run another parse whenever the source changes or your scope expands. Common examples include: - a feature update adds a new screen or step - you move from one-page research to a broader workflow - your first parse answered one question but raised another - you need stronger context before writing a technical reference page If you are using parsing as part of a larger documentation effort, pair the results with your page planning and review process rather than treating the workspace as a one-time task. The next step is to look more closely at what was captured in the results and how complete that coverage is in [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage). ## Common issues when uploading or parsing code and how to fix them Most parsing problems in Atloria come from the input you selected, not from the documentation workflow itself. When results look wrong or incomplete, start by checking the workspace inputs and run status. If uploaded files do not appear in the workspace, confirm that the upload finished and that the files were added to the pending input list. If the list is empty, use **Upload** again and wait for the files to show in the preview before you click **Parse**. If snippet results are incomplete, the pasted code is often too narrow. Instead of submitting a few lines from the middle of a block, expand the snippet so it includes the surrounding section. Adding the full block usually gives Atloria enough context to produce more useful results. If a parse run does not finish or the output looks outdated, check the status area first. A run may still be **queued** or **in progress**. If the run completed but the results still reflect older content, remove the previous input, add the latest file or snippet version, and start a fresh parse. If the results are technically correct but not helpful for writing, change the scope: - switch from a tiny snippet to a related file upload when you need context - narrow a large upload when the results are too broad - focus on the files tied directly to the screen or workflow you are documenting - re-run parsing after replacing outdated source material A good rule is simple: if the results do not help you explain a real feature clearly, adjust the input until the parsed view matches the documentation question you are trying to answer. ## Overview Use the **Code Parsing Workspace** in Atloria when you need source-backed input for documentation work. The workflow is straightforward: add files or paste a snippet, review the pending input, start a parse run, and study the results before you write. The most important choices happen before parsing begins: - choose **Upload** for broader feature or workflow research - choose the **snippet** area for a focused question - confirm the preview so you do not analyze the wrong material - re-run parsing whenever your source changes Keep the workspace centered on your documentation goal. If you are writing a feature guide, upload the files tied to that feature. If you are checking one small section, paste a snippet with enough surrounding context to make the result meaningful. After the run completes, use the parsed results to confirm structure, identify the right screen names, and gather accurate details for your draft. This document focused on running the workflow from input to results. For a closer look at how to inspect what Atloria found and judge whether your parse covered enough of the source, continue with [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage). ## Confirming what must be reviewed before a release Before you start checking screenshots, make sure you are looking at the correct version in Atloria. Open the version or release candidate your team plans to approve, then review the pages included in that version’s scope. If you already manage versions from the version workspace, keep that screen open while you move through the related documentation pages so you do not accidentally review screenshots from an older draft. [SCREENSHOT: version workspace showing the selected release candidate and included pages] 1. Open the version you are preparing for release and confirm its title or label matches the release under review. 2. Review the list of included documentation pages and identify pages that contain screenshots, image blocks, or step-by-step interface captures. 3. Open those pages one by one and note where screenshots appear inside procedures, walkthroughs, or feature explanations. 4. Confirm your reviewers can access the same Atloria pre-release or staging environment that reflects the current interface being released. 5. Gather the release notes, the list of changed features, and any page ownership details so you can match screenshot checks to actual product changes. This preparation step matters because screenshot review is not only about image quality. In Atloria, a screenshot can become misleading when a page title changes, a button moves, a form adds new fields, or a navigation label is renamed. If you review screenshots without the release notes or the current version scope, it is easy to miss those mismatches. If you need help understanding how the version itself is organized before starting screenshot review, use [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) or [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review) first. ## Finding pages with screenshots that may need updates Once you know which version you are reviewing, focus first on the pages most likely to have outdated images. In Atloria, the highest-risk pages are usually the ones updated during the current review window, especially when the related feature includes renamed navigation, changed buttons, updated forms, or revised page layouts. Start with those pages instead of trying to inspect every screenshot in random order. [SCREENSHOT: documentation page list filtered to recently updated pages] 1. Filter or review the documentation pages included in the current version and prioritize pages changed during this release cycle. 2. Move changed pages to the top of your review list if they describe navigation updates, new fields, revised workflows, or renamed actions. 3. Open each page and inspect every screenshot placement inside procedures, callouts, and feature walkthroughs. 4. Compare each image with the current Atloria interface, paying close attention to page titles, left navigation labels, main action buttons, and table column headers. 5. Mark each screenshot as one of these review outcomes: unchanged, outdated, missing, or no longer relevant. Do not review the written instructions alone. A page can have accurate text but still show an older interface in the image. For example, a screenshot may still display an old navigation label, a previous page header, or a button that has moved to a different toolbar area. Those differences can confuse readers even when the surrounding paragraph has already been updated. As you work, keep your review notes tied to the page itself. It helps to record which screenshot appears near which task, such as a setup step, a review step, or a confirmation step. That makes follow-up easier when the page owner or technical writer needs to replace the image. If you need broader guidance on screenshot organization before release review, see [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). ## Checking whether each screenshot is complete and still relevant After you identify pages that may need attention, inspect each screenshot closely to decide whether it still supports the task on the page. In Atloria, a screenshot is ready for release only when it shows the exact screen state the instructions describe. That means the image should include the right tab, the correct dialog title, the visible action button, and any confirmation or validation state the reader is expected to recognize. [SCREENSHOT: documentation page with a screenshot beside step-by-step instructions] 1. Read the instruction directly above and below the screenshot so you know what the image is supposed to show. 2. Check that the screenshot includes the exact interface area being referenced, such as the full dialog, the selected tab, or the visible success state. 3. Confirm that all labels in the image match current Atloria wording, including menu names, field labels, button text, and status names. 4. Look for missing context caused by cropping, overlays, or partial captures, especially where breadcrumbs, modal titles, filters, or messages help explain the step. 5. Decide whether the screenshot still helps the reader complete the task or whether it should be replaced or removed. A screenshot can be technically current but still not useful. For example, if the image repeats what the text already explains and does not help the reader identify a decision point, it may no longer deserve space on the page. On the other hand, a small interface change can make an image misleading if the screenshot still shows an older button label or a missing field that now matters to the workflow. Pay special attention to screenshots used in critical tasks, such as sign-in, project setup, version review, approvals, and publishing. Readers rely on those images to confirm they are in the right place. If the screenshot hides the selected tab or cuts off the page title, it may no longer give enough context to be trusted. ## Recording review decisions and assigning follow-up work As you review pages, record the result immediately instead of waiting until the end. Screenshot review moves faster when every page has a clear status and a short note explaining what was found. In Atloria release work, the most useful review notes are specific enough that the page owner can open the page, see the mismatch, and fix it without asking for clarification. [SCREENSHOT: release review tracker with screenshot status notes] 1. Log the review result for each page in your version review tracker or release checklist. 2. Record the page title, the screenshot status, and whether a new capture is required. 3. Add a short note describing the exact mismatch, such as an outdated navigation label, a missing field, or a button moved to a different location. 4. Assign the follow-up to the page owner or technical writer responsible for that content. 5. Link the follow-up work to the related release item, documentation task, or version review item so it stays visible during sign-off. Use consistent status wording so the team can sort and act on results quickly. A simple structure like the table below keeps reviews easy to scan: | Page | Screenshot status | Issue found | Follow-up needed | |---|---|---|---| | Page title | Unchanged / Outdated / Missing / Remove | Short mismatch note | Recapture, replace, or remove | | Page title | Unchanged / Outdated / Missing / Remove | Short mismatch note | Recapture, replace, or remove | | Page title | Unchanged / Outdated / Missing / Remove | Short mismatch note | Recapture, replace, or remove | Flag any page that could block release readiness. In practice, that usually means the screenshot shows a deprecated workflow, contradicts approved release behavior, or points readers to controls that no longer exist. Those pages should stay open in the release tracker until the replacement image is added and checked again. For related review and approval guidance, see [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions). ## Approving screenshot readiness for version release Approval should happen only after all required screenshot updates have been completed and checked again in the version draft. Return to every page marked for follow-up and confirm that the replacement image appears in the correct location on the page. In Atloria, it is not enough for a new screenshot to exist somewhere in the project; it must be attached to the right page and support the exact step being documented. [SCREENSHOT: updated draft page with replacement screenshot in place] 1. Re-open each page that was marked for screenshot updates. 2. Confirm the replacement screenshot appears in the correct section of the documentation page. 3. Compare the updated page side by side with the current Atloria release candidate or staging view. 4. Verify that critical workflows still include the screenshots readers need and that any removed images were intentionally dropped. 5. Mark the page, documentation set, or release checklist item as screenshot-ready only after all blocking issues are resolved. This final check is where you catch last-minute mistakes such as the wrong image being uploaded, an older image being re-used, or a screenshot being removed without updating the surrounding instructions. Look especially at pages that describe high-traffic workflows or release-sensitive changes. If a screenshot was replaced, make sure the image matches the final interface, not an earlier draft from the same release cycle. When the last blocking mismatch is cleared, update the release checklist so the version’s screenshot review is visibly complete. That gives approvers confidence that the draft reflects the real Atloria experience readers will see after release. ## Fixing common problems found during screenshot review Most screenshot issues fall into a few repeat patterns. When you recognize them early, you can fix them quickly and avoid repeated review rounds. In Atloria, the goal is not to keep every screenshot at all costs. The goal is to keep only the screenshots that accurately support the current workflow and help the reader make progress. [SCREENSHOT: examples of outdated, cropped, and corrected screenshots] - **A screenshot shows an older Atloria layout** Check where the image came from before replacing it. If it was captured from an older version or the wrong review environment, recapture it from the current release candidate so the page header, navigation, and action buttons match the latest interface. - **The page instructions mention controls that are not visible in the image** Open the correct tab, panel, or dialog state before taking the new screenshot. If the step refers to a confirmation message, validation warning, or expanded section, make sure that state is visible in the image. - **Several screenshots on one page use inconsistent wording** Align all captures to the approved release vocabulary. If Atloria now uses a new page title, button label, or status name, replace older images so the page reads consistently from start to finish. - **A screenshot is accurate but no longer useful** Remove it when it duplicates the text or no longer helps the reader identify the right action. This is common on pages where the workflow has become simpler or where the image adds clutter without improving understanding. - **A screenshot is cropped too tightly** Retake it with enough surrounding context to show the page title, selected section, or dialog heading. Readers often need that extra context to confirm they are on the correct screen. If screenshot issues keep appearing across multiple pages, review your team’s capture approach using [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) and [Capturing Screenshots from Web Pages](doc:capturing-screenshots-from-web-pages). ## Overview Screenshot readiness review in Atloria is the release-stage check that confirms every image in the version draft still matches the interface readers will see. This review focuses on completeness, accuracy, and usefulness. You are not only checking whether an image exists. You are checking whether it shows the correct screen, the right labels, and enough context to support the task on the page. Use this review when a version includes interface changes, updated workflows, renamed navigation, or revised forms. It is especially important for pages that guide readers through setup, approvals, project management, publishing, and other high-impact actions. A screenshot that shows an outdated button label or an older page layout can create confusion even when the written instructions are correct. During this process, you typically work across three things at once: - The version or release candidate being prepared for sign-off - The documentation pages included in that version - The current Atloria interface in the release candidate or staging environment Your main outcomes are straightforward: - Identify which screenshots are still correct - Find screenshots that need recapturing or removal - Record follow-up work clearly - Confirm the version is ready for release from a screenshot perspective This document focuses on the first screenshot review pass before release approval. It helps you decide what needs attention and how to track it. For broader screenshot management across projects, use [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). For the next step in this release workflow, continue with [Reviewing Version Screenshots Before Release](doc:reviewing-version-screenshots-before-release). ## Prerequisites Before starting screenshot readiness review in Atloria, make sure you have access to the materials and screens needed to compare the version draft against the current interface. This work goes much faster when you prepare those items first instead of searching for them during review. You should have: - Access to the Atloria version or release candidate that is being prepared for approval - Access to the documentation pages included in that version - Access to the current Atloria release candidate, staging environment, or other approved pre-release view used for validation - The release notes or changed-features list for the version under review - Page ownership details, or a clear way to identify who should update screenshots when issues are found - A release checklist, review tracker, or version review log where you can record screenshot status and follow-up actions It also helps if you are already familiar with: - How to open and review documentation pages in a project - How your team tracks version readiness and release blockers - Which workflows in Atloria are considered critical for release review - Where your team stores or updates screenshots for documentation pages If you are still getting oriented, review [Managing Project Version Workspaces](doc:managing-project-version-workspaces) and [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) before starting. If your team needs to replace screenshots during review, keep [Capturing Screenshots from Web Pages](doc:capturing-screenshots-from-web-pages) available as a companion reference. The next step in this sequence is [Reviewing Version Screenshots Before Release](doc:reviewing-version-screenshots-before-release), where you move from readiness checking into a more focused page-by-page review pass. ## Reviewing Supported Languages and Frameworks for Your Stack Before you start a parsing run in Atloria, open the area where supported languages and framework coverage are listed and compare that list to the repositories you plan to document. If you need a refresher on how Atloria presents parser coverage, use [Understanding Supported Languages Frameworks and Parser Availability](doc:understanding-supported-languages-frameworks-and-parser-availability) as your reference point, then come back here to make a go-or-no-go decision. Focus on exact matches, not broad assumptions. A repository may be “JavaScript-based,” but what matters in Atloria is whether the code you want to parse lines up with the supported language entry and any framework notes shown alongside it. Review each major part of your stack separately, such as backend services, frontend apps, shared libraries, and infrastructure folders. If Atloria shows that one language is supported but a framework layer has limited coverage, note that difference before you upload or connect code. As you review the support list, sort each part of your repository into practical planning groups: - **Fully supported**: the language is listed and the framework or common project structure is also recognized. - **Partially supported**: the language is listed, but framework-specific patterns or project conventions may not be fully captured. - **Unsupported**: the language or framework layer does not appear in Atloria’s support information. Also check whether framework recognition depends on repository files that help Atloria understand the project structure. In practice, this means confirming that your repository includes the normal setup files for that stack, such as dependency manifests, build files, or lockfiles. If those files are missing, Atloria may identify the language but miss important framework details. [SCREENSHOT: Supported languages list in Atloria with parser availability and framework notes highlighted] Keep a short planning note for each repository or folder. For example, record combinations like “supported backend language, partially supported web layer” or “shared library supported, generated client excluded.” That simple comparison will save time when you decide what to parse and what to document manually. ## Comparing Repository Contents Against Parsing Requirements Once you know what Atloria supports, compare that support list to the actual contents of your repository. This step is less about the technology name and more about the files Atloria will actually see when parsing begins. Open your repository in the code parsing workspace or review its folder structure before starting the run. Look first for the source files that match the supported language entries. If your team expects Python reference pages, the repository should contain Python source files. If you expect TypeScript output, the repository should include TypeScript files rather than only compiled JavaScript. The same applies to Java and other supported languages: Atloria needs the original source files, not just build output. Check for the supporting files that help Atloria understand the project: - Source folders where active code lives - Dependency manifests - Framework configuration files - Build or workspace files that show package structure - Lockfiles when they are part of framework detection At the same time, identify folders that should not shape your parsing results. These often include: - Generated output - Compiled assets - Minified files - Vendored libraries - Third-party dependency folders - Large generated code areas If your repository is a monorepo, do not treat it as one uniform codebase without checking each package or app. One folder may contain a supported backend service, while another contains a partially supported frontend framework. Nested applications, shared packages, and mixed-language folders often need separate evaluation. [SCREENSHOT: Repository folder view in Atloria showing source folders, config files, and folders marked for exclusion] This is also the right time to flag code that may technically parse but produce weak results. Heavily generated files, transpiled output, and copied external libraries can clutter the workspace and reduce the value of the generated reference pages. Your goal is to confirm that the repository contains the right source material for Atloria to work with, and to separate that from everything that should be ignored. ## Estimating What Technical Reference Content Can Be Generated After reviewing support and repository contents, decide what kind of documentation Atloria is likely to generate from that codebase. This prevents a common mistake: expecting detailed technical reference pages from a stack that only supports partial extraction. In Atloria, supported code parsing can lead to different levels of output depending on the language, framework patterns, and file quality. For well-supported areas, you can usually expect richer technical reference content such as: - File and module structure - Named code elements - Relationships across files - Organized reference pages for code areas - Navigation that reflects the codebase structure For partially supported areas, Atloria may still provide useful results, but the output may stay closer to file-level or directory-level summaries instead of complete API-style reference detail. This matters when you are planning documentation for engineering teams, customer-facing technical readers, or internal support teams who expect deep reference coverage. Framework conventions can also affect what appears in generated documentation. If a framework uses clear routing, component organization, schema files, or other recognizable patterns, Atloria may be able to expose more useful structure in the technical documentation view. If those conventions are missing, inconsistent, or only partly supported, the generated output may be thinner even when the language itself is supported. Set expectations early for likely gaps, especially in partially supported stacks. These gaps may include: - Missing relationships between code elements - Incomplete type or inheritance details - Unresolved cross-file links - Skipped framework-specific constructs - Uneven coverage across folders in the same repository [SCREENSHOT: Technical documentation view in Atloria showing detailed reference output for one folder and lighter summary output for another] A simple way to estimate results is to ask: “Will this area produce detailed reference pages, basic structural summaries, or almost nothing useful?” That answer helps you decide whether automated generation is enough on its own or whether you should plan author-written pages alongside the parsing output. ## Deciding Whether to Parse the Whole Project or Only Supported Areas Once you understand likely output quality, choose the scope of your parsing run. In Atloria, this usually means deciding between a full-repository parse and a more focused parse that targets only the folders most likely to generate reliable technical references. Start by grouping the repository into practical parse candidates. For example, you might have one backend service in a well-supported language, a frontend package with only partial framework coverage, and a tools folder full of generated files. Those areas should not automatically be treated the same. Instead, review them as separate candidates and decide which ones are worth including in the first run. Use a scoped approach when only part of the repository is a strong fit for Atloria’s parser coverage. This is especially useful for monorepos, mixed-language projects, and codebases that include both source code and large amounts of build output. A smaller, cleaner parsing target often gives better technical documentation than a broad run filled with unsupported or noisy folders. As you define the scope, write down clear inclusion and exclusion rules for the run: 1. Include the main source roots that match supported languages. 2. Exclude build output, generated assets, and third-party dependency folders. 3. Separate partially supported packages from fully supported ones if they need different expectations. 4. Decide whether shared libraries should be parsed with the main app or as their own target. You should also define success criteria before starting. Useful criteria include: - Whether the generated reference pages cover the main code areas you care about - Whether important code elements appear consistently - Whether the structure is clear enough for readers to navigate - Whether manual cleanup stays at an acceptable level [SCREENSHOT: Atloria parsing setup view with selected folders included and unsupported folders excluded] A pilot run is often the safest choice. Parse the most promising area first, review the generated technical documentation, and then expand only if the results are strong enough to justify broader coverage. ## Planning Around Unsupported or Partially Supported Technologies Most real repositories contain at least one area that Atloria will not document perfectly through automated parsing. The key is to plan for those gaps before they become a surprise during documentation work. When part of your stack is unsupported or only partially supported, split the documentation plan by coverage level. Let Atloria generate technical references for the areas it handles well, and use regular documentation pages for the rest. This works especially well when backend code is a strong match for parsing, but the user interface layer, infrastructure definitions, or custom internal formats need more hands-on explanation. Create a simple planning table for your project team: | Repository area | Support level | Documentation approach | |---|---|---| | Backend service folders | Fully or partially supported | Use Atloria parsing to generate technical references, then review and refine | | Frontend or framework-specific folders | Partial or limited support | Combine parsing results with author-written pages | | Custom formats, generated code, or proprietary layers | Unsupported | Document manually in regular project pages | As you plan, keep explicit notes on what Atloria may miss. Useful notes include skipped directories, framework conventions that are not recognized, and sections where generated references may be incomplete. These notes help reviewers understand why some parts of the technical documentation are rich and others are intentionally handled outside the parsing workflow. You should also revisit support decisions when the repository changes. Framework upgrades, language version changes, reorganized folders, or a move to a monorepo can all change what Atloria can detect cleanly. A stack that was only partially useful for parsing last quarter may become a better candidate after a cleanup or restructuring effort. [SCREENSHOT: Project planning notes in Atloria showing supported areas for parsing and unsupported areas assigned to manual documentation] This approach keeps your documentation realistic. Instead of forcing every code area through one workflow, you use Atloria where it adds the most value and fill the remaining gaps with targeted author-written content. ## Checking Common Evaluation Mistakes Before You Commit to Parsing Before you launch a parsing run, do a final review for the mistakes that most often lead to disappointing results in Atloria. These issues usually come from assumptions made too early, not from the parsing process itself. One common mistake is seeing that a language is supported and assuming the repository will produce strong reference pages. In practice, the repository may contain mostly compiled output, generated files, or copied dependencies instead of the original source code Atloria needs. If the source material is weak, the generated documentation will be weak too. Another frequent problem is assuming framework coverage based only on package names or general team knowledge. A repository might include a known framework, but if the expected configuration files, workspace files, or normal folder structure are missing, Atloria may not recognize the project in the way you expect. Always compare the actual repository contents to the support information shown in Atloria. Monorepos create another evaluation trap. Teams often start one broad parsing run for the entire repository even though different packages use different languages, frameworks, and support levels. That can produce uneven results and make the technical documentation feel unreliable. Review each major package or application separately before deciding on one shared run. Also watch for expectation gaps around partial support. Partial support does not usually mean “complete reference coverage with a few small omissions.” It may mean sparse output, unresolved relationships, missing metadata, or skipped framework-specific structures. Plan for that honestly. Use this quick review before committing: - Confirm the repository contains original source files - Confirm key framework and dependency files are present - Confirm unsupported folders are excluded - Confirm monorepo packages were evaluated individually - Confirm your team expects the right level of output for partial support [SCREENSHOT: Pre-parse review checklist or setup confirmation screen in Atloria] If any of those points are unclear, pause and adjust the scope first. A careful evaluation almost always produces better documentation than a rushed full-repository parse. ## Overview Evaluating language support before parsing code is the step where you decide whether Atloria can generate useful technical reference content from your repository, and how much of that repository should be included. You are not just checking whether a language name appears in a support list. You are matching your real codebase to Atloria’s supported languages, framework coverage, and repository requirements so you can choose the right parsing scope. In practice, this evaluation happens before you upload code or start a parsing session in the code parsing workspace. You review the supported language entries, compare them to the folders and files in your repository, and estimate what kind of output Atloria is likely to create. For some projects, that means full technical reference coverage across the main source folders. For others, it means parsing only selected services or libraries and documenting the rest manually. This guide focuses on the decision-making part of that process. It helps you compare support information to actual repository contents, identify risky areas such as generated code or mixed-language monorepos, and set realistic expectations for the technical documentation Atloria can produce. If you already know how to view support coverage, this guide picks up from there and turns that information into a practical parsing plan. Use this guide when you are preparing a new project, reassessing an existing repository, or deciding whether automated technical reference generation is worth the effort for a specific stack. The goal is to avoid wasted parsing runs and to make sure the documentation you generate in Atloria matches the structure and quality of the code you actually have. ## Prerequisites Before working through this evaluation in Atloria, make sure you have the following: - Access to an Atloria account and the project or workspace where code parsing will be reviewed - A repository, code upload, or folder structure you can inspect before starting a parsing run - Enough familiarity with your project to identify major languages, frameworks, shared packages, and generated-code areas - The ability to review source folders and supporting files such as dependency manifests, lockfiles, and framework configuration files - A clear idea of which parts of the repository matter most for technical reference generation It also helps to have already reviewed Atloria’s language and parser coverage information. If you have not done that yet, start with [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage) and then use [Understanding Supported Languages Frameworks and Parser Availability](doc:understanding-supported-languages-frameworks-and-parser-availability) for the support details behind your evaluation. You do not need to finalize your entire documentation plan before using this guide, but you should be ready to answer a few practical questions: - Which folders contain the original source code? - Which parts of the repository are generated, compiled, vendored, or otherwise poor candidates for parsing? - Does the repository contain one stack or several different stacks? - Are you aiming for detailed technical reference pages, lighter structural summaries, or a mix of both? If you are preparing for the next step after this evaluation, continue with [Evaluating Supported Languages and Parser Availability](doc:evaluating-supported-languages-and-parser-availability), where you can apply these decisions more directly to parsing readiness. ## Opening a project and finding its documentation areas In Atloria, start by opening the project you want to review from the main project workspace. Once you are inside the project, use the project navigation to find the documentation areas. Depending on how your team has organized the workspace, you will typically move between the main documentation area and the **API Reference** area from the same project navigation, rather than leaving the project and opening a separate public site. The main documentation area is where you review written guides, setup instructions, how-to pages, and other narrative content. These pages usually read like end-user or team-facing documentation. The **API Reference** area is different: it is structured as reference content, where pages are grouped into endpoint sections, resource groups, or schema-based entries. This makes it easier to tell where explanatory guides end and where detailed request-and-response reference begins. Inside a project workspace, these pages can be reviewed before they are publicly released. That means your team can open draft documentation, move through the page structure, and inspect API reference entries while the content is still internal. Look for signs that content is still in progress, such as draft labels, unpublished status indicators, or sections that appear only inside the workspace and not on the public documentation view. This internal view is useful for several roles: - **Writers** review page structure, wording, and navigation flow. - **Managers** check whether the documentation is complete enough for release. - **Administrators** confirm that the right people can access internal project content. [SCREENSHOT: Project workspace showing the main navigation with documentation pages and API Reference visible in the same project] ## Browsing documentation pages inside the project workspace When you are reviewing documentation inside a project, use the navigation tree to move through pages without leaving the workspace. The sidebar is the main tool for this. It lets you open top-level pages, expand grouped sections, and move into child pages in the order your readers will likely follow after publication. Open a page from the sidebar and focus on three main parts of the screen: the **page title** at the top, the main **content area** in the center, and any in-page navigation such as a table of contents or anchor links if they are available on that page. The page title helps you confirm you are in the correct section. The content area shows the full draft text, headings, images, and structured content blocks. If the page includes anchor navigation, use it to jump between sections and confirm that longer pages are easy to scan. To review the full documentation flow, continue through nearby pages using the sidebar or any **previous** and **next** page controls that appear around the content. This is especially helpful when you want to check whether a setup guide leads naturally into a reference page, or whether grouped pages are ordered correctly for readers. Because you are working inside the project workspace, you may also see content that is not yet public. Watch for draft-only indicators, unpublished changes, or workspace-only visibility cues. These signals help you distinguish between content that is ready for release and content still being edited. If a page appears unfinished, check whether headings are missing, sections are incomplete, or links point to pages that are still being prepared. [SCREENSHOT: Documentation page inside a project workspace with sidebar navigation, page title, and content area] ## Exploring API reference pages for endpoints and schemas To review technical reference content inside a project, open the **API Reference** area from the project navigation. The left-hand navigation usually organizes entries into groups, such as resource sections, tags, or related endpoint categories. Use these groups to move through the reference in a structured way instead of opening pages one by one at random. When you open an endpoint page, start at the top of the entry. This area usually gives you the most important summary details first. Look for the **HTTP method** label, the **request path**, and the short operation summary. These items tell you what the endpoint does and how it is categorized. If the page includes authentication details near the top, review those as well so you can confirm whether access requirements are clearly described before release. As you scroll, inspect the request details in the structured sections of the page. These often include parameter tables and request body details. | Section | What to review | Why it matters | |---|---|---| | Path parameters | Required values included in the URL path | Confirms the endpoint can be used correctly | | Query parameters | Optional or filtering values | Helps reviewers check search, filtering, or paging behavior | | Headers | Required request headers | Verifies important request requirements are documented | | Request body | Input fields and schema structure | Shows whether users can understand what data to send | Continue to the response area and review the listed **status codes**, response descriptions, and example payload blocks. This is where internal reviewers can confirm whether success and error responses are documented clearly enough. If schema sections are available, use them to check field names, nested structures, and overall completeness before the documentation is published. [SCREENSHOT: API Reference page showing method label, request path, parameters, request body, and response examples] ## Using project navigation and search to move between docs and reference content When a project contains many guides and reference sections, search becomes the fastest way to move around. In Atloria, use the workspace or documentation search to find a specific page title, endpoint name, or schema term instead of manually expanding every group in the sidebar. This is especially useful during review sessions when you need to confirm whether a term appears consistently across multiple pages. Search is not only for finding content quickly. It also helps you test whether users inside the project will be able to locate the right material before release. Try searching for a guide title, a feature name, an endpoint label, and a schema term. If the results are clear and well named, reviewers can move between narrative documentation and API reference content with less confusion. Use the shared project navigation to switch between the written documentation area and the **API Reference** area. This is an important review step because many projects rely on both types of content together. For example, a setup guide may introduce a workflow, while the API Reference provides the exact request details. Moving between both areas helps you confirm that cross-links make sense and that the documentation feels connected rather than split into unrelated sections. During review, also test navigation details: - Open sidebar groups and confirm labels are easy to understand. - Click internal links and anchor links to make sure they open the expected section. - Check whether related pages are grouped together logically. - Compare page names and endpoint titles for consistent wording. Documentation managers often use this step to audit naming consistency. If a guide uses one term but the API Reference uses another, search results and navigation labels will reveal the mismatch quickly. ## Checking what internal users can see before public release One of the main benefits of reviewing content inside a project workspace is that internal users can see documentation before it is publicly available. Use this view to compare what is visible in the workspace with the project’s public release state. If a page or API section appears in the project but not in the public documentation, that usually means it is still internal, still in draft, or not yet included in the released version. This is also the right time to confirm access patterns. Project members may be able to open draft pages, unpublished edits, and in-progress API reference sections, while people outside the project may not see them at all. If you are checking readiness with a manager or administrator, ask them to confirm that the correct team members can open the project workspace and review the same internal content. As you move through the workspace, verify that recent edits are visible. This includes updated page text, changed endpoint details, revised schemas, and newly added sections. Internal review is most useful when it reflects the latest draft state, so it is worth checking that the content shown in the project matches what your team expects to release later. Use the page itself to judge readiness. Common signs that content is close to release include: | Sign | What it suggests | |---|---| | No draft marker visible | The page may be closer to final review | | Complete sections from top to bottom | The content is likely structurally ready | | Endpoint details include parameters, request body, and responses | The reference entry is more complete | | Working internal links and anchors | Navigation is ready for reader testing | Pages still under review often show draft indicators, missing sections, incomplete examples, or placeholder-level structure that has not been fully filled out yet. ## Fixing common issues when pages or API sections do not appear If you cannot find the **Docs** or **API Reference** area, first make sure you are inside the correct project workspace. It is easy to open the wrong project when several projects have similar names. After confirming the project, check whether your role includes access to internal documentation. If you can open the project but do not see its documentation areas, the issue may be related to your workspace permissions. If a documentation page does not appear in the sidebar, review the project structure carefully. The page may still be unpublished, moved into another section, or placed under a different parent page than expected. Expand grouped sections in the navigation before assuming the page is missing. If your team recently reorganized the documentation tree, older links or saved expectations may no longer match the current layout. When an API reference page opens but looks incomplete, review the page content itself. A complete endpoint entry should include a summary near the top and structured sections for request details and responses. If those sections are missing or mostly empty, the source material for that reference may not be complete enough yet for Atloria to show a full entry in the workspace. If search does not return the result you expect, double-check the exact title or term you are using. Search works best when page titles, endpoint names, and section labels have been saved clearly and consistently. | Problem | What to check | |---|---| | Docs or API Reference missing | Correct project and your access level | | Page missing from navigation | Unpublished status, moved location, or different section | | Endpoint page incomplete | Missing summary, request details, or response details | | Search returns nothing | Saved title, endpoint name, or section label may differ | If the content still does not appear after these checks, ask a project administrator or documentation owner to confirm the page’s current location and visibility inside the workspace. ## Overview Atloria lets you review both draft documentation pages and draft **API Reference** content inside a project workspace before anything is publicly released. This internal view is useful when you need to check structure, wording, navigation, and technical completeness in one place. Instead of relying only on the public documentation experience, your team can open the project directly and inspect what readers are likely to see once the release is ready. The most important distinction to keep in mind is the difference between narrative documentation and API reference content. Narrative pages explain workflows, setup steps, and concepts in a guided format. API reference pages are more structured and focus on endpoint details such as request paths, parameters, request bodies, response codes, and schema information. Inside the project workspace, both can be reviewed side by side so teams can confirm that guides and reference entries support each other. This document focused on how to: - Open a project and locate its documentation areas - Browse draft documentation pages through the project sidebar - Review API reference sections and endpoint details - Use search and shared navigation to move between content types - Confirm what internal users can see before release - Troubleshoot missing pages, incomplete reference entries, or search issues If you need a refresher on how published technical documentation behaves outside the project workspace, see [Reading Published API and Technical Documentation](doc:reading-published-api-and-technical-documentation). For the next step in this workflow, continue with [Viewing Technical Entities and Related Reference Details](doc:viewing-technical-entities-and-related-reference-details). ## Prerequisites Before you start reviewing API reference sections inside a project, make sure you can open the correct project workspace in Atloria and that the project already contains documentation content to browse. You do not need public release access for this task, but you do need access to the internal project area where draft pages and draft API reference entries are available. You will be able to follow this guide more easily if the following are already true: - You can sign in to Atloria and open the target project. - The project includes documentation pages, API reference content, or both. - Your role allows you to view internal project documentation. - You know the general project area where your team keeps technical docs. If you are still getting familiar with technical reference layouts, it helps to first read [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages). If you need help understanding how technical documentation is organized more broadly inside a project, see [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). And if you want a comparison between internal project views and released documentation views, use [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views). During review, it is helpful to have a clear goal before you begin. For example, you may be checking page order in the sidebar, confirming that endpoint entries include complete request and response details, or verifying that draft-only content is visible only to internal reviewers. Starting with one of those goals makes it easier to move through the workspace efficiently and notice gaps before release. ## Understanding how agents use project-linked knowledge In Atloria, a support agent answers questions based on the knowledge you make available in its setup. The most important part of that setup is the connection between the agent and a project. When you link an agent to a project, you are telling Atloria which project workspace the agent should look to for documentation context. This is different from adding extra knowledge sources in the agent’s settings. The linked project identifies the main project the agent belongs to, while the knowledge sources list lets you control exactly which documentation collections the agent can use. This distinction matters when teams manage several projects with similar names or overlapping content. If the wrong project is linked, the agent may pull answers from the wrong documentation set. If the project is correct but unrelated knowledge sources are also attached, the agent may mix content that should stay separate. For that reason, you should always review both the **Linked Project** field and the **Knowledge Sources** section together. Published documentation is what support agents are expected to use. If a page is still a draft, under review, or otherwise not published, you should not expect the agent to answer from it. When a team updates documentation, the agent’s response quality depends on whether the final, published version is actually available in the project content the agent can access. Teams usually split responsibility across roles: - **Support Team Lead** sets up the support agent and reviews its knowledge sources. - **Project Administrator** makes sure the correct project is linked. - **Documentation Manager** controls which pages and articles are published and ready for agent use. [SCREENSHOT: Support agent settings showing the linked project field and knowledge sources section] ## Preparing projects and published documentation before linking an agent Before you link a support agent to a project in Atloria, confirm that the project already exists and contains the documentation your team wants the agent to use. Start from your project list or project workspace and open the intended project. Check that the documentation space includes the pages, articles, or structured content your support team expects the agent to answer from. If the project is incomplete or still being set up, linking the agent too early can lead to weak or misleading responses. Next, review the publication status of the content. Support agents should rely on published documentation, not drafts or unfinished edits. If your team has recently updated a page, open that page and make sure the published version reflects the latest approved content. If a page is archived or not available in the live documentation set, it should not be treated as a reliable source for the agent. This is especially important when support teams expect answers for newly released features. You should also confirm that the person doing the setup can access both sides of the workflow: - The project workspace that contains the documentation - The support agent settings where project links and knowledge sources are managed If someone can open the agent but cannot view the project content, they may not be able to verify whether the right material is available. If they can view the project but cannot edit the agent, they will not be able to finish the setup. Before saving anything, decide what should be included and what should stay out. Customer-facing help articles, published setup guides, and approved troubleshooting pages are good candidates. Internal notes, draft procedures, and team-only working documents should remain excluded. [SCREENSHOT: Project documentation area showing published pages ready for support use] ## Linking a support agent to the correct project 1. Open the support agent you want to configure in Atloria. On the agent’s settings or configuration page, look for the project linking area. This is usually the place where you choose which project the agent belongs to. 2. Find the **Linked Project** field or project picker. Open the list and select the correct project carefully. If your team uses similar project names, pause and double-check before choosing. It helps to confirm the project name against the project workspace your documentation team maintains, rather than selecting the first close match. 3. After selecting the project, review the rest of the page briefly to make sure you are editing the intended agent. This is useful when teams manage multiple support agents for different products, audiences, or documentation sets. 4. Click **Save** to store the project connection on the agent record. Do not leave the page before saving, or the selected project may not be kept. 5. Re-open the same support agent settings after saving. Check the **Linked Project** field again and confirm the same project still appears. This quick re-check helps catch accidental changes, unsaved edits, or cases where the wrong project was selected from the list. 6. If the linked project does not look right, update it immediately and save again before moving on to knowledge source setup. It is much easier to fix the project link first than to troubleshoot mixed answers later. A correct project link gives the agent a clear home base. Once that is in place, you can move to the **Knowledge Sources** section and refine exactly which published documentation collections the agent should use. [SCREENSHOT: Agent configuration page with a project selected in the linked project field] ## Organizing the agent's knowledge sources After linking the project, open the **Knowledge Sources** section in the same support agent settings. This area is where you review what the agent can actually use when answering questions. Some sources may come from the linked project, while others may have been added separately. Read each source name carefully so you can tell whether it belongs to the correct documentation set. Use this section to keep the agent focused. If the agent supports one product area, keep only the documentation collections that match that scope. Remove unrelated sources that could introduce conflicting instructions or answers from another project. For example, if an agent is meant to answer only from one team’s published help content, avoid mixing in sources from another product line or internal documentation set. A simple organization approach makes ongoing maintenance easier: - Group sources by **product area** when one team supports multiple products - Group sources by **team ownership** when different documentation teams maintain separate collections - Group sources by **documentation set** when you want one agent to answer from a specific published library only Consistent naming also helps. If source names are clear and recognizable, support leads and documentation managers can quickly confirm whether the right material is attached. If Atloria shows sources in a list, review the order as well. A tidy, predictable order makes future audits faster, especially when several people share responsibility for agent upkeep. As you edit the list, save changes and return to the source list to confirm it still matches your plan. The goal is not to attach as many sources as possible. The goal is to give the agent a clean, relevant set of published documentation that matches its support role. [SCREENSHOT: Knowledge sources list showing project-based sources and separately added sources] ## Confirming the right published content is available to agents Once the project link and knowledge sources are in place, verify that the agent can use the published content you expect. Start by opening the linked project and reviewing a sample of the pages or articles your support team relies on most. Focus on content that is already published, especially recently updated pages, because these are often the first places where teams notice gaps. Then return to the support agent settings and compare the configured knowledge sources with the published documentation you just reviewed. Make sure the source names line up with the correct project content. If a key documentation collection is missing from the **Knowledge Sources** section, the agent may not be able to answer from it even if the page is published elsewhere in Atloria. A practical way to validate the setup is to test the agent with real support questions. Use representative questions that should clearly be answered from the linked project’s published documentation. For each test: 1. Ask a question tied to a known published page. 2. Read the agent’s answer carefully. 3. Open the matching published page in the project. 4. Compare the wording, instructions, and topic coverage. You are looking for alignment, not necessarily identical wording. The answer should reflect the same published guidance, product area, and scope. If the response sounds like it came from another project, or if it ignores a recently published page, review the project link and source list again. This check is especially useful after a documentation release, a project rename, or a change in agent ownership. Small configuration mistakes are easier to catch with a few targeted questions than with a broad review of every page. [SCREENSHOT: Side-by-side view of a support agent response and the matching published documentation page] ## Fixing missing or incorrect knowledge in agent responses If a support agent in Atloria cannot find content you expected it to use, start with the page itself. Open the relevant article or documentation page and confirm it is published. If it is still a draft, pending review, or otherwise not part of the published documentation set, the agent may not use it as expected. This is the most common reason a newly written page does not appear in answers. If the agent gives answers from the wrong documentation, go back to the agent settings and inspect the **Linked Project** field first. A similar project name can easily cause confusion, especially in organizations with multiple related workspaces. If the wrong project is selected, correct it, click **Save**, and then review the **Knowledge Sources** section for any leftover sources that no longer belong. When newly published content still does not seem available, check whether the correct source was actually added to the agent’s knowledge configuration. Publishing content in a project does not help if the agent is limited to a different documentation collection. Open the source list and verify that the expected collection is present and that unrelated sources are removed. If only some team members can validate the setup, compare access levels. The people involved may need permission to: - Open the project and view its published documentation - Open the support agent settings - Edit the agent’s project link and knowledge sources Without both project visibility and agent management access, a team member may see only part of the workflow and assume something is missing when it is actually hidden by permissions. For broader admin-side navigation and workspace access, see [Using the Admin Workspace](doc:using-the-admin-workspace) and [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Overview Managing support agent knowledge in Atloria comes down to three connected decisions: which project the agent belongs to, which knowledge sources are attached to that agent, and whether the needed documentation is actually published. The **Linked Project** field gives the agent its primary project context. The **Knowledge Sources** section narrows or expands what documentation collections the agent can use. Published content is what makes those sources useful in practice. This workflow is easiest to manage when each role handles a clear part of the process: - **Support Team Lead** reviews the agent’s scope and keeps the source list focused - **Project Administrator** confirms the correct project is linked - **Documentation Manager** publishes the pages that should be available for support answers A clean setup usually follows this pattern: | Area to check | What to confirm | Why it matters | |---|---|---| | Linked Project | The selected project is the intended workspace | Prevents answers from the wrong project | | Knowledge Sources | Only relevant documentation collections are attached | Reduces mixed or conflicting responses | | Published Content | Key pages are published and available | Ensures the agent can answer from approved material | If you are still setting up the agent itself, pair this guide with [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) and [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup). If your team is reviewing how project navigation affects documentation access, [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces) is also useful. The next step is learning how agents use published documentation directly in day-to-day support workflows: [Using Published Documentation as Support Agent Knowledge](doc:using-published-documentation-as-support-agent-knowledge). ## Prerequisites Before you start linking a support agent to project knowledge in Atloria, make sure these basics are already in place: - You can sign in and open the main Atloria workspace - The support agent already exists and you can open its settings - The target project already exists in Atloria - The project contains the documentation space or content the agent should use - The pages or articles you want the agent to rely on are published - You can view the project and edit the agent’s knowledge setup It also helps to prepare a short list of the exact documentation collections the agent should use. This prevents guesswork when you reach the **Knowledge Sources** section. If your organization has several projects with similar names, note the exact project title before opening the agent settings so you can choose the right one in the project picker. Use this guide when you are in one of these situations: - You are setting up a new support agent for an existing project - You need to move an agent from one project to another - You want to clean up an agent that is using too many unrelated sources - You need to confirm whether published documentation is available to the agent If you still need help getting into Atloria or creating your account, start with [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If your access depends on admin approval, [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) explains how teams typically control workspace access. ## Opening the public page review tools for a specific audience 1. Open the published documentation site for the project in Atloria and go to the public page you want to review. You can reach it by browsing through the public navigation, using a search result, or opening the page directly from its public URL. For this task, stay in the public documentation experience rather than opening the page from a project editing screen. 2. Make sure you are looking at the live public reading view. You should see the page as a reader would see it, including the page title, navigation, breadcrumb trail, and any public audience controls. If you are in a workspace that shows editing tools, version management options, or other internal project actions, return to the published public page before continuing. 3. Find the audience selection control on the public documentation page. This is the control you use to switch the reader view from one audience to another. It may appear near the top of the page or within the public reading layout. Use that control before you begin checking page visibility, links, or redirects. 4. Confirm that the audience setting applies to the page you are currently viewing. After you select an audience, watch for changes in the page content, navigation links, or page route. If nothing changes right away, refresh the page and check again. 5. Before you start your review, verify that the page you opened is the exact public page you intend to inspect. Check the page title, the breadcrumb path, and the surrounding navigation so you know you are validating the correct destination for that audience. [SCREENSHOT: Public documentation page showing the page title, breadcrumb trail, navigation menu, and audience selector] ## Switching the page to the audience you want to review 1. On the public documentation page, open the audience picker and choose the audience you want to test. Use the exact audience name that matches your review plan, such as a role-based reader group or another public audience segment already set up for the project. If you planned the audience structure earlier, use that naming consistently with [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences). 2. After you select the audience, wait for the page to update. In Atloria, changing the audience can affect what appears in the left navigation, which links are shown on the page, and whether the current page remains available. If the page does not visibly update, refresh the browser and confirm the selected audience is still shown. 3. Review the page again with the new audience applied. Look for visible changes such as: - A different set of navigation links - Hidden or newly visible content sections - Different related links or calls to action - A redirect to another page if the current page is not available to that audience 4. Record the exact audience name shown in the selector before taking notes or screenshots. This helps avoid confusion later, especially when comparing two similar audience groups on the same page. 5. If you are reviewing with teammates, ask everyone to switch to the same audience before discussing results. Small differences in the selected audience can make the same page look different, even when the URL stays the same. [SCREENSHOT: Audience picker opened on a public documentation page with one audience selected] ## Checking whether the selected page is available to that audience 1. Start by confirming that the page loads normally for the selected audience. A successful review page should display its expected title and content. If Atloria sends you to a different page, shows a missing-page message, or blocks access, note that result immediately because it means the page is not available in the way you expected for that audience. 2. Check the page title and breadcrumb trail. These two elements help confirm that the page you are seeing is the intended public page, not a fallback page or a nearby section with a similar name. Also review the navigation state so you can see whether the correct section is highlighted. 3. Test the page through direct access. Copy or open the public page URL while keeping the same audience selected. This confirms whether the page is truly available for that audience or only reachable when you click through navigation. A page that opens through menus but fails on direct access needs further review. 4. Compare discoverability across the public reading experience. Look for the page in: - The main navigation - Breadcrumb paths from parent pages - Search results, if public search is available - Related links or next-step links on nearby pages 5. If the page is meant to be public for that audience, it should be both reachable and discoverable through normal reading paths. If it only appears in one place, or disappears from menus while still loading by direct URL, capture that mismatch in your review notes. [SCREENSHOT: Public page with visible title, breadcrumb trail, and navigation state used to confirm page availability] ## Confirming readers are seeing the intended content path 1. Begin from a realistic public starting point instead of jumping straight to the page every time. Open a landing page, category page, search result, or related link that a reader from the selected audience would normally use. Then follow the path to the page under review. 2. Watch for redirects as you move through the public site. If Atloria sends the selected audience to another page, confirm that the destination makes sense for that audience. A correct redirect should guide the reader to the matching public content path, not to a general fallback page or a page intended for another audience. 3. Review the page’s surrounding navigation once you arrive. Check the breadcrumb sequence, nearby menu items, and any related links shown on the page. These should all support the same audience journey and keep the reader moving through the right set of documentation pages. 4. Pay close attention to audience-specific guidance on the page itself. If the page includes banners, prompts, or calls to action, make sure they point to the next page that audience should read. A page can be available and still be wrong if its follow-up links send readers into another audience’s route. 5. Confirm that the URL path, breadcrumb order, and linked next steps all match the intended reading journey you planned for that audience. If the path breaks at any point, note exactly where it happens: the starting page, the redirect, the breadcrumb jump, or the related link. [SCREENSHOT: Public reader journey from a landing page to a target page, with breadcrumbs and related links visible] ## Comparing what different audiences see on the same public page 1. Open the same public page and switch between at least two audience selections using the audience picker. Keep the page URL the same while you compare results. This makes it easier to spot whether Atloria changes the page content, hides the page, or redirects one audience elsewhere. 2. For each audience, review the same set of page elements: - Page title - Main heading - Body sections - Navigation links - Related content modules - Calls to action - Redirect behavior, if the page is unavailable 3. Note which parts stay the same and which parts change. Some pages should remain shared across audiences, with only small differences in supporting links. Other pages may be fully audience-specific and should disappear or redirect when the wrong audience is selected. Your review should confirm that the page behaves according to its intended public use. 4. Pay special attention to cases where the same URL shows the wrong variation. For example, one audience may see content that should only belong to another audience, or a shared page may hide content that should remain visible to everyone. These are important review findings because they affect the public reading experience directly. 5. When documenting differences, use the audience names exactly as shown in Atloria and describe the visible change on the page rather than using general notes like “looks different.” Clear comparisons make it easier to correct audience targeting later. | Review area | Audience A result | Audience B result | What to confirm | |---|---|---|---| | Page availability | Loads, redirects, or missing | Loads, redirects, or missing | Whether access matches the intended audience | | Navigation | Visible links and highlighted section | Visible links and highlighted section | Whether readers can find the page naturally | | Content blocks | Sections shown or hidden | Sections shown or hidden | Whether each audience sees the correct content | | Follow-up links | Next pages offered | Next pages offered | Whether the content path stays consistent | ## Fixing common issues when audience-specific pages do not match expectations When a page does not behave the way you expect, start with the simplest checks on the public page itself. First, confirm the audience picker is set to the correct audience and that the selected audience name is still visible after the page loads. If the page does not change after switching audiences, refresh the page and compare the navigation, title, and visible sections again. In many cases, the issue is that the audience change was not fully applied before the review started. If a page seems missing for one audience, test the public page URL directly while keeping that audience selected. Then compare what appears in the navigation and breadcrumb trail. A page may be hidden from menus, redirected to another page, or unavailable entirely. These are different results, so record which one you see instead of writing only that the page is “not there.” If readers land on the wrong page, trace the route step by step. Start from the public landing page or category page, click the same links a reader would use, and note the exact point where the path changes unexpectedly. Check: - The redirect destination - The breadcrumb sequence - Related links on the page - Calls to action that move the reader forward If different reviewers report different results, make sure everyone is using the same public URL, the same selected audience, and the same published page state. Differences in any of those three items can make review findings look inconsistent even when Atloria is working as configured. [SCREENSHOT: Side-by-side review notes showing the same public page tested with different audience selections] ## Overview Use this review when you need to confirm that a published documentation page in Atloria behaves correctly for a specific audience. The goal is not to edit content or change audience settings. Instead, you are checking the public reading experience: whether the page is available, whether readers can find it through normal navigation, and whether the surrounding links keep them on the right documentation path. This task is most useful after audience planning is complete and the public documentation is already published. If you still need to define which pages belong to which audience, return to [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences) before starting this review. During the review, focus on what a public reader actually sees: - The selected audience in the audience picker - The page title and main heading - Breadcrumbs and navigation menus - Related links and calls to action - Redirects or missing-page behavior - Differences between audience views on the same page A strong review answers three practical questions: - Can this audience open the page? - Can this audience discover the page through normal public navigation? - Does this page lead the audience to the correct next page? Because Atloria supports audience-specific public experiences, the same page URL may not behave the same way for every audience. That is why it is important to test both direct access and normal click paths, and to compare results across more than one audience when needed. ## Prerequisites Before you start reviewing audience-specific public pages in Atloria, make sure the following are already in place: - You can access the project’s published public documentation site. - The project already has audience options available in the public reader view. - The page you want to review has been published to the public site. - You know which audience name you are testing. - You have a specific page, section, or reader journey to validate. - You are working in the public documentation view, not in an internal editing or project workspace. It also helps to have these details ready before you begin: - The public page URL you want to test directly - The expected starting point for the reader, such as a landing page or category page - The expected next step after the page, such as a related page or follow-up section - Any review notes from earlier audience planning work If you need help getting into Atloria or reaching the correct workspace first, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). If you need to confirm how public readers browse published content before testing audience behavior, see [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience). The next step in this audience workflow is [Planning Audience Specific Release Views](doc:planning-audience-specific-release-views). ## Identifying Which Parsing Outputs Belong in Your Docs Workflow After you review coverage in [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage), the next job in Atloria is deciding which parsed results should feed your documentation work. In the Code Parsing workspace, focus on results that can directly support pages your team already maintains: file paths, exported items, route entries, inline descriptions, type details, imports, and configuration keys. These are the most useful starting points because they describe what exists in the codebase without requiring writers to inspect every file manually. A practical way to organize this in Atloria is to map each result type to a documentation outcome: | Parsing result | Best documentation use | |---|---| | File paths and folder structure | Project structure pages and onboarding docs | | Exported items and signatures | Technical reference pages | | Route entries | Endpoint and navigation-related docs | | Imports and dependencies | Architecture and relationship pages | | Inline descriptions | Draft summaries for reference content | | Configuration keys | Setup and configuration docs | Keep a clear line between parser facts and writer judgment. Parser facts are items Atloria can surface directly from uploaded code, such as a file location, an exported name, a route path, or a parameter list. Writer judgment is everything that explains meaning: when to use something, why it matters, what readers should avoid, and how it fits a workflow. Use parsed results to build the skeleton of a page, but treat explanations and recommendations as editorial work. Before your team uses parsed results in a draft, make sure each item includes enough identifying detail to be trustworthy. At minimum, confirm the result shows the repository path, language, item name, signature or visible structure, visibility level if available, and source location. If any of those details are missing in Atloria’s parsing results, the item may still help with research, but it is not a strong candidate for direct documentation drafting. [SCREENSHOT: Code Parsing workspace showing parsed result types such as file paths, exports, routes, and configuration entries] ## Turning Parsed Code Data into Technical Reference Pages In Atloria, parsed results are most valuable when you turn them into structured reference pages instead of leaving them as raw findings in the Code Parsing workspace. Start with exported items and signatures. These results usually give you the page title, where the item lives, what inputs it expects, what it returns, and how it is exposed to other parts of the project. That information can fill the core sections of a reference page: name, source file, inputs, outputs, visibility, and related items. When Atloria shows grouped exports by file or package area, use that view to plan parent-and-child reference pages. A higher-level page can describe a folder, package, or module area, while linked child pages cover individual exported items. If the parsed results show relationships such as inheritance, implemented interfaces, or shared types, include those as “Related reference pages” links so readers can move naturally between connected entries instead of searching from scratch. Inline descriptions are helpful, but they should be treated as draft material. If Atloria surfaces comments or short descriptions from the code, pull them into a draft summary and then review the wording before publishing. Some descriptions are written for developers and may be too brief, too internal, or too inconsistent for end-user technical docs. If an exported item has no inline description at all, flag it for writer follow-up rather than publishing a nearly empty page. You can also use relationship data to improve navigation. Imports, shared types, and call links often reveal which reference pages belong together. In Atloria, connect these pages with links such as “Used by,” “Depends on,” or “Related pages” where that relationship is clearly supported by the parse results. This makes your reference section easier to browse and reduces duplicate explanations across pages. [SCREENSHOT: Draft technical reference page in Atloria populated from parsed exports and linked related entries] ## Using Parse Results to Explain Project Structure and System Behavior Parsed results in Atloria are not only for reference pages. They also help you explain how a project is organized and how work moves through it. Instead of manually listing folders and guessing responsibilities, use the parsed directory tree, entry files, and grouped file areas to build project structure pages. These pages are especially useful for onboarding writers, reviewers, and subject-matter experts who need a quick map of the repository before editing documentation. Start with the broadest visible structure: top-level folders, major feature areas, and known entry points. In Atloria, these parsed results can help you describe where account access screens live, where admin workspace pages appear, where project pages are grouped, and where public documentation views are defined. That gives readers a practical orientation without requiring them to inspect code line by line. Dependency and import views are useful for explaining interaction between areas of the project. If one area consistently depends on another, document that relationship as part of the project structure story. If Atloria reveals unexpected cross-connections, note them as review points for your team. These findings can help you explain why a workflow touches several areas, such as account access, project setup, document editing, analytics, and publishing. Route-related parse results also help you describe user-facing flows. For example, if Atloria shows routes for login, registration, admin analytics, project analytics, or webhook-related pages, you can use those findings to map visible navigation paths and screen groupings. Configuration keys are another important source. When parse results reveal named settings that affect workflows, use them to identify setup topics your docs should cover, especially when behavior changes by project, organization, or connected feature. The goal is not to reproduce a code map. It is to turn parsed structure into readable documentation that explains how Atloria’s screens, workflows, and connected areas fit together. ## Planning Documentation Coverage from Gaps in the Parsed Data One of the best uses of parsed results in Atloria is finding what your documentation does **not** cover yet. Gaps become easier to spot when you compare parsed outputs with your existing docs set. Publicly exposed items with no description, route entries with no matching page, and configuration keys with no setup guidance are all strong signals that your team has missing documentation work. Use the Code Parsing workspace to sort findings by likely impact. Start with items that appear central to the reader experience: visible routes, heavily connected exports, shared types, and files near entry points. These usually affect more pages and more workflows than isolated items buried in a narrow feature area. If Atloria shows import frequency, dependency relationships, or placement in core project areas, use those signals to rank what should be documented first. Grouping also matters. Rather than assigning work file by file, create documentation sets based on visible project areas in the parsed results. For example, you might group account access pages together, admin workspace pages together, project analytics pages together, and integration-related pages together. This makes assignments cleaner and helps writers stay consistent within a topic area. Parsed results are also useful for drift tracking. When a file moves, a visible item is renamed, a route changes, or a parameter list no longer matches your published page, your documentation may already be out of date. Comparing current parse results with published content in Atloria helps you catch those changes before readers do. This is especially important for technical reference pages, setup instructions, and workflow documentation that depends on exact names and locations. If your team already publishes reference content, use parsed gaps as a planning queue rather than a one-time cleanup list. That turns code parsing into an ongoing documentation maintenance process. [SCREENSHOT: Atloria documentation planning view with parsed gaps grouped by feature area and priority] ## Reviewing and Enriching Parser-Derived Drafts Before Publishing Parser-derived drafts in Atloria can save time, but they should never be treated as publish-ready without review. Before a draft becomes part of your project documentation, verify that the parsed details still match the current source. Check the source location, visible signature, and the branch or repository state used for the parsing run. If the parse results came from an older upload or a previous workspace session, the draft may already be stale. Once the factual details are confirmed, add the context that parsing cannot reliably provide. Atloria can help surface names, relationships, and structure, but it cannot fully explain business meaning, audience expectations, workflow consequences, or when a reader should choose one option over another. Writers still need to add plain-language explanations, usage notes, limitations, and examples that fit the project’s audience. This review step is also where you standardize naming. Parsed results often reflect inconsistencies in the source material, such as mixed naming styles, uneven descriptions, or overlapping patterns across files. In Atloria, keep your published page titles, section names, and cross-links consistent even if the parsed source data is not. That makes the documentation easier to scan and reduces confusion for readers moving between related pages. A simple editorial workflow helps keep quality high: 1. Confirm the parsed facts match the current code results in Atloria. 2. Rewrite draft descriptions so they fit the audience and documentation style. 3. Add missing context, examples, and workflow notes. 4. Check related links so readers can move to connected pages. 5. Send the page through technical review and writer review before publishing. This is especially important for pages generated from route data, configuration keys, and exported items, because those pages often look complete at first glance even when they still lack the explanation readers actually need. ## Fixing Common Problems in Parse-Driven Documentation Workflows When parsed results in Atloria do not line up with what your team expects, start by checking scope before rewriting documentation. Missing items often come from incomplete parsing coverage rather than missing features. If a route, export, or configuration entry is absent, review whether the language is supported, whether the relevant folders were included in the parsing run, and whether generated or excluded files were filtered out. A missing result in the workspace usually means you should fix the parsing input before updating docs. Relationship data can also be incomplete. Imports and dependency links are useful, but they may not capture every connection when a project uses aliases, indirect loading, generated files, or patterns that are harder to trace. If Atloria shows a relationship that seems too thin or misses an expected connection, treat the graph as a guide for review, not final proof. Confirm important links by opening the related parsed entries and checking the surrounding context. Another common issue is noisy draft output. Not every parsed item belongs in published docs. Internal-only members, test files, deprecated exports, and private implementation details can clutter reference pages and make navigation harder. Before generating or approving drafts, filter the results to focus on reader-facing material. This keeps your technical docs useful instead of overwhelming. Stale inputs are just as risky as missing ones. After merges, refactors, dependency changes, or route updates, rerun parsing in Atloria so your documentation work reflects the current project state. If a page still references an old file path or outdated signature, compare it against the latest parsing session and update the draft before publication. When problems repeat, use the parsing workspace as a maintenance checkpoint. Review scope, rerun parsing, confirm relationships, and trim noise before your team spends time editing pages based on incomplete results. ## Overview Atloria’s Code Parsing workspace helps documentation teams turn raw repository analysis into usable documentation inputs. In this stage of the workflow, you are no longer just checking whether parsing succeeded. You are deciding how parsed results should support reference pages, project structure docs, setup guidance, and documentation planning across a project workspace. The most useful outputs in Atloria are the ones that describe visible structure and reusable facts: exported items, file paths, route entries, imports, inline descriptions, and configuration keys. These results can speed up technical writing by giving you a reliable starting point for names, locations, relationships, and page groupings. They are especially helpful when you need to document large projects with many screens, connected features, and technical reference areas. This guide focuses on how to use those results responsibly. Parsed data is strong at showing what exists and where it appears. It is not enough on its own to explain business purpose, user impact, release differences, or editorial meaning. That is why the workflow in Atloria combines parser-derived facts with writer review before anything is published. Use this guide when you want to: - Turn parsed results into draft reference pages - Explain project structure using repository findings - Identify documentation gaps from missing descriptions or uncovered routes - Review parser-generated drafts before they move into published docs - Clean up common issues such as missing items, noisy output, or stale parsing sessions If you need help reading coverage and completeness first, return to [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage). The next step after this guide is [Reviewing Code Parsing Results Symbols and Dependencies](doc:reviewing-code-parsing-results-symbols-and-dependencies), where you will look more closely at how individual parsed items connect. ## Prerequisites Before you use parsed results to support technical docs in Atloria, make sure you already have a project workspace with code parsing results available to review. This guide assumes you are working from completed parsing output rather than starting a new upload. You should be comfortable with these parts of Atloria before continuing: - Opening a project workspace and accessing the Code Parsing area - Reviewing parsing sessions and choosing the correct result set - Checking coverage and completeness for the uploaded repository - Navigating existing documentation pages in the same project - Recognizing the difference between draft content and published content It helps if you have already worked through these related guides: - [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace) - [Managing Code Parsing Workspace Sessions](doc:managing-code-parsing-workspace-sessions) - [Using Code Parsing to Support Technical Documentation](doc:using-code-parsing-to-support-technical-documentation) - [Uploading and Parsing Code for Documentation Workflows](doc:uploading-and-parsing-code-for-documentation-workflows) - [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage) For the smoothest workflow, make sure: - The repository you want to document has already been parsed in Atloria - You are looking at the latest parsing session for the current project state - Your team knows which documentation areas are in scope, such as reference pages, setup docs, or project structure pages - You have permission to edit or plan documentation in the project workspace If your next task is to inspect parsed items in more detail, continue with [Reviewing Code Parsing Results Symbols and Dependencies](doc:reviewing-code-parsing-results-symbols-and-dependencies). ## Understanding What Public Readers See When Audience Targeting Is Applied When audience targeting is active in Atloria, public readers do not see the full internal page tree. They only see the published pages and sections that are available to their audience. This changes the reading experience in a very specific way: the left navigation stays clean and only lists pages the current reader can actually open. If you already read [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation), think of this as the same published navigation experience with one important difference: visibility rules can remove pages from view entirely. Atloria does not show restricted pages as grayed out items or blocked links. If a page is not available to that audience, it is simply missing from the side navigation. This means the page hierarchy still matters, but readers may see a shortened version of it. A parent page can still appear in the left navigation while only some of its child pages are shown underneath. If several sibling pages exist internally, a public reader may only see the ones that match their audience access. The result is a filtered page tree that still follows the original structure as closely as possible. For example, a reader may open a published guide and see a parent page with only two visible child pages, even though your team sees more pages in the authoring workspace. That is expected when some pages are audience-restricted. The reading path is still shaped by parent and child relationships, but hidden pages do not interrupt the public experience because they are removed rather than displayed as unavailable. [SCREENSHOT: Published documentation page showing left navigation with some child pages visible and others omitted due to audience targeting] ## Moving Through the Side Navigation and Page Tree In Atloria’s published documentation, the left navigation panel is the main way readers move through related pages. When audience targeting is applied, readers still move through the same page hierarchy, but only through the branches available to them. 1. Open a published documentation page. 2. Look at the left navigation panel to find the current page in the page tree. 3. Use the visible parent pages and child pages to move to related content. 4. If a section has nested pages, expand or collapse it using the arrow or disclosure control beside the page title. 5. Select another page title to open it. As you move through the page tree, hierarchy cues help you understand where you are. Parent pages appear higher in the tree, child pages are indented underneath them, and the current page is usually highlighted so you can tell which page is open. Expanded sections show available child pages. Collapsed sections hide them until you open that branch. Audience targeting affects what appears inside each branch. A visible parent page may show only a few child pages, even if more exist in the workspace. That is normal. Atloria only shows child pages that are both published and available to the current audience. If a page in the middle of a hierarchy is not available to the current audience, the visible tree adjusts around that restriction. Readers do not see a broken placeholder for the missing page. Instead, they see the remaining published path that is available to them. This is why a branch can look shorter or simpler in the public view than it does for authors managing the full documentation structure. [SCREENSHOT: Left navigation panel with highlighted current page, indented child pages, and an expanded branch] ## Using the Table of Contents on a Page with Audience-Specific Sections The table of contents on a published page helps readers jump to sections within the page they are currently viewing. In Atloria, this table of contents is built from the headings that are visible on that page. When audience-specific sections are used, the table of contents changes to match what the public reader is allowed to see. If a page contains headings for both public content and audience-restricted content, only the visible headings appear in the table of contents for that reader. A heading inside a hidden section is not listed. This keeps the page navigation accurate and prevents readers from clicking links to sections they cannot access. To use the table of contents, readers open a published page and select a heading from the on-page list. Atloria then moves them directly to that section on the same page. This is especially useful on long pages with multiple heading levels, because readers can skip straight to the part they need without scrolling through the full page. Audience filtering can explain why a heading expected by an internal author does not appear publicly. If your team knows a page includes a section such as advanced setup, internal process notes, or audience-specific instructions, that heading may be visible in the workspace but absent from the public table of contents. In the public view, Atloria only includes headings from sections that remain visible after audience rules are applied. This also means the public table of contents may be shorter than the authoring version of the same page. That is not a formatting problem by itself. It usually means the page contains hidden sections that are intentionally excluded for the current audience. [SCREENSHOT: Published page with table of contents showing only visible headings for the current audience] ## Checking the Reader Experience as a Documentation Manager If you manage documentation in Atloria, it is important to review the public reading experience instead of relying only on the internal page tree. Audience targeting can change both the left navigation and the table of contents, so a quick check in the published view helps you catch confusing gaps before you share links. Start by reviewing the page hierarchy in your documentation structure. Confirm which pages are published for general public visibility and which pages are limited to specific audiences. Pay close attention to parent and child relationships. A parent page may still be public even when some of its children are restricted, and that can be perfectly fine if the remaining child pages still make sense on their own. Next, open the published site and move through the same branch as a reader would. Check the left navigation panel and make sure the visible page list feels complete. If a parent page appears with only one or two visible children, verify that those page titles still provide enough context without the hidden siblings around them. Then inspect individual pages that contain mixed content. On pages with both public and audience-specific sections, compare what appears in the page body with what appears in the table of contents. The visible headings in the table of contents should match the sections a public reader can actually scroll to and read. This kind of review is especially useful before sharing a published documentation link with customers, partners, or external readers. It helps you confirm that Atloria is presenting the right navigation path and that hidden content is removed cleanly rather than leaving the page feeling incomplete. [SCREENSHOT: Published documentation preview showing side navigation and table of contents for a manager reviewing audience-specific visibility] ## Designing Page Hierarchies That Still Read Clearly for Different Audiences A clear page hierarchy matters even more when different audiences see different parts of your published documentation. In Atloria, the best public navigation experience usually starts with keeping the most important orientation pages visible to everyone who needs them. That way, readers still understand where they are, even when some child pages are hidden. Keep broad, high-level pages public whenever possible. Introductory pages, section landing pages, and general workflow pages give readers context before they move into more specific content. If those pages remain visible, the left navigation still feels complete when audience-restricted child pages are removed. Be careful about relying on a restricted page in the middle of a branch to explain the pages underneath it. If that middle page is hidden from a public audience, the remaining visible pages may appear without enough context in the side navigation. Readers may still be able to open those pages, but the branch can feel abrupt or incomplete. Use headings consistently inside each page as well. A strong heading structure makes the table of contents useful even after audience-specific sections are filtered out. If your public sections use clear heading levels and descriptive titles, readers can still scan the page and jump to the right section without seeing the hidden material. Before sharing published links, test the hierarchy from each audience view you intend to support. Open the published documentation as that audience and move through the left navigation branch by branch. Then open longer pages and confirm that the table of contents still reflects the visible content in a way that feels natural to a first-time reader. For planning related audience structure, see [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Applying Audiences to Documentation Structure and Content Decisions](doc:applying-audiences-to-documentation-structure-and-content-decisions). ## Fixing Missing Pages, Empty Navigation Branches, and Incomplete Tables of Contents When something looks wrong in published navigation, the cause is often a visibility setting or a page structure issue rather than a publishing error. In Atloria, you can usually narrow the problem down by checking whether the missing item is restricted, unpublished, or placed in a branch that no longer makes sense after filtering. A page does not appear in the side navigation: - Check whether that page is restricted to an audience that does not include the current public reader. - Confirm the page is published. - Review its parent page. If the parent is not available in the published structure, the page may be harder to discover through navigation. A navigation branch looks incomplete: - Compare the public view with your internal documentation structure. - Confirm that missing sibling pages or child pages are intentionally restricted. - Make sure the remaining visible pages still read clearly without the hidden pages around them. The table of contents is missing expected entries: - Open the published page and look for whether the related section is visible at all. - If the section is hidden for that audience, its heading will not appear in the table of contents. - Also check whether the content uses proper page headings rather than plain bold text or styling that does not create a table of contents entry. A direct link opens a page, but readers cannot find it from navigation: - Review where that page sits in the page tree. - Check whether the parent path is visible to the same audience. - If the page is reachable only by direct link, consider whether its placement in the hierarchy still works for public readers. If you need to validate how a specific audience sees published pages, [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience) is a helpful companion. ## Overview - Atloria’s published navigation changes based on audience visibility. - Public readers only see pages and page sections available to their audience. - The left navigation does not show restricted pages as disabled items; those pages are omitted entirely. - Parent and child relationships still shape the reading path, even when some pages are hidden. - The table of contents only includes headings from sections visible on the current published page. - Documentation managers should review the public view to confirm that navigation branches, page titles, and in-page headings still make sense after filtering. - Clear public landing pages and consistent heading structure make audience-specific documentation easier to browse. This guide focused on how audience targeting changes what readers see in the published navigation. The next step is [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page). ## Prerequisites - You should already be familiar with the basic public reading experience described in [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation). - You need access to a published documentation site in Atloria. - To verify audience behavior as a documentation manager, you should also have access to the project’s published documentation structure and audience visibility settings. - It helps to review pages that include: - Parent and child pages in the left navigation - Nested page branches - Long-form content with multiple headings - Pages or sections that are visible only to selected audiences ## Understanding what appears on a technical entity page In Atloria, a technical entity page is the detail view for one specific reference item inside your project’s technical documentation. You usually open it when you need more than a section list or summary page can show. Instead of presenting a broad topic, this page focuses on one named item and gathers the generated reference details that Atloria has attached to it. The first thing to check is the page title. This tells you which entity you are viewing. Near that title, you may also see an entity type label that helps you tell one kind of item from another when names are similar. This is especially useful in larger documentation sets where the same name may appear in more than one place. Below or beside the title, Atloria may show a metadata area with identifying details, source information, and relationship clues that help you understand where this item belongs. Another important area is the related references list. This section helps you move beyond the single page by showing connected technical topics. Depending on the documentation structure, these links can help you move to surrounding items, related entries, or the source topic where the entity appears in context. This makes the page useful not only for reading one record, but also for tracing how the documentation is organized. It helps to think of the page as having two layers. One layer is the entity record itself: the named item you opened. The other layer is the generated reference information Atloria displays alongside it, such as identifiers, source placement, and related links. Together, these details help you understand how technical topics are grouped and connected across the documentation set. [SCREENSHOT: Technical entity page showing the title, type label, metadata area, and related references section] ## Opening an entity detail page from technical documentation If you already know how to move through API reference sections from [Exploring API Reference Sections Inside Projects](doc:exploring-api-reference-sections-inside-projects), the next step is opening one specific entity page. In Atloria, you typically start from a technical documentation index, a reference topic list, or search results inside a project. From there, click the entity name you want to inspect. When several items have similar names, use the visible label or type indicator shown in the list before you open anything. That extra label helps you choose the correct entry instead of guessing based on name alone. This matters when a documentation set includes multiple related items with overlapping names. If the listing includes surrounding context, such as the parent topic or section, use that too before selecting the link. After the page opens, confirm that you are on the correct record right away. Start with the page title, then look for the entity identifier or other identifying detail shown near the top of the page. If the name matches but the surrounding details do not, you may have opened a different item with a similar label. It is faster to verify this immediately than to read the full page and realize later that you are in the wrong place. You should also check the breadcrumb trail or any parent topic links near the top of the page. These show where the entity sits inside the technical documentation hierarchy. If the breadcrumb path does not match the area you expected, use it to step back to the correct section and choose a different item. [SCREENSHOT: Technical documentation list with entity links and visible type labels] [SCREENSHOT: Entity detail page header with title and breadcrumb trail] ## Inspecting generated reference details on the page Once you are on the entity page, focus on the generated reference details rather than only reading the visible heading. In Atloria, this section helps you confirm exactly how the entity has been captured in the reference set. Look first for the canonical name, identifier, or signature shown on the page. These details tell you how Atloria recognizes that item in the documentation structure. Next, review the metadata fields displayed with the entity. Depending on the page, this may include the source topic, where the item sits within a module or namespace grouping, and any relationship labels that describe how it connects to other entries. Even if you are not working deeply with technical content, these labels are useful because they explain whether the current page stands alone or belongs to a larger group of related items. The related reference area is where the page becomes especially valuable. Use this list to see where the entity is mentioned, linked, grouped, inherited, or otherwise connected. If you are trying to understand why a topic appears in a certain place, or why one item links to another, this section often gives the clearest answer. Open a few of these links when you need to compare nearby entries or confirm that you are following the right branch of the documentation. It is also a good habit to compare the generated reference details with the visible topic heading and surrounding content. If the title says one thing but the identifier, signature, or source topic suggests something else, pause before relying on the page. That mismatch can signal that you need to return to the listing and open a different entity. | Page area | What to check | Why it matters | |---|---|---| | Title and name | The displayed entity name | Confirms the page opened to the expected item | | Identifier or signature | The exact reference detail shown near the top | Helps distinguish similarly named entries | | Source topic | The linked or named topic where the entity belongs | Shows where the item fits in context | | Relationship labels | Any labels describing linked or related entries | Explains how the item connects to other topics | | Related references | The list of connected reference entries | Helps you trace mentions and structure | ## Following related topics to understand documentation structure A technical entity page is often most useful when you treat it as a navigation hub rather than a final destination. In Atloria, the related topic links on the page help you move to connected technical topics so you can understand the bigger structure around the current item. Start with any parent, child, or sibling links shown in the related sections. These links help you move outward from one entity into the surrounding reference hierarchy. As you move between pages, keep an eye on the breadcrumb trail and any section labels shown near the top. These are the quickest way to understand where the current page sits. If you open several related entries in a row, the breadcrumb path helps you avoid losing track of which branch of the documentation you are exploring. This is especially helpful when a project contains many grouped reference topics. You can also use linked reference entries to trace relationships between broader topics and more specific items. For example, a higher-level topic may lead you to a member-level topic, or a type-level entry may lead you to a more detailed item beneath it. Following these links in sequence helps you see how Atloria has grouped generated technical topics into larger sections. A simple reading pattern works well here: - Start on the entity page you need - Check the breadcrumb path - Open one related topic at a time - Compare each page title with its hierarchy position - Return to the previous page if the branch does not match what you expected This approach helps you build a mental map of the documentation. Instead of reading isolated pages, you begin to see how modules, namespaces, packages, or other grouped sections are connected through Atloria’s reference structure. [SCREENSHOT: Entity page with related topic links and breadcrumb hierarchy highlighted] ## Using entity pages for writing, support, and public reading tasks Entity pages are useful for different kinds of work, even when the goal is not the same. For technical writers in Atloria, these pages are a practical way to verify that generated names, signatures, and cross-references appear correctly in the published reference content. When reviewing a documentation version, open the entity page and compare the page title, reference details, and linked topics. This helps you confirm that the generated reference data matches the intended structure before readers rely on it. Support team leads can use the same page differently. When a customer mentions a specific technical item, the entity page helps confirm exactly which documented entry they mean. Instead of searching only by topic title, support staff can inspect the identifier, source topic, and related references to make sure they are looking at the right item. This is especially useful when several entities have similar names or when a question refers to a small part of a larger reference section. Public documentation readers also benefit from these pages. If someone lands on a single entity from search or a direct link, the related references and hierarchy links help them move outward into the surrounding context. Rather than leaving the page to search again, they can use the visible connections on the page to find the parent topic, nearby entries, or the broader section that explains how the item fits into the documentation. Use the entity detail page when you need exact reference data. Use a broader overview topic when you are trying to learn concepts, workflows, or general usage. In Atloria, that distinction matters: overview pages explain ideas, while entity pages help you validate precise reference details and navigate connected technical entries. ## Fixing common problems when entity details or references look wrong If an entity page looks wrong, start by checking whether you opened the correct item. In Atloria, the fastest way to confirm this is to compare three things at the top of the page: the page title, the entity type label, and the breadcrumb path. If one of those does not match what you expected, go back to the technical documentation list or search results and choose the entry again more carefully. Similar names are a common reason for landing on the wrong page. If expected related references are missing, make sure you are on the specific entity detail page and not a broader parent topic. A parent topic may describe a group of items without showing the same linked reference details that appear on an individual entity page. Check whether the page is focused on one named item or on a larger section. If it is a broader section, use the links inside that topic to open the exact entity. Sometimes the generated metadata does not seem to match the visible content. When that happens, compare the page heading, the identifier or signature shown in the reference details, and the linked source topic information. If the heading looks familiar but the source topic points somewhere unexpected, you may be reading a related item rather than the intended one. Open the source topic and review the surrounding entries before continuing. If navigation between technical topics feels confusing, use the breadcrumb links and related topic sections together instead of relying on only one of them. The breadcrumb shows location in the hierarchy, while related links show connections across nearby entries. Reading both at the same time usually makes the structure clearer. | Problem | What to check | What to do | |---|---|---| | Wrong item opened | Title, type label, breadcrumb path | Return to the listing and choose the correct entity link | | Missing related references | Whether the page is a parent topic or a single entity page | Open the specific entity detail page | | Metadata does not match content | Heading, identifier, source topic | Compare all three before using the page | | Navigation feels unclear | Breadcrumbs and related topic links | Use both together to confirm hierarchy | ## Overview Technical entity pages in Atloria give you a focused view of one reference item and the generated details connected to it. They are most useful when you need to confirm exactly what an item is, where it belongs, and how it connects to surrounding technical topics. Instead of relying only on section lists or broad reference pages, you can open an entity page to inspect the title, type label, metadata, and related references in one place. The main value of these pages is precision. The visible heading tells you what you opened, while the generated reference details help you verify that you are looking at the correct entry. Related links and breadcrumb navigation then help you move outward into the broader documentation structure. This makes entity pages useful for checking exact names, comparing similar entries, and understanding how one topic fits into a larger reference hierarchy. Use these pages when you need to: - Confirm a specific technical item - Review generated reference details - Follow links to connected topics - Check where an item sits in the documentation hierarchy - Validate that published reference content matches the expected structure If you need a refresher on moving through project-level reference areas before opening individual items, return to [Exploring API Reference Sections Inside Projects](doc:exploring-api-reference-sections-inside-projects). If you are ready to continue, the next step is [Reading API Reference Sections in Technical Documentation](doc:reading-api-reference-sections-in-technical-documentation), which focuses on reading larger reference sections effectively. ## Prerequisites Before using technical entity pages in Atloria, you should already be comfortable moving through project documentation and opening technical reference areas. You do not need advanced technical knowledge, but you do need to recognize how Atloria presents reference content in lists, search results, and linked topic pages. Make sure you can do the following before starting: - Open a project workspace in Atloria - Navigate to the technical documentation or API reference area - Use a topic list or search results to find a reference entry - Recognize page titles, breadcrumbs, and linked topics - Distinguish between a broad topic page and a single entity detail page These pages are easier to use if you have already read: - [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages) - [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views) - [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation) You may also find it helpful to have already completed [Exploring API Reference Sections Inside Projects](doc:exploring-api-reference-sections-inside-projects), since that document covers how to reach the reference areas where entity links appear. Once you can reliably open a technical reference section, choose a named entry from the list, and confirm its location using breadcrumbs, you are ready to use entity pages as a detailed reference-reading tool in Atloria. ## Confirming access and release prerequisites Before you start release preparation in Atloria, make sure you can open the project workspace and switch to the correct documentation version in the version selector. The version you plan to release should already exist and should be the team’s chosen release candidate, not an older draft or a version still being evaluated. If you need help deciding whether the version is actually ready for release work, use [Managing Project Version Timelines and Status Decisions](doc:managing-project-version-timelines-and-status-decisions) before continuing. Check that the parts of Atloria you need are available to you in the interface. For this workflow, you should be able to: - open the version workspace - start **Generate** or **Regenerate** - open the **Compare Versions** view - review changed pages - update screenshots where needed - open version visibility or access settings - view available export options If one of those actions is missing from the page, stop here and ask an administrator or project owner to confirm your access. You should also confirm that the source content for this release is stable enough to build. In practice, that means your team has already agreed on the content scope for the release candidate. If your project uses a selected branch, connected source, or a defined set of pages for generation, verify that everyone is preparing the same source before you run the build. Before sign-off, most teams in Atloria check the same release items: - content differences against the previous release - screenshot updates on changed pages - visibility and access settings - export needs for reviewers, customers, or archive copies [SCREENSHOT: version selector showing the chosen release candidate in the project workspace] ## Generating the release candidate version Once the release candidate is confirmed, open that version’s details or workspace screen and start the build using **Generate** or **Regenerate**. Use **Generate** when the version has not been built yet, and use **Regenerate** after content, screenshots, or source settings have changed and you need a fresh output for review. 1. Open the project in Atloria and select the release candidate from the version selector. 2. On the version screen, click **Generate** or **Regenerate**. 3. In the build dialog, choose the scope shown for this run. If Atloria offers a choice such as all pages or only changed content, select the option your team uses for release review. 4. Confirm the action and watch the status indicator on the version screen. During processing, the version may show a queued or in-progress state. Wait until the status changes to a completed state before you begin comparison or sign-off work. If you start reviewing too early, you may miss pages that have not finished rendering yet. After the build completes, review the output summary carefully. Look for anything that suggests the release candidate is incomplete, including: - failed pages - missing images or other assets - warnings tied to specific pages - sections that did not generate as expected If the output includes warnings, open the affected pages before moving on. A release candidate can look mostly complete while still hiding missing content in a few topics. It is better to catch those issues now than after reviewers begin approval. [SCREENSHOT: version details page with Generate or Regenerate button and build status] ## Comparing the version against the previous release After the release candidate finishes generating, open **Compare Versions** and set up the comparison using the new release candidate and the previous published version. This gives you a focused view of what changed between releases and helps you decide what needs review before approval. 1. Open the release candidate in Atloria. 2. Click **Compare Versions**. 3. Select the release candidate as the version to review. 4. Select the previous published version as the baseline. 5. Load the comparison results and review the page list. Start with the page-level indicators. These usually help you spot which topics were added, removed, or modified. That high-level view is useful for assigning work to writers, reviewers, and approvers because it shows where the release changed most. Next, open the detailed differences for pages that could affect release readiness. Pay close attention to: - renamed pages that may confuse readers - navigation changes that move or hide important topics - missing generated sections - broken or incomplete links - pages that appear in one version but not the other As you review, separate expected release changes from unexpected ones. Expected changes are the edits your team planned for this release. Unexpected changes are the ones that need correction, clarification, or a second review before approval. If you need a deeper walkthrough of the comparison screen itself, use [Working with Version Comparison Views](doc:working-with-version-comparison-views). For this release workflow, the goal is not to study every small edit. The goal is to identify which differences are acceptable for release and which ones still block sign-off. [SCREENSHOT: Compare Versions view showing added, removed, and modified pages] ## Reviewing pages and resolving screenshot updates Once comparison results show which pages changed, open those pages directly from the comparison list and move through your team’s review process. Focus first on pages with major edits, navigation changes, or visual content, because those are the most likely to create release issues. 1. Open a changed page from the comparison results. 2. Review the page content in preview or the available review view. 3. Check whether the text, headings, links, and page structure match the intended release content. 4. Look for screenshot placeholders, image references, or screenshot status markers that suggest a visual needs attention. 5. Replace outdated screenshots where necessary. 6. Save the page or screenshot update, then regenerate the version if the updated visual does not appear immediately. 7. Mark the page or review task complete using the review controls your team uses in Atloria. Screenshot review is especially important when the release includes interface changes. A page can have correct text but still mislead readers if the screenshot shows an older screen. When you replace a screenshot, confirm that the new image appears correctly in preview and fits the surrounding instructions. Watch for these common visual problems: - an old screenshot still appears after content changed - the image is missing from preview - the screenshot shows a different menu or button label than the text describes - the screenshot was updated on one page but not on related pages If your team tracks review progress inside Atloria, keep page statuses current as you work. That gives the documentation manager a clear view of what is finished and what is still waiting on content, screenshots, or approval. For more detail on managing screenshots across versions, see [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). ## Checking version visibility and export decisions before publishing Before a version moves toward publishing, confirm that people can see exactly what they should see—and nothing more. In Atloria, this means checking the release candidate’s visibility and any page or portal access rules that affect who can open it during final review. 1. Open the release candidate version. 2. Review the version visibility settings and confirm whether it is limited to internal reviewers or available to a broader audience. 3. Check page-level restrictions or audience-related access rules if your project uses them. 4. Confirm that unfinished pages are not exposed through the release candidate view. 5. Open the export options for the version and review which formats are available. 6. Decide whether this release needs export output for review, sharing, or archiving. A release candidate often needs tighter access than a published version. For example, reviewers may need access while general readers should not. Make sure the current settings match that stage of the workflow. When reviewing exports, focus on what your team actually needs for this release. Depending on your setup, that may include: - a PDF for stakeholder review - an offline package for distribution - another export option shown on the version screen Do not treat export as automatic. If screenshots are unresolved, pages are restricted unexpectedly, or the latest generation includes warnings, those issues can affect export quality or completeness. Note those limitations clearly before anyone expects a final deliverable. If you need a deeper review of access controls, use [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access). If you are deciding whether exports are ready, [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness) is the best companion guide. [SCREENSHOT: version visibility settings and export options on the release candidate] ## Fixing common release-preparation issues Even when the workflow is clear, a few problems show up often during release preparation. In Atloria, the fastest way to recover is to trace the issue back to the specific version, page, or access setting instead of restarting the whole process. If generation completes with warnings, open the build output and review the affected pages one by one. Warnings usually point to missing assets, incomplete content, or pages that did not render as expected. Correct the page content or replace the missing visual, then run **Regenerate** again so the release candidate reflects the fix. If comparison results look incomplete, check the versions selected in **Compare Versions**. The most common mistake is comparing the release candidate to the wrong baseline. Make sure the baseline is the previous published version and confirm that both versions finished generation successfully. If one version is outdated or incomplete, the comparison will not be reliable. If updated screenshots do not appear in preview or export, verify that you replaced the image in the correct page and version context. Then regenerate the version if needed. A screenshot may be updated in the library or page settings but still not appear in the rendered output until the version is rebuilt. If reviewers cannot access the release candidate, recheck: - version visibility settings - reviewer permissions - page-level restrictions - audience or portal access rules that may hide the content When a release issue affects approval timing, document the blocker directly in your team’s review workflow so others do not assume the version is ready. That is especially important when the problem is not obvious from the page list alone, such as a hidden access rule or an export that omits restricted pages. ## Overview Coordinating version work before release in Atloria means bringing several review tasks together around one release candidate. You are not just checking whether the version generated successfully. You are confirming that the generated output matches the intended release, that the differences from the previous published version are understood, that screenshots still match the content, and that access and export settings support the release plan. This stage usually happens after your team has already organized the version workspace and made timeline or status decisions. If you still need to confirm where the version sits in the release process, refer back to [Managing Project Version Workspaces](doc:managing-project-version-workspaces) and [Managing Project Version Timelines and Status Decisions](doc:managing-project-version-timelines-and-status-decisions). The key screens you will use in Atloria are: - the version selector - the version details or workspace screen - **Generate** or **Regenerate** - **Compare Versions** - page preview and review views - screenshot-related page controls - version visibility settings - export options This workflow is most useful when the team is close to sign-off and needs a reliable way to catch release blockers before publishing. Instead of reviewing pages in isolation, you work from the release candidate outward: build it, compare it, inspect changed pages, refresh visuals, confirm access, and decide whether exports are ready. The next document in this sequence is [Generating Documentation Versions for Release Cycles](doc:generating-documentation-versions-for-release-cycles), which goes deeper into running version generation as a repeatable release activity. ## Prerequisites Before you coordinate release work in Atloria, make sure the project and version are already far enough along for final preparation. This workflow assumes you are not creating a brand-new version from scratch and not doing early draft review. You are working with a version that already exists and is being prepared as the release candidate. Use this checklist before you begin: - You can sign in to Atloria and open the correct project workspace. - The target version appears in the version selector. - Your team has identified that version as the release candidate. - You can use **Generate** or **Regenerate** for that version. - You can open **Compare Versions**. - You can review changed pages and page previews. - You can update screenshots or coordinate with the person who manages them. - You can review version visibility or access settings. - You can open export options for the version, if exports are part of the release. It also helps to have these decisions already settled: - which earlier version should be used as the comparison baseline - which source content belongs in this release - who is responsible for page review - who confirms screenshots - who makes the final release or export decision If those decisions are still unclear, release preparation can stall even when the version itself looks complete. In that case, return to [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) or [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness) before moving forward. ## Opening the AI usage dashboard and understanding what it measures In Atloria, open the main workspace and go to the **Admin** area. From there, select **Analytics** when you need a high-level view of usage reporting, or open your organization’s **AI settings** area if your team manages AI features there. The usage dashboard is the place to review overall AI activity rather than individual prompts one by one. If you need a refresher on where AI-related reporting fits into broader monitoring, see [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history). At the top of the dashboard, look for summary cards or headline totals that show broad activity for the selected period. These metrics typically help you answer questions such as: - How many AI requests were made - How many people actively used AI features - How much recent activity happened during the selected period - Whether usage is rising, steady, or slowing down These totals are meant for pattern spotting. They help you understand volume and direction, not the details of a single interaction. Use the **date range** control before drawing conclusions from the numbers. Changing the date range updates the totals, the chart, and the request list shown on the page. A short range helps with recent incidents or sudden changes. A longer range is better when you want to compare adoption over time or check whether a spike is part of a larger trend. It helps to separate two views of the same information: - **Usage dashboard view**: shows combined totals, charts, and trends across many requests - **Request History view**: shows individual AI interactions in a list so you can inspect specific activity [SCREENSHOT: AI usage dashboard with summary totals at the top and a date range selector above the chart] Use the dashboard first when your question is “How much AI activity happened?” Switch to request history when your question is “What exactly happened in this request?” ## Reviewing request history for individual AI interactions When you need to inspect specific AI-assisted actions, open **Request History** from the AI administration area. This view shows a time-based list of activity, with the newest entries typically appearing first. Unlike the summary dashboard, this screen is built for investigation. Use it when you need to review a particular user’s activity, check what happened during a failed action, or confirm whether repeated requests came from the same workflow. Start by narrowing the list with the controls available on the page. Common filters include: - **Search** to find matching text - **Date range** to limit the list to a specific period - **User** to focus on one person or a smaller group - **Status** to show only certain outcomes These controls are especially useful when the history list is long. If you are investigating a recent issue, begin with the date filter and then add a user or status filter to reduce noise. Open a single history entry to review its details. Depending on what Atloria shows in your workspace, you may see information such as the person who started the request, the time it happened, the related action or prompt context, and whether the response completed successfully. This is the best place to confirm what happened during one interaction rather than relying on summary totals. The status shown in each entry helps you interpret the result quickly: | Status type | What it means in practice | |---|---| | Successful | The AI action completed and returned a result | | Failed | The request did not complete as expected | | Blocked or limited | The request was stopped or restricted before completion | [SCREENSHOT: Request History list with search, date filter, user filter, and status filter] If you only need broad monitoring, stay in the dashboard. If you need evidence for a support review or policy check, request history is the more useful screen. ## Analyzing activity trends to spot spikes, drops, and unusual patterns The activity trend chart helps you move from raw totals to a clearer story about how AI features are being used over time. After choosing a **date range**, read the chart from left to right and look for changes in request volume. A steady line usually suggests consistent use. Sharp increases or sudden drops deserve a closer look, especially if they do not match your team’s normal work cycle. Begin with the broad pattern. Ask whether the chart shows: 1. A gradual rise in usage over time 2. A sudden spike during a short period 3. A drop that may point to reduced adoption or an interruption 4. Repeated peaks that line up with a recurring workflow If Atloria shows breakdown or grouping controls in the reporting area, use them to compare activity across different parts of your organization. Depending on what is available in your workspace, you may be able to compare usage by user, team, workspace, or feature area. These comparisons help you tell the difference between healthy growth and concentrated activity from a small number of people. A spike does not always mean a problem. It may reflect stronger adoption, a new documentation effort, or a team using AI assistance more heavily during a release cycle. It can also point to repeated retries, inefficient prompting, or misuse. That is why the chart should always be checked alongside **Request History**. For example, if the chart shows a sudden jump, open the matching time period in the history list and review the entries around that window. Look for patterns such as: - Many requests from one user - Repeated failed attempts - A burst of similar actions in a short time - Normal activity spread across several users [SCREENSHOT: Activity trend chart with a selected date range and a visible spike in request volume] This comparison between chart trends and individual entries gives you a more reliable basis for follow-up than totals alone. ## Using usage insights to manage AI-assisted workflows responsibly Usage reporting is most useful when it leads to practical decisions. In Atloria, high request volume often points to workflows where teams rely heavily on AI assistance, such as drafting documentation, reviewing content, or supporting project setup. That does not automatically mean something is wrong, but it does tell you where closer review may be worthwhile. Start with the busiest areas. If one team, workspace, or feature area generates far more requests than others, review whether that usage matches the team’s responsibilities. Heavy use may be expected during documentation generation or large content updates. It can also show that people are leaning on AI for tasks that may need clearer guidance, better prompts, or a more consistent review process. Failed and repeated requests are often even more useful than high totals. Open the history list and look for clusters of unsuccessful entries or repeated attempts close together. Those patterns can reveal: - Prompts that are too vague or inconsistent - Workflows that encourage users to retry the same action - Support issues that are driving repeated requests - AI-assisted steps that need clearer internal guidance You can also use the reporting view to identify who is generating the most activity. That helps administrators decide where to focus coaching, approval oversight, or policy reminders. In many teams, a small number of users account for a large share of requests. Reviewing those patterns can improve consistency without limiting everyone else. For sensitive or high-impact AI use, keep a simple internal review routine tied to what you can actually see in the dashboard and history screens. For example: - Review trend changes during regular admin check-ins - Inspect unusual spikes in the history list - Check repeated failures before they become a support burden - Note recurring high-volume workflows for policy review This kind of review keeps AI use visible and manageable without turning every request into a manual audit. ## Controlling access and setting expectations for administrators and support leads Not everyone in Atloria needs access to AI usage reporting. Because these screens can include user-linked activity and request details, access should be limited to people who have a clear reason to review them. In most organizations, that usually includes: - Project administrators - Documentation managers - Support team leads - Organization administrators responsible for AI settings or oversight Each role may need a different level of review. Project administrators often focus on whether AI activity supports project work as expected. Documentation managers may watch for heavy usage around drafting and revision workflows. Support leads are more likely to open individual history entries when investigating failed requests or unusual bursts of activity. Set clear expectations for what each group should check regularly: | Role | What to review | |---|---| | Project administrators | Overall usage trends and unusual changes tied to project work | | Documentation managers | High-volume content workflows and repeated request patterns | | Support leads | Issue-specific request history and failed or limited requests | | Organization administrators | Cross-team usage patterns and broader oversight | Before anyone reviews prompts, responses, or user-linked records, communicate that these screens may show activity connected to named users and specific AI-assisted actions. Teams should understand that usage reporting is for operational review, support follow-up, and responsible oversight—not casual browsing. It also helps to agree on a review rhythm. Many teams do well with: - A **weekly** check of trend data - A **monthly** review of broader usage patterns - An **incident-based** review of request history when something goes wrong If support leads cannot reach the right screens, coordinate with the people who manage admin access. For broader guidance on admin areas, see [Using the Admin Workspace](doc:using-the-admin-workspace) and [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Resolving common issues when usage data or request history looks incomplete If the AI usage dashboard appears empty or the request list seems incomplete, start with the simplest explanation: the current filters may be hiding the data you expect to see. In Atloria, the selected **date range** affects both charts and totals, so first confirm that you are looking at the right period. A short range can make it seem like no activity happened when the requests actually fall just outside the selected window. If the dashboard still shows no activity, check whether the relevant users or projects are actively using Atloria’s AI features. A blank chart or zero totals may reflect a genuine lack of activity rather than a reporting problem. When expected entries are missing from **Request History**, review every active filter on the page: 1. Clear the **search** box if you entered a keyword 2. Reset the **date range** to a wider period 3. Remove any **user** filter that limits the list 4. Remove any **status** filter that hides successful, failed, or limited requests After clearing filters, reload the view and check the list again. If chart totals do not seem to match your manual count from the history list, compare what each view includes. Summary reporting may count a broader set of activity than the list you are currently viewing, especially if your history screen is filtered to one user or one status. It is also important to check whether failed, blocked, limited, or retried requests appear in the same way across both views. Access problems can also make data seem incomplete. If a support lead cannot open usage reporting or request history, review whether they have the right admin, analytics, or audit-related access for those screens. If needed, work with your organization’s admin team to confirm their permissions. For related admin guidance, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls) and [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Overview This guide focuses on the day-to-day management side of AI reporting in Atloria. Instead of introducing the reporting screens from scratch, it shows how to use them to answer practical questions: who is using AI features, when request volume changes, which entries need closer review, and how administrators can respond when patterns look unusual. The main areas covered are: - Opening the AI usage dashboard from Atloria’s admin or AI-related workspace - Reading top-level totals and understanding what the selected date range changes - Switching from summary reporting to **Request History** when you need to inspect a specific interaction - Using charts and filters to investigate spikes, drops, repeated failures, or concentrated usage - Turning what you see into follow-up actions such as coaching, policy review, or support investigation - Limiting access to the right administrative roles and setting a review routine - Troubleshooting empty charts, missing entries, and permission-related access issues Use this guide after you already know where the reporting screens are and what they generally show. If you need that foundation first, read [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history). This document stays focused on what administrators and support leads do inside the reporting views themselves. It does not cover broader AI setup, provider configuration, or project-specific content workflows. The goal is to help you manage AI-assisted work responsibly using the dashboard, chart views, and request-level history that Atloria makes available. ## Prerequisites Before working through the steps in this guide, make sure the following are already in place: - You can sign in to Atloria and open the main authenticated workspace - You have access to the **Admin** area, AI-related settings, or other reporting screens used by your organization - Your team is already using Atloria features that generate AI request activity - You understand the basic monitoring concepts covered in [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history) It also helps if you are one of the people expected to review AI activity regularly, such as: - An organization administrator - A project administrator - A documentation manager - A support team lead For this guide to be useful, there should be enough recent activity to review in the dashboard or **Request History** list. If your organization is just getting started with AI features, you may not see meaningful patterns yet. Have these details ready before you begin an investigation: - The approximate date range you want to review - The user, team, or workspace you are checking, if known - Whether you are looking for general trends or a specific request - Any known issue window, such as a recent spike or failed action If you are unsure whether your account has the right level of access, check with the people who manage admin permissions in Atloria before you begin. After you are comfortable managing usage and request history, continue with [Monitoring AI Usage and Request Activity](doc:monitoring-ai-usage-and-request-activity) to follow activity patterns more closely. ## Opening a project's audit history and understanding what each entry shows In Atloria, start from the project workspace, then open the area where project activity and audit records are listed. If you already worked through [Managing Audit Exports and Activity Records](doc:managing-audit-exports-and-activity-records), use the same project-level audit view rather than a general dashboard summary. For compliance work, make sure you are looking at the project’s own audit history so the entries match the release or review request you are preparing. [SCREENSHOT: Project workspace with the audit history or activity area highlighted] The audit list is most useful when you read it as a timeline of recorded changes. In most cases, each row shows a few core details you should pay attention to: | What to look at | Why it matters | |---|---| | Timestamp | Shows exactly when the action happened | | User | Identifies who made the change | | Action or event type | Tells you what kind of change was recorded | | Affected item | Shows what page, version, setting, or record was changed | This audit history is different from a general project update feed. A project update may help you understand what is happening overall, but the audit history is the record you use when you need evidence of a specific action. It focuses on tracked changes rather than broad progress notes. During release checks or compliance reviews, look closely for entries tied to important control points, such as: - status changes for documentation versions - approval decisions and review completions - metadata edits - visibility or publication changes - permission-related updates - file, page, or content updates When you open this screen, scan the action labels first. That helps you quickly separate routine activity from the records that matter for an audit trail. ## Finding the records needed for a compliance or release review Once you are in the audit history, narrow the list before you export anything. A long activity list is hard to review and usually includes records that are not relevant to the release window or compliance request. Use the filters available on the page to focus only on the events you need. 1. Set the **date range** to match the review period, release window, or requested audit timeframe. 2. Filter by **user** if the review is focused on actions taken by a specific approver, editor, or administrator. 3. Filter by **action type** to isolate records such as approvals, status changes, publication updates, or permission changes. 4. If the screen offers project-area filtering, narrow the results to the part of the project involved in the review. 5. Change the sort order to **newest first** or **oldest first**, depending on whether you need a quick check or a full event sequence. [SCREENSHOT: Audit history filters for date range, user, and action type] For release reviews, search for milestone events rather than every small edit. Common examples include a review being completed, an approval being recorded, a version status changing, documentation becoming visible to readers, or access settings being updated before publication. If Atloria lets you open a row or expand entry details, use that before deciding the record belongs in your export. The summary line may show that a change happened, but the detail view is where you confirm what actually changed. This is especially important for metadata edits, status updates, and permission-related records, where the exact before-and-after values may matter to an external reviewer. If you need to reconstruct the full sequence, sort from oldest to newest and read the entries as a timeline. That makes it easier to show that the right steps happened in the right order. ## Checking that the export includes the right scope and level of detail Before you click **Export**, decide what the file is supposed to prove. Some reviews need a complete filtered audit history for a project. Others need only the records tied to one release, one approval cycle, or one compliance request. Taking a moment to define the scope helps you avoid sending too much information or leaving out key events. 1. Decide whether you need the **full filtered list** or only a smaller set tied to a specific release period. 2. Review the visible rows and confirm they match the request you are responding to. 3. Check that each important entry includes the basic compliance details: **who** made the change, **when** it happened, and **what** changed. 4. Look for gaps caused by filters that are too narrow, date ranges that end too early, or record types that are not currently shown. 5. Reopen any important entries to confirm the detail shown on screen is enough for the exported record. A good compliance export usually includes the actions that explain the decision path around a release. For example, if you are preparing evidence for a release review, do not include only the final approval. Include the related status changes, review completion records, and any publication or access changes that happened around the same time. Sometimes the audit file alone is not enough. If the export shows that a version changed status but does not fully explain why that version mattered, capture supporting context from the project page or the related release record as a separate reference. This gives reviewers the business context while the audit export provides the tracked evidence. [SCREENSHOT: Filtered audit list showing release-related entries ready for export] If anything looks incomplete on screen, fix that first. It is much easier to correct the scope before exporting than to explain missing records later. ## Exporting audit records for external review When the filtered audit history looks correct, start the export directly from that page. In Atloria, use the **Export** action or the export menu available in the audit history area. Start from the filtered view you already checked so the downloaded file reflects the exact records you intend to share. 1. Open the project’s **Audit History** or activity record screen. 2. Apply the filters for the correct **date range**, **user**, **action type**, and any other available limits. 3. Click **Export** or open the export menu. 4. Choose the available file format, such as **CSV** or another downloadable report option shown on the screen. 5. Confirm the export and download the generated file. 6. Open the file right away and compare it with the filtered audit list. [SCREENSHOT: Export button on the audit history page with format options visible] As you export, make sure the current filters are still active. The file should reflect the same date range, visible record types, and narrowed scope you reviewed on screen. If the list was sorted to help you inspect the sequence, keep in mind that the export may follow the current view or a default ordering, so always verify the downloaded result. After download, check whether the exported columns match what you saw in the audit table and any entry detail panel. At minimum, the file should clearly show the event timing, the person who made the change, the action label, and the affected item or changed value where available. Use a file name that ties the export to its purpose. A clear naming pattern makes later review easier, especially when you prepare several exports for the same project. Include the project name, the release or review period, and the export date if that information helps your team distinguish one file from another. ## Reviewing exported files before sharing them outside the system Do not send the file as soon as it downloads. Open it first and compare it with the filtered audit history in Atloria. This quick review helps you catch missing rows, extra activity, or formatting problems before the export leaves your team. Start by checking whether the main columns are readable and complete. You should be able to identify the timestamp, user, action label, and changed value or affected item without guessing. If the file opens in a spreadsheet, scan several rows from the beginning, middle, and end to make sure the data stays aligned. Use this review pass to remove doubt about scope. Look for records that do not belong in the external review, especially activity outside the requested date range or unrelated project changes that slipped in because the filters were too broad. It is better to return to the audit history and export again than to manually edit the file and risk changing the record set. A careful comparison should include: - the first and last timestamps in the file - the number and type of key events included - any approval, status, publication, or permission records expected for the review - whether the exported rows match the filtered screen in Atloria [SCREENSHOT: Exported audit file open beside the filtered audit history screen] It also helps to record a few notes alongside the file for your own team. Note the purpose of the export, the filters used, and the date the file was generated. That way, if someone asks later why a certain record was or was not included, you can trace the export back to the exact review conditions used at the time. ## Fixing common problems with missing, incomplete, or unusable exports If the export does not look right, go back to the audit history screen instead of trying to repair the file by hand. In Atloria, the most common export problems come from filter settings, project scope, or choosing a file format that is hard for reviewers to open. 1. If records are missing, recheck the **date range** first. 2. Confirm you are in the correct **project** and not reviewing another workspace. 3. Review the active **action type** and **user** filters to make sure they are not hiding needed entries. 4. If the file contains too many rows, tighten the filters before exporting again. 5. Open important entries on screen to see whether extra detail is available there. 6. If the file is hard to use, export again in another available format and reopen it. Missing entries are often caused by a date range that starts too late or ends before the final approval, publication change, or release action. Overly narrow action filters can also hide records that matter, such as a status change that happened just before an approval. If the file includes too much activity, avoid deleting rows manually unless your process specifically requires that. A cleaner approach is to refine the audit history view, confirm the new result set, and generate a fresh export. That preserves the connection between what you saw on screen and what you shared. Sometimes the exported columns do not provide enough context for an external reviewer. In that case, open the related audit entries in Atloria and confirm whether the detail view shows the exact value change or affected area more clearly. You may need to provide that screen context alongside the export. If reviewers report that the file opens incorrectly, regenerate it in a different available format and check the column layout again before resending. ## Overview This guide focuses on using a project’s audit history in Atloria as evidence for compliance checks, release reviews, and external requests. The goal is not just to download activity, but to produce an export that clearly shows the right actions, during the right timeframe, for the right project. You begin in the project’s audit history or activity record view, where each entry acts as a tracked record of change. From there, you narrow the list using filters such as date range, user, action type, and project area. That filtered view becomes the basis for your export, so the quality of the export depends on how carefully you review the list before downloading it. This guide also emphasizes the difference between a useful audit export and a broad activity dump. For compliance work, the most valuable records are usually tied to release and control events, including: - review completion - approval decisions - status changes - publication or visibility updates - permission changes - content or metadata edits You will also see when to include supporting context from the project page or release-related screens if the audit rows alone do not fully explain the business event being reviewed. If you need a refresher on the basic export workflow, return to [Managing Audit Exports and Activity Records](doc:managing-audit-exports-and-activity-records). That guide covers the broader export process, while this one focuses on choosing the right audit records for compliance use and validating the file before it is shared outside Atloria. ## Prerequisites Before you prepare an audit export for compliance or release review in Atloria, make sure you have the following in place: - Access to the correct **project workspace** - Permission to open the project’s **Audit History** or activity record view - Permission to use the **Export** action from that screen - A clear review target, such as a release window, approval cycle, or compliance request - Enough project context to recognize the key events you need to include It also helps to know which types of records the reviewer expects. In many cases, that means identifying the release-related actions in advance, such as approval decisions, status updates, publication changes, or access changes. If you are unsure which records matter, confirm the review scope with your team before exporting. Have these details ready before you start filtering: - the project name - the date range to review - the people or roles involved in the actions - the release or compliance milestone being checked - any related project or version details you may need as supporting context If you have not yet worked through the earlier export steps, read [Exporting Audit and Version Records](doc:exporting-audit-and-version-records) and [Managing Audit Exports and Activity Records](doc:managing-audit-exports-and-activity-records) first. They provide the foundation for locating export options and understanding how Atloria presents audit-related records. For the next part of this workflow, continue with [Using Audit History for Release Checks](doc:using-audit-history-for-release-checks). ## Understanding what the Export Center can export In Atloria, the Export Center is where you choose exactly what you want to send out of a project. The main source record is a **documentation version**. From there, you can export either the version by itself or the version together with **related records** that are linked to that selected version. Those related records matter when the destination needs more than the main documentation content, such as supporting items that belong with the same release or handoff. You usually begin from an Export Center list that shows available records, or from a version detail view that leads into export actions for that specific version. In both cases, the workflow starts with the same decision: select the correct source version first. After that, Atloria asks you to choose an export path based on what you need the output to include. The most important difference is scope: - **Single documentation version export** gives you only the selected version. - **Documentation version with related records** gives you the selected version plus linked content that belongs with it. Before you start the export, pause at these decision points: | Decision | What to check | Why it matters | |---|---|---| | Which version to export | Version name, revision, and status | Prevents sending the wrong release | | Whether related records are needed | Linked items associated with that version | Ensures the package is complete enough for its purpose | | What output the destination needs | Review copy, archive, transfer, or handoff | Helps you choose the correct export path | If you already checked readiness in [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions), use that work here instead of repeating it. In this stage, the focus is not whether a version is ready in general, but whether you are choosing the right record and the right export scope for the job. [SCREENSHOT: Export Center list showing documentation versions and an export action for the selected record] ## Preparing the version and related records before export Before you click **Export**, confirm that the version shown in Atloria is the exact revision you mean to send. If the Export Center includes a version selector, use it to switch to the correct version. If you started from a version detail page, review the version name and any visible status or identifying details there before opening the export options. This is the easiest place to catch a wrong selection before Atloria creates the output. Next, review the related records attached to that version. If your export needs linked content, make sure those records are current and belong to the same release or handoff. A version can look correct on its own while still pointing to outdated or incomplete supporting records. When that happens, the export may finish successfully but still be missing important context. Focus on these checks before exporting: - The version name matches the release, review round, or handoff you intend to send - Related records connected to the version are the ones you expect - Names are clear enough that the exported package will be easy to identify later - The source content looks complete, not partially updated It also helps to review whether the record status and visible content match the intended use. For example, a review package may be acceptable with a narrower set of records, while an archive or handoff usually needs a more complete set. If something looks unfinished, go back and update the source records before exporting rather than trying to fix the package afterward. Finally, make sure you can actually use the export actions on the records you selected. If the **Export** action is not available, or if you can open the version but cannot complete the export, your access may not include the required Export Center permissions or source record access. In that case, confirm your access with an administrator before continuing. [SCREENSHOT: Version detail page or Export Center selection area showing the chosen documentation version and linked records] ## Choosing the right export path for your goal The export path you choose in Atloria controls how much content goes into the final output. In practice, you are usually choosing between a **narrow export** and a **broader export**. A narrow export includes only the selected documentation version. A broader export includes that version plus its related records. The right choice depends on what the recipient needs to do with the output after it leaves Atloria. Use this table to match common goals to the best export path: | Goal | Best export path | Why | |---|---|---| | Review copy | Selected documentation version only | Keeps the package focused on the content under review | | Archival package | Version with related records | Preserves supporting context for later reference | | Downstream system transfer | Depends on what the receiving process expects | Avoids sending too little or too much | | Full project handoff | Version with related records | Includes the linked items needed to understand the release | A narrower export is usually better when the recipient only needs the main documentation version. This avoids clutter, reduces confusion, and keeps reviewers focused on the exact revision you selected. It is especially useful when you want a clean output for approval, comparison, or limited sharing. A broader export is better when the destination needs context, continuity, or supporting records tied to the version. This is often the safer choice for archiving, migration, or team handoff because it preserves more of what belongs with the selected version. When you open the export action or export dialog in Atloria, pay close attention to wording that indicates scope. If the option mentions only the selected version, expect a narrower result. If it mentions related records, linked content, or a fuller package, expect a broader result. If you are unsure, compare your goal against [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving) before you run the export. ## Exporting documentation versions and related records 1. Open the **Export Center** in Atloria and locate the documentation version you want to export. If you entered from a version detail page, confirm you are still looking at the correct version before moving on. 2. Select the version from the available records list. In list view, this usually means clicking the row or opening the record so the export actions apply to the right source item. 3. Click the **Export** action. Atloria will present the available export path options for that selected version. Choose whether you want: - only the selected documentation version, or - the documentation version together with its related records 4. Review the export configuration shown in the export dialog or confirmation screen. Check the selected version name carefully. If the export includes related records, confirm that this broader scope matches your purpose. If you only need a review copy, switch back to the narrower option before starting. 5. Start the export. Atloria will create the output based on the path you selected. Depending on the workflow shown in the Export Center, you may see a generated output record, a package entry, or a download-ready result after processing finishes. 6. Monitor the result in the Export Center. Look for the completed export entry and open it when it becomes available. If Atloria provides a **Download** link or a generated package record, use that item to access the exported output. 7. Open the exported result right away instead of assuming it is correct. A quick check immediately after export is faster than discovering later that the wrong version or wrong scope was used. [SCREENSHOT: Export dialog showing a selected documentation version and options to export only the version or include related records] ## Checking that exported output matches the intended use After the export finishes, open the file or package and compare it with what you intended to send. Start with the most important check: make sure the exported content matches the documentation version you selected in Atloria. Look at the version name, visible revision details, and any identifying labels in the output. This helps you catch cases where an earlier or later revision was exported by mistake. If you chose an export path that includes related records, verify that those linked items are actually present in the output. Do not assume they were included just because you selected the broader option. Open the package and confirm that the expected supporting content appears alongside the main version. If the package looks too small or too simple for the path you chose, review it more closely before sharing it. It also helps to compare the exported structure to the destination use case: - **Review**: the output should stay focused and easy to inspect - **Archive**: the package should preserve enough context for future reference - **Migration or transfer**: the output should contain the items needed by the receiving destination - **Delivery or handoff**: the package should include the version and the supporting records the recipient will expect Check visible filenames, package contents, and how items are grouped. If the result feels too narrow, you likely exported only the selected version when you needed related records too. If it feels too broad, you may have included linked content that the recipient does not need. When the output does not match the intended use, return to the Export Center and run the export again with a different path. That is usually faster and cleaner than trying to work around an incorrect package after it has already been shared. [SCREENSHOT: Exported package opened for review, showing the selected version and included related items] ## Fixing common export mismatches and missing content Most export problems in Atloria come from one of four issues: the package is missing records, the wrong version was selected, the export scope does not fit the destination, or the export action is unavailable. Start by identifying which of these happened before you rerun anything. If the exported package is missing expected records, go back to the Export Center and check which export option you used. A package created from **documentation version only** will not include related records. If you expected linked content, rerun the export using the option that includes related records with the selected version. If the wrong version was exported, reopen the source record before you click **Export** again. Confirm the version selector, list selection, or version detail page shows the intended revision. This is especially important when several versions have similar names or belong to the same project. If the output does not fit the destination use case, the problem is usually scope rather than content quality: - For a package that is too limited, choose the broader export path - For a package that includes unnecessary items, choose the narrower export path - For review, keep the export focused unless supporting records are specifically required - For archive or handoff, include related records when context matters If you cannot complete the export at all, check whether the **Export** action is visible and available on the selected record. Also confirm that you can access the source version and any linked records involved in the export. If access appears limited, work with your Atloria administrator to confirm your Export Center permissions and record access. When you need a more detailed readiness check before trying again, return to [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). If the issue is choosing the right package shape rather than fixing source content, compare your options in [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records). ## Overview The Export Center in Atloria is built around a simple workflow: choose a documentation version, decide whether related records should travel with it, run the export, and confirm the result matches its purpose. The main records you work with are documentation versions and the related records linked to those versions. Every export begins by selecting the correct source record, either from the Export Center list or from a version detail page that leads into export actions. The most important choice is export scope. If you export only the selected documentation version, the output stays narrow and focused. If you export the version with related records, the package becomes broader and better suited to archiving, transfer, or handoff. That choice should always be driven by the destination. A reviewer usually needs less than an archive or receiving team. This workflow also depends on preparation. Before exporting, confirm the selected version is the intended revision, review the linked records that may be included, and make sure the visible names and content are complete enough for the package you want to produce. If the export action is unavailable, access to the Export Center or to the source records may need to be updated. After the export finishes, open the result and inspect it. Check the version, the included items, and the overall structure against the reason you created it. If the output is too broad or too narrow, rerun the export with a different path rather than trying to reuse a package that does not fit. ## Prerequisites Before working in the Export Center, make sure these conditions are met: - You can sign in to Atloria and open the authenticated workspace - You can access the project, documentation version, or Export Center area needed for the export - The documentation version you plan to export already exists and is identifiable by name or revision - You know whether your destination needs only the selected version or the version plus related records - Any related records you expect to include are already linked to the selected version - The version and linked records have been reviewed for readiness in [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions) - The **Export** action is available for the records you need to use - You have permission to view the source records and complete export actions in Atloria It is also helpful to decide the destination before you begin: - **Review** usually needs a focused export - **Archive** usually needs a broader package - **Transfer** depends on what the receiving destination expects - **Handoff** often benefits from including related records If you are still deciding which package shape fits your goal, review [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving). The next step after this workflow is [Managing Documentation Exports for Sharing and Archiving](doc:managing-documentation-exports-for-sharing-and-archiving), which covers how to use the exported results once they are created. ## Opening the project version workspace In Atloria, the project version workspace is the main place to monitor documentation versions for a single project. Open your project from the main project area, then go to the section where versions are listed and managed. This workspace is most useful when you want one screen that shows version progress, current state, and the next page you may need to open. When the workspace loads, look first for the version list. Each version appears as its own entry, making it easy to scan several versions without opening them one by one. Alongside the list, Atloria surfaces status information so you can quickly tell which versions are still being worked on, which are ready for review, and which have already moved further through the release process. You should also see action controls tied to each version or to the currently selected version, plus links that let you open the related comparison page or review page. [SCREENSHOT: Project version workspace showing the version list, status badges, and links to comparison and review pages] This workspace is especially helpful for Documentation Managers, Project Administrators, and Technical Writers who need to coordinate version work. Managers typically use it to track progress across multiple versions. Writers often use it to jump into the version that needs checking next. Administrators may use it to confirm the current state before making version-related decisions. Use the project version workspace as your starting point when you are not yet sure which version needs attention. If you already know you need a detailed difference check, the comparison page may be the faster destination. If you already know a version is waiting for a decision, the review page may be more direct. For a refresher on how comparison views work, see [Working with Version Comparison Views](doc:working-with-version-comparison-views). ## Reading the version list and status indicators The version list is the quickest way to understand what is happening across your project’s documentation versions. Each row represents one version and gives you a compact summary before you open any details. In practice, this means you can scan the list to find the version you need, check its current state, and decide whether to open comparison or review next. Start by reading each row from left to right. The version name or identifier tells you which release or documentation set you are looking at. Nearby, Atloria shows the current status for that version. These status indicators are important because they help separate versions that are still in progress from versions that are ready for review or already completed. If you are managing several releases at once, the status display is often the fastest way to decide where to focus. The list may also include supporting details that help you confirm you have the right version before opening it. Depending on what is visible in the workspace, look for labels, badges, or other row-level markers that signal recent activity or a version that needs attention. These visual cues are useful when several versions have similar names or when one version is waiting on review while another is already further along. A practical way to use the list is: - Find the version row that matches the release you are working on. - Check the status badge before opening anything. - Use any visible labels or activity markers to spot urgent items. - Open the next page only after confirming you selected the correct version. If you need a broader explanation of how version states fit into the release cycle, refer to [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness) and [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). ## Moving between comparison and review pages The project version workspace is designed to help you move into detailed version work without losing your place. Once you identify the correct version in the list, select that version and use the available link or action to open its comparison page. The comparison page is where you inspect differences tied to that version and confirm what changed before anyone makes a review decision. 1. Open the project version workspace and locate the version you want in the version list. 2. Check the version’s status so you know whether you should inspect differences first or go straight to review. 3. Select the version and open the **Comparison** page to examine changes connected to that version. 4. After checking the differences, use the workspace navigation options to move to the **Review** page for the same version. 5. When you finish on either page, return to the version workspace and confirm you are still looking at the same version row. [SCREENSHOT: Selected version row with links to open the comparison page and review page] In most cases, open the comparison page first when the version is still being checked, when you need to verify what changed, or when the status suggests work is still in progress. Go directly to the review page when the version is already at a stage where a decision is expected and the changes have already been examined. The key benefit of using the workspace for navigation is that you do not need to back out to the broader project area each time. The version list keeps the current context clear, so you can move from one detailed page to another and then return to the same set of versions. If you want more detail on reading change views before making review decisions, see [Working with Version Comparison Views](doc:working-with-version-comparison-views). ## Managing version actions from one workspace One of the biggest advantages of the project version workspace is that it brings version actions together in one place. Instead of opening several pages just to confirm the state of a version and then act on it, you can review the version list, select the right version, and use the available controls from the same workspace. Look for action controls near the selected version or within the version row itself. These controls are tied to the current version state, so the actions you see may differ from one row to another. For example, a version that is still in progress may offer different options than a version already under review or already completed. This helps prevent you from taking the wrong step at the wrong time. A good workflow is: 1. Select the version from the list. 2. Read the visible status indicator before choosing any action. 3. Use the available action control for that version. 4. Wait for the workspace to refresh or update. 5. Confirm the result by checking the version row again. After an action completes, the clearest sign of success is usually an updated status badge or refreshed version details in the list. If the version moves to a new stage, that change should be reflected directly in the workspace. You may also notice that the available actions change immediately after the update, which is another sign that Atloria has accepted the change. [SCREENSHOT: Version workspace with row-level action controls and updated status after an action] Because action availability depends on status, always check the version row first. If an option is missing, the current version state may not allow that action yet. This is one reason the workspace is so useful: you can see the version’s current state and the allowed next step together, without switching screens. ## Keeping reviews organized across multiple versions When a project has several active documentation versions, the workspace becomes the easiest way to stay organized. Documentation Managers and Project Administrators can use the version list as a live tracking board for the project. Instead of opening each version separately, they can scan statuses, identify which items are still active, and decide where attention is needed first. The most effective approach is to treat the version list as your daily review queue. Versions that are still active stand out through their status display, while completed versions are easier to ignore once they no longer need action. If Atloria shows badges, labels, or row-level indicators, use those visual markers to separate items that need follow-up from items that are already settled. Technical Writers can also work faster from this screen. A writer may start with one version that needs a comparison check, open the comparison page, return to the workspace, and then move to another version already waiting in review. Because the list keeps all versions together, it reduces the risk of working on the wrong release or forgetting which version is currently under review. Helpful habits for multi-version work include: - Scan the full version list before opening any detailed page. - Use status indicators to group versions mentally into active, review-ready, and completed work. - Return to the workspace after each comparison or review task so the next step stays clear. - Check the version row again before taking any action, especially when several versions have similar names. This workspace is the best central checkpoint before any version-related action. It gives you the current state, the available navigation, and the next likely step in one place. For release-stage decision-making after this point, continue with [Managing Project Version Timelines and Status Decisions](doc:managing-project-version-timelines-and-status-decisions). ## Fixing common issues when working with project versions Most issues in the project version workspace come down to selecting the wrong project, viewing an outdated list, or trying to open a page that is not available for the version’s current state. The workspace itself usually gives you the clues you need, especially through the version row and its status indicator. If a version does not appear in the list, first make sure you are in the correct project’s version area. It is easy to confuse similar projects when switching between workspaces. Once you confirm the project, refresh the workspace and check the version list again. If the version still does not appear, compare the visible versions carefully so you do not overlook a similar name. If you cannot move to the comparison page or review page, check the selected version’s status before trying again. Some navigation options are only available when the version has reached the right stage. When the status suggests the version is still earlier in the process, Atloria may not show the next page link yet. If an expected action is unavailable, the status is the first thing to inspect. The workspace only shows actions that fit the version’s current state. A version that is already completed, for example, may not offer the same controls as one still moving through review. If the status looks outdated after you take an action, reload the workspace and recheck the version row. A refreshed list should show the latest state. Confirm the update by looking for: - A changed status badge - Updated row details - Different available actions - Access to the next page in the workflow When you need help understanding whether a version’s current state should allow review activity, see [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness). ## Overview The project version workspace in Atloria is the central screen for managing version activity inside a project. It combines the version list, status indicators, action controls, and links to comparison and review pages so you can manage version work without jumping through unrelated screens. Use this workspace when you need to: - See all project versions in one place - Check which versions are in progress, ready for review, or completed - Open the comparison page for a selected version - Move from comparison into review with less back-and-forth - Confirm whether a version action has updated the version’s status This screen is especially useful when several versions are active at the same time. Instead of relying on memory or opening pages one by one, you can use the visible status display to decide what needs attention first. Documentation Managers often use it to monitor progress across releases. Project Administrators use it to confirm version state before taking action. Technical Writers use it to move quickly between versions that need comparison checks and versions already in review. If you already know exactly which detailed page you need, you can open that page directly. But when you want a reliable starting point that keeps the current version context visible, the project version workspace is usually the better choice. It reduces context switching and helps you avoid acting on the wrong version. For related tasks, you can revisit [Working with Version Comparison Views](doc:working-with-version-comparison-views). The next step after mastering this workspace is learning how version timing and state changes affect release decisions in [Managing Project Version Timelines and Status Decisions](doc:managing-project-version-timelines-and-status-decisions). ## Prerequisites Before working in the project version workspace, make sure you have the basics in place so the version list and related pages are meaningful. You should have: - Access to Atloria with permission to open the project you need - A project that already contains documentation versions - Familiarity with the project’s release naming so you can recognize the correct version in the list - A clear reason for opening the workspace, such as checking differences, reviewing progress, or confirming a version’s current state It also helps if you already understand the earlier parts of the version workflow. In particular, you should be comfortable reading version lists and recognizing version states. If those areas are still new, review [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) before relying on the workspace for day-to-day decisions. If your goal is to inspect changes between versions, be ready to open the comparison page from the workspace. If your goal is to participate in review, make sure the version has reached a status that supports opening the review page. The workspace will help you confirm this by showing the current status and the actions or links available for that version. You do not need to start from a comparison page or review page to use this guide. In fact, the project version workspace is the preferred starting point when you want to confirm the current state first and then decide what to do next. ## Opening Published Documentation and Understanding the Page Layout When you open published documentation in Atloria, you are taken to a reader-facing documentation page rather than an editing workspace. The screen is organized around two main areas: a left-side navigation panel and a main document content area. The left side helps you move through the published documentation set, while the larger content area on the right shows the page you are currently reading. Readers usually arrive in one of three ways: - By opening a published documentation link directly - By landing on a version-specific page link - By selecting a link from another published document page No matter how you arrive, the layout gives you clues about where you are. The left-side navigation shows the broader documentation structure. The main content area shows the current page title and body content. The address bar shows the page path, which helps you confirm whether you are in the expected published documentation set and version. This is different from the browsing approach described in [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page). In that guide, the focus is on locating content. Here, the focus is on understanding how the published page itself supports movement between pages once you are already inside the documentation. Use the layout in two ways: - **Browse through the navigation tree** when you want to scan sections and move through the documentation in order - **Open a page directly by link** when you already know the exact document you need [SCREENSHOT: Published documentation page showing the left-side navigation panel, the main document content area, and the browser address bar with a version-aware path] If you open a direct page link, Atloria should still display the same published reading experience, with the navigation visible alongside the document content. ## Moving Between Documents with the Side Navigation The left-side navigation is the main tool readers use to move between published pages in Atloria. It shows the documentation structure as a list of sections and pages. Some items appear as top-level sections, while others appear nested underneath a parent item. This lets you see how topics are grouped before you open them. When you scan the navigation, look for these patterns: - A single page item opens one document page - A parent item with child pages represents a section with multiple related documents - Expanded groups show the pages available inside that section - Collapsed groups hide child pages until you open them If a group can be expanded or collapsed, changing its state affects only what you can see in the navigation list. It does not change the published content itself. Expanding a group helps when you want to compare nearby topics. Collapsing a group makes the navigation easier to scan when the documentation set is large. As you move from page to page, Atloria should show your current location in the navigation. The open document should appear highlighted or otherwise visually marked so you can tell which page is active. This is especially helpful when several pages have similar titles or when you entered the documentation from a direct link instead of starting at the top of the structure. When you select another page from the navigation: 1. Click the page title in the left-side navigation. 2. Wait for the main content area to update. 3. Confirm that the newly opened page is now marked in the navigation. 4. Keep using the same navigation panel to continue moving through related pages. [SCREENSHOT: Left-side navigation with one section expanded and the current page highlighted] The key benefit is continuity: the document content changes, but the navigation context stays visible so you can keep your place in the published structure. ## Reading and Following Links Inside a Document Page After you open a page from the left-side navigation, most of your time is spent in the main document content area. This is where Atloria displays the published page title and the full body of the document. Readers typically move through the page from top to bottom, then follow links to related topics as needed. Links inside a document page are useful when the writer wants to guide readers to supporting material without making them return to the navigation panel first. In practice, you may see links that move you to another published document page covering a related task, a deeper explanation, or a follow-up topic. These links should keep you inside the same published documentation experience rather than sending you to a private editing view or another workspace. As you read, use links in two ways: - Follow related-topic links when you need more detail before continuing - Use the side navigation again if you want to jump to a different section entirely A good published reading flow in Atloria feels consistent. When you click a document-to-document link, the main content area should switch to the target page, and the left-side navigation should continue to reflect your current place in the documentation set. You should not lose the surrounding documentation context just because you followed a link in the page body. If you manage published documentation, it is worth checking linked pages yourself. Open a few links from within published pages and confirm that they lead to the intended reader-facing page. The destination should display as a published document with the same navigation experience still available. [SCREENSHOT: A published document page with a link in the body content leading to another page in the same documentation set] For related reading patterns, you can continue from this guide into [Finding Content Through Public Documentation Structure](doc:finding-content-through-public-documentation-structure), which focuses more on how the structure itself helps readers locate information. ## Using Version-Aware Paths to Stay in the Right Documentation Version In Atloria, published documentation may be available in more than one release version. When that happens, the page address helps identify which version you are reading. A version-aware path is the version-specific part of the published documentation link. Readers do not need to edit it, but they should know how to recognize it. When you open a published page, check the address bar if you need to confirm version context. If the documentation is versioned, the page path should clearly keep you within that same release as you move between pages. This matters because two versions of the same documentation may contain different instructions, screenshots, or feature descriptions. As you move from one page to another, Atloria should preserve the same version-aware path. If you start in one published version and click a page in the side navigation or a link inside the document body, the next page should remain in that version unless you intentionally switch to another release. Check the URL in these situations: - You followed a link and the content looks different than expected - The page title is familiar, but the instructions do not match your release - You are comparing two releases and want to confirm which one is open - You are validating links before sharing them with readers A quick version check usually involves comparing several pages in the same documentation set and making sure the version part of the address remains consistent. If one page opens under a different version path, readers may end up mixing instructions from different releases. [SCREENSHOT: Browser address bar showing a published documentation page with a version-specific path segment] Version-aware paths are especially important for documentation managers. They help confirm that shared links, navigation items, and in-page links all point to the same published release, which keeps readers from landing in older or unintended documentation. ## Checking That Navigation Matches the Published Structure When you review published documentation in Atloria, it is important to confirm that the left-side navigation matches the structure readers are meant to see. This is less about editing content and more about validating the public reading experience page by page. Start by opening the published documentation and scanning the full navigation tree. Expand any visible parent sections and click through several pages. Each item shown in the navigation should open a valid published document in the main content area. If a page appears in the navigation, readers should be able to open it without leaving the published documentation experience. As you review, compare what appears in the navigation with what appears in the page itself: - The navigation label should clearly match the page readers open - The page title in the main content area should make sense in relation to the navigation label - Parent and child items should reflect the intended topic hierarchy - Pages grouped under one parent should feel like part of the same section It is normal for a navigation label and a page title to differ slightly, but they should still be recognizable as the same topic. If the wording is too different, readers may think they opened the wrong page. You should also check version consistency while reviewing structure. Open several pages from different parts of the navigation and confirm that their page addresses stay within the same published version. Then follow a few links inside the page body and make sure those links also stay in that version. A practical review flow looks like this: 1. Open the published documentation home or a known published page. 2. Expand each visible section in the left-side navigation. 3. Open several parent and child pages. 4. Confirm the page title, navigation label, and page address all align. 5. Repeat the check in another section of the same published version. [SCREENSHOT: Published documentation with multiple navigation groups expanded and a page title visible in the main content area] ## Fixing Common Navigation Problems Readers Encounter Reader navigation issues in Atloria usually show up in a few recognizable ways. The good news is that you can often identify the cause by comparing the current page, the left-side navigation, and the page address. If a page opens but the side navigation does not highlight the current document, first look at the page address. The published page may have opened from a link that does not match the navigation path readers normally use. In that case, the content may still load, but the navigation cannot clearly show where the page belongs. Reopen the page from the left-side navigation and compare the address with the original link. If a link sends readers to the wrong version, inspect the address bar before and after clicking. The target page may be using an older or different version-aware path. This is especially noticeable when the content looks familiar but the instructions do not match the release you expected. Test the link again from the current published version and confirm that the version portion of the address stays consistent. If a document is missing from the side navigation, the page may still exist as a direct link but not be included in the published structure readers browse. Open the page directly if you have the link, then compare it with the visible navigation tree. If readers cannot reach it from the navigation, it is not fully discoverable in the published documentation experience. If navigation labels and page titles do not match, readers may hesitate because they cannot tell whether they are on the correct page. Review both the label shown in the left-side navigation and the title shown in the main content area. They should point to the same topic in plain, recognizable wording. Use this quick comparison table when checking issues: | Problem | What to check | Expected result | |---|---|---| | Current page not highlighted | Page address and navigation path | The open page is visibly marked in the navigation | | Wrong version opens | Version-aware part of the address | The page stays in the same published version | | Page missing from navigation | Visible navigation tree versus direct page link | The page appears in the published structure | | Label and title mismatch | Navigation label and page title | Both clearly describe the same document | ## Overview Managing reader navigation in published documentation means checking how people move through Atloria’s public reading experience after a page has already been published. The most important elements are the left-side navigation, the main document content area, and the page address in the browser. Together, these help readers understand where they are, what they are reading, and how to move to the next topic. The left-side navigation shows the published structure of the documentation set. Readers use it to scan sections, open pages, and keep track of their current location. The main content area displays the selected document page and any links placed inside the page body. The browser address helps confirm whether the page belongs to the correct published version. This guide focuses on managing that reading flow, not on creating pages or publishing them. If you need help locating pages before thinking about navigation behavior, refer back to [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page). Keep these core navigation checks in mind: - Readers should be able to move between pages using the left-side navigation - The current page should remain clear in the navigation - Links inside a document page should keep readers inside the same published documentation experience - Version-aware paths should remain consistent as readers move across pages - Navigation labels, page titles, and page addresses should all point to the same published content [SCREENSHOT: Full published documentation view showing navigation, content, and URL together as one reading experience] The next guide, [Finding Content Through Public Documentation Structure](doc:finding-content-through-public-documentation-structure), builds on this by focusing on how readers use the published structure itself to locate information efficiently. ## Prerequisites Before working through reader navigation checks in Atloria, make sure you have access to a published documentation page that opens in the public reading experience. You do not need the editing workspace for the tasks in this guide, but you do need a live published page or a shared published link that displays the left-side navigation and main document content area. It helps if you already know how to browse within published documentation. If you have not done that yet, read [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page) first. That guide explains how readers arrive at content and recognize the right page before they begin moving through the documentation structure. Have these items ready: - A published documentation link in Atloria - Access to at least one documentation set that includes multiple pages - If available, a published version that uses version-aware paths - A few known document links to test from inside page content You will get the most value from this guide if the published documentation includes: - Parent sections with child pages in the left-side navigation - Links inside document pages that point to other published pages - More than one page in the same published version so you can compare addresses If you are reviewing navigation quality for your team, plan to open several pages rather than checking only one. Navigation issues often appear only when you move between sections, follow in-page links, or compare one page address with another. [SCREENSHOT: Published documentation opened and ready for navigation review, with the left-side navigation visible] ## Understanding How Atloria Stores and Reuses Screenshots In Atloria, screenshots work best when you treat them as shared documentation assets instead of one-off images added to a single page. The usual workflow starts with capturing a screenshot, saving it to the screenshot library, selecting it from the document editor, and then checking it again during version review when product screens change. This keeps one source image available for reuse across multiple guides instead of creating duplicate files every time you edit a page. The main areas you will use are the **Screenshot Library**, the **document editor** image picker, the page editing view where image issues appear, and the version review or comparison workspace where you check whether screenshots still match the current product interface. When you open a page in the editor and add an image, Atloria lets you choose from screenshots that already exist in the library. That makes it easier to reuse approved images and keep documentation consistent. Screenshots are easiest to manage when they are saved with clear identifying details. In practice, writers usually rely on the screenshot preview together with details such as: - the related feature or product area - the documentation page or article it belongs to - the filename - the last updated date These details help you decide whether an image is still current or whether it has already been used somewhere else. Create a new screenshot when the screen has changed, when you need a different state of the same feature, or when the existing image does not match the page you are writing. Reuse an existing screenshot when the same screen and same state are already documented and still accurate. If your team already uses shared screenshot libraries, keep that process aligned with [Using Enterprise Screenshot Libraries for Documentation Teams](doc:using-enterprise-screenshot-libraries-for-documentation-teams). [SCREENSHOT: Screenshot Library showing image preview cards with filename, related page, and last updated date] ## Capturing and Organizing Screenshots for Reuse 1. Open the screenshot capture flow from the area your team uses for screenshot management in Atloria. 2. Enter the details that identify the image clearly. At minimum, use the page or feature context and a descriptive filename. 3. Add any tags your team uses to group screenshots by feature, release, or documentation area. 4. Save the screenshot to the correct library location so other writers can find it later. 5. Open the **Screenshot Library** and confirm the image appears with the expected preview and details. A good screenshot record should be easy to recognize without opening it. Use filenames that describe what the reader sees, not vague names that only make sense on the day you captured them. For example, a filename based on the feature and screen purpose is much easier to find during review than a generic image name. If Atloria shows page associations or feature labels, fill those in when you save the image so it appears in the right searches and filters. When you organize screenshots, think about how someone else will look for them later. Writers often search by document title, feature area, or keyword, so save each screenshot where it matches the guide it supports. If the same image belongs to a specific article, link it to that page during capture or immediately after saving it. Check the saved record before moving on. The library entry should show: - a clear thumbnail preview - the filename you expect - the related page or feature association, if available - the most recent updated date - ownership or attribution details, if Atloria displays them If any of those details are missing or unclear, edit the screenshot record before inserting it into documentation. That small cleanup step makes later review much faster, especially when your team is updating release content across many pages. [SCREENSHOT: Capture form with fields for filename, feature context, tags, and save action] ## Adding Screenshots to Documentation Pages 1. Open the documentation page you want to edit in the **document editor**. 2. Place your cursor where the screenshot should appear. 3. Use the image picker or media selection option in the editor. 4. Search the **Screenshot Library** for the image by filename, page association, or feature tag. 5. Select the screenshot and insert it into the page. 6. Add any available display details such as alt text, caption, alignment, or size. 7. Preview the page and confirm the image displays correctly. When you add screenshots in Atloria, choose them from the screenshot picker instead of uploading the same image again directly into the page. This keeps the screenshot connected to its library record, which makes it easier to review, replace, and trace later. If a screenshot is already approved and stored in the library, selecting it from the picker avoids duplicate copies with slightly different names. You may need to choose between an existing screenshot and a newly captured one. Reuse an existing image when it already matches the page exactly. Choose a new screenshot when the interface has changed or when the page needs a different view, state, or step. Because the inserted image stays linked to its source record, other writers can still see where it came from and whether it has been updated. After inserting the image, check any presentation options the editor provides. If Atloria shows fields for **Alt Text**, **Caption**, alignment, or image size, complete them before saving. Use captions only when the screenshot needs extra explanation. Keep alt text focused on what the image shows in the context of the step. Before you leave the page, open the page preview and verify that the screenshot renders correctly in the right position. Make sure you did not accidentally insert the wrong version of a similar image. If the page is part of a larger release update, this is also a good time to confirm the screenshot is linked to the intended document record and not to an unrelated draft. [SCREENSHOT: Document editor image picker showing search results from the Screenshot Library] ## Reviewing Screenshot Versions During Document Updates 1. Open the document review area or version comparison view for the page or release you are updating. 2. Scan the page for screenshots that no longer match the current Atloria interface or the product screens being documented. 3. Open the screenshot details and review the last updated date, linked pages, and any earlier replacement history shown in the library. 4. Decide whether to keep the existing image, replace it, or capture a new one. 5. Update the screenshot and recheck the page preview or comparison view. Screenshot review is most useful during planned documentation updates, not only after readers report a problem. When you compare an older version of a page with a current draft, look closely at navigation labels, button names, page headers, and panel layouts. Even small interface changes can make a screenshot feel outdated if the surrounding instructions have already been updated. The screenshot details help you make better decisions. If Atloria shows the **Last Updated** date, linked documentation pages, or earlier replacements, use that information before changing anything. A screenshot that appears old may still be correct if the feature has not changed. On the other hand, a recently updated screenshot may still need replacement if it was captured for a different article or a different user flow. When you replace an outdated screenshot, use the linked screenshot record whenever possible so the image can be refreshed without losing its placement in the page. This is especially important when the same screenshot appears in more than one guide. Reviewers and documentation managers can then follow the update more easily through the existing record instead of chasing duplicate files. If your team uses shared review responsibilities, agree on who owns screenshot decisions during release work. Writers usually identify mismatches while editing pages, and documentation managers often confirm whether the updated image is ready for approval. Where Atloria shows ownership, status, or approval indicators tied to screenshot updates, use them consistently so everyone can see what still needs attention. [SCREENSHOT: Version comparison or review view highlighting a page section with an outdated screenshot] ## Keeping Screenshot Usage Consistent Across Multiple Documents A single approved screenshot can support several pages when those pages describe the same screen and the same user action. In Atloria, this is usually the best approach because it reduces duplicate images and keeps related guides visually aligned. If one onboarding guide, one feature guide, and one release note all show the same interface state, reusing the same screenshot record helps your team maintain one trusted image instead of three separate copies. Before replacing a shared screenshot, check where else it is used. A change that improves one guide can accidentally make another guide inaccurate if the screenshot is linked across multiple documents. Review the linked pages listed in the screenshot record, and confirm that the replacement still fits every page that uses it. If the new image only matches one article, create a separate screenshot instead of overwriting a shared one. Consistency also depends on naming and classification. Use the same approach for filenames, tags, and page associations across your team so managers can quickly find all screenshots tied to a feature or release. This matters most when you are reviewing a large set of documentation updates and need to answer questions like “Which pages still use the old navigation?” or “Which screenshots belong to this release?” To keep screenshot usage under control: - reuse approved screenshots for identical UI states - check linked documents before replacing a shared image - keep filenames descriptive and predictable - apply tags and page associations the same way every time - review screenshot freshness during release work, not after publication If your team manages screenshots across broader release planning, pair this workflow with the organization methods covered in [Organizing Screenshots for Documentation and Releases](doc:organizing-screenshots-for-documentation-and-releases) and the reuse practices in [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). [SCREENSHOT: Screenshot details panel showing linked documents that use the same image] ## Fixing Missing, Broken, or Outdated Screenshots 1. Open the page in the **document editor** and look for any missing-image warning or empty image area. 2. Check whether the screenshot record still exists in the **Screenshot Library**. 3. Search for the image by filename, feature tag, or page association. 4. If you find the correct screenshot, reopen the image picker and relink it to the page. 5. Preview the page to confirm the image loads correctly. 6. If the screenshot is outdated, capture a replacement and update the affected linked pages. A missing screenshot usually means one of three things: the image record was removed, it was saved under a different name or filter than expected, or the page was never linked to the correct screenshot in the first place. Start with the library search. Use the filename if you know it, then widen your search with tags, feature names, or the related document title. Also check whether a filter is hiding the image from the current view. If the screenshot appears in the library but not on the page, the page link may be broken or pointing to the wrong image. Open the image picker again, select the correct screenshot, and save the page. Then use the preview to make sure the image displays in the intended position. For outdated screenshots, compare the stored image with the current interface you are documenting. If the page instructions mention buttons, menus, or labels that no longer appear in the screenshot, capture a replacement. Before saving over a shared image, review all linked documents so you do not unintentionally change unrelated pages. When a screenshot cannot be found at all, review the details that affect search: - filename wording - tags - feature or page association - active library filters If repeated search problems come up across your team, standardize naming and tagging before the next release cycle. For broader troubleshooting patterns, see [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) and [Troubleshooting Screenshot Availability Across Projects and Versions](doc:troubleshooting-screenshot-availability-across-projects-and-versions). [SCREENSHOT: Editor warning for a missing image with the option to relink from the Screenshot Library] ## Overview This guide focuses on the day-to-day screenshot workflow inside Atloria documentation work. You use this process when a screenshot needs to be captured, saved into the screenshot library, inserted into a page, reviewed during a documentation update, or replaced because the interface has changed. The goal is not just to get an image onto a page, but to keep that image traceable, reusable, and easy to update later. The most important screens in this workflow are the **Screenshot Library**, the **document editor**, and the review views used during version updates. In the library, you store and find screenshots by details such as filename, feature area, related page, and updated date. In the editor, you insert screenshots through the image picker so the page stays connected to the library record. During review, you compare current documentation against updated product screens and decide whether an image still matches the instructions around it. This guide is especially useful if your team works across multiple guides that reuse the same screenshots. It explains how to avoid duplicate uploads, how to replace outdated images without losing their placement in the page, and how to check linked documents before changing a shared screenshot. It also covers common problems such as missing images, broken placements, and screenshots that are hard to find in search. If you need help with library structure before working through this guide, refer to [Using Enterprise Screenshot Libraries for Documentation Teams](doc:using-enterprise-screenshot-libraries-for-documentation-teams). After you are comfortable managing screenshots inside individual documentation workflows, continue with [Managing Screenshot Operations Across Projects and Releases](doc:managing-screenshot-operations-across-projects-and-releases) to coordinate screenshot work at a broader release level. ## Prerequisites Before you start, make sure you can access the Atloria areas used in the screenshot workflow: - a signed-in Atloria account - access to the project or documentation workspace you need to edit - permission to open the **Screenshot Library** - permission to edit pages in the **document editor** - access to version review or comparison views if you are updating release documentation You should also have the source screen ready before capturing a new screenshot. That means the page, feature, or workflow you want to document is already in the correct state and matches the instructions in your draft. If you are updating an existing guide, it helps to know which documentation pages already use the screenshot so you can decide whether to reuse it or create a separate image. Have these details ready when possible: | Item | Why it matters | |---|---| | Feature or page context | Helps you save the screenshot in the right place | | Descriptive filename | Makes search and review easier | | Related document title | Connects the image to the correct guide | | Tags or labels | Helps teams filter by feature or release | If you are new to Atloria account access or sign-in, use [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). If you need a broader introduction to screenshot handling before focusing on documentation workflows, start with [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation). ## Preparing to Start a Version Generation Job Before you start a new generation run in Atloria, open your project and go to the **Versions** area. This is the workspace where you manage documentation versions and start a new one. Look for the action that creates a version, such as **New Version** or **Generate Version**. If you have already worked through [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness), use the same version workspace so you are starting from the correct project and release context. On the version creation screen, review every field before you submit. Atloria may ask for a version label, an internal identifier, a source selection, and other generation settings. Pay close attention to the version name and any source choice that points to the content you want to generate from, such as the selected branch, content set, or saved source snapshot. If the form includes a template, preset, or generation option, confirm that it matches the type of output you want to produce. Use the form as a final readiness check. If Atloria shows fields such as **Title**, **Slug**, or an output destination, fill them in carefully because these values affect how the generated version is identified later. Also review any default options related to review or publishing so you do not accidentally send an unfinished version further down the release process. Before clicking the submit button, make sure the current documentation is in a stable state: - Resolve draft edits that should be included in this run - Check for missing pages in the document structure - Review any warnings shown on the version form - Confirm screenshots or assets needed for this version are already available - Make sure you are generating from the intended source [SCREENSHOT: Versions area with the New Version or Generate Version action highlighted] ## Starting a New Documentation Version 1. Open your project in Atloria and go to **Versions**. 2. Click **New Version** or **Generate Version** to open the version creation form. 3. Enter the version details shown on the form. Atloria may present fields similar to the following: | Field | What to check | |---|---| | **Version Label** | Use the name reviewers will recognize in the Versions list | | **Internal Identifier** | Confirm it matches your team’s naming pattern | | **Source** | Choose the correct branch, content set, or source snapshot | | **Title** | Make sure the displayed title is accurate | | **Slug** | Check that the version slug is correct and consistent | | **Output Target** | Verify the destination for the generated output | 4. Review any inclusion options before you continue. If Atloria offers settings that control what gets regenerated, check whether the run should include rendered pages, navigation, assets, search-related output, or derived documentation pages. A missed option here can lead to a version that looks incomplete even when the job finishes successfully. 5. Look over the full form one more time. This is the best moment to catch an incorrect source selection or a version name that does not match the release you are preparing. 6. Submit the form to start the generation job. Right after submission, return to the **Versions** list or the job detail view and note the first status Atloria shows. Depending on timing, the job may appear as **Queued**, **Pending**, or **Running**. That first status matters because it tells you whether Atloria accepted the request and placed it into the generation pipeline. [SCREENSHOT: New Version form showing version fields and generation options] ## Monitoring Job Progress While Generation Runs 1. After you submit the version, stay in the **Versions** area or open the version’s detail page to watch the job status. 2. Check the status label first. In Atloria, a generation run typically moves through a short sequence such as **Queued**, **In Progress**, **Completed**, or **Failed**. If the label changes from a waiting state to an active state, the run has started. 3. Review the progress details shown on the screen. Atloria may display indicators such as: - **Percentage complete** - **Current stage** - **Started at** - **Finished at** - **Duration** These fields help you tell the difference between a job that is still moving and one that may be stuck. 4. Open the activity details, results panel, or job log if that option is available on the page. This is where you can see which step Atloria is currently working on, such as content generation, asset processing, validation, or output packaging. 5. Refresh the page or reopen the version detail screen if the status has not changed for a while. A fresh page load helps confirm whether the run is still active or whether the last visible update is simply old. 6. Stop monitoring only when the job reaches a final state. In practice, that means: - **Completed**: the output is ready to inspect - **Failed**: the run stopped and needs attention - **Completed with warnings** or a similar result panel: the version exists, but you still need to review issues If you are tracking several releases at once, compare the **Started at** and **Duration** values across jobs so you can spot unusual delays more quickly. [SCREENSHOT: Version job detail page showing status, progress, stage, and timestamps] ## Reviewing the Generated Version Output 1. Open the completed version from the **Versions** list or from the finished job record. 2. Start with the version summary. Check the visible metadata Atloria shows for the generated result, including the version name, the generation time, the source used for the run, and any job reference shown on the page. This confirms you are reviewing the correct output and not an older version with a similar name. 3. Locate the generated output areas. Depending on what is available in your project, this may include rendered pages, navigation structure, and processed assets. Review the navigation first because it quickly shows whether major sections were included. 4. Open the validation or results panel and read every warning. Atloria may flag issues such as: - Broken links - Missing references - Skipped files - Content that could not be rendered A version can still finish even when these warnings appear, so do not assume **Completed** means everything is ready for review. 5. Use any preview action available on the version to inspect the output before handing it off. Spot-check several page types rather than reading only the home page. Open a few top-level pages, confirm child pages appear in the navigation, and verify that screenshots or other assets display where expected. 6. Compare what you see against the source you intended to generate. If section names, page order, or visible content look older than expected, pause before sending the version to reviewers. This stage is about confidence, not deep approval. You are confirming that the generated version is complete enough to move forward. [SCREENSHOT: Generated version view with navigation, preview area, and validation warnings panel] ## Deciding Whether to Regenerate or Move to Review Once you finish checking the output, use the final result state in Atloria to decide what happens next. A version that shows **Completed** with no visible issues is usually ready for reviewer handoff. A version that shows **Completed** but includes warnings needs a closer judgment call. A version marked **Failed** should not move forward until you correct the problem and run it again. Use the result details, not just the status badge, to make that decision. If the warnings involve missing assets, the wrong source selection, incomplete navigation, or pages that did not render, start another generation run after correcting the inputs. These problems affect what reviewers see and can waste review time. On the other hand, if the version finished and the warnings are minor, you may decide the output is still suitable for review, especially if the issues do not block page reading or release comparison. A full rerun is usually the better choice when you notice: - The wrong branch, content set, or source snapshot was used - Important pages are missing from navigation - Assets did not process correctly - The generated content is clearly outdated - Validation errors affect key pages You may still move to review when: - The version output is complete and readable - Warnings are limited and understood - Reviewers only need to assess content changes, not final release quality Before handing the version to reviewers, record the details they may need: - Version label or identifier - Generation date and time - Source used - Any warnings attached to the run - Whether this is the preferred output for review For the formal comparison step that follows generation, continue with [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). ## Fixing Common Generation Problems When a generation run does not behave as expected, start with the status shown in the **Versions** area and then open the job details for more context. If the job stays in **Queued** or **Pending**, first check whether Atloria offers a retry action in the job menu. Then reopen the version details and confirm that all required fields were completed when you created the run. An incomplete title, slug, source choice, or output setting can lead to a job that never moves cleanly into processing. If retry is available, use it after confirming the inputs. If the run fails during validation, read the error list carefully. Atloria may point to broken links, missing files, unsupported content, or invalid metadata in the selected source. Focus on the items that block rendering or remove important pages from the output. After you correct those issues in the source content, start a fresh generation run instead of relying on the failed result. If the version completes but pages or assets are missing, return to the generation settings you used. Confirm that the correct source was selected and that the run included the options needed for assets and navigation. A version can finish successfully while still excluding content because of the choices made on the form. If the output looks outdated or incorrect, compare the version details against the source you intended to use. In many cases, the issue is simply that the wrong branch, content snapshot, or preset was selected before submission. Correct the source and regenerate. Helpful checks when troubleshooting: - Compare the current run with the last successful version - Re-read the version metadata before retrying - Confirm the version name matches the release you intended - Review warnings even when the job says **Completed** [SCREENSHOT: Failed or warning state on a version job with error details visible] ## Overview Managing version generation jobs in Atloria means following the full path from version setup to finished output. You begin in the **Versions** area, create a new version, submit the generation job, monitor its progress, and then inspect the result before anyone starts formal review. This document focuses on that operational work: what to click, what statuses to watch, and how to decide whether the result is usable. The most important screens are the **Versions** list, the version creation form, the job or version detail page, and the generated version preview. Together, these screens tell you whether Atloria accepted the run, what source was used, how far the job has progressed, and whether the final output includes the pages, navigation, and assets you expected. As you work, pay attention to visible status changes such as **Queued**, **In Progress**, **Completed**, and **Failed**. Also watch for result panels and warning messages. A finished job is not always a ready job. Atloria can complete a generation run while still reporting broken links, missing references, or skipped content, so the review step starts with checking the output quality yourself. This guide does not repeat the earlier readiness evaluation covered in [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness). Instead, it shows how to manage the generation run itself and how to interpret the result once Atloria finishes processing it. The goal is simple: make sure the version you pass forward is the right one, generated from the right source, with issues understood before review begins. ## Prerequisites Before you manage a version generation job in Atloria, make sure the project and version workspace are already in a usable state. You do not need deep administrative setup for this task, but you do need access to the project’s **Versions** area and the ability to open the version creation form. Check these items before you begin: - You can sign in to Atloria and open the correct project - The project already has documentation content ready to generate - You can access the **Versions** area for that project - The **New Version** or **Generate Version** action is available to you - You know which source should be used for this run, such as the correct branch or content set - You have the version naming details your team expects, including the visible version label and any internal identifier - Any required pages, screenshots, or assets for this release have already been added - You are ready to review warnings and rerun the job if needed It also helps if you have already completed these related guides: - [Generating New Documentation Versions](doc:generating-new-documentation-versions) - [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness) If you need help getting into Atloria or confirming your access, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). Once these basics are in place, you can create a version, follow the generation job through to completion, and decide whether the result should be regenerated or sent on for comparison and review. ## Understanding version review requests and decision states In Atloria, version review happens on the version record itself. After you finish the preparation work described in [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review), you open the version and use the review controls on that page to ask for a formal decision. The version page is where you can see whether review has started, whether a reviewer has responded, and whether the version can move toward release. Look for review-related details in the version header and surrounding panels. The most important item is the **Review status** indicator. This shows the current review state for that version. You may also see an activity area or decision history that records review events in order, along with action buttons such as **Request review**, **Approve**, **Reject**, or a follow-up action that moves the version forward after approval. These review states are the ones to pay attention to: - **No review requested**: no formal review has been opened yet. - **Review requested** or **Pending review**: the version has been submitted and is waiting for reviewer input. - **Approved**: the reviewer recorded a positive decision and the version can continue in the release workflow. - **Rejected**: the reviewer recorded a negative decision and the version should be updated before another review request. - **Ready for release**: review is complete and the version has been moved to the next release-ready stage. The review state is different from the broader version lifecycle status. A version can still be in a draft or pre-release stage while also having a review request in progress. Atloria preserves decision tracking on the version record. In the activity history or decision log, you can confirm who requested the review, who approved or rejected it, when each action happened, and any comments entered with the decision. This history matters when a version goes through more than one review cycle, because older decisions remain visible instead of disappearing. [SCREENSHOT: Version page showing Review status, action buttons, and decision history] ## Preparing a version before requesting review Before you click **Request review**, open the version and make sure it is still in a state where changes and review actions are allowed. If the version has already been fully released, locked by a completed release step, or already has an active review decision that has not been resolved, Atloria may not show the review request action or may prevent you from submitting a new request. Start with the version details that reviewers are most likely to check. Confirm that the version title is correct, the version identifier is final, and any release notes or summary information on the version page are complete. If your workspace shows reviewer, approver, or owner fields, make sure those are filled in before you begin. Missing ownership or release information often creates confusion later, even if Atloria allows you to continue. It also helps to review the page for visible warnings before opening review. Pay attention to: - Required fields marked as incomplete - Validation messages near the version header or form sections - Status warnings that suggest the version is not ready - Existing rejection notes that still need to be addressed - Missing reviewer or approver assignments, if those fields appear in your workspace Your ability to request review or record a decision depends on your role in the project. In most teams, a **Documentation Manager** or **Project Administrator** is responsible for opening formal review and moving the version forward after approval. A **Technical Writer** may prepare the version content and in some workspaces may also request review, but decision actions such as **Approve** or **Reject** may be limited to designated reviewers or approvers. If the review controls are missing, do not assume the version is broken. First check whether the version is already under review, already approved, or in a state that no longer accepts changes. Then confirm that your account has the right level of access for review actions. ## Opening a review request for a version 1. In Atloria, open the project and go to the version you want to submit. You can usually start from the versions list or from the project’s version detail area, then click the target version to open its full record. 2. On the version page, find the review action in the main toolbar or the actions menu. Depending on your workspace, the button may appear as **Request review** or **Open review**. Click that action to start the review request. 3. Complete the review form that appears. Atloria may ask for one or more of the following details before it will send the request: | Field | What to enter | |---|---| | **Reviewer** | Select the person who should review the version | | **Due date** | Choose the date by which the review should be completed | | **Review notes** | Add context about what changed or what needs special attention | | **Decision context** | Explain the release goal, scope, or any known issues if this field appears | 4. Review the information you entered, then submit the request. After you save, return to the version page and check the **Review status** indicator. It should change from a not-requested state to **Review requested** or **Pending review**. 5. Open the version’s activity history or decision history and confirm that the request was recorded. You should see an entry showing that the review was opened, along with the requester name and timestamp. If the status does not change after submission, refresh the version page and check for any validation message that may have prevented the request from being saved. [SCREENSHOT: Review request form with reviewer, due date, and notes fields] ## Reading review status and decision history on the version Once a review request is open, the version page becomes the main place to monitor what is happening. The first item to check is the **Review status** badge or status field. This tells you the current review outcome for that version. Do not confuse it with the version’s broader workflow status, which may still show a draft, in-progress, or pre-release stage. A version can be technically ready for review while still not being ready for release. When reading the status, use it as a release signal: - **Pending review** means the version is waiting for a reviewer and is typically blocked from moving forward. - **Approved** means the review step is complete and the version can continue to the next release action. - **Rejected** means the version should not move forward until the issues are addressed and a new review cycle begins. - **Ready for release** means the approval has already been carried into the next workflow stage. To understand how the version reached its current state, open the activity stream, audit area, or decision history panel on the same page. This section shows the sequence of review events over time, such as: - review requested - comments added by the reviewer - approval recorded - rejection recorded - status changed after a follow-up review This history is especially important when a version has been reviewed more than once. The latest decision is the active one, but older entries still remain visible. That means you may see an earlier rejection followed by a later approval. In that case, treat the newest recorded decision as the current one, while using the older entries to understand what changed between review rounds. [SCREENSHOT: Version activity history showing review request, comments, and final decision entries] ## Recording approvals and rejections with clear rationale 1. Open the version that is currently in **Pending review** or **Review requested** status. On the version page, locate the decision controls in the toolbar or actions area. 2. Click **Approve** if the version is ready to move forward, or click **Reject** if it needs more work before release. Atloria records the decision on the version itself, so make sure you are on the correct version before saving. 3. In the decision form, enter the explanation Atloria asks for. Depending on your workspace, this may include a **Decision comment**, **Reviewer notes**, or a **Rejection reason**. Keep the comment specific. For example, use the notes to point to missing release notes, unresolved content issues, or confirmation that the version is ready for the next release step. 4. Save the decision. Return to the version header and confirm that the **Review status** updates immediately to **Approved** or **Rejected**. 5. Open the activity history or decision log and verify that the entry includes: - the reviewer’s name - the date and time of the decision - the decision type - the comment or rationale entered with the decision Clear rationale matters because review decisions often affect release timing, handoffs, and follow-up work. A short but direct comment is usually enough if it explains why the version passed or failed review. If you reject a version, make sure the note helps the writer or project owner understand what must be corrected before another review request is opened. ## Moving an approved version toward release and fixing common review issues After a version is marked **Approved**, use the next available workflow action on the version page to move it forward. Depending on how your Atloria workspace is set up, this may appear as **Mark ready for release**, a status promotion action, or another release-related button in the version toolbar. After you use that action, check that the approval remains visible in the version history so the release record still shows who approved it and when. If the version does not move forward, look for blockers on the version page before trying again. Common causes include: - required release fields still missing - validation warnings on the version record - unresolved issues from an earlier rejected review cycle - a version state that allows approval but not final release progression You may also run into cases where the review buttons are missing entirely. When **Request review**, **Approve**, or **Reject** does not appear, check these items first: - your role may not have permission to perform that action - the version may already have an active review in progress - the version may already be approved, rejected, or released - the version may be in a state that no longer accepts review changes If the wrong decision was recorded, avoid trying to hide or replace the older entry. In Atloria, the safer approach is to reopen the review process by creating a new review request or starting another review cycle on the same version, if that option is available in your workspace. The earlier decision should remain in the history so the audit trail stays complete. That preserved history is useful when teams need to understand why a version was delayed, revised, and then approved later. The next step is [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up), which explains how to work through reviewer comments and prepare the next response. ## Overview Use this workflow when a version is ready for a formal decision but has not yet been released. In Atloria, the review process centers on the version page, where you request review, monitor the **Review status**, read decision history, and record an **Approve** or **Reject** outcome. This document focuses on the decision-handling part of the workflow rather than the earlier preparation work. If you still need to finish the version before sending it out, return to [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review). The core tasks covered here are: - opening a review request from the version record - checking whether the version is waiting for review, approved, or rejected - reading the activity history to understand what happened and when - recording a clear decision with comments that remain attached to the version - moving an approved version into the next release stage You will spend most of your time in a few visible areas on the version page: - the **Review status** indicator - the version toolbar or actions menu - the activity history or decision history panel - any review form that appears when you request review or record a decision This guide is most useful for team members who coordinate release readiness, including documentation leads, project administrators, and reviewers who are responsible for formal approval steps. It is also useful for writers who need to understand why a version is blocked and what the latest review decision means. [SCREENSHOT: Full version page with review controls highlighted] ## Prerequisites Before you work through review requests and decisions in Atloria, make sure these conditions are already met: - You can sign in and open the correct project workspace. - The target version already exists in the project’s versions list. - The version has been prepared for review, including any required title, version identifier, and release details that appear on the version page. - You have the right project role to perform the action you need, such as requesting review or recording an approval decision. - You know whether you are acting as the requester, reviewer, or release coordinator for that version. It also helps to have these items ready before you begin: - the name of the reviewer or approver, if Atloria asks you to select one - any review notes you want to include with the request - a clear reason for approval or rejection if you are the person recording the decision Use this guide after you have already learned the basics of version review status and approval handling in: - [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) - [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals) - [Understanding Review Statuses Comments and Next Steps](doc:understanding-review-statuses-comments-and-next-steps) If the version is not yet ready for formal review, complete the preparation steps in [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review) before opening a new review request. ## Confirming you can prepare the version for approval Before you start, open your project in Atloria and go to the **Versions** area for that project. Find the version you plan to send for final approval and check its current status in the version list or on the version details screen. You should be working with a version that is still in progress, under review, or otherwise not yet finished. If the version already shows **Final Approved** or **Published**, it is no longer in the preparation stage and you should not resubmit it as if it were still pending. Open the version details page and make sure you can reach the controls that matter for approval work. You should be able to view or update the version **status**, review any assigned **reviewers**, and access the action used to move the version into final approval. If those controls are missing or read-only, your current access level may not allow approval preparation. In most teams, this work is handled by people with **Documentation Manager** or **Project Administrator** access. In practical terms, you need to be able to: - edit version content - update visibility or access settings - review assigned approvers - submit the version into the final approval step Gather everything you need before you begin the final pass. That usually includes: - the finished page content for the version - approved screenshots - any linked files or media used in the pages - the list of reviewers or approvers expected to sign off If you still need to resolve comments or follow-up items from an earlier review round, return to [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up) before moving ahead. [SCREENSHOT: Versions list showing a version status and the version details page with review controls] ## Reviewing the version content for release quality Use the version workspace to open each page included in the release. This is the point where you stop thinking about drafts and start checking what reviewers will actually see. Read page titles, section headings, and body content carefully. Remove any unfinished wording such as “TBD,” internal draft notes, temporary reminders, or comments copied into the page body by mistake. A page can look complete at a glance while still containing small draft leftovers that slow down final approval. Check the structure of the version as you move through the page tree or navigation panel. The page order, nesting, and navigation labels should match the release scope you intend to approve. If a page belongs in the version, it should appear in the right place with a clear label. If a page was only for drafting or internal reference, remove it from the release version before submission. Pay close attention to page details that affect consistency across the full set of content. In Atloria, confirm fields such as **Title**, **Description**, and **Keywords** are filled in where they are used. Keep naming and tone consistent from page to page so reviewers are not seeing one polished page beside another that still looks unfinished. Preview each page rather than relying only on the editor view. In preview, confirm that: - headings display in the right order - bullet lists and numbered lists are formatted correctly - tables are readable - callout blocks appear properly - embedded media displays as expected - spacing and paragraph breaks are clean This is also a good time to click through internal links and navigation items to make sure readers land on the correct pages. If you need a broader refresher on review decisions and approval handling, see [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). [SCREENSHOT: Version page editor beside page preview with headings, lists, and links being checked] ## Updating screenshots and linked assets before sign-off Screenshots often cause the last round of approval delays, so review them one by one before you submit the version. Open each page in the version and compare every screenshot against the current Atloria interface or the product screen being documented. If a button label, menu name, layout, or color treatment has changed, replace the image from the page editor or asset picker so reviewers are not approving outdated visuals. When you replace or confirm screenshots, check the supporting details attached to each image. Reviewers should be able to tell what an asset is without opening it blindly. Make sure the image name is recognizable, and where Atloria shows supporting fields, confirm the **alt text** and **caption** are accurate and useful. This helps both review clarity and final publishing quality. Also test every linked asset used in the version. In preview mode, open: - downloadable files - linked documents - media attachments - image references used inside pages Each item should open correctly and point to the intended file for this version. If a page still links to an older asset or a draft file, update it before submission. A version can be blocked in final approval simply because one download opens the wrong attachment. Clean up anything that could confuse approvers. Remove duplicate images, unused files, or older assets that were replaced during editing. If reviewers see multiple similar screenshots or attachments, they may not know which one is meant to be approved. For broader screenshot handling guidance, use [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) or [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release). [SCREENSHOT: Page editor showing screenshot selection and linked asset checks in preview] ## Verifying access settings and reviewer visibility Before you submit a version for final approval, make sure the right people can actually open it. Go to the version’s access or visibility settings and confirm who is allowed to view the version during review. In Atloria, this may involve checking whether the version is available to the correct project workspace, audience, or internal review group. Look closely at any restrictions applied before approval. Some versions should only be visible to internal reviewers until sign-off is complete. Others may need access for a specific set of named reviewers. The important point is that the version should be visible to everyone involved in approval, but not accidentally exposed more broadly than intended. Review the approval setup on the version details screen and confirm: - the correct reviewers are assigned - any due dates are set if your team uses them - notifications are enabled or sent through the expected workflow - no required approver is missing from the review chain After checking settings, test the version from the reviewer’s point of view as much as your access allows. Open the version preview and move through the pages, attachments, and restricted content areas. Confirm that hidden pages stay hidden, protected drafts are not visible to the wrong audience, and approved reviewers can reach the content they need. If your team manages audience-based access or version sharing rules, it helps to cross-check this work with [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export). Those guides go deeper into access behavior, so you can stay focused here on final approval readiness. [SCREENSHOT: Version visibility settings with reviewer assignments and preview access check] ## Completing the final approval checklist and submitting the version Once the content, screenshots, assets, and access settings are ready, return to the version record and complete the readiness checks your team uses before final approval. In Atloria, this usually means working through the version checklist and confirming that each review area has been finished. Mark content review, screenshot validation, asset verification, and access checks as complete only after you have personally confirmed them in the version preview. Add final notes for approvers on the version record if there is a comments area or reviewer note field. Keep these notes short and specific. For example, mention that screenshots were updated, links were tested, or earlier review comments were resolved. This gives approvers context without forcing them to recheck issues you already closed. Before submitting, confirm that all required fields on the version are filled in. If your team uses a review-ready status before final approval, update the version to that status first. Then use the **Submit for Final Approval** action from the version screen. After submission, verify that the version moves into the expected approval status rather than staying in a draft or editable state. Check the version history or activity area if it is visible. You want to confirm that Atloria recorded the submission with the correct timestamp and that the approval trail reflects the latest action. This is especially useful when multiple people are involved in the same release. 1. Open the version details page. 2. Complete each readiness item on the version checklist. 3. Add final reviewer notes or approval comments. 4. Update the version to the review-ready status if required. 5. Click **Submit for Final Approval**. 6. Confirm the status changes to the expected approval stage. 7. Review the recorded activity or timestamp on the version. The next step in this workflow is [Requesting and Completing Version Reviews](doc:requesting-and-completing-version-reviews). ## Fixing issues that block final approval If Atloria will not let you submit the version, start with the version form itself. Missing required information is one of the most common blockers. Look for empty fields on the version record, incomplete checklist items, or missing reviewer assignments. If the version has a **Title**, **Description**, reviewer section, or readiness checklist, make sure none of those areas are left unfinished. When reviewers say they cannot open the version preview, recheck the version’s visibility settings first. Confirm the version is shared with the correct internal audience, group, or named reviewers. Then test any linked files or attachments from preview. A reviewer may be able to open the page itself but still be blocked from a linked asset if that item is not available under the same access setup. If approval is delayed because content or screenshots are outdated, compare the current preview against the latest product state and your most recent edits. Replace stale screenshots, update labels that no longer match the interface, and remove references to older workflows. Even small mismatches can cause approvers to send the version back. Sometimes the submission appears to work, but the status does not change. In that case, check whether: - you have permission to move the version into final approval - another review step is still pending - a required approver has not been assigned - the version is still missing a required readiness item If you need help deciding whether a version is actually ready for this stage, revisit [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review). If the issue is tied to approval decisions already in progress, [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions) can help you identify where the workflow is stuck. [SCREENSHOT: Version submission blocked by missing required items or access settings] ## Overview Preparing a version for final approval in Atloria means doing a controlled last pass on the version before approvers make the release decision. You are not rewriting the documentation at this stage. Instead, you are confirming that the version already reflects the intended release, that the pages look complete in preview, that screenshots and linked assets are current, and that the right reviewers can access everything they need. This work usually happens on the version details page and inside the version’s page editing and preview views. The most important areas to check are: - version status - page content quality - screenshots and attachments - visibility and reviewer access - checklist completion - final approval submission A version is typically ready for final approval when it is no longer in active drafting, all major review feedback has been addressed, and the version can be read from start to finish without obvious gaps. If there are still unresolved comments, missing images, broken links, or unclear access settings, final approval should wait until those issues are fixed. This guide focuses on the preparation work immediately before submission. It does not repeat how to interpret review comments or follow up on earlier feedback rounds. For that part of the process, use [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up). It also does not replace the broader approval workflow guidance covered in [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions). Use this page when you are the person responsible for making sure a version is polished, accessible, and ready to move into the final approval step without avoidable back-and-forth. ## Prerequisites Before you prepare a version for final approval in Atloria, make sure these conditions are already in place: - You can sign in and open the project workspace that contains the version. - You can access the project’s **Versions** area and open the version details page. - Your role includes the ability to edit version content or manage approval preparation, typically **Documentation Manager** or **Project Administrator** access. - The version is not already marked **Final Approved** or **Published**. - Earlier review comments have been addressed, or you have confirmed which items are intentionally left unchanged. - The pages included in the version are already drafted and organized in their intended release structure. - Required screenshots, downloads, and other linked assets are available for the version. - The expected reviewers or approvers are known before submission. It also helps to have these materials ready while you work: - the final wording for page titles and body content - the latest approved screenshots - any version-specific files or attachments - notes about what changed since the last review round If you are still earlier in the workflow, these related guides may be more useful first: - [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) - [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness) - [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness) If those items are already in place, you can move through the checks in this guide and submit the version with much less risk of rejection or rework. ## Opening the Screenshot Review Page for a Release Version Before you start checking images, make sure you know the exact documentation version you are reviewing. In Atloria, screenshot review is tied to a specific version, so you need to open the screenshot page for that release rather than relying on screenshots you saw in another version, project area, or earlier review session. If you already completed the readiness check in [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release), use the same version name or release label here. 1. Open your project in Atloria and go to the version you plan to release. 2. From the version-related navigation, open the screenshot page for that version. Use the release or documentation navigation that belongs to the selected version so you are reviewing version-specific assets only. 3. Check the page header as soon as the page opens. Confirm the version name, release label, or selected version matches the one you intend to approve. 4. If Atloria shows a version selector on the page, verify that the correct version is selected before you review any thumbnails or previews. 5. Wait for the screenshot list, gallery, or page entries to finish loading. Do not start marking items as missing until the full page has appeared. [SCREENSHOT: Version screenshot review page with the selected release visible in the page header or version selector] A quick header check prevents one of the most common review mistakes: approving screenshots from the wrong release. This matters most when several versions are active at the same time and the interface looks similar across releases. As you open the page, look for signs that you are seeing the current version’s screenshot set: - The version name in the header matches your release. - The screenshot entries belong to the expected documentation areas. - The page shows the current version’s list, not a leftover view from an earlier session. If anything looks off, switch to the correct version first, then begin the review. ## Checking Whether Every Required Screenshot Is Present Once the correct version page is open, use that page as your source of truth for what is currently available for the release. Your goal here is simple: confirm that every screenshot expected for the version appears as its own entry in the screenshot list, gallery, or grouped section. 1. Start at the top of the version screenshot page and review entries in order instead of jumping around. 2. Compare each visible screenshot name, label, or card title against the documentation pages and workflows that require images for this release. 3. Move section by section if the page is grouped by topic, feature area, or documentation area. 4. Watch for empty image spaces, placeholder thumbnails, or entries that appear without a usable image. 5. Continue until you reach the bottom of the page so no screenshot group is skipped. [SCREENSHOT: Screenshot list or gallery showing named entries for a release version] This review works best when you check coverage by documentation area rather than by memory. For example, if a release includes updates to onboarding, project settings, and public documentation pages, make sure each of those areas has matching screenshot entries on the version page. A screenshot is only truly present when the entry exists and shows the expected image for that page or workflow. Use these visual clues while scanning: - A complete entry usually has a clear label and a visible thumbnail or preview. - A missing item may appear as an empty slot, placeholder image, or entry without a real screenshot. - A partially prepared section may show some screenshots loaded and others still blank. If the version contains multiple product areas, pause at the end of each section and ask whether every required page in that area has a matching screenshot entry. That section-by-section approach is the easiest way to avoid missing a gap hidden deep in a long release page. ## Identifying Missing, Outdated, or Incorrect Assets After confirming which entries exist, look more closely at what each one contains. A screenshot can appear on the page and still be wrong for the release. In Atloria, the most common problems are missing images, outdated screenshots, incorrectly assigned screenshots, and duplicates that hide missing coverage. 1. Open or inspect each screenshot entry closely enough to tell whether the image is actually present and usable. 2. Separate missing assets from broken or incomplete entries. If the entry exists but shows no image, an error state, or a placeholder, treat that differently from a screenshot that was never added. 3. Compare the visible interface in the screenshot against the release you are reviewing. Check page labels, navigation, buttons, and screen states. 4. Confirm that each screenshot belongs to the page or workflow named in its entry. 5. Watch for repeated images used in multiple places where different screens should appear. [SCREENSHOT: Screenshot entry showing a thumbnail, title, and a preview state that helps identify missing or incorrect images] Use this table to classify what you find: | Issue type | What you see on the version page | What it usually means | |---|---|---| | Missing screenshot | No thumbnail, empty slot, or placeholder image | The screenshot has not been added yet | | Broken or incomplete entry | Entry exists but the image does not load properly | The screenshot reference needs attention | | Outdated screenshot | Thumbnail shows older labels, older navigation, or an earlier screen layout | The image does not match the current release | | Incorrect assignment | The image does not match the screenshot title, feature, or workflow | The wrong screenshot was attached to that entry | | Duplicate screenshot | The same image appears in more than one place where different screens are expected | One or more required screenshots may still be missing | A screenshot should match both the version and the entry it appears under. If the title suggests a settings page but the image shows a different workflow, flag it even if the screenshot itself looks clear. ## Reviewing Screenshot Readiness Before Sign-Off Once you have checked for coverage and obvious mismatches, do a final quality review before release sign-off. This is where you confirm that each screenshot is not only present, but also ready to ship as part of the version. The version screenshot page should be your final review surface for this step. 1. Open individual screenshot previews from the version page rather than relying only on small thumbnails. 2. Check that the screenshot is readable at review size. Text, labels, menus, and page headings should be visible enough to confirm the image is usable. 3. Look for cropping problems. Make sure the important part of the screen is visible and not cut off. 4. Confirm the screenshot reflects the final release interface for that version, including the correct labels, navigation, and visible page state. 5. Check for temporary or unwanted content before approving the version. [SCREENSHOT: Open screenshot preview showing a full-size image for final review] During this pass, focus on what a reader would actually see in published documentation. A screenshot may technically exist but still fail review if it is too tightly cropped, shows the wrong state, or includes unfinished content. Pay close attention to: - Page titles and section names shown in the image - Navigation items visible in the screenshot - Buttons, tabs, and labels that changed during the release - Draft content, test data, or unfinished interface elements - Any visual mismatch between the screenshot and the final version you are approving If a screenshot looks acceptable in the thumbnail but unclear in the preview, treat it as not ready. Final sign-off should only happen when the version page shows a complete and visually accurate set of screenshots for the release. ## Recording What Needs to Be Fixed When you find problems, record them in a way that lets your team return to the exact version page entry and fix the right item quickly. The most useful review notes are specific, version-based, and grouped by issue type. Avoid vague comments like “some screenshots are wrong.” Instead, tie each issue to the exact screenshot entry shown on the version page. 1. For every issue, note the version you reviewed. 2. Record the screenshot name, page label, or entry title exactly as it appears on the version screenshot page. 3. Add the issue type so the next person knows whether the problem is missing, outdated, incorrectly assigned, or duplicated. 4. Include a short description of what is wrong in the thumbnail or preview. 5. Keep all findings together in one release-specific checklist until the review is complete. A simple tracking format like this works well: | Version | Screenshot entry | Issue type | What needs attention | |---|---|---|---| | Release being reviewed | Entry title on the screenshot page | Missing / Outdated / Incorrect / Duplicate | Short note about the problem | [SCREENSHOT: Example of a screenshot review note that references the exact screenshot entry title from the version page] Grouping issues makes follow-up easier: - **Missing screenshots**: entries with no usable image - **Outdated screenshots**: images that show an older interface - **Incorrect assignments**: screenshots attached to the wrong page or workflow - **Duplicates**: repeated images hiding missing coverage elsewhere When you share findings with writers, administrators, or release owners, always reference the exact screenshot page entry or preview item. That keeps everyone reviewing the same asset list for the same version, which is especially important when several releases are being updated at once. ## Fixing Common Issues During Screenshot Review Some screenshot problems are real, and some are caused by reviewing the wrong version page or checking the page before everything has loaded. Before you escalate an issue, use a short cleanup pass to confirm that the problem is truly tied to the release. 1. If screenshots appear to be missing, first confirm that the version name in the page header or version selector is correct. 2. If an image looks wrong for the release, compare the version label on the page with the interface shown inside the screenshot preview. 3. If the screenshot list looks incomplete, refresh the version screenshot page and wait for all entries to load again. 4. Recheck any section that seemed partially loaded before marking screenshots as missing. 5. If reviewers disagree, have everyone open the same version-specific screenshot page and compare the same entries and previews. [SCREENSHOT: Version screenshot page after refresh, showing the full list of screenshot entries] These quick checks help resolve common review confusion: - A cross-version mix-up can make a perfectly good screenshot look outdated. - A partially loaded page can make existing screenshots appear missing. - Similar-looking releases can lead reviewers to compare the image against the wrong version. - Duplicate images can hide the fact that one expected screen is still absent. If a problem remains after you confirm the correct version page and reload the list, keep the issue on your release checklist and send it back for correction. The key is consistency: everyone should review the same version page, the same screenshot entries, and the same previews before deciding whether the release is ready. ## Overview This guide focuses on one specific review task in Atloria: checking the screenshot page for a single documentation version before that version is released. You are not reviewing screenshots across the whole project or across every release. Instead, you are confirming that the selected version has a complete, accurate, and release-ready set of screenshots attached to it. Use this guide after you have already confirmed general screenshot readiness in [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release). That earlier step helps you decide whether a version is ready for screenshot review at all. This guide picks up from there and shows you how to inspect the version’s actual screenshot entries, thumbnails, and previews. In Atloria, this review usually includes four checks: - The correct version screenshot page is open - Every required screenshot entry is present - Each image matches the release and the page it belongs to - Any problems are recorded clearly enough for follow-up This is especially useful when a release includes interface changes, new documentation pages, or updated workflows. Even when the written content is complete, the version should not move forward if the screenshot page still shows missing images, outdated screens, or incorrect assignments. Keep your review anchored to what you can see on the version screenshot page: - The version name in the header or selector - The screenshot list, gallery, or grouped sections - Thumbnail images and full previews - Entry titles that identify each screenshot After you finish this review and any fixes are applied, the next step is to check screenshots in the broader page and version context in [Reviewing Screenshots in Document and Version Context](doc:reviewing-screenshots-in-document-and-version-context). ## Prerequisites Before you begin this review in Atloria, make sure you have the basics needed to check the correct release without confusion. - You know the exact version or release label you are reviewing. - You can open the project and navigate to that version’s screenshot page. - The version already has screenshot entries prepared for review. - You have already completed the earlier readiness check in [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release). - You know which documentation pages or workflows in the release are expected to have screenshots. It also helps to have access to the release materials you are comparing against, such as: - The version’s documentation pages - The release scope or list of changed areas - Any internal review notes about pages that require updated screenshots Before starting, confirm these points on the screen: - The version page header shows the release you intend to review. - The screenshot list or gallery finishes loading. - You can open screenshot previews from the version page. - You have a place to record findings for that release. If any of those pieces are missing, pause and correct them first. Screenshot review is much faster when you are certain you are on the right version page and looking at the full set of entries. Once that is in place, you can move through the review confidently and record only the issues that truly affect release readiness. ## Confirming the release is ready for audience-targeted validation Before you start testing, make sure you are checking a release that is already available in Atloria’s published documentation view. If the version is still being reviewed or has not been published yet, the public page and version selector will not reflect the final audience experience. If you need help with the publishing flow itself, use [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences) first, then return here to validate the published result. Gather the exact pages you plan to test and confirm each one has audience targeting applied in its publishing setup. In practice, that means you should already know which audience each page is meant for and which parts of the page are expected to change. This is especially important for pages that include audience-specific notices, different screenshots, alternate links, or navigation entries that only appear for one audience. Before opening the public site, prepare a simple validation table so you can compare expected results against what you actually see. | Page | Expected Audience | Expected Version | What Should Be Visible | |---|---|---|---| | Getting Started page | Selected audience | Published release | Main heading, audience-specific callout, correct links | | Setup page | Selected audience | Published release | Matching navigation item, expected body sections | | Troubleshooting page | Selected audience | Published release | Correct related links and visible notices | Also confirm you know: - The standard public URL for the page - The versioned documentation URL for the same page - The audience-specific path pattern your team uses for published content - Whether the audience is selected through a visible switcher, a dedicated path, or another public-facing route pattern - Which browser session you will use for testing [SCREENSHOT: validation notes showing page name, audience, version, and expected visible elements] ## Reviewing how the targeted page should appear before testing A useful validation pass starts with knowing exactly what should change on the page. Open your source page in Atloria and review the visible content structure before you test the public output. Focus on the page title, main heading, section headings, notices, tabs, screenshots, related links, and any right-side table of contents entries that may appear or disappear for a specific audience. If you do not define these expected differences first, it becomes much harder to tell whether the published page is correct. Create a side-by-side expectation for two views of the same page: - The canonical public view - The versioned audience path for the release you are validating For each view, note the exact items you expect to see. For example, the page may keep the same H1 but show a different warning box, a different screenshot, or a different internal link for one audience. In some cases, the page should also change how it appears in left navigation, breadcrumbs, search results, or related-links sections. If a page is meant to be hidden from a certain audience, record that too so you can verify it does not appear where it should not. Define your pass criteria before testing. A page should count as valid only when all of the following are true: - The correct audience-specific body content is visible - The correct version is shown in the version selector - Content meant for other audiences does not appear - Breadcrumbs and navigation match the intended page - Internal links open the correct destination without losing the audience context [SCREENSHOT: published page with callouts identifying H1, breadcrumb, left navigation, and targeted content block] This preparation step reduces guesswork and gives you a clear checklist when you move into public and versioned validation. ## Validating the page in the public documentation view 1. Open the public page in a clean browser session. Use an incognito or private window so previous browsing does not affect what you see. This matters when Atloria remembers a prior audience selection or loads an older page state from cache. 2. Confirm that you landed on the correct page. Check the browser address, page title, H1 heading, breadcrumb trail, and the matching entry in the left navigation. These should all point to the same published page. If the breadcrumb or navigation label does not match the page you intended to test, stop there and record it as a navigation issue. 3. Review the audience-targeted content in the body of the page. Look for the exact sections you listed earlier: audience-specific paragraphs, notices, screenshots, tabs, badges, or links. Compare what is visible against your validation notes. If a callout should appear for one audience, make sure it is present and placed in the expected section of the page. 4. Check for content leakage. Scroll through the full page and look for anything that should not be public for the selected audience. This may include alternate instructions, hidden screenshots, links intended for another audience, or extra sections that should have been excluded from the published view. 5. Test the page links. Open the most important links from the page body, breadcrumbs, related links, and left navigation. Make sure each one opens the correct public destination and keeps you in the same audience context instead of sending you to a generic or mismatched page. [SCREENSHOT: public documentation page showing breadcrumb, left navigation, and audience-specific content area] If the page passes these checks in the public view, you are ready to compare it against the versioned audience path. ## Checking versioned audience paths and version switching behavior 1. Open the versioned URL for the same page you just tested in the public view. Once the page loads, check the version selector immediately. It should show the exact release version you planned to validate. If the wrong version appears by default, note that before testing anything else. 2. Review the address and confirm the page follows the expected audience-specific route pattern for that version. The versioned page should not drop you onto a generic page, a different audience path, or a different document entirely. Compare the page title, H1, breadcrumb, and left navigation with your validation notes to confirm you are still looking at the same content in the correct release. 3. Switch between available versions using the version selector. After each change, watch for two things: whether the page stays on the same document, and whether the audience-targeted content updates correctly for that version. A correct result keeps the page context intact while changing the release version. An incorrect result may send you to the wrong page, remove audience-specific content, or show content from another audience. 4. Compare the versioned page with the standard public page. For the same audience, the visible headings, notices, links, and content blocks should remain consistent unless your team intentionally changed them between versions. If the public page shows one callout and the versioned page shows another for the same release, record that mismatch. Use this comparison checklist while switching versions: | Checkpoint | Public View | Versioned View | |---|---|---| | H1 heading | Matches expected page | Matches same page | | Version label | Current published state | Selected release shown | | Audience-specific content | Correct | Correct | | Internal links | Open correct destination | Keep version and audience context | [SCREENSHOT: versioned documentation page with version selector open] ## Recording validation results across audiences and pages As you test, record each result page by page rather than waiting until the end. Audience-targeted publishing issues are much easier to fix when you can point to the exact page, audience, and version where the mismatch appeared. A simple tracking sheet is enough as long as it captures what you tested and what failed. For every page and audience combination, log: - The page name - The tested public URL - The tested versioned URL - The selected audience - The selected version - The browser session used, such as normal window or incognito - A pass or fail result - Notes describing what you saw When a page fails, describe the exact visible issue in Atloria’s published view. Good examples include: - Breadcrumb shows the wrong page name - Left navigation includes a page that should be hidden - Audience-specific notice is missing - Wrong version appears in the version selector - Internal link opens the wrong destination - Screenshot for another audience is visible Use screenshots whenever the mismatch is visual or hard to describe in one sentence. | Page | Audience | Version | Result | Issue Found | |---|---|---|---|---| | Setup page | Audience A | v1 | Pass | — | | Setup page | Audience B | v1 | Fail | Wrong callout displayed | | Troubleshooting page | Audience A | v1 | Fail | Broken related link | [SCREENSHOT: failed validation example showing incorrect callout or wrong breadcrumb] Also note the scope of the issue: - One page only - All pages for one audience - Multiple pages in one version - All tested pages in the release That scope helps your team decide whether the problem is a page-level publishing issue or a broader release problem. ## Fixing common validation failures in targeted publishing When audience-targeted validation fails, start with the visible symptom and trace it back to the publishing choices used for that page. In Atloria, most issues fall into a few repeat patterns. If audience-specific content appears in the wrong public view, first reopen the page’s audience targeting setup and confirm the page is assigned to the intended audience. Then compare the published result with your latest page changes. If the page still shows an older variant, the public output may not yet reflect the newest publish. Republish the page or release, then test again in a clean browser window. If the versioned audience path opens the wrong page or the wrong release, check the selected entry in the version selector and confirm you are using the correct versioned URL for that document. A mismatch here often shows up as the right page title with the wrong body content, or the right audience with the wrong version label. If hidden content is still visible after release, inspect the published page carefully and compare it with the intended audience view. Look for alternate screenshots, extra instructions, or links that should have been excluded. Then republish the corrected page and retest both the public page and the versioned page. If links break when switching audiences or versions, test each link from the visible page again and confirm it points to the matching published destination. Audience-specific pages should link to the equivalent audience-aware destination whenever one exists. If a link sends readers to a generic page, the audience context may have been lost. [SCREENSHOT: comparison of correct audience view and incorrect audience view] After each fix, repeat the same validation steps on the affected page instead of assuming the issue is resolved across the whole release. ## Overview Audience-targeted publishing validation in Atloria is the check you perform after publishing to confirm that each audience sees the right documentation in the right place. You are not reviewing draft content here. You are reviewing the actual published experience across the public documentation site and the versioned documentation view. This validation focuses on a few visible outcomes: - The correct page opens for the selected audience - The correct release appears in the version selector - Audience-specific sections display when they should - Content for other audiences stays hidden - Navigation, breadcrumbs, and links remain consistent This guide assumes you already know how to publish documentation for a defined audience. If you need to revisit that setup, refer to [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences). The goal here is different: confirm that the published result matches your expectations before you move further into release checks. In Atloria, this work usually happens after a version is published and before broader release sign-off. You will compare the same page in two places: - The standard public documentation view - The versioned audience path for the release That comparison helps you catch issues that are easy to miss in editing screens, such as: - A page showing the wrong audience-specific notice - A hidden section leaking into the public page - A version selector pointing to the wrong release - A left navigation item appearing for the wrong audience - An internal link dropping readers out of the intended audience path [SCREENSHOT: public page and versioned page open side by side] If you treat validation as a page-by-page check instead of a quick spot check, you will find release issues earlier and produce a more reliable published experience. ## Prerequisites Before you begin this validation workflow in Atloria, make sure the following items are already in place: - A published documentation release that includes the pages you want to test - At least one page with audience-targeted content already configured - Access to the public documentation site for the project - Access to the versioned documentation view, including the version selector - A list of the audiences included in the release - The expected public page locations and versioned page locations for each test page - Notes describing what should appear for each audience, such as headings, notices, screenshots, or links It also helps to prepare a small validation worksheet before you start. Include: - Page name - Audience name - Expected version - Expected navigation label - Expected breadcrumb - Expected visible content blocks - Key links to test Use a clean browser session for final checks. If you test in a browser window that already contains older page state, you may see outdated audience results and record a false failure. If you are still setting up audiences or organizing audience rules across projects, review: - [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) - [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation) - [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content) If your release includes multiple versions, make sure you know which version is meant to be the public default and which versions should remain available in the version selector. The next step after completing this validation is [Validating Audience Targeted Publishing Before Release](doc:validating-audience-targeted-publishing-before-release). ## Confirming you can compare the right documentation versions Before you start a release comparison in Atloria, make sure the **newly generated version** and the **baseline version** are both available in the version list for the project you are reviewing. Open the project workspace, go to the area where documentation versions are listed, and check that the release candidate appears as a saved version rather than an in-progress item. The version you compare against should usually be the **currently approved**, **previous release**, or **published** version, depending on your team’s release process. If the version you expect to review does not appear yet, return to the version job or results area and confirm that the generation run has finished. A comparison is only useful when the new version reflects the latest completed output. If you need help checking job results first, use [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results). It also helps to decide your comparison roles before opening the diff view: - **Release candidate**: the new version you may publish - **Baseline**: the version you trust as the current reference - **Scope**: the set of pages or documentation areas included in the comparison If Atloria does not show the comparison option, check whether you can open version history and version details for that project. Teams often limit who can review release-level changes. You should be able to access the project workspace, open saved versions, and use the comparison screen. [SCREENSHOT: Version list showing a newly generated version and a previously approved version ready for comparison] A quick check at this stage prevents the most common review mistake: comparing the right release candidate against the wrong baseline. ## Opening the comparison view for a newly generated version In Atloria, start from the project’s documentation version list or version history area. Select the **newly generated version** you want to review, then choose the **Compare** action. Atloria should prompt you to choose another saved version as the comparison source. In most release reviews, that source is the **previous approved version** or the **currently published version**. Once the comparison opens, look first at the header area. This is where Atloria shows which version is being compared against which reference version. Before reading any changes, confirm that the header matches your intended review: - the **new version** is the release candidate - the **comparison source** is the correct baseline - the **document scope** matches the pages or content set you meant to review If Atloria offers more than one comparison layout, switch to the one that best fits the type of review you are doing. A **side-by-side** layout is useful when you want to read old and new content together, especially for rewritten sections or moved text. An **inline diff** is better when you want to scan exact wording changes in a single reading flow. Use the layout controls to move between these views if a section feels hard to interpret. For example: - use **side-by-side** for heading changes, larger rewrites, and page structure review - use **inline diff** for sentence edits, terminology changes, and short additions - return to the comparison header whenever you need to double-check the selected versions [SCREENSHOT: Comparison screen header showing source version, target version, and diff layout options] Do not begin release sign-off until the comparison header clearly shows the correct pair of versions. A clean review starts with the right comparison setup. ## Reviewing added, removed, and modified content before release The comparison view in Atloria is most useful when you read it as a change map rather than a full document. Focus on how the screen marks **added**, **removed**, and **changed** content. New text should stand out as inserted content, deleted text should appear as removed content, and rewritten passages should show as edited rather than entirely new sections. This helps you separate genuine release updates from simple wording adjustments. As you review, pay attention to changes that affect how readers move through the documentation. These often matter more than isolated sentence edits. Look closely for: - **renamed headings** that may change meaning or searchability - **reordered pages or sections** that affect navigation flow - **removed topics** that may leave gaps in the release - **newly generated sections** that need a quality check before publication If Atloria shows a change summary or lets you narrow the view, use that to focus on high-impact updates first. Start with the sections most likely to affect release readiness, such as policy content, setup instructions, technical reference wording, or other material your team flagged during generation. You should also review linked content and embedded materials. If links, references, screenshots, or other assets changed between versions, confirm that those changes were intentional. A release candidate can look complete at the text level while still pointing to outdated pages or missing visuals. Helpful review habits include: - scanning the summary first for large changes - opening major edits before minor wording changes - checking whether deleted content was replaced elsewhere - confirming that moved content still appears in the right place [SCREENSHOT: Diff view highlighting added text, removed text, and edited headings] When you treat the comparison screen as a release review tool instead of a proofreading screen, it becomes much easier to spot changes that affect publish decisions. ## Validating that version changes are ready for publication After you identify what changed, the next step is deciding whether those changes match the release you intended to produce. In Atloria, compare the diff against your release scope, update plan, or requested changes. The goal is not only to confirm that new content appears, but also to catch missing updates that should have been included in the release candidate. Start by checking whether the expected pages, sections, and edits are present. If a section was supposed to be updated but appears unchanged in the comparison view, that is a signal to investigate further. Open that page directly if needed and verify whether the change was missed, saved elsewhere, or excluded from the version you generated. If the comparison screen includes document details beyond body text, review those as well. Fields such as **title**, **description**, **labels**, **status**, or **version notes** can affect release clarity just as much as the page content itself. A version may be textually correct but still not ready if these details are outdated or inconsistent. Use Atloria’s review tools wherever they appear in the version workspace. Record your findings in: - **comments** for section-specific concerns - **approval notes** for release-level decisions - **status or tracking fields** when your team uses them to document readiness This creates a clear trail showing why a version was approved, held, or sent back for revision. That record is especially useful when several reviewers are involved or when publication timing depends on stakeholder sign-off. [SCREENSHOT: Version comparison with review notes or approval comments visible alongside changes] A comparison becomes much more valuable when it ends with documented review outcomes, not just a visual scan of edits. ## Using comparison results to decide whether to release A final comparison in Atloria should help you make a practical release decision, not just confirm that changes exist. As you review the diff, decide which findings are **release blockers** and which are minor issues that can wait. This keeps your team focused on what must be fixed before publishing. Typical blockers in a version comparison include: - **missing required updates** that were part of the release scope - **unexpected deletions** that remove important guidance - **unreviewed generated content** that has not been checked for accuracy - **wrong version scope** where the release candidate includes unrelated changes - **broken references or assets** that affect the reader experience By contrast, some differences are cosmetic. These may include light wording cleanup, formatting shifts, or small layout changes that do not alter meaning. Atloria’s comparison view helps you separate these lower-risk edits from changes that affect correctness, completeness, or release timing. Use the diff during approval discussions with project leads, documentation managers, or other stakeholders who need evidence before publication. Instead of describing changes from memory, you can point to the exact sections that were added, removed, or revised. This is especially helpful when deciding whether the version is ready now or needs another generation or editing pass. At the end of the review, your decision usually falls into one of three paths: - **Publish** when the compared changes are complete and accurate - **Regenerate** when expected generated updates are missing or incomplete - **Return for revision** when the content needs manual fixes before release If your team also uses formal review and sign-off steps, pair this comparison with the approval process described in related version review guides rather than treating the diff alone as the final decision. ## Fixing common problems when version differences do not look right If the comparison result in Atloria seems confusing, start by checking the setup rather than assuming the content is wrong. Many comparison issues come from selecting the wrong version pair or opening the diff before the latest version is fully available. When the **Compare** option is missing, first confirm that the project has at least **two saved versions** available. Atloria cannot compare a version against itself or against an item that has not been saved as a version yet. If versions exist but you still cannot compare them, your access may not include version review or history screens. If expected edits are missing from the diff, verify that you selected the correct **generated version**. It is easy to open an earlier run with a similar name or date. Also check that the generation work finished successfully before you trust the comparison result. If needed, return to the job results area and confirm the latest output, as covered in [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results). If the comparison shows too many unrelated changes, the most likely cause is the wrong **baseline version** or the wrong **document scope**. Review the comparison header and make sure you are comparing the intended release candidate against the correct approved or published reference. For formatting problems or broken assets in the diff view, open each version on its own and inspect the same page outside the comparison screen. This helps you tell the difference between: - a real content problem in the version itself - a display issue limited to the comparison view - an asset that changed between versions and now needs review [SCREENSHOT: Comparison header with version selectors highlighted for troubleshooting] ## Overview In Atloria, comparing documentation versions is the step where you decide whether a generated version is actually ready to move toward release. The comparison view helps you review the release candidate against a trusted baseline so you can see exactly what changed before anyone publishes it. This review is most useful after generation is complete and before final approval. You are looking for more than simple text edits. A strong comparison review checks whether the new version includes the right updates, avoids accidental removals, and stays aligned with the release scope your team intended. The comparison workflow usually centers on a few key actions: - opening the **version list** or **version history** - selecting the **newly generated version** - choosing **Compare** against a previous approved or published version - reviewing **added**, **removed**, and **modified** content - recording review outcomes in **comments**, **approval notes**, or status fields Atloria’s comparison layouts help with different review styles. Use a broader layout when you want to understand page structure and section movement, and a tighter diff view when you need to inspect wording changes line by line. Together, these views help you judge both release completeness and content quality. This guide focuses on using comparison results to support release decisions. It does not repeat how to manage generation runs or job outcomes. If you still need to confirm whether the latest version finished processing correctly, refer back to [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results). By the end of this workflow, you should be able to tell whether the version is ready to publish, should be regenerated, or needs another editing and review pass before release. ## Prerequisites Before you compare versions in Atloria, make sure the project and version workspace are in a reviewable state. You do not need to prepare every release detail in advance, but a few checks will save time and prevent misleading comparison results. You should already have: - access to the **project workspace** that contains the documentation set - permission to open **saved versions**, **version history**, and the **Compare** view - a **newly generated version** available as the release candidate - at least one earlier **approved**, **published**, or otherwise trusted version to use as the baseline It also helps if the generation work for the new version is already complete. If the version is still updating or if the latest results have not appeared in the version list, the comparison may not reflect the final content. Confirming generation status first is especially important when several runs were created close together. For the smoothest review, have the release scope or expected change list nearby. That gives you something concrete to compare against when you inspect the diff. Without that reference, it is much harder to tell whether unchanged sections are acceptable or whether important updates were missed. You will get the most value from this guide if you already know how Atloria handles version jobs and saved results. If you need that foundation first, review [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results). After you finish this comparison workflow and record your release decision, continue with [Monitoring Version Generation Jobs and Results](doc:monitoring-version-generation-jobs-and-results) to keep track of follow-up activity and confirm the version stays on course for release. ## Checking what makes a version shareable or export-ready In Atloria, a documentation version is only ready for wider use when three separate controls line up on the version screen: - **Access or visibility** - **Review status** - **Release or published state** These controls work together. A version can look finished to your team and still not be ready for sharing or export if even one of those indicators is missing. Start from the project’s **Versions** area, open the version you want to use, and review the status details shown on the version page. You are looking for clear signs that the version is not limited to internal work, that review has been completed, and that the version has moved out of draft status. This is different from basic collaborator access. A version that project members can open inside Atloria is not automatically ready for public sharing. Internal visibility only means people with project access can view it in the workspace. Public sharing requires a version setting that allows external access, and export workflows usually expect the version to be in a released or published state as well. On the version details view, check for badges, labels, or status indicators that show: | What to check | What it tells you | |---|---| | **Visibility / Access** | Whether the version is restricted to collaborators or available for broader sharing | | **Review Status** | Whether the version is still pending review, in review, or complete/approved | | **Release / Published State** | Whether the version is still a draft or has been released for downstream use | If you already worked through [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export), use that validation process here as a quick pre-check. This guide focuses on changing the version so it becomes eligible, not just inspecting the current state. [SCREENSHOT: Version details view showing visibility, review status, and release badges together] ## Setting access so the version can be shared with the right audience 1. Open your project in Atloria and go to the **Versions** list. 2. Select the version you want to share, then open its **Settings**, **Access**, or **Visibility** area on the version page. 3. Find the current access choice. In most cases, you will see a difference between a restricted option and a broader sharing option. Restricted access keeps the version available only to project members and collaborators inside Atloria. A public or share-enabled option allows the version to be used for external sharing. 4. Change the access setting to the option that matches your intended audience. If you plan to use a public link or another external sharing action, the version must no longer be limited to internal-only access. 5. Click **Save** or apply the change from the version settings panel. After saving, return to the main version view and check the version toolbar or **Actions** menu. If the version is now configured for broader access, sharing actions such as a public link or external sharing option should become available or stop appearing disabled. If those actions are still unavailable, another requirement—usually review completion or release state—is still blocking the version. Use access settings carefully. Changing a version from restricted to public affects who can reach that version once it is also released and approved for use. If your team is still deciding who should see which content, review [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) before making the change. A good way to confirm the update is to compare the version’s access label before and after saving. The version should no longer show an internal-only or collaborator-limited state if you intend to share it outside the project workspace. [SCREENSHOT: Version settings panel with access or visibility options and Save button] ## Completing review requirements before sharing or export 1. Open the version in Atloria and locate the **Review Status** area on the version page. 2. Check whether the version is marked as **Pending**, **In Review**, **Complete**, or **Approved**. A version that is still waiting on review work usually cannot be treated as ready for public sharing or export. 3. Look through the version’s review activity for anything still open. This can include unresolved feedback, comments that still need action, or approvals that have not yet been recorded. 4. Finish the remaining review work. Resolve outstanding comments, address requested changes, and complete the final approval step used by your team on that version. 5. Return to the version header or review panel and confirm that the status changes to the completed state your team uses for release-ready versions. This step matters because Atloria separates content creation from release readiness. A version may contain all the right pages and still remain blocked if its review trail is incomplete. If the version still shows **In Review** or another unfinished state, Atloria continues to treat it as work in progress rather than approved documentation. When you check the version after review, focus on the visible review indicator rather than assuming the work is finished. If comments were resolved but the final approval was never recorded, the version may still fail readiness checks. The same is true if approval was expected from a reviewer and that action has not been completed yet. If you need a refresher on how review decisions affect release progress, see [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) and [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). Those guides cover the review workflow in detail; here, your goal is simply to make sure the version shows a completed review state before you try to share or export it. [SCREENSHOT: Version review panel showing completed or approved status] ## Releasing the version so it can be used outside the draft workflow 1. Open the version details page and check the current state shown near the version name or in the status area. 2. If the version still shows **Draft** or another unreleased state, open the version toolbar or **Actions** menu. 3. Click **Release**, **Publish**, or the equivalent action available for that version. 4. Confirm the action if Atloria asks you to review the change before continuing. 5. Wait for the version page to refresh, then verify that the status badge now shows **Released** or **Published**. This step moves the version out of the internal drafting workflow and into the state expected by external sharing and export processes. Even if the content is complete and approved, a draft version is usually treated as internal working material. That means export options may stay disabled, and public-facing actions may remain unavailable until the release state changes. Release state does not replace access settings or review completion. These three controls are separate. For example: - A **released** version with **restricted access** is still not ready for public sharing. - A **public** version that is still in **draft** may still be blocked from export. - A **review-complete** version that has not been **released** may remain unavailable in downstream workflows. After releasing the version, check whether export-related actions appear in the version toolbar, action menu, or export flow. You should also see the updated released or published badge in the version details area. If the badge changed but sharing or export is still unavailable, go back and compare all three readiness indicators together. [SCREENSHOT: Version page showing Publish or Release action and released badge after completion] ## Confirming that the version is ready for public sharing and export Before you share a version outside your team or include it in an export workflow, confirm all three readiness requirements on the version page: - **Access** is set to a public or share-enabled option - **Review Status** is complete or approved - **Release State** is released or published Start with public-sharing readiness. Open the version and look at the toolbar or **Actions** menu. If the version is ready, sharing choices such as **Share**, **Public Link**, **External Access**, or a public view option should be available without warning messages. If those actions are missing or disabled, compare the version’s access label, review status, and release badge to find the missing requirement. Next, test export readiness. Open the export workflow from the version page or the related export area in Atloria. A ready version should appear as a selectable version, not as a disabled item and not hidden from the list. If the version does not appear, or appears but cannot be selected, Atloria is still treating it as not ready for export. Typical behavior when one requirement is missing: | Missing requirement | What you will usually see | |---|---| | **Access still restricted** | Public sharing actions remain unavailable | | **Review not complete** | Readiness warnings or blocked sharing/export steps | | **Still draft / unreleased** | Export disabled, version unavailable in release-based workflows | This final check is especially useful after you make several changes in a row. A version can be approved but not released, or released but still private. Confirming all three indicators together helps you avoid sharing the wrong version state. [SCREENSHOT: Version actions menu with share and export options enabled] ## Fixing versions that still are not eligible to share or export If a version still is not available for sharing or export in Atloria, check the visible status indicators one by one instead of retrying the same action. - **Share option is unavailable** - Open the version’s **Access** or **Visibility** setting. - Make sure the version is not set to a private, internal-only, or collaborator-limited option. - Save the change, then return to the version toolbar and check whether public sharing actions are now enabled. - **Export action is disabled** - Check the version state near the top of the version page. - If the version still shows **Draft** or another unreleased state, use **Release** or **Publish** first. - Reopen the export flow and confirm the version now appears as an eligible choice. - **The version passed review work, but readiness still fails** - Look again at the **Review Status** label. - Make sure approvals were fully recorded and that unresolved comments or pending review items are no longer present. - If the review work is done but the status did not update to **Complete** or **Approved**, the version is still not ready. - **The version is publicly visible but missing from export** - Compare the version’s release badge and readiness indicators in the details panel. - Public visibility alone does not guarantee export eligibility. - The version may still be unreleased or waiting on final review completion. When troubleshooting, the version details panel is your best reference point because it shows the current state in one place. If you only check the share menu or only check the export flow, you may miss the actual blocker. For a more structured pre-check process, return to [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export). [SCREENSHOT: Version details panel highlighting a missing readiness requirement] ## Overview Atloria uses three visible version controls to decide whether a documentation version can move beyond internal workspace use: **access**, **review status**, and **release state**. You manage these on the version itself, not in a separate publishing screen. That means the version details page is the main place to confirm whether a version is still internal, ready for public sharing, or eligible for export workflows. A version can be available to collaborators inside a project without being ready for external use. That is the key distinction in this workflow. Internal visibility only allows project members to work with the version in Atloria. Public sharing requires a share-enabled access setting, and export workflows usually depend on the version also being approved and released. This guide focuses on the point where a version moves from “ready inside the team” to “ready for outside use.” You will use the version page to: - Check the current **Visibility** or **Access** setting - Confirm the **Review Status** is complete or approved - Verify the version shows a **Released** or **Published** badge - Test whether **Share** and **Export** actions are available If you are still deciding whether the current settings are correct, review [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options) and [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access). If you already validated the current state and now need to make the version ready, the sections above walk you through the exact checks and changes to make on the version screen. The next step in this sequence is [Preparing Versions for Public Access and Sharing](doc:preparing-versions-for-public-access-and-sharing), which focuses on getting a version ready for the public-facing experience after these readiness controls are in place. ## Prerequisites Before you start, make sure you have the right version open in Atloria and that you can access its version details page. - You can open the project’s **Versions** list and select the version you want to prepare. - You can view the version’s current **Access** or **Visibility** setting. - You can see the version’s **Review Status**. - You can see whether the version is marked **Draft**, **Released**, or **Published**. - You have permission in Atloria to update version settings, complete review actions, or use the **Release** or **Publish** action if your team requires those steps. It also helps if the version content is already in a stable state. This guide does not cover editing pages, comparing version output, or running the full review workflow from the beginning. If you still need to finish those tasks, use these related guides first: - [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness) - [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) - [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review) If you want to confirm the current state before making changes, use [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export). That guide is the best companion when you are unsure which readiness requirement is missing. [SCREENSHOT: Project Versions list with a selected version ready to open] ## Understanding How Published Docs Are Organized In Atloria’s published documentation, you move through a structured reading experience rather than an editing workspace. You are not expected to create pages, change settings, or use project tools here. Instead, you read through a public documentation site that is organized into sections, pages, and headings. At the highest level, readers usually begin on a documentation home page or a category landing page. These top-level areas group related topics together so you can start broad and narrow down. A category might contain a parent page that introduces the topic, followed by child pages that cover specific tasks or detailed explanations. When a section contains multiple layers, the navigation shows that hierarchy so you can tell which pages belong under the same topic. Inside an individual page, Atloria also helps you move through the content with heading-based navigation. This on-page table of contents is different from the main sidebar. The sidebar helps you move between pages and categories. The table of contents helps you jump to a section within the page you are already reading. If you want another topic, use the sidebar. If you want another section on the same page, use the table of contents. You can also confirm your location by checking visible page cues: - The page title at the top - Section headings inside the page - The surrounding page hierarchy in the navigation - Any breadcrumb-style location trail shown above the content These cues work together. If the title says one thing but the headings focus on something else, you may be on a broader parent page instead of the exact task page you need. [SCREENSHOT: Published documentation page showing the left navigation, page title, and on-page table of contents] If you already worked through [Managing Reader Navigation in Published Documentation](doc:managing-reader-navigation-in-published-documentation), think of this guide as the next step: using that structure to locate the exact page more quickly. ## Browsing Categories from the Main Documentation Navigation When you want to find a topic in Atloria’s published docs, start with the main documentation navigation rather than scrolling through random pages. The left navigation area or primary sidebar is where related content is grouped into categories. This is the fastest way to move from a broad subject to a specific page. 1. Open the published documentation home page or any page in the docs site. 2. Look at the left sidebar for the main category list. 3. Select a category that matches your goal as closely as possible. 4. Expand that category to reveal child pages or nested sections. 5. Keep opening deeper levels until you see page titles that match the task you want. As you expand the navigation tree, pay attention to how page names are written. Some labels signal broad orientation pages, while others clearly point to a task. For example: - Broad pages often use wording like “Understanding,” “Overview,” or a category name by itself. - Task pages usually begin with action words such as “Using,” “Managing,” “Creating,” “Configuring,” or “Reviewing.” - Reference-style pages often focus on a specific content type, screen, or detailed reading topic. This matters because a category landing page may help you understand the section, but it may not answer a specific question. If you need instructions, continue into the child pages under that category instead of stopping at the first matching title. Expanded navigation is especially useful when several topics look similar. Rather than backing out to the documentation home page each time, stay inside the same branch and compare nearby pages. If one page feels too general, the next level down often contains the exact task-focused page you need. [SCREENSHOT: Expanded documentation sidebar showing a category, subcategory, and selected page] Following the category hierarchy in this way helps you stay oriented. You always know whether you are still in the same topic area or whether you have moved into a different part of the documentation set. ## Using the Table of Contents to Scan a Page Quickly Once you open a page in Atloria’s published docs, the fastest way to judge whether it contains the answer you need is the on-page table of contents. This area is built from the page’s section headings and gives you a quick preview of what the page actually covers. Before reading the full page, scan the table of contents and compare the heading names with your question. If you are looking for a specific task and the headings focus on background or general explanation, you may be on the wrong page. If the headings match the steps or concepts you expected, stay on the page and jump directly to the section you need. 1. Open the page from the sidebar navigation. 2. Find the table of contents near the page content. 3. Read the heading names from top to bottom. 4. Select a heading to jump straight to that section. 5. Use the table of contents again whenever you need to move to another section on the same page. This is especially useful on long pages. Instead of scrolling back and forth, you can move directly between sections such as setup details, workflow steps, and related reading areas. If you are comparing parts of the same page, the table of contents becomes your shortcut for repeated movement. The heading names also help you decide whether to stay on the page or return to the surrounding category. For example: - If the headings describe a complete workflow, the page is likely task-focused. - If the headings explain ideas or definitions, the page is likely conceptual. - If the headings break down items, fields, or detailed structures, the page may be more reference-oriented. When the heading you need is missing, that is a strong sign to check a sibling page in the same category rather than forcing your way through unrelated content. [SCREENSHOT: On-page table of contents with several headings, one selected and highlighted] Using the table of contents this way turns each page into a quick decision point: read here, jump within the page, or return to nearby pages in the same branch. ## Choosing the Right Page from Titles, Headings, and Navigation Cues In Atloria, the best way to confirm that you are on the right page is to compare several visible cues together instead of relying on the page title alone. A title may place you in the correct topic area, but the headings and surrounding navigation tell you whether the page is the exact match for your goal. Start with the page title at the top of the content area. Then compare it with the label highlighted in the sidebar. If both match, you know which page you opened. Next, look at the section headings or the table of contents. These show what the page actually covers in detail. Use these cues to judge the page type: - A page with broad headings is often a parent topic or orientation page. - A page with action-based headings usually supports a task or workflow. - A page with tightly focused headings often serves as a detailed reading or reference page. The surrounding navigation gives even more context. Check: - The parent category above the current page - Nearby pages in the same expanded branch - Nested items under the same section - Any breadcrumb-style trail shown above the content These clues help when two pages have similar names. One may be an introduction, while another may be the practical page you actually need. For example, a broader page may explain how a documentation area is organized, while a neighboring page may show how to complete a specific reading task inside that area. Consistent heading structure also helps you understand where you are in the full documentation set. If the page begins with orientation sections and then moves into detailed task sections, you may be on a parent page. If it starts immediately with direct instructions, you are more likely on the right destination. [SCREENSHOT: Page title, highlighted sidebar item, and breadcrumb-style hierarchy visible together] When these cues line up, you can move forward confidently. When they do not, use the current branch in the navigation to check the closest related pages before leaving the topic area entirely. ## Moving Between Related Pages Without Losing Your Place When you browse published docs in Atloria, you do not need to restart from the documentation home page every time a page is close but not quite right. The easiest approach is to move within the same navigation branch so you can compare related pages while keeping your place in the overall structure. 1. Start on the current page and check the table of contents for the section you need. 2. If the heading is missing, look back to the left navigation. 3. Use the expanded category branch to open a nearby page in the same section. 4. If you need a broader explanation, return to the parent category or parent page. 5. Watch which page stays highlighted so you always know your current location. This approach works well because related pages usually sit next to each other in the same branch. If one page is too broad, a child page may be more specific. If one page is too narrow, the parent category may give you the context you need before you continue. The sidebar is especially helpful here. Keep an eye on: - Which category is expanded - Which page is highlighted - Which neighboring pages appear above and below the current page - Whether the current page sits under a parent topic with additional child pages If Atloria shows a breadcrumb-style trail above the content, use it when you want to step back one level without losing the section you were exploring. This is often faster than collapsing and reopening categories in the sidebar. A good habit is to use the table of contents first and the sidebar second. That keeps you on the current page when the answer is already there. Only switch pages when the heading structure shows the content is missing. [SCREENSHOT: Sidebar with one category expanded, current page highlighted, and nearby sibling pages visible] By moving this way, you stay inside the same topic area, compare pages more easily, and avoid the common problem of losing your place after several clicks. ## Fixing Common Problems When You Can't Find the Right Page Sometimes a page in Atloria looks promising at first, but once you open it, the content is either too broad, too narrow, or focused on a different question. When that happens, use the visible structure of the published docs to recover your place instead of starting over. If a category feels too broad, the usual fix is to expand deeper levels in the navigation tree. A top-level category often contains several child pages, and those child pages may contain even more specific subpages. Keep opening the branch until you reach individual task pages rather than stopping at the first category label that sounds familiar. If the current page seems related but does not include the section you need, check the on-page table of contents. This is the quickest way to confirm whether the missing topic is actually covered. If the heading is not listed, return to sibling pages in the same category. Staying in the same branch is usually faster than jumping to a completely different section. When page titles are similar, use multiple clues together: - Compare the page title with the highlighted sidebar label - Check the breadcrumb-style hierarchy - Read the first few section headings - Scan the table of contents for task wording versus general explanation This helps you tell the difference between an introductory page and a detailed how-to page. If you lose your place while browsing, simplify the navigation view. Collapse unrelated categories so only the branch you are using stays open. Then look for the highlighted current page in the sidebar. That highlight is your anchor point. From there, you can move up to the parent page or sideways to a sibling page without guessing. [SCREENSHOT: Sidebar with unrelated categories collapsed and the current page clearly highlighted] These small adjustments make a big difference. Most “I can’t find it” moments are really navigation-structure problems, and Atloria’s category tree, page headings, and current-page highlight usually give you enough information to get back on track. ## Overview - This guide focuses on how to find the right page in Atloria’s published documentation by using visible structure rather than search or editing tools. - You use two different navigation aids for two different jobs: - The **sidebar or category navigation** helps you move between sections and pages. - The **table of contents** helps you move within the page you are already reading. - The most reliable way to confirm you are in the right place is to compare: - The **page title** - The **highlighted page in the sidebar** - The **section headings** - The **breadcrumb-style hierarchy**, if shown - When a page is close but not exact, stay in the same navigation branch and compare nearby sibling pages before leaving the topic area. - If you lose your place, use the expanded category state and the highlighted current page in the sidebar to reorient yourself quickly. This guide builds on [Managing Reader Navigation in Published Documentation](doc:managing-reader-navigation-in-published-documentation) by showing how to use that navigation structure to pinpoint the page you actually need. ## Prerequisites - You should already be viewing a published documentation site in Atloria. - You should be comfortable opening pages from the public navigation sidebar. - It helps to understand the basic public reading experience covered in: - [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) - [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page) - If your documentation uses audience-specific navigation, you may also want to review: - [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content) For the next step, continue to [Finding and Reading Content in Published Documentation](doc:finding-and-reading-content-in-published-documentation). ## Reading version timeline details and progress signals In Atloria, start from your project workspace and open the version you want to review. If you need help getting back to the right version workspace, use [Managing Project Version Workspaces](doc:managing-project-version-workspaces). On the version record, focus first on the timeline details shown around the version status and progress information. These details help you decide whether the version is moving normally or slipping behind the project schedule. Look for date fields that show the planned timing of the version. In most cases, the key dates to compare are the **planned start date**, the **target release date**, and any visible completion or release marker that shows when work actually finished. When the target date is still ahead, the version may still be on track. When that date has already passed and the version is not complete, treat it as a delay that needs a status check before anyone moves it forward. The progress area is the next place to review. Atloria may show a completion percentage, a status badge, or other progress signals that tell you whether work is still active, already finished, delayed, or no longer continuing. Read these items together rather than one at a time. A version can show high completion but still be delayed if the target release date has passed. It can also show an active status even though the planned timeline suggests it should already be under review. Use the version status area to separate: - versions still being worked on - versions delayed against the target date - versions completed and ready for the next decision - versions canceled or no longer moving forward [SCREENSHOT: Version record showing status badge, progress indicator, planned start date, target release date, and completion marker] Before making any release decision, compare the version’s timeline with the broader project schedule shown in the surrounding project workspace. That quick comparison helps you see whether the version is aligned with the release plan or whether its dates and status need to be corrected first. ## Checking whether a version is ready for review or release When you open a version in Atloria, do not rely on a single badge to decide that it is ready. Review readiness is usually a combination of progress, current status, and whether any blocking items are still visible on the version. Start by checking whether the version appears complete enough to leave active work and enter review. If the version still shows unresolved work, incomplete progress, or a status that clearly indicates ongoing changes, it is usually too early to move it toward release. Compare the current state of the version with its planned scope. If the version was intended to include a specific set of documentation updates, make sure those updates are actually reflected in the version workspace before changing any status. A version can look nearly complete from a timeline point of view while still missing important content or review work. That is why readiness should be checked from both the schedule side and the work-completion side. Use the review-related status area on the version to confirm whether required checks have already happened. In Atloria, the version may show review status badges or decision indicators that tell you whether the version is still in progress, under review, approved, deferred, or blocked by a decision that requires more work. If a blocking decision is still visible, do not treat the version as ready for release even if the progress indicator looks complete. Keep these three states separate when you review a version: | Version state | What it means | |---|---| | Functionally complete | The work appears finished enough to stop editing and begin review | | Approved | A review decision has been recorded allowing the version to move forward | | Released | The version has actually been moved into its released state | These are not the same milestone. A version can be complete but not approved, or approved but not yet released. [SCREENSHOT: Version detail view with readiness indicators, review status badge, and release-related status area] If you need a deeper comparison before deciding, pair this check with [Working with Version Comparison Views](doc:working-with-version-comparison-views) or [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness). ## Recording review outcomes and updating version decisions Once a version has reached review, open its review or decision controls and record the outcome based on the current state of the work. In Atloria, this is where you move beyond general progress tracking and make a formal decision that other team members can see. Choose the outcome that matches the review result, such as **Approved**, **Needs Changes**, **Deferred**, or **Rejected**, if those options are available on the version. 1. Open the version record from the project workspace. 2. Find the review decision area or status controls on the version. 3. Select the outcome that matches the review result. 4. Add any notes, comments, or internal explanation that should stay with the version. 5. Save the change and confirm the updated status appears on the version. Be specific when you enter notes. Instead of leaving a short comment that only says the version is delayed, explain what caused the hold, what still needs attention, or why the version was approved despite a schedule shift. These notes are especially useful when another documentation manager, approver, or project lead returns to the version later and needs to understand the decision without reopening every related document. After saving the review outcome, make sure the lifecycle status also reflects that decision. For example, if the review result is positive, the version should no longer look like active draft work. If the review result is **Needs Changes** or **Deferred**, the visible status should make that clear so nobody mistakes it for a release-ready version. Then check the version history or activity area. Atloria should show that the review decision was saved, making the change visible for later reference. This is important when teams need to confirm who made the decision and when it happened. [SCREENSHOT: Review decision area with outcome selection, notes field, and saved status shown in the version activity history] For broader approval workflows, see [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions). ## Managing release-related status changes across the version lifecycle A version’s status in Atloria should follow the actual stage of work, not just the date on the calendar. As the version moves from planning into active work, then review, approval, release, and closure, use the version status selector carefully so the visible lifecycle matches reality. This matters because teams often use the status badge as the quickest signal for whether a version can still change, needs attention, or is ready to ship. 1. Start with the version in its early planning or draft state while dates and scope are still being set. 2. Move it into an active work state when documentation updates are underway. 3. Change it to a review-related state when editing is complete enough for formal review. 4. Mark it approved only after the review decision supports moving forward. 5. Change it to released only when the version is actually being released. 6. Use a closed or completed state only after release work is finished and no further action is expected. Avoid skipping steps. A version should not be marked **Released** just because the target release date has arrived. If review is incomplete or approval has not been recorded, keep the version in the correct pre-release state until those actions are done. This keeps the project workspace trustworthy for everyone who depends on it. Atloria also needs to reflect exceptions clearly. If a release is delayed, update the status so it no longer looks on schedule. If an approved version must be reopened, change the status back to an active or review state and adjust the dates if needed. If the version will not ship at all, use the canceled or postponed state available on the version rather than leaving it in a misleading in-progress or approved state. After every status change, recheck: - the current status label - the target release date - any actual release or completion marker - whether the progress display still matches the lifecycle stage [SCREENSHOT: Version status selector showing lifecycle stages from draft through released, with release date fields nearby] ## Using version history to explain schedule and status decisions The version history or activity stream in Atloria is where you confirm how a version reached its current state. When a target release date changes, a review decision is reversed, or a version suddenly appears delayed, the history gives you the clearest explanation without relying on memory or side conversations. Open the version and look for the activity area that lists recent changes tied to status, dates, and review updates. Use this history to answer practical questions: - Who changed the version status? - When was the target release date updated? - Was the version moved because of a review decision or a release action? - Did the version move from approved back into active work? - When was it marked ready, deferred, or released? Read the entries in order so you can follow the timeline of decisions. For example, if the version now shows a later release date, check whether the history also shows a deferred review outcome or a reopened status change around the same time. If the visible status says **Approved** but the latest activity shows a newer blocking decision, that mismatch tells you the version needs correction. This history is especially useful when you need to explain schedule changes to project leads or other administrators. Instead of saying the version was delayed at some point, you can point to the exact activity sequence: the original target date, the review result that paused progress, and the later update that changed the release plan. That makes the version record easier to trust and easier to hand off between team members. [SCREENSHOT: Version activity stream showing date changes, status updates, review outcomes, and user names] When you use history this way, always compare it with the current version header. The latest activity and the visible status should tell the same story. If they do not, update the version before anyone uses it for release planning. ## Fixing inconsistent timelines, readiness states, and release statuses Sometimes a version in Atloria shows mixed signals. You might see a version that looks 100% complete but is still marked as active work, or a version with a release date filled in even though it is not marked released. These mismatches can confuse reviewers and lead to the wrong release decision, so fix them directly on the version record before moving forward. Start by comparing the most visible fields on the version: - progress or completion indicator - current status badge - target release date - actual completion or release marker - review outcome or approval state If the progress looks complete but the version is still blocked from review, check whether the review decision is missing or whether the status was never advanced from draft or in progress. If the version appears ready but still carries a blocking review result such as **Needs Changes**, **Deferred**, or **Rejected**, update the review outcome only after the underlying issue has actually been resolved. For release-date mismatches, make sure the dates and status agree with each other. A version should not show an actual release marker while still carrying an unreleased status. In the same way, a version marked **Released** should not still look like it is awaiting review. If a previously approved version was reopened, update both the lifecycle status and any related timeline fields so the record no longer looks final. 1. Open the version and review the status, dates, and decision area together. 2. Check the version history to see which value was changed last. 3. Correct the status or review decision that no longer matches the current state. 4. Update any date fields that should reflect the latest plan. 5. Save the version and confirm the header, readiness signals, and history now align. [SCREENSHOT: Version with mismatched progress, review status, and release date fields highlighted for correction] If inconsistencies keep appearing, compare the version against your project’s normal release flow and the guidance in [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness). ## Overview This guide focuses on the decision-making side of version management in Atloria. You use these steps after a version workspace already exists and work is underway. The goal is to read the version’s timeline, understand whether it is on schedule, decide if it is ready for review, and keep the status aligned with what is actually happening in the release cycle. The most important screens are the project version record, the version status area, the review decision controls, and the version history or activity stream. Together, these parts of Atloria show whether a version is still being worked on, delayed against its target release date, approved for release, or already released. They also help you explain why a decision was made when someone asks later. Use this guide when you need to: - judge whether a version is on track - decide if a version should move into review - record an approval, deferral, rejection, or change request - update release-related statuses without creating confusion - investigate why a version’s dates and status do not match This guide does not repeat workspace navigation or general version browsing. For that foundation, refer to [Managing Project Version Workspaces](doc:managing-project-version-workspaces). It also does not go deep into side-by-side comparisons or detailed approval workflows, which are covered in related version documents. A good working habit in Atloria is to read the version header, timeline fields, readiness indicators, and activity history together before changing anything. That quick review helps you avoid marking a version ready too early or leaving it in an outdated state after a review decision. [SCREENSHOT: Project version page showing the main areas used for timeline review, status decisions, and history checks] ## Prerequisites Before you manage timelines and status decisions in Atloria, make sure you already have access to a project that includes at least one documentation version. You should also be comfortable opening the version workspace and identifying the version record you want to review. If you are not there yet, start with [Managing Project Version Workspaces](doc:managing-project-version-workspaces). You will get the most value from this guide if the following are already true: - You can open a project and locate its versions. - You understand the basic difference between draft work, review, approval, and release states. - You have permission to update version details or record review decisions. - The version already contains enough work to evaluate progress and readiness. - Your team is using version statuses consistently enough that the visible badges and dates matter for release planning. It also helps to have related information available before you begin reviewing a version: - the planned release timing for the project - the version’s current target release date - any review feedback already recorded on the version - the latest activity history for recent status or date changes If your team is still deciding how statuses should be interpreted, read [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) and [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness) before making release decisions. After you are comfortable reading timelines and recording status changes, continue with [Coordinating Version Work Before Release](doc:coordinating-version-work-before-release) to organize the final handoff from active version work into release preparation. ## Defining Which Readers Need Separate Release Views Start by listing the audience groups you already manage in Atloria and deciding which of them need their own public documentation experience. In most teams, that means separating readers such as customers, partners, and internal teams when they should not all see the same release notes, upgrade guidance, or feature pages. If you already reviewed how audience-specific pages appear in the public site, use that work as your starting point instead of rebuilding it from scratch: [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation). A simple planning table helps keep these decisions clear before you publish: | Audience | Public content to include | Content to keep out of that view | Main release focus | |---|---|---|---| | Customers | Published feature pages, release notes, upgrade guidance | Internal procedures, draft material | Current and archived versions | | Partners | Shared feature pages, partner-facing release notes | Internal-only workflows | Current, upcoming, and archived versions | | Internal teams | Full release context, internal process pages | Nothing intended only for external readers | Current, upcoming, and archived versions | For each audience, write down the reader goal in plain language. For example: - Customers may need to land on the latest release notes, then open feature documentation for the version they use. - Partners may need to compare current and upcoming releases before supporting shared accounts. - Internal teams may need access to pre-release content and archived guidance in one place. As you define these groups, decide which version paths matter most to each one: - **Current version** for active readers - **Upcoming version** for preview or preparation - **Archived version** for older deployments [SCREENSHOT: audience planning worksheet showing audience names, visible content, hidden content, and version priorities] Keep the result practical. If two audiences would see the same landing page, same version selector, and same page set, they probably do not need separate release views. Create separate public views only when the reader journey, visible content, or version path is meaningfully different. ## Mapping Version Paths Before You Publish Once your audience list is settled, map the public paths readers will use to reach each release. In Atloria, this planning step matters because readers may arrive through a project’s public documentation home, a version-specific page, release notes, or a shared link. Before publishing, decide which path is the default for each audience and how older releases stay available. Document three path types for every audience-specific public view: 1. The **current version** path readers should reach by default. 2. The **older version** paths that remain available for support, migration, or compliance. 3. Any **audience-specific entry page** that acts as the front door for that reader group. Then list the pages that must exist in every version path. At minimum, most release views need: 1. A landing page for that audience 2. Release notes 3. Upgrade or migration guidance 4. Core feature documentation If one of those pages is missing in an archived version, note that before publishing so the team can either add the page or remove links that would send readers to an empty path. You should also decide how readers move between versions: 1. Stay inside the same audience view and switch versions with a version selector 2. Move from one audience landing page to another when the audience changes 3. Follow direct links from release notes into version-matched feature pages [SCREENSHOT: version path map showing current, archived, and audience-specific public entry pages] Finally, record redirect decisions for pages that were renamed, moved, or retired. If a release note links to an older page title, that link should still guide the reader to the right public page instead of dropping them into the wrong version or a missing page. This is especially important when shared pages appear in multiple audience views but point to different release paths. Your plan should show where each old link now leads so publishing does not break existing bookmarks or support references. ## Designing Reader Journeys Across Audience and Version Boundaries After mapping paths, walk through how real readers will move across them. In Atloria, audience-specific release planning works best when you trace the journey from entry point to destination page instead of thinking only about page lists. A customer may arrive from search on a direct release note link, while a partner may start from an audience landing page and then switch to an archived version. Those journeys need different signposts. Focus on the most common entry routes: 1. A reader opens a search result that points directly to a versioned page. 2. A reader uses a bookmarked URL for a specific release. 3. A reader starts on an audience-specific landing page and browses from there. 4. A reader opens release notes first, then follows links into feature documentation. For each route, note the decision points where the reader must choose: 1. Which audience view they belong in 2. Which version they need 3. Whether they want the latest release or an archived release Plan the navigation elements that keep those choices visible: - A clear version selector - Audience labels on landing pages or page headers - Links back to the correct audience landing page - Release notes links that stay inside the same version path [SCREENSHOT: public documentation page with version selector, audience label, and link back to the audience landing page] Also check where readers could accidentally cross into the wrong path. Common trouble spots include shared links, search results, and release notes that point to a page in another audience view. When you find one of these risks, write down how the public view should prevent confusion. For example: - Keep audience labels visible on entry pages - Make version labels easy to spot - Avoid linking from one audience’s release notes into another audience’s landing page unless that jump is intentional This planning stage should leave you with a simple answer for every major journey: where the reader enters, what they choose next, and how Atloria keeps them in the right release view. ## Setting Rules for What Appears in Each Public View With the journeys mapped, define the visibility rules for each audience-specific public view. In Atloria, this means deciding exactly which sections, pages, and release note entries appear for each audience before anything is published. Clear rules prevent last-minute confusion when writers prepare release content across multiple versions. Start with inclusion rules. For each audience, list the content that should always appear in its public view: - Audience landing page - Version-specific feature pages - Release notes entries intended for that audience - Upgrade or migration guidance for supported versions - Shared documentation pages that are safe for that audience Then define exclusion rules just as clearly. Mark content that must stay out of a public audience view, such as: - Internal-only procedures - Draft or pre-release material not intended for that audience - Support workflows meant only for internal teams - Pages that belong to a different audience journey A shared-page plan is especially important. Sometimes the same topic appears in more than one audience view, but each audience should reach a different version path or a differently framed landing page. In that case, document: - Which audience sees the page - Which version path the page belongs to - Whether the title stays the same across audiences - Which release notes should link to it Use consistent naming so readers can tell where they are. Your plan should define how you will label: - Audience names - Version labels such as current or archived - Landing page titles - Shared page titles that appear in more than one public view | Item to label | Keep consistent by deciding | Example planning question | |---|---|---| | Audience badge | Exact audience name | Will you use “Customers” everywhere? | | Version label | Same wording across pages | Will archived pages always say “Archived”? | | Landing page title | Standard title pattern | Will every audience page start with the same product name? | | Shared page title | Reuse or audience-specific variation | Does the same topic need different wording for partners? | [SCREENSHOT: release planning sheet showing included pages, excluded pages, and naming rules by audience] When these rules are written down before publishing, writers can build release content without guessing which pages belong in each public view. ## Reviewing the Plan with Writers and Stakeholders Before you publish, review the full plan with the people who own content, approvals, and public experience decisions. In Atloria, this usually means walking through the audience matrix, version paths, and reader journeys with technical writers, documentation managers, and anyone responsible for release communication. The goal is not to redesign the plan during the meeting. The goal is to confirm ownership, scope, and publishing readiness. Use the review to answer practical questions: 1. Which writer owns each audience landing page? 2. Who is responsible for release notes in each version path? 3. Which shared pages must appear in more than one audience view? 4. Which pages are intentionally excluded from public release views? A live walkthrough works best when you use sample navigation flows instead of abstract discussion. Open the planned audience entry pages, then trace how a reader would move to: 1. The current version 2. An archived version 3. Release notes 4. Related feature documentation [SCREENSHOT: review session checklist showing audience entry page, version path, release notes, and related content checks] Ask stakeholders to confirm three things for every targeted audience: - There is a clear public entry page - The version path is visible and understandable - The route to related release content is complete You should also capture sign-off criteria in writing. Keep it simple and specific: - Audience definitions are approved - Version path structure is approved - Visibility rules are approved - Required pages exist for each release view - Redirect decisions for moved or retired pages are approved If your team also manages broader audience settings across projects, align this review with the guidance in [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation) and [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences). That way, your release view plan matches the audience structure already in use across Atloria. ## Common Planning Mistakes and How to Fix Them Audience-specific release views usually break down in predictable ways. If you catch these issues during planning, you can avoid confusing public readers after publishing. One common mistake is sending readers into the wrong version path. This often happens when the default version selection points to an older release, or when a landing page links to the wrong release notes set. If you see this in your plan, check: - Which version opens by default - Whether landing page links point to the intended release - Whether redirects send old links to the correct version path Another issue is exposing the wrong content in an audience-specific public view. A page may be useful internally but should never appear for customers or partners. Fix this by reviewing your inclusion and exclusion rules side by side. If a page is shared, confirm that it belongs in that audience’s public path and not only in an internal release view. Navigation drift is another frequent problem. Across multiple releases, labels can become inconsistent. One version selector may say “Latest,” another may use a version number, and a third may show an archived label differently. Compare these items before publishing: - Version selector labels - Audience labels - Shared page titles - Landing page naming patterns Search can also send readers into the wrong journey. If public search results surface the wrong audience page or the wrong release, review which pages are meant to be publicly discoverable. Make sure versioned pages and audience-specific pages are the ones you expect readers to find first. [SCREENSHOT: planning review notes highlighting wrong version default, inconsistent labels, and incorrect audience visibility] When you find a mistake, update the release plan itself, not just the page draft. The plan should remain the single source for audience definitions, version paths, and visibility rules. That makes later publishing reviews much faster and gives your team one place to verify whether a release view is ready. ## Overview Use this planning process when your team is preparing public documentation that should look different for different reader groups across multiple releases. In Atloria, this is most useful when customers, partners, and internal teams need separate landing pages, different release notes visibility, or different paths into current and archived versions. This document focuses on planning decisions you should make before publishing: - Which audiences need separate public release views - Which version paths each audience should use - How readers move between landing pages, release notes, and feature pages - What content appears or stays hidden in each public view - How writers and stakeholders confirm the plan before release This guide does not repeat the page-level review process covered in [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation). Instead, it helps you step back and design the release structure around those pages so the public experience stays consistent once versioned content is live. You will get the most value from this guide if you are responsible for one of these jobs: - Planning public documentation releases - Organizing audience-specific landing pages - Coordinating release notes and version navigation - Reviewing publishing scope with writers or documentation managers By the end of your planning work, you should have a clear release map for each audience in Atloria, including entry pages, version paths, shared content rules, and sign-off criteria. That plan becomes the reference point for publishing and for later validation when you test public audience journeys. ## Prerequisites Before using this guide, make sure you already have the basic audience structure and public page review work in place. This planning process assumes you are not starting from a blank slate. You should already have: - A signed-in Atloria account with access to the relevant project workspace - A project that already has documentation content, release content, or both - Audience definitions that have been created or agreed on for the project - A public documentation structure that has already been reviewed at the page level - A list of versions you expect readers to access, such as current and archived releases It also helps if you have already worked through these related guides: - [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences) - [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation) - [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) Bring these materials into your planning session if they are available: - Your audience list - Draft release notes structure - Proposed landing pages for each audience - Current and archived version names - Notes about pages that were renamed, moved, or retired If your team shares responsibility for public publishing, include the people who manage release notes, public navigation, and audience settings. That will make it easier to confirm path structure and visibility rules in one pass instead of revisiting the release plan later. The next step is [Reading Audience Tailored Documentation](doc:reading-audience-tailored-documentation), which shows how these planned release views translate into the actual reader experience. ## Opening a version review and reading the outcome In Atloria, start from the **version details** screen for the version you submitted for review. This is the best place to understand the current decision because it brings together the **review status**, the **discussion area**, and any **comparison view** used during review. If you already worked through review decisions in [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions), use that same version record and focus on the feedback attached to it. Look first for the **review status indicator** on the version. This status tells you the overall outcome at a glance, such as **Approved**, **Changes Requested**, or **Rejected**. Treat that badge as a starting point, not the full answer. A version can show a clear status while the real detail lives in the reviewer conversation. Open the **review panel** or **comment thread** and read each reviewer note carefully. Reviewers may explain why they approved the version, what still needs work, or what prevented approval. If several people reviewed the same version, read all comments before deciding what to change. Pay attention to where each comment appears: - Some comments apply to the **entire version** - Some are attached to a **specific section** - Some are tied to **highlighted content** in the **diff** or comparison view - Some point to **changed text** only, which helps you focus on what was updated since the last version When feedback is attached to a highlighted area, open the related comparison or changed-content view so you can see the exact wording under review. This is especially useful when a reviewer comments on a small edit that is easy to miss in the full document. [SCREENSHOT: Version details page showing review status badge, comment thread, and comparison area] ## Understanding what reviewers are asking you to change Once you have read the outcome, sort the feedback by importance. In Atloria, the most urgent comments are the ones that clearly block release. These usually appear when the version status is **Changes Requested** or **Rejected**, but you should still read the wording in the comment thread to understand the exact expectation. Look for signs that a comment is **blocking**: - The reviewer says the version is **not ready** - The comment points out an **accuracy problem** - The reviewer identifies **missing information** - The note asks for a correction before approval can continue - The review outcome itself is **Changes Requested** or **Rejected** Other comments may be helpful but not release-blocking. These often read more like suggestions, wording improvements, or style preferences that can be handled later if your team agrees. Use the context around each comment to understand what needs to change. Atloria may show feedback beside highlighted text, within a specific content area, or against a changed section in the version comparison. That context matters. A short comment like “clarify this” is much easier to interpret when you can see the exact paragraph or changed line it refers to. As you review the thread, group similar comments together. Repeated themes often point to a larger issue, such as: - **Accuracy** problems across several sections - **Style** or wording corrections throughout the version - **Missing details** in setup, release notes, or feature explanations - Gaps between the updated content and the reviewer’s expectations Also check whether the reviewer expects: - a **direct edit** to the content - a **reply in the thread** with clarification - a **revised version** for another review pass If the request is not obvious, do not guess. Use the existing comment thread to confirm what the reviewer wants before changing the version. ## Responding to requested changes and rejections When a version comes back with **Changes Requested** or **Rejected**, respond in the review conversation before you start editing. A short reply in the existing **comment thread** helps reviewers see that you received the feedback and are acting on it. This is especially helpful when several reviewers are involved or when the version has multiple open comment threads. Your reply should make the next action clear. For example, you might note that you are updating the affected section, checking related pages, or preparing a revised version for another review. Keeping that note in the same thread creates a visible record on the version details screen. After that, make the required updates in the draft or revised version. The right path depends on how your team handles version changes in Atloria, but the key point is the same: update the actual content that the reviewer flagged, not just the discussion. If the reviewer rejected the version because of larger issues, review the full set of comments before editing so you can address everything in one pass. As you complete each fix, return to the related comment thread and verify that the content now matches the request. Only then should you mark that conversation as resolved, if that option is available on the review screen. Avoid resolving comments too early, because unresolved threads are often the easiest way for reviewers to track what still needs attention. Before asking for another review, add a clear follow-up note that summarizes what changed. Keep it specific: - which sections were updated - which comments were addressed - whether any suggestions were deferred - whether the version is ready for re-check That summary saves reviewers time and reduces back-and-forth during the next review cycle. [SCREENSHOT: Review thread with author reply, updated comment status, and response summary] ## Coordinating follow-up with reviewers before release After you finish the edits, bring the right people back into the review. In Atloria, use the **reviewer assignment**, **mentions**, or any available **notification** controls on the version discussion area to direct attention to the updated version. This is more reliable than assuming reviewers will notice the changes on their own. Focus first on the people whose approval is required for release. If your version has multiple reviewers, check whether all assigned reviewers have responded or whether some are still marked as pending. A version may look nearly complete while still waiting on one required decision. The version details screen is the best place to track follow-up. Review it for signs that work is still open: - **unresolved comment threads** - a **pending review** indicator - reviewers who have not yet responded - earlier decisions that may no longer apply after edits If you updated the version after feedback, mention that directly in the discussion area so reviewers know what changed since their last visit. A short note such as “updated the installation section and corrected the release notes based on review comments” gives reviewers a clear starting point. It also helps to record release readiness in the same visible area. Use the version discussion or approval area to leave a concise note about the current state, such as whether all requested changes are complete, whether any non-blocking suggestions remain, and whether the version is being held for one final check. This creates a shared decision trail for everyone involved in the release. If you need a refresher on broader approval handling, return to [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). For follow-up work, stay focused on the open comments and current approval state shown on the version itself. ## Deciding when a version is ready to move forward A version is ready to move forward only when the current version record shows that review work is complete. In Atloria, do not rely on memory or earlier comments alone. Open the latest version and confirm that the visible review state matches the content that is actually on screen. Start by checking that all accepted feedback has been applied to the latest version. Review the updated sections, then compare them against the open and resolved comment threads. Make sure there are no unresolved comments that still refer to active problems. If a comment is outdated because the content changed, verify that the latest wording truly fixes the issue before treating that thread as complete. Next, check the **final approval state** again after resubmission. This matters because earlier approvals may no longer represent the current version if substantial edits were made afterward. A version that was once approved may need another review pass if important sections changed. Use the current review outcome to guide your decision: - Move toward release when the version shows the needed approval state and no blocking feedback remains - Request another review cycle when major edits were made after the last decision - Hold the version when comments are still unresolved, reviewers are still pending, or the outcome does not support release Be especially careful after large revisions. If the version content changed significantly between review rounds, make sure the release decision reflects the newest draft, not an older approval. The safest habit is to treat the version details page as the source of truth for readiness. The next step in this workflow is [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval), where you move from review follow-up into final release signoff. ## Fixing common problems during review follow-up Most review follow-up problems come from looking at the wrong revision, missing an open thread, or assuming an earlier decision still applies. In Atloria, the fastest way to troubleshoot is to return to the **version details** screen and check the current review state, discussion area, and comparison view together. If comments seem outdated after edits, first confirm that you are viewing the **latest version**. Then open the **comparison view** and make sure you are comparing against the correct earlier revision. A reviewer comment may look incorrect simply because you are reading it against an older draft or the wrong set of changes. If the version still shows **Pending Review**, check for these common causes: - one or more **unresolved comment threads** - a required reviewer who has not responded - a follow-up round that was started but not completed - a version update that needs another approval pass If approval appears to have disappeared after you made changes, verify the current approval state on the version after the new submission or update. In some review workflows, a significant revision means the earlier approval no longer applies to the latest content. Instead of relying on the old outcome, ask reviewers to confirm the updated version directly. When feedback is unclear, stay in the same comment thread and ask for a concrete change request. Good follow-up questions are specific to the content under review, such as whether the reviewer wants a factual correction, extra detail, or a wording change. This keeps the discussion tied to the exact section and helps avoid unnecessary edits. [SCREENSHOT: Version review screen showing pending review status, unresolved comments, and latest revision comparison] ## Overview Version review follow-up in Atloria is about turning reviewer decisions into clear action on the **version details** screen. The main items to watch are the **review status badge**, the **comment thread**, any **highlighted feedback** attached to content, and the current **approval state** after edits. Those elements together tell you whether the version can move forward or needs more work. Keep these core ideas in mind: - **Status badges** such as **Approved**, **Changes Requested**, and **Rejected** show the overall outcome - **Comment threads** explain the reason behind that outcome - **Highlighted comments** and the **comparison view** help you locate the exact content under review - **Unresolved comments** and **pending reviewers** usually mean follow-up is still open - **Updated versions** may need a fresh approval check before release This guide focuses on what to do after a review decision has already been made. If you need help with the earlier request-and-decision process, use [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions). If you need help interpreting statuses and comment behavior more generally, see [Understanding Review Statuses Comments and Next Steps](doc:understanding-review-statuses-comments-and-next-steps). A practical review habit in Atloria is to read the full discussion before editing, make all related content changes together, and then leave a short response note explaining what changed. That keeps the version history easier to follow and makes re-review faster for approvers. The goal is not just to clear comments. The goal is to make sure the current version, the visible review outcome, and the release decision all match. ## Prerequisites Before you work through review feedback in Atloria, make sure you already have access to the version that was submitted for review and that the version has an active review outcome or comment history on its **version details** page. You do not need special setup steps in this guide, but you do need to be in the right place in the workflow. You should already be comfortable with these tasks: - opening a project and selecting the correct **documentation version** - viewing the **version details** screen - reading **review statuses** and **approval outcomes** - using the **comment thread** and any available **comparison** or **diff** view - updating the version content or revised draft after feedback This guide assumes you have already completed the earlier review stages covered in: - [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) - [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals) - [Understanding Review Statuses Comments and Next Steps](doc:understanding-review-statuses-comments-and-next-steps) - [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review) It also helps if the version already includes: - at least one reviewer decision, such as **Approved**, **Changes Requested**, or **Rejected** - visible reviewer comments in the version discussion area - a latest revision you can compare against earlier changes, if follow-up edits were made If you open the version and do not see any review status, comments, or approval activity, you may still be earlier in the workflow. In that case, return to the review request process before using the follow-up steps in this guide. ## Understanding which audit events support release checks In Atloria, the **Audit History** view is most useful when you treat it as a timeline of what happened during a release cycle. Each row in the activity list represents a recorded action tied to a specific item, such as a documentation page, version-related item, project area, or export-related action. The value of this screen is not just that it shows activity, but that it shows activity in order, with enough detail to confirm whether the right steps happened before a release moved forward. For release checks, Project Administrators and Documentation Managers usually focus on events that prove work was reviewed and finalized correctly. That often includes page edits, review or approval actions, status changes that mark content as ready, comment-related activity when review feedback has been cleared, and export or publication-related actions. If your team already uses export checks from [Managing Audit Record Exports for Compliance](doc:managing-audit-record-exports-for-compliance), the Audit History screen helps you verify the surrounding review activity instead of only the export itself. A useful audit row normally gives you the details reviewers need at a glance: | What to look at | Why it matters for release checks | |---|---| | **Action** | Shows what happened, such as an edit, approval, status update, or export | | **Target item** | Identifies the page, release item, or content area affected | | **Actor** | Shows who performed the action | | **Timestamp** | Confirms when the action happened | When you scan the list, you are looking for a sensible sequence. For example, a reviewer approval should appear before the export tied to that release window, and a publication action should not appear before required review steps. [SCREENSHOT: Audit History list showing action, target item, actor, and timestamp columns] ## Preparing the audit view for a release review Before you start checking individual events, narrow the **Audit History** view so it only shows activity related to the release you are reviewing. A broad activity list is hard to use because it mixes routine edits, unrelated projects, and older release cycles into the same timeline. A focused view makes it much easier to confirm whether the current release followed your team’s expected process. 1. Open the area in Atloria where audit activity is available for your team’s review workflow, such as the project activity area or the administrative audit area. 2. Set the **date range** to match the release window you are checking. Use the start of the review cycle as the beginning point and the export or publication date as the end point. 3. Apply any available scope filters, such as **project**, **space**, **document set**, or the release-related item you are validating. 4. Narrow the list further with **action type** filters so the screen focuses on approval, status, export, and publication activity instead of every edit. 5. If needed, filter by **user** to review actions completed by a specific reviewer, approver, or documentation manager. This setup matters because release checks are usually about a defined set of content, not the whole workspace. If your team is preparing one project for publication, filtering to that project keeps unrelated work out of the evidence. If you are checking a specific documentation set before export, filtering to that content area helps you avoid false matches from similar actions elsewhere in Atloria. Once the filters are in place, review the list from oldest to newest. That makes it easier to see whether the release moved through review in the correct order. [SCREENSHOT: Audit History filters with date range, project filter, action type filter, and user filter selected] ## Checking that required documentation actions were completed After filtering the activity list, go milestone by milestone and confirm that every required release action appears in **Audit History**. The goal is to verify that the documented process actually happened, not just assume it did because the content looks finished. For most teams, that means checking for a draft completion point, reviewer approval, any final edit, and the status change or release-ready action that signals the content was ready to move forward. 1. Start with the earliest release milestone in the filtered list and identify the row that shows the content entered review or reached a draft-complete stage. 2. Find the approval-related event and confirm it appears for the correct page, document set, or release item. 3. Check whether any final edit happened after review comments were resolved and before the release moved ahead. 4. Look for the status update that marks the content as ready for export or publication. 5. Use the item link in the audit row, if available, to open the affected content and confirm the current page still matches the recorded action. Pay close attention to the **actor** and **timestamp** columns. The actor should match the person responsible for that step, such as the assigned reviewer or documentation manager. The timestamp should also make sense in sequence. An approval that appears after an export, or a final edit that appears after sign-off, is a warning that the release may need another review pass. This is also the point where you compare the audit trail with your release assignments. If the row shows the wrong person completed a key action, do not ignore it. Review the item carefully and confirm whether the action was intentionally completed by someone else. [SCREENSHOT: Filtered audit list with one approval event and one final status event highlighted] ## Using audit history to approve exports and public releases Once you have confirmed the required actions, use the audit trail as evidence for the release decision itself. In Atloria, this means matching the filtered **Audit History** results to your team’s release checklist and making sure the final steps happened in the right order. The audit list should support the decision to export, share, or publish—not leave open questions. 1. Compare the filtered audit results with your release checklist and confirm that every mandatory review step has a matching event. 2. Check the final sequence of release activity, looking especially for approval before export and export before publication. 3. Review the timestamps to make sure no late edits were made after sign-off without a new approval. 4. If the timeline is clean, use the audit results as supporting evidence for the release approval or stakeholder sign-off. A reliable release sequence usually looks like this: | Release checkpoint | What to confirm in Audit History | |---|---| | Review completed | Approval or sign-off event appears for the correct content | | Final content state confirmed | Last required edit or status change appears before release actions | | Export created | Export-related action appears after approval | | Public release completed | Publication-related action appears last | Managers often rely on this timeline during compliance reviews, internal approvals, and post-release verification. If someone later asks who approved the content, when it was exported, or whether publication happened after review, the audit trail gives you a dated record instead of a verbal confirmation. Pause the release if the timeline shows missing approvals, edits after sign-off, or an export created before the final review was complete. In those cases, the safest next step is to return to the content, complete the missing review action, and then repeat the release check before moving ahead. [SCREENSHOT: Audit History timeline showing approval, export, and publication events in sequence] ## Saving and sharing audit evidence for reviewers When the **Audit History** view shows the right release activity, save that evidence in a form reviewers can easily understand. The most useful evidence is focused and specific: it should show the release window, the filtered action types, and the users involved in the decision. Avoid sharing a full unfiltered history when a smaller, release-specific record is enough. Capture the filtered results exactly as you reviewed them. If your team shares screenshots in approval packets, make sure the image includes the active filters and the visible event rows. If your team uses exported audit results, keep the export tied to the same filter settings you used during the release check. Either approach works as long as the evidence clearly shows what was reviewed. The key details reviewers usually need are: | Field to capture | Why reviewers need it | |---|---| | **Action** | Confirms what happened | | **Target item** | Shows which page, content set, or release item was affected | | **Actor** | Identifies who performed the step | | **Timestamp** | Proves when the step occurred | | **Release context** | Connects the event to the specific review window or release decision | You can attach this evidence to a review packet, approval request, or release record so the decision can be revisited later if needed. Screenshots are especially helpful when you want to show the exact filtered view a manager approved. [SCREENSHOT: Audit History results prepared for sharing with filters visible] If your team keeps release records over time, store the audit evidence alongside the release notes or approval materials. That makes later audits, incident reviews, and stakeholder questions much easier to answer because the supporting record stays with the release decision. ## Fixing common audit-history gaps before release If the audit trail does not show what you expected, fix the gap before approving the release. Most issues come from filters, timing, or actions completed outside the normal Atloria workflow. The important thing is to treat missing or confusing records as a release blocker until you understand them. - **No approval event appears in the log** - Recheck the **date range** first. The approval may sit just outside the current release window. - Review the **action type** filters and make sure approval-related events are included. - Confirm you are looking at the correct **project**, **space**, or content area. An approval recorded in a different area will not appear in the current filtered view. - **The audit trail shows edits after sign-off** - Open the affected page or release item from the audit row. - Review what changed after the approval. - If the change affects release content, reopen the release check and require a fresh approval before export or publication. - **The wrong user appears as the actor** - Confirm whether the action was completed by a delegate, a shared team login, or another approved participant in the workflow. - If the recorded actor does not match your expected reviewer, verify the release assignment before accepting the event as valid evidence. - **Export or publication events are missing** - Check whether the release action was completed through the supported Atloria screens used for tracked export or publication steps. - If the action happened outside that tracked flow, repeat it from the proper Atloria screen so the release record includes the expected event. When in doubt, rebuild the filtered view from scratch and review the timeline again from oldest to newest. A clean, narrow audit view usually reveals whether the issue is a filter problem or a real workflow gap. [SCREENSHOT: Audit History with missing approval event and filters being adjusted] ## Overview Use **Audit History** in Atloria when you need proof that a release followed the right review path before export or public publication. This screen is especially helpful for Project Administrators and Documentation Managers who need to confirm that approvals, final edits, status changes, and release actions happened in the correct order for a specific release window. This guide focuses on using the activity list as release evidence rather than as a general activity feed. You will prepare a filtered audit view, check milestone events, confirm who completed each action, and decide whether the release can move forward. You will also learn how to save the filtered results as evidence for reviewers and how to handle common gaps, such as missing approvals or edits that happened after sign-off. Use this guide when: - You are preparing a documentation export for review - You need to verify that approval happened before publication - You are collecting evidence for stakeholder sign-off - You need to pause a release because the timeline looks incomplete or out of order If you need help with broader export handling before this step, refer back to [Managing Audit Record Exports for Compliance](doc:managing-audit-record-exports-for-compliance). That guide covers export-focused checks, while this one concentrates on using the audit timeline to support release decisions. In practice, the strongest release check is a filtered audit view that clearly shows the right content, the right people, and the right sequence of events. When those three pieces line up, the release decision is easier to defend later. ## Prerequisites Before you use **Audit History** for release checks in Atloria, make sure you have access to the project or administrative area where audit activity is available. You should also know which release, document set, or publication window you are reviewing so you can apply the right filters and avoid checking unrelated activity. You will get the best results if you already have: - Access to the relevant **project workspace** or **admin workspace** - A defined **release window** or review period - The name of the **project**, **space**, or documentation area included in the release - A clear list of required release steps, such as approval, final status update, export, or publication - The names of the reviewers, approvers, or managers expected to appear in the activity list It also helps to have the release checklist or approval request open while you review the audit log. That way, you can compare each required checkpoint against the matching audit event without switching context. Before starting, confirm these practical details: - You know whether the release is tied to a project-level review or a broader administrative review - You understand which actions count as release evidence for your team - You are checking the correct time period and not an earlier release cycle - You are ready to open target items from the audit rows if something needs verification If your team has already exported audit-related records and you want to connect that work to a release decision, keep that material nearby while you review the timeline. The next step after this guide is [Reviewing Audit History and Exporting Compliance Records](doc:reviewing-audit-history-and-exporting-compliance-records), which builds on this release-check process. ## Opening Published Documentation and Understanding the Reading Layout When you open published documentation in Atloria, the reading view is built around two main areas: a **left sidebar** and a **main content pane**. The **left sidebar** shows the documentation structure as a list of pages and grouped sections. The **main content pane** shows the page you selected. At the top of the reading area, you will see the current **page title**, which confirms exactly what you are reading. This is different from simply browsing a documentation collection. When you are browsing, you are scanning the sidebar and deciding where to go next. When you are reading, one page is already open in the main content area, and the sidebar helps you understand where that page sits in the larger set of documentation. In Atloria’s published view, the page you are currently reading is visibly highlighted in the sidebar, so you can quickly see your position without guessing. Published documentation is a read-only experience for visitors. You are not editing page names, changing headings, or reorganizing sections here. Instead, you are moving through published content the way a reader would: opening pages, reading headings, and using the sidebar to continue to the next topic. To confirm where you are at any moment, look at these visible cues together: - The **highlighted page** in the left sidebar - The **page title** at the top of the content area - The **nearby pages and groups** around the selected item in the sidebar [SCREENSHOT: Published documentation page showing the left sidebar, highlighted current page, and page title in the main reading area] If you need a refresher on how readers move through the public structure before opening individual pages, see [Finding Content Through Public Documentation Structure](doc:finding-content-through-public-documentation-structure). ## Using the Sidebar to Move Between Pages The left sidebar is the fastest way to move through published documentation in Atloria. Instead of going back and forth with your browser controls, use the sidebar to jump directly to the page you want. This keeps your place inside the documentation set and makes it easier to compare related pages. Follow these steps to move between pages: 1. Open the published documentation and look at the **left sidebar**. 2. Scan the list of **section names** and **page titles** to find the topic you want. 3. If a section is already expanded, review the page titles listed underneath it. 4. Click the page title you want to read. 5. Wait for that page to load in the **main content pane**. 6. Check the **page title** at the top of the content area to confirm you opened the correct page. 7. Look back at the sidebar and note the **highlighted page**, which shows your current location. Expanded groups are especially useful when you want to stay within one topic area. For example, if you are reading a task page and then need background information or a related instruction, you can often find it in the same expanded section without returning to a separate landing page. This makes the reading flow smoother because related content stays visible while you move. The active page highlight is one of the most important reading cues in Atloria’s public documentation. If you click several pages in a row, the highlight updates each time, helping you keep track of where you are. When you are comparing instructions, this visual marker prevents confusion between similarly named pages. [SCREENSHOT: Sidebar with one section expanded and the current page highlighted] If the documentation includes audience-specific content, the reading experience may also depend on which pages are visible to you. For that topic, see [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content). ## Reading a Page with Full Document Context A single page makes more sense when you read it with its surrounding context. In Atloria, that context comes from three visible elements working together: the **page title**, the **headings inside the page**, and the **sidebar structure** around the selected page. When you use all three, you can understand not just what the page says, but why it appears where it does. Start with the **page title** at the top of the content area. This tells you the main topic of the page you opened. Then look down the page for section headings. These headings break the content into smaller parts, so you can scan the flow before reading every paragraph. If a page includes sections for setup, usage, or troubleshooting, those headings help you decide whether the page answers your question right away. Next, look back to the left sidebar. The pages above and below the selected page often reveal whether you are in an introductory section, a task sequence, or a more detailed reference section. For example, if the selected page sits between a general explanation and a more advanced topic, that placement gives you a strong clue about the page’s role in the documentation. Use this quick reading approach: 1. Read the **page title** first. 2. Scan the **section headings** in the main content area. 3. Check the **highlighted page** in the sidebar. 4. Review the **nearby page titles** above and below it. 5. Decide whether you should keep reading, open a related page, or move to an earlier topic. For documentation teams, clear page names and a logical sidebar order make this much easier for public readers. A reader who lands directly on one page should still be able to understand the surrounding topic by looking at the visible navigation. [SCREENSHOT: Open page with visible section headings and nearby related pages in the sidebar] ## Finding the Right Page Faster When you need an answer quickly, the goal is not to open every page one by one. In Atloria, you can usually narrow down the right page by reading the sidebar carefully before you click. Clear page titles, nearby related pages, and the page heading in the content area all help you confirm whether you are in the right place. Begin with the page titles in the **left sidebar**. Look for wording that matches your task as closely as possible. A title such as **Managing Project Settings and Website Options** gives a much clearer signal than a broad title that could cover many topics. If two pages seem similar, check the surrounding entries in the same section. Sibling pages often reveal the difference between setup instructions, overview content, and deeper reference material. Use this process to find pages faster: 1. Scan the **sidebar page titles** for the most specific match to your question. 2. Review the **nearby pages in the same section** to spot related topics. 3. Click the page that looks closest to what you need. 4. Read the **page heading** at the top of the main content area. 5. Scan the visible **section headings** on the page. 6. If the page is not the right fit, return to the **sidebar** and choose a nearby page instead of relying only on your browser’s Back button. This approach is especially helpful when several pages cover the same feature from different angles. The sidebar keeps the whole section visible, so you can compare titles quickly without losing your place in the documentation set. [SCREENSHOT: Reader comparing several related page titles in one sidebar section] If you are still deciding which published page to open first, see [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page). ## Helping Readers Navigate Published Documentation More Easily Documentation managers shape the reading experience long before a reader opens a page. In Atloria, the public reading view depends heavily on how pages are grouped in the sidebar, how page titles are written, and how headings are organized inside each page. When these elements are clear, readers spend less time guessing and more time finding answers. Use these practices to make published documentation easier to navigate: 1. Group related pages together in the **sidebar** so readers can stay within one topic area. 2. Use clear, descriptive **page titles** that make sense on their own in the navigation list. 3. Keep similar pages named in a consistent style so readers can compare them quickly. 4. Organize page content with clear **section headings** so the main content pane is easy to scan. 5. Place pages in a logical order, such as introductory pages first, task pages next, and detailed reference pages after that. Good sidebar grouping helps readers understand the structure at a glance. For example, a reader should be able to tell whether a section contains setup guidance, reading guidance, or advanced reference pages just by scanning the group and page names. Strong page titles reduce unnecessary clicks because readers can identify the right page before opening it. Inside the page itself, consistent headings matter just as much. Readers often decide within a few seconds whether to stay on a page. If the content is broken into clearly labeled sections, they can jump to the part they need without rereading the entire page. Logical ordering also improves movement between pages. When pages appear in a sensible sequence, readers can move from one topic to the next directly from the sidebar. [SCREENSHOT: Well-organized published documentation sidebar with clearly named page groups and pages] For broader guidance on shaping the public reading experience, see [Managing Reader Navigation in Published Documentation](doc:managing-reader-navigation-in-published-documentation). ## Common Navigation Problems and How to Resolve Them Even with a clear sidebar, readers can still lose context or open the wrong page. In Atloria, most navigation problems can be solved by checking the visible reading cues already on the screen: the **highlighted sidebar item**, the **page title**, the **section headings**, and the **nearby pages** in the same navigation group. If a page is open but you are not sure where it belongs, pause and look at the **highlighted page** in the left sidebar. Then read the page titles directly above and below it. This usually shows whether you are in the right section and what kind of content surrounds the page you opened. If the wrong page keeps opening, compare two things every time you click: - The **page title in the sidebar** before you select it - The **page heading** at the top of the content area after it loads This quick check helps when several pages have similar wording. If you finish a page and still need related information, do not leave the documentation set immediately. First, inspect the adjacent pages in the same sidebar section. Related instructions are often grouped together, and the next useful page may already be visible a few lines above or below the current one. If the documentation feels hard to browse overall, the issue is often structural rather than visual. Review whether the **sidebar group names** and **page titles** clearly describe what readers expect to find. If readers repeatedly open the wrong pages, the naming may be too broad or too similar. A simple troubleshooting pattern is: 1. Confirm the **highlighted page** in the sidebar. 2. Read the **page heading** in the main content area. 3. Compare the **nearby page titles** in the same section. 4. Open the closest related page from the sidebar. 5. Recheck the heading after each selection. [SCREENSHOT: Reader using the highlighted sidebar item and page heading to confirm location] ## Overview - In Atloria’s published documentation, readers mainly use two areas: the **left sidebar** for navigation and the **main content pane** for reading. - The **page title** at the top of the content area confirms which page is open. - The currently selected page is **highlighted in the sidebar**, making it easier to keep your place. - Readers use the published view in a **read-only** way. They open pages and move through the documentation, but they do not edit content from this view. - **Expanded sidebar groups** help readers move between related pages without returning to a separate index page. - **Section headings** inside a page make it easier to scan the content before reading in detail. - The pages above and below the current page in the sidebar provide useful **document context**, especially when you are trying to understand whether a page is introductory, task-based, or more detailed. - To find content faster, compare **descriptive page titles**, open the closest match, and confirm it using the **page heading** and visible structure in the main reading area. - If navigation feels confusing, use the combination of **highlighted sidebar item**, **page heading**, and **nearby page titles** to re-establish your location. This document focuses on reading and moving through already published content. If you need help understanding the public structure before selecting pages, refer back to [Finding Content Through Public Documentation Structure](doc:finding-content-through-public-documentation-structure). ## Prerequisites - You should be able to open a published documentation site in Atloria. - You should be familiar with basic public navigation concepts covered in [Finding Content Through Public Documentation Structure](doc:finding-content-through-public-documentation-structure). - You only need access to the published reading view; no editing access is required. - It helps to recognize these visible parts of the page: - **Left sidebar** - **Highlighted current page** - **Main content pane** - **Page title** - **Section headings** - If you are reading documentation that changes by audience, you may also want to review [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content). For the next step in this reading flow, continue to [Understanding Public Document Views and Version Context](doc:understanding-public-document-views-and-version-context). ## Preparing a Release Cycle for Version Generation Before you click **Generate Version**, open the release cycle you plan to use and review the details already attached to it. In Atloria, this step matters because the version you generate will follow the release cycle’s selected documentation scope and release identity. If the release cycle is missing key details, the version you create may be incomplete or tied to the wrong release. Start in the project’s documentation versions area and open the release cycle record you prepared earlier. If you need help organizing the release before this point, use [Coordinating Version Work Before Release](doc:coordinating-version-work-before-release). On the release cycle screen, confirm the product, project, or documentation set shown for that cycle matches the material you want to generate. Then check the release identifier or version label already associated with the cycle so you do not create output for the wrong release. Review the inputs that affect generation. Depending on what your team uses, make sure the release cycle points to the correct source content, branch, or saved content state. Also confirm the version label, default language, and any comparison baseline or review baseline linked to the cycle. If these details are visible on the release cycle or version setup area, verify them before you proceed rather than correcting them after a failed run. It also helps to scan the existing versions list for that release cycle. Look for duplicate names, older test runs, or a version entry that already uses the same release label. This avoids creating two nearly identical versions and sending reviewers to the wrong one. Check that you can see the version actions and results area. If you cannot access the release cycle details, generation action, or results view, you may need a Documentation Manager or Project Administrator to grant the right access. [SCREENSHOT: Release cycle page showing release identifier, source content details, language setting, and versions list] ## Creating a New Documentation Version 1. Open the release cycle you want to use, then go to the version management area on that screen. In Atloria, this is where you start a new output for the selected release. Click **Generate Version** to open the version creation form. 2. Fill in the version details carefully. Use the release-ready version name your team expects reviewers to see. Check the source content reference shown in the form and make sure it matches the content snapshot, branch, or selected source for this release cycle. If Atloria shows an output scope, choose the scope that matches what you want to generate for this release. If a publication target appears, review it before continuing so the generated version is tied to the correct destination. 3. Review the generation options before submitting. If Atloria gives you a choice between rebuilding everything and generating changed content only, select the option that fits your release. A full rebuild is usually the safer choice when the release includes broad structural changes, navigation updates, or language changes. A changed-content option is more suitable when you only need to refresh recent edits and want a faster run. 4. Submit the form by clicking the action button that confirms generation. After you submit, Atloria creates a new version entry in the versions list for that release cycle. Watch the initial status shown beside the new entry. It may appear as waiting, queued, or another early processing state before the actual build begins. Use the new version entry as your main tracking point from this stage onward. The version name, release label, and status shown there help you confirm that the correct release cycle is now being processed. | Field or option | What to check | Why it matters | |---|---|---| | Version name | Matches the release your team expects | Prevents confusion during review | | Source content reference | Points to the correct content state | Ensures the right material is generated | | Output scope | Includes the intended pages or sections | Avoids missing documentation | | Publication target | Matches the intended destination if shown | Keeps release output aligned | | Generation option | Full rebuild or changed content only | Affects speed and completeness | [SCREENSHOT: Generate Version form with version name, source content reference, scope, and generation options] ## Monitoring Generation Progress 1. After submitting the version, open its details page or stay in the release cycle activity area where Atloria shows processing updates. The status will usually move through early states before the final result appears. Keep an eye on the status text first, because that is the fastest way to tell whether the run is waiting, actively processing, or finished. 2. Check the timestamps shown for the run. If Atloria displays **Started**, **Completed**, or similar time markers, compare them with the current status. A version that has a recent start time and changing activity is still moving. A version with no new event for a long period may need closer attention. 3. Review any progress markers shown during build and validation. Some version screens show separate stages, such as generation, validation, or output preparation. These stage updates help you understand whether Atloria is still working through the run or whether it stopped before the final checks. 4. Refresh the page or reopen the results view when you expect new information. This is especially useful if you are waiting for build logs, warning messages, or downloadable output links to appear. If the latest event time changes and new messages appear, the run is still updating. When you are deciding whether a run is active or stalled, compare three things together: - The current status text - The elapsed time since the last visible event - Whether new logs or stage markers have appeared If the status still says it is processing but nothing has changed for an unusually long time, note the last event shown before deciding to retry. Do not assume a long run has failed if Atloria is still updating timestamps or adding new messages. [SCREENSHOT: Version details page showing status, started time, completed time, and generation activity] ## Reviewing Results Before Publication 1. Open the completed version entry and read the final status first. In Atloria, the result may show a successful completion, a completed run with warnings, or a failed run. Treat these outcomes differently. A successful result usually means you can move into review. A warning result means the version exists, but you still need to inspect what was excluded or flagged. A failed result means you should stop and fix the issue before handoff. 2. Review the output attached to the version. Look for preview content, generation logs, validation messages, and version details saved with the release cycle. These items tell you whether the generated version matches the release you intended to produce. 3. Check the structure of the generated documentation. Confirm that the navigation looks complete, the expected page count is present, language variants appear where needed, and linked assets such as related content or supporting files were included. If your team expects a specific set of documents for the release, compare the generated output against that expectation before sending it to reviewers. 4. Use the warnings and validation messages as a decision point. Missing pages, broken links, excluded assets, or incomplete language coverage may not block generation, but they can still make the version unsuitable for review or publication. A version is usually ready for reviewer handoff when: - The final status is successful, or warnings are minor and understood - The preview reflects the intended release content - Navigation and page coverage look complete - Language and asset coverage match the release plan - The version metadata matches the release cycle If anything important is missing, run another generation pass after corrections instead of asking reviewers to work from an incomplete build. [SCREENSHOT: Completed version results showing final status, preview link, validation messages, and metadata summary] ## Managing Regeneration and Version Updates 1. If you fix content, adjust release details, or correct version information after a run, return to the existing version entry or use the release cycle action menu to start generation again. In Atloria, regeneration is the quickest way to refresh output when the release itself has not changed, but the generated result needs to be updated. 2. Decide whether to reuse the current version entry or create a separate version record. Reuse the existing entry when you are correcting the same release candidate and want one clear record for the latest output. Create a separate version record when you need to preserve an earlier run for comparison, testing, or approval history, especially if the release label or source has meaningfully changed. 3. Before rerunning generation, update any version fields that no longer match the intended release. This may include the version label, source content reference, selected scope, or other release-linked information visible on the version or release cycle screen. Make these updates first so the next run reflects the correct release candidate. 4. After regeneration finishes, confirm that the newest result is the one attached to the review and publication workflow. Check the latest timestamp, final status, and visible output links. If Atloria shows multiple runs or multiple version entries, open the one with the most recent successful result before sending it forward. Use extra care when several similar version names appear in the same release cycle. Reviewers can easily open the wrong entry if an older run remains visible. A clear label and a quick check of the latest generation time help prevent that mistake. For comparing different outputs before deciding which one to keep, pair this step with [Working with Version Comparison Views](doc:working-with-version-comparison-views). [SCREENSHOT: Release cycle versions list with multiple runs, updated labels, and latest generation result highlighted] ## Fixing Common Version Generation Problems If a version does not generate as expected, start with the visible information on the release cycle, version form, and results screen. Atloria usually gives enough on-screen detail to narrow the problem before you ask someone else to investigate. - **Generation does not start** - Reopen the release cycle and confirm it is the correct one for this release. - Check the version form for missing required fields such as the version name, source content reference, or other visible release details. - Make sure you can see the generation action and results area. If those options are missing or unavailable, your access level may not allow version generation. - **Generation stays in progress too long** - Open the version details and look at the latest event or most recent activity line. - Compare the last update time with the current time. - Refresh the page and check whether the status, logs, or stage markers have changed. - If nothing updates and the run appears stuck, retry the generation from the version entry or release cycle actions. - **Build completes with warnings** - Read the validation output carefully. - Look for missing pages, unresolved links, excluded assets, or incomplete language output. - Decide whether the warnings are acceptable for internal review or whether you should correct the content and regenerate first. - **Build fails entirely** - Open the error details and generation log attached to the version. - Check whether the source content reference is valid and whether the release cycle details still match the intended output. - Review the version label and release data for mismatches that could cause the wrong content to be pulled into the run. When repeated failures affect the same release cycle, compare the current setup with a previously successful version in the same project. That often reveals a changed field or release detail that needs correction. [SCREENSHOT: Failed generation result with error details, warning messages, and retry action] ## Overview Generating documentation versions in Atloria is the step where a prepared release cycle becomes a reviewable documentation output. You begin from a release cycle, create a version entry with the correct release details, submit the generation request, and then follow the status until Atloria finishes building the result. From there, you review the output, decide whether warnings are acceptable, and either move the version forward or regenerate it after fixes. This workflow fits after your release planning and pre-release coordination work. If you have already organized the release content, confirmed ownership, and aligned the version timeline, generation becomes much more predictable. That earlier preparation is covered in [Coordinating Version Work Before Release](doc:coordinating-version-work-before-release). The screens that matter most in this process are: - The release cycle record - The versions list for that release cycle - The **Generate Version** form - The version details page - The generation results area with status, logs, and validation output As you work through generation, focus on three questions: - Is this version tied to the correct release cycle and release label? - Did Atloria generate the expected pages, languages, and linked assets? - Is the final result clean enough to send into review and publication steps? You do not need to solve every release decision during generation. The goal here is to produce the right version output and confirm it is accurate enough for the next stage. Once the version has been generated and checked, you can move on to status handling and release readiness decisions in [Coordinating Version Statuses and Release Readiness](doc:coordinating-version-statuses-and-release-readiness). ## Prerequisites Before generating a documentation version in Atloria, make sure the release cycle and project workspace are already prepared. This guide assumes you are not starting from a blank project and that the release has already been planned. You should have the following in place: - Access to the project’s documentation versions area - Permission to open release cycles and create or rerun versions - A release cycle that already identifies the intended release - The correct source content reference or saved content state for that release - A version label your team plans to use for review and release - The expected default language, if your project uses language-specific output - Enough familiarity with the project workspace to recognize the correct version entry and release record It is also helpful to confirm these items before you begin: - Existing version entries do not already use the same release label - The release cycle points to the correct documentation set or project content - Any review baseline or comparison baseline tied to the release is already selected - The team has finished the content changes intended for this release candidate If you still need to organize the project workspace or locate the right release area, see [Managing Project Version Workspaces](doc:managing-project-version-workspaces). If you need a broader refresher on how versions move through the release cycle, use [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle). Once these prerequisites are in place, you can generate a version with much less risk of duplicate labels, incomplete output, or review confusion. ## Opening enterprise analytics and understanding the reporting workspace In Atloria, open the main workspace after signing in and go to the **Admin** area. From there, select **Analytics** to open **Analytics & Insights**. This area is intended for organization-wide reporting, so it is typically used by Documentation Managers, Project Administrators, and other users who already have access to administrative screens. If you can open **Admin** but do not see **Analytics**, your account may not have permission to view enterprise reporting. In that case, use the project-level analytics view instead, or ask an administrator to confirm your access. For help with the broader admin area, see [Using the Admin Workspace](doc:using-the-admin-workspace). When the analytics workspace is available, the main items to look for are the controls that shape the report you are viewing. These usually include a **project selector** for choosing one project or several projects, a **date range** control for setting the reporting period, summary **metric cards** for top numbers, **trend charts** for changes over time, **comparison controls** for current versus previous periods, and **export** actions for sharing what you see. [SCREENSHOT: Enterprise Analytics workspace showing the project selector, date range filter, metric cards, charts, comparison controls, and export option] It helps to separate two views in your mind: - **Organization-level analytics** shows rolled-up activity across multiple documentation projects. - **Project-level analytics** focuses on one project’s documentation performance only. That difference matters when you interpret totals. A high page-view total in enterprise analytics may come from several strong projects rather than one standout documentation set. The reporting period also changes what every chart and total means. A shorter range usually highlights recent movement, while a longer range smooths out spikes and dips. If you switch from one period to another, expect the totals, averages, and trend lines to update together. If you need a refresher on using analytics to decide what to improve, see [Using Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements). ## Reviewing performance across projects Enterprise analytics is most useful when you compare projects in the same reporting session instead of reviewing them one by one. Start by opening the **project selector** and choosing the projects you want to review together. If Atloria shows an all-projects or cross-project view, use that first to understand the overall picture, then narrow the list to a smaller portfolio when you need to investigate a specific team, product line, or documentation program. The dashboard should center your review around a few core measures: - **Page views** to show overall traffic - **Unique visitors** to show how many distinct readers are coming in - **Search activity** to show how often users rely on search - **Engagement** to show whether readers stay with the content - **Project contribution** to show how much each project adds to enterprise totals When projects are listed in rows, sorting becomes one of the fastest ways to find patterns. Sort by traffic to find the most-visited documentation sets. Sort by engagement to spot projects where readers spend more time or return more often. Filter the list when you want to isolate a subset of projects instead of comparing everything at once. This is especially useful when one very large project would otherwise dominate the view. Side-by-side comparison is where the numbers become actionable. For example, one project may have much higher **page views** but weaker **engagement**. That usually points to content that attracts readers but does not hold attention or answer questions clearly. Another project may have lower traffic but stronger engagement and better search outcomes, which can indicate a smaller but more effective documentation set. [SCREENSHOT: Cross-project analytics table with sortable project rows and key metrics] Use these comparisons carefully. A project with a broad audience will naturally look different from a specialized internal project. The goal is not to force every project to match the same totals. Instead, compare each project’s traffic, search, and engagement together so you can tell whether the documentation is simply popular, genuinely useful, or both. ## Interpreting trends in traffic, engagement, and search behavior Trend charts in Atloria help you move beyond totals and understand what changed over time. Start by reading the line or bar pattern across the selected date range. A sharp spike often points to a release, announcement, onboarding event, or temporary surge in interest. Sustained growth is different: it suggests the documentation is becoming more useful or more widely adopted over several reporting periods. Seasonal dips may be normal if your audience follows predictable release cycles or business rhythms. A sudden drop after a content change or release deserves closer review, especially if it appears across several metrics at once. Use the **comparison** controls to place the current period next to the previous period. This is one of the best ways to avoid overreacting to a single high or low day. If the current period is only slightly different from the previous one, the change may be temporary. If the same direction appears across traffic, engagement, and search, the shift is more likely to be meaningful. Engagement indicators add context to traffic numbers. Look for patterns such as: - Longer **time on page**, which can suggest readers are working through the content - Higher **repeat visits**, which can show ongoing value - Bounce or exit patterns that may suggest users leave without finding what they need These signals are strongest when read together. High traffic with weak engagement often means readers arrive but do not stay. Lower traffic with strong repeat visits can still represent healthy documentation for a focused audience. Search analytics is especially useful for finding content gaps. Watch for: - High-volume search terms that deserve stronger coverage - Low-result searches that suggest missing or hard-to-find content - Searches that do not lead to engagement, which can mean the results are not relevant [SCREENSHOT: Trend chart with current period and previous period comparison, plus search analytics panel] When a search term appears often but readers do not continue into useful pages, treat that as a signal to review page titles, navigation, and the depth of the related content. ## Using analytics to guide program decisions A practical enterprise analytics workflow in Atloria starts with scope. First, set the **date range** so everyone is looking at the same reporting period. Then choose whether you need the full enterprise view, a smaller group of projects, or one project that needs closer attention. Once the scope is set, look for the metric that changed the most. That might be a rise in page views, a drop in engagement, or a jump in search activity. From there, connect the signal to a documentation action: 1. Select the reporting period and confirm the projects included in the view. 2. Identify the metric with the clearest change. 3. Open the related project or project group in a narrower view. 4. Review whether the change appears in traffic, engagement, search, or a combination. 5. Decide on the content action that best matches the pattern. A few common examples make this easier to apply: - If a page or project has **high traffic but low engagement**, review the content structure, page clarity, and whether the page matches reader intent. - If **search volume** is rising around a topic, expand coverage for that subject and make sure the related pages are easy to find. - If a project shows **declining adoption**, review recent releases, onboarding materials, and whether the documentation still reflects the current product experience. Documentation Managers can use enterprise totals and project comparisons to guide staffing and maintenance work. A project contributing heavily to enterprise traffic may need more editorial attention than a low-traffic project with stable performance. Project Administrators can use project-specific trends to check whether a release improved documentation usage, whether onboarding content is being used, or whether support-related content is reducing repeated questions. If you already use analytics to rank improvement opportunities, build on that process here rather than starting over. The difference in enterprise analytics is scale: you are deciding not only what to improve, but where to invest effort across several documentation programs. ## Sharing reports and aligning stakeholders on analytics findings When you are ready to share findings from enterprise analytics, keep the report view stable before you export or capture it. In Atloria, that means preserving the same **selected projects**, **date range**, and **comparison period** that you used during analysis. If those filters change between review sessions, stakeholders may think the numbers shifted when the view itself actually changed. Useful sharing actions typically include: - Exporting the dashboard data for offline review - Capturing the current filtered view as a reporting snapshot - Preparing one version for enterprise-wide reporting and another for project-specific discussion [SCREENSHOT: Analytics view prepared for sharing with filters visible at the top] The most important habit is to share the context with the numbers. A leadership review usually needs rolled-up metrics such as enterprise traffic, project contribution, and broad trend direction. Project owners usually need a narrower view that shows how their documentation compares with the previous period and where search or engagement changed. Documentation teams often need the most detailed view, especially when they are deciding which pages, topics, or search gaps to address next. A lightweight reporting cadence works well for most teams: - **Monthly reviews** for active documentation programs, release-heavy teams, or fast-changing support content - **Quarterly reviews** for broader program health, staffing discussions, and roadmap planning Use the same analytics views each time so trends stay comparable. If one month’s report uses all projects and the next uses only a subset, the change in scope can hide the real story. For administrative reporting that sits alongside analytics, see [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). When you present findings, separate observation from recommendation. For example, show that one project gained traffic but lost engagement, then recommend a content review for the most-visited pages. That keeps stakeholders aligned on both the evidence and the next decision. ## Resolving misleading analytics patterns and reporting issues If analytics numbers in Atloria look inconsistent, start by checking the report scope before drawing conclusions. Totals often change for valid reasons when you adjust the **date range**, switch the **project filter**, or turn the **comparison period** on or off. A 30-day view and a 90-day view should not be expected to match, and a single-project view will naturally differ from an enterprise-wide total. When a project appears to have missing data, unusually low traffic, or no visible trend line, review the basics first: - Confirm the correct project is selected in the **project selector** - Check whether the **date range** is too narrow to show meaningful activity - Make sure you are in the enterprise view when expecting cross-project totals - Narrow the view to the single project to see whether its data becomes easier to read A flat or nearly invisible trend line does not always mean something is broken. It can simply mean the project has low activity during the selected period. Expanding the date range often makes the pattern easier to interpret. Search metrics can also be misleading if you do not account for audience size. A small project may show very few searches, while a large public documentation set may generate many more. That does not automatically mean the smaller project is underperforming. Also watch for low-result queries in very short date windows. A handful of searches over a few days can look dramatic without representing a lasting issue. Before acting on reported increases or declines, verify that everyone is reviewing the same filtered view. Ask stakeholders to confirm: - The same selected projects - The same date range - The same comparison period - The same enterprise or project scope [SCREENSHOT: Analytics filters highlighted for validation before sharing] This simple check prevents many reporting disputes. If the numbers still seem unclear after confirming the filters, compare the enterprise view with the matching project-level view to see whether the pattern holds at both levels. ## Overview This guide focuses on the **Analytics & Insights** area in Atloria’s **Admin** workspace and explains how to use it for documentation program decisions across multiple projects. The emphasis is on enterprise reporting rather than single-project review. You use this workspace when you need to understand how documentation is performing across the organization, compare projects in one place, and decide where to focus content work, maintenance effort, and reporting attention. The main parts of the workflow are: - Opening **Admin** and selecting **Analytics** - Setting the right **date range** - Choosing projects in the **project selector** - Reviewing summary metrics and trend charts - Comparing current and previous periods - Sharing the filtered view through export or reporting snapshots This document builds on the prioritization approach covered in [Using Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements). Here, the scope is wider: instead of deciding what to improve inside one documentation area, you are comparing documentation programs across projects and using enterprise totals to support broader planning. Use this guide when you need to answer questions such as: - Which projects contribute most to overall documentation traffic? - Which documentation sets are losing engagement? - Are users searching for topics that are not well covered? - Which projects need more maintenance or stronger release documentation? - How should analytics be shared with leadership, project owners, or documentation teams? Because Atloria also provides project-level analytics, it is important to know which view you are in before interpreting results. Enterprise analytics gives you the rolled-up picture. Project analytics gives you the local detail. The most useful reporting practice is to move between those views deliberately rather than treating them as interchangeable. ## Prerequisites Before using enterprise analytics in Atloria, make sure the following are true: - You can sign in to Atloria and reach the main authenticated workspace - Your account can open the **Admin** area - You can see or access **Analytics** from the admin navigation - The projects you want to review already exist in Atloria - You know whether you need an enterprise-wide view, a selected group of projects, or one project only It also helps to be familiar with a few related areas before you begin: - The **Admin** workspace, especially if you are responsible for organization-wide reporting - Project navigation, so you can move from enterprise findings into a specific project when needed - Basic analytics review, particularly how you already prioritize content improvements from traffic, engagement, and search signals If you need help with account access, start with [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If you need a refresher on the admin area, see [Using the Admin Workspace](doc:using-the-admin-workspace). If your next step after enterprise review is to compare projects more directly, continue with [Comparing Project Performance in Enterprise Analytics](doc:comparing-project-performance-in-enterprise-analytics). ## Working in the visible document workspace In Atloria, most page work happens inside the project’s documentation workspace. This is the area where you move between the page list, open a page for editing, and check how that page fits into the rest of the documentation set. If you already worked through [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content), this screen will feel familiar, but here the focus is on moving content from working draft to release-ready page. The workspace is typically divided into three practical areas: - A **page tree** or sidebar where sections and pages are listed in their current structure - A **main editing area** where you write and revise page content - **Page actions** around the editor for saving, previewing, and preparing content for release [SCREENSHOT: Documentation workspace showing the page tree on the left and the editor open for a selected page] Writers usually move through a visible content lifecycle in this workspace: - **Draft page**: a page you are still building or revising - **Saved changes**: edits that are stored in Atloria but not yet part of a released documentation version - **Preview-ready page**: a saved page you can review in reader format - **Release-ready content**: pages that are organized, checked, and selected for an upcoming version Documentation Managers and Technical Writers often use the same screens in different ways. A Technical Writer usually spends more time in the editor, updating titles, headings, body text, and page flow. A Documentation Manager is more likely to review the page tree, confirm section placement, check whether drafts are complete, and decide which pages should move forward into a versioned release. Even when roles differ, both people rely on the same visible cues: page titles in the tree, the selected page in the editor, save status, and preview or release actions tied to that page. ## Creating new pages and building the initial draft When you need to add content, start in the project’s documentation workspace and look for the **New Page** option or the add-page control near the current section in the page tree. Creating the page from the correct part of the tree helps you avoid moving it later. 1. In the page tree, select the section where the new page should live. 2. Click **New Page** or the add-page control for that section. 3. Enter the **page title**. 4. Add the first draft of the page body in the editor. 5. Save the page so it becomes a stored draft in Atloria. [SCREENSHOT: New page action opened from a section in the page tree] A new page usually starts as working content rather than something readers can immediately see in published documentation. That gives you room to shape the page before it appears in a release. The most important first decisions are the page title, the opening structure, and the page’s location in the hierarchy. If you place a page under the wrong parent section, it can be harder for reviewers to understand where it belongs. As you type, pay attention to whether the workspace shows unsaved edits or a saved draft state. Unsaved edits are changes still sitting in the editor and not yet stored. A saved draft means Atloria has recorded the page, but it is still part of your internal work rather than a released version. If you leave the page before saving, those latest edits may not appear in preview or release preparation. A practical way to build the first draft is to save early once the title and basic outline are in place. After that, continue adding headings, paragraphs, links, and supporting content in smaller passes. This makes it easier for teammates to open the page, review the draft, and understand its purpose even before the content is complete. ## Editing page content and reviewing changes before release To revise an existing page, open it from the page tree or page list in the documentation workspace. Once selected, the page loads in the main editor so you can update the content without affecting the released documentation right away. 1. Select the page you want to revise from the page tree. 2. Update the **title**, body content, and any page details shown in the editing panel. 3. Click **Save** to keep your changes as draft updates. 4. Open **Preview** to check how the page will look to readers. 5. Review the draft against the current published version before marking it ready for release. [SCREENSHOT: Existing page opened in the editor with Save and Preview actions visible] This draft-first workflow is useful because it separates editing from publishing. You can rewrite headings, fix wording, adjust links, and improve structure while the current released version remains unchanged. For teams working on active documentation, that means you can keep improving a page over several editing sessions without exposing half-finished work. When you preview the page, focus on the reader experience rather than the writing interface. Check that: - Headings appear in the right order - Paragraph spacing is readable - Links point to the correct pages - Embedded content appears as expected - The page title matches the topic and navigation label If your team uses published pages as the benchmark, compare the draft with the currently available version before release. This is especially useful when a page already exists publicly and you are making an update rather than creating something new. Look for changes that affect meaning, navigation, or page completeness. A page may be well written in the editor but still not be release-ready if the preview shows broken formatting, missing sections, or a title that no longer fits the surrounding structure. ## Organizing pages in the project structure A strong page structure makes Atloria easier to browse for both your team and your readers. The page tree is where you control that structure. It determines how sections appear in navigation, which pages are grouped together, and what order readers see when they move through the documentation. 1. Open the page tree in the documentation workspace. 2. Drag a page to a new position to change its order within the current section. 3. Move a page under a different parent section if the topic belongs elsewhere. 4. Create parent and child relationships so related pages stay grouped together. 5. Review the updated tree to confirm labels and order still make sense. [SCREENSHOT: Page tree with nested parent and child pages being reorganized] Reordering pages is not just cosmetic. The order in the tree often becomes the order readers follow in the published sidebar. If setup instructions appear after advanced troubleshooting, or a reference page sits above a beginner guide, the documentation can feel confusing even when each page is well written. Nested structure is especially helpful for longer documentation sets. A parent page can introduce a topic, while child pages cover detailed tasks, examples, or related reference material. This keeps the sidebar cleaner and helps readers understand which pages belong together. When moving pages, watch for these effects: - **Navigation labels**: readers will see page titles as part of the structure - **Page order**: the tree order influences how sections are presented - **Topic grouping**: moving a page can change how discoverable it is - **Section depth**: too many nested levels can make browsing harder Documentation Managers often use the structure view to keep the full documentation set consistent, while Technical Writers may reorganize only the pages they are actively drafting. Both should review the tree after changes to make sure the new placement supports how readers actually search for information. ## Preparing content for a versioned release Once draft pages are written, saved, and organized, the next step is deciding what belongs in the upcoming documentation version. In Atloria, this is where page editing shifts into release preparation. The goal is not just to have good content, but to make sure the right pages are included in the right version. 1. Review draft pages and recently edited pages in the project workspace. 2. Confirm each page’s **title**, placement in the page tree, and preview output. 3. Use the version or release preparation workflow to include approved pages in the target version. 4. Leave unfinished pages in draft if they should not ship yet. 5. Verify which pages are part of the versioned release set before final handoff. [SCREENSHOT: Version preparation view showing selected pages ready for release] Before you include a page in a release, check three things carefully: - The **page title** is final and reader-friendly - The **hierarchy placement** is correct in the page tree - The **preview** matches what you expect readers to see This step matters because versioned documentation is usually treated as a stable snapshot. If a page is still being debated, missing sections, or sitting in the wrong part of the tree, it is often better to keep it as draft-only until the next release cycle. That helps avoid publishing content that is technically saved but not truly ready. Documentation Managers typically make the final inclusion decision, especially when multiple writers are contributing pages across the same project. Technical Writers usually support that process by making sure their assigned pages are saved, previewed, and clearly placed in the structure before review begins. If your team also works with broader version workflows, release approvals, or comparison screens, continue with the related version guidance in [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle). For page-level readiness, the key question is simple: should this page stay as an internal draft, or should it become part of the next published version? ## Fixing common issues with drafts, previews, and page organization Most content problems in Atloria come down to one of four things: the page was saved in the wrong place, changes were not saved before preview, the page was not included in the version workflow, or the navigation tree was reorganized incorrectly. When something looks wrong, start with the visible workspace cues rather than rewriting the page from scratch. If a **new page does not appear where you expect**, check these points: - The page was created under the correct parent section - You clicked **Save** after creating it - You are viewing the right part of the page tree - Any current workspace filter is not hiding it If the **preview does not match the editor**, the most common cause is unsaved work. Save the page first, then open **Preview** again. If the difference remains, review the formatting in the editor. Headings, links, and embedded items may display differently once Atloria renders the saved page. If a **page is missing from the release**, confirm that it was actually included during version preparation. A saved draft is not automatically part of a released documentation version. Pages left in draft-only status will stay internal even if they look complete in the editor. If the **navigation order looks wrong after reorganizing pages**, reopen the page tree and inspect the exact placement. A page may have been dropped above or below the intended section, or nested under the wrong parent page. [SCREENSHOT: Page tree showing a misplaced child page under the wrong parent section] A quick troubleshooting routine usually helps: - Reopen the page from the tree - Confirm the title and parent section - Save again if needed - Preview the saved version - Recheck release inclusion if the page should ship For larger release issues, it can also help to compare your page set with the version workspace your team is using for final review. ## Overview This guide focuses on the everyday page management work that happens between writing and release in Atloria. You use the documentation workspace to create draft pages, revise existing content, organize the page tree, preview reader-facing output, and decide which pages should move into a versioned release. The main ideas to keep in mind are: - **Drafts are working pages** that can be saved without being released - **Saved changes** protect your work and make previews more reliable - **The page tree controls structure** and strongly affects navigation - **Preview helps you review the reader experience** - **Version preparation decides what actually ships** This guide does not repeat the content planning and review habits covered in [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content). Instead, it picks up from that point and shows how to manage the visible page workflow inside the project workspace. Use this document when you need to answer questions like: - Where should I create a new page? - Why is my page still only a draft? - How do I check what readers will see? - Why is the page order wrong in navigation? - Which pages are going into the next release? If you are a Technical Writer, the most common actions will be creating pages, editing content, saving drafts, and checking previews. If you are a Documentation Manager, you will likely spend more time reviewing the page tree, confirming release readiness, and deciding which pages remain draft-only until a later version. The next step after page-level drafting and release preparation is shaping how readers move through the documentation as a whole in [Managing Project Content Structure and Navigation](doc:managing-project-content-structure-and-navigation). ## Prerequisites Before you work through draft and release preparation tasks in Atloria, make sure you already have the basic access and project context needed to open the documentation workspace and edit pages. You should have: - An Atloria account you can sign in with - Access to the relevant project workspace - Permission to create or edit documentation pages in that project - A project that already contains documentation content or a section where new pages can be added - Familiarity with the page editing basics from [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) - Familiarity with content review and organization concepts from [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content) It also helps if you already know: - Which section of the page tree your new content belongs in - Whether the page is meant to stay internal for now or be prepared for the next version - Who on your team makes final release decisions for documentation versions - Whether you are updating an existing published page or creating a brand-new one If you are entering Atloria for the first time, start with account and sign-in guidance such as [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If your work includes version handoff and release decisions beyond page editing, you may also want the broader version workflow references nearby, especially [Managing Project Version Workspaces](doc:managing-project-version-workspaces) and [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle). ## Understanding the version generation workflow In Atloria, version generation starts from the project area where you manage documentation versions. Open your project, go to the version management screen, and use the **Versions** list to find the version you want to work with. Each version appears as its own row, and that row is where you can usually tell whether the version is only created as a record or whether generated output already exists. If a **Generate**, **Build**, or similar action is available for the version, that means the version can be processed into usable output. It helps to separate two ideas: creating a version and generating a version. A version record is the entry that identifies the release you want to manage. It may appear in the **Versions** list with its name, status, and timestamps even before any output has been produced. Generation is the step that creates the actual result you can review, compare, publish, or move forward in the release process. If a version exists but has no generated output, you may see that it has no current build result, no output link, or no recent completion status. Once you start generation, Atloria tracks that work as a job. The job usually moves through a clear lifecycle: - **Queued**: the job has been submitted and is waiting to start - **Running** or **In Progress**: Atloria is actively generating the version - **Completed**: the output finished successfully - **Failed**: the job stopped because of a problem You can usually see this state in the version row itself, and in some cases in a job details panel or history view. After the build finishes, watch for clear result indicators such as: - a success badge or completed label - a failed badge or error message - a **Completed at** timestamp - a preview, output, or result link - a logs or details link for reviewing what happened If you need help deciding whether a finished result is good enough for release review, use [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions) alongside the job status details. ## Starting a new version build 1. Open the project that contains the documentation version you want to generate. From the project workspace, go to the version management area and open the **Versions** list. 2. Find the version you want to build. Check the row for its current status so you do not accidentally rebuild the wrong entry. This is especially important when several versions have similar names or were created close together. 3. Select the version and click the available build action. Depending on what your Atloria workspace shows, this may appear as **Generate Version**, **Start Build**, **Generate**, or a similar action attached to that version row or details view. 4. Review any confirmation window that appears. Pay attention to the selected version identifier and any output target shown in the dialog. If Atloria displays a summary before submission, confirm that you are building the correct version and not an older draft. 5. Click the confirmation button to submit the job. Right after submission, the screen should change to show that the build has started. In most cases, you will see one of these signs: - the version status changes to **Queued** - the version row changes to **In Progress** or **Running** - a new job entry appears in the job list or activity area - the build action becomes temporarily unavailable while the job is active 6. Stay on the version screen for a moment and make sure the new state appears. If the row still looks unchanged, refresh the page once and check again. You want to confirm that Atloria accepted the request before moving on. [SCREENSHOT: Versions list showing one version row changing from ready to queued after clicking Generate Version] If you are already managing multiple version runs at once, it is useful to compare the new job with earlier attempts in the same version history. That makes it easier to tell whether you started a fresh run or are still looking at an older result. ## Watching build progress in real time 1. After starting the build, stay on the version screen and watch the status area for changes. Atloria may show the current state directly in the version row, in a side panel, or in a job details view. The most common states to watch are **Queued**, **Running**, and **Completed**. 2. If a progress area or activity feed is available, open it to follow the build as it moves forward. This is where you can tell whether the job is still waiting in line or actively processing the version output. 3. Check the timestamps shown with the job. These are often the quickest way to tell whether the build is moving normally: - **Started at** tells you when processing began - **Updated at** helps you see whether activity is still happening - **Completed at** confirms the run has finished 4. Open the job details or logs panel when you need more than the status badge. If Atloria exposes build stages, you may see the version move through steps such as content collection, rendering, packaging, and publication. Even if the screen does not show every stage, the details view can still help you tell whether the job is advancing or has stopped at one point. 5. Watch how the page updates. Some Atloria screens refresh status automatically, while others may need a manual reload before the latest state appears in the list. If the **Updated at** time is not changing and the badge still looks old, refresh the page or reopen the version details to load the newest information. [SCREENSHOT: Job details panel with status badge, timestamps, and log entries] A job that is healthy usually shows movement: the status changes, the **Updated at** value advances, or new detail lines appear in the logs. If none of those change for an extended period, treat the run as possibly stalled and review the job details before starting another build. ## Interpreting completed, failed, and partial results When a version build succeeds in Atloria, the result is usually easy to spot. The version row or job details view shows a **Completed** status, a success-style badge, or a finished timestamp such as **Completed at**. You should also expect to see some sign that output is available, such as a preview link, generated result link, published indicator, or another action that lets you open what was produced. A successful job is not just one that stopped running; it is one that finished and left behind usable output for review. A failed result looks different. Instead of a completion badge, the job list or details panel shows a failure state such as **Failed**, an error label, or a visible failure message. In many cases, the output link is missing because Atloria did not finish creating the version result. If you open the job details, look for the point where progress stopped. That is often more useful than the top-level failure badge because it tells you whether the problem happened early or near the end of the run. You may also run into results that are neither fully successful nor fully usable. For example, a job may finish but still leave you with outdated output, warnings, or only part of the expected result. In the interface, this often shows up as a completed job without the links or labels you expected for the latest run. If the version appears finished but the generated files, preview action, or release-ready indicators are missing, treat it as incomplete until you confirm the output. To make sense of repeated runs, compare the job history carefully. Focus on: - the most recent timestamp - the newest status badge - whether the latest run has output links - whether older runs show different results The latest job result matters most. A version may have an older successful run and a newer failed run, or the other way around. Always match the status to the newest timestamp before deciding what to do next. ## Responding to generation outcomes 1. When a build finishes successfully, open the result from the available preview, output, or generated version link. Confirm that the version you built is the one now available and that you are not viewing an older run by mistake. Check the version label and the latest completion time before you continue. 2. Review the generated output in the project workspace. At this stage, you are confirming that Atloria produced something usable, not just that the status says **Completed**. If the version is part of a release decision, compare what you see here with your expected changes and with any earlier comparison work you already completed. 3. If the build fails, open the job details or logs panel right away. Look for the stage where the run stopped and note whether the same point appears in earlier failed attempts. This helps you decide whether the issue is temporary or tied to the version content or setup. 4. Use **Retry**, **Regenerate**, or **Run Again** when that action is available and you want Atloria to attempt the build again. A retry should create a new job entry instead of replacing the previous one, so you can compare attempts side by side. That history is useful when you need to see whether the same failure keeps happening. 5. If the result looks outdated, return to the **Versions** list and verify that you selected the correct version before you started the build. It is easy to launch a run for an older version with a similar name. Once you confirm the correct version, start a fresh build so the latest documentation changes are included. 6. After you have a stable result, move toward release preparation rather than repeating the same monitoring steps. The next stage is covered in [Creating Release Ready Documentation Versions](doc:creating-release-ready-documentation-versions). [SCREENSHOT: Completed version row with preview link and a separate earlier failed job in history] ## Fixing common version generation problems A few build problems show up often in Atloria, and you can usually narrow them down from the version list and job details without leaving the project workspace. - **The build stays in queued status for too long** First, check whether another version generation job is already running. If Atloria is processing one job at a time, your version may simply be waiting its turn. Look at the job list, activity area, or other version rows to see whether a different run is active. If nothing appears to be moving, refresh the page and confirm that the queue is still updating. - **The build shows completed but no output is available** A completed badge by itself is not enough. Open the latest job result and confirm that the output link, generated files section, or preview action exists for that same run. If the version row says **Completed** but there is no result to open, compare the latest timestamp with older jobs to make sure you are not looking at a leftover success from a previous attempt. - **The build fails every time you retry** Compare the messages in the logs across multiple attempts. If the same stage fails each time, the issue is likely tied to that version rather than a one-time interruption. Repeated failures with the same message usually point to a version-specific problem, while different messages across attempts may suggest a broader configuration or timing issue. - **The version list status does not match the latest job result** Refresh the page or reopen the job details view. Sometimes the list view lags behind the latest run, especially after a retry. Always trust the newest timestamp in the detailed job view over an older badge that may still be showing in the list. [SCREENSHOT: Version history showing multiple retries with timestamps and different statuses] If you are managing several versions at once, keep your troubleshooting focused on one version row and its newest job history. That prevents confusion between an older successful run and a newer failed one. ## Overview This guide focuses on the day-to-day monitoring work that happens after you start a version generation job in Atloria. The main screen you will use is the project’s **Versions** area, where each version row shows whether output exists, whether a build is waiting or running, and whether the latest attempt finished successfully. From there, you can open job details, review timestamps, and decide whether the version is ready for review or needs another run. The most important idea is that a version entry and a generated result are not the same thing. You can have a version listed in Atloria with no usable output yet. That is why this guide keeps returning to visible result markers such as **Queued**, **Running**, **Completed**, **Failed**, completion timestamps, and output or preview links. Those are the signals that tell you whether the version is only recorded in the list or has actually been generated. This guide does not repeat the comparison work covered in [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). Instead, it picks up after that stage and shows you how to monitor active jobs, read the latest result correctly, and respond when a run succeeds, stalls, or fails. If you are handling multiple attempts for the same version, the job history and timestamps become especially important because Atloria keeps each run as a separate result rather than replacing the older one. Use this page when you need to answer practical questions such as: Did the build actually start? Is it still moving? Which run is the newest one? Is there output to open? Should I retry this version or move it forward? ## Prerequisites Before you follow the steps in this guide, make sure you have the basics in place inside Atloria: - You can sign in and open the project workspace that contains the documentation version you want to monitor. - The project already has at least one entry in the **Versions** list. - You have access to the version management area where build actions such as **Generate Version**, **Start Build**, **Retry**, or **Run Again** are available. - You can open the version row, job details view, or logs panel for recent generation attempts. - You already understand how to compare version output and review release differences. If you need that earlier step, use [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). It also helps to know what you are trying to confirm before you start watching a build. For example: - whether you are building a brand-new version - whether you are rerunning a failed attempt - whether you are checking that recent content changes are included - whether you need a finished result for release review If several people work in the same project, take a moment to confirm which version should be built and whether another generation job is already running. That small check can save time when the **Versions** list contains multiple similar entries. You do not need to know any behind-the-scenes processing details to use this guide. Everything here is based on what you can see directly in Atloria: version rows, status badges, timestamps, result links, retry actions, and job details. Once those are familiar, you can move on to preparing the finished version for release in [Creating Release Ready Documentation Versions](doc:creating-release-ready-documentation-versions). ## Checking which version you are preparing to share Before you change any sharing or visibility setting in Atloria, start in the project’s **Versions** list and open the exact version you plan to release. This is especially important if your team keeps several versions in progress at the same time, such as a current public release, a review copy, and a draft for upcoming changes. When the version opens, confirm the identifying details shown on the version screen: - **Version name** - **Status** badge - **Last updated** details - Any visible release or revision label tied to that version These details help you avoid sharing the wrong entry. If the version still shows a draft-style status or appears to be an internal working copy, stop before changing access. A version that is still being edited can expose unfinished page content, incomplete navigation, or notes intended only for your team. Next, review the version content itself. Open the pages included in that version and make sure the material you expect readers to see is already there. Check that recent edits, screenshots, attachments, and other published changes are included. If your team has already worked through release checks in [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness), use that as your reference point rather than repeating those checks here. It also helps to confirm who is still working in the version. If Atloria shows editing access separately from viewing or sharing access, make sure you are not opening a version that is still reserved for internal updates. The safest approach is to share only the version whose name, status, and update details clearly match the release you intend external readers to open. [SCREENSHOT: Versions list showing version name, status badge, and last updated details] ## Choosing the right access mode for readers In Atloria, the version’s **Visibility**, **Access**, or **Sharing** settings determine who can open the version after you send a link or make it available outside your team. Before you switch anything on, compare the available access choices shown on the version screen. A typical decision looks like this: | Access mode | What it means for readers | Best used when | |---|---|---| | **Internal** | Only people with the right workspace access can open the version | Team review, editor collaboration, internal sign-off | | **Restricted** | The version is shareable, but readers may still need permission or sign-in access | Controlled customer review or limited external sharing | | **Public** | The version is available to external readers without internal workspace access | Published documentation meant for broad distribution | If Atloria offers a **Share link**, pay attention to whether that link is simply a direct shortcut or whether it still respects sign-in requirements. A copied link does not always mean open public access. In a restricted setup, readers may still land on a sign-in screen or an access message if they are not allowed to view that version. When you mark a version **Public**, treat that as a deliberate publishing decision. Depending on the project setup, the version may appear through a public documentation address or become available through a direct public link. If your team needs to control exposure carefully, verify the exact reader outcome in preview before distributing the link. Also remember that project-level permissions and version-level visibility can work together. A **Project Administrator** may have broader control over who can access the project overall, while a documentation lead may only be adjusting the visibility of one version. If a visibility option does not behave as expected, check whether the project’s broader access rules are affecting the version you are preparing. ## Making a version publicly accessible or shareable Once you have confirmed the correct version, open its **Settings**, **Visibility**, or **Sharing** area in Atloria. This is where you change how readers can access the version and where you usually find the controls for copying or managing a share link. 1. Open the version you want to release from the **Versions** list. 2. Select the version’s **Sharing**, **Access**, or **Visibility** controls. 3. Change the access mode from **Private** or **Internal** to the sharing state you want, such as **Restricted** or **Public**. 4. Click **Save**, **Update**, or the matching confirmation button so Atloria applies the new access setting. 5. Return to the sharing panel and copy the available **Share link** if you plan to send readers directly to that version. After you save the change, stay on the version screen long enough to confirm the new state is actually shown. You should see the updated visibility reflected in the version details or sharing panel. If Atloria provides link controls, review the options carefully. Some versions may allow you to: - **Copy** the current share link - **Disable** a link that should no longer work - **Regenerate** the link if the old one was distributed too widely - Review whether the link remains active for future readers If your handoff includes an export as well as a share link, do not generate the export too early. First confirm that the version is in the correct access state and that the visible content matches what readers should receive. That way, the downloaded file reflects the same release you are sharing in the browser. [SCREENSHOT: Version sharing panel with visibility selector and share link controls] ## Reviewing what external readers will actually see After changing access, switch from editor thinking to reader thinking. In Atloria, the safest way to do that is to use the version’s **Preview**, **Reader view**, or **Open shared link** action if it is available. This lets you inspect the version outside the editing workspace and catch issues before anyone else sees them. 1. Open the version’s **Preview** or **Reader view**. 2. If a **Share link** is available, open that link in a separate browser tab. 3. Review the version page by page as if you were an external reader. 4. Check the same link in a signed-out or private browsing window. 5. Confirm that the access result matches the sharing mode you selected. As you review, focus on what readers actually experience: - **Page titles** should be correct and easy to scan - **Navigation** should show the expected sections in the right order - **Images, screenshots, and embedded media** should load properly - **Attachments** should appear where expected - **Callouts and highlighted content blocks** should display cleanly Just as important, confirm what readers should **not** see. Look for internal notes, draft labels, editor-only reminders, or unfinished sections that may still be present in the version. If the version was moved from internal review to public access too quickly, these details can slip through. Testing in an incognito or signed-out browser window is one of the most useful checks because it shows the real outcome of the selected access mode. If the version is public, it should open as expected. If it is restricted, you should see the same sign-in or permission requirement that an outside reader would see. This is the fastest way to verify whether your sharing choice matches the intended audience. [SCREENSHOT: Public or shared reader view of a documentation version] ## Confirming the version is ready for export and distribution Before you send a link or export file to customers, stakeholders, or other external readers, run one final readiness check in Atloria. This step ties together the version’s visibility, reader experience, and release approval so you know the distributed copy matches the intended publication state. Use a simple checklist based on the version screen and shared view: - The correct **version name** is selected - The **status** reflects a share-ready or release-ready state - The chosen **visibility** or **access mode** is saved - The **share link** opens with the expected reader outcome - The **preview** matches the content you want to distribute - Final content approval has already been completed by the right team members If you are also exporting the version, compare the exported output with the browser preview. The headings, screenshots, attachments, and version-specific content should match what you just reviewed in the shared reader view. If they do not match, stop and regenerate the export only after the version has been finalized. It is also worth checking whether the version label, publication date, or revision identifier is visible where readers will notice it. These details help recipients confirm they are looking at the correct release, especially when several versions may still circulate internally. For team coordination, record who approved the release and where future corrections should be made if something needs to change after sharing. In practice, that usually means noting the approved version in your team’s release workflow and making sure any follow-up edits happen in the correct version rather than in a newer draft. If you need a deeper review of reader outcomes after access is set, continue with [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes). ## Fixing common sharing and visibility problems Most sharing problems in Atloria come from a mismatch between the version you intended to release and the access settings actually saved on that version. When a link or export behaves unexpectedly, go back to the version’s **Sharing**, **Access**, and **Preview** areas and recheck each one in order. If a shared link opens an **access denied** message or a **sign-in** screen, the version is usually still using an internal or restricted access mode. Open the version’s sharing settings and confirm whether readers are expected to sign in. If they are not, switch the version to the correct public-facing option, save the change, and test the same link again in a signed-out browser window. If readers are seeing an outdated version, return to the **Versions** list and verify that you copied the link from the correct version entry. Compare the **version name**, **status**, and **last updated** details. Then reopen the version and make sure the latest edits were saved and included before you copied the link. If internal notes or draft content appear in the shared view, inspect the version page by page in **Preview** or **Reader view**. Remove content that was only meant for editors, and confirm that any draft-only markers are no longer present. This is especially important after moving a version from internal review to public access. When the exported file does not match the browser preview, compare the export output against the current version state. A common fix is to finalize the version first, confirm visibility and content in preview, and then generate the export again. Treat the browser preview as the reference point for what external readers should receive. ## Overview This guide focuses on the final preparation work you do in Atloria before a documentation version is shared outside your immediate editing team. The goal is not just to turn on public access, but to make sure the version readers open is the right one, shows the right content, and behaves the right way when accessed through a share link or exported file. You will usually work across a few connected areas in the version workflow: - The **Versions** list, where you choose the correct version entry - The version **Status** and identifying details, which help confirm release readiness - The version **Visibility**, **Access**, or **Sharing** controls, where you decide who can open it - The **Preview**, **Reader view**, or shared link experience, where you verify the real reader outcome - Any **Export** action tied to the version, if you are distributing a file as part of the release This document assumes you have already handled the earlier release checks around sharing and export readiness. If you still need to review those decisions, go back to [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness). Here, the focus is narrower: preparing one version for public access or controlled sharing and confirming that external readers will see exactly what you intend. Because Atloria supports both internal project workspaces and public-facing documentation experiences, a version can look correct inside the editor but still behave differently for outside readers. That is why this guide emphasizes checking the actual shared outcome, not just the saved setting. ## Prerequisites Before you start preparing a version for public access or sharing in Atloria, make sure the basic release conditions are already in place. This helps you avoid changing visibility on a version that is still incomplete or not approved for distribution. You should have the following ready: - Access to the project’s **Versions** list - Permission to open the version’s **Sharing**, **Access**, or **Visibility** settings - A version that already contains the content you intend to share - Final or near-final page updates, including screenshots, attachments, and navigation changes that should appear to readers - Any required internal review or approval already completed for that version - A reason for the release choice, such as internal review, limited external sharing, or public documentation access It also helps if you can test the result from a reader’s perspective. For example: - A separate browser window for opening the **Share link** - A signed-out or private browsing session for checking public access behavior - Enough time to compare the shared view with any exported output before distribution If your team manages version access alongside audience planning, public navigation, or release approvals, keep those related decisions nearby while you work. You do not need to repeat those setup steps here, but you do need to confirm that the version you are sharing reflects them correctly. Once these items are in place, you can move through the version’s sharing controls with confidence and verify the exact experience external readers will receive. ## Opening Documentation in the Right Audience Context When you open published documentation in Atloria, you may arrive in a general public view or in a view already tailored to a specific audience. This usually depends on how you entered the docs. A reader might start from the published documentation home page, click an audience-specific link shared by a Documentation Manager, or choose a path from public navigation after the site loads. If you planned these paths earlier, the setup described in [Planning Audience Specific Release Views](doc:planning-audience-specific-release-views) is what makes those entry points possible. As soon as the page opens, look at the top area of the page for signs of the active audience context. In Atloria, this can appear as an audience label, a selected audience name in a switcher, or navigation that already reflects one audience path instead of the full public set of pages. If the page title and surrounding navigation feel narrower than the full site, you are likely already reading in a filtered audience view rather than the default public view. The difference matters. The default public view is the broadest reading experience available to public visitors. An audience-tailored view narrows what you see so the page, navigation, and supporting guidance match a specific reader group. That can affect which pages appear in the sidebar, which notes show inside an article, and which examples are visible on the page. Documentation Managers publish these audience-ready public views so readers can open them directly without signing in. If a public page has been prepared for a specific audience, you can read it from the published documentation site just like any other public page. [SCREENSHOT: published documentation page showing page header with active audience label or switcher] ## Following an Audience Path Through the Docs 1. Start on the published documentation home page in Atloria. Look for the audience selector, an audience-based landing choice, or navigation links that clearly point to a specific reader path. 2. Choose the audience that matches what you need to read. After you select it, open a section from the main page, sidebar, or featured links area. The page should load with navigation that reflects that audience instead of showing every available topic. 3. Check the left navigation, table of contents, or breadcrumb trail as you move deeper into the docs. These page elements help confirm that you are still following the same audience path. If the selected audience is active, the surrounding structure should stay consistent with that choice. 4. Continue opening related pages from links inside the article or from the sidebar. In a well-structured audience path, those links continue to surface content that belongs to the same audience view. You should not need to reselect the audience on every page if the public docs are set up correctly. 5. Watch for shared pages. Some articles are meant for everyone, so they may appear in more than one audience path with little or no visible change. Other pages may show different guidance, examples, or notes depending on the selected audience. If the article stays the same but the surrounding navigation still reflects your audience, you are likely on shared content. This is especially useful when you want to read a sequence of pages without constantly checking whether you have drifted into a broader public view. The breadcrumb, sidebar, and page-to-page links are your best cues for staying inside the intended path. [SCREENSHOT: documentation home page with audience choice and sidebar updating after selection] ## Reading Tailored Content on a Page Once you are inside an audience path, the article itself may change. In Atloria, audience-tailored content can appear as special callouts, audience-only notes, tabs with different guidance, banners, or full sections that show only when a certain audience is active. These changes are part of the reading experience, so pay attention not just to the page title but also to what appears between headings. A common pattern is shared page structure with tailored details inside it. The main heading may stay the same for all readers, while examples, instructions, or inline guidance shift to match the selected audience. For example, one audience might see a more introductory explanation, while another sees more advanced operational guidance on the same page. If you notice a section that appears in one audience view but disappears after switching audiences, that is a sign the content is intentionally filtered. Hidden content is handled by simply not showing it to public readers outside the intended audience. You do not see blocked placeholders or internal editing markers. Instead, Atloria presents only the material that belongs in your current reading context. That keeps the page cleaner and avoids mixing instructions meant for different reader groups. Look for visual cues that separate shared content from tailored content. These may include an audience label near a note, a banner tied to the active audience, or a section that changes while the rest of the article remains unchanged. When only part of the page shifts after an audience change, that usually means the article contains both shared content and audience-specific content together. If you want to confirm what changed, switch audiences and compare the same heading, note, or example block rather than scanning the whole page at once. [SCREENSHOT: article page with shared headings and an audience-specific callout or section] ## Checking That You Are in the Correct Reading View 1. Look near the page title or top header for the active audience name. In Atloria, this may appear as an audience badge, a selected value in the audience switcher, or another clear label showing which reader view is active. 2. Confirm the path around the article. Use the breadcrumb, section navigation, or page metadata to make sure the page belongs to the audience path you intended to follow. If the surrounding navigation looks too broad or unrelated, you may be in the default public view instead of a tailored one. 3. Compare the page with another audience view. Open the audience selector and switch to a different audience while staying on the same page if that option is available. Then watch for changes in notes, examples, banners, and section visibility. Even small changes can confirm that audience filtering is working. 4. Reload the page after selecting the audience. If the same audience label and the same tailored sections appear again, the view is loading consistently. This is a quick way to confirm that the audience context is not temporary. 5. Reopen the page from an audience-specific link if one was shared with you. When the page opens with the same audience already selected, you can be more confident that you are reading the intended public version. This check is especially helpful before sharing a page with teammates or using the content in training, onboarding, or release communication. If the audience name, breadcrumb, and visible content all align, you are in the correct reading view. [SCREENSHOT: page header showing audience badge next to title and breadcrumb below] ## Switching Audiences Without Losing Your Place 1. Open the audience switcher on the current page. If Atloria supports the same article across multiple audiences, you can change the selected audience and stay on the current article instead of going back to the documentation home page. 2. After switching, look at the page title, audience label, and body content. If the article exists for the newly selected audience, the page stays in place while the tailored sections, notes, examples, or navigation update to match the new context. 3. If the article is not available for the audience you selected, Atloria may move you to a fallback view. Depending on how the public docs were published, this can mean showing shared content, opening a related page, or returning you to an audience landing page where you can choose another section. 4. Check in-page navigation after the switch. If the article includes anchor links, tabs, or a table of contents, make sure those still match the visible sections. When audience-specific sections disappear, some in-page links may also change because the page structure has been updated for the new audience. 5. Continue browsing to another page and confirm the audience remains selected. Atloria may preserve the chosen audience through the page address or through a saved reading preference, which helps keep the same context across multiple pages. Switching audiences is most useful when you need to compare how the same topic is presented to different reader groups. Stay focused on one article at a time and watch what changes in the header, navigation, and content blocks after each switch. [SCREENSHOT: audience switcher opened on an article page with current article retained after selection change] ## Fixing Common Problems with Audience-Specific Views If the audience view does not look right, start with the most visible clues on the page. - **Audience label is missing or incorrect** - Reload the page and check the header again. - Open the audience switcher and reselect the intended audience. - Confirm that you opened a published public page, not a private workspace view. - If you used an old bookmark or copied link, reopen the page from the published documentation home page and choose the audience again. - **Expected tailored section does not appear** - Check whether you are on a shared page. Some pages are intentionally the same across multiple audiences. - Switch to another audience and compare the same area of the article. - Look for changes in callouts, examples, tabs, or banners rather than expecting the whole page to change. - If nothing changes, return to the audience path entry page and reopen the article from there. - **Navigation shows the wrong pages** - Go back to the audience landing page or documentation home page. - Reset the audience selection and choose the correct path again. - Reopen the section from the updated sidebar or navigation menu so the table of contents rebuilds around the right audience. - **A shared link opens the wrong context** - Check whether the page address includes audience-specific details that may have been removed when the link was copied. - Reopen the page from the intended audience path instead of from a general public page. - After the correct audience loads, use that version of the link when sharing. If you are reviewing a public reading experience before launch, the next guide, [Reviewing Public Audience Pages Before Launch](doc:reviewing-public-audience-pages-before-launch), walks through how to validate those pages more systematically. ## Overview - Atloria lets public readers open documentation in a general public view or in an audience-tailored view. - The active audience is typically confirmed through the page header, an audience label, a selected audience switcher value, or navigation that reflects a specific audience path. - Audience paths affect more than just the page list. They can also change breadcrumbs, section links, examples, callouts, and other guidance inside an article. - Shared pages may appear in multiple audience paths with little change, while tailored pages can show different sections or hide content entirely depending on the selected audience. - You can usually verify the correct reading view by checking the audience name near the page title, reviewing the breadcrumb trail, and comparing the same page across different audience selections. - When Atloria supports it, switching audiences keeps you on the same article so you can compare how the content changes for different reader groups. - If something looks wrong, the fastest fixes are to reload the page, reselect the audience, return to the audience landing page, and reopen the article from the correct public path. - For planning decisions behind these reading experiences, refer back to [Planning Audience Specific Release Views](doc:planning-audience-specific-release-views). ## Prerequisites - You need access to a published Atloria documentation site that has already been prepared for public reading. - The documentation should include at least one audience path, audience selector, or audience-specific navigation option. - It helps to know which audience you are trying to read as, especially if the same project includes shared pages and tailored pages. - If you are comparing views, have a page open that is known to contain audience-specific notes, examples, tabs, or sections. - If a Documentation Manager shared a direct public link for a specific audience, keep that link available so you can confirm it opens the correct reading context. - For background on how these audience experiences are designed before publication, see [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences) and [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation). ## Understanding the version review workflow In Atloria, the version review workflow centers on the **Versions** list and the **version details** page. A version usually starts in **Draft**, moves to **In review** when you send it for review, changes to **Approved** when the review decision is accepted, or returns for changes when **Rework requested** is recorded. The current status appears on the version record, so you can quickly tell whether the version is still being prepared, waiting on reviewers, or ready for the next release step. Each role has a different part in this process. The **Technical Writer** prepares the version and uses **Request review** when the content is ready for formal feedback. The **Documentation Manager** opens the version, checks the content, and records a decision such as approval or rework. The **Project Administrator** makes sure the right people can open the project, access the version, and participate in the review process without permission problems. It helps to separate the actions in the workflow: - **Requesting a review** sends the version to selected reviewers. - **Checking reviewer responses** means reading comments, decisions, and pending responses on the version details page. - **Recording a decision** means a reviewer or approver chooses the available decision option and adds comments. - **Returning a version for changes** moves the version out of the active review path so the writer can revise it and submit it again. The **version details** page is the main place to manage all of this. That page shows the version status, reviewer assignments, review notes, and decision history in one place. If you already completed the readiness work described in [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval), this is where that preparation turns into a formal review decision. [SCREENSHOT: Version details page showing status, assigned reviewers, and review history] ## Preparing a version before requesting review Before you click **Request review**, open the version from the **Versions** list and confirm that the version record is complete. The version should already be saved and visible in the list. If you cannot find it in **Versions**, finish saving your work first and return to the version details page before starting the review process. On the version record, check the main details that reviewers rely on to understand what they are reviewing. At minimum, confirm that the version has a clear **title**, a useful **description**, and the correct current **status** before the review starts. These details help reviewers identify the right release candidate and avoid confusion when several versions are being worked on at the same time. It is also important to confirm access before sending the request. Reviewers must be able to open the project or workspace where the version lives. If a reviewer does not have access, they may appear to be assigned but still be unable to open the version and submit a decision. This is usually something the **Project Administrator** checks in advance. Before sending the request, review the latest content on the version details screen: - Make sure recent edits are saved. - Check that any supporting attachments or related review materials are present. - Confirm you are opening the correct version, especially if there are multiple drafts. - Re-read any notes that should guide the reviewer’s decision. This preparation step is where you catch incomplete drafts before they enter formal review. If you need a refresher on getting a version into a ready state, use [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval) as your reference rather than repeating those checks during the review request itself. [SCREENSHOT: Version details page with title, description, status, and related content ready for review] ## Requesting review for a documentation version 1. In Atloria, open the project and go to the **Versions** list. 2. Select the version you want to review to open its **version details** page. 3. On the version page, click **Request review**. 4. In the reviewer selection area, choose one or more reviewers. 5. Add any review notes or decision context that reviewers should read before they begin. 6. Confirm the request to send the version into review. When you choose reviewers, make sure you are selecting the people responsible for the actual decision. A **Technical Writer** usually submits the request, while a **Documentation Manager** often reviews the content and records the decision. If access needs to be adjusted first, ask the **Project Administrator** to confirm that the selected reviewers can open the version. Use the review notes area to give clear direction. For example, you might explain what changed in this version, which sections need the closest attention, or whether the review is focused on release readiness. These notes appear as context for reviewers when they open the request, so this is the best place to set expectations without adding separate messages outside the version record. After you submit the request, stay on the version details page and verify the result: - The version status should change from **Draft** to **In review**. - The review panel should show the assigned reviewers. - The request date should be visible. - The overall review state should show that responses are pending. If the status does not change, refresh the page and check whether the request was fully submitted. You should not leave the page assuming the review started until you can see the updated status and reviewer list. [SCREENSHOT: Request review panel with reviewer selection, notes field, and updated In review status] ## Checking review status and reviewer responses Once a version is in review, return to the **version details** page to track progress. This page is the clearest place to see whether the version is still waiting on responses, has already been approved, or has been sent back for changes. The status indicator gives the overall result for the version, while the review area shows what each assigned reviewer has done. As responses come in, read the comments and decision entries in the review history or activity area. This is where reviewers explain why they approved the version or why they want changes before approval. If you need to follow up, use those comments to understand exactly what is blocking the version instead of guessing from the status alone. Keep in mind that individual reviewer responses and the overall version decision are not always the same thing. One reviewer may have completed their review while another is still pending. The version can remain **In review** until the required decision is fully recorded. When you monitor progress, look at both the overall status and the list of assigned reviewers. Use the version details page to answer these questions: - Is the version still **pending review**, or has a decision already been made? - Which reviewers have responded? - Which reviewers are still pending? - Did any reviewer leave comments that require clarification or changes? If one or more assigned reviewers have not responded, the review is not fully complete. In that case, the writer or manager may need to follow up outside the version page, but the version record remains the source of truth for what has and has not been submitted. For more detail on interpreting comments and review outcomes, see [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up). [SCREENSHOT: Review history showing reviewer names, comments, decisions, and pending responses] ## Approving a version or sending it back for rework 1. Open the version from the **Versions** list and confirm it is currently marked **In review**. 2. On the **version details** page, find the decision controls in the review area. 3. Choose **Approve** if the version is ready to move forward, or choose **Request rework** if changes are still needed. 4. Enter decision comments explaining why you approved the version or why it is being returned. 5. Submit the decision and wait for the page to update. 6. Confirm the new status and review history entry on the version record. Decision comments matter because they become part of the version history. If you approve the version, your comments can explain what was reviewed and any limitations that were accepted. If you request rework, use the comments to point the writer to the exact content or attachments that need attention. Clear comments reduce back-and-forth and make the next review cycle faster. After an approval, verify that the version status changes to **Approved**. The review history should also show the approval decision and the comment you entered. This gives everyone working on the release a visible record that the review step is complete. If you choose **Request rework**, confirm that the version moves into a rework-needed state. At that point, the writer can reopen the version, make the required edits, save the changes, and submit a new review request when the updates are ready. Rework does not end the process; it sends the version back into revision so it can return to review with the issues addressed. If you need more guidance on decision handling, see [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). [SCREENSHOT: Decision controls showing Approve and Request rework options with comment box] ## Common issues and how to fix them The most common review problems in Atloria are easy to spot once you know where to look on the version details page. - **Request review is unavailable** - Check whether the version has been saved. - Confirm the version is not already marked **In review**. - Review the version record for missing required details such as **title**, **description**, or other information expected before review. - Return to the version page, save your updates, and try **Request review** again. - **A reviewer cannot access the version** - Confirm the reviewer has access to the correct project or workspace. - Check that the reviewer was actually assigned in the review request. - Make sure you are sending the correct version from the correct project. - If needed, ask the **Project Administrator** to review permissions before resending the request. - **The status does not update after a decision** - Refresh the version details page. - Check whether the reviewer fully submitted the decision after entering comments. - Look in the review history or activity area for a new decision entry. - If no entry appears, the reviewer should reopen the version and submit the decision again. - **The version stays blocked in rework** - Make sure the writer saved all requested edits. - Confirm the version was submitted for review again after the changes were completed. - Check that the status moved out of the rework state and back to **In review** after the new request. When troubleshooting, always start with the **version details** page. It shows the current status, reviewer assignments, and decision history together, which makes it the fastest place to identify whether the problem is missing information, access, or an incomplete review action. ## Overview Version reviews in Atloria are managed from the **Versions** list and the **version details** page. The workflow is straightforward: a writer prepares a version, uses **Request review**, selected reviewers respond, and the version either moves to **Approved** or returns for changes through **Request rework**. The status shown on the version record is the main indicator of where that version stands in the approval process. This workflow is shared across the people involved in release decisions: | Role | Main action in the review workflow | Where they usually work | |---|---|---| | Technical Writer | Prepares the version and clicks **Request review** | **Versions** list and **version details** page | | Documentation Manager | Reviews content and records **Approve** or **Request rework** | Review area on the **version details** page | | Project Administrator | Confirms access and keeps the review process moving | Project access and workspace controls | The most important thing to remember is that requesting a review is not the same as completing one. Sending the request only moves the version into **In review**. You still need to watch reviewer responses, read comments, and confirm that a final decision appears in the review history. If the version is returned for changes, the writer must update the version and submit a new request. If you have already worked through [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval), this guide picks up from that point and shows how the actual review request and decision cycle works in Atloria. ## Prerequisites Before you start a version review in Atloria, make sure the version and the people involved are ready. This avoids failed review requests, missing reviewer access, and versions getting stuck in the wrong status. Use this checklist before opening **Request review**: - The version appears in the **Versions** list. - The version opens correctly on its **version details** page. - The version has been saved after the latest edits. - The version record includes a clear **title** and **description**. - The current status still allows the version to be sent for review. - The intended reviewers can access the same project or workspace. - Any supporting attachments or related review material are already visible on the version record. - The writer knows what feedback or decision is being requested. You should also know who is responsible for each part of the workflow: - The **Technical Writer** sends the review request. - The **Documentation Manager** reviews the version and records the decision. - The **Project Administrator** helps resolve access or workspace issues if reviewers cannot open the version. If the version is still being finalized, do that work first before starting the review cycle. The earlier preparation steps are covered in [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval). After you complete the review process described here, the next step is [Preparing Versions for Review and Approval](doc:preparing-versions-for-review-and-approval). ## 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. ## Opening a page and checking whether it is ready for release In Atloria, start from your project’s documentation workspace and open the page you want to review. If you already organized your page tree and navigation, use the structure you set up earlier in [Managing Project Content Structure and Navigation](doc:managing-project-content-structure-and-navigation) to find the correct page quickly. Once the page opens, look first at the page header. This is where Atloria shows the current page state, such as whether the page is still a draft, ready for review, or already part of a release-focused workflow. Before you edit anything, check the visible status labels and readiness indicators in the page header or toolbar. These labels help you avoid changing content that may already be under review. If the page shows a review-related state, pause and confirm whether your team expects further edits or whether the page should remain unchanged until review is complete. You should also look for ownership and responsibility details on the page. In many team workflows, the page view shows who is currently responsible for writing, reviewing, or approving the content. If an assigned editor or reviewer is listed, use that information before making direct changes. This helps prevent duplicate work and avoids confusion about who is expected to finish the page. Pay attention to whether the page is tied to a version generation or release review process. If Atloria shows that the page has already been included in a release-related workflow, confirm whether your changes belong in the current cycle or a later one. A quick check at this stage saves time later when teams are trying to explain why a page changed after review. [SCREENSHOT: Documentation page header showing page title, status badge, readiness indicator, and assigned team members] ## Comparing revisions to understand what changed When you need to understand how a page has changed over time, open the page and use the revision history or changes option in the page toolbar. Atloria keeps saved revisions so your team can inspect earlier versions instead of guessing what was edited. This is especially useful when a reviewer asks why wording changed, when a section disappeared, or when a page suddenly looks different from the last approved draft. Choose two saved revisions from the history list to compare them side by side. In the comparison view, focus on three kinds of changes: added content, removed content, and edited wording. Read through headings, body text, and links carefully. If the page includes structured sections, compare each section in order so you can tell whether the change was a small wording fix or a larger rewrite that may affect release readiness. Use the details attached to each revision to understand the context of the change. Atloria may show who saved the revision, when it was saved, and any note entered at the time. These details are often enough to answer practical questions such as whether the change came from a writer, a reviewer, or a manager preparing the page for release review. After comparing revisions, decide what should happen next: 1. Keep the latest revision if the newer content is correct and complete. 2. Restore an earlier revision if the recent changes introduced mistakes or removed approved content. 3. Continue editing the current draft if the latest version is mostly right but still needs updates. If you are unsure which revision should move forward, leave a page-level note before making a restore decision so the rest of the team can see your reasoning. [SCREENSHOT: Revision history panel with two revisions selected for side-by-side comparison] ## Coordinating edits without overwriting each other's work Team editing works best when everyone checks the page state before typing. In Atloria, look for page edit controls that show whether someone else is already working on the same page. If the page indicates active editing, avoid jumping in with direct changes unless your team has agreed on that handoff. Instead, review the current draft and communicate through the page’s collaboration tools. Use page-level comments, review notes, and assignment details to coordinate work. For example, if you want a writer to expand a section, leave that feedback directly on the page rather than rewriting the section yourself while they are still editing. If the page needs a final quality pass, assign or confirm the reviewer instead of making untracked last-minute edits. These small habits make the revision history easier to follow and reduce the chance that one person’s work will replace another person’s draft. Save changes in small, meaningful revisions rather than waiting until the entire page is complete. Frequent saved revisions give your team a clearer trail of what changed and when. They also make it easier to compare versions later during review. If your team uses change notes when saving, write short notes that explain the purpose of the update, such as clarifying a workflow, fixing internal links, or responding to review feedback. If a conflict does happen, involve the right person quickly. Project administrators or documentation managers may need to step in when a page must be unlocked, reassigned, or restored after overlapping edits. Ask for help when: - A page appears locked and the original editor is no longer available - The assigned owner is no longer the right person for the work - Recent edits replaced approved content - The team cannot agree which saved revision should become the active draft [SCREENSHOT: Page editing area with comment panel, assignment details, and edit status indicator] ## Reviewing page quality before version generation Before a page moves into version generation, review it as a finished documentation page rather than as a working draft. In Atloria, start with the visible readiness or quality indicators on the page. If the page is still marked as draft or not ready, open the page content and confirm what is missing before changing the status. Check the core page elements first. A release-ready page should have a clear title, a useful description if your team uses one, complete body content, and working internal links. Read the page from top to bottom in the editor and make sure the structure is complete. Watch for unfinished headings, placeholder wording, broken flow between sections, or references to content that has not been added yet. Then review collaboration items that can block readiness. Open the comments or notes area and look for unresolved feedback. A page may appear complete at first glance but still be held back by open review questions or pending edits. Also confirm that the latest changes were saved as a revision. If a writer made updates but did not save them properly, those changes may not be available for comparison or release review. Use a simple quality check like this before updating the page status: | Check area | What to confirm | |---|---| | Title and structure | The page title matches the topic and sections are complete | | Description and body | The main content is filled in and reads clearly | | Links and references | Internal links point to the correct pages | | Comments and notes | No unresolved review items remain | | Status | The page is moved from draft to the correct review-ready state | Once everything is complete, update the page status to the appropriate review state so release reviewers can immediately see that the page is ready for the next step. ## Using release review to confirm approved content is included Release review is where Atloria helps your team confirm that the right page revision is actually moving forward. After a page has been reviewed, open the release review area for the version or release set you are preparing. Your goal here is not just to see that the page exists, but to confirm that the correct reviewed revision is the one being picked up. Start by checking whether the page appears in the release review set at all. If it does, compare the release review entry with the page’s current status and latest saved revision. This helps you catch a common problem: a page was reviewed earlier, but later edits changed the draft after review. In that case, the page may need another review pass before it should be included. Focus on pages that look outdated, missing approval, or changed after they were marked ready. Atloria’s review and status information should help you spot these issues quickly. If a page in the release review set still shows an incomplete state, unresolved feedback, or a newer unreviewed revision, pause and coordinate with the assigned writer or reviewer before sign-off. A clean release review usually involves three roles working together: 1. Technical writers confirm the page content is complete and saved correctly. 2. Documentation managers verify the page status, review outcome, and inclusion in the release set. 3. Project administrators step in if access, ownership, or workflow issues prevent the correct revision from moving forward. Use release review as a final confirmation point, not as the first time anyone checks quality. By the time a page reaches this screen, the content should already be stable, reviewed, and clearly assigned. [SCREENSHOT: Release review screen showing included pages, review state, and pages needing attention] ## Fixing common collaboration problems during review When a page does not behave as expected during review, start with the page itself before assuming something larger is wrong. Most collaboration issues in Atloria come from page status, unsaved revisions, unresolved comments, or ownership confusion. If a page shows as not ready, reopen it and check the visible status, required content areas, and collaboration panel. Make sure the title and body are complete, internal links are in place, and any review comments have been resolved. A page can remain blocked simply because one open comment or pending note still signals unfinished work. If a revision seems to be missing from comparison, first confirm that the draft was actually saved. Then reopen the revision history and make sure you selected the correct entries. Teams often compare the wrong pair of revisions and assume a change disappeared, when the needed revision is simply further down the history list. If edits appear to have been overwritten, use revision history immediately. Compare the recent saved versions, identify the correct content, and restore the right revision if needed. After that, check the assignment details so only one person is actively responsible for the next update. This avoids repeating the same conflict. If a page is excluded from version generation or release review, verify three things: - The page status is in the correct review-ready or approved state - The latest revision is the one that was submitted for review - No unresolved collaboration items are still blocking inclusion When the issue is not clear, involve a documentation manager or project administrator. They can help confirm whether the page needs reassignment, status correction, or revision restoration before the release cycle continues. ## Overview This guide focuses on how teams work together on documentation pages inside Atloria without losing track of quality or ownership. The main tasks are checking whether a page is ready to be edited, comparing saved revisions, coordinating updates through comments and assignments, and confirming that the correct reviewed content is included in release review. Use this workflow when multiple people touch the same page during drafting, review, and release preparation. It is especially useful when a writer updates content after feedback, when a reviewer needs to verify what changed between drafts, or when a documentation manager must confirm that only ready pages move into version generation. Instead of treating page editing as a one-person task, Atloria supports a shared process built around visible page status, revision history, and review readiness. This document does not repeat page creation or content structuring steps. For writing and editing page content, see [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages). For organizing pages in the project structure, see [Managing Project Content Structure and Navigation](doc:managing-project-content-structure-and-navigation). Here, the focus is on collaboration after the page already exists and is moving through team review. You will get the most value from this guide if your team already uses consistent page statuses and review responsibilities. That makes it easier to tell whether a page is still being drafted, waiting for review, or ready to be included in release work. After you are comfortable with these collaboration steps, continue with [Managing Document Comparisons During Content Updates](doc:managing-document-comparisons-during-content-updates) to go deeper on comparing content changes across updates. ## Prerequisites Before you use the collaboration steps in this guide, make sure you can already open the correct project and work inside its documentation area in Atloria. You should also be comfortable finding pages in the project structure and opening them for review. You will need: - An Atloria account that can sign in and access the relevant project workspace - Permission to view and edit documentation pages, or at least permission to review them - A project that already contains documentation pages and saved drafts - A team workflow that uses page statuses, review steps, or release preparation - At least one page with revision history if you want to compare changes - Access to comments, notes, assignments, or other page-level collaboration tools used by your team It also helps if your team has already agreed on who handles each part of the workflow, such as writing, reviewing, and final release checks. Without that shared understanding, pages can stay in draft too long or move into review with unresolved issues. If you still need help with account access, start with [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If you need to get familiar with project navigation before reviewing pages, use [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). The next document in this sequence is [Managing Document Comparisons During Content Updates](doc:managing-document-comparisons-during-content-updates), which focuses on comparing changes in more detail during ongoing content updates. ## Opening enterprise analytics and choosing projects to compare In Atloria, start from the authenticated workspace and open the **Admin** area. On the main **Admin** screen, look for the **Analytics** card labeled **Usage statistics and insights**. Select that card to open **Analytics & Insights**. When the analytics screen opens, first confirm that you are working from the enterprise reporting view rather than a single project workspace. This matters because project comparison only makes sense when the page is showing combined reporting across multiple projects. The page header should stay focused on **Analytics & Insights**, and your comparison should be built from the project selection controls and reporting filters available on that screen. To compare projects fairly, add the projects you want to review into the same analytics view. Use the **project selector**, **project filter**, or any project-picking control shown in the analytics toolbar. As you add projects, check that each one is included in the current reporting scope before you begin reading charts or tables. If one project is missing from the selected set, the comparison will be incomplete and enterprise totals will not reflect the same group of projects. Set the **date range** before you evaluate any numbers. If one project is being viewed over a different time period than another, the comparison will be misleading. Keep the same reporting window across all selected projects so activity, documentation changes, and usage patterns are measured on equal terms. A quick visual check helps here: - Confirm the **Analytics & Insights** header is visible - Verify the selected **projects** are all included - Make sure the **date range** is the same for the full comparison - Review any active filters before interpreting results [SCREENSHOT: Analytics & Insights screen with project selection and date range filters highlighted] If you need a refresher on enterprise-level reporting before comparing projects, see [Managing Enterprise Analytics for Documentation Programs](doc:managing-enterprise-analytics-for-documentation-programs). ## Comparing project metrics in analytics views Once your projects are selected, move between the available analytics formats to see differences more clearly. In Atloria, comparison is easier when you switch between a **chart view** and a **table view**, if both are available in the current analytics screen. Charts help you spot large gaps quickly, while tables make it easier to read exact values and compare rows side by side. In a chart, look for separate project series, bars, or grouped results that represent each selected project. This view is useful when you want to answer questions like which project is generating more documentation activity or which one is lagging behind over the chosen date range. In a table, scan project rows and compare the values in each metric column directly. This is usually the better option when you need a precise ranking. To make the comparison more useful, sort the current view by the metric that matters most for your review. For example, if you are evaluating documentation performance, sort the table so the strongest and weakest projects rise to the top and bottom of the list. Sorting helps you avoid guessing based on visual impressions alone. Keep your filters consistent while comparing. If one project is being measured with a different content scope, documentation area, or reporting slice, the result is no longer a true side-by-side comparison. Before drawing conclusions, verify that all selected projects are being shown under the same conditions. Focus on these checks while reviewing the screen: - Use **chart view** to spot broad differences quickly - Use **table view** to read exact project values - Apply **sorting** to identify top and bottom performers - Keep the same **filters** active for every selected project - Recheck the **date range** if results seem unexpectedly far apart [SCREENSHOT: Enterprise analytics comparison shown in both chart and table formats] ## Finding stronger and weaker documentation areas across projects Project comparison becomes much more useful when you move beyond overall totals and look at specific documentation areas. In Atloria, use the analytics breakdowns for **category**, **area**, or **section** whenever those reporting dimensions are available. These views help you see whether a project is strong in one part of its documentation but weak in another. Start by narrowing the view to a documentation area you want to evaluate. Then compare how each selected project performs within that same area. One project may show stronger activity or better coverage in a section where another project is consistently low. That difference helps you separate a project-specific issue from a broader enterprise pattern. This kind of comparison is especially helpful when overall project numbers look similar. Two projects may appear close at the summary level, but one may be carrying gaps in a particular documentation area that are hidden in the total. By opening the area-level breakdown, you can identify where the weaker project needs attention. When you review low-performing areas, avoid assuming the problem is always the same. A weak result may come from: - **Low activity**, where the project simply has less recent documentation work - **Low coverage**, where key sections are missing or underdeveloped - A combination of **low activity and low coverage** Use filtered results to test each possibility. If a project looks weak only in one area, the issue may be local to that content. If the same area is weak across several projects, that points to a broader documentation pattern worth addressing at the enterprise level. [SCREENSHOT: Analytics breakdown by documentation area showing multiple projects side by side] For a broader approach to turning analytics into improvement priorities, refer to [Using Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements). ## Understanding how project activity rolls up into enterprise reporting Enterprise analytics in Atloria combines activity from the projects included in your current reporting scope. When you look at enterprise totals, you are not seeing a separate set of numbers created on their own. You are seeing a rollup of the project activity that matches the selected projects, filters, and time window on the screen. This is why project comparison is so important. If an enterprise total rises or falls, the change may come from one project with unusually high activity, or it may reflect smaller changes across several projects. To understand what is driving the enterprise view, compare the selected projects directly and see how each one contributes to the combined result. A practical way to do this is to adjust the **project filter** while staying on the same analytics screen. Review the enterprise total with all selected projects included, then narrow the view to one project or a smaller subset. If the total changes sharply when one project is removed, that project is likely driving much of the enterprise result. If the total changes only slightly, the trend is probably spread across multiple projects. Keep these factors in mind when reading enterprise reporting: - **Project participation**: only selected projects contribute to the current total - **Reporting scope**: filtered documentation areas can reduce what is counted - **Time window**: enterprise trends reflect the chosen date range only - **Selected dimensions**: grouped views can change how the same activity appears When enterprise numbers seem surprising, do not treat them as abstract totals. Trace them back to the projects included in the current view and confirm whether the trend is concentrated or broadly shared. [SCREENSHOT: Enterprise analytics dashboard with total metrics and project filter changes] ## Refining comparisons with filters and reporting dimensions A useful comparison in Atloria usually depends on narrowing the analytics view to the exact question you want to answer. Broad project totals are helpful for an initial scan, but filters and reporting dimensions make the comparison much more reliable. Begin with the most important controls on the analytics screen: - **Date range** - **Project filter** - **Documentation area** filter - Any available **grouping** or **dimension** selector Use the **date range** to focus on the same reporting period for every project. Then narrow by **project** so only the projects relevant to your review are included. If you are investigating a specific content concern, apply a **documentation area** filter to isolate that part of the documentation rather than comparing entire projects. If Atloria offers grouping options, switch the view to compare projects by the reporting slice that best matches your goal. For example, a grouped view may help you compare by **team**, by **documentation area**, or by another available dimension shown in the analytics controls. This is useful when a simple project-to-project total does not explain why one project is performing differently. If your team reviews the same comparison regularly, reuse the same filtered setup whenever possible. A repeated view makes trend tracking easier because you are not rebuilding the comparison from scratch each time. Before sharing conclusions with managers, double-check that the same filters are still active and that no hidden constraint is narrowing the data unexpectedly. When results look inconsistent, clear the current filters and rebuild the comparison carefully. Resetting the view is often the fastest way to confirm whether the issue comes from the data itself or from a leftover filter that changed the reporting scope. [SCREENSHOT: Analytics filters and grouping controls used to refine a project comparison] ## Resolving mismatched project comparisons in analytics If project comparisons do not look right in Atloria, start by checking what is included in the current analytics view rather than assuming the reporting is wrong. Most mismatches come from scope, filter, or visibility differences on the screen. When a project does not appear in the comparison, first confirm that you have access to enterprise reporting and that the project is part of the current reporting scope. Then review the **project filter** or selection control to make sure the project is actually included. A missing project usually means it was not selected or is outside the current enterprise view. If metrics look inconsistent between projects, compare the active settings at the top of the analytics screen. Make sure the same **date range**, **documentation area**, and any grouping or dimension settings are applied across the comparison. Even one extra filter can make two projects look dramatically different. If enterprise totals do not match what you expected from project activity, check whether some projects or documentation areas are excluded. A total that seems too low often reflects a narrowed reporting scope rather than missing activity. Review all active filters before trying to interpret the rollup. When a documentation area appears weaker than expected, look at both activity and coverage in that area. A low result may mean the project has less recorded work in the selected period, or it may mean that documentation in that area is incomplete compared with other projects. Use this quick troubleshooting list: - **Missing project**: review access and project selection - **Uneven metrics**: align date range and filters - **Unexpected enterprise total**: check excluded projects or areas - **Weak documentation area**: compare activity and coverage together If you also need to review administrative reporting availability, see [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Overview Use Atloria’s **Admin** workspace and **Analytics & Insights** screen to compare multiple projects in one enterprise reporting view. The goal is not just to see which project has higher numbers, but to understand how those numbers relate to documentation activity, coverage, and the reporting scope currently selected on the page. A strong comparison usually includes four parts: - The same **projects** selected in one analytics view - The same **date range** applied across all projects - The same **filters** and **reporting dimensions** - A review of both **project-level** and **enterprise-level** results As you work through the comparison, move between broad enterprise totals and project-specific breakdowns. Enterprise totals help you spot overall trends, while project rows, chart series, and documentation-area breakdowns help you identify where those trends are coming from. This is especially useful when one project seems to be lifting enterprise performance or when a weak area appears across several projects at the same time. In practice, you will often use this screen to answer questions such as: - Which project is strongest in the current reporting period? - Which project is falling behind in a specific documentation area? - Is an enterprise trend driven by one project or several? - Are weak results caused by low activity, low coverage, or both? This guide focuses on comparison inside the enterprise analytics view. It builds on the enterprise reporting approach covered in [Managing Enterprise Analytics for Documentation Programs](doc:managing-enterprise-analytics-for-documentation-programs), but stays focused on side-by-side project analysis rather than general enterprise monitoring. [SCREENSHOT: Enterprise analytics screen showing project comparison context] ## Prerequisites Before you compare projects in Atloria, make sure you can open the authenticated workspace and access the **Admin** area. From there, you should be able to select the **Analytics** card and open **Analytics & Insights**. If you cannot reach that screen, you will not be able to build an enterprise-level comparison. You should also have the right level of visibility for the projects you want to review. A project can only be compared if it is available in the current enterprise reporting scope and appears in the project selection controls on the analytics screen. Have these items ready before you begin: - Access to the **Admin** workspace - Access to **Analytics & Insights** - At least two projects available in the current enterprise reporting scope - A clear **date range** for the comparison - A clear question to answer, such as comparing overall activity or reviewing one documentation area It also helps if you already know the difference between enterprise reporting and project-level reporting. If you need that foundation, review [Analyzing Documentation Performance Across Projects](doc:analyzing-documentation-performance-across-projects) and [Managing Enterprise Analytics for Documentation Programs](doc:managing-enterprise-analytics-for-documentation-programs) before continuing. For the next step after project comparison, continue with [Using Analytics Reporting Across Enterprise and Project Views](doc:using-analytics-reporting-across-enterprise-and-project-views). ## Understanding how version statuses signal release readiness In Atloria, the **Status** field on each documentation version is the quickest way to understand where that version stands in the release process. When you open a project and go to its version list, you can use the status badge on each row to see whether a version is still being edited, waiting for review, cleared for release, limited for access testing, or already live. This is especially useful when several release versions are moving at the same time. The most common status values in this workflow are: | Status | What it means in Atloria | Typical next step | |---|---|---| | **Draft** | The version is still being edited or assembled | Finish content and readiness checks | | **In Review** | Editing is complete enough for stakeholder review | Collect review decisions and feedback | | **Approved** | Required reviewers have signed off | Validate access and publication settings | | **Restricted** | The version is approved but limited to selected viewers for final access checks | Confirm audience and permission behavior | | **Published** | The version has been released | Monitor the live result | A version can be **review-ready** without being **publication-ready**. Review-ready usually means the pages, structure, and release content are complete enough for reviewers to evaluate. Publication-ready is a stricter state. It means the version has already passed review and approval, and any visibility rules, audience restrictions, or release timing settings have also been checked. Documentation Managers and Project Administrators usually read this information from the **version list**, the **Status** badge on the version record, and any readiness indicators shown on the version page. If a version says **Approved** but still needs access validation, it is not ready to publish yet. If it says **Restricted**, that often means the content is finished, but the team is still confirming who can and cannot see it. If you need a refresher on how versions are created before they reach this stage, see [Generating Documentation Versions for Release Cycles](doc:generating-documentation-versions-for-release-cycles). ## Preparing a version before it enters review Before you change a version from **Draft** to **In Review**, open the version record and check that the release details are complete. In Atloria, this usually means confirming the version has a clear **version name**, the correct **release date**, an assigned **owner**, and the intended content scope linked to that version. If any of these details are missing, reviewers may not know what they are approving or whether they are looking at the correct release. Use the version details area to verify the core information: | Detail to check | Why it matters | |---|---| | **Version name** | Helps reviewers identify the release correctly | | **Release date** | Confirms timing and planning | | **Owner** | Shows who is responsible for updates and follow-up | | **Linked content scope** | Confirms which pages belong to the release | Next, review the pages attached to the version. Make sure all planned documentation pages are included and that nothing important is still sitting outside the version or left in an unfinished editing state. If your team expects a feature guide, setup page, or release note to be part of this version, confirm it appears in the version workspace before review begins. A version should not move into review if the page list is still incomplete. You should also confirm access for the people involved in the review. Reviewers, approvers, and publishers need to be able to open the version workspace, read the content, and use the review controls available to them. If someone cannot access the version when review starts, the status may move forward, but the release process will still stall. Finally, look for any checklist area or readiness panel on the version page. Use it to confirm that required checks are complete before you change the status. This is the best point to catch missing details, rather than sending a version into review too early. [SCREENSHOT: Version details panel showing Status, version name, release date, owner, and readiness checks] ## Moving work through review and approval checkpoints 1. Open the version record from the project’s version list and confirm editing is complete. When the content is ready for formal review, change the **Status** field from **Draft** to **In Review**. This signals that the version should now be evaluated rather than edited casually. 2. Check the review and approval controls on the version page. If Atloria shows reviewer or approver assignments, confirm the correct stakeholders are listed before you continue. This helps avoid a version sitting in review with no one clearly responsible for the decision. 3. Follow the progress through the version’s activity area. Use the **activity feed**, workflow history, or checkpoint indicators on the version page to see what happened next. Typical outcomes include: - Review completed - Approval granted - Changes requested - Waiting on a reviewer or approver 4. If reviewers request changes, move the version back to **Draft** so the content team can make updates. This keeps the status aligned with the actual state of the work. After the requested changes are complete, return to the version page and set the **Status** back to **In Review** to restart the checkpoint process. 5. Change the version to **Approved** only after all required review steps are complete and no blocking issues remain. An approved version should not have unresolved reviewer objections, missing sign-off, or incomplete release checks. This stage is about traceability as much as approval. Atloria’s status badges and workflow history help you show whether a version is still under review, sent back for revision, or fully signed off. If your team uses formal review decisions, keep the status in sync with those decisions so the version list remains reliable for everyone involved in release planning. For more detail on review decisions themselves, see [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions). ## Applying access control before publication An **Approved** version is not always ready to go live immediately. In Atloria, you may need to place the version into a **Restricted** status before publication when the release must be tested with limited visibility. This is especially useful when documentation is intended for a specific team, role, group, or audience and you need to confirm that only the right people can see it. Open the version page and review the visibility settings tied to that version or its published output. Depending on how your team manages release access, this may involve setting restrictions for: - Specific teams - User roles - Groups - Audiences Use the preview or restricted-access view to test the result. The goal is to confirm two things: - People who should have access can open the version preview and navigate the content normally - People outside the allowed audience are blocked according to the configured rules This step matters because a version can be fully approved from a content perspective and still fail release readiness if the wrong audience can see it. For example, internal release notes, customer-only setup guides, or role-specific instructions may require a final permission check before publication. There is often a handoff here between Documentation Managers and Project Administrators. Documentation Managers usually confirm the content is approved and organized correctly. Project Administrators may then verify that the visibility rules match the intended audience. If both roles are involved, record that handoff clearly in the version activity or release process your team follows, so nobody assumes publication is ready before access has been tested. If your team needs deeper guidance on visibility decisions, see [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export). ## Confirming that a version is ready to publish 1. Open the version page and review the final readiness indicators. At this point, the version should show an **Approved** status or the equivalent release-ready state used by your team. Any checklist items on the page should be complete, and there should be no unresolved blockers in the version history or review area. 2. Use the available preview or staging view to inspect the exact content that will be released. Check the page order, navigation labels, and overall structure. This is the last practical moment to catch missing pages, incorrect titles, or content that appears in the wrong place. 3. Confirm audience and access behavior in the preview. If the version was placed in **Restricted** status for access testing, make sure that validation is complete before you proceed. A version is only truly publishable when both content approval and visibility checks are finished. 4. Review the publication controls on the version page. Depending on what Atloria shows for your workspace, this may include **Publish**, **Schedule Publish**, or release timing settings. Make sure the selected option matches the release plan. If the documentation should go live later, verify the scheduled timing before saving. 5. Trigger the release only after all checks are complete. If your workspace uses a direct **Publish** action, use it when the version is fully ready. If the workflow updates the **Status** to **Published**, make that change only after review, approval, and access validation are all complete. [SCREENSHOT: Version page showing approved status, checklist completion, preview access, and Publish or Schedule Publish controls] A good final review is not just about the words on the page. It also confirms who can see the release, when it becomes visible, and whether the published navigation matches what reviewers approved. ## Fixing status and readiness problems that block release When a version will not move forward, start with the version page rather than guessing. In Atloria, most release blockers show up as missing details, incomplete review steps, or access settings that do not match the intended audience. If a version cannot move to **In Review**, check the basics first: - Required version details such as **version name**, **release date**, or **owner** may still be missing - Planned pages may not all be linked to the version - A readiness checklist item may still be incomplete - Some content may still be left in an unfinished editing state If a version stays stuck in review, the problem is usually in the checkpoint flow: - A reviewer or approver may not be assigned - A required approval action may not have been completed - A workflow checkpoint may still be waiting for input - The version may need to be returned to **Draft** so changes can be made before resubmission If a version is **Approved** but still not publishable, look at access settings next. A mismatch between the intended audience and the configured restrictions can block release readiness. Use preview to confirm whether the right people can open the version and whether excluded users are correctly blocked. If preview validation fails, fix the visibility settings before trying to publish. If the version should already be live but does not show as **Published**, check the publication action itself: - The **Publish** action may not have been confirmed - The version may have been set to **Schedule Publish** for a later time - The person attempting the release may not have permission to publish - A final permission check may still be preventing the release When troubleshooting, compare the current **Status**, the activity history, and the version checklist together. Those three areas usually tell you whether the problem is missing content, missing approval, or missing release access validation. ## Overview Use this guide when your team already has a documentation version created and needs to decide whether it is truly ready to move toward release. In Atloria, that decision is usually made by reading the **Status** field on the version record, checking the version page for readiness indicators, and confirming that review, approval, and visibility steps have all been completed in the right order. This guide focuses on the middle and late stages of the release workflow: - Interpreting statuses such as **Draft**, **In Review**, **Approved**, **Restricted**, and **Published** - Preparing a version for formal review - Moving the version through review and approval checkpoints - Applying audience or permission restrictions before release - Confirming whether the version is ready for **Publish** or **Schedule Publish** - Troubleshooting versions that appear blocked even after review is complete It does not repeat the earlier steps for creating a version from release content. If you still need to build the version itself, start with [Generating Documentation Versions for Release Cycles](doc:generating-documentation-versions-for-release-cycles). If you need a broader explanation of how statuses appear in version lists and comparison views, see [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). For the planning side of release timing and status decisions, see [Managing Project Version Timelines and Status Decisions](doc:managing-project-version-timelines-and-status-decisions). The goal here is practical: help Documentation Managers and Project Administrators use the version page, review controls, visibility settings, and publication actions in Atloria to make a confident release decision. ## Prerequisites Before you follow the steps in this guide, make sure you already have the basic release materials in place inside Atloria. This workflow assumes you are not starting from an empty project and that the version already exists in the project’s version list. You should have: - Access to the relevant project in Atloria - A documentation version already created for the release cycle - Pages or content already linked to that version - Permission to open the version workspace and update its status - Reviewers or approvers identified for the release, if your team uses formal sign-off - Any audience or visibility requirements already defined for the version It also helps if you are already familiar with: - The project’s version list and version detail page - The meaning of your team’s review and approval checkpoints - How your team handles restricted access before publication - The release timing your team plans to use, especially if you expect to use **Schedule Publish** If you are still organizing the version workspace itself, read [Managing Project Version Workspaces](doc:managing-project-version-workspaces) first. If your team is still coordinating pre-release tasks across contributors, see [Coordinating Version Work Before Release](doc:coordinating-version-work-before-release). The next step after status coordination is learning how the version workspace supports day-to-day release work. Continue with [Understanding Documentation Version Workspaces](doc:understanding-documentation-version-workspaces). ## Preparing source content before you create a release-ready version Before you create a release-ready version in Atloria, review the source content set you plan to freeze for review. This is the point where you stop treating the content as an active draft and start treating it as a candidate for approval and publication. If you have already been tracking generation activity in [Monitoring Version Generation Jobs and Results](doc:monitoring-version-generation-jobs-and-results), use that context to confirm which content set is ready instead of starting over from scratch. Focus first on the pages reviewers are most likely to inspect: the project home page, section landing pages, release notes, setup guides, and any pages linked from top-level navigation. Open those pages in the project workspace and confirm the final wording is present. If a page is still being rewritten, still missing screenshots, or still sitting in a draft-only workstream, do not include it in the release-ready cut yet. Next, check the page details that appear in generated output. In Atloria, that usually means the page title, description, navigation label, and any release-specific values that affect how the version appears in menus or page headers. A version can look complete at first glance but still confuse reviewers if the navigation label uses an old product name or the page description still reflects a previous release. Then review assets and references. Open pages with screenshots, linked guides, reusable content blocks, and cross-links to other sections. Make sure images load, links open the intended destination, and shared content displays correctly in context. Pay extra attention to legal wording, product naming, release identifiers, and any approval-sensitive text. Those details often trigger review feedback even when the rest of the page is correct. [SCREENSHOT: Project documentation page showing title, description, navigation label, and linked assets before version creation] ## Choosing the right moment to cut a documentation version The best time to create a documentation version in Atloria depends on how stable your release content is. In practice, most teams choose one of three moments: feature freeze, release candidate, or general availability. The right choice comes down to how much content churn is still happening and how much time reviewers need before publication. If you cut the version at feature freeze, reviewers get more time to read and comment, but the version may miss late product changes, renamed features, or final screenshots. If you wait until general availability, your content may be more accurate, but formal review can become rushed and publication may slip. A release candidate often gives the best balance because the structure is usually stable while there is still time to fix review findings. Use Atloria’s version workspace as a coordination point with product, engineering, and review stakeholders. Before you create the version, confirm everyone is validating the same release scope. If engineering is still changing feature names, or product is still deciding what ships, your review copy can become outdated almost immediately. It is better to delay the cut slightly than to send reviewers a version that no longer matches the planned release. You should also define what becomes locked once the version is created. For example: - Allow minor corrections such as typos, punctuation fixes, and small wording clarifications - Allow urgent factual fixes that prevent incorrect instructions - Hold back larger rewrites, structural changes, and new sections for the next working draft - Keep release naming, navigation structure, and review links stable unless there is a clear approval reason to change them This decision helps everyone treat the version as a review candidate instead of an open editing space. That discipline is what makes a version truly release-ready rather than simply generated. ## Creating the version intended for review and publication Once the source content is stable, create the review version from the version management area in your project workspace. This is the step where Atloria turns your approved content snapshot into a distinct version that reviewers can inspect without being affected by later edits in ongoing work. 1. Open your project in Atloria and go to the documentation version area for that project. Use the version list or version workspace where existing versions and their statuses are shown. 2. Start a new version from the approved source content. If your team works from a current documentation set that is ready for release, choose that exact source. If multiple content snapshots are available, select the one your team agreed to freeze for review. 3. Enter the release version label exactly as it should appear to reviewers. This label should match the release naming used in navigation, page headers, and any version selector. Be consistent with punctuation, spacing, and numbering. A small mismatch here can create confusion later when reviewers compare comments against the version list. 4. Confirm that Atloria is creating a frozen version rather than pointing reviewers to the live working content. The goal is to preserve the review candidate so later edits in the main documentation flow do not silently change what reviewers are seeing. 5. Run the version generation action and wait for Atloria to create the reviewable output. When the process finishes, open the new version from the version list and verify that it appears as a separate item rather than replacing the current published documentation. [SCREENSHOT: Version management screen with New Version action, version label field, and generated version listed separately] If your team also uses comparison and readiness checks, pair this step with the review approach described in [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). That helps you confirm the version you just created is the right candidate before formal approval begins. ## Validating the generated output before formal review After Atloria creates the version, open it immediately and validate the output before sending it for formal review. This step is not a full editorial pass. It is a focused check to make sure the generated version behaves like a stable release candidate and does not contain obvious publishing problems. 1. Start with the main entry points. Open the version home page, major section landing pages, release notes, and a few task pages that matter most for the release. These pages are the first places reviewers usually visit, so they should look complete and use the correct release wording. 2. Check navigation inside the version. Open the sidebar, follow breadcrumbs, use previous and next links, and switch between a few pages to confirm you stay inside the same version. If Atloria shows a version selector, verify it displays the expected label and does not send you to unversioned or latest content by mistake. 3. Test links and media. Open pages with screenshots, linked procedures, and section cross-references. Watch for broken anchors, missing images, or links that jump outside the intended version. A single broken reference can make reviewers question the reliability of the whole release candidate. 4. Compare a sample of high-priority pages against the source content you froze. Check headings, tables, callouts, and embedded content. You are looking for rendering issues, missing sections, or formatting changes that appeared during generation. A quick validation table can help you stay focused: | What to check | Where to look | What to confirm | |---|---|---| | Entry pages | Home page and section landing pages | Correct release wording and complete content | | Navigation | Sidebar, breadcrumbs, previous/next links, version selector | Reviewers remain in the intended version | | References | Internal links, anchors, screenshots, shared assets | No broken links or missing media | | Page rendering | High-priority task pages and release notes | Headings, tables, and callouts display correctly | [SCREENSHOT: Generated version open in review mode with sidebar, breadcrumbs, and version selector visible] ## Handling review updates without compromising the release candidate Once reviewers begin commenting, protect the release candidate from turning into a moving target. In Atloria, the safest approach is to treat the generated version as the approved review baseline and make only deliberate, documented updates. That keeps review feedback tied to a stable version instead of a constantly shifting draft. Start by separating feedback into two groups: changes that must be made before publication and changes that belong in the next documentation cycle. Publication-critical fixes usually include incorrect steps, wrong release names, missing screenshots, legal wording issues, or broken links on high-traffic pages. Broader rewrites, new examples, or content expansion requests are often better left in the ongoing draft unless they block release approval. When you do need to update the release-ready version, track those edits clearly against the frozen version. Keep a simple record of what changed between review rounds, especially if you regenerate the version. Reviewers should be able to tell whether they are looking at the same release candidate with a few approved fixes or a substantially different copy. This is especially important when multiple teams are reviewing at once. To avoid confusion: - Keep the version label the same unless the release name itself changed - Reuse the same review destination instead of creating parallel copies with similar names - Limit updates to approved publication fixes - Tell reviewers what changed before asking for another pass - Avoid mixing next-release edits into the current review candidate If the update is small, verify only the affected pages and linked paths. If you regenerate more broadly, repeat the validation checks from the previous section before sending the version back for review. For approval-specific workflows, align your update process with [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review) so the release candidate stays controlled all the way to sign-off. ## Fixing common mistakes when creating release-ready versions Most release-version problems in Atloria come from a small set of avoidable mistakes. When something looks wrong after generation, start by checking the version source, the version label, and whether the content was actually frozen at the time you created it. If the version shows incomplete content, the most likely cause is that the wrong source content set was selected. Open the version details and compare the generated pages with the content you intended to freeze. If key pages are missing or older wording appears, create the version again from the correct source snapshot rather than trying to patch around the problem page by page. If reviewers report broken links or missing media, inspect pages that use screenshots, shared assets, and cross-links to other sections. These problems often appear when a page points to content outside the versioned set or when an asset was not available in the source you used. Open the affected page in the generated version and follow each visible link so you can identify exactly where the path breaks. If the wrong release name appears in page headers, navigation, or the version selector, check both the version label and the page-level release wording used in the source content. Correct the naming mismatch and regenerate the version so the review copy stays consistent everywhere reviewers see it. If changes keep appearing unexpectedly after version creation, confirm that your version was created from a frozen snapshot and not from live working content. A release candidate should not keep shifting as teammates edit the main documentation set. Use this table to diagnose quickly: | Problem | Likely cause | What to do | |---|---|---| | Incomplete pages | Wrong source content selected | Recreate the version from the intended source snapshot | | Broken links or missing images | References outside the versioned set or missing assets | Recheck linked pages, shared assets, and media paths | | Wrong release name | Version label or page wording not updated | Correct naming and regenerate the version | | Unexpected content changes | Version not frozen from a stable snapshot | Recreate the version from a fixed review source | [SCREENSHOT: Version details view showing version label, source selection, and generated output status] ## Overview Creating a release-ready documentation version in Atloria means more than clicking a generate action. You are preparing a stable review candidate that matches the release scope, uses the correct naming, and can move through formal review without constant rework. The version should be distinct from your ongoing draft content so reviewers can evaluate a fixed snapshot instead of chasing live edits. This workflow usually starts in the project’s version management area, where you create a new version from the content set your team has agreed to freeze. From there, you validate the generated output, confirm navigation and links behave correctly, and decide how tightly to control changes during review. The goal is to give stakeholders a version they can approve with confidence. A release-ready version in Atloria should meet a few practical standards: - The source content is complete enough for formal review - The version label matches the release name reviewers expect to see - The generated output appears as its own reviewable version - Key pages, links, screenshots, and navigation elements work correctly - Any updates during review are intentional, limited, and easy to explain This guide focuses on that release-preparation stage. It does not repeat the broader job tracking process covered in [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results) or [Monitoring Version Generation Jobs and Results](doc:monitoring-version-generation-jobs-and-results). Instead, it shows how to turn a generated version into a reliable publication candidate that is ready for formal review and eventual release. ## Prerequisites Before you start, make sure you have the right project access and that the content you plan to version is actually ready to freeze. In Atloria, release-ready versioning works best when the project team has already aligned on scope, naming, and review timing. You should have the following in place: - Access to the project workspace where documentation versions are managed - Permission to open the version list and create a new version - A stable source content set that is ready for formal review - Agreed release naming for the version label - Reviewer awareness of which release scope is being documented - Enough time to validate the generated output before sending review links It also helps if you have already completed these related tasks: - Generated at least one documentation version before, using the workflow in [Generating New Documentation Versions](doc:generating-new-documentation-versions) - Reviewed how version comparisons support release decisions in [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness) - Checked current generation activity in [Monitoring Version Generation Jobs and Results](doc:monitoring-version-generation-jobs-and-results) Before cutting the version, confirm that high-visibility pages are ready. That includes the documentation home page, section landing pages, release notes, setup instructions, and any pages likely to be reviewed by product, support, or legal stakeholders. If those pages still contain placeholder text, incomplete screenshots, or draft-only wording, finish that work first. After your release-ready version is created and validated, continue with [Monitoring Version Generation Progress and Results](doc:monitoring-version-generation-progress-and-results) to follow the version through the next stage. ## Reviewing Your Project's Page Hierarchy Before you reorganize anything in Atloria, open your project workspace and use the left navigation area to review the current page structure. Focus on how pages are grouped today, not just on the content inside each page. In the page tree, look for top-level pages that act as major sections, then check which pages appear nested underneath them. Indentation is your quickest clue: pages aligned to the far left are usually broader sections, while indented pages belong under a parent topic. As you scan the list, compare page titles side by side. Similar names often reveal overlap, such as two setup pages that cover nearly the same task or a workflow page that was added under the wrong section. Open a few pages and check the title and slug together so you can spot naming mismatches early. If a page title says one thing but the slug suggests another, readers may have trouble understanding where that page belongs in the structure. It also helps to identify pages that feel disconnected from the rest of the documentation. Draft pages, temporary pages, or pages sitting outside the expected topic branches are often the first signs that the hierarchy needs cleanup. If you recently worked through release status and page readiness in [Managing Project Content from Drafts to Published Pages](doc:managing-project-content-from-drafts-to-published-pages), use that same status awareness here while reviewing the tree. As you review, ask one practical question for every branch: “Would a reader know where to click next?” If the answer is unclear, note the section for reorganization. [SCREENSHOT: Project workspace showing the left navigation tree with top-level pages and indented child pages] ## Organizing Pages into Clear Parent and Child Groups Once you understand the current layout, start grouping pages into clear parent and child sections. In Atloria, a parent page should represent a broad topic that helps readers orient themselves quickly. Good parent pages are usually category-style entries such as setup, workflows, integrations, or reference. Child pages should then break that topic into focused tasks or subtopics that readers can scan without opening every page in the section. 1. In your project workspace, select the page that should become the main landing page for a topic area. 2. Review the related pages in the content tree and decide which ones belong under that topic. 3. Move those pages into the correct place using the page tree arrangement tools or the page location option in the page’s settings. 4. Open each moved page and confirm that the page title and slug still match its new position in the hierarchy. 5. Reorder sibling pages so readers see introductory or overview content first, followed by task-based guides and then deeper reference material. Keep sibling pages consistent. For example, if one child page starts with “Setting Up…,” nearby pages should follow a similar pattern instead of mixing overview titles, question-style titles, and partial phrases. Consistent naming makes the sidebar easier to scan and reduces hesitation when readers are choosing between similar topics. Also separate overview pages from action pages. A parent page can introduce a topic and explain when to use it, while child pages handle specific tasks. That structure keeps the navigation clean and prevents long, overloaded pages from trying to do everything at once. [SCREENSHOT: Content tree with a parent topic page and several child pages grouped underneath in a clear order] ## Controlling How Pages Appear in Navigation A strong hierarchy only helps if the navigation is easy to read. In Atloria, review how page titles appear in the sidebar and trim any titles that are too long, repetitive, or hard to distinguish from nearby items. If several pages begin with the same words, readers may need to read the full line every time. Shorter, clearer labels make the navigation faster to use. 1. Open the project’s page list or content tree and read the sidebar labels as a reader would. 2. Shorten titles that wrap awkwardly or look nearly identical to neighboring pages. 3. Check each page’s visibility and publish status before expecting it to appear in reader-facing navigation. 4. Decide whether the page belongs in the main navigation or should be reached only through links from another page. 5. Reorder pages within each section so the sequence matches a real reading path, from basic guidance to advanced detail. Draft and unpublished pages are especially important here. A page can exist in your workspace without being ready for readers, so keep in-progress work out of the main navigation until the content is complete enough to support the rest of the section. This is useful when you are building a new branch of documentation gradually and do not want readers clicking into unfinished pages. You should also be selective about what deserves a top-level position. Too many top-level pages make the sidebar feel crowded and flatten the structure. Reserve top-level placement for major sections, then place supporting material underneath them. If a page is useful but too narrow for the main menu, link to it from a parent page or a related guide instead of giving it equal prominence. [SCREENSHOT: Sidebar navigation with concise page titles and a logical top-to-bottom reading order] ## Keeping Related Content Discoverable Even a clean sidebar cannot carry every navigation need on its own. In Atloria, readers often move between overview pages, task guides, and reference material while working through a topic. Add internal links wherever readers are likely to need the next step, a related explanation, or supporting detail. This keeps them moving through the documentation naturally instead of backing out to the project home every time. 1. Open an overview page and identify the task pages readers are most likely to need next. 2. Add links from that overview page to the most relevant child pages or related sections. 3. Review task pages and add links back to the overview page or onward to deeper reference content where appropriate. 4. Check page details such as title, summary, and slug so they use the same wording readers are likely to search for. 5. Find pages that are hard to reach and place them under a clear parent page or connect them through related links. When you review discoverability, pay attention to terminology. If one page says “setup,” another says “configuration,” and a third says “getting started” for the same concept, search results and navigation labels become less predictable. Choose one naming pattern for each topic area and use it in titles, summaries, and linked text. This is also the right time to reconnect orphaned content. If a page exists but is not clearly visible in the hierarchy, readers may never find it unless they already have a direct link. Place it under a logical parent or link to it from a nearby page that readers already use. Good structure and good linking work together; one without the other usually leaves gaps. [SCREENSHOT: Documentation page with links to related guides, overview pages, and supporting reference content] ## Auditing the Structure with Your Team After you reorganize the hierarchy, review it with the people who write, review, and maintain the documentation. In Atloria, structural decisions affect more than navigation—they also affect ownership, review flow, and how quickly teams can find pages to update. A short walkthrough of the page tree can reveal issues that are easy to miss when one person reorganizes content alone. 1. Open the project’s page tree and walk through each major branch with your writers and subject matter experts. 2. Confirm that the order of sections matches how readers actually learn or complete tasks. 3. Review draft, published, and older pages together to decide what should stay visible, be merged, or be removed from navigation. 4. Identify duplicate topics that appear in more than one branch and choose a single page to keep as the main source. 5. Assign clear ownership for each branch so future changes do not pull the structure in different directions. During this review, ask your team to think from the reader’s perspective rather than from internal team boundaries. A section that makes sense to one department may feel fragmented to readers if related tasks are split across several branches. If two teams contribute to the same topic area, agree on one parent section and one naming style before more pages are added. Status indicators are useful here as well. A branch filled with draft pages may need to stay hidden until the section is coherent, while a published branch with outdated child pages may need consolidation. If your team already uses review steps and page status decisions from [Managing Project Content from Drafts to Published Pages](doc:managing-project-content-from-drafts-to-published-pages), apply those same habits to structure reviews so navigation changes stay coordinated. [SCREENSHOT: Team review session using the project page tree to discuss page placement and ownership] ## Fixing Common Navigation Problems Most navigation issues in Atloria come down to four things: placement, visibility, naming, or too much clutter. When a page is missing or hard to find, start by checking the simplest explanation before making larger structural changes. 1. If a page does not appear in navigation, open that page and check its publish status, visibility setting, and current parent page. 2. If readers cannot find a topic in search, review the page title, slug, and summary for inconsistent wording. 3. If the sidebar feels crowded, reduce the number of top-level pages and merge thin pages that do not need to stand alone. 4. If teams keep creating overlapping structures, agree on naming rules and assign one owner to each main branch. 5. After each change, test the navigation again by following the path a reader would take to reach the page. Use the table below as a quick way to match a problem with the most likely fix: | Problem | What to check | Likely fix | |---|---|---| | Page missing from navigation | Publish status, visibility, parent page | Publish it if ready, adjust visibility, or move it under the correct parent | | Topic hard to find in search | Title, slug, summary wording | Rename the page using clearer, consistent terms | | Sidebar too crowded | Number of top-level pages, thin sibling pages | Merge related pages and group them under stronger parent pages | | Duplicate sections created by different teams | Branch ownership, naming patterns | Consolidate into one branch and assign clear ownership | When you troubleshoot, avoid solving every problem by adding another page. In many cases, the better fix is to rename, merge, reorder, or relink existing content. A smaller, clearer structure usually serves readers better than a larger one with too many choices. ## Overview - In Atloria, content structure starts with the page tree in your project workspace. - Top-level pages should represent major topic areas, while child pages should handle narrower tasks or subtopics. - Clear page titles, consistent slugs, and a logical reading order make the sidebar easier to scan. - Visibility and publish status affect whether pages appear in reader-facing navigation. - Internal links help readers move between overview pages, task guides, and supporting reference content. - Team reviews are useful for spotting duplicate topics, misplaced pages, and unclear ownership. - Common navigation issues are usually fixed by adjusting placement, naming, visibility, or page order rather than creating more pages. If you need to revisit how page readiness affects what readers can see, refer back to [Managing Project Content from Drafts to Published Pages](doc:managing-project-content-from-drafts-to-published-pages). The next document in this workflow is [Collaborating on Document Changes and Page Quality](doc:collaborating-on-document-changes-and-page-quality). ## Prerequisites - You should be able to open the correct project workspace in Atloria. - Your project should already contain multiple documentation pages so you can review and reorganize the hierarchy. - You should be familiar with creating and editing pages from [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages). - It helps to understand content review and page organization from [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content). - You should already know how draft and published states affect content availability from [Managing Project Content from Drafts to Published Pages](doc:managing-project-content-from-drafts-to-published-pages). - If your team shares responsibility for documentation branches, confirm who can update page placement, titles, and navigation decisions before making large structural changes. ## Opening a Versioned Documentation Page from a Public URL When you open public documentation in Atloria, you do not need to sign in first. A public page opens directly in the browser and is designed for reading, browsing, and moving between published releases. Unlike the private workspace, there is no project dashboard, editing toolbar, or publishing screen in this view. You arrive straight on the documentation page itself. A versioned public link usually includes a release-specific part in the web address. That version segment is what tells you which release you are reading. For example, one public link may open the current documentation set, while another includes a version name in the path and opens an older published release. Even if the page title is the same, the version segment in the address helps confirm whether you are on the latest documentation or a frozen historical copy. As soon as the page loads, look for the visible version cues in the page layout. In Atloria, this may appear as a version label in the top area of the page, a release badge near the page title, or a version switcher in the header. These are the quickest signs that you are reading a specific published release rather than a general landing page. Because this is a public reading experience, the screen focuses on navigation controls such as the header, sidebar, breadcrumbs, and version selector. You can move through pages, open related topics, and switch releases, but you will not see editing actions such as creating pages, changing content, or publishing updates. [SCREENSHOT: Public documentation page showing the page title, version label, and version switcher in the header] ## Recognizing Which Release You Are Reading The most reliable way to confirm the active release is to check the version information shown in the page layout before you start reading. In Atloria, the active release may appear in several places at once: the top navigation area, a breadcrumb trail, a badge near the page title, or the version switcher itself. If more than one of these is visible, use them together. That makes it easier to avoid confusing an older release with the current one. This matters most when two releases contain a page with the same title. For example, a page called **Getting Started** can exist in both the current documentation set and an archived release. The title alone does not tell you which one you are viewing. Instead, compare: - The version label shown in the header or near the title - The version segment in the web address - Any release badge or archived notice on the page When you are on the current documentation set, Atloria may show cues that indicate you are reading the latest published version rather than a fixed older release. That cue might appear in the version switcher, in the top page area, or through the absence of an archived-version notice. If you move into an older release, the page layout should continue to show that older release name as you browse from page to page. That persistent version context is important. As you use the sidebar, breadcrumbs, or in-page links, keep an eye on the release label. If the label stays the same, you are still inside the same documentation set. If it changes, you have moved to a different release and should recheck the page before relying on the content. For a broader explanation of public page context before focusing on releases, see [Understanding Public Document Views and Version Context](doc:understanding-public-document-views-and-version-context). ## Moving Between Current and Older Documentation Versions To move between releases in Atloria, use the version switcher or release dropdown shown in the public page header. This is the safest way to change versions because it keeps you inside the published navigation instead of forcing you to guess the correct web address. 1. Open the public documentation page you want to read. 2. Find the version switcher or release dropdown in the top area of the page. 3. Click the current release name to open the list of available versions. 4. Select the release you want to view. If the same page exists in both releases, Atloria should keep you on the equivalent page after the switch. The page title may stay the same, but the version label and the web address will update to match the release you selected. This is useful when you want to compare how a single topic changed over time without manually searching for it again. Sometimes the selected release does not include that page. In that case, Atloria may take you to the release home page, the nearest available section, or show a message that the page is not available in that version. If that happens, use the sidebar or breadcrumbs inside that release to find the closest matching page. To return to the latest documentation, open the version switcher again and choose the current release. If Atloria shows a latest-version link or a clearly labeled current release option in the page header, use that instead of editing the web address by hand. [SCREENSHOT: Version switcher open in the public header with current and older releases listed] ## Comparing the Reading Experience Across Releases Reading across releases in Atloria often feels familiar, but the structure can change from one version to another. The sidebar may contain different sections, page names may move to new locations, and the order of topics can shift as documentation evolves. When you open an archived release, expect the navigation menu and page hierarchy to reflect how the documentation looked at the time that release was published. Older releases may also include extra visual cues that affect how you read. For example, an archived version can show a release-specific notice, an outdated-content warning, or a message that a newer release is available. These notices help you understand that the content is still available for reference but may no longer describe the recommended workflow. Version context should stay consistent while you browse. If you click a sidebar item, a breadcrumb link, or a cross-reference inside the page, Atloria should keep you inside the same selected release whenever that content exists there. Search results and internal links should behave the same way. If you started in an older release, the destination page should continue to show that release label so you do not accidentally jump to the latest content without noticing. A practical way to compare releases is to open the latest documentation in one browser tab and an older release in another. That lets you check differences in wording, page placement, and release notices side by side. If you are researching historical behavior or validating instructions from an older rollout, this approach is usually faster than switching back and forth repeatedly in one tab. ## Understanding What Documentation Managers Control in Public Version Views What you see in a public versioned page is shaped by publishing choices made by the people managing documentation in Atloria. Readers do not control which releases appear in the version switcher. That list depends on which releases were published publicly and which one was marked as the current release. From a reader’s point of view, the visible clues are straightforward: - The release names shown in the version switcher - Which release appears as the current or latest option - Whether an older release shows archived or outdated messaging - Which pages are available inside each release Those cues come from decisions made before the public documentation was shared. If a page was included when a release was published, readers can open it in that release. If it was not included, it will not appear there later just because the page exists in a newer release. This is why one version may contain a page that another version does not. Documentation managers also shape how easy public navigation feels by choosing clear release names and by deciding how archived releases are labeled. A well-named release in the version switcher makes it much easier for readers to choose the right documentation set without opening several pages first. The boundary is simple: public readers can browse, read, and switch between the releases that are available to them, but they cannot change release labels, mark a release as current, add missing pages, or publish updates from the public view. If you manage documentation and want to understand the publishing side behind these reader-visible results, see [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options). ## Fixing Confusing Version Navigation and Missing Pages Version confusion usually happens when the page title looks correct but the release is not. In Atloria, start by checking the version badge, release label, or version switcher in the page header. Do not rely on the page title alone. The same title can appear in multiple releases. If you think you are on the wrong release: - Check the version label in the top page area - Open the version switcher and choose the release you actually want - Confirm that the web address updates after the switch If a bookmarked link opens an outdated page: - Look at the version segment in the web address - Use the version switcher to move to the current release - If Atloria shows a latest-version link in the page header, use that to jump back to the newest published set If the release you selected does not show the page you expected: - The page may not have existed when that release was published - Open the release home page if Atloria sends you there automatically - Use the sidebar, breadcrumbs, or section navigation to find the nearest equivalent page in that release If links or search results seem to jump between releases unexpectedly: - Check the version label before and after you open the destination page - Confirm whether the destination stayed in the same release - If not, return to the version switcher and reselect the release you want before continuing [SCREENSHOT: Public documentation page with an archived release badge and version switcher highlighted] When version-related navigation still feels inconsistent, compare the current page’s release label, web address, and sidebar position together. Those three cues usually reveal whether you are on the correct page in the correct release. ## Overview Versioned public documentation in Atloria lets you read published content by release without entering the private workspace. The key idea is simple: the page title tells you what topic you are reading, while the version label and web address tell you which release that topic belongs to. You need both pieces of information to read confidently. As you move through public documentation, watch for these reader-facing elements: - A version switcher or release dropdown in the page header - A release label or badge near the page title - Breadcrumbs and sidebar navigation that stay inside the selected release - Archived or outdated notices on older documentation sets The current release is usually the easiest place to start when you want the most up-to-date instructions. Older releases are useful when you need to confirm historical behavior, review past wording, or match documentation to an earlier rollout. Atloria supports both reading styles by keeping public pages read-only and centered on browsing rather than editing. This guide focused on how to identify version context, move between releases, and handle common problems such as outdated bookmarks or missing pages. If you need background on how public page context appears before switching releases, return to [Understanding Public Document Views and Version Context](doc:understanding-public-document-views-and-version-context). The next topic expands from version awareness into broader discovery patterns across public documentation: [Understanding Public Navigation and Content Discovery](doc:understanding-public-navigation-and-content-discovery). ## Prerequisites Before using versioned public documentation in Atloria, make sure you have the basics needed to follow release-specific pages without confusion: - A public documentation link that opens in your browser - Access to a published documentation set that includes more than one release, if you want to compare versions - Familiarity with basic public navigation elements such as the header, sidebar, breadcrumbs, and page links - A general understanding that public documentation is read-only and does not include editing or publishing actions It also helps if you already know how Atloria presents public page context. If you have not reviewed that yet, read [Understanding Public Document Views and Version Context](doc:understanding-public-document-views-and-version-context) first. You do not need: - An Atloria sign-in for public reading - Admin access - Project editing permissions - Access to the private workspace When reading across releases, keep these simple habits in mind: - Check the version label before trusting the content - Use the version switcher instead of changing the web address manually - Expect some pages or navigation sections to differ between releases - Use separate browser tabs when comparing the latest and archived documentation side by side These basics are enough to follow the workflows in this guide and move through public versioned documentation with fewer mistakes. ## Confirming you can review the correct public audience pages Before you start checking pages, make sure you are looking at the same public documentation experience your readers will see. In Atloria, that usually means opening the public documentation site in its preview or published view rather than staying inside the editing workspace. If you are still deciding which pages belong to each audience, review your plan first in [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences) and compare it with the public page structure you already reviewed in [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation). Look for the visible cues that tell you which audience view you are reviewing. Depending on how your documentation is organized, this may be an audience selector, a dedicated audience landing page, or a navigation section that groups pages for a specific reader type. Stay in one audience view at a time so you do not mix pages from different reader journeys. You should also confirm the release context before checking anything else. Use the version switcher, release label, or any version name shown in the page header to make sure you are reviewing the intended release. If the page URL includes a version segment, compare that with the release you expect to launch. Next, prepare a simple page checklist from what is already visible in the public navigation: - Top navigation items - Sidebar sections - Audience landing pages - Child pages under each section - Any related pages linked from the main audience entry point This gives you a clear list of what should be publicly available. As you review, compare each visible page in the menu or sidebar against that expected list so you can quickly spot missing pages, extra pages, or pages showing up under the wrong audience. [SCREENSHOT: public documentation page showing audience selector, sidebar, and visible version label] ## Checking navigation paths for each audience Once you have the correct audience and version selected, walk through the public navigation exactly as a reader would. Start from the audience landing page or the main public home page, then open the navigation menu and sidebar. Your goal is to confirm that each audience page appears in the right place and leads to the correct destination. 1. Open the audience’s main section in the public navigation. Check that the expected pages appear under the correct heading and in the right order. If a page belongs under a parent section, make sure it is nested there instead of appearing as a top-level item. 2. Select each page link one by one. On every page, compare the page title with the navigation label you clicked. If Atloria shows a breadcrumb trail, confirm it matches the path you expected through the site structure. 3. Watch the page URL as each page opens. The URL should match the intended audience page and stay within the correct public documentation area. If the URL changes to an unexpected section, you may be opening the wrong page or the wrong version. 4. Check movement between related pages. Use previous and next links, related content blocks, and links inside the page body to make sure readers can continue through the audience journey without getting stuck. 5. Repeat the same review for every audience section included in the release. Pay close attention to nested content. A child page may technically open, but still be misplaced in the sidebar or grouped under the wrong parent. That creates confusion for readers even when the page itself is published correctly. Helpful signs to verify on each page: - Navigation label - Page title - Breadcrumb path - URL - Previous/next navigation - Related content links [SCREENSHOT: public page with sidebar navigation, breadcrumb trail, and page title highlighted] ## Verifying page availability and public access After navigation looks correct, test whether each page is truly available to public readers. A page can appear in the menu but still fail when opened directly, especially if it was not fully published or if linked files are not available outside internal workspaces. 1. Open each target page from the public navigation and confirm it loads normally without a sign-in screen, restricted-access message, or internal-only prompt. 2. Copy the page URL and open it directly in a fresh browser tab. This helps you confirm the page works as a public destination, not only as a page you reached while already browsing. 3. Check that the page shows the published content rather than a missing-page message, unpublished notice, or empty placeholder. 4. Test pages that should stay private by trying their direct links if you have them. They should not appear in public navigation, and they should not open as public pages in the release you are reviewing. 5. Open linked assets on the page, including screenshots, downloadable files, and embedded media. Make sure they load for a public reader and are not broken or blocked. If you want a cleaner access check, open the public page in a browser window where you are not signed in to Atloria. That helps you catch cases where your own account access hides a publishing problem. Look for these warning signs during the check: - A sign-in page appears - The page shows a 404 or missing-page message - A draft or unpublished notice is visible - Images do not load - Download links fail - Embedded media areas appear blank When you find a problem, note the exact page title and URL so the publishing or content team can correct the right page quickly. [SCREENSHOT: public page opened directly by URL with visible published content and working image] ## Reviewing version context and release accuracy A public page can look correct and still belong to the wrong release. Before launch, verify that every audience page is shown in the intended version context and that readers will not be pushed into older or future documentation by mistake. 1. On each page, look for the version switcher, release badge, or version label in the header. Confirm it matches the release you are preparing to launch. 2. Open the same page in another available version, if Atloria shows one. Compare the content to make sure audience-specific changes appear only in the release where they were meant to go live. 3. Check the page URL for version-related wording or structure that helps identify the release. The URL should match the version you selected in the page header. 4. Follow links from the page to nearby content. Make sure those links stay inside the same release instead of sending readers to an older version or a future branch. 5. If a page is likely to be shared externally, open it from its direct URL again and confirm it lands in the correct release view without forcing readers to switch versions manually. This review is especially important when a page exists in more than one release. A reader may arrive from search, a shared link, or a bookmarked page. If the visible version label and the page content do not match, they may read outdated instructions without realizing it. Check for consistency between these visible elements: | What to check | What should match | |---|---| | Version switcher | The release you are reviewing | | Release label or badge | The same release name shown elsewhere on the page | | URL | The expected version context | | Cross-page links | Other pages in the same release | | Shared direct link | Opens the intended public version | If you spot unreleased content in an older version, or outdated content in the launch version, stop and correct that before sharing the public site. ## Inspecting the reader-facing presentation before release Once access and versioning are confirmed, review the page as a reader would. This is where you catch issues that make a page feel unfinished even though it technically works. Focus on what is visible on the page: header details, content formatting, labels, and how the page behaves on different screen sizes. 1. Start at the top of the page. Check the title, summary text, and any audience label or callout shown near the header. These should clearly tell readers what the page is for and who it is meant to help. 2. Scan the body content from top to bottom. Look at headings, lists, tables, callout boxes, and screenshots. Make sure spacing is consistent and the page is easy to read without awkward breaks or crowded sections. 3. Watch for internal-only content that should never appear publicly. Remove or flag anything that looks like an editorial note, draft wording, review comment, placeholder text, or unfinished instruction. 4. Open the page on a smaller screen or narrow browser window. Confirm the navigation menu still works, the content width remains readable, and images or embedded media do not overflow the page. 5. Test any visible buttons or links inside callouts and content blocks to make sure they still fit the public reading flow. Common presentation issues include mismatched headings, missing summaries, oversized tables, screenshots that do not scale well, and notes that were meant only for internal review. These are easy to miss when you focus only on publishing status. Use this quick visual review list: - Page title is clear - Summary text matches the page topic - Audience label is correct if shown - Headings are in logical order - Tables and lists are readable - Callouts look complete - No draft badges or internal comments are visible - Desktop and mobile layouts both work [SCREENSHOT: published documentation page on desktop with title, summary, callout, and formatted content blocks] ## Fixing common issues found during launch review Most launch-review problems fall into a few repeat patterns. When you find one, use the visible page structure in Atloria to narrow down the cause before you publish again. Focus on the page’s audience placement, version selection, and public visibility rather than rechecking everything at once. 1. If a navigation item is missing or appears in the wrong section, return to the page’s audience setup and navigation placement. Confirm the page is assigned to the correct audience, grouped under the right parent section, and ordered correctly in the public sidebar or menu. 2. If a page opens in the wrong release, check the selected version in the version switcher first. Then review whether the page is actually included in the release you are launching. A page may exist publicly but still be tied to another version. 3. If public pages show draft wording or internal notes, open the published page and compare it with the latest approved content. Remove editorial comments, unfinished callouts, and placeholder text, then confirm the public view reflects the approved version. 4. If links or assets fail, test them again without relying on your signed-in session. Broken screenshots, files, or media usually become obvious when you open the page as a public reader. A simple issue log can help you move faster during final review: | Issue found | What to check in Atloria | |---|---| | Page missing from navigation | Audience assignment, parent section, page order | | Page in wrong section | Navigation grouping and audience placement | | Wrong release shown | Version switcher and release selection | | Draft content visible | Published content and final approved page | | Broken image or file | Public asset availability and direct link behavior | If several issues appear across the same audience path, recheck the full audience journey from the landing page instead of fixing pages one at a time. That usually reveals a shared setup problem more quickly. ## Overview This review is the final public-facing check for audience pages before launch. In Atloria, you are not editing content here—you are validating what readers will actually experience on the public documentation site. That means checking the audience path, confirming the correct release is visible, opening pages directly by URL, and making sure the published presentation looks complete. This guide focuses on launch review for public audience pages only. It assumes you have already planned the audience experience and already know how to read audience-tailored content in the public site. If you need to revisit that earlier reading flow, see [Reading Audience Tailored Documentation](doc:reading-audience-tailored-documentation). During this review, you should confirm four things: - The right audience pages are included in the release - Readers can reach them through public navigation - Each page opens publicly in the correct version - The published page looks clean and ready for external readers This is not the same as a full content rewrite or a project setup task. You are checking the live or preview reading experience from the outside. The most useful mindset is to behave like a first-time reader: use the menu, follow links, switch versions, and open pages directly. A strong launch review in Atloria helps you catch issues such as: - Missing audience pages - Incorrect page grouping - Wrong-version links - Unpublished assets - Draft notes left on public pages - Mobile layout problems If you work through each section in order, you will have a reliable final check before making audience-specific documentation broadly available. ## Prerequisites Before you begin this launch review in Atloria, make sure you have enough context to recognize what should be public and what should stay hidden. You do not need deep administrative knowledge, but you do need access to the public documentation experience you are reviewing and a clear idea of the release scope. Have these items ready: - Access to the public documentation site in preview or published form - The audience or audiences included in the upcoming release - The expected page list for each audience, based on the public navigation or launch plan - The release or version name you are supposed to validate - At least one way to test pages as a public reader, such as opening links directly in a separate browser tab or unsigned session It also helps if you are already familiar with: - Public navigation in Atloria - Audience-specific page groupings - The visible version switcher or release label - How published pages differ from internal editing views If you have not yet reviewed how audience content is structured in public documentation, read [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience) and [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation) before continuing. You may also want a simple review list while you work, such as: - Audience name - Page title - Expected navigation location - Direct URL result - Version shown - Issues found After you finish this launch review, continue with [Reading Audience Specific Documentation Views](doc:reading-audience-specific-documentation-views) to examine how readers move through audience-focused documentation after publication. ## Choosing Where Captured Screenshots Are Stored After you capture a screenshot in Atloria, move it into your team’s agreed storage location right away. Do not leave working files in **Downloads**, on your **Desktop**, or inside a temporary screen capture folder, because those locations make screenshots hard to find later and easy to lose during doc updates. If your team is still capturing images, follow the capture workflow from [Capturing Website Screenshots for Documentation](doc:capturing-website-screenshots-for-documentation), then store the image in the shared location your documentation team uses for active work. Most teams use one of these storage approaches: - **Shared cloud folder** Best when writers, reviewers, and release owners all need quick access. This works well for folders arranged by product, version, and document set. - **Repository image folder** Best when screenshots are managed alongside documentation files for a specific project or version. This is useful when images are tightly tied to one documentation workspace. - **Asset library used by the docs team** Best when your team needs searchable metadata, approval tracking, and a reusable screenshot library across multiple projects. Choose one **canonical location** for final screenshots and use it consistently. A clear path structure helps everyone store files the same way, such as: - `/Product-Name/2026.1/User-Guide/` - `/Admin/Users/2026.1/` - `/Release-Notes/2026-Q2/` - `/Project-Docs/Approved-Screenshots/` [SCREENSHOT: shared screenshot library showing folders by product, version, and document type] Set permissions before your library grows. In practice, teams usually separate access like this: | Team role | Typical access | |---|---| | Technical Writers | Upload, rename, move files in active folders | | Documentation Managers | Approve folder structure, rename standards, archive older files | | Reviewers | View and comment, but do not delete or reorganize | | Release owners | Collect approved screenshots for version and release work | If more than one person can rename, move, or delete approved images, agree on that process first. That prevents one writer from replacing a screenshot another writer already used in a published guide. ## Creating a Folder Structure Authors Can Reuse A reusable screenshot library starts with a folder structure that matches how your team writes in Atloria. Keep current work, release work, and older screenshots separate so authors do not accidentally insert outdated images into a document. If your folders are flat or inconsistent, searching becomes slower every time you update a guide or prepare a release. Start with a few top-level folders that clearly separate active and historical work: - **Active-Docs** - **Release-Screenshots** - **Archive** - **Deprecated-UI** Inside those folders, organize screenshots by the same product areas and workflows your team documents in Atloria. For example: - `Active-Docs/Admin/Users/` - `Active-Docs/Billing/Invoices/` - `Active-Docs/Projects/Onboarding/` - `Release-Screenshots/2026.1/` - `Archive/2025.4/` - `Deprecated-UI/Admin/Old-Navigation/` Then add one more level to distinguish screenshot status: - **Source-Captures** for original images - **Edited** for cropped or annotated working files - **Approved** for publication-ready images That gives you a structure like: - `Active-Docs/Admin/Users/Source-Captures/` - `Active-Docs/Admin/Users/Edited/` - `Active-Docs/Admin/Users/Approved/` - `Release-Screenshots/2026.1/Approved/` This separation matters. A raw image from a browser session should not sit beside the final image used in a guide, especially when multiple writers are updating the same Atloria project. When someone opens the **Approved** folder, they should only see screenshots that are ready to place into documentation or release notes. [SCREENSHOT: folder tree with Active-Docs, Release-Screenshots, Archive, and Approved folders] Use the same archive pattern every time. For example, move older screenshots into `Archive/2025.4/` or `Deprecated-UI/` instead of leaving them mixed into active folders. That keeps historical screenshots available for comparison without cluttering current searches when you are updating live documentation. ## Naming Screenshot Files So They Are Easy to Find A good filename should tell another writer exactly what the screenshot shows before they open it. In Atloria documentation work, filenames are most useful when they follow a stable pattern built from the screen area, the task, the screen state, and the version only when needed. That makes it much easier to search, sort, and reuse screenshots across projects and releases. A practical naming format looks like this: `product-area_workflow_screen-state_version.png` Examples: - `admin_users_list_2026-1.png` - `billing_create-invoice_draft_2026-1.png` - `projects_onboarding_repository-connected.png` - `documents_editor_approval-dialog_2026-1.png` Use names that reflect what a user actually sees in Atloria, such as: - page name - dialog name - tab label - status value - workflow step Avoid generic filenames like: - `screenshot-12.png` - `image-final.png` - `final2.png` - `latest.png` Those names become meaningless as soon as a second version exists. If the screen has not changed between releases, you may not need a version marker at all. Add the version only when it helps distinguish one interface state from another. For example, if the **Users & Permissions** screen changed in a new release, include `2026-1` or `2026-2` so both files can exist without confusion. Add extra tags only when your team maintains multiple variants of the same screenshot. Common examples include: - `_fr-FR` for language variants - `_dark-mode` for theme variants - `_macos` or `_windows` for platform-specific captures [SCREENSHOT: list of screenshot files showing clear, searchable names] Keep the order of filename parts consistent across the whole library. If one writer starts with the product area and another starts with the version, search results become messy. A shared naming pattern lets Atloria authors quickly find the right image when updating a page, reviewing a version, or collecting screenshots for release preparation. ## Tagging and Tracking Screenshots During Authoring Folders and filenames help, but they are not enough once your team starts reusing screenshots across multiple Atloria guides. To keep images traceable during writing and review, record a small set of metadata for every screenshot. You can do this in your asset library, a shared tracking sheet, or the fields available in your documentation workflow. Track the details that help authors decide whether a screenshot is safe to use: | Field | What to record | |---|---| | Document name | The guide, release note, or page where the screenshot belongs | | Topic ID or section | The exact article, heading, or content section | | Product version | The release or version the screenshot matches | | Owner | The writer or manager responsible for updates | | Approval status | Raw, annotated, approved, or obsolete | | Last verified date | When someone last checked the screenshot against the current UI | | UI build number | The build or release reference used during verification | This tracking makes a big difference during authoring. If a writer opens a screenshot and sees it marked **Raw**, they know it still needs cleanup. If it is marked **Approved**, they can place it into a guide with more confidence. If it is marked **Obsolete**, it should stay out of current work even if the image still looks familiar. Link each screenshot to where it is used. For example, connect it to: - a user guide page - a specific section heading - a release-preparation checklist item - a feature update note [SCREENSHOT: screenshot tracking view with status, owner, version, and linked document fields] Review details are especially useful before publication. A Documentation Manager can sort by **Last verified date** or **Approval status** to find screenshots that need refresh. If a screenshot was verified against an older UI build, it can be flagged for recapture before the next version is approved in Atloria. ## Finding the Right Screenshot When Updating Docs or Preparing a Release When you update documentation in Atloria, start by searching the existing screenshot library before capturing anything new. Many workflows repeat across guides, release notes, and version updates, so the screenshot you need may already exist in an approved folder. Reusing an approved image saves time and keeps visual language consistent across your documentation set. Use three search methods together: 1. **Search by filename pattern** Look for terms such as `admin_users`, `projects_onboarding`, or `documents_editor`. 2. **Browse by folder path** Open the product area and workflow folders where that screenshot would normally live. 3. **Filter by metadata** Narrow results by version, owner, approval status, or document name. If your library includes archived material, filter that out first. When you are updating a current guide, you usually want to exclude anything in **Archive**, **Deprecated-UI**, or items marked **Obsolete**. That keeps older screenshots from appearing beside current approved assets. Before taking a new screenshot, check whether the workflow already exists in the library. This is especially important for repeated paths such as: - signing in - opening project settings - reviewing version details - using the **Users & Permissions** area - moving through common admin screens For release work, gather screenshots into a version-specific set. Search for all images tagged to the target release, changed features, or release notes deliverables. That gives you a clean collection for review without digging through unrelated screenshots from earlier work. [SCREENSHOT: search results filtered by product area, version, and approval status] This approach is especially helpful when one Atloria feature appears in several documents. Instead of recapturing the same screen for every guide, you can confirm whether an approved image already exists and reuse it wherever the UI and version still match. ## Fixing Common Organization Problems in Screenshot Libraries Even a well-planned library gets messy over time. Writers save duplicate files, approved images end up beside raw captures, and older screenshots stay in active folders long after the interface changes. When that happens, fix the library in place instead of working around the mess. A few cleanup habits make Atloria screenshot searches much more reliable. Start with duplicate files. Compare screenshots using: - filename pattern - modified date - version marker - approval status If two files show the same screen, keep one **canonical** image in the correct folder and remove or archive the extra copy. In most cases, the approved and most recently verified image should remain. If both are still in use, rename them clearly so the difference is obvious. Next, fix screenshots with missing context. If a file is already circulating in your team but has a vague name, rename it and add the missing details in your tracking fields. At minimum, backfill: - topic or document name - product version - owner - approval status Mixed raw and final assets are another common problem. Move files into the correct folders: - raw browser captures into **Source-Captures** - cropped or annotated work into **Edited** - publication-ready images into **Approved** Then update any links in your authoring workflow so writers stop pulling from the wrong location. [SCREENSHOT: before-and-after screenshot library cleanup with duplicate and approved folders] Before a release, look for outdated screenshots by filtering for old version tags or stale verification dates. Assign each outdated image to an owner for recapture or review. This is much faster than waiting until final release checks to discover that a guide still shows an older Atloria screen. ## Overview This guide focuses on what happens after you capture a screenshot for Atloria documentation. The goal is to make every image easy to store, identify, review, and reuse across guides, release notes, and version updates. If your team already knows how to capture screenshots, this is the step where those images become part of a reliable documentation workflow instead of scattered files saved in personal folders. You will use this guide when you need to: - move screenshots out of temporary local folders - place them into a shared team library - organize them by product area, workflow, and release - name files so other writers can find them - track approval and verification details - clean up duplicate or outdated images before publication This topic builds directly on [Capturing Website Screenshots for Documentation](doc:capturing-website-screenshots-for-documentation). That earlier guide covers how to capture the right screen. Here, the focus shifts to what your team does next so those captures remain useful during authoring and release preparation. In Atloria, screenshot organization matters because the same feature can appear in multiple places: project guides, admin documentation, release notes, and version review work. Without a clear storage location and naming pattern, writers often recapture screens that already exist or accidentally use outdated images. A shared structure avoids that problem and helps Documentation Managers review visual assets faster. [SCREENSHOT: organized screenshot library used for active docs and release preparation] By the end of this guide, you should have a practical way to store screenshots in one canonical location, separate raw images from approved ones, and find the right screenshot quickly when you update documentation. The next document, [Capturing and Saving Screenshots for Documentation](doc:capturing-and-saving-screenshots-for-documentation), continues that workflow by connecting capture habits and storage habits into one repeatable process. ## Prerequisites Before you organize screenshots, make sure you already have the basics in place for your Atloria documentation workflow. This guide assumes you are not starting from zero. You should already know how your team captures screenshots and which documentation areas those screenshots support. Have these items ready: - Access to the shared location your team uses for screenshot storage, such as a cloud folder, repository image folder, or asset library - Permission to upload files into active documentation folders - A set of recently captured screenshots that need to be sorted, renamed, or approved - A clear understanding of which Atloria project, guide, or release the screenshots belong to - Your team’s current naming and approval rules, if they already exist It also helps if you can identify the Atloria screen shown in each image. For example, you should know whether the screenshot belongs to **Users & Permissions**, **Projects**, **Documents**, **Analytics & Insights**, or **Security & Audit**. That makes it much easier to place the file into the correct folder and give it a useful name. If you are working with release screenshots, gather any version details your team uses during review, such as the release number and the last verified date. If you are cleaning up an existing library, be prepared to compare older files and decide which image is the approved one. You may also want a shared tracking place for screenshot details, especially if several writers work in the same Atloria workspace. That can be an asset library view or a team-maintained tracking sheet with fields for owner, version, and approval status. [SCREENSHOT: screenshot library or tracking sheet prepared for organizing captured images] If you still need help with the capture step itself, return to [Capturing Website Screenshots for Documentation](doc:capturing-website-screenshots-for-documentation) before organizing your files. ## Recognizing What Public Page You Are Viewing When you open a public documentation page in **Atloria**, start by checking the context around the page content before you focus on the article itself. The **document title** tells you which page you are reading, but it does not tell you whether you are in the right **project**, **version**, or **audience view**. Those details usually appear in the surrounding page header, navigation area, or version controls. Look for these cues first: - The **project name** shown in the public documentation header or navigation - Any **project-specific branding**, such as a distinct site name or visual identity - The **version selector** or visible version label in the page header - Any **audience indicator** that shows whether you are viewing a general public page or an audience-specific variation These details matter because the same page title can appear in more than one place. For example, a page called **Getting Started** may exist in multiple projects, or it may exist in several releases of the same project. If you only look at the title, it is easy to assume you are on the correct page when you are actually reading a different release or a different documentation set. A good habit is to read the page in this order: - **Project context**: Which documentation set am I in? - **Version context**: Which release am I viewing? - **Audience context**: Is this the public view or a targeted view? - **Document title**: Is this the page I meant to open? [SCREENSHOT: Public documentation page showing the project name, document title, and version selector in the header] If you need help finding the page itself, use the navigation techniques from [Finding and Reading Content in Published Documentation](doc:finding-and-reading-content-in-published-documentation). This guide focuses on understanding the context around the page once you have already opened it. ## Understanding How Project, Version, and Audience Shape the Page A public page in **Atloria** is shaped by three layers of context working together: - **Project** - **Version** - **Audience** The **project** decides which documentation set you are reading. If your team manages more than one published project, each one can have its own public pages, structure, and branding. Even when two projects contain similarly named pages, they are still separate public documentation experiences. The **version** decides which release of that documentation is shown. When a public page includes a **version selector**, changing it can keep you on the same page name or path while swapping the visible content to another release. That means the page title may stay familiar, but the instructions, screenshots, or wording can change because you are now reading a different published revision. The **audience** decides whether the page shows the general public content or an audience-targeted variation. If your team uses audience-specific publishing, some sections may appear only for certain readers, while other sections may be hidden or replaced. This is why one reader may report seeing a warning, note, or setup instruction that another reader cannot find. Keep these effects in mind: - **Same project + different version** can show older or newer instructions - **Same project + same version + different audience** can show different sections or wording - **Different project + same page title** can show a completely different documentation page This combination explains why two people can open what seems like the “same” page and still see different results. Before comparing content, confirm that both people are looking at the same **project name**, the same **version label**, and the same **audience context**. [SCREENSHOT: Version selector open on a public page, with the same page shown across different release labels] ## Checking Why a Public Page Looks Different Than Expected If a public page in **Atloria** looks outdated, incomplete, or unfamiliar, check the visible context before assuming the content is wrong. In most cases, the difference comes from the selected **version**, the active **audience view**, or the fact that the page belongs to a different **project** than expected. Start with the **version label** in the page header or version selector. If the page text does not match the release you expected, you may be reading an earlier or later version of the document. This is especially common when a page title stays the same across releases, but the instructions inside the page have changed. Next, review any **audience indicator** shown on the page. Audience-targeted documentation can hide sections, swap content blocks, or present alternate wording. If a reader says a section is missing, the page may still be correct for the current audience context. Then confirm the **project context**. If your organization publishes multiple documentation sets, a link or search result may have opened a similarly named page in the wrong project. The page title alone will not always reveal that mistake, so compare the header, branding, and navigation area. Use this quick comparison: - **Outdated wording**: check the active **version** - **Missing section**: check the active **audience** - **Unexpected navigation or branding**: check the **project** - **Correct title but wrong content**: compare all three together When reviewing a confusing page, rely on the combination of: - **Page title** - **Project name** - **Version selector** - **Audience context** [SCREENSHOT: Public page header with title, project indicator, and version label highlighted] These cues usually explain why a page looks different without needing to inspect anything behind the scenes. ## Managing Public Context as a Documentation Team For documentation teams, public context is something to review actively, not something to assume is correct. In **Atloria**, a page can look perfectly polished while still being published from the wrong **project**, shown under the wrong **version label**, or displayed with the wrong **audience-targeted content**. When reviewing a public documentation set, first confirm that the correct **project** is the one being presented to readers. Check the public header, project naming, and navigation structure to make sure the published docs set matches the team’s intended project. This is especially important when teams manage multiple projects with similar page names. Then review the **version labels** visible to readers. The labels shown on public pages should match the release naming your team uses internally and in customer communication. If a release is known by one name internally but appears differently in the public selector, readers may choose the wrong version without realizing it. Audience targeting also needs a public review. Check that the current **audience configuration** is exposing the correct content to public readers and not showing a variant meant for a different audience. When audience rules change, revisit affected pages and confirm that the visible sections still match the intended reader experience. A practical review workflow usually includes: - Opening key public pages after each **version update** - Checking the **version selector** on those pages - Reviewing audience-targeted pages in the expected **audience view** - Confirming the **project name** and public navigation are still correct - Comparing important pages side by side when teams report mismatches [SCREENSHOT: Public documentation review session with version selector and page navigation visible] If your team also manages release readiness, pair this review with the checks described in [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options). ## Using Public Context Cues to Answer Reader Questions When readers report a problem with public documentation in **Atloria**, the fastest way to resolve it is to ask about the visible context on the page. Most support questions become much clearer once you know the **project**, **version**, and **audience view** the reader is using. If a reader says the instructions are outdated, ask them to check the **version shown in the page header** or the current selection in the **version selector**. Often, they are reading an older release while expecting the latest one. If the reader says a section is missing or the page feels incomplete, ask whether the page shows any **audience-specific context**. Audience-targeted content may hide blocks that are visible in another audience view. This is one of the most common reasons two readers describe the same page differently. If a link opens an unexpected page, compare the **project name** and surrounding navigation. A shared link, search result, or bookmarked page may lead to a document with the same title in a different public documentation set. When collecting details from a reader, ask for a screenshot that includes: - The **page title** - The **project name** or public header - The **version selector** or version label - Any visible **audience indicator** [SCREENSHOT: Example support screenshot showing title, project header, version selector, and audience context] Those four items usually provide enough information to identify the mismatch quickly. If the reader only shares the article text, you may miss the real cause of the issue. Encourage teams to compare context first, then content. That keeps support conversations focused and avoids unnecessary back-and-forth about wording that may actually be correct for a different release or audience. ## Fixing Common Public View Confusion Most public-view confusion in **Atloria** comes down to one of four mismatches: wrong **version**, wrong **audience**, wrong **project**, or a comparison between two pages that only look similar. The fix is usually simple once you identify which context is different. If the **wrong content is showing**, start with the **version selector**. Switch to the intended release before comparing any page text. A page can keep the same title while showing a different revision underneath, so always confirm the active version first. If **a section seems missing**, review the current **audience context**. Audience-targeted pages may exclude certain blocks from the public view or replace them with alternate content. This does not always mean the page is incomplete; it may simply be filtered for the current audience. If the **page looks correct but belongs to the wrong docs set**, check the **project name** and any project-specific navigation elements in the header. This often happens when multiple projects publish similar documentation structures. If **two people see different content on the same page**, compare these items side by side: - **Project name** - **Version label** - **Audience context** - **Page title** A useful troubleshooting pattern is: - Match the **project** first - Match the **version** second - Match the **audience** third - Compare the page content only after those three align [SCREENSHOT: Side-by-side comparison of two public pages showing different version labels or project headers] This approach helps you explain missing sections, unexpected wording, and inconsistent screenshots without guessing. In most cases, the page is behaving as published; the confusion comes from readers opening the page in different public contexts. ## Overview Public document views in **Atloria** are easier to understand when you treat every page as a combination of visible context, not just a standalone article. The page body matters, but the surrounding controls and labels tell you **why** that specific content is being shown. The main context cues to watch are: - **Project name** in the public header or navigation - **Version label** or **version selector** - **Audience context** when audience-targeted content is used - **Document title** for the page itself These cues work together. The **project** tells you which documentation set you are in. The **version** tells you which release of that documentation you are reading. The **audience** tells you whether the page is showing general public content or a targeted variation. The **document title** tells you which article is open inside that context. This is why public pages can feel inconsistent if you only compare titles. Two pages with the same name may belong to different projects. One page may be from an older release. Another may be showing content for a different audience. Once you check the visible context, those differences usually make sense. Keep these points in mind while reading or reviewing public docs: - Do not rely on the **page title** alone - Check the **version selector** before judging whether content is outdated - Review **audience context** when sections appear missing - Confirm the **project header** when a page seems to belong to the wrong docs set For browsing help, refer back to [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) and [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page). The next topic is [Reading Versioned Documentation in Public Views](doc:reading-versioned-documentation-in-public-views). ## Prerequisites Before this topic is useful, you should already be comfortable opening published documentation pages and moving through public navigation in **Atloria**. This guide assumes you can already reach a public page and identify the main reading area, navigation links, and page header. You will get the most value from this guide if you can already do the following: - Open a published documentation page in **Atloria** - Recognize the **page title** and the surrounding public navigation - Use public navigation to move between pages - Understand that one documentation set may contain multiple releases - Know that some published content may be audience-specific If you have not covered those basics yet, read these first: - [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) - [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content) - [Finding and Reading Content in Published Documentation](doc:finding-and-reading-content-in-published-documentation) This guide does **not** require access to Atloria’s editing screens, project setup screens, or admin areas. It focuses on what readers and documentation reviewers can understand directly from the **public documentation view**. You only need access to a published page where the header, navigation, and version controls are visible. It also helps if you are reviewing a page that belongs to a project with more than one published version or with audience-targeted content, because those are the situations where context differences are easiest to spot. [SCREENSHOT: Public documentation page ready for review, with navigation and version controls visible] If you are ready to focus specifically on how release labels affect reading across published docs, continue with [Reading Versioned Documentation in Public Views](doc:reading-versioned-documentation-in-public-views). ## 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](doc: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. [SCREENSHOT: Version settings showing visibility mode and public navigation option] ## 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. [SCREENSHOT: Same version page opened in signed-in view and anonymous public view] ## 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. [SCREENSHOT: Version landing page with nested page links and a child page opened directly] ## 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. [SCREENSHOT: Public documentation menu compared with internal version list] ## 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](doc:validating-version-access-before-sharing-or-export). [SCREENSHOT: Anonymous browser window testing a version link] ## 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](doc: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](doc: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?” [SCREENSHOT: Project version screen alongside published documentation navigation] ## 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](doc: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. ## Setting Up the Project for Publishing 1. Open **Atloria** and go to your main workspace under **/app**, then open the project you plan to publish from the project list or dashboard. If you still need to create the project or finish onboarding, use [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release) for the full setup flow before continuing here. 2. In the project workspace, review the project details shown in the project administration and settings areas. Make sure the project name and description are complete and clear enough to appear in published documentation. If your team uses visibility settings, confirm the project is still set for draft work rather than public release. 3. Open the project membership or permissions area and confirm the people involved in the release have the right access. At minimum, make sure the people acting as project administrators, documentation managers, and technical writers can open the project, edit documentation, and participate in review. Reviewers should be able to access the version review process without having broader editing access than they need. 4. Check the current release scope before anyone generates a version. Look through the project’s documentation pages, related assets, and any linked content that will be part of this publication. This is the point to decide what belongs in the upcoming release and what should stay out until a later version. 5. Before moving on, confirm the project has the publishing pieces you need: - a version area where you can create a release candidate - a review workflow for approvals - public access or visibility controls for the final release [SCREENSHOT: Project workspace showing project details, members or permissions area, and draft visibility settings] ## Preparing Content Before You Generate a Release 1. Open the project’s documentation content area and review the full page list that will feed into the release. Work through the draft pages one by one and confirm the required content is present. Remove unfinished notes, temporary wording, and any visible placeholder text that should not appear in the public version. 2. Open each important page in the editor and use the page status indicators to check whether it is still treated as draft work or is ready for review. If a page is not ready, finish the edits before you generate a version. It is much easier to catch gaps in the draft workspace than after a release candidate has already been created. 3. Check the structure readers will see after publication. Review page titles, navigation labels, and where each page sits in the documentation tree. If a page belongs in a different section, move it now so the generated version reflects the correct public layout. 4. Confirm that linked content is complete. If a page points to another documentation page, image, screenshot, or related resource, open those items and make sure they are available. A release candidate can look incomplete if a linked page is missing or an expected asset does not appear. 5. Before leaving the content area, do a final release-readiness pass: - page names are consistent - navigation order makes sense - required screenshots and assets are present - internal links point to real pages - content intended for later release is not included by mistake If you need more detail on editing and organizing pages, use [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) and [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content). [SCREENSHOT: Documentation page list with statuses, navigation structure, and editor open on a draft page] ## Generating a Version from the Current Draft 1. In the project workspace, open the area used for documentation versions or release generation. Start a new version from the current draft so Atloria captures the content exactly as it exists at that moment. This creates a reviewable release candidate without requiring you to publish it immediately. 2. Complete the version form carefully. Enter the version name or identifier your team uses, then add any release label or notes that help reviewers understand what changed. Clear naming matters when you compare multiple candidates or need to return to an earlier build. 3. Start the generation process and watch the version status as it updates. The draft content should move into a generated version that can be reviewed separately from ongoing editing work. If Atloria shows a status indicator or timestamp, wait until generation finishes before opening the result. 4. Open the new version record and check the details shown there. Confirm that the version reflects the correct release candidate and that the date and time match the build you just created. If Atloria lists included pages or related assets in the version view, compare that list with your intended release scope. 5. Use the version record as your checkpoint before review begins: - the correct draft was used - the version label is easy to recognize - the generation completed successfully - the included content matches the planned release If your team works heavily with version states and comparisons, [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Generating New Documentation Versions](doc:generating-new-documentation-versions) go deeper into those screens. [SCREENSHOT: Version creation screen with version name, release notes, and generated status visible] ## Reviewing the Generated Version and Approving It for Release 1. Open the generated version preview and read it the way a real documentation reader would. Move through the navigation tree, open key pages, and confirm the content renders correctly. Pay close attention to headings, section order, screenshots, linked pages, and any assets that should load inside the version preview. 2. Start the review workflow from the version area. Assign the people responsible for review, then track comments and status updates directly against that version. Use the visible review status to see whether the release candidate is still waiting for feedback, needs changes, or is ready for approval. 3. Collect feedback in one place before making decisions. If reviewers identify missing pages, incorrect navigation, outdated wording, or asset problems, return to the draft workspace and fix the source content there. Do not treat the generated version as the editing workspace; use it as the review copy. 4. After making corrections in the draft, generate a fresh version so the review reflects the latest content. This is important when reviewers need to confirm that their requested changes were actually included. If several versions exist, use the version name and notes to keep the review history clear. 5. Do not move to publication until the version reaches the approved or release-ready state in Atloria. That approval status is your signal that the content, structure, and reviewer decisions are aligned. For more detailed review guidance, see [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) and [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). [SCREENSHOT: Generated version preview with navigation panel, review comments, and approval status] ## Checking Access Rules Before Making the Project Public 1. Open the project’s visibility or access settings and confirm the difference between internal workspace access and public documentation access. Your team should still be able to edit the draft workspace, but outside readers should only see the published documentation once release is complete. 2. Review which version is allowed to appear publicly. The approved version should be the only release candidate prepared for public viewing. Draft content, in-progress versions, and internal review work should remain unavailable to public visitors. 3. Check editing and management permissions for the people who work on the project. Editors should still be able to update draft content after release, while reviewers and administrators should keep the access they need for future cycles. This is also a good time to confirm that public readers do not gain access to internal project screens. 4. Use any preview or access-testing options available in the project and public documentation areas. Open the public entry point and confirm the experience matches your expectations: - public pages open correctly - restricted areas do not appear publicly - draft workspace screens still require sign-in - only the intended version is visible 5. If your team uses audience-specific visibility or version access controls, validate those settings before release so the right readers see the right content. Helpful related guides include [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access), [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export), and [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences). [SCREENSHOT: Project visibility settings and public preview showing approved version access] ## Publishing the Approved Version and Fixing Release Problems 1. Return to the approved version in the project’s versions or publishing area and use the publish action for that release. After publishing, confirm that Atloria updates the project or version state to show that the documentation is now publicly available. 2. Open the public documentation view immediately after release. Check the visible version label, navigation tree, and several key pages to make sure the correct release is live. This is the fastest way to catch a mismatch between what was approved and what readers can actually see. 3. If publishing does not complete, review the version and project details for common blockers: - the version is not fully approved - required content is still missing - public visibility settings are not enabled correctly - the wrong release candidate was selected 4. If the wrong version appears on the public site, go back to the versions area and check which version is marked as active or published. Select the intended approved version and publish again if needed. Then refresh the public view and verify the corrected release is now visible. 5. When the release is live, do one final public check across the most important pages, especially landing pages, navigation hubs, and recently updated content. If you also manage public browsing and audience behavior, [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) and [Reviewing Audience-Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation) are useful follow-ups. [SCREENSHOT: Published version screen and public documentation view showing the active release] ## Overview Coordinating a release in **Atloria** means moving a project through a controlled sequence: confirm the project is ready, prepare the draft content, generate a version, review that version, validate access, and then publish the approved release. This guide focuses on the coordination work that happens between initial project setup and the moment the documentation becomes public. Unlike the earlier setup-focused guide, this document assumes your project already exists and your team is ready to turn draft material into a release candidate. The main screens involved are the project workspace, documentation content area, version or publishing area, review workflow, and public visibility settings. Each of those screens plays a different role in the release cycle, and using them in the right order helps prevent incomplete or incorrect documentation from being published. The most important idea is that draft content and published content are not the same thing in Atloria. Your team edits pages in the project workspace, then creates a separate version for review. That version becomes the release candidate reviewers evaluate. Only after approval and access checks should you make it public. Use this guide when you need to coordinate people and decisions across the release process, not just click the final publish button. If you are still working on project setup, return to [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release). If your next task is to manage the version release process in more detail, continue with [Running a Documentation Release From Draft to Publication](doc:running-a-documentation-release-from-draft-to-publication). ## Prerequisites Before you start this workflow in **Atloria**, make sure these items are already in place: - You can sign in and reach the main authenticated workspace under **/app** - The project already exists in the project dashboard or project list - The project has draft documentation content ready for release preparation - The people involved in editing, reviewing, and approving the release already have access to the project - You know which pages, assets, and linked content belong in this release - Your team is using the project’s version or publishing area to create release candidates - A review process is available for the version you plan to publish - Public visibility or access controls are available for the final release It also helps if you have already worked through these related tasks: - Creating the project and finishing onboarding in [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release) - Organizing draft pages in [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) - Managing release candidates in [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) - Handling approvals in [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) If your team needs a more release-focused walkthrough after this one, continue with [Running a Documentation Release From Draft to Publication](doc:running-a-documentation-release-from-draft-to-publication). ## Checking whether a version is ready for review Before you click any review action in Atloria, open the version from the **Versions** list and check the version detail page carefully. This step helps you avoid sending reviewers an incomplete draft or a version that cannot move forward yet. If you need a refresher on getting a version into review shape, use [Preparing Versions for Review and Approval](doc:preparing-versions-for-review-and-approval). Start by confirming that the version is still editable and not already sitting in a completed review state. On the version page, look at the **status badge** near the top of the screen. If the version already shows a completed decision such as **Approved** or **Rejected**, you may need to update the version first before sending a new request. Also check whether the page shows review-related controls instead of edit controls, which can indicate the version is already in an active review cycle. Then review the content reviewers will actually judge. Make sure the version **title** and **description** are filled in and clearly explain what changed. If the version includes release notes, document updates, screenshots, or other release content, open those sections and verify they are complete and saved. Reviewers should be able to understand the scope of the version without guessing. Next, check the people involved in the review. If Atloria shows a **reviewer selection**, **approval participants**, or a similar review assignment area, confirm the correct people are listed before you continue. A request sent to the wrong reviewers usually delays the decision. Finally, make sure you can actually request review. If the **Request Review** or **Request Approval** button is missing or disabled, that usually means one of three things: - The version is not in the right status yet - Required details on the version are still missing - Your account does not have permission to send the request [SCREENSHOT: Version detail page showing status badge, title, description, reviewer area, and Request Review button] ## Requesting approval for a version Once the version page is complete, use the review action directly from that version record. In Atloria, this usually starts from the version detail screen, where you will see a button such as **Request Review** or **Request Approval**. Click that button to open the review request window. 1. Open the version from the **Versions** list. 2. Click **Request Review** or **Request Approval**. 3. If Atloria shows a reviewer picker, select the required reviewers or approval group. 4. Enter a note in the message area explaining what changed in this version. 5. Submit the request. 6. Return to the version page and confirm the status changed to a review state. If reviewer assignment is available during the request, take a moment to verify every name before submitting. This is especially important when a version needs sign-off from specific project leads or documentation owners. If the reviewer list is already filled in automatically, review it anyway so you do not send the request to an outdated group. Use the message or note field to give reviewers context. A short, direct note works best, such as what was updated, what needs special attention, or whether the version is targeting a specific release window. This note appears with the request and helps reviewers focus on the right areas. After you submit, check the version page again. The **status badge** should move from a draft or work-in-progress state to a review-related state such as **Pending Review**. You should also see evidence that the request was recorded, usually in one of these places: - An **activity feed** - A **review history** section - A **comments** or **timeline** panel - An updated **status badge** at the top of the version page If none of those change after submission, do not assume the request went through. Reopen the version and confirm the review request is visible before leaving the page. [SCREENSHOT: Request Review dialog with reviewer selection and approval note field] ## Reading reviewer outcomes and tracking decision status After you send the request, keep checking the version detail page rather than relying only on notifications. Atloria shows the current review state on the version record, and that status tells you whether the version is still waiting, has been approved, or has been rejected. The first place to look is the **status badge**. A review that is still in progress will usually show a pending state. Once reviewers respond, the badge should update to a final outcome such as **Approved** or **Rejected**. This top-level status is the quickest way to understand where the version stands. To understand the full story behind that status, open the **review history**, **approval timeline**, or **comments** area on the version page. These sections help you answer practical questions such as: - Who has already responded - When each response was submitted - Whether comments were added with the decision - Whether the decision shown is final or still partial Reviewer comments are especially important after a rejection, but they also matter when a version is approved with notes. Read each comment attached to the decision record so you understand whether the reviewer is fully satisfied or expects a follow-up before release. If more than one reviewer participates, separate individual responses from the final version decision. One reviewer may approve while another is still pending, and the version may remain in a review state until all required responses are complete. In other cases, a single rejection may immediately set the version to **Rejected**. The review history or timeline is the best place to confirm how Atloria applied the decision. When you need a deeper explanation of review outcomes and comment handling, see [Understanding Review Statuses Comments and Next Steps](doc:understanding-review-statuses-comments-and-next-steps) and [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). [SCREENSHOT: Version page showing status badge, review history, reviewer names, timestamps, and comments] ## Updating a rejected version and requesting review again When a version is rejected in Atloria, start from the rejection record rather than editing blindly. Open the version detail page and read the comments attached to the **Rejected** decision. Those comments usually point to the exact content, release notes, screenshots, or version details that need attention. 1. Open the rejected version from the **Versions** list. 2. Review the rejection comments in the **review history**, **comments**, or **timeline** area. 3. Return to the editable sections of the version and make the requested updates. 4. Save your changes and confirm the version is no longer blocked by the earlier review cycle. 5. Use **Request Review** or **Request Approval** again to submit the revised version. As you make changes, keep the revision clear and easy to follow. Update the same version carefully so reviewers can see that the rejected issues were addressed. If the version **description** or release summary needs clarification, revise that too. A clear summary helps reviewers understand what changed since the rejection. After a rejection, confirm the version has returned to an editable state. You should be able to open the content areas, save updates, and see the earlier rejection preserved in the history rather than mixed into the new request. Atloria should keep the previous decision visible as part of the record while still allowing you to prepare a fresh review cycle. Before you send the version back, double-check that the new request reflects the latest changes. If Atloria provides a message field during the second request, use it to explain what was fixed. That saves reviewers time and reduces back-and-forth. For guidance on handling comments and follow-up work between review rounds, see [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up) and [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions). [SCREENSHOT: Rejected version showing reviewer comments and updated Request Review action] ## Moving an approved version toward release Once a version shows **Approved**, the review phase is largely complete, but you should still verify that the approval is fully finished before moving toward release. Start on the version detail page and confirm the **status badge** shows **Approved**, not a partial or still-pending review state. 1. Open the approved version. 2. Confirm all required reviewer responses are complete in the **review history** or **timeline**. 3. Look for release-related actions on the version page. 4. Check any release readiness indicators or activity records tied to the approval. 5. Coordinate the actual release timing with the project team. An approved badge alone is not always enough if multiple reviewers were involved. Open the **review history** and make sure there are no missing decisions still holding the version in a conditional state. If Atloria uses a timeline or activity area, verify that the approval was recorded as the final decision. Next, look for controls that become useful after approval. Depending on your project setup, the version page may show actions related to release, publishing, finalization, or the next handoff step. Review those controls carefully before proceeding so you do not move a version forward too early. It is also helpful to check for signs that approval changed the version’s workflow state. On the version page, this may appear as: - A new **status badge** - A **release readiness** indicator - A new item in the **activity feed** - A recorded approval entry in the version history If your team releases on a schedule, do not assume approval means immediate publication. Some approved versions should be held until a planned release window. In that case, confirm the approved version is ready, then coordinate with project administrators or release owners before taking the next action. The next stage in this workflow is covered in [Preparing Versions for Final Approval and Release Handoffs](doc:preparing-versions-for-final-approval-and-release-handoffs). ## Fixing common review workflow problems Most review issues in Atloria can be traced back to the version page. When something does not behave as expected, return to the version detail screen and check the status, reviewer information, and visible actions before trying again. If **Request Review** or **Request Approval** is unavailable, inspect the version first. The button may be hidden or disabled because the version is in the wrong status, key fields are incomplete, or your account does not have the right access. Check the **title**, **description**, and any release-related content areas, then look at the **status badge** to confirm the version is still eligible for review. If reviewer decisions seem to be missing or delayed, open the **review history** or **timeline** and confirm the request was actually submitted. Then check whether the correct reviewers were assigned. A request sent without the right participants can sit in a pending state even though the version looks submitted. If the version stays in **Pending Review** after some responses are in, the most likely cause is that Atloria is waiting for all required reviewers. Compare the list of assigned reviewers with the responses shown in the history. One approval does not always create a final decision. If an approved version still cannot move forward, look for release blockers on the version page. These may include a status lock, missing release prerequisites, or project-level approval rules that still need to be satisfied. A quick troubleshooting checklist: - **Review button missing:** Check version status, required details, and your permissions - **No reviewer response visible:** Confirm reviewer assignment and that the request was submitted - **Still pending after responses:** Check whether all required reviewers must respond - **Approved but not releasable:** Review release readiness indicators and project approval rules If you need more help with admin-level review controls, see [Using the Admin Workspace](doc:using-the-admin-workspace), [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls), and [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Overview Use this workflow when a documentation version is ready to leave editing and enter formal review in Atloria. The main work happens on the **Versions** list and the individual **version detail page**, where you check readiness, send the review request, monitor decisions, and respond to approval or rejection outcomes. This guide focuses on the handoff point between preparation and decision handling. It assumes the version content has already been reviewed for completeness and that you are ready to use the **Request Review** or **Request Approval** action. If you still need to finish the version itself, return to [Preparing Versions for Review and Approval](doc:preparing-versions-for-review-and-approval) before continuing. You will use this process to: - Confirm the version can enter review - Send the review request to the right people - Read approval, pending, and rejection outcomes - Update a rejected version and submit it again - Move an approved version toward release planning In Atloria, the most important signals are visible directly on the version page: the **status badge**, the **review history**, the **comments** area, and any release-related actions that appear after approval. Staying on that page gives you the clearest picture of what happened and what still needs attention. This guide does not repeat the broader version lifecycle, comparison work, or release preparation steps covered elsewhere. For that surrounding context, see [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle), [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions), and [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions). ## Prerequisites Before you request review for a version in Atloria, make sure these conditions are already in place: - You can sign in and reach the project workspace where the version is stored - You can open the **Versions** list and access the relevant **version detail page** - The version already contains the content reviewers are expected to evaluate - The version **title** and **description** are filled in clearly - Any release-related content included with the version has been saved - The correct reviewers or approval participants are available for selection, if Atloria allows manual assignment - Your role includes permission to send a review request or approval request - The version is not already locked by a completed decision that prevents a new request It also helps if you have already completed the earlier preparation work covered in: - [Preparing Versions for Review and Approval](doc:preparing-versions-for-review-and-approval) - [Requesting and Completing Version Reviews](doc:requesting-and-completing-version-reviews) - [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval) If you expect to move quickly from approval into release coordination, keep your project administrators or release owners aligned before you submit the request. That way, an **Approved** version does not sit waiting because the next handoff was never planned. For users who also manage project-level settings, it may be useful to understand the surrounding workspace and approval context in [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home) and [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness). ## Confirming the audience rules and permissions before you validate Before you start launch checks in Atloria, open the audience area for the project and review every audience that affects the release. Use the audience list to confirm the **audience name** is clear and matches the group you expect to publish to. Then open each audience entry and review the membership setup carefully. If your team uses group-based or profile-based conditions to decide who belongs to an audience, make sure those conditions still match the people who should see the content at launch. Next, confirm that your own account has the access needed to complete the review. You should be able to open the project workspace, update audience settings, review version visibility, and open the published documentation view for testing. If you can view content but cannot change audience settings or version access, stop here and have a project administrator or documentation manager complete the validation with you. You should also confirm that the release version already exists before testing. Open the version you plan to launch and check its current visibility. Make sure the version is set the way your team intends to release it, whether that is broader public access or a more limited audience-based release. If the wrong version is selected, your audience checks will not reflect the actual launch experience. Finally, make a short review list of all content that uses audience targeting. Include pages, sections in navigation, linked articles, and any content areas your team marked for a specific audience. This gives you a checklist for both sides of validation: what the intended audience should see, and what everyone else should not see. [SCREENSHOT: Audience list showing audience names and membership settings next to a project version selected for review] ## Setting up the target audience for the content you plan to publish Use the project’s audience settings to create a new audience or update an existing one for the content you are about to release. Start by opening the audience entry and checking the details that determine who belongs to it. Pay close attention to the audience name and any membership conditions so the label matches the actual readers. If the audience is meant for a customer tier, partner group, or internal team, the setup should reflect that clearly before you apply it to content. Once the audience is ready, go to the documentation content you plan to publish. Open the page, article, section, or navigation item and look for the audience targeting control in the editor or content settings. Select the intended audience and save your changes. After saving, confirm that the content item shows an audience label or restriction indicator so you can tell at a glance that the targeting was applied. Do not stop at the main page. Open related child pages and linked articles to make sure the same audience logic is applied where needed. A parent page that is restricted while a child page remains unrestricted can still expose content through navigation or direct links. Likewise, a restricted child page under an unrestricted section can create a confusing experience for readers who can see the menu item but not the content they expect. As you review, check the navigation structure from the same editing area. Make sure only the right pages are grouped under the audience-targeted section. If a page should stay public, leave it outside the restricted branch. If it belongs to the targeted experience, apply the same audience setting before moving on. [SCREENSHOT: Documentation editor or content settings showing an audience selection control and a saved restriction label on a page] ## Checking version access for each audience before launch Open the version workspace for the release you are preparing and review the access settings tied to that version. Your first check is simple: confirm that the selected version is the one you intend to launch. Then inspect the visibility and audience access rules attached to it. A page can be targeted correctly and still fail in the public experience if the version itself is available to the wrong audience or unavailable to the right one. Look at the version status together with its access settings. If the version is in a release-ready state but still limited to the wrong audience, your launch check will produce misleading results. You want the version status and audience restrictions to support the same release plan. For example, if this version is meant for a specific audience, that audience must be able to open it from the published documentation view, while excluded audiences should be blocked consistently. Test this with real viewing scenarios. Use at least one account that should have access and one that should not. If your team uses a view-as or impersonation option during review, use that to switch between audience perspectives. Open the version directly, then try reaching it through the version selector if one is available. After that, use search and any saved direct links to confirm the same access rules apply everywhere. What you are looking for is consistency. An allowed audience should be able to find and open the version from normal navigation paths. An excluded audience should not be able to reach it through the version selector, search results, or a copied page link. If one route behaves differently, treat that as a launch blocker and fix it before release. [SCREENSHOT: Version settings screen with visibility options and audience-based access controls for a selected release] ## Reviewing the documentation as each audience will see it Open the published documentation view in Atloria and switch to the version you plan to launch. This is the most important part of pre-launch validation because it shows the experience readers will actually get, not just what authors see in the editor. Start with the target audience view first. If you are signed in as a matching user, or using your team’s audience testing method, confirm that the correct version opens and the expected navigation appears. Review the left navigation carefully. Check section names, page listings, and nested items to make sure audience-restricted content appears only where it should. Then open each targeted page and read it as a user would. Verify the **page title**, body content, callouts, downloads, attachments, and related links. If the page includes links to other articles, open those too and confirm they stay within the intended audience experience. After reviewing the allowed audience, repeat the same checks as a non-member audience or public visitor. The goal is not only to hide the page body, but to remove clues that the restricted content exists. Restricted pages should disappear from navigation, should not appear as visible related links, and should not open successfully from a copied URL if the viewer is outside the audience. This is also the point where you should compare what appears in menus with what appears inside pages. Sometimes a page is hidden correctly, but an in-page link or attachment still points to restricted material. Open those links one by one and confirm they follow the same audience rules as the page itself. If you already completed the checks in [Validating Audience Targeted Publishing Before Release](doc:validating-audience-targeted-publishing-before-release), use that work here as your baseline and focus only on the final published reader experience. [SCREENSHOT: Published documentation view with version selector, left navigation, and a targeted page open for audience review] ## Comparing targeted and public views to catch launch-blocking gaps A common pre-launch problem in Atloria is that content looks correct in the editor but behaves differently in the published view. To catch this, compare the internal authoring view side by side with the public documentation view for the same version and page. Start with a page that has audience targeting applied, then verify that the same title, content blocks, and navigation placement appear for the intended audience after publishing. Pay special attention to mismatches between page-level targeting and version-level access. A page may be assigned to a specific audience, but if that audience cannot open the selected version, the page will effectively disappear in the public experience. The opposite problem can also happen: the version is visible more broadly than intended, while individual pages are only partially restricted. That creates a confusing release where readers can enter the version but encounter missing or inconsistent content. Check shared assets during this comparison. Open images, downloadable files, and cross-links from both targeted pages and public pages. Make sure a public page does not expose restricted information through a file download, image caption, or related article link. If a page is safe but its linked asset is not, the release still needs correction. Document every issue you find while comparing views. A simple tracking table helps your team fix the right thing quickly before launch. | Audience | Version | Page or location | Issue type | What happened | |---|---|---|---|---| | Intended audience | Selected release version | Targeted page | Missing content | Page appears in editor but not in published view | | Excluded audience | Selected release version | Direct page link | Incorrect access | Page opens even though it should be hidden | | Public visitor | Selected release version | Related link or file | Content exposure | Linked asset reveals restricted information | [SCREENSHOT: Side-by-side comparison of an internal page view and the published page view for the same targeted content] ## Fixing common audience publishing validation issues If an audience can open the version but cannot see the page, start with the page itself. Open the page settings and confirm the correct audience is assigned. Then check whether the page is included in the published navigation. In Atloria, a page can be properly restricted but still seem missing if it is not placed in the visible navigation structure for that version. If a page is hidden in navigation but still opens by direct link, review both the page restriction and the version access settings. These two controls need to work together. Hiding a page from menus is not enough if the version remains open in a way that still allows the page URL to load for excluded readers. Recheck the version’s audience access and test the direct link again with a non-member account. If public visitors can still see restricted content blocks, inspect more than the parent page. Open any embedded sections, reusable content, linked articles, attachments, or shared assets used on that page. Sometimes the main page is targeted correctly, but a nested content block or linked file remains available more broadly and exposes information you meant to limit. If the expected audience does not appear during testing, verify the test account itself. Open the audience definition and compare its membership rules with the user profile or group membership of the account you are using. If your team recently changed audience membership, save those updates fully before retesting. Then sign out and back in, or switch back to the published view again, so you are checking the latest audience state. When an issue keeps repeating, return to the earlier setup guidance in [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences) and [Validating Audience Targeted Publishing](doc:validating-audience-targeted-publishing) to confirm the targeting model is still aligned with the release you are preparing. ## Overview This guide focuses on the final validation pass for audience-targeted publishing in Atloria before launch. At this stage, you are not planning the audience model from scratch and you are not doing an early draft review. Instead, you are confirming that the release version, audience rules, page targeting, and published reader experience all match each other. The core workflow has four parts: 1. Confirm the audience definitions and your own permissions. 2. Apply or verify audience targeting on the content being released. 3. Check version access for allowed and excluded audiences. 4. Review the published documentation view exactly as each audience will see it. This document is especially useful when a release includes pages that should only appear for certain readers, such as customer-specific guidance, internal-only notes, or restricted release content. In those cases, it is not enough to verify the editor setup. You also need to confirm that navigation, direct links, related content, and version access all behave correctly in the published view. Use this guide after you have already completed the broader pre-release checks in [Validating Audience Targeted Publishing Before Release](doc:validating-audience-targeted-publishing-before-release). Here, the focus is narrower: catching launch-blocking gaps that only show up when the selected version is viewed through audience rules in the public documentation experience. ## Prerequisites Before you work through this validation in Atloria, make sure these items are already in place: - You can sign in to Atloria and open the project workspace. - You have access to the project’s audience settings, version settings, and published documentation view. - The documentation version you plan to launch has already been created. - The pages, sections, or navigation items that use audience targeting have already been identified. - You have at least one way to test an allowed audience and one excluded audience, such as separate user accounts or your team’s review method for switching audience perspective. - The content itself is already prepared for release, including page titles, links, callouts, and attachments. It also helps to have these earlier guides completed so you are not repeating setup work during launch validation: - [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) - [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation) - [Validating Audience Targeted Publishing Before Release](doc:validating-audience-targeted-publishing-before-release) After you finish the checks in this guide, continue with [Validating Audience Specific Release Views](doc:validating-audience-specific-release-views) to review the final audience-facing release presentation in more detail. ## Opening the screenshot capture workspace In Atloria, start from your project workspace where you manage documentation content and related assets. Open the screenshot capture area from the documentation workflow you are already using for image collection. If you have already worked through [Saving and Organizing Captured Screenshots](doc:saving-and-organizing-captured-screenshots), return to the same screenshot area and begin a fresh capture instead of reusing an older preview. Look for the main capture screen elements before you begin: - a **URL** entry field where you paste the page address you want to capture - a **preview area** where the target page loads - a **capture** action that creates the screenshot - **save** controls that store the image for later use Paste the exact page address into the **URL** field, then start the page load so Atloria can display that page in the preview area. If the page does not open correctly, stop here and confirm you copied the right address. A screenshot is only useful if the preview shows the same page state you want readers to see in your documentation. If the page you are capturing requires sign-in, permissions, or a specific page state, make sure those conditions are already in place before you capture. For example, if you need a menu open, a dialog visible, or a settings page loaded, confirm that the preview shows that exact state first. Atloria can only capture what is currently visible in the loaded page. [SCREENSHOT: Screenshot capture workspace showing the URL field, loaded page preview, capture button, and save controls] Before moving on, scan the screen once so you know where each action lives. That makes the rest of the workflow faster, especially when you need several screenshots for one guide. ## Capturing a screenshot from a URL Once the page is loaded in the preview area, you can create the screenshot. This is the point where Atloria turns the current visible page state into an image attached to your active capture workflow. 1. Paste the page address into the **URL** field. 2. Load the page in the preview area. 3. Wait until the page finishes rendering and all needed interface elements are visible. 4. Use the **Capture** action to create the screenshot. 5. Review the newly generated image in the preview before moving to the next page. Do not rush the capture step. If the page is still loading, the screenshot may miss navigation items, panels, dialog boxes, or other details you intended to document. Wait until the preview looks stable. If you are documenting a workflow, this is also the time to make sure the page shows the right step, such as a menu expanded or a form section open. After you capture the image, Atloria keeps that screenshot in the current capture flow so you can review it and decide whether to save it. If you need more than one image, repeat the same process for each page or page state. This is especially useful when you are documenting a sequence, such as opening a page, changing a setting, and confirming the result. For multi-step documentation, keep your captures focused: - capture one clear state per screenshot - avoid mixing several actions into one crowded image - capture alternate page states separately when they explain the process better [SCREENSHOT: Loaded page preview with the Capture action highlighted] If a page needs several screenshots, capture them one at a time in the order readers will follow them. That makes naming and saving much easier later. ## Reviewing the captured image before saving After you capture a screenshot, pause on the preview instead of saving immediately. The preview is where you confirm that the image is accurate, readable, and worth keeping as a reusable documentation asset. Start by checking whether the screenshot shows the correct page and the exact visible content you meant to capture. Look closely at the main navigation, page title, open panels, buttons, and any dialogs or menus that should appear in the image. If your guide depends on a specific state, such as a settings panel being expanded, verify that the preview clearly shows it. Use the preview to catch common issues: - the page had not fully loaded before capture - a menu or dialog closed before the image was taken - important content is clipped or cut off - an overlay, popup, or unexpected banner is covering the page - the screenshot shows the wrong page or an earlier step If you spot any of these problems, go back to the loaded page, restore the correct state, and capture again. It is usually faster to recapture immediately than to save a weak image and discover later that it cannot be used in a document. A good screenshot for reuse should be easy to understand without extra explanation. Readers should be able to identify the page, the action area, and the relevant controls at a glance. If the preview feels confusing, crowded, or incomplete, create a cleaner version before saving. [SCREENSHOT: Screenshot preview showing a clean captured page ready for review] This review step matters because saved screenshots often get reused across pages, versions, and projects. A careful check now prevents clutter in your saved asset list and reduces rework later. ## Saving screenshots for later use Capturing a screenshot and saving it are two different steps in Atloria. A captured image can appear in the preview temporarily, but it does not become a reusable documentation asset until you use the **Save** action. 1. Review the screenshot in the preview area. 2. Click **Save** to store the image. 3. Enter a clear name for the screenshot. 4. Confirm the image appears in your saved captures or asset list. When you name the screenshot, use a label that tells other writers exactly what the image shows. The best names usually include the page, feature area, and visible state. For example, instead of a vague name that only tells you it is an image, choose a name that reflects the screen readers will see and the step it supports. A useful naming pattern includes: - the product area or feature area - the page name - the page state or action shown - the step number, if the image belongs to a sequence This makes saved screenshots easier to search, sort, and reuse later. If your team works across several projects, clear names are even more important because the same type of page may appear in more than one place. After saving, check the stored captures or asset list to make sure the screenshot is actually available there. If you only captured the image but did not save it, it may not be available when you return later to build or edit documentation. [SCREENSHOT: Save action and asset name field with a saved screenshot appearing in the stored list] If you are building a library of screenshots for repeated use, save each approved image as soon as you finish reviewing it. That keeps your documentation workflow moving and avoids losing good captures between sessions. ## Organizing saved captures so teams can reuse them Once screenshots are saved, organization becomes just as important as capture quality. In Atloria, saved images are much easier to reuse when they are grouped in a way that matches how your team writes documentation. You can organize saved captures by: - page - feature area - project - workflow step - release or version stage Choose one approach and use it consistently. For example, if your documentation is usually written by feature area, keep screenshots grouped the same way. If your team works mostly inside project-based workspaces, organize saved images by project first and then by page or workflow. Consistent naming helps just as much as grouping. A pattern like `product-area_page-state_step-number` makes it easier to scan a list of saved captures and immediately understand what each image contains. The exact wording can vary, but the structure should stay predictable across the team. If Atloria shows folders, collections, or a saved asset list, use those areas to separate working images from approved images. This helps prevent draft captures from being reused in polished documentation. Keep your best screenshots where writers can find them quickly without opening every image one by one. It also helps to review saved captures regularly. Remove outdated screenshots when the interface changes, and keep only the images that still match the current Atloria experience or the external page you are documenting. A smaller, cleaner library is easier to maintain than a large list of mixed-quality assets. For broader screenshot management practices, see [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation). [SCREENSHOT: Saved screenshot list grouped by project or feature area] A well-organized screenshot library saves time during writing, review, and version updates because the right image is already easy to locate. ## Fixing common problems with captures and saved images Most screenshot issues in Atloria come from one of four points in the workflow: the wrong page was loaded, the page was captured too early, the image was never saved, or the saved asset was named poorly. If the screenshot shows the wrong content, first check the **URL** field. Make sure it contains the exact page address you intended to capture. Then reload the page in the preview and confirm the visible content matches your documentation step before using **Capture** again. If the preview looks incomplete or clipped, the page may not have finished loading or the required content may not be visible yet. Return to the page state you want, reopen any menus or dialogs that should appear, and recapture only after the preview clearly shows those elements. If you can see the image right after capture but cannot find it later, the most likely reason is that it was previewed but not saved. Open the stored captures or asset list and check whether the image appears there. If it does not, repeat the capture and use **Save** before leaving the screen. If saved screenshots are hard to find, improve the organization rather than recapturing everything. Rename images so the page and state are obvious, then move them into the correct project or feature grouping if that option is available in your screenshot area. A quick troubleshooting approach: | Problem | What to check | What to do | |---|---|---| | Wrong page captured | **URL** field and preview content | Reload the correct page and capture again | | Incomplete image | Preview not fully loaded or content not visible | Wait, restore the page state, and recapture | | Image missing later | Saved asset list does not include the screenshot | Capture again and click **Save** | | Hard to locate saved image | Asset names or grouping are unclear | Rename and regroup the screenshot | For issues that affect screenshot reuse across teams or versions, see [Troubleshooting Screenshot Availability Across Projects and Versions](doc:troubleshooting-screenshot-availability-across-projects-and-versions). ## Overview This workflow in Atloria focuses on turning a live page into a reusable documentation image. You begin with a page address in the **URL** field, load that page into the preview area, capture the visible state, review the result, and then save the image so it becomes part of your reusable screenshot library. The key idea is that a screenshot is not finished when it appears in preview. It becomes useful for documentation only after two checks happen: - the preview shows the exact page state you want readers to see - the image is saved with a clear name so it can be found later This guide fits between two related screenshot tasks. If you need help managing saved images after capture, return to [Saving and Organizing Captured Screenshots](doc:saving-and-organizing-captured-screenshots). That guide covers the broader storage and organization side of the workflow. Here, the focus is the full path from loading a page to saving a reviewed image. In practical terms, this means you should treat the screenshot capture screen as a working area with four parts: - **URL** entry for the page you want to document - **preview** for checking the loaded page and captured image - **Capture** for generating the screenshot - **Save** for storing it as a reusable asset When you follow those steps carefully, your screenshots are easier to reuse in documentation pages, version updates, and review cycles. This is especially helpful when several writers work in the same Atloria project and need a shared set of approved images instead of one-off captures stored only in a temporary session. ## Prerequisites Before you start capturing screenshots in Atloria, make sure a few basics are already in place. This keeps the preview accurate and reduces the chance of saving images you will need to replace later. You should have: - access to the Atloria project or documentation workspace where you manage screenshots - the page address you want to capture - permission to view the target page - the target page already prepared in the state you want to document, if it requires sign-in or a specific visible step - enough context to name the screenshot clearly when you save it It also helps if you already know where the screenshot will be used. For example, if the image belongs to a step-by-step guide, decide the step order before you start capturing. That makes naming more consistent and helps you avoid duplicate images. If the target page requires you to be signed in, confirm that the page loads correctly in the preview before capturing. If a menu, modal, or settings panel needs to be visible, open it before you take the screenshot. Atloria captures what is shown in the loaded page state, so preparation matters. For the best results, have a simple plan for how you will save images: - by project - by feature area - by page - by workflow step If you have not yet set up a consistent screenshot storage approach, review [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). From here, the next step is [Capturing Website Screenshots and Saving Reusable Assets](doc:capturing-website-screenshots-and-saving-reusable-assets), which builds on this workflow for repeatable asset creation. ## Opening the language support catalog To review parser availability in Atloria, open the workspace where you evaluate code parsing and language support, then go to the **Supported Languages** page. This page is the main catalog for checking whether Atloria recognizes the languages, frameworks, and source formats used in your documentation environment before you upload code or connect a repository. If you already worked through [Evaluating Language Support Before Parsing Code](doc:evaluating-language-support-before-parsing-code), use that preparation list here instead of rebuilding it from scratch. On the **Supported Languages** page, scan the catalog row by row. Each entry is meant to help you judge fit, not just confirm that a language name appears somewhere in the list. Focus on the visible columns that tell you what Atloria can handle for each entry: | Column | What to look for | |---|---| | **Language** | The main language or format name shown in the catalog | | **Framework / Variant** | A more specific label when support differs by framework, flavor, or syntax style | | **Parser Count** | How many parsers Atloria lists for that language or framework entry | | **Coverage Indicator** | Whether support appears broad or more limited | This catalog is especially useful when one language appears in several forms. For example, the same language may be listed once as a general language entry and again with framework-specific entries. In that case, do not assume every row offers the same parsing depth. Use the page as a comparison screen. Your goal is to confirm whether Atloria supports the exact combinations your team uses, including framework-specific documentation sources and mixed repositories. [SCREENSHOT: Supported Languages page showing the catalog with Language, Framework or Variant, Parser Count, and Coverage Indicator columns] ## Reading parser counts and coverage indicators The **Parser Count** column tells you how many parser options Atloria has for a specific language and framework combination. This number matters because parser availability can vary even when the language name looks familiar. A language with several parser options may support more than one ecosystem or syntax style, while another entry with the same language name may have fewer options. When you review a row, read **Parser Count** together with the **Coverage Indicator**. These two values work best as a pair: - **Parser Count** shows how many parser options are available. - **Coverage Indicator** shows whether support appears broad or more limited for that entry. Do not rely on the language name alone. If you only check the **Language** column, you may miss important differences between a general language entry and a framework-specific one. For example, one row may show stronger coverage for a framework variant than the base language entry, or the opposite may be true. As you compare rows, pay attention to repeated language names with different framework labels. That usually means Atloria separates support by ecosystem, syntax variant, or framework target. In those cases, the parser count may differ from one row to another, and the coverage indicator may also change. That difference is the signal you need when deciding whether a repository is likely to parse cleanly. A practical way to read the catalog is: 1. Find the exact language or format. 2. Check whether there are multiple framework or variant rows. 3. Compare the **Parser Count** values across those rows. 4. Use the **Coverage Indicator** to judge whether support looks broad enough for your content. [SCREENSHOT: Catalog rows showing the same language listed with different framework or variant entries and different parser counts] ## Filtering languages by framework and support level When the catalog contains many entries, use the **search field** first. Enter the language name, markup format, or framework your team uses in repositories and documentation sources. This is the fastest way to narrow the list before you start comparing parser counts. If a language has several related entries, try both the broad language name and the framework name to make sure you are looking at the most relevant rows. After searching, use any framework-related filtering options on the page to narrow the results further. This is especially helpful when Atloria lists both core language support and framework-specific parsing for the same language family. Instead of reviewing every row manually, you can focus on the exact framework or syntax style used by your team. While filtering, keep your eye on two columns: - **Parser Count** - **Coverage Indicator** These columns help you separate stronger support from entries that may need closer review. If your documentation environment includes several repositories or mixed source types, scan or sort the **Parser Count** column to find the entries with deeper parser coverage. That gives you a quick view of where Atloria appears strongest. Filtering is most useful when your team works across multiple stacks. For example, you might search one language, then refine by framework, then compare the remaining rows by parser count and coverage. Once the list is narrowed, review the coverage labels carefully. A filtered result can still include combinations with limited support, so do not stop at the search result alone. Use this workflow: 1. Enter a language, format, or framework in the **search field**. 2. Narrow the results with framework-related filters if available. 3. Scan the **Parser Count** column for stronger coverage. 4. Confirm the **Coverage Indicator** before treating an entry as rollout-ready. [SCREENSHOT: Supported Languages page with a search field in use and filtered results showing framework-specific entries] ## Comparing Atloria support against your documentation stack Before you decide whether Atloria is a good fit for your parsing workflow, compare the catalog against the real content sources your team already uses. Start with a simple working list of the languages, frameworks, and source formats that appear across your documentation pages, code comments, and generated reference material. Keep the list practical. Focus on what your team actively maintains, not every possible language that exists somewhere in your organization. Once you have that list, open the **Supported Languages** catalog and match each item to a row in Atloria. Look for the exact language name first, then confirm the **Framework / Variant** label. This step matters because a broad language match is not always enough. If your team depends on a specific framework or syntax style, the matching row should reflect that exact combination. As you compare, review these points for each item: | Check | What to confirm in Atloria | |---|---| | **Language match** | The language or format appears in the catalog | | **Framework match** | The framework or variant label matches your actual stack | | **Parser Count** | The row shows enough parser availability for that combination | | **Coverage Indicator** | The support level looks broad enough for your expected content | Flag any gaps as you go. A gap might mean the language appears in the catalog but the framework label does not match, the parser count is lower than expected, or the coverage indicator suggests only partial support. Those are the entries that deserve extra attention before rollout. Prioritize your review by business importance. Start with the languages and formats tied to your highest-volume documentation or your most important reference content. If those entries look strong in Atloria, you can move forward with more confidence. If they look weak, that is a sign to slow down and validate further before adoption. ## Deciding whether parser coverage is sufficient for rollout After you compare your stack to the catalog, decide which parts of your content are safe to onboard first. In Atloria, the strongest rollout candidates are usually the entries that combine a clear language or framework match, a solid **Parser Count**, and a strong **Coverage Indicator**. Those combinations are the lowest-risk starting point because they suggest broader parser availability for the content you want to bring in. Treat entries with limited or partial coverage more carefully. A language may appear in the catalog, but that does not always mean every syntax pattern in your repositories will behave the same way. If your team uses custom syntax, framework extensions, or mixed-format repositories, a limited coverage indicator is a sign to validate those areas before making them part of a larger rollout. Multiple parser options for the same language can also improve confidence, especially if your teams work across several framework variants. When Atloria shows more than one parser path for a language family, that can be a good sign for organizations managing different documentation sources under one program. Still, use the exact framework row that matches your content rather than assuming all related rows offer equal support. A practical rollout decision usually looks like this: - Start with languages and frameworks that show strong coverage and healthy parser counts. - Hold back entries with partial coverage until you validate them in real project content. - Note any repositories that depend on uncommon syntax or mixed source structures. - Share those findings with the people planning onboarding, project setup, and documentation scope. If you need help planning the broader rollout sequence after this review, the project setup and onboarding guidance in [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) can help you turn parser findings into an adoption plan. ## Handling gaps in language or framework support If you cannot find a language right away, start by trying different search terms in the **search field**. Some entries may be easier to find under a framework name, a syntax family, or a more specific variant label rather than the broad language name your team uses in conversation. Search again using alternate naming before you assume the language is missing. If the language appears but the support looks limited, compare nearby entries for related frameworks or variants. Atloria may list a more specific parser target that better matches your content than the general language row. In that case, the more specific entry may show a different **Parser Count** or a stronger **Coverage Indicator** than the broader listing. When parser counts are lower than expected, identify which repositories actually depend on that language or framework. Focus on the content that matters most: high-traffic documentation, generated reference pages, or repositories that drive published documentation. This helps you separate a minor gap from a rollout blocker. If support still feels unclear after searching and comparing, capture the exact details shown in the catalog so your team can review them internally. Record: - The **Language** name exactly as shown - The **Framework / Variant** label - The **Parser Count** - The **Coverage Indicator** That record gives project leads, documentation managers, or admins a concrete basis for follow-up. It is much more useful than a general note saying a language is “not supported enough.” For broader admin-side review of planning and oversight, see [Using the Admin Workspace](doc:using-the-admin-workspace). If your team needs to continue the evaluation process after identifying gaps, keep those exact catalog details with your rollout notes so they can be checked again during project planning. ## Overview This page in Atloria is designed for one specific job: helping you decide whether the languages and frameworks in your documentation environment are supported well enough for parsing. The **Supported Languages** catalog is not just a reference list. It is a decision tool that lets you compare your real stack against visible support signals before you upload code, connect repositories, or commit to a wider documentation rollout. The most important parts of the catalog are the rows and columns that show: - **Language** - **Framework / Variant** - **Parser Count** - **Coverage Indicator** Together, these tell you whether Atloria recognizes a language broadly, whether support changes by framework, and whether there are multiple parser options available for a specific combination. That is especially important for teams working with mixed repositories, framework-heavy projects, or generated technical documentation. Use this document when you need to answer questions such as: - Does Atloria support the exact language and framework combination we use? - Is there just one parser option, or several? - Does the coverage indicator suggest broad support or limited support? - Which parts of our documentation stack are safest to onboard first? This guide builds on the evaluation approach introduced in [Evaluating Language Support Before Parsing Code](doc:evaluating-language-support-before-parsing-code). Here, the focus is narrower: reading the catalog itself and using parser counts and coverage indicators to make a practical support decision. After you finish this review, continue with [Evaluating Supported Languages and Framework Coverage](doc:evaluating-supported-languages-and-framework-coverage) to look more closely at how support depth affects framework-heavy documentation environments. ## Prerequisites Before you use the **Supported Languages** catalog in Atloria, make sure you have the basic information needed to compare the catalog against your real documentation environment. You do not need a technical inventory, but you do need a clear list of the languages, frameworks, and source formats your team actually relies on. Have these items ready: - Access to Atloria and the workspace where you review language support - A list of the languages used in your documentation-related repositories - The framework names or syntax variants tied to those languages - Notes on any generated reference content, code comments, or markup formats your team depends on - A rough sense of which repositories or content sources are most important to your rollout It also helps if you already know which content is business-critical. When you compare parser availability, the most important question is not whether every possible language appears in the catalog. It is whether the languages that matter most to your documentation program are covered well enough to support onboarding. If you have not yet organized that information, review [Evaluating Language Support Before Parsing Code](doc:evaluating-language-support-before-parsing-code) first. That document helps you prepare your stack list so you can use the catalog efficiently instead of searching one term at a time without context. You may also want access to the project and documentation owners who know which repositories produce your most important docs. Their input is useful when parser counts or coverage indicators suggest that some parts of the stack are stronger candidates for early rollout than others. ## Starting a Conversation with a Support Agent If you already know how to open and use the chat experience, use this guide alongside [Chatting with Support Agents and Managing Conversations](doc:chatting-with-support-agents-and-managing-conversations). Here, the focus is on how conversations are created, tracked, and managed over time inside Atloria. 1. Open the support chat from the chat launcher or the **Help** or **Support** entry point available in your current Atloria workspace. When the chat panel opens, look for the active conversation area and the message box at the bottom of the panel. 2. Before you send your first message, check the top area of the chat panel for the active support agent or support destination. If Atloria shows an agent name, support queue, or thread header, confirm that it matches the help you want. This matters when your team uses more than one support agent or different support workspaces. 3. Click into the message composer and type your question. Keep the first message specific so the new thread is easy to recognize later. For example, include the project, page, or issue you are asking about if that information is relevant to your work. 4. Use the **Send** action in the composer to post the message. After you send it, Atloria creates a conversation thread and adds your message to the timeline. 5. Check the conversation list or history panel to confirm that the new thread appears. You can usually identify it by: - the latest message preview - the most recent timestamp - any unread marker or highlighted state [SCREENSHOT: support chat panel showing the conversation list on one side and a new thread selected after the first message is sent] Once the thread appears in the list, you can return to it later without starting over. ## Following Replies and Understanding Conversation Context After you send a message, stay in the selected thread so you can follow the reply in the message timeline. Atloria shows the conversation as a running sequence of messages, which helps you see what you asked, what the agent answered, and whether extra context is affecting the current reply. 1. Read each response directly in the message timeline. Look for visible details attached to each message, such as: - who sent it - when it was sent - whether it appears as a normal reply, a pending response, or a notice 2. Check the conversation header or thread details area at the top of the chat panel. This area helps you confirm which support agent is replying and whether you are still inside the same active conversation. If you switch threads, the header should change to match the newly selected conversation. 3. Pay attention to contextual cues that appear with the reply. In Atloria, a response may reflect earlier messages in the same thread. If the reply seems to refer back to a previous question, review the messages just above it before sending a follow-up. This makes it easier to understand why the answer was phrased a certain way. 4. Distinguish the message types in the thread: - **Your messages** show what you entered in the composer - **Agent messages** contain the support response - **Automated or system notices** may appear as informational updates inside the same timeline [SCREENSHOT: message timeline with user messages, agent replies, timestamps, and a thread header showing the active conversation] If a reply feels out of place, do not assume the answer is wrong right away. First confirm that you are viewing the correct thread and that the agent is responding to the most recent issue in that conversation. ## Reviewing Earlier Chats and Reopening Past Threads When you need to revisit an earlier issue, use the conversation history instead of starting a new chat immediately. Atloria keeps past threads in the chat panel so you can reopen them, review what was already discussed, and continue from the same place. 1. Open the chat panel and look for the conversation history or thread list. This area shows your earlier chats in a scrollable list, usually ordered by recent activity. 2. Scan the thread details to find the right conversation. The most useful clues are: - participant or agent name - latest message preview - last activity time - unread or active state 3. Click the thread you want to review. Atloria reloads that conversation in the main chat area so you can read the full message history in order. 4. Scroll through the timeline before replying. This is especially helpful if the thread includes several rounds of back-and-forth messages. Reading the earlier entries helps you avoid repeating information the agent already has in the same conversation. 5. If the issue is still the same, continue in that thread by typing in the existing composer and using **Send**. This keeps the full history together and makes it easier for the next reply to reflect the earlier discussion. [SCREENSHOT: conversation history list with several past threads, each showing a message preview and last activity time] Use a past thread only when the topic still matches. If the old conversation was about a different document, project, or support issue, starting a separate thread is usually clearer than adding unrelated messages to the older one. ## Resetting or Restarting a Conversation Sometimes a conversation becomes too mixed to be useful. If the current thread includes outdated details, old troubleshooting steps, or replies that no longer match your issue, restart the conversation instead of continuing to add corrections. 1. In the active chat thread, look for a control such as **Reset**, **Clear chat**, or **Start new conversation**. The exact label may vary by workspace, but the purpose is the same: remove the current reply context or begin a fresh thread. 2. Decide whether you need to clear the current context or begin a completely new conversation. Use a reset when the existing thread is causing confusing replies. Use a new conversation when you want a separate history entry for a different issue. 3. If Atloria shows a confirmation prompt, read it before continuing. A warning usually means the current conversation state, active context, or selected thread will be discarded from the chat panel view. 4. Confirm the action. After the reset, check that the chat area reflects a clean start: - the previous message timeline is no longer the active focus - the composer is ready for a new message - the selected thread state has changed to a fresh conversation 5. Type your new request with the current issue only, then use **Send** to begin again. [SCREENSHOT: chat panel showing a reset or start new conversation option and a confirmation prompt] If you are unsure whether to continue or restart, ask yourself one question: “Would someone reading this thread understand my current issue without the older messages?” If the answer is no, restart the conversation. ## Keeping Chat History Useful for Ongoing Support Work A clean conversation history makes Atloria easier to use for both you and anyone else reviewing support activity later. The goal is not to save every possible detail in one thread. The goal is to keep each thread understandable when someone opens it from the history list. - Keep one thread focused on one issue. If you change from a documentation question to a project setup problem, start a new conversation instead of mixing both topics together. - Restart the conversation when replies begin referencing details that are no longer relevant. This usually happens after several topic changes inside the same thread. - Before you reply, check the thread preview and timestamp in the history list. This helps you avoid posting into an older conversation by mistake, especially when several chats have similar subjects. - Use consistent wording for recurring issues. If your team regularly asks about the same project area, document section, or support workflow, similar phrasing makes the history easier to scan and compare. - Review the most recent messages before adding a follow-up. A quick reread often prevents duplicate questions and keeps the thread shorter. - When a conversation is still active, continue in the same thread rather than opening multiple parallel chats about the same problem. This keeps the message timeline complete and easier to follow. [SCREENSHOT: thread list showing clearly named or easily recognizable conversations with distinct message previews] Well-organized chat history is especially helpful when you return to a conversation after time away or when another teammate needs to understand what has already been discussed in Atloria. ## Fixing Common Problems with Agent Replies and Chat History Most chat problems in Atloria come from thread selection, old context, or reopening the wrong conversation. When a reply looks confusing, use the visible chat controls and thread list to confirm where you are before sending another message. - **A reply appears in the wrong thread** Check which conversation is selected in the history list. The highlighted thread and the conversation header should match the discussion you expect. If not, open the correct thread before replying again. - **Earlier messages seem to be missing** Reopen the conversation from the history list instead of relying on whatever timeline is currently loaded. If you switched threads earlier, Atloria may be showing a different conversation than the one you intended to review. - **The agent response seems unrelated** Read the previous messages in the timeline to see whether the reply is based on older context from the same thread. If the answer is still off-topic, use **Reset**, **Clear chat**, or **Start new conversation**, then resend your request with only the current issue. - **A new chat does not feel like a clean start** Confirm that the previous thread was actually cleared or that a different fresh thread is selected. The composer should be attached to a new conversation state rather than an older message history. - **You are not sure which past chat to reopen** Use the latest message preview and last activity time in the thread list to identify the right one before clicking into it. [SCREENSHOT: support chat with one selected thread in the history list and a visible conversation header matching the open timeline] If you continue to have trouble following where a reply belongs, keep the thread list open while you work. Seeing the selected conversation and the active timeline together usually makes the issue obvious. ## Overview - This guide explains how to manage support chat threads after you open the chat experience in Atloria. - You learn how to: - start a new conversation from the chat panel - recognize a thread in the conversation list - read replies in the message timeline - reopen older chats from conversation history - reset or restart a conversation when the current thread is no longer useful - The main areas used in this workflow are: - the chat launcher or **Help** / **Support** entry point - the conversation list or history panel - the conversation header - the message timeline - the message composer - the **Send** action - any visible **Reset**, **Clear chat**, or **Start new conversation** control - This document does not repeat the basics of opening the chat and sending everyday messages. For that, refer to [Chatting with Support Agents and Managing Conversations](doc:chatting-with-support-agents-and-managing-conversations). - Use this guide when you need to keep support threads organized, return to earlier discussions, or make sure replies are tied to the right conversation context. - If you work with multiple support questions across projects or documentation areas, these chat history habits make Atloria easier to navigate and reduce confusion in longer threads. ## Prerequisites - You can sign in to Atloria and access a workspace where the support chat is available. - You know how to open the support chat panel from the chat launcher or the **Help** or **Support** entry point. - You have already used the basic chat workflow covered in [Chatting with Support Agents and Managing Conversations](doc:chatting-with-support-agents-and-managing-conversations). - You can recognize the main chat areas on screen: - conversation list or history - active thread header - message timeline - message composer - **Send** action - If your Atloria workspace offers more than one support agent or support destination, you should know which one you intend to contact before starting a new thread. - If you are returning to an earlier issue, it helps to know roughly when the conversation happened so you can find it faster in the history list. The next step is [Managing Agent Conversations and Session Follow Up](doc:managing-agent-conversations-and-session-follow-up), which covers what to do after a chat continues beyond the initial exchange. ## Choosing the Right Export for Review or Archive In Atloria, the best export choice depends on what you need to do with the file after download. When you open a documentation version, the export options usually center on two decisions: whether to export only that version’s content, and whether to include related records such as attachments and linked version details. A version-only export is the simplest option when you need a clean copy for someone to read, compare, or sign off on. An export that includes related records is better when the package needs to travel with supporting material. For review work, choose the export option that keeps the documentation easy to read and clearly tied to the version label. This is useful when a reviewer needs to inspect a fixed version without opening the live workspace. Review packages are usually best when they focus on the document structure itself and include only the supporting items needed for that review cycle. For archiving, choose a broader export scope. Include the documentation version together with attachments, approval notes, and linked metadata when those records are part of the official history of the version. This creates a more complete handoff package for long-term storage, audit support, or release retention. You may export from different record scopes depending on where you start: - A single documentation version from its detail page - Multiple versions selected from a versions list - One version together with attachments and linked metadata Clear naming matters once files leave Atloria. Before exporting, check that the version label, title, and date fields are accurate. These details help you tell apart draft, approved, and older superseded packages after download, especially when several exports from the same project are stored together. [SCREENSHOT: Documentation version page showing export choices for version-only and version-with-related-records] ## Checking That a Documentation Version Is Ready to Export Before you click **Export**, review the documentation version carefully so the downloaded file reflects the right state of the record. In Atloria, start with the version status shown on the version record. A version that is still in draft may be useful for internal review, but it may not be appropriate for stakeholder sharing or archive storage. A version marked ready for review is usually a better choice for formal feedback, while a finalized version is the safest option for long-term retention. Next, confirm that the identifying fields on the version record are complete. Missing version details make exported files harder to recognize later and can create confusion if several packages are downloaded from the same project. Check these fields before exporting: | Field | Why it matters | |---|---| | **Title** | Helps identify the document package after download | | **Version Number** | Distinguishes one release or draft from another | | **Publication Date** | Shows when the version was prepared or released | | **Owner** | Identifies who is responsible for the version | You should also review the related records linked to that version. If you plan to include attachments, approval notes, or project details in the export, make sure those records are already saved and up to date. A package exported too early may leave out supporting files or include outdated notes. Pay special attention to unfinished work. If the version still has open edits, pending approvals, or incomplete supporting records, the exported package may not be suitable for external review or compliance retention. If you already worked through readiness planning in [Managing Export Center Workflows](doc:managing-export-center-workflows), use that same decision process here and focus on the final record check before export. [SCREENSHOT: Documentation version detail page with status, title, version number, publication date, and owner visible] ## Exporting a Single Documentation Version Use a single-version export when you need one specific documentation package from Atloria. This is the most direct option for sending a version to a reviewer, preparing a release handoff, or saving a final copy for records. 1. Open the documentation version detail page for the version you want to export. Review the header area and confirm you are on the correct version by checking the **Title**, **Version Number**, and status. 2. Find the **Export** action in the page toolbar or in the actions menu. If you do not see it, stop and review the version status and required fields before continuing. 3. Choose the export scope. Select whether you want to export only the version content or include related records and attachments as part of the package. 4. Review the export options before starting. Pay close attention to the file name, version label, and any inclusion settings so the downloaded file is easy to identify later. 5. Start the export. Atloria will begin generating the file. 6. Watch the export until it finishes and the download becomes available. If the page shows an in-progress state, wait for completion before leaving the screen. A single-version export works best when you need a fixed snapshot of one documentation version rather than a collection of records. If the version is intended for review, keep the package focused and readable. If it is intended for archive storage, include the supporting records that belong with that version. After the file downloads, open it and confirm that the version label and contents match the record you exported. This quick check is especially important when several versions have similar names. [SCREENSHOT: Export menu on a documentation version detail page with scope and naming options] ## Exporting Multiple Versions and Related Records in Bulk Bulk export is the better choice when you need to download several documentation versions at once. In Atloria, this starts from the documentation versions list, where you can select multiple rows and run one export action across the whole selection. This is useful for release reviews, milestone handoffs, and archive preparation when several versions need to be collected together. 1. Open the documentation versions list view for the project or workspace you are working in. 2. Use the row checkboxes to select each version you want to include. Before moving on, compare the selected rows with the visible version titles and labels so you do not miss a record. 3. Open the bulk **Export** action. 4. Choose how the export should be packaged. If Atloria offers separate files per version, use that when each version needs to stand on its own. If it offers a combined package, use that when you want one bundle for review or storage. 5. Set the inclusion options for the whole batch. If you need attachments, linked references, or approval history, apply those choices consistently across all selected versions. 6. Start the bulk export and monitor its progress until the package is ready to download. 7. After download, compare the completed package with your original selection and verify that every chosen version is included. Consistency matters more in bulk exports than in single exports. If one version includes attachments and another does not, reviewers may assume something is missing. Before starting the export, make sure the selected versions are at a similar stage and that the same related records should travel with each one. If you are deciding whether to create separate files or one combined package, use the guidance in [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving) to match the export type to your audience. [SCREENSHOT: Documentation versions list with multiple row checkboxes selected and bulk Export action open] ## Using Exported Files for Review, Handoff, and Archiving Once a file is downloaded from Atloria, treat it as a fixed copy of the documentation version at that moment. For review, this is helpful because reviewers can inspect the package without needing access to the live version record or worrying that the content will change while they are reading it. A clean export is especially useful for structured review cycles, sign-off meetings, or external feedback. For stakeholder handoff, project administrators often use exported files as a formal package. A versioned file name, clear version label, and included metadata make it easier for recipients to understand what they received. When attachments and approval notes are included, the package becomes more useful for milestone reviews, release evidence, and audit requests because the supporting context travels with the documentation itself. For archiving, keep finalized exports together with the records that explain why that version mattered. In practice, that usually means storing the documentation export alongside approval evidence, supporting attachments, and any retention label or archive naming convention your team uses. The goal is not just to save the content, but to preserve enough context that someone can identify the package later without reopening Atloria. After every download, validate the package before sharing or storing it: - Confirm the **Version Number** matches the intended documentation version - Check that the file name clearly reflects the version label or date - Verify that attachments and related records are present if you selected them - Open the package and make sure the contents are complete and readable - Compare the downloaded package with the version record if anything looks incomplete This validation step is quick, but it prevents confusion later when several review and archive packages exist for the same project. ## Fixing Common Export Problems Most export issues in Atloria come from record readiness, selection choices, or missing inclusion settings. Start by checking the version record itself before assuming the export failed. If the **Export** action is unavailable on a documentation version, first review the record status. A version that is incomplete or not in the right stage may not be ready for export. Then check the required identifying fields such as **Title**, **Version Number**, **Publication Date**, and **Owner**. If those details are missing, update the version record and try again. If the button is still unavailable, your access level may not include documentation export. If the downloaded package is missing attachments or linked records, the most common cause is that those items were not included in the export settings. Reopen the export options and confirm that the package is set to include related records. Also verify that the attachments, approval notes, or linked details were saved on the version before you started the export. If a bulk export finishes with fewer files than expected, compare the completed package to the rows you selected in the versions list. Check whether any versions were filtered out, not actually selected, or not eligible for export. This is easiest to spot when you review the selected rows before starting the bulk action. If file names are hard to recognize after download, fix the record details before exporting again. Update the version label, publication date, and naming pattern so each package is easy to identify later. This is especially important when you are exporting drafts, approved versions, and superseded versions from the same project. For a deeper readiness check before rerunning an export, refer to [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). ## Overview This guide focuses on the practical side of managing documentation exports in Atloria after you have already planned your export workflow. Here, the emphasis is on choosing the right export scope, checking whether a documentation version is actually ready, running exports from both the version page and list view, and confirming that the downloaded files are complete enough for review or archive use. The main export situations covered in this guide are: - Exporting one documentation version from its detail page - Exporting several versions together from a list view - Including related records such as attachments, approval notes, and linked metadata - Preparing files for reviewer access, stakeholder handoff, or long-term retention - Correcting common issues when exports are incomplete or hard to identify later This guide does not repeat the workflow planning covered in [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records) or [Managing Export Center Workflows](doc:managing-export-center-workflows). Instead, it assumes you already know when an export is needed and helps you complete the export accurately from the screens where you work with documentation versions. As you follow the steps, keep your attention on the visible details that travel with the file after download: the version label, the publication date, the included attachments, and the related records selected in the export options. Those details are what make an exported package useful once it leaves Atloria and is shared with reviewers, stakeholders, or archive owners. [SCREENSHOT: Export Center workflow moving from version selection to completed download package] ## Prerequisites Before managing exports in Atloria, make sure the documentation version and its related records are in good shape. Export problems are much easier to prevent than to fix after files have already been shared. You should have the following in place: - Access to the project workspace that contains the documentation versions you need - Permission to open documentation version records and use the **Export** action - At least one documentation version with complete identifying details - Related records already saved if you plan to include them in the export - A clear decision on whether the export is for review, handoff, or archive storage Check these version details before you begin: | Item to confirm | What to look for | |---|---| | Version status | Draft, ready for review, or finalized, depending on your purpose | | Record details | **Title**, **Version Number**, **Publication Date**, and **Owner** are filled in | | Related records | Attachments, approval notes, and linked metadata are present if needed | | Selection scope | You know whether you are exporting one version or multiple versions | | Naming clarity | Version labels and dates are clear enough to identify after download | If you are working with several versions, it also helps to review the versions list first so you can select the correct rows for a bulk export. If you are preparing a formal release or retention package, confirm that approvals and supporting records are complete before you export. The next guide, [Choosing the Right Export for Review Release and Retention](doc:choosing-the-right-export-for-review-release-and-retention), helps you decide which export style fits each delivery or archive scenario. ## Finding the project setup choices you can still change After onboarding, you can return to a project’s setup decisions from the project workspace rather than starting over. In Atloria, open the project from your project list or dashboard, then go to the project’s settings area or project administration area where configuration details are shown. This is the place to review the choices made during onboarding and confirm whether they still match how the team plans to document the project. Look for the saved setup information in the project details view. Atloria surfaces the current project configuration so you can check what is already in place before editing anything. For this document, the setup decisions that matter most are: - **Project type** - **Connected source** or repository-related setup - Other saved project details that help you understand how the project was originally configured Before changing anything, compare the current values shown on screen with the setup approach your team intended to use. If you need a refresher on the original setup paths, refer back to [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). Some setup choices have a direct effect on later documentation work. In practice, **project type** and **connected source choices** can shape how documentation is organized, what guidance appears during authoring, and how imported structure influences planning. Other project details may simply describe the project and help teammates understand its context without changing documentation behavior in a major way. A quick review in the project details screen helps you avoid unnecessary changes. If the current values already match the team’s documentation plan, leave them as they are. If they no longer fit the project, update them from the same settings area so the rest of the documentation workflow stays aligned. [SCREENSHOT: Project settings or project details screen showing current project type and connected source information] ## Reviewing and changing the project type The **Project type** setting is one of the most important onboarding choices to revisit because it influences how your team structures documentation work. In Atloria, open the project’s setup or settings screen and find the field that shows the current project type selected during onboarding. Review the current value first so you know whether you are refining the setup or making a larger shift in direction. When you open the project type selection, compare the available options against the kind of documentation your team is actually building. A project that started with one documentation approach may later need a different structure if the audience, source material, or publishing goals have changed. The selected project type can affect the kind of documentation organization Atloria expects, including the shape of planning work and the guidance documentation managers see when creating content. To change it: 1. Open the project’s settings or setup screen. 2. Find the **Project type** field. 3. Select the new project type from the available options. 4. Review the rest of the visible setup details to make sure they still fit the new choice. 5. Click **Save** or the available update action. After saving, watch for any on-screen confirmation, updated field value, or change in related setup information. If Atloria refreshes the project view or updates planning behavior afterward, treat that as a sign that the new project type is now active. Because project type can influence templates, expected sections, and generated guidance, change it carefully when documentation work has already started. A different project type may cause documentation managers to see a different structure or set of expectations in later screens. If your team is already drafting pages, review those areas after saving so you can confirm the new setup still supports the documentation plan. [SCREENSHOT: Project settings screen with the Project type field expanded and ready to save] ## Reassessing connected sources before updating setup If your project was set up with a connected source, review that connection before changing any setup choices tied to it. In Atloria, the current connected source is typically shown in the project settings or related project configuration area. Start by checking what source is currently linked so you can confirm whether the original connection still reflects the project your team is documenting. A connected source can shape how Atloria understands the project and how your team approaches authoring. If the source has changed significantly since onboarding, the original setup may no longer be the best fit. For example, the connected source may now have a different structure, incomplete content, or access limitations that make imported or detected information less reliable for documentation planning. Before updating source-related setup, verify these points in the project settings and related source views: - The correct source is connected to the project - The source is complete enough to support documentation work - The branch or workspace selection still matches the material your team wants to document - The connection is ready for sync or refresh if Atloria uses source information in the project workspace - The team still has the access needed to keep using that source These checks matter because source-related setup decisions can influence later documentation work. Imported content, detected structure, and source-driven planning cues may shape what documentation managers expect to see when they begin organizing pages. If the connected source no longer matches the project’s real scope, those expectations can drift away from the actual documentation goal. Make source changes only after confirming what the team needs from the project. If you are unsure whether to keep the current connection or move to a different setup path, compare your current project with the setup guidance in [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). [SCREENSHOT: Project settings area showing connected source details and related connection status] ## Understanding how setup changes affect documentation work Changing setup after onboarding does more than update a field in project settings. In Atloria, these choices can flow into the documentation workspace and influence how the team plans, drafts, and reviews content. That is why project administrators should connect every setup change to the work documentation managers are already doing. A revised **Project type** can change the expected shape of documentation. Depending on the selected type, Atloria may guide the team toward different content areas, planning assumptions, or page structures. Documentation managers may notice changes in how they organize content, what sections seem necessary, or what guidance appears when they begin creating documentation. If the team has already agreed on a structure, even a small setup change can shift those expectations. Changes to the **connected source** can also affect downstream work. If Atloria uses source information to shape planning, imported structure, or suggested content direction, updating the source setup may change what appears relevant in the project workspace. Existing drafts may still be present, but the context around them can change. Teams may need to revisit page plans, section groupings, or assumptions about what the source covers. Pay special attention to these areas after a setup update: - Project organization in the documentation workspace - Recommended content areas or planning views - Guidance shown during documentation creation - Existing drafts that were based on earlier setup assumptions - Team workflows that depend on source-driven structure When active documentation work is already underway, coordinate setup changes with the people managing content. A project administrator may be able to save the new configuration quickly, but the documentation team may need to adjust outlines, templates, or page priorities afterward. If you change setup without warning, teams can end up revising work they already started. For broader project administration context, see [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). ## Updating setup safely in active projects When a project is already in use, treat setup changes as controlled updates rather than quick edits. In Atloria, start by checking whether documentation work is already in progress. Open the project workspace and review whether the team has begun planning pages, drafting content, or organizing documentation structure. If work is active, make sure the people responsible for that content know a setup change is being considered. Use this approach to reduce disruption: 1. Review the current **Project type** and **Connected source** values in the project settings screen. 2. Record the current selections somewhere your team can reference during review. 3. Decide which single change is most important to make first. 4. Update only that one field and click **Save**. 5. Reopen the project details and documentation areas to see what changed before editing anything else. 6. Share the updated setup with documentation managers so they can confirm whether templates, sections, or planning guidance still make sense. Making one change at a time is especially important when both project type and source setup may need adjustment. If you change several fields together, it becomes much harder to tell which update caused a shift in documentation behavior. It also helps to compare the old and new setup states directly. Even a simple note of the previous project type and previous connected source can save time if the team later notices unexpected differences in planning views or authoring guidance. If your project has active contributors, communicate clearly before and after the change. Documentation managers need to know when setup updates may affect expected sections, source-driven planning, or content structure. That coordination is often the difference between a smooth update and unnecessary rework. [SCREENSHOT: Project settings screen before saving a setup change, with current values visible for comparison] ## Verifying the updated setup After saving any setup change, return to the project settings or details screen and confirm that the new values are actually stored. In Atloria, the first check is simple: make sure the **Project type** field now shows the updated selection and that the **Connected source** area reflects the current source choice. If the old values still appear, the change may not have been saved. Next, move beyond the settings screen and verify that the update is reflected where documentation work happens. Open the project overview, documentation workspace, or any planning view available in the project. Look for signs that the new setup is influencing downstream behavior. Depending on what changed, this may include updated guidance, a different planning emphasis, or documentation expectations that better match the revised project direction. If the project uses a connected source, also confirm that source-related information still works after the update. Check whether the source remains accessible and whether any visible sync or imported structure indicators still look correct. You are not just confirming that the connection exists—you are confirming that it still supports the documentation workflow your team expects. A practical final check is to open an existing documentation item or start a new one and compare what you see with the revised setup. Review whether the structure, guidance, or expected sections now align with the updated project type and source choice. If something still looks out of place, return to the project settings and compare the saved values again before making further changes. This verification step is worth taking every time. It confirms that the project configuration and the documentation workspace are still moving in the same direction. [SCREENSHOT: Project details and documentation workspace showing updated setup reflected in planning or authoring views] ## Overview This guide focuses on the setup decisions that project administrators can revisit after onboarding is complete. In Atloria, the most important editable choices discussed here are the project’s **Project type** and its **Connected source** setup. These are not just descriptive settings. They can influence how a project is organized for documentation, what planning guidance appears, and how source-linked information shapes later authoring work. Use this guide when a project has changed since onboarding, such as when the team chose the wrong setup path initially, the connected source no longer reflects the real project, or the documentation plan has shifted. Instead of repeating the onboarding flow, you return to the project settings or project details area, review the saved configuration, and update only the fields that still need adjustment. This document builds on [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup) rather than repeating it. If you are still deciding between setup approaches, read that guide first. Here, the focus is on what happens after those initial choices have already been saved and the project is moving into documentation work. The sections above walk through four practical tasks: - Finding the saved setup values in the project - Changing the project type carefully - Rechecking connected source decisions before updating them - Verifying how those changes affect the documentation workspace Because setup changes can affect templates, expected sections, and source-driven planning, this guide also emphasizes coordination with documentation managers. That is especially important in active projects where drafts or content plans already exist. The next step in this workflow is [Planning Project Structure Before Document Authoring](doc:planning-project-structure-before-document-authoring), where you turn the confirmed setup into a workable documentation structure. ## Prerequisites Before you update onboarding decisions in Atloria, make sure you have access to the project and can open its settings or project administration area. You need to be able to review the current project details and save changes to setup fields. If you cannot reach those areas, resolve your access first through the appropriate project or administrative workflow. Have these items ready before you begin: - A project that has already completed onboarding - Access to the project workspace and its settings or configuration area - A clear understanding of the project’s current documentation goal - Agreement from the team on whether the **Project type** or **Connected source** should change - Awareness of any documentation work already in progress It also helps to gather a few details in advance so you can compare the current setup with the intended one: - The currently saved **Project type** - The currently displayed connected source information - Whether the connected source still has the right content, structure, and access - Whether documentation managers have already created outlines, drafts, or planning work based on the old setup If your team is still deciding whether the project should use a manual setup or a connected source approach, review [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup) before making changes here. For active projects, plan a short review with the people managing documentation so they can confirm the impact of any update. That is especially useful when setup changes may alter templates, expected sections, or source-driven planning. A small amount of coordination before editing the project settings can prevent larger cleanup work later. ## Opening the support agent workspace and understanding what each area controls In Atloria, open the main workspace for support agents from the signed-in area of the product. This workspace is where you review existing agents, start a new one, and check whether each agent is ready for use. The screen is organized around a few practical areas that help you move from setup to launch without leaving the workspace. The first area to look for is the **agent list**. This is the main list of all support agents already created in Atloria. Team leads can use this list to scan agent names, identify which agent they want to work on, and quickly spot whether an agent is still being prepared or is already available. When you click an agent in the list, Atloria opens that agent’s details so you can continue setup. Next is the **agent detail panel**. This is where you review the selected agent’s setup information, including its intended use, whether it is available, and which project knowledge it is connected to. If you need to adjust setup, this is the area you return to most often. You should also expect to see **availability controls** in the workspace. These controls show whether an agent can currently be used. An unavailable agent is still in setup. An available agent is ready for the audience it was prepared for. Another key area is **project knowledge connections**. This part of the workspace shows which project or documentation source the agent will use when answering questions. Before marking an agent available, confirm the correct knowledge source appears here. Primary actions in this workspace include: - **Create** a new support agent - **Open** an existing agent from the list - **Edit** setup details in the detail view - **Review** connected knowledge sources - **Check** status and availability before sharing [SCREENSHOT: Support agent workspace showing the agent list, selected agent details, availability area, and connected project knowledge] If you already worked through embedding and day-to-day operation in [Embedding and Operating Support Agents in Documentation Experiences](doc:embedding-and-operating-support-agents-in-documentation-experiences), this screen is the place where you control whether those experiences are actually ready to be used. ## Creating a new support agent Use the support agent workspace when you need to add a new agent for a team or a reader-facing documentation experience. Start by clicking the **create-agent** action shown in the workspace. Atloria opens a setup form for the new agent so you can enter the basic details that identify how it will be used. 1. In the support agent workspace, click the option to create a new agent. 2. Enter the **agent name** exactly as you want it to appear in the agent list. 3. Complete any **role** or **usage designation** shown in the setup form. This helps distinguish whether the agent is being prepared for internal team support or for readers using published documentation. 4. Review the information you entered before saving. 5. Click **Save** to create the new agent. After you save, Atloria adds the new agent to the **agent list**. At this point, it should appear with an initial setup state rather than as fully available. That early state is useful because it lets you confirm the agent record exists before you connect knowledge or change availability. Once the new agent appears in the list, click its name to open the **detail view**. This is where the rest of the setup happens. From there, you can review the audience designation, connect the right project knowledge, and decide whether the agent should remain unavailable while you finish configuration. A good way to confirm the creation step worked is to check for these signs in the workspace: - The new agent appears in the list immediately after saving - The name matches what you entered - The agent opens correctly in the detail panel - The setup still shows as incomplete or not yet available until you finish the remaining steps [SCREENSHOT: New support agent form with the name field, audience or usage selection, and Save button] If you need broader setup guidance for agent records and conversation use, see [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents). ## Configuring when the agent is available Availability controls determine whether people can actually use the support agent. In Atloria, you manage this from the selected agent’s detail view. This is one of the most important parts of setup because an agent can exist in the workspace without being ready for access. 1. Open the support agent from the **agent list**. 2. In the **agent detail view**, find the **availability** setting or status control. 3. Change the agent to the state you want for the current stage of setup. 4. Save the change if Atloria prompts you to confirm it. 5. Return to the list and verify the updated status appears there as well. When an agent is marked as unavailable, it stays in a preparation state. This is the right choice while you are still checking the agent name, audience, or connected project knowledge. Keeping it unavailable helps prevent the wrong people from using an unfinished agent. When you are satisfied with the setup, change the availability state so the agent is ready for active use. Atloria reflects that change in two places: - In the **agent list**, where you can quickly scan readiness across all agents - In the **detail panel**, where the current status is shown for the selected agent This makes it easier for team leads to review multiple agents and see which ones are still being prepared. Use availability carefully based on the audience: - Keep the agent **unavailable** if its knowledge source is missing or still being reviewed - Keep the agent **unavailable** if the audience designation is not final - Mark the agent **available** only after the setup matches the intended use - Recheck the list after saving so you can confirm the status changed as expected [SCREENSHOT: Agent detail view with the availability control and visible status indicator] If you need deeper guidance on audience and access planning, refer to [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability). ## Connecting project knowledge to the agent A support agent is only useful when it is connected to the right project knowledge. In Atloria, the support agent workspace shows these knowledge connections in the selected agent’s setup area. This is where you confirm what source material the agent will rely on when answering questions. 1. Open the agent you want to review from the **agent list**. 2. In the **detail view**, locate the section that shows **project knowledge connections**. 3. Check which project or documentation source is currently attached. 4. Compare that connection with the content the agent is supposed to answer from. 5. If the wrong source is shown, update the connection before making the agent available. The connected project knowledge acts as the agent’s answer source. In practical terms, that means the quality and relevance of responses depend on whether the correct project or documentation set is attached. If the agent is meant to help an internal team with one project, make sure that project is the one shown in the connection area. If the agent is meant for readers, confirm the linked documentation matches what readers will be asking about. There is an important difference between these two setup states: - **Agent with project knowledge connected:** the workspace shows a specific project or documentation source attached, and the agent is much closer to being ready - **Agent without project knowledge connected:** no source is attached yet, so the agent should stay unavailable until this is completed Before you enable the agent, review the connection carefully. A correctly named agent can still give unhelpful answers if it points to the wrong project knowledge. Helpful checks in this section include: - The connected source name matches the intended project - The agent’s audience matches the attached knowledge - No empty or missing knowledge connection is shown - The connection is reviewed before changing availability [SCREENSHOT: Agent detail panel showing the connected project knowledge section with the selected project or documentation source] For more detailed guidance on linking knowledge and project sources, see [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup) and [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking). ## Preparing the agent for team use or reader use In Atloria, support agents are not all prepared for the same audience. Some are intended for internal team use, while others are meant for readers in documentation experiences. The support agent workspace includes labels, audience choices, or usage designations that help you tell these apart. Review this setting early, because it affects the rest of the setup. 1. Open the agent in the support agent workspace. 2. Find the **audience**, **role**, or **usage designation** shown in the setup details. 3. Confirm whether the agent is intended for **team use** or **reader use**. 4. Review the connected project knowledge to make sure it fits that audience. 5. Check availability only after the audience and knowledge source both match the intended use. For **team use**, the main goal is to support internal users working inside Atloria. Before sharing the agent with a support team, confirm: - The agent name clearly identifies its purpose - The audience or usage label points to internal team use - The connected project knowledge matches the team’s working documentation - The availability status is set only after setup is complete For **reader use**, the setup needs extra care because the agent may be exposed in a documentation experience. Before making it available for readers, confirm: - The audience or usage label is set for reader-facing use - The connected knowledge source matches the published or intended reader content - The availability state is correct for public or reader access - The agent is not still carrying an internal-only setup Audience choice affects nearly every decision in this workspace. A team-facing agent can be confusing if it is connected to reader documentation, and a reader-facing agent should not go live if it was prepared with the wrong audience in mind. [SCREENSHOT: Agent setup view showing the audience or usage designation for team use versus reader use] If you are planning how the agent appears in documentation, pair this setup work with [Embedding and Operating Support Agents in Documentation Experiences](doc:embedding-and-operating-support-agents-in-documentation-experiences). ## Verifying your setup before the agent goes live Before you treat a support agent as ready, use the workspace to verify the full setup from top to bottom. This final check helps you catch the most common issues: the wrong audience, missing project knowledge, or an agent that still shows as unavailable. 1. In the **agent list**, confirm the agent appears with the expected **name**. 2. Open the agent and verify its **audience designation** or usage label. 3. Check the **availability state** in the detail view. 4. Review the **project knowledge connection** and confirm it matches the content the agent should answer from. 5. Use the same workspace preview or access point your team uses to test whether the agent is reachable by the intended audience only. When you run this review, compare what you see in the list with what you see in the detail panel. The list gives you a quick summary, but the detail view is where you confirm the full setup. If those two views do not match your expectations, stop and correct the setup before sharing the agent. Common setup gaps to look for include: - The agent is still **unavailable** - No **project knowledge connection** is shown - The wrong project or documentation source is attached - The audience is set for **team use** when it should be for readers - The audience is set for **reader use** when it should remain internal A short test from the same entry point used by your team is especially useful. If the agent should be internal, make sure it is not being exposed more broadly. If it is intended for readers, confirm the experience matches the correct documentation context. [SCREENSHOT: Final setup review showing agent name, audience label, availability status, and connected project knowledge in one view] The next step after this readiness check is refining how the agent behaves in its final experience. Continue with [Configuring Support Agent Behavior and Embedded Experiences](doc:configuring-support-agent-behavior-and-embedded-experiences). ## Overview Managing support agent setup and availability in Atloria centers on four decisions: which agent you are working on, who it is for, what knowledge it can use, and whether it is currently available. The support agent workspace brings those decisions together so you can review them from one place instead of checking separate areas. The most important screen elements in this workflow are the **agent list** and the **agent detail view**. The list helps you scan all existing agents and spot their current readiness. The detail view lets you inspect one agent closely and confirm its name, audience designation, availability state, and connected project knowledge. If you are responsible for several agents, these two areas are the fastest way to see what still needs attention. Availability should always be treated as the last major setup decision, not the first. An agent can be created and saved before it is ready for use, and that is often the safest approach. Leave the agent unavailable while you confirm the audience and knowledge connection. Once those pieces are correct, you can update the availability state and verify that the list reflects the change. This document focuses on setup and readiness. It does not repeat the broader creation workflow from [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) or the knowledge-planning guidance in [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup). Instead, use this guide when you need to answer practical questions such as: - Is the agent created and visible in the workspace? - Is it meant for team use or reader use? - Is the right project knowledge connected? - Is the availability state correct for launch? When those answers are clear in the workspace, the agent is much easier to manage confidently. ## Prerequisites Before you work through support agent setup in Atloria, make sure you can access the signed-in workspace where support agents are managed. You do not need every related feature configured in advance, but you do need enough information to complete the setup without guessing. You should have the following ready: - Access to the **support agent workspace** in Atloria - A clear decision about whether the agent is for **internal team use** or **reader-facing use** - The **agent name** you want to use in the workspace - The correct **project** or **documentation knowledge source** the agent should be connected to - Permission to review or update the agent’s **availability** setting It also helps if you have already completed the earlier support agent documents, especially: - [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) - [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup) - [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability) If your team plans to use the agent in a documentation experience, you should also be familiar with: - [Embedding and Operating Support Agents in Documentation Experiences](doc:embedding-and-operating-support-agents-in-documentation-experiences) Before you begin, confirm these practical points with your team: - Which audience should be able to use the agent first - Which project knowledge should be attached at launch - Whether the agent should remain unavailable until a final review - Who will verify the setup from the workspace before it goes live Having these answers in place makes the setup process much smoother, because every field and status you review in the workspace can be checked against a clear plan rather than adjusted later. ## Checking who can change version access In Atloria, version access changes should be handled by the people who manage documentation releases for a project, typically a **Documentation Manager** or **Project Administrator**. If you can already work with project versions, review release settings, and manage project-level controls, you are usually the right person to update who can see a version. If those options are missing when you open a version, you may need someone with broader project access to make the change for you. Before you look for any sharing or visibility setting, make sure the version already exists in the project. Open the project, go to the **Versions** area, and select the version you want to manage from the version list. You need to be on the version’s own details screen before you can review its access state. If you are still comparing drafts or waiting on approvals, it is better to confirm you are editing the correct version record first. On the version details page, look for the area that controls **visibility**, **sharing**, or **reader access**. This is where Atloria lets you decide whether a version is broadly available, limited to a smaller group, or not shared at all. The exact wording may vary slightly depending on the project setup, but the control will be part of the version’s settings rather than the document editor. It also helps to check whether the version is still being prepared or is ready for readers. A version that is missing pages, screenshots, approvals, or audience checks may technically be shareable, but it may not be ready to expose. If you need a refresher on how access modes affect readers, see [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes). [SCREENSHOT: Version details page showing the visibility or sharing controls] ## Choosing the right access mode for a version When you choose a version access mode in Atloria, you are deciding two separate things: whether people are allowed to read the version, and whether the version is easy for them to find. That difference matters. A version can be readable through a direct link while still being kept out of general browsing areas such as version selectors or navigation. The most common access choices can be understood like this: | Access mode | What readers can do | Where it may appear | |---|---|---| | Fully visible | Readers can open and use the version normally | May appear in navigation, version selectors, and shared entry points | | Restricted | Only approved or permitted readers can open it | May be limited in discovery, even if a direct link exists | | Not shared | Readers cannot access the version | Does not appear as an available version for general readers | Use **fully visible** when the version is ready for normal reading and should be available as part of the project’s published documentation experience. This is the right choice when the content has passed review and you want readers to discover it naturally. Use **restricted** when the version needs a controlled release. This is useful for internal review, stakeholder sign-off, or limited testing before wider publication. In this mode, you can allow access without making the version broadly discoverable. Use **not shared** when the version is still in preparation, contains incomplete material, or should remain hidden until release day. If you need more detail on visibility and export decisions, refer to [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness) and [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access). ## Updating version visibility and saving the change 1. Open your project in Atloria and go to the **Versions** list. 2. Find the version you want to update and open its version details page. Make sure you are changing the correct version, especially if several versions have similar names or are in review at the same time. 3. In the version settings area, locate the current **visibility**, **sharing**, or **access** setting. Atloria shows the current state on the version record, so you can confirm whether the version is already visible, restricted, or not shared before making changes. 4. Select the access mode that matches your goal: - Choose the broadest option when the version is ready for normal reader access. - Choose a restricted option when you want limited review or controlled sharing. - Choose the hidden or unshared option when the version should not be available yet. 5. Save the change using the available action on the page, such as **Save**, **Update**, or the version publishing control if the screen combines release and access settings. Do not leave the page until the save finishes and the updated state is shown. 6. Check the version record again after saving. Atloria should display the new access state on the page so you can confirm the change took effect. If the old state still appears, refresh the page and verify that the update was actually stored. 7. If the version is meant for immediate reader use, test the outcome from the reader side by opening the version through the same entry point your audience will use, such as version switching or a shared link. [SCREENSHOT: Version settings panel with the access mode selected and saved] ## Understanding what readers experience in each sharing state Reader experience changes noticeably depending on the version’s sharing state. When a version is fully available in Atloria, readers can open it normally and move through the documentation without interruption. If the version is intended for general use, it may also appear in places readers expect to browse, such as version selectors, navigation choices, or other visible version entry points. Restricted versions behave differently. A reader might receive a direct link, but if they do not have the right access, Atloria does not simply show the content. Instead, the reader is blocked from opening the version and sees an access-related message or unavailable state. This is important for controlled release because it lets you share a link structure without exposing the documentation itself to everyone who receives it. Hidden or unshared versions are generally not discoverable. Readers should not expect to find them in search, navigation menus, or version switchers. If a version is intentionally kept out of discovery, that does not always mean it is broken. It may be readable only in a limited way, or it may be completely unavailable until release. This is why “readable” and “discoverable” should be treated as separate decisions when you manage access. Atloria’s unavailable and access-denied states help readers understand what happened. Instead of silently failing, the interface signals that the version is either restricted, not currently shared, or not available to that reader. If you are planning a staged release, this behavior is useful because it prevents confusion while still protecting in-progress content. For a broader explanation of reader outcomes, see [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes). ## Preparing a version for sharing or controlled release Before you expose a version to readers, review whether the content is actually ready to be seen. In Atloria, that means more than checking whether the version exists. Open the version details page and confirm the version includes the pages, updates, screenshots, and audience-facing material you expect readers to see. If the version is part of a release process, make sure internal review is complete and any required approvals have already been handled. A restricted access mode is the safest choice when stakeholders need to validate the version before public release. This lets you share the version with a smaller group without placing it into normal reader discovery. It is especially useful when teams need to check wording, structure, screenshots, or release timing in a near-final state. You should also coordinate the visibility change with your release schedule. If you make a version broadly visible too early, readers may encounter incomplete material, outdated screenshots, or pages that are still being revised. Keeping the version restricted until the planned release time helps avoid accidental exposure. When the review group confirms the version is ready, return to the version’s access setting and move it from restricted access to a broader visible state. This final switch should happen only after the version has passed internal review and is ready for normal reader traffic. If you are still checking whether a version is safe to expose, use [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export) alongside your release review process. [SCREENSHOT: Version details page reviewed before switching from restricted to visible] ## Fixing common access and sharing problems If a version does not appear for readers after you shared it, start by reopening the version details page and checking the saved access setting. In Atloria, the most common issue is that the intended visibility change was selected but not actually saved. Confirm the version record now shows the expected state. If it still shows the old state, save the change again and refresh the page. If readers can open a link but see an access error, the version is likely still in a restricted state or limited to a smaller set of people than expected. Review the version’s sharing setting and confirm whether the audience you are testing with should truly have access. A direct link does not override restrictions. Atloria will still block readers who are outside the allowed group. If a version becomes visible too early, go back to the version settings immediately and switch it to a more limited state, such as restricted or not shared. This removes broad exposure while you finish review. After saving, test the version again from the reader side to confirm it no longer appears where it should be hidden. If the expected version is missing from selectors, menus, or navigation, do not assume the version is unavailable. It may still be readable through a direct link while intentionally hidden from discovery. Check whether the version was set to be accessible without being broadly listed. When troubleshooting, compare what you expected readers to see with where they are trying to access the version: - **Direct link works, but version is not listed:** likely hidden from discovery - **Link opens an access message:** likely restricted - **Version is missing everywhere:** likely not shared or not saved correctly - **Version appears too broadly:** visibility is set wider than intended The next step is [Validating Version Access Before Public Release](doc:validating-version-access-before-public-release). ## Overview This guide focuses on the practical side of managing version access outcomes in Atloria after you already understand the basic access modes. Instead of repeating the definitions covered in [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes), this document shows how to apply those choices on a real version record and how to predict what readers will experience once the change is live. The main tasks covered here are: - Checking whether you are the right person to change a version’s visibility - Opening the correct version from the **Versions** list - Choosing between visible, restricted, and not shared states - Saving the updated access setting on the version details page - Confirming whether readers can discover the version, open it directly, or are blocked - Correcting common mistakes when a version appears too early or does not appear at all This topic is especially useful when you are managing staged releases. In many Atloria projects, a version is not simply either “published” or “unpublished.” You may need to let a small review group open the version first, keep it out of version selectors until launch, or temporarily remove it from reader view while updates are still in progress. Those are the sharing outcomes this guide helps you manage. Use this document when you are actively changing a version’s exposure and need to confirm the result from a reader’s point of view. If you are still deciding whether the version is ready for exposure at all, pair this guide with your version review and release checks. ## Prerequisites Before you work through version access changes in Atloria, make sure the following are already in place: - You can sign in to Atloria and open the correct project workspace. - The project already has at least one existing version in the **Versions** list. - You have access to version-level settings, typically as a **Documentation Manager** or **Project Administrator**. - You know which version you are updating and whether it is meant for internal review, limited sharing, or broader reader access. - The version has reached a point where sharing decisions make sense, even if it is still restricted for review. - You understand the difference between a version being readable and being discoverable. If needed, review [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes). It also helps to have these decisions ready before you open the version settings: - Whether the version should appear in normal reader browsing - Whether only a limited group should be able to open it - Whether the version should stay hidden until a planned release time - Whether you need to test the result using a direct link or reader-facing navigation If your team is still reviewing content quality, approvals, or release timing, you may want to pause before changing visibility. In that case, review your version readiness process first and return to this guide when the version details page is ready for an access update. ## Opening the AI activity dashboard and confirming access In Atloria, AI activity monitoring is typically handled from the admin side of the workspace rather than from everyday document editing screens. If you already worked through [Managing AI Usage and Request History](doc:managing-ai-usage-and-request-history), use that as your starting point for where AI-related controls live. For monitoring, open the main signed-in area and go to the **Admin** workspace. From there, look for cards and menu items related to usage reporting, especially **Analytics** and other AI-related settings areas. The **Admin** workspace includes sections such as **Users & Permissions**, **Organizations**, **Documents**, **Projects**, and **Analytics**. Open **Analytics** when you want a reporting-style view of activity. Depending on your access level, you may also review AI-related information from workspace settings or project-level areas where AI features are managed. Administrators usually have the broadest visibility, while team leads may only see activity tied to their own workspace, team, or assigned projects. When the dashboard opens, first confirm the filters at the top of the page before you interpret anything. If available in your Atloria workspace, check these controls: - **Date range** - **Team** or **Project** - **User** - Any tab or switcher for **Usage**, **Requests**, or **Activity** These controls matter because the same screen can show very different totals depending on the selected scope. On first load, expect a summary view rather than a full investigation screen. Atloria may show headline metrics such as: - Total AI requests - Active users - Consumption totals - Recent request entries If the **Analytics & Insights** page currently shows a coming-soon message in your workspace, that means the reporting area is present in navigation but not yet available for detailed review. In that case, continue using the AI usage and request history areas you already learned in [Managing AI Usage and Request History](doc:managing-ai-usage-and-request-history). [SCREENSHOT: Admin workspace with the Analytics card highlighted] ## Reviewing AI usage totals across teams, users, and time periods Once you are in the AI usage or activity area, start with the summary metrics before opening individual request records. These top-level numbers help you answer basic questions quickly: who is using Atloria’s AI features most, whether usage is increasing, and whether activity is spread across teams or concentrated in one area. Read the top cards first. In a typical usage view, these cards summarize: - Total request count - Overall AI consumption - Active users during the selected period - Team, workspace, or project totals If your Atloria workspace includes breakdown cards, compare them side by side instead of looking at one number in isolation. A high request count from one project may be normal if that project has many contributors, while a smaller team with the same volume may deserve a closer look. Use the **Date range** control to compare patterns over time. Daily views help you investigate a sudden spike. Weekly and monthly views are better for spotting sustained changes, such as a team adopting AI-assisted drafting more heavily over several release cycles. When you change the date range, recheck the totals and any trend line or summary table below it. Then narrow the scope with the available filters: 1. Select the broadest level first, such as the full organization or workspace. 2. Switch to a specific **Team** or **Project** to see where usage is concentrated. 3. Apply a **User** filter if you need to understand one person’s activity. 4. Compare the filtered totals against the broader view. Trend charts and summary tables are most useful when read together. The chart shows when activity rose or dropped, while the table helps you identify which users or groups drove that change. If one team appears at the top of both the chart and the breakdown list, that is usually where you should investigate next. [SCREENSHOT: AI usage dashboard showing summary cards, date range selector, and team filter] ## Inspecting individual request history and response details After you identify a time period or team worth reviewing, move from summary totals into the request history list. This is where you confirm what actually happened rather than relying only on totals. In Atloria, the request list is the most useful view for checking whether a spike came from normal drafting work, repeated retries, or failed AI actions. Open the **Requests** or **Activity** tab if your workspace separates summary reporting from request-level history. In the list, review the visible columns first. Depending on what your Atloria workspace shows, common details include: | Column | What to look for | |---|---| | **Timestamp** | When the request happened | | **User** | Who submitted it | | **Model** | Which AI option handled the request | | **Status** | Whether it completed or failed | | **Project** or **Workspace** | Where the request came from | Use filters before opening individual rows. This is faster than scrolling through a long list. Narrow the log by: - **User** - **Status** - **Model** - **Date** - **Project** or **Workspace**, if available Once you find the request you need, select the row to open its detail view. The detail panel or detail page may include the original prompt, the generated response, how long the request took, and usage-related details tied to that interaction. This view is especially helpful when a user reports that AI output looked incomplete or when a team lead wants to confirm whether a request actually ran. Pay close attention to the **Status** indicator. Completed requests show successful activity. Failed, canceled, or rate-limited requests point to a different kind of issue. If several entries from the same user or project share the same non-success status, you are no longer looking at normal usage volume—you are looking at a pattern that needs follow-up. [SCREENSHOT: Request history list with filters and one request detail panel open] ## Understanding activity patterns and spotting unusual usage AI monitoring becomes more useful when you stop looking at single requests and start comparing patterns. In Atloria, unusual activity is often easier to spot when you move back and forth between the summary dashboard and the request history list. One view tells you that something changed; the other tells you what caused it. Start by comparing high-volume users or teams against their usual baseline. A writer working on a large documentation release may naturally generate more AI requests than usual for a few days. That is different from a sudden jump with no matching project activity. Look for changes that stand out from the team’s normal rhythm rather than assuming every spike is a problem. Watch for patterns such as: - Repeated failed requests from the same user - Short bursts of many requests in a narrow time window - Heavy concentration in one project or workspace - Activity appearing outside the team’s normal working period - One AI feature driving most of the consumption If your Atloria view includes model-level or feature-level breakdowns, use them to understand what kind of work is generating demand. For example, chat-style assistance, drafting, or summarization may each create different request patterns. A rise in drafting activity during a release cycle may be expected. A burst of repeated failed requests in one feature is more likely to indicate confusion, misuse, or a workflow problem. The most reliable way to judge unusual usage is to compare aggregate and detailed views together: 1. Use the summary dashboard to find spikes, dips, or top users. 2. Open the matching request history for that same period. 3. Check whether the entries reflect real documentation work. 4. Confirm whether statuses, timing, and volume look consistent. This combined approach helps you separate legitimate high activity from wasteful retries, accidental overuse, or behavior that needs policy review. ## Using usage insights to manage AI-assisted operations responsibly The goal of monitoring is not just to collect numbers. In Atloria, usage insights are most valuable when they help you improve how teams use AI in documentation work. Once you identify patterns, turn them into practical decisions about guidance, access, and review expectations. Use per-user and per-team activity data during coaching conversations. If support agents, writers, or project contributors rely heavily on AI for first drafts, that may be completely appropriate. What matters is whether the request history shows productive use or repeated low-value activity. For example, a team with steady completed requests tied to active project work may simply be using Atloria effectively. A user with many failed or repeated requests may need help choosing the right workflow. You can use monitoring results to support decisions such as: - Clarifying when AI drafting is appropriate - Reinforcing manual review before publishing - Reviewing who needs access to AI-assisted features - Identifying teams that would benefit from additional guidance - Escalating recurring concerns to administrators Request patterns can also reveal where AI is helping most. If one team consistently uses AI during document creation and still moves smoothly through review, that is a strong signal that the workflow is working. If another team shows heavy request volume but frequent retries or poor output quality, that may indicate a need for tighter review steps or better prompt habits. When activity raises concerns—such as overuse, repeated failed interactions, or prompts that suggest sensitive-content handling—coordinate with administrators through the appropriate admin areas. Atloria’s **Admin** workspace, including **Users & Permissions**, **Organizations**, **Security & Audit**, and **Analytics**, gives you the right places to align usage findings with access and policy decisions. For broader admin follow-up, see [Using the Admin Workspace](doc:using-the-admin-workspace) and [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls). ## Resolving common issues when reviewing AI activity If AI activity does not look right in Atloria, the issue is often caused by filters, visibility limits, or timing differences between summary totals and request-level history. Before assuming data is missing, work through the screen controls carefully. If no activity appears in the dashboard, start with the filters at the top of the page. A narrow **Date range** or the wrong **Team** or **Project** can make the dashboard look empty even when requests exist. Also confirm that you are looking in the correct workspace area for AI monitoring rather than a general admin page that does not yet include live reporting. If your **Analytics & Insights** page shows a coming-soon notice, use the AI usage and request history screens instead. If a team lead cannot see expected request history, the most likely cause is limited visibility. Team leads may only be able to review activity for assigned teams, workspaces, or projects. In that case: - Check whether the correct team or project is selected - Remove extra user filters - Confirm the person is opening the right admin or workspace area - Ask an administrator to verify access if broader visibility is needed If usage totals do not match the recent request list, compare like with like. Summary cards may reflect an aggregated period, while the request list may show only the currently filtered entries. Some summaries may also differ from visible request rows if failed requests are counted separately or if totals refresh on a delay. If you cannot find a specific request, narrow the search instead of broadening it. Try a shorter time window, then add the **User** filter and **Status** filter. Requests with failed or rate-limited outcomes are easier to find when you isolate those statuses directly. [SCREENSHOT: Filter bar with date range, team, user, and status controls] ## Overview This guide focuses on monitoring AI activity after AI usage tracking is already familiar. Instead of repeating the basics from [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history) and [Managing AI Usage and Request History](doc:managing-ai-usage-and-request-history), the emphasis here is on reading activity patterns, checking request details, and using those findings to support responsible team operations. In Atloria, AI monitoring usually involves two connected views: - A summary area that shows totals, trends, and top usage patterns - A request history area that shows individual AI interactions You use the summary view to answer questions like “Which team is driving most AI activity this week?” or “Did usage spike after a release started?” You use the request list to answer more specific questions like “Which user submitted these requests?” or “Were these requests completed, failed, or retried?” This matters most for administrators and team leads who need to balance productivity with oversight. Atloria supports AI-assisted work across documentation, support, and project workflows, so request volume alone does not tell the full story. A large increase may reflect healthy adoption, or it may point to repeated retries, unclear guidance, or access that needs review. As you work through this guide, stay focused on three tasks: - Confirm you are viewing the right scope with the right filters - Compare totals and trends before judging individual behavior - Use request details to validate whether unusual activity is expected The next document, [Reviewing AI Usage and Request Activity](doc:reviewing-ai-usage-and-request-activity), builds on this by helping you turn monitoring findings into a more formal review process. ## Prerequisites Before you monitor AI activity in Atloria, make sure the basics are already in place. This guide assumes you can sign in successfully, reach the authenticated workspace, and open the admin or workspace areas available to your role. If you need help with account access first, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). You should also already be familiar with the AI usage screens covered earlier in this documentation set. This guide does not repeat setup or basic navigation steps from [Managing AI Usage and Request History](doc:managing-ai-usage-and-request-history). Instead, it focuses on how to interpret what you see once you are already in the monitoring area. Before you begin, confirm the following: - You can access Atloria’s signed-in workspace - You have a role that allows you to view AI usage or admin reporting - AI-assisted features are in use by your team, workspace, or project - You know which team, project, or user group you want to review - You are prepared to compare both summary totals and request-level history It also helps to know where related admin areas are located. In Atloria, the **Admin** workspace includes cards such as **Users & Permissions**, **Organizations**, **Documents**, **Projects**, and **Analytics**. Depending on your permissions, you may use these areas alongside AI activity monitoring when you need to follow up on unusual usage. If your workspace’s **Analytics & Insights** page is not yet active and only shows a placeholder message, you can still use the available AI usage and request history screens to perform the monitoring steps described in this guide. ## Opening a version generation job and identifying its current state In Atloria, start from the **Versions** area inside your project and open the version you recently generated. If your team also uses a generation queue or job list, you can open the same run from there and then move into the job details view. The job details screen is where you confirm whether generation is still running, has finished, or needs attention before anyone starts editorial review. At the top of the job details page, look for the status badge in the header. This badge is the quickest way to understand the current state of the run. You may see states such as: - **Queued** for a run that has been submitted but has not started yet - **In Progress** for a run that is actively moving through processing stages - **Completed** for a run that finished and has results ready to inspect - **Needs Another Pass** for a run that finished but should be regenerated before review Below the header, use the summary area to confirm you are looking at the right run. This section typically shows the source item used for generation, the target version, when the run started, when it was last updated, and the current stage. These details are especially useful when several versions are being generated around the same time. The actions available on the page change with the status. While a run is active, you will usually focus on **View Progress** or the live status area. Once it finishes, the main action shifts to opening the generated result and checking warnings or notes. If the run is marked **Needs Another Pass**, look for the action that starts a rerun instead of sending the version forward. [SCREENSHOT: Version generation job details page showing the header status badge, summary panel, and available actions] ## Following progress while generation is running When a version generation job is running, stay on the job details page and watch the progress area near the top of the screen. Atloria shows progress in a way that helps you tell whether the run is actively moving or waiting at a step. The most useful indicators are the percentage complete, the current stage label, and the animated running state. As the job advances, the stage label helps you understand what Atloria is doing. Depending on the run, you may see updates that reflect steps such as: 1. **Content extraction** from the source material 2. **Draft generation** for the new version output 3. **Validation** to check the generated content 4. **Final assembly** to prepare the finished result These stage names matter because they tell you where the run is spending time. For example, a job that remains in **Validation** may still be working normally, while a job that has not changed stage or percentage for a long period may need a closer look. Use the activity feed or status timeline on the same page to follow timestamped updates. This view shows how the run moved from **Queued** to active processing and then through each stage. It is the best place to confirm that Atloria is still recording progress, even if the percentage changes slowly. If you are unsure whether the run has advanced, refresh the page or reopen the job details view from the version list. Compare the **Last updated** time with the current stage. If both remain unchanged after you check again, treat that as a sign to review the run more carefully before waiting longer. [SCREENSHOT: Running generation job with progress percentage, current stage label, and status timeline] ## Reviewing generated results when the job finishes Once the status badge changes to **Completed**, open the result panel from the finished job. This is where you review what Atloria generated for the target version and decide whether it is ready to move into editorial review. Do not rely on the completed badge alone. A finished run can still include warnings, skipped items, or validation notes that affect release readiness. Start with the completion details shown near the top of the result view. Confirm the **Success** or completion status, the **Finished** timestamp, and any summary information attached to the generated version. This summary helps you verify that the output belongs to the version you expected and that the run ended normally. Next, compare the generated output with the source content the run used. Focus on whether the expected sections appear, whether the structure looks complete, and whether the generated version reflects the intended source material. If you already worked through release preparation in [Creating Release Ready Documentation Versions](doc:creating-release-ready-documentation-versions), use that same release-readiness mindset here without repeating the full preparation process. Before you hand the version to editors or reviewers, read every warning and note attached to the result. Pay close attention to: - **Warnings** that point to incomplete or uncertain output - **Skipped items** that were not included in the generated result - **Validation notes** that indicate checks passed with concerns or did not fully pass A completed result is ready for review only when the output looks usable and the attached notes do not block normal editing and approval. If the result summary or warnings suggest missing sections or unreliable output, stop here and plan another pass instead of sending the version forward too early. [SCREENSHOT: Completed generation result panel showing finished status, summary details, warnings, and generated version output] ## Deciding when generated output needs another pass A version does not need another pass just because it is imperfect. In Atloria, the key question is whether the current output is good enough for editorial review or whether the issues are serious enough to block review entirely. The **Needs Another Pass** state is your clearest signal, but you should also use the result details to make the decision even when the run shows as completed. Open the result details and look for the reason Atloria is recommending another pass. Common signs include missing sections in the generated version, low-confidence output, failed checks, or warnings that clearly block review. If the result panel shows that important content was skipped or validation raised concerns that affect the whole version, rerunning is usually the better choice. Use this distinction when deciding what to do next: - Issues that can stay in editorial review: - Minor wording problems - Small structure adjustments - Limited clean-up that editors can fix directly - Issues that should trigger another pass: - Major sections missing - Validation problems that affect trust in the output - Repeated skipped items tied to important content - Result notes that explicitly mark the run as incomplete When you decide to rerun, record the reason in the version’s notes, comments, or team workflow area if your project uses one. Keep the note specific so Documentation Managers and Technical Writers can understand why the first result was not accepted. A short explanation such as “missing setup section in generated output” or “validation warnings blocked review” is more useful than a general note saying the run “looked wrong.” This makes later comparisons easier and helps your team avoid repeating the same decision discussion on every attempt. ## Starting another generation pass and tracking the rerun If the current output is not ready, start the next attempt from the finished job view. In Atloria, look for an action such as **Regenerate** or **Run another pass** on the result screen. Use that action from the version you already reviewed so the rerun stays connected to the same documentation workflow. After you start the rerun, check how Atloria records it. Depending on how your workspace is set up, you may see either: | What to look for | What it tells you | |---|---| | A new job entry in the list | Atloria created a separate run you can open on its own | | A new attempt under the same version | Atloria kept the rerun grouped with the existing version record | | An attempt number | Which run is the latest and which one came before it | The attempt number is especially important when you need to compare results. Make sure you open the latest attempt before reviewing progress or warnings, since older runs may still appear in the history. Track the rerun exactly the same way you tracked the original job. Watch the status badge, progress percentage, current stage label, and activity timeline. If the first run stalled or produced incomplete output, pay extra attention to whether the rerun moves cleanly through the same stage. When the rerun finishes, compare the latest result with the previous attempt. Check whether the warnings are gone, whether skipped items were resolved, and whether the generated version now includes the content that was missing before. If the rerun fixed the blocking issues, the version can move forward to review. If not, keep the attempt history visible so your team can see the pattern before deciding on another rerun. [SCREENSHOT: Rerun action on a completed generation result and attempt history showing multiple passes] ## Fixing common issues when progress or results do not look right Most generation checks in Atloria come down to reading the status badge, the timeline, and the result notes together. When something looks off, use the job details page before deciding whether to wait, review, or rerun. If a job appears stuck in **Queued** or **In Progress**, open the status timeline and check whether new updates are still being added. Then reload the job details page and compare the current stage with the **Last updated** time. If the timeline has stopped changing and the stage remains the same after refreshing, treat the run as stalled rather than assuming it is still moving normally. If progress reaches the end but no usable output appears, go straight to the result summary. A finished run may still be blocked by validation notes, warnings, or partial generation. Look for messages that explain whether the output was incomplete, whether some content was skipped, or whether the version was completed with issues. When another pass produces the same problem, compare the attempt history side by side. Focus on whether each attempt stopped at the same stage or repeated the same warning. Repeated failures at the same point usually mean your team should not keep rerunning without first documenting what is happening for the next reviewer or manager. If team members are unsure whether to review or rerun, use the final state shown on the job and the notes attached to the result: - **Completed** with no blocking warnings usually means the version is ready for review - **Completed** with serious warnings means you should inspect the result carefully before sending it on - **Needs Another Pass** means rerunning is the safer next step For broader job handling and result management, see [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results). ## Overview This guide focuses on the point between generation and editorial review: watching a version generation run, confirming whether it is moving normally, and deciding what to do with the result. In Atloria, that work happens on the job details page and the completed result view, where the status badge, progress area, timeline, and result notes tell you whether a version is ready to move forward. You will usually use this workflow after you have already created the version run. If you need help starting a new run, go back to [Generating New Documentation Versions](doc:generating-new-documentation-versions). If you need help comparing outputs after generation, use [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness) or [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). The main tasks covered here are: - Opening a generation job from the **Versions** area or job list - Reading the current status, progress percentage, and stage label - Following timestamped updates in the activity feed or timeline - Reviewing completed output, warnings, skipped items, and validation notes - Deciding whether the version is review-ready or needs another pass - Starting a rerun and checking whether the latest attempt fixed earlier issues This guide does not repeat the full release-readiness process from [Creating Release Ready Documentation Versions](doc:creating-release-ready-documentation-versions). Instead, it helps you decide whether the generated output is stable enough to enter that review path at all. The next document in this workflow is [Generating Documentation Versions and Monitoring Results](doc:generating-documentation-versions-and-monitoring-results), which brings generation and monitoring into one repeatable working pattern. ## Prerequisites Before you monitor a version generation run in Atloria, make sure you already have access to the project and a version generation job to open. This guide assumes the generation process has already been started and that you are checking progress or reviewing the result afterward. You should have: - Access to the relevant project workspace in Atloria - Permission to open the **Versions** area and view version records - At least one version generation run that is **Queued**, **In Progress**, **Completed**, or **Needs Another Pass** - Enough familiarity with your team’s version naming so you can identify the correct target version - The source content or source item context needed to confirm the generated result matches the intended input It also helps if you already understand the earlier parts of the version workflow: - How to start a run: [Generating New Documentation Versions](doc:generating-new-documentation-versions) - How Atloria tracks job lists and results: [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results) - How to judge release readiness after generation: [Creating Release Ready Documentation Versions](doc:creating-release-ready-documentation-versions) If you are opening a rerun, be ready to compare the latest attempt with the previous one. That means knowing which warnings, missing sections, or validation notes caused the earlier result to be rejected. For teams working together, agree before you begin whether your role is to monitor progress only, decide on reruns, or hand completed versions to editors. That keeps the status badge and result notes from being interpreted differently by different reviewers. ## Deciding Whether Your Project Needs Audiences Use audiences in Atloria when one documentation project needs to serve more than one reader group, but you still want to keep the content together in a shared project workspace. An audience represents a reader segment, such as customers, partners, internal support teams, or project administrators. Instead of creating duplicate pages for each group, you can plan one project with shared pages and audience-specific sections where needed. Audiences add the most value when the project has a strong shared foundation but some instructions, permissions, or workflows differ by reader type. For example, a project may include the same onboarding pages for everyone, while certain setup steps should appear only for administrators or internal teams. In that case, audience targeting helps you avoid maintaining two nearly identical page sets. [SCREENSHOT: project documentation page showing shared content with audience-specific sections] Before you decide to use audiences, compare that approach with simpler options: - Use shared, untargeted content if differences between readers are small - Use separate pages if only a few topics need different wording - Use separate projects or spaces if the content, navigation, and ownership are mostly different Audience targeting also changes how you plan the project. You need to think ahead about page structure, reusable content, review steps, and published navigation. A page that works well for one reader group can become confusing for another if key headings, links, or numbered instructions are hidden. If you already worked through content structure decisions in [Applying Audiences to Documentation Structure and Content Decisions](doc:applying-audiences-to-documentation-structure-and-content-decisions), use that guidance here to decide whether your project should stay unified or be split into cleaner reader paths. ## Defining Audiences Before You Build Content Define your audiences before your team starts building pages, versions, and reusable content. In Atloria, this planning work is easiest when you do it at the project level first, then carry those decisions into page creation and publishing review. If you wait until pages already exist, teams often apply audience labels inconsistently and end up reworking navigation, links, and page sections later. Start by listing the reader groups your project serves. Common examples include: - External Customers - Partners - Internal Support - Project Administrators - Implementation Teams For each audience, decide what they should see and what they should not see. Write those decisions in plain language your contributors can follow. For example, you might decide that **External Customers** can see setup, usage, and troubleshooting pages, while **Internal Support** can also see escalation steps and internal review notes. Keep these rules close to the project documentation process so editors can apply the same targeting choices every time they update a page. Use this planning sequence: 1. Open the project workspace and review the main documentation areas your team plans to create. 2. List each reader group that will use the published documentation or project content. 3. For each group, note which page types, instructions, warnings, and configuration details belong to them. 4. Mark any content that should stay visible to all readers, such as common navigation steps or general introductions. 5. Decide who on your team can approve new audience definitions and who reviews audience use before publishing. Keep your audience list as small as possible. Broad, stable labels are usually easier to manage than many narrow labels that overlap. If two audience names lead editors to ask, “Which one should I choose?” they are probably too similar. For hands-on setup of audience definitions inside a project, see [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). ## Choosing Audience Names That Stay Clear Over Time Audience names need to stay understandable long after the original project team has changed. In Atloria, these names appear wherever contributors choose who should see targeted content, so unclear labels create editing mistakes, review delays, and confusing publishing results. A good audience name tells editors exactly who the content is for without requiring background knowledge. Choose names based on recognizable reader roles, not internal shorthand. Names such as **Project Administrators**, **External Customers**, or **Internal Support** are much easier to apply consistently than labels like **Advanced**, **Tier 2**, **Blue Team**, or **Q4 Launch Group**. Those vague or temporary labels may make sense during one release cycle, but they usually become unclear when the project grows or new contributors join. A simple naming standard helps keep audience options clean across the project: | Naming choice | Good approach | Avoid | |---|---|---| | Reader focus | Name the audience after the reader role | Naming it after an internal team nickname | | Time span | Use stable labels that still make sense next year | Release-specific or temporary labels | | Style | Pick one capitalization style and use it everywhere | Mixed capitalization across audience names | | Form | Choose singular or plural and keep it consistent | Mixing “Administrator” and “Customers” styles | | Shortening | Use abbreviations only if everyone already recognizes them | Short forms that need explanation | Also decide how your team will handle renamed, merged, or retired audiences. If **Partners** is later merged into **External Customers**, review the pages and reusable content that still use the old label. Without that cleanup, editors may continue targeting content to an outdated audience name and create gaps in the published experience. Keep a simple record of approved names, older names that should no longer be used, and who can approve changes. This keeps audience selection predictable wherever contributors work in Atloria. ## Structuring Pages Around Targeted and Shared Content When you plan audience targeting in Atloria, build each page around shared content first. Put the information that everyone needs in the main flow of the page, then add targeted sections only where the experience truly changes. This keeps maintenance lower and makes pages easier to read, review, and publish across multiple reader groups. Shared content usually includes page introductions, prerequisites, navigation paths, common setup steps, and expected outcomes. Audience-specific content often includes permission notes, internal-only warnings, different approval paths, or extra configuration details for administrators and support teams. If you place too much shared information inside targeted sections, some readers may lose the context they need to complete the task. Use this page-planning sequence when outlining content: 1. Draft the full task flow using only the steps every reader must follow. 2. Highlight the points where one audience needs different instructions, extra warnings, or restricted details. 3. Move only those differences into targeted sections, leaving the main page structure visible to all readers. 4. Read the page again as if you were each audience, checking that headings, numbered steps, and links still make sense. 5. Split the page into separate pages if most of the content is hidden for one or more audiences. A single page works well when the differences are small and the shared workflow stays easy to follow. Separate pages are usually better when each audience sees a very different process, different navigation, or different outcomes. For example, if a page contains one short section for **Project Administrators** but the rest applies to everyone, keep it together. If half the page is hidden from **External Customers**, create separate pages instead. Also review cross-links and reusable content carefully. A link to a page with mostly hidden instructions can frustrate readers, especially in published documentation. Use the project hierarchy and page relationships to make sure each audience can move through the content without hitting dead ends or missing context. ## Checking How Audience Targeting Changes Publishing and Reader Experience Audience targeting affects more than page editing. It also changes how your team reviews content before publishing and how readers experience the finished documentation. In Atloria, a page can look complete to one audience while appearing incomplete or confusing to another, so your publishing process needs to account for every intended reader group. During editorial review, check each targeted page from the perspective of each audience that will use it. Confirm that hidden sections do not break the page flow. A heading should still make sense if a targeted block beneath it is not visible. A numbered procedure should not jump from step 2 to step 5 because the middle steps were targeted to someone else. Links in navigation, related content, and reusable page elements should also lead to content that the selected audience can actually use. Use this pre-publish review sequence: 1. Open the pages planned for release and identify any audience-specific sections or reusable content. 2. Review the page flow for each intended audience, checking headings, step order, notes, and links. 3. Confirm that shared navigation still leads readers to useful pages even when some sections are hidden. 4. Check that audience assignments match the naming rules and project decisions your team defined earlier. 5. Review the published reader experience, including discoverability and page-to-page movement, before final release approval. This review matters for search and navigation as much as for page content. If readers can find a page through project navigation or published browsing but most of the important instructions are hidden from them, the page may create confusion instead of helping them. Keep that in mind when planning menus, page titles, and cross-links. If your team is also preparing versions for release, combine audience review with your normal publishing checks so you do not validate content for only one reader group. For related release planning, see [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences). ## Fixing Common Audience Planning Mistakes Most audience problems in Atloria start during planning, not publishing. If your team notices inconsistent targeting, confusing page flow, or unclear audience choices, fix the planning model first before editing large numbers of pages. That usually saves time and prevents the same issue from spreading into new content. One common mistake is creating too many audiences. If contributors regularly hesitate between similar labels, the audience list is probably too detailed. For example, if editors cannot clearly distinguish between **Internal Support**, **Support Managers**, and **Support Operations** when targeting routine troubleshooting content, those labels may need to be consolidated. Fewer, clearer audience choices usually lead to better page consistency. Another issue is unclear naming. Labels that depend on team history or internal shorthand are hard for new contributors to use correctly. Rename those audiences to match recognizable reader roles, then update the affected pages and reusable content so the new names are applied consistently. Broken page flow is another frequent problem. This happens when shared instructions are placed inside targeted sections, leaving some readers without the context they need. It also appears when numbered procedures no longer read in order after hidden content is removed. Fix this by moving common instructions back into the visible page body and limiting targeted sections to the details that truly differ. Use this correction process: 1. Review the audience list and identify labels that overlap or cause repeated editing mistakes. 2. Rename, merge, or retire unclear audience labels based on recognizable reader roles. 3. Audit targeted pages to find hidden sections that remove required context, steps, or outcomes. 4. Move shared instructions into the main page flow and keep only role-specific details targeted. 5. Add audience-specific review checks to your publishing process so the same issues do not return. If you are seeing these problems across several projects, compare your project setup with the broader guidance in [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). ## Overview Use this document when you are planning how a documentation project in Atloria should serve different reader groups before large amounts of content are written. The focus here is not on the mechanics of creating pages or publishing versions. Instead, it helps you decide whether audiences belong in the project at all, how to define them clearly, and how those decisions affect page structure, review, and reader navigation. This planning step is most useful for teams working in shared project workspaces where one documentation set may need to support multiple readers, such as customers, partners, internal support teams, and administrators. In those cases, Atloria audiences help you keep shared content together while still controlling which sections are shown to specific readers. That can reduce duplication, but it also adds responsibility during content design and publishing review. This document builds on the earlier guidance in [Applying Audiences to Documentation Structure and Content Decisions](doc:applying-audiences-to-documentation-structure-and-content-decisions). If you already understand how targeted content changes page design, the next step is to make project-level decisions that keep those patterns manageable over time. That includes agreeing on audience names, deciding who owns audience changes, and checking how targeted pages will behave in published documentation. Use the sections below to plan your audience model before your team expands the page tree, creates reusable content, or prepares versions for release. [SCREENSHOT: Atloria project workspace with documentation navigation and audience planning notes] ## Prerequisites Before you use this planning guidance in Atloria, make sure the following project basics are already in place: - You can sign in to Atloria and open the correct project workspace - You understand the project’s main documentation goals and intended readers - Your team has already discussed whether the project should stay unified or be split across separate projects or spaces - You have reviewed [Applying Audiences to Documentation Structure and Content Decisions](doc:applying-audiences-to-documentation-structure-and-content-decisions) - You know who on your team can make project-level documentation decisions, especially for naming, publishing, and review - You have access to the parts of Atloria where your team manages project content, versions, and publishing workflows It also helps to gather a small planning group before you begin. Include the people who write documentation, review releases, manage project structure, and represent the reader groups most affected by targeted content. Audience planning works best when the same people who shape page structure also help define which readers should see each type of content. If your team has not yet set up project audiences in Atloria, that is fine. This document is intended to help you make the decisions first so the setup is cleaner later. After you finish this planning work, continue with [Planning Audience Targeting for Project Content](doc:planning-audience-targeting-for-project-content) to turn these project-level decisions into page-by-page content planning. ## Defining the Project Scope Before You Create It Before you click **Create project** in Atloria, decide exactly what the new workspace is meant to hold. This step matters because the project name, description, page organization, and contributor access should all reflect the documentation scope you agreed on earlier in [Managing Project Setup Decisions After Onboarding](doc:managing-project-setup-decisions-after-onboarding). Start by confirming the basics with your stakeholders: - The documentation set name that should appear in the project list and workspace - The main audience for the content - Whether the project covers one product, one release, or several ongoing content streams - What content belongs inside this project and what should stay outside it - Who owns the project after setup - Who reviews content before it is considered ready - What “ready for authoring” means for your team It helps to gather the planning inputs before opening the project setup flow. In practice, that usually means collecting: - The approved project name - A short project description - Expected top-level sections such as guides, references, release notes, or internal review pages - The first contributor list - Any required templates or starter pages - Naming patterns your team wants writers to follow These early choices shape what users see right away in Atloria. If your team plans to separate guides from reference content, the opening page tree should reflect that from day one. If only a small group should edit early drafts, assign access accordingly during setup instead of fixing it later. If the project will support multiple content streams, plan a structure that makes those streams easy to recognize in the left navigation. [SCREENSHOT: Project creation screen showing project name, description, and initial structure planning notes] A well-scoped project feels organized the first time a writer opens it. A loosely defined project usually leads to misplaced pages, unclear ownership, and rework before drafting can begin. ## Aligning Documentation Goals with Team Roles Once the scope is clear, match the project goals to the people who will work in the Atloria workspace. The goal is not just to create a project, but to make sure everyone knows who decides the structure, who writes the pages, and who signs off before content moves forward. For most teams, these responsibilities break down into three working roles: | Role | Main focus in Atloria | What they should confirm before writing starts | |---|---|---| | Documentation Manager | Approves scope, review expectations, and content priorities | Which sections matter first, what quality standard applies, and which pages need formal review | | Technical Writer | Creates and updates pages in the project workspace | Where drafts belong, which templates to use, and how to mark content as ready for review | | Project Administrator | Sets up the project workspace and contributor access | Project name, description, initial structure, and who can enter or edit each area | At kickoff, record the project goals in a way that can guide setup decisions inside Atloria. Useful goals include: - Publishing deadlines - Content quality expectations - Review checkpoints - Maintenance expectations after launch - The first content types to produce Those goals should turn into visible workspace decisions. For example, if release notes are a launch requirement, they should appear as a clear top-level section. If only certain pages need formal review, those pages should be easy to identify in the structure and handoff notes. If multiple contributors will draft content, they need edit access from the start. The handoff between setup and writing should also be agreed early. Decide: - Who confirms the workspace is ready - Who reviews the page structure before writers begin - How writers are told that drafting can start - Which first pages or milestones are assigned immediately [SCREENSHOT: Project workspace with team members reviewing structure and assigned content areas] When these role decisions are made up front, Atloria becomes a working space for coordinated writing rather than a blank project waiting for direction. ## Setting Up the Workspace for the First Writing Cycle After planning is approved, create the project workspace in Atloria using the agreed project name and description. These details are more than labels—they help everyone recognize the project in the project list and understand its purpose as soon as they open it. 1. Open the project creation flow and enter the approved **project name** and **description**. 2. Create the starting structure based on the planned content model. 3. Add the first contributors who need access for setup, writing, and review. 4. Prepare the starter content your team expects to see on day one. The starting structure should match how your team plans to write. If the project will begin with user guides, reference pages, and release notes, those sections should appear clearly in the page tree. If internal review content needs to stay separate from public-facing pages, create a distinct area for that from the beginning. Writers work faster when they can tell where each page belongs just by looking at the navigation. Contributor setup is just as important. Give writers access to the areas where they will draft content, make sure reviewers can open the pages they need to check, and keep project-level setup access with the people responsible for maintaining the workspace. It is much easier to assign the right access before drafting starts than to pause writing later because someone cannot open or edit the correct section. Starter assets should also be visible immediately. Depending on your plan, that may include: - Template pages - Placeholder pages for priority topics - Writing guidance pages - A location for review tracking - Shared content planning notes [SCREENSHOT: New project workspace showing page tree with Guides, Reference, Release Notes, and Review sections] A good first-writing setup in Atloria should feel ready for action. When a writer enters the workspace, they should see where to start, what to use, and who else is involved. ## Confirming Authoring Standards Before Writers Begin Before anyone writes the first draft, make the project rules visible inside Atloria. A project can be technically created and still not be usable if writers do not know how to title pages, where to place drafts, or how to signal that a page is ready for review. Set the page-level standards first. At minimum, your team should agree on: - How page titles should be written - What metadata needs to be completed - Which section pattern each page should follow - Which terms, product names, and voice rules writers must use consistently These standards should not live only in meeting notes. Put them somewhere writers can find as soon as they enter the workspace, such as a guidance page or a clearly named starter page in the project tree. Next, define how the workspace should be used during drafting. Writers need to know: - Which area is for draft pages - Where final or review-ready pages should appear - Where shared assets are stored - How in-progress content is labeled - How ownership is shown for each content area Visible naming patterns help a lot here. If your team uses a specific label for draft content or a consistent naming style for release pages, apply that pattern from the start. If each section has an owner, make sure that ownership is documented where contributors can see it. A practical authoring-readiness check should confirm that the workspace includes: - A usable page tree - At least one starter template - Clear page naming rules - Shared writing guidance - A visible review path - Assigned owners for the first content areas [SCREENSHOT: Writing standards page inside the project workspace with title rules, page structure, and review instructions] When these standards are visible in Atloria at launch, writers spend less time asking where things go and more time producing consistent content. ## Handing Off the Project from Setup to Ongoing Writing The handoff from setup to writing is the point where the project stops being an administrative task and becomes an active documentation workspace. In Atloria, that handoff should happen only after the structure, access, and writing rules are confirmed. 1. Review the final project structure with the people who approved the scope. 2. Confirm that contributors can enter the workspace and reach the sections they need. 3. Check that templates, starter pages, and writing guidance are already in place. 4. Approve the workspace for drafting and notify the writing team. 5. Assign the first pages or milestones so work begins with clear direction. The Documentation Manager should verify that the workspace still matches the agreed documentation goals. That includes checking whether the top-level sections reflect the approved scope, whether the first writing priorities are visible, and whether the review approach is clear enough for writers and reviewers to follow. The Project Administrator should confirm the setup details inside Atloria: project name, description, page structure, contributor access, and any shared planning pages or review locations. If writers are expected to begin immediately, nothing essential should still be “coming soon” inside the workspace. At handoff, the Technical Writer should receive a clear starting package inside the project itself: - Confirmed page locations - The template or starter page to use - Review process expectations - Any project-specific writing constraints - The first assigned topics or milestones A short kickoff note in the workspace can make this transition much smoother. It can point writers to the correct sections, identify owners, and state which pages should be drafted first. [SCREENSHOT: Project workspace handoff note showing first assigned pages, owners, and review expectations] After this handoff, the project should feel active and writable—not merely created. ## Verifying the Project Is Ready for Content Creation Before drafting begins, do one final readiness check in Atloria. This is where you confirm that the workspace is not only present in the project list, but actually prepared for sustained content creation. Start with the structure. Open the project and compare the visible page tree to the approved scope. Make sure no top-level section is missing. If your team planned separate areas for guides, references, release notes, or internal review pages, those areas should already exist and be clearly named. Then verify access by role. Each person should be able to reach the part of the workspace they need: - Writers need edit access in their assigned sections - Reviewers need visibility into the pages they will check - Administrators need access to maintain project setup and contributor controls Also confirm that the handoff materials are complete. Writers should not need to search across messages or meetings to understand how to begin. The workspace should already show the documented goals, ownership, writing standards, and first priorities. Common readiness problems usually show up in a few predictable ways: - The scope is still unclear, so pages do not fit neatly into the structure - Contributors can open the project but cannot edit the right sections - Starter pages or templates are missing - No review path has been agreed - Ownership for major sections is not visible Correct these issues before anyone starts drafting. It is better to pause for a short cleanup than to let writers create pages in the wrong place or follow different standards. [SCREENSHOT: Final project readiness review showing page tree, contributor access, and starter content] Once this check is complete, continue with [Managing Project Creation Choices and Setup Readiness](doc:managing-project-creation-choices-and-setup-readiness) to confirm the workspace is fully prepared for the next stage of project work. ## Overview This stage of project setup in Atloria focuses on planning the workspace before active writing begins. You are not repeating onboarding choices here—you are turning those earlier decisions into a practical project structure that writers and reviewers can use immediately. If you still need to revisit the earlier decision stage, return to [Managing Project Setup Decisions After Onboarding](doc:managing-project-setup-decisions-after-onboarding). The main goal is to make sure the new project is organized around real documentation work. That includes confirming the project name and purpose, deciding what belongs in the workspace, preparing the page tree, assigning the right contributors, and making writing standards visible from the start. In Atloria, these choices affect what users see in the project list, how they move through the workspace, and whether drafting can begin without confusion. This planning step is especially useful when: - A new documentation project is about to be created - Multiple contributors will write or review content - The team needs clear separation between content types - The first writing cycle must begin quickly after setup - Stakeholders want approval and ownership defined before drafting starts By the end of this process, the project workspace should have a clear structure, known owners, visible standards, and an agreed handoff into authoring. That means writers can open Atloria, find the right section, use the correct starter materials, and begin drafting without waiting for more setup decisions. [SCREENSHOT: Completed project workspace ready for first writing cycle] ## Prerequisites Before you work through this planning stage in Atloria, make sure the earlier setup decisions are already settled. This document assumes the project idea has been approved and that your team is ready to turn that idea into a usable workspace. You should have the following ready: - A confirmed project purpose - An approved project name - A clear understanding of the intended audience - Agreement on whether the project covers one product, one release, or multiple content streams - A first list of contributors who need access - A draft of the top-level content areas the workspace should include - Any required templates, starter pages, or writing guidance - Agreement on who approves content and who maintains the workspace It also helps if the team has already discussed: - Which pages need formal review - Which content types should be written first - How ownership will be shown for each section - What “ready for authoring” means for this project If account access or sign-in is still being sorted out, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) before continuing. If the project itself has not yet been created, review [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) and [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). Having these items ready will make the setup screens in Atloria much easier to complete and will reduce rework once your writers begin using the workspace. ## Checking that the version is ready to send for approval Before you use **Review**, **Submit for Review**, or **Request Approval**, open the version workspace and confirm you are working in a version that is still editable. If the status badge already shows an in-progress review state, a locked state, or another non-editable state, finish those steps first before trying to submit again. The goal here is simple: reviewers should receive a version that is complete enough to evaluate, not one that still needs basic cleanup. Start in the version details area and check the fields reviewers rely on to identify the release. Make sure the **version title** is correct and easy to recognize. Confirm the **owner** is assigned so reviewers know who is responsible for follow-up. If your version screen includes a **status**, **category**, or similar details panel, fill those in before moving forward. Missing details can stop the approval action or create confusion once the request appears in the review queue. Next, look at the page list, table of contents, or navigation tree for the version. Every required page should be present, named clearly, and placed in the right order. If a section is still missing, do not send the version yet. Reviewers should not have to guess whether a page was intentionally removed or simply forgotten. Finally, scan for unfinished writing markers. Remove visible **TODO** text, placeholder copy, empty headings, and blank sections. If a page contains a heading with no body text underneath it, fill it in or remove it. If a section is not ready, it is better to hold the version than to send an obviously incomplete draft. [SCREENSHOT: Version workspace showing the status badge, version details panel, and page list before submission] ## Reviewing the version for completeness before submission Once the version details look correct, open the content itself and read it the way a reviewer will. Use the version preview or editor to move page by page through the documentation. Look for missing headings, unfinished paragraphs, awkward formatting, and places where body text stops abruptly. A version can look complete in the page list while still containing half-finished content inside individual pages. 1. Open the version preview or editor. 2. Move through each page in the navigation tree or page list. 3. Check that headings appear in a sensible order and that each section has complete body text. 4. Confirm pages are arranged correctly in the navigation so reviewers see the intended reading flow. 5. Remove draft-only pages that should not be part of the review. Pay close attention to linked content. Images should display properly, attachments should be available if they are part of the page, and internal cross-references should lead to the right place. If Atloria shows a missing asset warning or a broken reference, fix it before submission. Reviewers should be evaluating the documentation itself, not reporting obvious file problems. Also review the approval-facing notes attached to the version. If your version includes fields such as **summary**, **change notes**, or **revision comments**, update them so they clearly explain what changed. A short, accurate summary helps reviewers focus on the right pages and understand whether they should expect a minor update, a structural rewrite, or a release-ready version. If you need a refresher on the broader review process, use [Requesting and Completing Version Reviews](doc:requesting-and-completing-version-reviews) alongside this preparation step. [SCREENSHOT: Version preview with page navigation, rendered content, and version summary fields] ## Resolving obvious issues that would block review Before you submit, clear anything in Atloria that is already flagged as a problem. If the version details panel, editor, or publishing area shows validation messages, warning banners, or issue indicators, treat those as blockers until proven otherwise. Sending a version with visible errors usually leads to an immediate request for changes instead of a meaningful review. Start with required-field warnings. If Atloria highlights missing information in the version details or workflow form, fill those fields first. Then review any inline alerts inside pages. These may point to formatting problems, incomplete content, or other issues that are already visible before a reviewer opens the version. Use any quality check, validation banner, or issue list available in the version workspace to clean up common content problems, such as: - Broken links - Missing images or attachments - Missing alt text - Empty sections - Content warnings shown in the editor - Open comments that still need action Open comments deserve special attention. If a comment is marked **open**, **pending**, or **needs changes**, resolve it before formal review whenever possible. Reviewers should not spend time re-reporting issues your team already knows about. If a comment cannot be resolved yet, make sure the reason is documented clearly in your submission note so reviewers understand the limitation. After fixing the issues, save the version and check the status indicators again. The page list, version header, and any warning banner should no longer show blocking problems. If the review action is still unavailable, return to the details panel and look for a missed field or unresolved alert. [SCREENSHOT: Version editor showing warning banners, open comments, and a clean saved state after fixes] ## Submitting the version into the approval flow When the version is complete and the obvious issues are cleared, you can move it into review. In Atloria, this action usually starts from the version header or a workflow actions menu. Look for **Review**, **Submit for Review**, or **Request Approval**. The exact label may vary by workspace, but the purpose is the same: you are sending the current version to named reviewers or approvers. 1. Open the version you want to submit. 2. Click **Review**, **Submit for Review**, or **Request Approval** in the version header or workflow actions menu. 3. Choose the required reviewers or approvers if Atloria asks you to assign people. 4. Add a note in the message or comments field. 5. Confirm the submission and watch for the status change. If Atloria shows a reviewer picker, select the people responsible for the next decision. If your team uses staged approvals, complete each required selection in the approval setup before confirming. Do not leave reviewer fields blank if the workflow expects named participants. Use the submission note to guide the review. This is the best place to call out major changes, known limitations, or pages that need extra attention. Keep it practical. For example, mention that the navigation was reorganized, several screenshots were updated, or one section still needs a final legal check. A clear note reduces back-and-forth once the review begins. After submission, confirm that the version status badge changes from an editable state to something like **In Review** or **Pending Approval**. Also check the activity timeline if it is available. You should see the review request recorded there, which helps confirm that the workflow started successfully. [SCREENSHOT: Submit for Review window showing reviewer selection, message field, and updated status badge] ## Understanding what reviewers will see during approval It helps to know what the approval screen looks like from the reviewer side, because that tells you what needs to be clean before you submit. Reviewers are typically looking at the rendered version content, the version status badge, and a set of version details that explain what they are approving. If those areas are incomplete or unclear, the review slows down quickly. On the review screen, approvers will usually see the submitted content as readers see it, not just raw draft text. That means page order, headings, images, and linked content all matter. If a page is missing from the navigation or appears in the wrong place, reviewers will notice it immediately. They may also see a metadata panel with fields such as the version title, assigned owner, summary, change notes, revision comments, and current workflow status. Reviewers may also have access to approval history or recent workflow activity. This helps them understand whether the version has already been revised, whether someone requested changes earlier, and who is currently responsible for the next step. If your submission note is vague, reviewers may rely on that history to piece together what changed. Comments and comparison tools are especially important during approval. If Atloria shows annotations, unresolved comments, or a comparison view between versions, reviewers can use those areas to spot unfinished work and recent edits. A version that still contains open issues will look less ready, even if the main pages read well. From their workflow panel, reviewers may be able to: - **Approve** - **Request changes** - **Reject** - Leave comments or notes For a deeper look at how those decisions are handled after submission, see [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals) and [Understanding Version Review Statuses Comments and Next Steps](doc:understanding-review-statuses-comments-and-next-steps). [SCREENSHOT: Reviewer view showing rendered content, metadata panel, comments, and approval actions] ## Fixing common problems before reviewers see the version A few common problems can stop the approval process before it starts. The first is missing required information. If **Submit for Review** or **Request Approval** does nothing, or if Atloria shows an error message, return to the version details panel and check for empty required fields. The version title, owner, and any required workflow fields should be filled in before you try again. Another common issue is that the approval action is unavailable because the version is not in the right state. If the version is already under review, locked, or otherwise not eligible for editing, Atloria may hide or disable the submission action. In that case, check the status badge in the version header and the activity timeline to see whether the version has already been sent or whether another step must be completed first. You may also hear from reviewers that pages are missing, images are broken, or content looks outdated. This usually means the wrong version was submitted or recent edits were not saved before the review request was sent. Open the submitted version directly and compare the page list, content, and assets against what you intended to send. If needed, withdraw or update the version using your team’s normal review process before asking reviewers to continue. If assigned approvers do not receive the request, check the reviewer selection carefully. A missing assignee, incomplete approval routing, or skipped workflow step can leave the version in review without reaching the right people. Reopen the workflow details and confirm the correct reviewers are listed. Common checks before resubmitting: | Problem | What to check | Where to look | |---|---|---| | Submit action fails | Missing required fields | Version details panel or workflow form | | Approval button is disabled | Current version status | Version header and activity timeline | | Reviewers see wrong content | Wrong version or unsaved edits | Version page list, preview, and saved content | | No reviewer response | Missing reviewer assignment | Reviewer picker or approval setup | If the version is ready and the workflow is clear, continue with [Requesting Review and Handling Version Decisions](doc:requesting-review-and-handling-version-decisions). ## Overview Preparing a version for review in Atloria means doing more than clicking **Submit for Review**. You are making sure the version is complete, readable, and clearly explained before it reaches the people responsible for approval. That preparation happens in three places: the version details panel, the content itself, and the review workflow controls. The version details panel gives reviewers the context they need. This is where they identify the version by title, see who owns it, and read any summary or revision notes that explain what changed. The content area shows whether the documentation is actually ready to review, including page order, headings, images, and linked references. The workflow controls move the version from an editable state into a formal review state, where approvers can comment, request changes, or approve it. This guide focuses on the checks you should complete before reviewers get involved. It does not repeat the full review cycle or decision handling steps covered in [Requesting and Completing Version Reviews](doc:requesting-and-completing-version-reviews). Instead, it helps you avoid preventable problems such as incomplete page lists, unresolved comments, missing metadata, and blocked submission actions. Use this guide when you have already drafted or updated a documentation version and want to make sure it is ready for formal review. If you prepare the version carefully, reviewers can focus on the quality of the documentation rather than basic cleanup. That usually leads to faster decisions, clearer feedback, and fewer avoidable review rounds. ## Prerequisites Before you prepare a version for approval in Atloria, make sure these basics are already in place: - You can open the project and access the version workspace. - The version already exists and is still in a state that allows editing. - The main documentation pages for the version have been created or updated. - You can view the version details panel, page list, and content editor or preview. - You know who should review or approve the version once it is submitted. It also helps if you have already completed the earlier review preparation work covered elsewhere in the Version Review set. In particular, this guide assumes you are not starting from a blank version. You should already have content ready for review and a general understanding of how review requests work. If you need that foundation first, read [Requesting and Completing Version Reviews](doc:requesting-and-completing-version-reviews). Have the following information ready before you submit: - A clear version title - The correct owner assignment - Any summary, change notes, or revision comments your team expects - A final check of page order and included content - Any notes reviewers should see about known limitations or special review focus If your team uses screenshots, linked files, or cross-references, make sure those items are already in place before opening the approval form. Reviewers should receive a version that reflects the intended reading experience, not a draft that still depends on missing assets or unresolved comments. ## Choosing the Right API Reference View In Atloria, you can open API reference content from two main places: a project workspace and a published documentation site. The page content may look similar, but the context matters. Use the project view when you are reviewing work that is still being prepared, checked, or updated inside your team’s documentation workspace. Use the public view when you want to read the version that has already been published for readers outside the project team. You will usually arrive at an API reference page in one of three ways: - From the left navigation tree inside technical documentation - From search results - From a direct link that opens a specific endpoint, schema, or section on the page When the page opens, look at the header first. The header helps you confirm where you are before you read any details. Depending on the documentation setup, the top of the page may show the API title, a version label, and whether you are reading content inside a project workspace or in the public documentation experience. If you are comparing content across versions, that version label is especially important. [SCREENSHOT: API reference page header showing API title, version label, and surrounding navigation] Choose the project view when you need to review draft reference content, check whether a recently generated version includes the latest endpoint details, or compare internal changes before release. If you only need the approved reader-facing reference, use the public documentation view instead. That avoids confusion when a draft page contains fields, examples, or notes that are not yet part of the published documentation. If you need more background on where API reference pages appear across Atloria, see [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views). If you want a refresher on how entity-level detail pages are organized, see [Viewing Technical Entities and Related Reference Details](doc:viewing-technical-entities-and-related-reference-details). ## Scanning an API Reference Page from Top to Bottom When you open an API reference page in Atloria, read it from the top down in the same order the page presents the operation. This makes it much easier to understand what the endpoint does before you get into field-by-field details. At the top, you will usually see the operation or resource title, followed by a method badge such as **GET**, **POST**, **PUT**, or **DELETE**. Near that badge, look for the URL path. This tells you exactly which operation you are reading. A short description usually appears nearby and gives a plain-language summary of the endpoint’s purpose. Right below the operation header, check for any authentication information. Atloria may show this as an authorization note, an authentication label, or a named security section near the top of the operation. Read this before reviewing parameters so you know whether the request needs credentials or special access. The middle part of the page is usually the request area. This is where you will find sections such as: | Section | What to look for | Why it matters | |---|---|---| | Parameters | Path, query, or header values | These change how the request behaves | | Request Body | Fields sent in the main payload | Often required for create or update actions | | Examples | Sample request values | Helps you see the expected format | As you move lower on the page, you will reach the response area. This section often groups responses by status code, such as success and error outcomes. Inside each response block, look for a response body example and a schema or field table. The example helps you recognize the shape of the returned data, while the schema table helps you confirm each field name, type, and meaning. [SCREENSHOT: API reference page showing method badge, URL path, parameters, request body, and responses] If the page is long, keep checking section headings as you scroll so you do not confuse request details with response details. ## Using Navigation and Search to Jump to the Right Details Long API reference pages can be difficult to read straight through, especially when a page includes several operations, large schemas, or deeply nested fields. In Atloria, the fastest way to move around is to use the navigation elements already built into the documentation page. Start with the left sidebar if it is available in your current view. The sidebar is useful when you want to jump directly to a specific operation, authentication section, model, or schema page. If the page includes a table of contents, use it to move between major sections such as **Parameters**, **Request Body**, **Responses**, and examples without scrolling through the entire page. When you know the exact term you need, use search or your browser’s find feature. This works well for locating: - A parameter name - A status code like **404** or **401** - A header name - A schema field - A repeated object name used across several sections Anchor links are especially helpful on long pages. If Atloria shows linked section headings or a table of contents entry for **Parameters**, **Request Body**, or **Responses**, use those links to jump directly to that section and then return to the top navigation when needed. Some reference sections may also be expandable or collapsible. Open these areas when you need more detail about nested object fields, allowed values, or example payloads. Closed sections can hide important details, especially in larger request body and schema areas. | Tool | Best use | Typical target | |---|---|---| | Left navigation | Moving between pages or major reference items | Operations, schemas, auth sections | | Table of contents | Jumping within the current page | Parameters, Request Body, Responses | | Browser find | Finding exact text quickly | Field names, status codes, headers | [SCREENSHOT: Left navigation and in-page table of contents on a long API reference page] If you are still learning how Atloria organizes technical documentation inside a project, see [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). ## Reading Request and Response Details Correctly The most common mistakes on API reference pages happen when readers skim tables too quickly. In Atloria, slow down when you reach parameter and schema sections, because small labels often change the meaning of a field. In a parameter table, read across the row instead of only reading the field name. Check the field name, where it appears, whether it is required, its type, and the description. A field with the same name can mean different things depending on whether it appears in the path, query string, headers, or request body. | Column | What it tells you | |---|---| | Name | The field or parameter label | | Location | Where the value is sent | | Required | Whether you must include it | | Type | The expected kind of value | | Default | What Atloria shows if no value is provided | | Description | What the field is used for | In the request body section, start with the top-level object and then move inward. Watch for nested properties, arrays, and fields marked as required. If a field is nullable, that means the value may be empty. If a field is inside an array item or nested object, do not assume it belongs at the top level of the payload. For responses, compare more than one status code before deciding how an operation behaves. A **200** or **201** response usually shows a successful result, but other sections may explain validation failures, authentication problems, or not-found outcomes. Read the example payload and the schema table together. The example shows the overall shape; the schema table explains each field more precisely. [SCREENSHOT: Parameter table next to request and response example sections] When a response example looks simpler than the schema table, trust the full schema to understand all possible fields, then use the example to see a realistic payload layout. ## Finding the Exact Reference Information Faster When you are trying to answer one specific question, do not start by reading the whole page. In Atloria, you can usually find the right detail much faster by checking a few high-value markers first. Begin with the method badge and URL path. This confirms that you are looking at the correct operation before you spend time reading parameters or response examples. It is easy to confuse similar operations when several endpoints share the same resource name. Next, look for links to related schemas or models. If the request body or response uses a reused object, follow that linked reference instead of manually hunting through multiple pages. This is especially helpful when the same object appears in several endpoints and only one dedicated schema section explains all of its fields. Pay close attention to labels that change how you interpret a field: - **Required** badges tell you which fields must be present - Enum lists show the allowed values for a field - Format labels such as **string**, **integer**, **boolean**, or **date-time** tell you what kind of value belongs there These small labels often matter more than the description text when you are checking whether a request or response is valid. If something looks different from what you expected, compare the same reference page in the project workspace and the public documentation view. A field, example, or response block may differ because one page is showing a draft version and the other is showing the published version. This is one of the fastest ways to explain why a teammate sees one value while a public reader sees another. | Fast check | What it confirms | |---|---| | Method + path | Correct operation | | Schema link | Full shared object details | | Required badge | Must-have fields | | Enum list | Allowed values | | Format label | Expected value type | Use this approach whenever you need to verify a single field, response code, or payload shape without rereading the entire reference page. ## Resolving Common Problems When Reference Pages Are Hard to Read If an API reference page in Atloria feels confusing, the problem is usually not the whole page—it is one missing clue. Start by narrowing down exactly what you cannot find. If a field seems to be missing, check whether you are looking in the wrong section. Some fields appear only in the **Request Body** schema, not in the parameter table. Others are hidden inside nested objects or linked schema definitions. Expand collapsed sections and follow any linked model or schema names before assuming the field is absent. If an endpoint looks incomplete, confirm which documentation view you are reading. A project page may show draft content that is still being prepared, while the public documentation view shows only the published version. If the page header includes a version label, compare that label first. A mismatch there often explains why examples, fields, or notes do not match what you expected. When response details seem inconsistent, compare three parts of the page together: | Compare this | With this | Why | |---|---|---| | Status code section | Response example | Confirms which outcome the example belongs to | | Response example | Schema table | Shows whether the example is partial or complete | | Project version | Public version | Reveals draft versus published differences | If navigation becomes difficult on a long page, stop scrolling and use the table of contents, anchor links, or browser find. Search for section names like **Parameters**, **Responses**, or **Schemas**, then move directly to the part you need. This is usually faster and more reliable than trying to remember where a section appeared on the page. For broader reading patterns across public and internal technical docs, see [Reading Published API and Technical Documentation](doc:reading-published-api-and-technical-documentation) and [Exploring API Reference Sections Inside Projects](doc:exploring-api-reference-sections-inside-projects). ## Overview API reference sections in Atloria are designed to help you move from a high-level operation summary to exact request and response details without leaving the page. The key to reading them well is to confirm the page context first, then work through the content in a consistent order. Use the page header to verify whether you are in a project workspace or a public documentation view. After that, scan the operation title, method badge, URL path, and short description so you know exactly what the page covers. From there, move into the request details, including parameters, headers, and request body fields, and then finish with the response section and its status codes, examples, and schema tables. The fastest readers in Atloria do not rely on scrolling alone. They use the left navigation, table of contents, anchor links, and browser find to jump directly to the detail they need. This matters most on long pages with nested schemas, reusable objects, and multiple examples. Keep these reading habits in mind: - Confirm the view and version before comparing details - Check the method and path before reviewing fields - Read parameter rows across all columns, not just the name - Use schema links when objects are reused - Compare examples with schema tables instead of relying on one alone If you already worked through [Viewing Technical Entities and Related Reference Details](doc:viewing-technical-entities-and-related-reference-details), this guide builds on that foundation by focusing on how full API reference sections are read efficiently from top to bottom. ## Prerequisites Before using this guide in Atloria, make sure you can already open a technical documentation area and reach an API reference page. You do not need advanced technical knowledge, but you should be comfortable moving through documentation navigation and recognizing common page sections. You will get the most value from this guide if you can already do the following: | What you should be able to do | Why it helps | |---|---| | Open a project documentation workspace or public documentation site | You need access to an API reference page to follow the reading steps | | Use the left navigation tree | Many reference sections are easiest to reach from the sidebar | | Open a linked endpoint, schema, or section heading | Direct links are common in shared documentation reviews | | Recognize page labels such as version markers and section headings | These help you confirm context before reading details | It also helps if you have already read these related guides: - [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages) - [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects) - [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views) If your main challenge is understanding how a single entity page is laid out before reading a full reference section, review [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation). The next step is [Browsing Technical Documentation and Entity Reference Pages](doc:browsing-technical-documentation-and-entity-reference-pages), which focuses on moving between documentation pages and related reference content more efficiently. ## Recognizing When You Are in an Audience-Specific View In Atloria, a public documentation page can open in two different reading contexts: a general public view or an audience-specific view. The topic title may look familiar in both places, but the page around it can change. Before you start reading, look at the top of the page and the navigation area for signs that you are in the right audience path. The easiest clues are the audience label, the breadcrumb trail, and the section navigation. If the page is audience-specific, Atloria may show an audience marker in the page header or near the navigation controls. The breadcrumb path can also be more specific than the general documentation path, showing that you entered through a tailored route instead of the broad public index. In the sidebar or page menu, you may also see a filtered list of pages chosen for that audience rather than the full documentation structure. [SCREENSHOT: Public documentation page showing the page title, audience label, breadcrumbs, and left navigation] A general documentation page usually presents broader navigation and more mixed page options. An audience-specific page narrows that experience. You may see different related links, a shorter page list, or a more focused sequence of pages designed for a particular reader group. This matters because Atloria can present the same topic in more than one audience view. The main article may cover the same subject, but the surrounding path, suggested next pages, and linked tasks are adjusted to match the selected audience. If you already reviewed public audience pages before launch, use that earlier review process as a reference point here: [Reviewing Public Audience Pages Before Launch](doc:reviewing-public-audience-pages-before-launch). In this guide, the focus is on reading the live public view and recognizing whether the page context matches the audience you intended to open. ## Opening the Right Public Documentation Path Start from the public documentation home page and choose the audience entry point before opening individual topics. In Atloria, that entry point may appear as an audience selector, an audience-specific landing page, or a clearly separated audience route in the public reading experience. The goal is to enter the documentation through the audience path first, not by jumping straight into a page title from a general index. 1. Open the public documentation home page. 2. Look for the audience entry option in the header, navigation area, or landing page content. 3. Select the audience you want to read for. 4. Open the topic from that audience-specific page list or section menu. 5. Confirm the breadcrumb trail and section navigation reflect the audience context. When you follow the audience-specific route, Atloria updates the reading context around the page. The URL may include an audience segment, the breadcrumb trail may become more specific, and the sidebar may show a smaller set of pages chosen for that audience. If you open the same topic from the general documentation index instead, the article may still load, but the surrounding navigation can shift back to the broader public structure. This difference is important when you share links. A Documentation Manager should test whether a shared link opens the intended public audience view or falls back to the default general page. If someone clicks a link and lands on the correct topic title but sees broad breadcrumbs or unrelated sidebar sections, they may not be in the audience-specific path. [SCREENSHOT: Public documentation home page with an audience entry point highlighted] When possible, open the topic from the audience landing page rather than from a saved browser tab or an older shared link. That simple step helps preserve the correct reading path and makes the related links, next pages, and breadcrumb trail line up with the audience you chose. ## Using Page Context to Confirm the Content Matches Your Audience Once a page opens, check the visible context before relying on the instructions. In Atloria, the fastest way to confirm you are in the right audience view is to compare four page elements: the page title, the audience label, the breadcrumb path, and the local navigation menu. These are the markers that tell you whether the topic is being presented inside the intended reader journey. Start with the page title to confirm you opened the right subject. Then look for an audience badge or audience label near the top of the page. After that, scan the breadcrumb trail. If the breadcrumb path looks broader than expected, or if it places the page under a general documentation section instead of an audience-focused section, you may be reading the general version. Finally, review the local navigation menu or sidebar. In an audience-specific view, the menu often groups pages differently and emphasizes the tasks most relevant to that reader group. Audience-specific pages can also change the supporting context around the main article. You may notice: - different related links - different sidebar groupings - audience-focused introductory text - examples aimed at a specific type of reader - calls to action that lead to audience-relevant next steps These differences help you avoid following instructions meant for another audience. A topic may share the same name across views, but the recommended path around it can be very different. If the topic itself looks right but the surrounding context does not, do not assume the page is fully correct for your needs. Reopen it from the audience-specific landing page or switch to the correct audience path before continuing. That extra check is especially useful when you arrive from a bookmark, a message, or a previously shared link. [SCREENSHOT: Same topic shown with audience-specific breadcrumbs and tailored sidebar links] ## Comparing General and Audience-Tailored Navigation The clearest difference between a general public page and an audience-specific page in Atloria is usually the navigation around the content. The article body may overlap, but the top-level menu, sidebar sections, and breadcrumb hierarchy can guide readers down very different paths. In the general documentation view, navigation is broader. The sidebar may include many sections across the full public documentation set, and the breadcrumb trail may point back to a wide documentation index. This is useful when readers are exploring freely, but it can expose pages that are not relevant to a specific audience. In an audience-specific public view, navigation becomes more selective. Atloria can hide unrelated sections and promote the pages most useful for that audience. The breadcrumb path may show a more focused route, and the sidebar may contain a shorter list of pages arranged in a sequence that makes sense for that reader group. Previous and next page controls can also change, leading to different destinations than the same topic would show in the general view. This means you should compare more than the page title when checking whether a link is correct. Look at the full reading frame around the page: | Page element | General view | Audience-specific view | |---|---|---| | Breadcrumbs | Broad documentation path | Audience-focused path | | Sidebar | Wider page list | Filtered, relevant sections | | Related links | General supporting pages | Audience-tailored supporting pages | | Previous/Next links | Broad reading sequence | Audience-specific reading sequence | For Documentation Managers, this is especially important when maintaining shared links. A page can be technically the right topic while still opening in the wrong navigation context. If the audience path matters, verify not just the destination page but also the breadcrumb trail, sidebar grouping, and related article links that appear around it. ## Checking Shared Links and Bookmarks Before You Read Shared links and saved bookmarks are often where audience confusion starts. In Atloria, a link can open a familiar topic title while still placing you in the wrong public reading path. Before you rely on the instructions on the page, take a moment to confirm that the link preserved the audience-specific context. Start by checking whether the bookmarked or shared page still includes the audience-specific route you expect. If the link opens a topic with broader breadcrumbs, a different sidebar, or unrelated related links, it may have resolved to the general documentation view instead of the intended audience view. This can happen when someone copies a link from the wrong public page or saves a bookmark before switching into the correct audience path. Use this quick three-point check every time you open a shared page: - **Page header:** confirm the topic title and look for the audience marker - **Breadcrumb trail:** make sure the path reflects the intended audience route - **Related links block:** check whether the suggested follow-up pages fit your audience [SCREENSHOT: Public page header and related links area used to verify audience context] If one of those three elements looks off, stop and compare the page with the audience-specific landing page. Open the same topic from that audience route and see whether the navigation changes. If it does, use the audience-specific version for reading and replace your bookmark with that version. Documentation Managers should be especially careful when distributing links in release notes, onboarding messages, or internal announcements. A shared topic link is only reliable if it opens with the same audience context your readers are expected to see. When in doubt, test the link from a fresh public session and verify the audience markers before sharing it more widely. ## Fixing Cases Where the Wrong Audience View Appears If Atloria opens the right topic but shows the wrong audience context, you can usually correct it without searching for the page again from scratch. The key is to restore the intended public reading path so the breadcrumbs, sidebar, and related links match the audience you meant to use. 1. Check the breadcrumb trail and sidebar first. 2. If the path looks too broad, return to the audience-specific landing page. 3. Open the topic again from the audience section menu or filtered page list. 4. If an audience control is available on the page, switch to the correct audience there. 5. Recheck the audience label, breadcrumb path, and related links area. This is the fastest fix when a direct link opens the general documentation version. Even if the article title matches, the broader breadcrumb path is a strong sign that the page is not being shown inside the intended audience journey. Reopening the page from the audience-specific route usually restores the correct context. If you are unsure which version to trust, compare these three elements side by side: - the audience label in the page header - the sidebar grouping - the related links area The version with the audience-focused markers is the one to use when you need a tailored reading experience. For Documentation Managers, it is worth testing published links in a logged-out public session. That check shows what readers actually see without private workspace context or saved navigation history affecting the result. If the audience-specific page does not appear consistently, update the shared link and test again until the public reading path opens correctly. After you can reliably open the right audience view, the next step is to verify those audience-targeted release paths more formally in [Validating Audience Targeted Release Views](doc:validating-audience-targeted-release-views). ## Overview Audience-specific documentation views in Atloria help readers stay inside the path designed for their role or reader group. The main thing to remember is that the topic title alone is not enough to confirm you are in the right place. You also need to check the page context around that topic. The most useful indicators are: - the audience label or audience marker - the breadcrumb trail - the sidebar or local navigation menu - the related links area - the previous and next page controls When those elements line up with the selected audience, you are likely reading the correct public documentation view. When they look broader or more generic than expected, you may have landed in the general public view instead. This matters because Atloria can present the same topic in more than one public reading path. The article may cover the same subject, but the navigation, examples, and recommended next pages can change based on audience. That audience-aware structure helps readers avoid unrelated instructions and move through documentation in a more useful order. If you need help deciding how those audience paths were planned in the first place, refer back to [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences). If you want to compare what readers see on public pages before they begin reading in detail, see [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation). [SCREENSHOT: Audience-specific public page with header, breadcrumbs, sidebar, and related links all visible together] ## Prerequisites Before using this workflow in Atloria, make sure you have the basic pieces needed to recognize and verify a public audience view: - Access to the public documentation site for the project you want to read - At least one audience-specific public route, landing page, or audience entry point already available - A topic that exists in public documentation and can be opened from both a general path and an audience-specific path - Familiarity with public navigation basics from [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience) - Familiarity with pre-launch review checks from [Reviewing Public Audience Pages Before Launch](doc:reviewing-public-audience-pages-before-launch) If you are a Documentation Manager and you plan to test shared links, it also helps to have: - a recently shared public link or saved bookmark - access to the audience-specific landing page for comparison - a logged-out browser session or private browsing window for public-view testing You do not need access to Atloria’s private project workspace to follow the reading checks in this guide. Everything here is based on what appears in the public documentation reader: the page header, breadcrumbs, navigation, and related links. If those items are visible, you can confirm whether you are in the correct audience-specific view. ## Opening the project analytics view and identifying the date range you are reviewing To make good documentation decisions in Atloria, start from the project’s analytics area rather than relying on a single document or page view. This keeps your reading focused on the full documentation set for that project, including guides, references, and release-related content. If you need a refresher on the general analytics workflow inside a project, see [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). 1. Open the project you want to review from your project list or project workspace. 2. Check the project header or project selector before reading any numbers. Make sure you are looking at the correct project, especially if you switch between multiple documentation workspaces during the day. 3. Open the **Analytics** view for that project. Stay in the project-level analytics screen so the totals reflect the project as a whole, not just one page. 4. Find the date-range control and select the reporting period you want to review. Choose the time window that matches the decision you are making, such as a recent release period, a launch week, or a longer trend window. 5. Look for any comparison setting that shows the current period against an earlier period. If a comparison is turned on, note that the screen may show both current values and change indicators. 6. Check whether any filters are active for version, environment, or similar scope controls. Before you compare results, confirm you are not mixing draft content with released documentation or reviewing a staging set when you meant to review published content. 7. Pause before interpreting the charts and cards. Read the filter bar and date controls one more time so you know exactly what content and time period the screen is showing. [SCREENSHOT: Project analytics view with the project header, date-range selector, and active filters highlighted] ## Reading the headline metrics that signal project performance The summary cards at the top of the analytics view give you the fastest read on how a project is performing. In Atloria, treat these cards as project-wide signals. They help you decide whether your documentation is attracting readers, keeping their attention, and supporting release activity over time. When you review headline numbers such as **Total Views**, **Unique Visitors**, **Average Time on Page**, and bounce or exit-related indicators, read them together instead of one at a time. A rise in **Total Views** can look positive on its own, but if **Average Time on Page** drops sharply during the same period, the project may be reaching more people while helping fewer of them find what they need. In the same way, a healthy number of **Unique Visitors** can mean new discovery, but it does not automatically mean the content is useful. 1. Start with the top metric cards and read the current values first. 2. Check the change indicator on each card to see whether the number is up or down compared with the previous period. 3. Compare traffic signals and engagement signals side by side. For example, pair **Total Views** with **Average Time on Page** instead of reading each card in isolation. 4. Watch for release-week distortion. A launch can create a short-term traffic spike that makes the project look stronger than it really is over a longer period. 5. Look for repeated movement across several cards. If views, visitors, and engagement all improve together, that usually points to a meaningful change in project performance. 6. Be cautious when only one card changes dramatically. A single spike may reflect a release announcement, a migration deadline, or a temporary burst of attention rather than a lasting improvement. A good reading of the headline area should answer one question: is this project gaining useful attention, or just temporary traffic? ## Using traffic and engagement views to find what content is helping or hurting users After the headline cards, move into the traffic and engagement tables. This is where Atloria becomes most useful for documentation decisions because you can see which pages are drawing people in, which ones hold attention, and where readers leave. 1. Open the table or list that shows top pages, top content, or similar page-level performance results inside the project analytics view. 2. Sort by **Views** first to identify the pages that attract the largest share of project traffic. These are often your most visible guides, release notes, onboarding pages, or reference content. 3. Sort by **Unique Visitors** next. This helps you separate pages with broad reach from pages that are revisited by the same group of readers. 4. Then sort by **Average Time on Page** to find pages where readers spend meaningful time. These often include setup guides, migration instructions, and detailed technical explanations. 5. Review entry-page data to see where readers begin. If many visitors start on a troubleshooting page, that may mean users are finding help through search before they ever reach your main navigation. 6. Review exit-page data to see where readers stop. A high exit rate on a setup or onboarding guide can signal confusion, missing steps, or weak follow-up links. 7. Compare low-engagement pages against what those pages are supposed to do. A short visit on a quick answer page may be fine. A short visit on a complex migration guide usually deserves attention. Look for patterns, not isolated pages. If several setup guides show high exits, or several troubleshooting articles show very short reading time, that points to a broader documentation problem rather than a single weak page. [SCREENSHOT: Top pages table with sorting controls for Views, Unique Visitors, and Average Time on Page] ## Comparing project trends across releases, launches, and documentation updates Project analytics become much more valuable when you compare one period against another. In Atloria, comparison views help you see whether a release, content update, or navigation change created a temporary spike or a lasting improvement. 1. Open the comparison option in the project analytics view. 2. Set the current reporting window to the release, launch, or update period you want to evaluate. 3. Choose a comparison period that makes sense for the question you are asking. A previous release window works well for release comparisons, while an earlier launch period can help you compare adoption patterns. 4. Review the trend lines and change indicators across the same set of metrics, rather than switching between unrelated views. 5. Match spikes and dips to known events in your team’s timeline, such as a product launch, a migration deadline, a documentation restructure, or a major update to navigation. 6. Check whether release-note traffic leads readers into other content afterward. A strong release usually creates an initial spike in release notes, then continued visits to task guides, upgrade instructions, or reference pages. 7. Compare before-and-after performance when you change page titles, reorganize content groups, or adjust navigation labels. If discovery improves after those changes, the trend should show up across the project rather than on only one page. This kind of comparison helps you avoid overreacting to launch-week excitement. A page that surges for two days and disappears from the top results tells a different story from a guide that keeps drawing readers for weeks after release. Use the analytics screen to separate short-term attention from durable documentation value. ## Turning analytics signals into documentation and release decisions Once you have read the project analytics clearly, use those signals to decide what to update, protect, expand, or retire. Atloria is most helpful when you connect the numbers to concrete documentation work instead of treating analytics as a reporting exercise. 1. Start with consistently high-traffic pages. Put these pages near the top of your maintenance list before each release. Review their screenshots, task steps, navigation labels, and version accuracy because they are likely to affect the largest number of readers. 2. Look for troubleshooting, migration, or onboarding pages that receive repeated search-driven traffic. These pages often reveal friction in the product experience or gaps in your core guidance. Improve cross-links, add clearer task steps, or strengthen the related onboarding content. 3. Protect low-traffic pages that show strong engagement. A specialist guide may not appear in the top traffic group, but if readers spend meaningful time there, it may be critical for advanced users or release teams. 4. Use repeated patterns to decide when a page should be split. If a very long page gets heavy traffic but weak engagement, readers may be struggling to find the right section quickly. 5. Retire or merge outdated content only after checking project-level trends across more than one period. A page with low traffic during one window may still matter during release cycles or migration events. 6. Feed your findings into release planning. Pages with sustained traffic should be validated before launch, while pages with high exits may need revision before the next version goes live. If you are deciding what to improve first, combine traffic, engagement, and release timing. The strongest candidates are usually pages that are both widely used and closely tied to upcoming product changes. ## Avoiding common mistakes when interpreting project analytics Analytics are useful only when you read them in context. In Atloria, a few common mistakes can lead to the wrong documentation priorities, especially when teams move quickly between projects, releases, and audience groups. - Do not compare two projects by raw **Views** alone if they serve different audiences. A broad public project and a specialist internal project will naturally show different traffic levels. - Do not assume a short **Average Time on Page** always means failure. Quick-reference pages, short release notes, and direct-answer content often do their job in a short visit. - Do not make structural changes until you confirm the date range, active filters, and comparison settings at the top of the analytics view. - Do not mix draft, staging, and released documentation when reviewing project performance. If version or environment filters are active, verify them before drawing conclusions. - Do not treat launch-week spikes as proof of long-term content success. Check whether readers continue into setup guides, upgrade instructions, or reference pages after the initial burst. - Do not remove specialist content just because it has lower traffic. Some pages support a smaller audience but still deliver strong value, especially when engagement is high. - Do not change staffing or roadmap priorities based on one short reporting window. Confirm the same pattern across multiple periods before making larger planning decisions. A careful reading usually means slowing down for a minute at the top of the screen. If the project name, date range, and filters are wrong, every conclusion below them will be wrong too. ## Overview Use this guide when you need to turn project analytics into documentation decisions inside Atloria. The focus here is not on learning what analytics are in general, but on reading the project-level analytics view in a practical way so you can decide what content to maintain, improve, expand, or review before a release. This document assumes you are already familiar with the basic project analytics area and want to go further by interpreting trends and acting on them. If you need the broader walkthrough of project analytics screens and common views, return to [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). What this guide helps you do: - Open the correct project analytics view and confirm the reporting scope - Read headline metrics such as **Total Views**, **Unique Visitors**, and **Average Time on Page** - Use top-page and engagement views to spot strong and weak content - Compare current performance with earlier release or launch periods - Turn analytics patterns into documentation and release decisions - Avoid common interpretation mistakes that lead to poor content changes This guide stays at the project level. It is meant for reviewing the overall documentation set for one project rather than judging a single page in isolation. That makes it especially useful when you are preparing for a release, reviewing the impact of a documentation restructure, or deciding where your team should spend update time. [SCREENSHOT: Project analytics landing view showing summary cards and page-performance sections] ## Prerequisites Before you use this workflow in Atloria, make sure the following basics are in place: - You can sign in to Atloria and open the project workspace you want to review - You know which project you are evaluating and can confirm it from the project header or project selector - You have access to the project’s **Analytics** view - The project has enough documentation activity to show meaningful trends in the analytics screen - You know the time period you want to review, such as a recent release window, launch period, or ongoing monthly trend - You understand whether you need to review released documentation only or compare it with another version or environment - You are familiar with the project’s recent changes, such as new releases, migration deadlines, navigation updates, or major content revisions It also helps to have these reference points ready before you begin: - A list of recent releases or launches you want to compare - Awareness of major documentation updates that may affect traffic patterns - Agreement within your team on what decision you are trying to make, such as improving onboarding, validating release readiness, or identifying pages that need maintenance first For the next step in this learning path, continue to [Using Project Activity Signals to Improve Release Planning](doc:using-project-activity-signals-to-improve-release-planning). ## Opening a project's audit history and understanding what is recorded In Atloria, start from the project you want to review, then open the project details area and go to the **Audit History** or **Activity** view. This is the best place to begin when you need evidence for a release, an approval trail, or a compliance request. If you already worked through release-focused checks in [Using Audit History for Release Checks](doc:using-audit-history-for-release-checks), use that process as your starting point and then stay in the audit view to gather the records you need for export. [SCREENSHOT: Project page with the Audit History or Activity tab highlighted] The audit list is typically easiest to read when you focus on the main columns first. Look for details such as: | Column or detail | What it tells you | |---|---| | **Timestamp** | When the event happened | | **User** | Who performed the action | | **Action** | What happened, such as create, edit, approve, or export | | **Record** | Which document, version, approval item, or project record was affected | | **Change summary** | A short description of what changed | Use this screen to review project events such as new records being created, document edits, status updates, approval decisions, permission-related changes, and export activity when Atloria records it in the audit trail. It also helps to know where to look when an event is not obvious. **Project-level activity** gives you a broad timeline across the project, which is useful when you are reconstructing what happened before a release. **Record-level history** is narrower and is better when you already know the exact document, version, or approval item you need to verify. Start with the project’s **Audit History** when you are unsure where the evidence sits, then open the related record if you need more detail. ## Filtering audit events to find compliance and release evidence Once you are in **Audit History**, narrow the list before you review or export anything. A long activity list is hard to defend in a compliance review, so use the filters to isolate only the events tied to the release window or audit period you care about. 1. Set the **Date range** first so the list only shows activity from the required review period. 2. Add filters for **User**, **Action**, or **Record type** to focus on the kind of evidence you need. 3. Use the search box to find a specific document, version, approval item, or named project record. 4. Change the sort order to **Newest first** or **Oldest first** depending on whether you are checking recent changes or reconstructing a full sequence. [SCREENSHOT: Audit History filters for date range, user, action, and search] For release and compliance work, the most useful filters are usually: - **Date range** for the release window, audit period, or approval cycle - **User** when you need to show who approved or changed something - **Action** to isolate approvals, edits, exports, or status changes - **Record type** to separate document activity from project settings or access changes - **Search** to find a release candidate, controlled document, or specific item name Sorting matters as much as filtering. Use **Oldest first** when you need to show the order of events, such as draft changes followed by review and then approval. Use **Newest first** when you are checking whether anything changed after a final approval or export. If the list still feels too broad, remove one filter at a time and reapply it carefully. That makes it easier to see which setting is excluding the entries you expected. For broader export planning, you can also compare this workflow with [Managing Audit Exports and Activity Records](doc:managing-audit-exports-and-activity-records). ## Reviewing individual audit entries and confirming the records you need After filtering the list, open the entries that look important instead of exporting immediately. A strong compliance record depends on confirming that each entry actually proves the event you need to show. 1. Click an audit entry in the list to open its full details. 2. Review the **Timestamp**, **User**, **Action**, and related **Record** information. 3. Check the change details to see exactly what was updated. 4. Follow any available link to the related document, version, or approval item. 5. Confirm that the historical event matches the current record state and your release requirements. [SCREENSHOT: Expanded audit entry showing timestamp, user, action, and change details] In the entry details, look for before-and-after values when Atloria shows them. These are especially useful for proving that a status changed from a draft or in-review state to an approved or release-ready state. They also help when you need to confirm that a document title, version status, or approval decision changed at the right time and by the right person. Use linked records carefully. If an audit entry opens the related project item, compare the audit event with what you see on that item now. This helps you answer questions like: - Was the final revision completed before approval? - Did the approval happen inside the required review window? - Was the released item the same one referenced in the audit trail? - Were there any later changes after the event you plan to cite? Build your final record set from entries that clearly show required approvals, final edits, release-related status changes, and any export or handoff activity tied to the review. If you need broader release decision context, pair this step with the comparison and approval guidance in [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions). ## Exporting audit history for sharing, review, or retention When the filtered audit list shows exactly the records you need, start the export from the **Audit History** page. Exporting after you filter is usually better than exporting everything and sorting it later, because the file is easier to review and easier to share with internal reviewers or auditors. 1. Apply the correct **Date range**, **Action**, **User**, and search filters on the audit list. 2. Click **Export** on the audit history screen. 3. If Atloria allows row selection, choose whether to export the full filtered list or only the selected entries. 4. Choose the available export format, such as **CSV** or another downloadable report option shown in the export menu. 5. Save the file with a clear name so you can identify the project, period, or release it covers. [SCREENSHOT: Audit History page with Export action and export format options] Before you confirm the export, double-check the list on screen. The export should reflect the exact project scope and filtered results you intend to share. If row selection is available, use it for tightly scoped evidence packages, such as a set of approval and status-change entries for one release candidate. If row selection is not available, rely on the filters to narrow the result set. The exported file should include the audit details visible in the list and related entry details, such as the event time, user, action, record reference, and change information when Atloria includes it in the output. Once downloaded, store the file where your team keeps release evidence or compliance records so it can be attached to review packets, retained for audit support, or shared during formal checks. ## Checking exported records before distributing them Always review the export before you send it to anyone. Even when the on-screen list looked correct, the downloaded file is the version that reviewers, auditors, or approvers will actually use. 1. Open the exported file and confirm it matches the project and audit period you intended to capture. 2. Check that the same event types shown in the filtered audit list appear in the file. 3. Review the key columns for readability and completeness. 4. Confirm that the file includes the approval, revision, or release evidence requested. 5. If needed, rerun the export with narrower filters before sharing it. [SCREENSHOT: Exported audit file open in a spreadsheet, showing timestamps, users, actions, and records] Pay special attention to the core fields. At a minimum, verify that the export clearly shows: | Field to check | Why it matters | |---|---| | **Timestamp** | Proves when the event occurred | | **User** | Identifies who performed the action | | **Action** | Shows whether the event was an edit, approval, export, or status change | | **Record reference** | Connects the event to the correct project item | | **Change details** | Explains what changed and supports the compliance claim | Then compare the file against the request you are answering. Internal reviewers may want proof of approvals and final revisions. Customers may want a release trail. Regulators or compliance teams may need a narrower set of controlled changes. If the export includes unrelated activity or sensitive details that are not needed, go back to **Audit History**, tighten the filters, and export again. A smaller, focused file is usually easier to approve and easier to retain. ## Fixing common problems with missing, incomplete, or unexpected audit exports If the audit list or export does not look right, troubleshoot from the **Audit History** screen before repeating the whole process. Most problems come from filters, scope, or access. - **No matching audit entries appear** - Recheck that you opened the correct project. - Expand the **Date range** in case the activity happened earlier or later than expected. - Remove one filter at a time, especially **Action**, **User**, or search terms, to see which one is excluding results. - **Expected approval or release events are missing** - Confirm that you are looking at the right type of record in the audit list. - Open the related document, version, or approval item and check whether its own history shows the event more clearly. - Search using the exact item name or release-related identifier shown in Atloria. - **The exported file does not match the on-screen results** - Refresh the audit view. - Reapply the filters and confirm the visible list before clicking **Export** again. - If row selection is available, make sure the correct entries are selected. - **You cannot export audit history** - Check whether your Atloria role includes access to audit records and the **Export** action. - If you can view the audit list but not export it, ask an administrator to review your permissions in the admin workspace. For broader permission and audit access guidance, see [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls) and [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Overview This guide focuses on one specific workflow in Atloria: reviewing a project’s **Audit History**, isolating the entries that matter for compliance or release review, and exporting those records in a form you can share or retain. The goal is not to review every project event. Instead, you use the audit list, filters, entry details, and **Export** action to build a clear record set that supports a release decision, an internal review, or an external request for evidence. You will work mainly from the project’s **Audit History** or **Activity** view. From there, you can narrow the timeline with **Date range**, filter by **User** or **Action**, search for the exact document or version involved, open individual entries for more detail, and then export the filtered results. This is especially useful when you need to show who made a change, when an approval happened, or whether a release-related status changed during a defined review window. This document assumes you already understand the basics of using audit history for release checks. If you need that earlier workflow, go back to [Using Audit History for Release Checks](doc:using-audit-history-for-release-checks). Here, the focus is on turning that review into an exportable compliance record. You will also see how to verify the downloaded file before sharing it, so the exported record matches the on-screen audit evidence and includes the fields your reviewers actually need. The next step after this guide is [Using Audit Records for Release and Approval Checks](doc:using-audit-records-for-release-and-approval-checks), which moves from collecting evidence to using it in approval decisions. ## Prerequisites Before you start, make sure you have access to the project and can open its **Audit History** or **Activity** view. You should also be able to recognize the project records involved in the review, such as the document, version, approval item, or release-related entry you want to trace. You will be in the best position to use this guide if the following are already true: - You can sign in to Atloria and open the correct project workspace - You know which project, release window, document set, or approval cycle you are reviewing - You can access the project’s **Audit History** or **Activity** screen - Your role allows you to view audit records - Your role also allows you to use **Export** if you need to download the results - You know the names of the records you need to search for, such as a document title, version label, or approval item It also helps to have the review scope defined before you begin. For example, know whether you need: - approval evidence - final revision history - status changes tied to release readiness - export activity for retention or handoff - permission or configuration changes related to controlled content If you are still confirming project access or account entry points, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) or [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). If you need help finding the right project workspace first, see [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards). ## Opening a parsing result and identifying what was analyzed When you return to a completed code parsing run in Atloria, start by opening the parsing result record from the Code Parsing Workspace for the project you are working on. If you already reviewed coverage in [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage), use that same result entry so you are checking symbols and dependencies from the exact same analysis. 1. Open your project in Atloria and go to the **Code Parsing Workspace**. 2. Find the parsing result you want to inspect in the results list or session history. 3. Open the result and read the header area first. 4. Confirm the visible status details, including whether the run completed successfully and when it was last analyzed. 5. Check the language, file type, repository, package, or source scope shown in the result summary. 6. Look for any indication that the run covered the full codebase or only selected files or folders. 7. Use the result navigation to identify the separate views for file coverage, symbols, and dependencies before you begin reviewing details. The header is the fastest way to avoid reviewing the wrong run. If the result shows only a limited selection of files, your symbol list and dependency map may be incomplete by design. That matters when you are planning architecture pages, API reference sections, or feature explanations. Pay close attention to how Atloria separates what was scanned from what was extracted. A file coverage area tells you what source content was included. A Symbols view shows what named items Atloria recognized inside that content. A Dependencies or Relationships view shows how those items connect. These are not interchangeable, so it helps to confirm which tab or panel you are on before drawing conclusions. [SCREENSHOT: parsing result page showing header details, analysis timestamp, scope summary, and tabs for files, symbols, and dependencies] ## Reviewing extracted symbols to see what the parser understood The Symbols view is where you check whether Atloria recognized the important named parts of the code you plan to document. This is especially useful when you need to confirm whether public-facing areas were captured clearly enough to support technical writing. 1. Open the **Symbols** tab or symbols panel inside the parsing result. 2. Scan the symbol list for recognizable names tied to the feature or code area you are documenting. 3. Review the symbol type shown for each entry, such as class, function, method, interface, module, or constant. 4. Use the file path or source location shown beside each symbol to confirm where it comes from. 5. Open a few key symbols to inspect their details. 6. Compare top-level items with nested items to see whether Atloria preserved parent-child structure. 7. Note any important gaps, such as missing public entry points or symbols with unclear names. A strong symbol list usually includes meaningful names, clear symbol types, and enough location detail to connect the item back to the source file. If you open a symbol detail panel and see information such as its signature, visibility, parent item, or source range, that gives you more confidence that Atloria understood the structure rather than only listing text matches. Look closely at relationships inside the symbol list. For example, if a top-level item contains several nested methods or functions, that suggests Atloria preserved the internal structure of that file. If everything appears flattened into one long list, you may need to be more cautious when using the result to explain ownership, feature boundaries, or public interfaces. This is also the point where you can separate likely documentation priorities from lower-value details. Publicly exposed items, shared modules, and clearly named entry points are usually more useful than deeply nested internal helpers. [SCREENSHOT: Symbols tab showing symbol names, types, file paths, and an expanded symbol detail panel] ## Inspecting dependencies and relationships between files and symbols After reviewing symbols, switch to the Dependencies or Relationships view to understand how Atloria connects files and named items. This view helps you move beyond “what exists” and into “what depends on what,” which is often the basis for architecture explanations, integration notes, and technical diagrams. 1. Open the **Dependencies** or **Relationships** tab in the parsing result. 2. Select a file or symbol that appears important in your documentation plan. 3. Review the linked entries that show what it imports, exports, references, extends, calls, or connects to. 4. Follow one relationship at a time into the next linked file or symbol. 5. Compare direct links with broader relationship chains so you can tell immediate dependencies from indirect ones. 6. Watch for missing or surprising gaps in the relationship list. 7. Record only the connections that Atloria shows clearly and consistently. When you trace a relationship, stay grounded in what the screen actually shows. A direct dependency is a visible first-level connection between one file or symbol and another. A broader chain may involve several hops. For documentation, that difference matters. If Atloria shows File A linked to File B, and File B linked to File C, do not automatically describe File A as directly dependent on File C unless the relationship view makes that explicit. Missing links can be just as informative as visible ones. If a public entry point appears isolated, or a central shared module has no incoming references, that may mean the parse is incomplete, the code area was only partially included, or the relationship extraction was limited for that language or file type. Use this view to identify likely feature entry points, shared building blocks, and cross-file interactions. Those patterns are often more useful for documentation planning than a raw list of files. [SCREENSHOT: dependency view showing linked files or symbols with relationship labels and selectable rows or graph nodes] ## Judging whether the parsed output is useful for documentation Not every parsing result is strong enough to support documentation decisions. Before you rely on it, use the visible evidence in Atloria to judge whether the output is complete and accurate enough for the kind of writing you need to produce. 1. Compare the result against the documentation task you are working on. 2. Check whether the files you need are present in the parsed scope. 3. Confirm that the main symbols for that area appear in the Symbols view. 4. Verify that the Dependencies or Relationships view shows the key connections you expected. 5. Open a few known files or code areas and compare what Atloria extracted with what you already know from the project. 6. Decide whether the result is good enough for planning, drafting, or only limited reference support. 7. Mark any areas that still need manual review before you write confidently. For architecture pages, you usually need broad coverage across folders, recognizable entry points, and visible relationships between major code areas. For API overviews, you need clear public symbols and stable naming. For feature explanations, you need enough structure to identify where a workflow starts and what supporting pieces it touches. Warning signs are usually easy to spot once you look for them: | What you see in Atloria | What it may mean for documentation | |---|---| | Many unnamed or generic symbols | The parser did not capture enough structure | | Missing expected files or folders | The parse scope may be partial | | Sparse or broken relationships | Dependency extraction may be incomplete | | Unsupported or mixed file types | Coverage may vary across the codebase | | Very limited symbol details | Use the result cautiously for deeper explanations | If the result is only partially reliable, you can still use it for orientation and topic discovery. Just avoid turning weak signals into firm statements in published documentation. ## Using parsing results to support technical writing decisions Once you trust the parsing result enough, you can turn what Atloria shows into practical writing decisions. The goal is not to repeat the code structure word for word, but to use symbols and relationships to shape documentation that matches the reader’s needs. If you need a broader workflow for using parsed output in writing, continue to rely on [Using Code Parsing Results to Support Technical Docs](doc:using-code-parsing-results-to-support-technical-docs). 1. Review the strongest symbols and relationship clusters in the parsing result. 2. Group related symbols into possible documentation topics or section headings. 3. Identify which items look publicly visible or externally important. 4. Use dependency links to locate feature entry points and shared supporting areas. 5. Separate internal implementation details from items that deserve reader-facing coverage. 6. Flag unclear areas that need source review or team confirmation. 7. Turn your findings into a documentation outline before drafting. A symbol list often maps naturally to topic planning. Exported modules, clearly named interfaces, and public classes can become candidate headings in a reference page or technical overview. Shared utilities and cross-cutting dependencies may deserve a short explanation, a diagram, or a note about reuse across features. Dependencies are especially helpful when you need to explain flow. If several files point back to one common entry point, that may be the right place to anchor a feature explanation. If one shared area appears across many relationships, it may deserve its own section so readers understand why it matters. Keep your audience in mind. Not every extracted symbol belongs in user-facing technical documentation. Focus on stable, externally meaningful names and visible boundaries. When Atloria shows incomplete relationships or ambiguous naming, treat those areas as research prompts rather than final answers. [SCREENSHOT: parsed results used alongside a documentation outline or notes panel for planning topics] ## Handling incomplete or confusing parsing results Sometimes the parsing result in Atloria looks thin, inconsistent, or harder to trust than expected. When that happens, work through the visible scope and result details before deciding whether to re-run the parse or validate the code manually. 1. Reopen the parsing result header and confirm the repository, package, branch, or file selection that was analyzed. 2. Check whether the run covered the full project or only selected folders or files. 3. Review the language or file type shown in the result details. 4. Return to the Symbols view and confirm whether missing items are absent everywhere or only in one area. 5. Open the Dependencies or Relationships view and look for signs that links were only partially resolved. 6. Decide whether the issue is likely caused by limited scope, weak parser support, or a genuinely simple code area. 7. Re-run the parse when the wrong content was included, and use manual validation when the result is present but unclear. A few patterns can help you decide what to do next: - If expected files are missing, the parse likely did not include the right source scope. - If names look collapsed, overly generic, or incomplete, the language support for that file type may be limited. - If dependencies are sparse even though symbols appear correctly, the relationship extraction may not have resolved fully. - If only one folder looks weak while the rest of the result looks strong, you may be dealing with a localized gap rather than a failed run. Use re-parsing when the problem is about what Atloria included. Use manual source review when Atloria included the right area but the extracted structure is still too thin to support confident documentation. That distinction saves time and keeps your documentation planning realistic. ## Overview This page focuses on one specific task in Atloria’s Code Parsing Workspace: reviewing a completed parsing result closely enough to decide whether it can support technical documentation work. You are not uploading code here, starting a new workspace session, or checking general parser coverage. Those tasks are covered elsewhere, including [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace), [Managing Code Parsing Workspace Sessions](doc:managing-code-parsing-workspace-sessions), and [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage). The main areas to review in Atloria are: - The parsing result header, where you confirm status, scope, language or file type, and analysis timing - The **Symbols** view, where you inspect the named items Atloria extracted from the source - The **Dependencies** or **Relationships** view, where you trace how files and symbols connect - The visible gaps or warnings that affect whether the result is reliable enough for documentation planning This review is most useful when you are preparing technical overviews, API reference coverage, architecture notes, or feature explanations and need to know whether the parsed output is trustworthy. A good result can help you identify entry points, shared areas, and documentation priorities. A weak result can still help with orientation, but it should not be treated as complete evidence. The next document in this sequence is [Uploading Code and Reviewing Parsing Results](doc:uploading-code-and-reviewing-parsing-results), which brings the upload and review steps together into one workflow. ## Prerequisites Before you review symbols and dependencies in Atloria, make sure you already have the right project context and at least one completed parsing result available. - You can open the relevant project and access its **Code Parsing Workspace** - A parsing run has already finished for the repository, package, or source files you want to inspect - You know which code area you are trying to document, such as a feature area, API surface, or architecture boundary - You have already reviewed general result coverage in [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage) - You understand the writing goal well enough to judge whether you need broad architecture coverage, public symbol coverage, or dependency mapping - You are ready to compare what Atloria shows against a few known code areas when needed It also helps if you have already worked through [Using Code Parsing Results to Support Technical Docs](doc:using-code-parsing-results-to-support-technical-docs). That earlier guide explains how parsed output fits into documentation work. This page stays narrower: it shows how to inspect the result itself and decide whether the extracted symbols and relationships are dependable enough to use. ## Opening the version workspace and understanding what it tracks In Atloria, you open the **documentation version workspace** from inside a specific project. This means the screen already reflects the project you came from, so the versions you see belong to that project only. If you were reviewing release planning in [Coordinating Version Statuses and Release Readiness](doc:coordinating-version-statuses-and-release-readiness), this workspace is where that planning becomes day-to-day version tracking. Once the workspace opens, the page is centered around a **version list**. Each row represents one documentation version for the current project, such as a release branch, milestone, or planned documentation update. Teams use these versions to keep release-specific content organized without mixing draft work for one release into another. Instead of treating the whole project as one moving set of pages, Atloria lets you work version by version. Across the workspace, users typically focus on four areas: - The **version list**, where you see all versions in the current project - **Status badges** or progress indicators that show where each version sits in the release workflow - **Compare entry points**, used to check differences between one version and another - **Review actions**, which let you move a version into review or open its review-related work [SCREENSHOT: Documentation version workspace showing the project context, version list, status badges, compare option, and review actions] Different roles usually read this screen in different ways: - **Documentation Managers** scan the list for versions that are close to release and versions that are blocked - **Project Administrators** use the same workspace to understand project-wide progress across multiple active versions - **Technical Writers** usually focus on the versions assigned to them, checking whether content is still in drafting, already under review, or waiting for follow-up Because the workspace stays tied to one project, it becomes the main place to monitor release progress without leaving that project’s documentation flow. ## Reading the version list to see release progress The **version list** is the fastest way to understand how documentation work is moving across releases in Atloria. Each row represents one version, and the row-level details help you judge whether that version is still being written, already in review, approved, or held up somewhere in the workflow. The most important item in each row is the **version name**. This tells you which release, milestone, or documentation branch you are looking at. Next to that, Atloria shows a **status badge** that summarizes the version’s current stage. This badge is the clearest signal when you are scanning the list quickly. A version in active writing looks different from one that is under review or already approved, so you can spot bottlenecks without opening each version individually. Depending on the row, you may also see other progress signals tied to release readiness. These are used to help you answer practical questions such as: - Which version still needs writer attention - Which version is waiting on reviewer input - Which version is ready for the next release checkpoint - Which version should not be published yet The list view is especially useful when several releases are active at the same time. Instead of opening versions one by one, you can compare their statuses side by side and identify which release branch needs attention first. The workspace may also include controls that narrow what you see, such as **sorting**, **filtering**, or **grouping** options. Use these controls when the project has many versions and you want to focus on a specific release cycle or only versions in a certain stage. [SCREENSHOT: Version list with version names, status badges, and row actions] When you need deeper detail, open the row actions for a version. That is usually where you move from list-level monitoring into comparison or review work. ## Following version statuses from draft work to release-ready content In Atloria, the version workspace acts like a release progress board. The **status** shown on each version tells your team what kind of work is expected next and who should take action. Rather than opening every version to understand its condition, you can use the visible status in the list to tell whether writing is still underway, review is in progress, approval is complete, or the version is blocked before release. The usual flow moves from **drafting** into **review**, then toward **approval** and final release preparation. Even if your team’s pace differs from project to project, the workspace still shows the same core idea: a version advances through clear checkpoints before it is considered release-ready. Here is how teams typically interpret the visible statuses: - **Draft** or similar early-stage status means contributors are still writing, editing, or organizing content - **In Review** means the version has moved beyond active drafting and is waiting on reviewer input or review completion - **Approved** means the version has passed review and is generally ready for the next release checkpoint - A **blocked** or incomplete state means something still needs attention before the version can move forward These badges matter differently depending on your role: - **Contributors** look for statuses that tell them whether they should keep editing or pause for review - **Reviewers** look for versions already submitted and ready for feedback - **Administrators and managers** look for versions that are stalled between checkpoints When a status changes, the update appears directly in the workspace so the row reflects the latest stage. If a version does not seem ready to move forward, the status usually tells you where it is waiting: - still in writing - waiting for review - waiting for approval - not yet ready for final release preparation This is why the workspace is so useful during release coordination. It gives everyone a shared view of progress inside the project, turning version tracking into something visible and easy to act on. ## Comparing versions to see what changed between releases The **Compare** option in the version workspace helps you understand what changed between one documentation version and another. You usually start from a version row, a row action menu, or another compare entry point tied to the selected version. This keeps the comparison anchored to the project you are already working in, so you are always comparing versions from the same documentation set. When you open comparison, Atloria lets you choose the two versions you want to review. In most cases, this means selecting a **source version** and a **target version**. Teams often use this to compare a current draft against the last approved or last published version. That makes it easier to validate whether the latest release work includes the expected updates before sending it forward. The comparison view is designed to surface release differences clearly. Instead of manually opening pages side by side, you can review the version delta in one place. Atloria highlights content that was: - **added** - **removed** - **modified** This is especially helpful when a release includes many page updates and you need to confirm what actually changed. A documentation manager might compare the current release against the previous published version to confirm scope. A writer might compare a draft against the last approved version to double-check that required updates were included. A project administrator might use comparison before a release checkpoint to make sure the version reflects the planned release work. [SCREENSHOT: Version comparison screen showing source version, target version, and highlighted changes] Common comparison scenarios include: - checking what changed since the last published version - validating updates before starting or requesting review - confirming that a release branch contains only the intended documentation changes - reviewing whether a version is truly ready for approval For a broader explanation of comparison decisions, see [Working with Version Comparison Views](doc:working-with-version-comparison-views). ## Starting reviews from the workspace and tracking review entry points The version workspace is not only for monitoring progress. It also gives you direct **review entry points** so you can move a version from drafting into formal review without leaving the project context. These entry points may appear as a **button**, a **row action**, or a control connected to the version’s current status. From the version list, start by locating the row for the version you want to review. Open the available action for that row and choose the review-related option. When you do this, Atloria carries the selected version with you into the review flow. That means you do not need to reselect the project or hunt for the correct release again—the review opens in the context of the version you started from. This handoff is especially useful when several versions are active at once. Managers can move directly from scanning the list to opening review on the version that is ready. Writers can use the same entry point to submit work or check whether feedback is still pending. Review availability usually depends on the current **status** of the version. In practice, that means: - versions still being drafted may need more work before review can begin - versions already in review may show review-related actions instead of a fresh submission option - versions with pending feedback may need follow-up before they can move ahead - approved versions may no longer need a review start action because they have already passed that checkpoint [SCREENSHOT: Version row with review action and status badge] This workspace-level review access helps teams coordinate handoffs cleanly. A writer can finish updates, open the review action from the same row, and move the version forward. A manager can later return to the list and immediately see whether that version is still under review, waiting on feedback, or already approved. For more detail on review decisions themselves, refer to [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions). ## Resolving common issues when versions, statuses, or comparisons do not look right If something in the version workspace looks wrong, start with the project context shown in Atloria. Most issues come from being in the wrong project, comparing the wrong versions, or expecting a status change before the related review step is complete. If the **version list is missing an entry** you expected to see, first confirm that you opened the workspace from the correct project. The version list only shows versions for the current project. If you are in the right project and the version still does not appear, check whether that documentation version has actually been created in that project yet. If a **status badge does not match team expectations**, look at where the version is in the workflow. A version may still be waiting for review completion, approval, or another release checkpoint before the badge updates. For example, a team might think a version is ready, but the workspace can still show a review-related status until that stage is fully completed. If the **Compare** option is unavailable or the comparison looks incomplete, make sure there are at least two valid versions available to compare. Then confirm that you selected the correct source and target versions. Many comparison problems come from choosing the wrong pair, especially when several similarly named releases exist in the same project. If the **review action cannot be started**, check two things: - whether the version is currently in a review-eligible state - whether your Atloria access level includes permission to open the review workflow from the workspace [SCREENSHOT: Version workspace with missing compare or review action highlighted] When troubleshooting, it often helps to scan the row carefully for the **version name**, **status badge**, and available **actions** before assuming data is missing. If the release itself is progressing but the workspace still seems confusing, revisit [Coordinating Version Statuses and Release Readiness](doc:coordinating-version-statuses-and-release-readiness) to align your team’s expectations with the visible workflow stages. ## Overview The documentation version workspace in Atloria gives you one project-focused place to monitor release progress and act on it. Instead of treating versions as separate, disconnected records, the workspace brings together the details your team uses most often: the **version list**, **status badges**, **comparison tools**, and **review entry points**. At a glance, this screen helps you answer several important release questions: - Which versions exist in this project - Which versions are still being drafted - Which versions are under review - Which versions are approved or close to release - Which versions need comparison before the team moves forward This workspace is especially useful when a project has multiple active releases. A writer may only care about one assigned version, but a documentation manager or project administrator can scan the full list and quickly understand where work is moving and where it is stuck. Because the workspace stays tied to the current project, every action you take—whether opening a comparison or starting a review—happens in the right release context. You will get the most value from this screen when you use it as a working dashboard rather than just a list. Open it regularly to: - spot versions that are waiting on review - identify versions that are ready for the next checkpoint - compare release changes before approval - keep project-wide documentation work aligned with release timing If you need more detail on related tasks, use the linked guides for comparison, review, and release coordination rather than trying to do everything from memory. The workspace is where those tasks come together in one visible project view. ## Prerequisites Before this workspace is useful, a few basics need to already be in place inside Atloria. You do not need advanced setup, but you do need the right project context and at least some version activity to review. Make sure the following are true: - You can open the relevant **project** in Atloria - The project already has one or more **documentation versions** - You have access to the project’s version workspace - If you want to use **Compare**, the project has at least **two versions** - If you want to start or follow **Review**, the version is far enough along in the workflow for review-related actions to appear It also helps if you are already familiar with the earlier version guides, especially: - [Managing Project Version Workspaces](doc:managing-project-version-workspaces) - [Managing Project Version Timelines and Status Decisions](doc:managing-project-version-timelines-and-status-decisions) - [Coordinating Version Statuses and Release Readiness](doc:coordinating-version-statuses-and-release-readiness) Those guides explain the broader release planning context. This document focuses on how that work appears inside the version workspace itself. Different users may approach the workspace with different expectations: - **Technical Writers** should know which version they are responsible for - **Documentation Managers** should know the release cycle they are monitoring - **Project Administrators** should have access to the project areas where version progress is tracked If you are ready to move from understanding the workspace to actively managing release movement through it, continue with [Managing Version Workspaces Statuses and Release Tracking](doc:managing-version-workspaces-statuses-and-release-tracking). ## Finding your way with the public sidebar In Atloria’s published documentation, the **public sidebar** is the main place readers use to move from one page to another. It shows the published documentation structure as a visible list of **categories** and **pages**, so readers can understand both what is available and where they are in the overall set of docs. If you already know the basics of moving through public docs, this section builds on [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) and focuses on how readers discover content more efficiently. When you look at the sidebar, you will usually see: - **Top-level categories** that group related topics - **Nested categories** under broader sections - **Individual page titles** listed inside those groups - A clear **active page highlight** showing the page currently open That active highlight matters because it helps readers stay oriented while moving through a large documentation set. Instead of guessing where a page belongs, they can glance at the sidebar and see the surrounding category and nearby related pages. If a category contains more content, readers can **expand** it to reveal child categories or page titles, then **collapse** it to reduce clutter and focus on the section they need. This is especially useful when a project has many published pages and readers want to scan only one branch of the documentation tree at a time. Selecting a page title in the sidebar opens that published page in the main reading area. Readers do not need editing access or project workspace access to do this. They simply use the public navigation to move through available content. [SCREENSHOT: Public documentation page showing the sidebar with expanded categories, nested pages, and the current page highlighted] A well-organized sidebar turns the published documentation into a browsable map. Readers can move confidently because the page list, category grouping, and current-page highlight all work together. ## Browsing documentation through categories and page hierarchies In Atloria, **categories** and **pages** do different jobs in public navigation. A **category** helps organize related content into a section, while an **individual page** is the actual document a reader opens and reads. Understanding that difference makes it much easier to scan the sidebar and predict where information is likely to be found. Readers often move through public documentation in layers: - Start with a **top-level category** - Open a **child category** if the topic is broken into smaller sections - Select a specific **published page** - Continue deeper if more nested content is available This hierarchy is what makes long documentation sets manageable. Instead of showing one long, flat list of page titles, Atloria groups content into meaningful sections. A reader looking for setup instructions, for example, can first identify the broad section, then narrow down into a more specific subgroup, and finally choose the exact page they need. Nested category structures are especially helpful when documentation includes: - Introductory pages - Task-based guides - Reference pages - Audience-specific sections - Detailed subtopics under a larger feature area For documentation managers, category names and page order strongly affect public discovery. Readers scan quickly, so labels should be clear and specific. A category name should tell readers what kind of content sits inside it, and page titles should distinguish one topic from another without forcing readers to open several pages just to compare them. Ordering also matters. Readers usually expect pages to appear in a sensible sequence, such as from basic to advanced, from overview to detail, or from setup to troubleshooting. If related pages are scattered across unrelated categories, readers are more likely to miss important content. [SCREENSHOT: Sidebar showing a top-level category expanded into child categories and individual published pages] When categories are named clearly and arranged logically, readers can discover content by browsing, not just by already knowing the exact page title. ## Moving between pages with in-content links The sidebar is not the only way readers move through published documentation in Atloria. Many pages also include **links inside the page content** that point to related published pages. These in-content links help readers continue naturally from one topic to the next without returning to the sidebar each time. This creates two different navigation styles: - **Sidebar navigation** for browsing the overall documentation structure - **In-content links** for following a guided reading path inside the page itself Both are useful, but they support different reading habits. A reader who wants to explore broadly may rely on the sidebar to compare sections and jump between categories. A reader who is already on the right topic may prefer to follow links in the page body to go directly to the next related page. This is especially helpful for guided content flows, such as: - Moving from an introduction page to a detailed setup page - Jumping from a feature overview to a task-specific guide - Opening a related troubleshooting page from a how-to article - Following a sequence from summary content into deeper subpages When a reader selects one of these links, Atloria opens the linked published page in the main content area. The **sidebar updates** to reflect the new location, showing the newly active page and its place within the category structure. That means readers do not lose context when they navigate by link instead of by sidebar. [SCREENSHOT: Published page with a link inside the content area and the sidebar updating after the linked page opens] This combination is important for content discovery. The sidebar helps readers understand the full structure, while in-content links help them move through related topics at the moment they need them. If you are planning public reading paths, use links to connect pages that are commonly read together rather than forcing readers to backtrack through the category tree every time. ## Using the table of contents to jump within a page On longer published pages in Atloria, the **table of contents** helps readers move within the current page instead of between different pages. It is built from the page’s visible **headings**, so section titles become clickable jump points that take readers directly to the part of the page they want. This is useful when a page covers several related topics, such as an introduction, setup notes, examples, and troubleshooting details all in one document. Rather than scrolling through the entire page, readers can scan the table of contents and jump straight to the section name that matches what they need. The table of contents helps readers by: - Showing the page’s section structure before they scroll - Making long pages easier to scan - Letting them jump directly to a lower section - Revealing whether the page includes the topic they are looking for Because the table of contents depends on heading structure, clear heading labels improve navigation. Readers benefit most when headings are specific and easy to recognize. A heading like **Troubleshooting login issues** is much easier to spot in the table of contents than a vague heading like **More information**. Heading levels also matter. When headings are used consistently, the table of contents reflects the page structure more clearly, showing main sections and supporting subsections in a readable way. That improves both on-page navigation and overall discoverability, because readers can understand the page at a glance. [SCREENSHOT: Long published documentation page with a visible table of contents linking to section headings] If a reader arrives on a long article from the sidebar or from an in-content link, the table of contents becomes the fastest way to refine their path. They can stay on the same page, skip to the right section, and continue reading without losing momentum. ## Understanding how readers discover related content Readers rarely move through published documentation in just one way. In Atloria, content discovery usually comes from several navigation elements working together: the **sidebar**, the **category hierarchy**, **in-content links**, and the **table of contents**. When these are aligned, readers can move from broad exploration to precise answers without feeling lost. A common reading path looks like this: - Enter the published docs on a landing or section page - Use the **sidebar** to open a broad category - Drill into a **child category** to narrow the topic - Open a specific page from the page list - Use the **table of contents** to jump to the right section - Follow an **in-content link** to a related page for more detail This layered workflow is what makes public documentation feel connected instead of fragmented. A reader might begin with only a rough idea of the topic, then use the sidebar to browse, the page title to confirm relevance, the table of contents to skip ahead, and inline links to continue into supporting material. Documentation managers can make this easier by checking that major pages are reachable in at least one obvious way: - Through the **sidebar** - Through a clear **category path** - Through **contextual links** from related pages - Through recognizable **page titles** and **section headings** Dead ends usually happen when an important page exists but is hard to discover from nearby content. If a reader finishes a page and has no visible next topic, they may stop even though useful related pages are available elsewhere in the published tree. Consistent naming helps prevent that. When **page titles**, **category labels**, and **heading names** use the same language, readers can scan faster and trust that they are following the right path. If you need more detail on version-aware reading while navigating public docs, see [Reading Versioned Documentation in Public Views](doc:reading-versioned-documentation-in-public-views). ## Fixing navigation problems readers may encounter When readers struggle to move through published documentation in Atloria, the problem is usually visible in the navigation itself. Start by checking what the reader sees in the **sidebar**, on the **page title**, and in the **table of contents**. Small structural issues can make published content feel much harder to find than it really is. If a page is hard to find in the sidebar, review whether it appears under the category readers would naturally expect. Also check its position in the page list. Even a correctly published page can be overlooked if it sits under an unexpected category or appears in an order that breaks the reading flow. Look for issues such as: - A page placed under the wrong **published category** - A useful page title buried too low in a long section - Related pages split across categories without clear labels - A title that does not match the terms readers scan for If readers cannot tell where they are, confirm that the current page is clearly reflected by the **active page highlight** in the sidebar and that the **page title** matches the surrounding category labels. Similar page names in the same section can make orientation harder, especially if nearby titles are too broad or repetitive. When the **table of contents** is missing or incomplete, the page may not have a clear heading structure. Long pages are much easier to navigate when section headings are visible and distinct enough to appear in the on-page navigation. If related topics feel disconnected, add or revise **in-content links** between pages that are commonly read together. Readers should not have to return to the sidebar after every page just to continue a common workflow. [SCREENSHOT: Published page showing sidebar location, page title, and table of contents for navigation troubleshooting] A good troubleshooting check is simple: open the page as a reader, try to find the next likely topic, and see whether the sidebar, headings, and links make that path obvious. ## Overview Public navigation in Atloria helps readers do more than open pages one by one. It gives them a clear way to **discover**, **compare**, and **move through** published documentation using the structure visible on the page. The most important parts of that experience are the **public sidebar**, the **category hierarchy**, **in-content links**, and the **table of contents**. Together, these elements support different reading behaviors: - **Browsing** through categories in the sidebar - **Scanning** page titles to find the right document - **Jumping** within a long page through the table of contents - **Following** links in the content to continue to related topics For readers, this means they can start broad and become more specific as they go. They might first recognize a category name, then choose a page title, then jump to a section heading, and finally open another linked page for more detail. That is the core of content discovery in published documentation. For documentation teams, the public reading experience improves when navigation elements stay aligned: - Category names match the language readers expect - Page titles clearly describe the topic - Heading labels make sense when shown in the table of contents - Related pages are connected through visible links If one of those pieces is unclear, readers may still reach the content, but they will do it more slowly and with more guesswork. If all of them work together, the published docs feel easy to explore even when the documentation set is large. This document focuses on how readers discover and move through public content. The next guide, [Managing Reader Navigation Across Public Documentation](doc:managing-reader-navigation-across-public-documentation), looks at how to shape that experience across the full published documentation set. ## Prerequisites Before using the navigation patterns in this guide, readers should already be comfortable opening and reading published documentation in Atloria. This topic assumes you can already recognize the public reading view and move around basic published pages. You will get the most value from this guide if you already understand: - How to browse published pages from the public reading experience - How public navigation differs from editing inside project workspaces - How version context affects what readers see in public docs - How audience-specific content can change what appears in navigation Helpful background reading includes: - [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) - [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page) - [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content) - [Reading Versioned Documentation in Public Views](doc:reading-versioned-documentation-in-public-views) You do not need access to Atloria’s editing screens, project setup screens, or admin areas to follow this guide. Everything here is based on the **published documentation view** that readers use publicly. It also helps to have a documentation set with: - More than one published category - Several published pages - Visible section headings on longer pages - At least a few links between related pages Those elements make it easier to see how discovery works in practice. If your published docs are still small, the same navigation ideas still apply, but the sidebar structure, page relationships, and table of contents will become more noticeable as your documentation grows. ## Confirming the release view and audience you are testing Before you test any public page, make sure you are looking at the correct release in Atloria. Start in the release area for your project and open the release you plan to share. Check the release name, the selected documentation version, and any version label shown in the release details. If your team uses multiple versions, this step matters because the same page title can appear in more than one release. Next, confirm that you are testing the public release view, not an internal editing or review screen. Use the release preview or public page opening option tied to that release so you are validating the same view your readers will receive. If the release shows audience settings, review the audience names attached to it and confirm they match the groups you expect to test, such as separate reader segments with different page visibility. Pay close attention to which pages are included in the release. A page should already be part of the published release set and have a public route. If you see pages that are still in draft or pages that are missing a public path, do not include them in your validation result because readers will not reach them the same way. A quick release check usually includes: - The correct project - The correct release - The intended documentation version - The intended audience or audiences - Public pages with live routes [SCREENSHOT: Release details panel showing release name, version label, audience settings, and public preview option] If you need a refresher on reading audience-based views before this validation step, see [Reading Audience Specific Documentation Views](doc:reading-audience-specific-documentation-views). ## Opening the public page as each target audience Once you have the right release open, launch the page from the release preview or the public link shown for that release. This helps you avoid testing an outdated bookmark or a general project link that may not reflect the audience-targeted setup. Open the exact page stakeholders are expected to review. 1. Open the public page from the release preview or public link. 2. Select the first audience view available for that release. 3. Note the page title, visible sections, callouts, links, and navigation items. 4. Switch to the next audience view and repeat the same check. 5. Open the same page in a private browser window and test again. As you move between audiences, compare what changes on the page. Look for hidden sections, different wording, different navigation choices, or missing links. In Atloria, these differences are often the clearest sign that audience targeting is working as expected. If two audiences should see different content but the page looks identical, pause and verify the audience setup before continuing. It helps to keep a simple comparison note while testing. Record the audience name, the page you opened, and the main items visible on screen. That makes it easier to explain differences during stakeholder review. Use a clean browser session for at least one pass. A signed-in session, an older preview tab, or saved browsing state can make a page appear under the wrong audience context. A private window gives you a cleaner check of the public experience. [SCREENSHOT: Public documentation page open with audience-specific content and visible navigation] [SCREENSHOT: Same page opened in a private browser window for comparison] ## Checking that routes resolve to the correct public pages After confirming the visible content, test whether the page route itself is correct. Start by looking at the page address in the browser and compare it with the route configured for the release. The route should match the intended public page slug. If Atloria opens a different route than expected, you may be landing on an older page, a default page, or a different release path. 1. Open the page directly from the release link. 2. Copy the page link and paste it into a new browser tab. 3. Open the same page through public navigation inside the documentation site. 4. Compare the results to make sure all entry points lead to the same page. 5. Repeat this check for each audience-targeted route you plan to share. Also test what happens when a reader tries to open a route that should not be available to their audience. The page should not quietly show content meant for another audience. Instead, confirm that Atloria shows the expected public result, such as a not found page or a limited-access view. This is especially important when stakeholders receive copied links by email or chat and open them directly. Check more than the page body. Review the navigation menu, sidebar links, and any search-driven links available on the public documentation site. A route can be hidden on the page itself but still appear in navigation if the release setup is incomplete. If an audience should not see a page, they also should not see a link leading to it. [SCREENSHOT: Browser address bar with the expected public route] [SCREENSHOT: Public navigation menu showing only audience-appropriate pages] ## Verifying the version context shown on the page A targeted page can still be wrong if it is showing the wrong documentation version. Open the public page and look for any version label in the page header, a version badge, or a version switcher. Compare that label with the version selected in the release details. If the release is meant to show a specific version, the public page should match it everywhere. 1. Open the page and locate the version label or version switcher. 2. Compare the displayed version with the release version in Atloria. 3. Open two or three related pages from the same navigation tree. 4. Confirm the version stays the same as you move between pages. 5. Copy a page link and reopen it in a new tab to confirm the same version appears. This step is important when your team maintains multiple versions at the same time. A page may look correct at first glance, but the text, screenshots, or links may belong to a different version than the one you are preparing for release. Compare the public page against the selected release version in your project workspace and make sure audience-specific sections match the published state for that version. Watch for links that jump readers to the latest version instead of keeping them in the release you are validating. This often shows up when you open a related page, use a navigation link, or paste a copied link into a new tab. If the version changes unexpectedly, that is a release issue worth fixing before review. [SCREENSHOT: Public page header showing version label] [SCREENSHOT: Version switcher or version badge remaining consistent across related pages] ## Comparing what stakeholders will see before launch Before you send a release for approval or external review, capture exactly what each audience will see. The easiest way to do this is to use one validation table for every audience and page combination you test. That gives you a clear record of the route, the version, and the visible differences. | Audience | Tested public page | Expected route | Actual route | Displayed version | Notes | |---|---|---|---|---|---| | Audience name | Page title | Expected public route | Opened route | Version label shown | Visible differences or issues | | Audience name | Page title | Expected public route | Opened route | Version label shown | Visible differences or issues | | Audience name | Page title | Expected public route | Opened route | Version label shown | Visible differences or issues | As you compare audiences, note the items that change in the final public rendering: - Hidden or visible sections - Different callouts or instructions - Audience-specific navigation items - Different page titles or metadata - Version labels that differ from the release setup Take screenshots of the final public page for each audience you test. Focus on the page header, the main content area, and the navigation around the page. These screenshots are useful when a reviewer wants proof that a page is ready without opening every route personally. [SCREENSHOT: Side-by-side comparison notes for two audience-targeted page views] [SCREENSHOT: Final public rendering captured for stakeholder approval] If you find a mismatch, write it down in plain language. For example: “Partner audience opens the correct page title, but the navigation still shows Internal Setup,” or “Version label shows the latest release instead of Version 2.1.” Clear notes make follow-up faster. ## Fixing common validation problems before stakeholder review Most validation issues fall into a few repeat patterns. If an audience sees the wrong content, start by reopening the release settings and checking the audience assignment tied to that release view. Then test again in a private browser window. In Atloria, an older session or previously opened preview can make a page appear under the wrong audience context. If a public link opens the wrong page, compare the page slug in the browser with the route you expected to test. Then open the page from the release preview again and see whether both paths match. If they do not, review the page route used in the release and any alternate public path your team may have shared earlier. Replace old stakeholder links with the current release link before review. When the version label is wrong, go back to the release details and confirm the release is tied to the intended documentation version. Then reopen the page and test navigation to related pages. If the first page is correct but later pages switch versions, the release needs more route checking before it is ready. If navigation exposes pages for the wrong audience, review the public menu and sidebar entries included in the release. A page should not appear in navigation if that audience should not open it. Remove or hide links that point to pages outside the targeted release view. Common fixes to verify before retesting: - Correct the audience assigned to the release view - Reopen the page in a clean browser session - Confirm the public route matches the intended page slug - Check the selected documentation version in the release - Remove navigation links that expose the wrong audience pages For broader admin checks around access, analytics, or audit review, see [Using the Admin Workspace](doc:using-the-admin-workspace), [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls), and [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Overview This guide focuses on one specific task in Atloria: validating that a public release view shows the right documentation to the right audience before you share it. You are not creating audiences here and you are not planning the content structure from scratch. Instead, you are checking the final public result of a release that already has audience targeting applied. The validation process centers on four things: - The release you opened - The audience context you selected - The public route readers will use - The documentation version shown on the page That combination determines what stakeholders actually see. A release can look correct inside a project workspace but still fail in the public view if the wrong route opens, the wrong audience content appears, or the page switches to the wrong version after navigation. Use this guide when you are preparing for launch, doing a final internal review, or sending a stakeholder preview. If you already reviewed how audience-specific pages behave in public documentation, this guide builds on that work rather than repeating it. For earlier planning and page review steps, see [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences) and [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation). The goal is simple: when someone opens the public page, Atloria should show the correct page, for the correct audience, in the correct release version, with the correct navigation around it. ## Prerequisites Before you start validating a targeted release view in Atloria, make sure you have access to the project and the release you need to test. You should also be able to open the public documentation view for that release. If you cannot reach the release area or public preview, ask an Atloria admin or project owner to confirm your access. You will get the best results if the following items are already in place: - A project with at least one published documentation release - Audience settings already defined for the content you are testing - Public pages with active routes - A release version selected and ready for review - A way to open the public page for each audience you need to validate It also helps to prepare a short list of the exact pages you plan to test. Include the page title, expected audience, and expected route so you can compare what opens in the browser against what should be visible. If your team is reviewing multiple versions, note the version label for each page in advance. For cleaner testing, have a private browser window available. This lets you confirm that saved sessions or earlier previews are not affecting the public result. If you are collecting approval evidence, be ready to capture screenshots during the validation pass. If you still need help with account access or sign-in before reaching your project, use [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). After you finish the checks in this guide, continue with [Reviewing Audience Specific Reading Experiences](doc:reviewing-audience-specific-reading-experiences). ## Confirming you can review the version as the intended audience Before you test anything in public view, make sure you are validating the exact version you plan to release. In Atloria, start from the project workspace and open the version list or the version selector for the documentation set you are preparing. Check the version name carefully and confirm you are opening the release candidate, published version, or shareable version you intend to expose. If you recently reviewed access behavior in [Managing Version Access and Sharing Outcomes](doc:managing-version-access-and-sharing-outcomes), use that setup as your starting point rather than redoing the same access decisions. 1. Open the project and go to the documentation version you want to validate. 2. Check the version label, status, and any visibility indicator shown on the version screen. 3. Confirm whether the version is set up for public access, restricted access, or sharing by link. 4. Review any audience targeting already applied to this version. 5. Make sure you have a way to test with each reader type you care about. Your test readers should match the real release plan. That usually means checking at least these viewing situations: - An anonymous visitor in a private or incognito browser window - A signed-in reader who should be allowed to open the version - A signed-in reader who should not be allowed to open the version - Any audience-specific reader account used for targeted documentation If your team uses audience rules, confirm those rules are already in place before you begin testing. If you change visibility, audience, or release settings halfway through the check, your results can be misleading. It also helps to note whether the version should appear in navigation, public listings, or only through a direct share link. [SCREENSHOT: Version list showing version name, status, and visibility before public-release testing] ## Checking how the version appears in public and restricted views Once you know you are testing the correct version, open it the same way a reader would. In Atloria, this usually means using the public page, preview, or shared link for that version. Your goal is to confirm that the version opens correctly, shows the right content, and respects the expected access rules. Do not rely only on what you see while signed in with a full-access account, because that can hide problems that real readers will run into. 1. Open the version using its public view, preview, or copied share link. 2. Confirm the page loads normally and does not ask for sign-in unless sign-in is expected. 3. Check the page title, header, navigation, and visible content to make sure this is the correct version. 4. Open the same link in an anonymous browser window and compare what appears. 5. Repeat the test with a signed-in account that should have access. 6. Repeat again with a signed-in account that should be blocked. As you move through these checks, pay attention to what changes between reader types. A public version should open cleanly for anonymous visitors. A restricted version should either block access or prompt for the correct sign-in path. A link meant only for approved readers should not quietly expose the content to someone outside that group. Look closely at the visible cues on the page: - Version title or version label - Navigation menu items - Page headings - Public-facing content blocks - Any message shown when access is denied If the page opens but the content looks older than expected, compare it with the version you selected inside the project workspace. If the wrong revision appears in public view, stop before sharing the link more widely. [SCREENSHOT: Same version opened in signed-in view and anonymous browser view for comparison] ## Verifying audience targeting and reader permissions If your version is meant for a specific audience, this is the point where you confirm that Atloria is showing the right content to the right readers. Open the version’s access or audience settings and review every rule that affects who can see it. Depending on how your team works, that may include named readers, internal teams, role-based access, or audience assignments used for targeted documentation experiences. 1. Open the version’s audience or access settings. 2. Review which readers, teams, or audience groups are allowed to view it. 3. Check whether the version should appear in public listings, shared links, or version selectors for those readers. 4. Test with at least one allowed reader and one non-allowed reader. 5. Compare what each reader can open and what each reader can see inside the version. Do not stop at “can open” or “cannot open.” Also verify the viewing context. A targeted reader might be able to open the version from a direct link but not see it in a public listing, or the reverse. If the version is supposed to be discoverable through navigation or a version selector, make sure it appears there for the intended audience only. Inherited access can also affect the result. If the parent document, project, or broader workspace has more restrictive settings than the version itself, the version may stay hidden even when its own access settings look correct. If the parent level is more open than expected, readers may see content you intended to limit. When audience-specific content is part of the release, confirm that restricted sections, gated content, and any audience-specific messaging display correctly for each reader type. The version should feel consistent from the reader’s point of view, not just technically accessible. [SCREENSHOT: Audience or access settings for a version with targeted readers] ## Testing links, assets, and export readiness before sharing A version is not ready for public release if the pages open but the links, files, or exports break. In Atloria, test the version from the same public-facing or shared view your readers will use. This helps you catch problems that do not appear inside the project workspace, especially when a file, image, or linked page has different visibility from the version itself. 1. Open the version in its public or shared view. 2. Select several important internal links and confirm they open the expected page. 3. Test anchor links that jump to sections on the same page. 4. Open attachments, downloadable files, and any external links included in the content. 5. Confirm that images and embedded media load without missing-file errors. 6. Use the share action or copy-link option and open the generated link in another browser session. 7. Run an export and compare the output with the on-screen version. Focus first on high-value content: - Main navigation links - Links between related documentation pages - Downloadable attachments - Screenshots and images - Embedded media - Any public-facing call-to-action links When you test the shared link, confirm it opens the intended version directly. It should not send readers to a draft, an internal editing area, or a page that requires more access than planned. If Atloria offers export output for the version, open the exported file and compare it with the public page. Check whether headings, page order, visible content, and assets appear as expected. If something is missing from the export, compare that missing item with the live version. This usually helps you decide whether the problem is with the source content, the asset’s visibility, or the export result itself. [SCREENSHOT: Public version page with links, images, and export option being validated] ## Reviewing release signals before making the version broadly available Before you announce a version, do one final pass on the release signals readers will actually notice. In Atloria, these signals include the version status, visibility label, publication state, and how the version appears in navigation or public listings. Even if the content itself is correct, confusing labels or discoverability problems can make the release feel unfinished. 1. Return to the version details and confirm the status matches your intended release state. 2. Check the visibility label or publication indicator shown for that version. 3. Open any public listing, navigation menu, or version selector where readers may discover it. 4. Confirm the version appears only where it should be discoverable. 5. Review the version name, page description, and any last-updated information shown to readers. 6. Decide whether the version is ready for direct sharing, targeted rollout, or export distribution. This is also the time to confirm that older versions are not competing with the release you are about to share. If readers can browse multiple versions, make sure the correct one is easy to identify. A version name that looked clear internally may be confusing in a public selector if similar names are listed together. Check these release-facing details carefully: | What to review | What to confirm | |---|---| | Version status | Matches the release stage you intend to share | | Visibility label | Shows the correct public or restricted state | | Navigation presence | Appears only in the right menus or listings | | Version name | Clearly identifies the release readers should open | | Reader-facing metadata | Matches the content you are preparing to announce | If all of these signals line up with your test results, you can move forward with confidence. If not, fix the mismatch before sending links or distributing exports. ## Fixing common visibility and public-view problems When a version fails validation, the fastest fix usually comes from matching the problem to the screen where readers experience it. In Atloria, start with the exact symptom: who opened the version, what link they used, and what they saw. That makes it easier to correct the right setting instead of changing several things at once. - **The version opens for admins but not for intended readers** - Reopen the version’s access settings and confirm the intended readers, teams, or audience groups are included. - Check whether a parent document or project setting is more restrictive than the version. - Retest with the same reader account after saving any changes. - **The public link shows the wrong content or an older revision** - Confirm you copied the link from the correct version. - Recheck the version label and publication state before testing again. - Open the version from the public view and compare it with the version currently selected in the project workspace. - **Images, files, or attachments fail in public view** - Open the version as an anonymous visitor and note which assets fail. - Confirm those files are available to the same audience as the version. - Retest the page after updating the affected content or asset sharing setup. - **The export is missing content or formatting** - Compare the exported file with the public page, section by section. - Look for missing images, embeds, or attachments that may not be included the same way in export output. - If only part of the version is missing, focus on the affected page rather than rebuilding the whole release. Keep your fixes small and retest after each change. If you modify access, audience targeting, and content all at once, it becomes hard to tell which change solved the issue. ## Overview This guide focuses on the final validation pass you should complete before making a documentation version broadly available in Atloria. The goal is not to reconfigure access from scratch, but to confirm that the version already prepared for release behaves correctly for real readers. That includes public access, restricted access, audience-targeted visibility, shared links, and export output. You will work across the same reader-facing areas your audience will use: the version selector, public or shared page view, navigation menus, visible page content, and export results. The checks in this guide help you answer practical release questions such as: - Does the correct version open from the link you plan to share? - Can the intended audience see it without extra barriers? - Are blocked readers actually blocked? - Do links, images, and files work outside the editing workspace? - Does the export match what readers see online? If you still need to adjust visibility rules or sharing setup, go back to [Managing Version Access and Sharing Outcomes](doc:managing-version-access-and-sharing-outcomes) or [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export) before continuing. This guide assumes those earlier decisions are already in place and concentrates on release validation rather than setup. Use this document when you are close to publishing, sending a share link, or distributing an export to customers, partners, or internal teams. It is especially useful when a version has audience targeting, restricted sections, or a mix of public and controlled access paths. By checking the live reader experience before release, you reduce the chance of exposing the wrong revision or blocking the people who need it. ## Prerequisites Before you start this validation process in Atloria, make sure the version and its release setup are far enough along that testing will reflect the final reader experience. You do not need every detail to be perfect, but you do need the main release settings in place so your results are meaningful. Have these items ready: - A project with an existing documentation version to validate - Access to the version list, version selector, or version details screen - The intended visibility setup already chosen for the version - Any audience targeting or reader access assignments already applied - A public link, preview, or share link for the version if one is available - At least one signed-in reader account that should be allowed access - At least one signed-in reader account that should be denied access, if restricted testing is required - A private or incognito browser window for anonymous-reader testing - Any export option you plan to distribute, if export validation is part of the release It also helps if the version content is stable enough to review without major edits happening at the same time. If teammates are still changing access rules, page structure, or release status while you test, you may get inconsistent results. Before beginning, you should already be comfortable with: - Reviewing version visibility and reader access - Understanding how your team uses audience-targeted documentation - Opening public documentation views and shared links - Comparing what different reader types can see If you need help with those earlier tasks, review [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options) and [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access). After finishing this validation, continue with [Preparing Version Access Sharing and Export Outcomes](doc:preparing-version-access-sharing-and-export-outcomes). ## Finding technical documentation from project and public views In Atloria, you can browse technical documentation in two main places: inside a project workspace and in the published documentation view. The project workspace is where your team reviews draft content, generated reference pages, and technical sections that may not be public yet. The published view is the reader-facing version that shows only content included in the live documentation set. If you already know how API reference sections are organized, use [Reading API Reference Sections in Technical Documentation](doc:reading-api-reference-sections-in-technical-documentation) as a companion while you browse. Inside a project, start from the documentation area for that project and use the left navigation panel to move through the page tree. You may see section names, nested categories, and generated reference entries listed under technical documentation areas. In published documentation, the same content is usually reached from the public navigation menu, sidebar, or section landing page. As you move through Atloria, pay attention to how you entered the content. A section page usually acts like a hub. It may contain an introduction, grouped links, or a list of related reference entries. An entity reference page is more structured. It typically focuses on one item and shows organized details such as fields, parameters, or related entities. A relationship link is different again: it takes you from one reference page directly to another linked item, such as a referenced type, related endpoint, or connected schema. [SCREENSHOT: project documentation sidebar showing a technical section with nested reference entries] Project context matters because internal workspaces can include draft pages, newly generated reference entries, or links that only project members can open. In the public view, you only see pages that have been published. If a link works in the project workspace but not in public documentation, you are likely looking at content that has not been published yet. ## Browsing sections, categories, and generated reference entries When you open a technical documentation section in Atloria, begin with the left sidebar or the section index on the page. These areas help you understand the structure before you open individual entries. A section may contain child pages, grouped categories, or nested folders that separate conceptual content from generated reference content. If the section is large, scan the grouped headings first so you can jump directly to the part you need. Many teams use a mix of written guidance and generated reference pages. In practice, that means you may start on a narrative page that explains a feature, then move into a structured reference entry by clicking a linked entity name inside the content. You might also enter through a section list that displays cards, grouped page names, or an index of technical items. Common entry points into generated reference pages include: - Linked names inside a technical article - Entity cards shown in a section landing page - Type or schema names listed in structured content - Endpoint names shown in a reference index - Related item links at the bottom or side of a page As you browse, look for visual clues that tell you whether a page was written manually or generated from parsed project content. A manually authored page usually reads like a guide, with paragraphs, headings, and explanatory text. A generated reference page is more structured and often includes a title, a short description, metadata blocks, and field-style listings. The table below shows the differences you are most likely to notice while browsing: | Page type | What you usually see | Best use | |---|---|---| | Section page | Intro text, grouped links, child pages, category lists | Start exploring a topic | | Authored documentation page | Narrative explanations, task steps, examples | Learn concepts or workflows | | Generated reference page | Structured details, field lists, linked related items | Check exact reference information | [SCREENSHOT: section landing page with grouped headings and links to generated reference entries] If you are unsure where to click next, open the section page first, then follow the linked entry that matches the exact item name you want to inspect. ## Opening an entity detail page and reading its reference information When you open an entity detail page in Atloria, the layout becomes more structured than a standard documentation page. At the top, you will usually see the entity title, followed by a short summary or description. Some pages also show an identifier or page label near the title area, which helps you confirm that you opened the correct reference entry. Below the header, Atloria may show one or more structured sections. These sections are designed for quick scanning. Instead of reading the page from top to bottom like an article, start with the summary, then move to the tables or grouped reference blocks that describe the item in detail. A field or property table often includes details like these: | Column | What it tells you | |---|---| | Name | The field or item name shown on the page | | Type | What kind of value or linked reference it uses | | Required/Optional | Whether the value must be provided | | Default | The starting value, if one is shown | | Notes | Extra explanation about how the field is used | Some entity pages also include signature-style details. In Atloria, these can appear as parameter lists, return information, inherited members, or request details such as method and path information on endpoint-style pages. If you are checking how one item connects to another, these structured blocks are often more useful than the summary text. Related links are another important part of the page. Look around the main content area for linked parent items, child members, referenced schemas, or other technical concepts connected to the current page. These links help you move through the documentation without going back to the sidebar each time. [SCREENSHOT: entity detail page showing title, summary, field table, and related links] When a page includes several structured sections, read them in this order: summary first, then fields or parameters, then related links. That sequence makes it easier to understand both the item itself and how it fits into the wider reference set. ## Following relationships between entities and reference pages Relationship links are what turn technical documentation in Atloria from a collection of pages into a connected reference map. On one page, you might see a linked type in a field row. On another, you may find a related entity panel, a parent item link, or a usage section that points back to where the current item appears elsewhere. These links help you trace how documentation pieces connect. A common browsing pattern starts on a section page, moves into a generated reference entry, and then follows one of its linked relationships. For example, you might open a reference page, review a field list, and click the linked type name in one row to open the referenced entity. In another case, you may open a detailed operation page and then use a related link to jump to the broader item that contains it. To avoid losing your place, use the navigation aids already on the page: - **Breadcrumbs** help you see the path back to the section or category. - **Previous/Next links** help you move through nearby pages in sequence. - **Related content panels** help you jump sideways to connected items. - **The left sidebar** helps you return to the broader documentation tree. These tools matter most when you are several clicks deep into linked reference pages. If you open one linked item after another, check the breadcrumb trail before continuing so you know whether you are still inside the same section or have moved into a different branch. Relationship browsing can differ between project and public views. In a project workspace, Atloria may let you open draft-only or internal reference pages that are still being reviewed. In public documentation, some links may not appear, or they may stop at the last published page in the chain. That usually means one of the connected items is not part of the published set yet. [SCREENSHOT: entity page with breadcrumb trail and related content links highlighted] ## Understanding what changes between project previews and public documentation Project previews and public documentation can look similar at first, but they serve different purposes in Atloria. The project preview is for internal review. It can include draft edits, newly generated technical reference pages, and links to items that are still being prepared. Public documentation is the published experience that readers see after release, so it only includes content that has been made available publicly. When you compare the two views, start by checking the page context. In the project workspace, you are usually navigating from a project-specific sidebar, project home area, or internal documentation tree. In the public view, navigation is centered on the published documentation structure. Even when the page title matches, the available links around it may differ. You can often tell which version you are viewing by looking for page-state clues such as: | Clue | What it helps you confirm | |---|---| | Workspace navigation | You are in the internal project view | | Public documentation navigation | You are viewing the published version | | Draft or unpublished indicators | The page is not fully public yet | | Missing related links | A connected page may not be published | One of the most important checks for technical writers and documentation managers is relationship completeness. A page may look correct in the project preview because all linked entities are available internally, but the public version may show fewer links if some connected entries were not published. That can make a relationship chain feel broken to readers. Before publishing, open the same section in both contexts and compare the entity title, summary text, and related links. If a generated reference page includes structured details, confirm that those details appear consistently in the public version as well. For more on public-facing reference reading, see [Reading Published API and Technical Documentation](doc:reading-published-api-and-technical-documentation) and [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views). ## Resolving common issues when browsing reference content If reference browsing feels inconsistent in Atloria, the fastest fix is usually to confirm what view you are in and whether the linked content is available there. Most browsing issues come from differences between project-only content and published content, not from the page you are currently reading. If a linked entity page does not open, first check whether you are in a public documentation view. The target page may exist in the project workspace but not be published yet. It may also have been removed from the current project content or no longer appear in the section where you expected it. Return to the sidebar or section index and search for the same title there. If it appears internally but not publicly, the issue is likely visibility rather than navigation. If a reference page looks incomplete, compare it with the same page in the project workspace. Missing field details, relationship blocks, or structured sections can mean the generated reference content is not fully available in the version you are viewing. This is especially important after content updates or publishing changes. Use this table to troubleshoot quickly: | Problem | What to check | Likely cause | |---|---|---| | Link does not open | Current view, sidebar listing, published availability | Target page is unpublished or unavailable in this view | | Page looks incomplete | Compare project and public versions | Structured reference content is not fully visible in the published set | | Navigation feels inconsistent | Breadcrumbs, sidebar, page context | You switched between project and public views | | Related entities are missing | Related links on both pages, published coverage | Connected pages are not available in the same published set | [SCREENSHOT: comparing the same reference page in project view and public view] If related entities are missing from a page, check whether both sides of the relationship are present in the same documentation set. A reference chain only works cleanly when the connected pages are all available in the view you are using. For admin-side checks on workspace visibility and review areas, you may also find [Using the Admin Workspace](doc:using-the-admin-workspace) helpful. ## Overview This guide focuses on how to move through technical documentation in Atloria once the reference content already exists. The main skill is recognizing where you are: a section landing page, a manually written documentation page, or a generated entity reference page. Each one supports a different reading pattern. Section pages help you enter a topic, authored pages explain concepts, and entity pages give you structured details. You also learned how Atloria presents technical relationships. Instead of treating each page as isolated, use linked names, related content panels, breadcrumbs, and sidebar navigation together. That makes it easier to move from one reference entry to another without losing the section context. When you open an entity page, scan the title and summary first, then use the structured tables and related links to answer specific questions quickly. Another key point is the difference between project and public views. Internal project browsing may include draft-only pages and relationship links that are not available publicly yet. Public documentation only shows what has been published, so missing links or shorter relationship chains are often expected if connected items are still internal. If you need a refresher on reading reference sections before moving between linked pages, return to [Reading API Reference Sections in Technical Documentation](doc:reading-api-reference-sections-in-technical-documentation). If your next step is learning how to manage browsing more deliberately across these views, continue with [Managing Technical Documentation Browsing and API Reading](doc:managing-technical-documentation-browsing-and-api-reading). ## Prerequisites Before using this guide, you should already be able to open documentation in Atloria and recognize the difference between project workspaces and published documentation. You do not need advanced technical knowledge, but you should be comfortable using the left navigation, opening pages from a documentation tree, and following links inside rendered documentation pages. This guide is most useful if you already know how to read a reference section at a basic level. In particular, it helps to understand how section pages group content and how generated reference entries appear alongside authored documentation. If that part is still unfamiliar, read [Reading API Reference Sections in Technical Documentation](doc:reading-api-reference-sections-in-technical-documentation) first. You should also have access to at least one of these browsing contexts: - A project workspace with technical documentation enabled - A published documentation view that includes technical reference content - A section that contains linked reference entries or entity detail pages If you are working as a technical writer or documentation manager, it is helpful to have permission to compare project preview content with public documentation. That allows you to verify whether entity titles, summaries, and relationship links appear correctly before release. If you need help getting to the right workspace first, use [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects) or [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views). ## Comparing export options before you choose In Atloria, the right export starts with one question: **who will open this file, and why?** This guide focuses on four common decisions inside the **Export** workflow: sending content for **stakeholder review**, preparing a **public release**, creating a **compliance retention** copy, and saving an **internal archive**. These scenarios often start from the same documentation version, but they need different export settings. When you open the export dialog from a documentation version or related export workflow, pay attention to the option labels that describe the output. Review-focused options usually emphasize readability and visible feedback. Release-focused options usually emphasize clean presentation. Retention and archive options usually emphasize completeness, supporting files, and preserved details. If Atloria shows export names or labels that mention comments, notes, package contents, or version details, use those labels to tell apart a reviewer-friendly export from a release-ready or record-keeping export. Most users compare exports using four checks: | What to compare | What to look for in Atloria | Why it matters | |---|---|---| | File format | Whether the export opens easily or is packaged for delivery | Reviewers usually want convenience, while records teams may need durable formats | | Comments and annotations | Whether comments, review notes, or markup are included | Helpful for review, but usually not appropriate for public release | | Metadata preservation | Whether version details, timestamps, and approval-related information are kept | Important for retention and audit review | | Packaging structure | Whether files are bundled with assets or delivered as a simpler final copy | Affects sharing, storage, and long-term reuse | The main tradeoff is simple: the easiest export to read is not always the best export to retain. A clean file may be perfect for approval or release, but a retention copy may need more detail, more files, and more context. If you need a refresher on the export workflow itself, see [Managing Documentation Exports for Sharing and Archiving](doc:managing-documentation-exports-for-sharing-and-archiving). [SCREENSHOT: Export dialog showing format, included content, and package options] ## Choosing an export for stakeholder review When you are sending documentation out for review, choose an export that opens easily and keeps reviewer context visible. In Atloria, that usually means selecting an export option that favors readable output over strict packaging completeness. Reviewers should be able to open the file, understand the page structure, and see where feedback applies without needing to return to the authoring workspace. Use these steps when choosing a review export: 1. Open the documentation version you want to share and start the **Export** workflow. 2. Look for an export option labeled for review use, draft sharing, or one that includes comments or annotations. 3. Choose a file format that reviewers can open easily, especially if they are outside your regular Atloria workspace. 4. Turn on any option that includes **comments**, **review notes**, **annotations**, or visible markup when feedback needs to travel with the file. 5. Check whether linked images, screenshots, and other assets are included so reviewers do not see missing content. 6. Review the page layout and navigation in the preview or option summary, then create the export. For **internal editorial review**, it is often useful to include comments, tracked edits, and notes so teammates can see open questions and unfinished areas. For **external stakeholder sign-off**, you may want a cleaner draft that still includes selected annotations, especially if stakeholders need to approve wording, structure, or release scope without seeing every internal discussion. Also check how navigation appears in the exported result. If the documentation relies on section menus, linked pages, or screenshots, make sure the export preserves enough structure for reviewers to follow the content in order. A review file that loses headings, page relationships, or linked assets can slow down approval even if the text itself is correct. [SCREENSHOT: Review export settings with comments or annotations included] ## Preparing exports for public release A public-release export should start from the **final approved version**, not a working draft. In Atloria, open the approved documentation version and use the same export workflow you use for controlled distribution, but choose settings that produce a clean, customer-facing result. The goal is to remove anything that belongs only to drafting or review. Follow this release-preparation process: 1. Open the approved version in Atloria and confirm you are not exporting an in-progress draft. 2. Start the **Export** workflow from that version. 3. Select an output option intended for final delivery, release distribution, or a clean published copy. 4. Turn off any setting that includes **internal comments**, **review notes**, **annotations**, or markup layers. 5. Check the export summary for release-facing details such as the **document title**, **version label**, and visible navigation structure. 6. Confirm that branding and presentation match what you want external readers to receive. 7. Export the file or package and review the finished result before sharing it. This is the stage where you should verify what external readers will actually see. Check that draft-only material is gone, section names are correct, and the navigation reflects the published structure rather than an internal working layout. If the export includes screenshots or linked assets, make sure they appear correctly and support the final reading experience. Choose the output based on where the release is going: - **Downloadable file**: useful when customers or stakeholders need a single handoff copy. - **Website upload package**: useful when the release will be placed into a hosted documentation experience or similar delivery channel. - **Customer-facing handoff copy**: useful when you need a polished file for account teams, onboarding, or release communication. If you are still confirming whether a version is ready to export at all, review [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). [SCREENSHOT: Clean release export settings with comments and markup removed] ## Selecting exports for compliance retention and internal archiving Compliance retention and internal archiving are similar, but they are not the same. In Atloria, a **compliance retention** export should preserve enough detail to stand up to audit, legal review, or formal recordkeeping. An **internal archive** export is often more about keeping a dependable copy for future reference, handoff, or team history. Use these steps to choose between them: 1. Open the version or record set you need to preserve. 2. Start the **Export** workflow and look for options that emphasize complete package contents, version details, or preserved records. 3. For compliance needs, choose settings that keep **timestamps**, **version information**, **approval evidence**, and any attached supporting files. 4. For internal archive needs, decide whether you want the original structure with bundled assets or a simpler final-output copy. 5. Check whether the export keeps metadata and related files together in one package. 6. Create the export and store it in the location your team uses for records or archives. For compliance retention, completeness matters more than convenience. If your organization may need to prove when a version was approved, what was included, and what supporting material existed at the time, do not choose a simplified convenience copy. A retention export should preserve the surrounding details that explain the record, not just the visible page text. For internal archiving, you have more flexibility. Some teams prefer a bundled package that keeps source structure, linked assets, and related files together. Others prefer a flattened final-output copy that is easier to reopen later. The best choice depends on whether the archive is meant for future reuse or simply for historical reference. Retention requirements often drive format choice. If records must remain readable years later, favor exports that keep content self-contained and understandable without depending on separate tools, missing assets, or workspace-only context. [SCREENSHOT: Export options showing complete package and metadata-focused settings] ## Matching export settings to your role and distribution method The best export in Atloria depends on both your role and how the file will be delivered. A Documentation Manager usually focuses on reviewer readability, release polish, and clear version labeling. A Project Administrator usually focuses on retention completeness, storage consistency, and audit readiness. The same documentation version may need different exports for each person. Use this matrix to match the export to the job: | Use case | Primary audience | What must be included | Recommended export direction | |---|---|---|---| | Review round | Editors, approvers, stakeholders | Readable content, visible comments or notes when needed, working layout | Review-friendly export | | Public release | Customers, readers, external teams | Clean content, branding, version label, published navigation | Release-ready export | | Compliance retention | Audit, legal, records teams | Metadata, timestamps, approval evidence, supporting files | Complete retention export | | Internal archive | Internal teams, future project owners | Stable copy, related assets if needed, clear version reference | Archive-focused export | Match the export to the delivery method as well: - **Email attachment**: choose a format that opens easily and stays readable without extra setup. - **Shared drive**: choose a file or package with clear naming and dependable structure so others can find and reopen it later. - **Records repository**: choose the most complete export, especially when metadata and supporting files matter. - **Public delivery package**: choose a clean output with no draft material and a polished reading experience. If you are a Documentation Manager, ask: “Will the recipient review this, approve it, or read it as final?” If you are a Project Administrator, ask: “Will we need to prove what this version contained later?” Those two questions usually point you to the right export settings faster than format alone. [SCREENSHOT: Example decision matrix or export selection screen by use case] ## Avoiding common export selection mistakes Most export problems in Atloria come from choosing the right content for the wrong audience. The file may generate successfully, but the result does not match the purpose. The fastest fix is to go back to the **Export** settings and compare the included content against the audience who will receive it. Use these corrections when something looks wrong: 1. If reviewers cannot see comments, reopen the export workflow and switch from a clean release-style export to a review-focused export that includes comments, notes, or annotations. 2. If a public-release file still shows internal notes, draft watermarks, or unresolved markup, regenerate the export with draft-only content removed. 3. If a retention copy is missing metadata, attachments, or version history, choose a more complete package option and confirm that supporting files are included. 4. If an archive copy is difficult to reopen later, replace it with a self-contained export or a package that keeps related assets together. A common review mistake is sending stakeholders a polished final-style file too early. It looks professional, but it hides the very comments and review context they need. On the other hand, a common release mistake is forgetting to remove internal discussion before sharing externally. Always scan the exported result, not just the settings screen. Archive and retention mistakes are usually discovered later, when someone tries to retrieve the record. If the export depends on missing linked assets or a format your team no longer uses, the archive loses value. For long-term storage, favor exports that remain understandable on their own and keep the version relationship clear. When in doubt, create a test export and open it exactly the way your audience will. That quick check usually reveals whether you chose a review copy, a release copy, a retention package, or an archive file by mistake. ## Overview - This guide helps you choose among Atloria export options for four specific outcomes: - **Stakeholder review** - **Public release preparation** - **Compliance retention** - **Internal archiving** - The main decision points in the **Export** workflow are: - the **file format** - whether **comments**, **annotations**, or **review notes** are included - whether **metadata** and version details are preserved - whether the export is a simple file or a more complete **package** - Use review-friendly exports when people need to read and comment on draft content outside the authoring workspace. - Use release-ready exports when you need a clean, customer-facing copy without internal discussion or markup. - Use retention-focused exports when records must preserve timestamps, approval evidence, supporting files, and version context. - Use archive-focused exports when your team needs a dependable internal copy for future reference or handoff. - If you need help with the export workflow itself before choosing among options, refer to [Managing Documentation Exports for Sharing and Archiving](doc:managing-documentation-exports-for-sharing-and-archiving). ## Prerequisites - You can open the relevant project and documentation version in Atloria. - You know whether the export is for: - review - release - retention - archive - The version you plan to export has already been checked for readiness if it is being shared or released. If needed, use [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). - For public-release exports, the version should already be approved. - For retention or archive exports, you should know whether your team needs: - metadata and timestamps - approval evidence - attached supporting files - a simple final copy or a complete package - You have access to the **Export** action for the documentation version or related records. For the next step in the Export Center, continue with [Managing Export Packages for Documentation and Release Records](doc:managing-export-packages-for-documentation-and-release-records). ## Understanding Which Settings Control the Support Agent Experience In Atloria, support agent setup usually spans more than one place, so it helps to separate **how the agent answers** from **where readers see it**. Start from the support agent area you already used in [Managing Support Agent Setup and Availability](doc:managing-support-agent-setup-and-availability), then open the settings tied to the documentation experience where the agent will appear. You are looking for groups of settings related to the agent’s behavior, its visible presentation, and its availability in published or in-project documentation views. A practical way to review these settings is to think in two layers: - **Workspace-level settings** - Control the support agent itself - Usually include the agent’s instructions, response scope, and supported topics - Affect how the agent behaves wherever that agent is used - **Documentation experience settings** - Control how the agent appears to readers - Usually include placement, launcher visibility, welcome text, and page-level display choices - Affect the reader-facing experience in a specific documentation area Before changing anything, confirm whether you are editing the shared support agent or the documentation experience that displays it. If you change the shared agent instructions, readers may notice different answers everywhere that agent is active. If you change the embedded experience settings, the answers may stay the same while the launcher, panel, or welcome message changes only in that documentation view. Teams often split responsibility across roles: | Setting area | Typical owner | What they focus on | |---|---|---| | Agent instructions and response rules | Support Team Lead | Tone, scope, approved answers, escalation behavior | | Embedded presentation | Documentation Manager | Launcher text, welcome message, placement, reader experience | | Availability and rollout | Project Administrator | Where the agent appears, who can use it, staged release decisions | [SCREENSHOT: Support agent settings area showing behavior, presentation, and availability sections] ## Adjusting How the Support Agent Responds to Readers To change how the support agent answers questions, open the agent’s behavior settings and look for the instruction fields that define tone, scope, and expected response style. This is where you shape the reader experience most directly. In Atloria, these settings are best used to keep the agent focused on documentation help rather than broad or open-ended support. 1. Open the support agent you want to update. 2. Go to the behavior or instruction section. 3. Edit the text that tells the agent how to respond to readers. 4. Save your changes. 5. Preview the agent in a documentation view and test a few questions. When you update the instruction text, keep it tied to what readers should actually get from the documentation experience. For example, you may want the agent to: - answer using project documentation first - stay within approved support topics - avoid guessing when the documentation does not cover a question - direct readers to human support when the answer is unclear You should also review any settings related to unsupported questions. If Atloria shows fields or options for fallback behavior, use them to define what the reader sees when the agent cannot answer confidently. That message should match the documentation experience and clearly redirect the reader instead of leaving the conversation open-ended. Common behavior areas to review include: - **Tone and style**: formal, concise, instructional, or friendly - **Topic boundaries**: what the agent should and should not answer - **Fallback messaging**: what appears when no reliable answer is available - **Handoff behavior**: whether the agent should point readers to another support path After saving, check whether the documentation experience reflects the change immediately or only after the documentation is republished. If the updated behavior does not appear in the embedded experience, test again after publishing the latest documentation changes. ## Customizing the Embedded Agent's Presentation Once the support agent is answering correctly, move to the reader-facing presentation settings. In Atloria, this is where you control what readers see on the page: the agent name, welcome message, launcher text, and the way the support panel appears inside documentation. 1. Open the documentation experience or site settings where the support agent is embedded. 2. Find the section for support agent display or embedded support settings. 3. Update the visible labels and branding elements. 4. Choose the placement style for the agent. 5. Save and preview the documentation page. The most important presentation settings are the ones readers notice first: - **Agent name**: the label shown in the support panel - **Welcome message**: the opening text readers see before asking a question - **Launcher label**: the text on the button or chat opener - **Branding elements**: any visible avatar, icon, or theme-related styling Placement matters just as much as wording. Depending on the documentation experience, the support agent may appear as: - a **floating launcher** that follows the reader across pages - an **inline embed** placed within page content - a **page-level support panel** that stays in a fixed area of the layout You should also review how the agent opens. Some experiences work best when the panel starts minimized so it does not interrupt reading. Others benefit from an open state on support-heavy pages where readers are expected to ask questions right away. If Atloria lets you choose whether the launcher appears on all pages or only in selected sections, match that choice to the purpose of the content. [SCREENSHOT: Embedded support settings showing agent name, welcome message, launcher label, and placement options] Keep the support agent visually consistent with the rest of the documentation. If your documentation uses a specific theme or branded reader experience, confirm that the support panel feels like part of the same site rather than a separate tool. ## Controlling When and Where Readers Can Access the Agent Availability settings decide whether readers can actually use the support agent in the places you expect. In Atloria, these settings are especially important when your documentation includes different spaces, audience-specific content, or staged publishing workflows. 1. Open the documentation experience settings for the site or project area you want to control. 2. Find the availability or visibility section for the support agent. 3. Choose where the agent should appear. 4. Apply any audience or access restrictions. 5. Save the settings and test the affected pages. Start by deciding the scope of availability. You may enable the support agent for: - the full documentation site - selected spaces or sections - specific article collections only Then review who should see it. If Atloria offers audience or access-based controls, use them to limit the support experience to the right readers, such as: - signed-in users - customers - internal team members - other permitted reader groups already defined in your documentation setup Page-level visibility is useful when some content should stay distraction-free or should not invite support questions. For example, you may want to hide the agent on: - landing pages - release notes - sensitive internal sections - pages meant only for announcements or navigation Availability also needs to match your publishing workflow. If you are preparing changes in a staged documentation version, confirm whether the support agent settings apply only to the draft experience or to the currently published one as well. A saved setting may not be visible to readers until the related documentation changes are published. If your team uses separate environments for testing and live documentation, verify that you are editing the correct one before rollout. This prevents readers in the live documentation from seeing unfinished support behavior or incomplete placement changes. ## Managing Reader Interaction Settings Reader interaction settings shape how people actually use the support agent once it appears on the page. In Atloria, these choices affect whether the experience feels guided and helpful or too open-ended for the documentation you are publishing. 1. Open the embedded support settings for the documentation experience. 2. Review the conversation options available to readers. 3. Add or adjust prompts that guide the first question. 4. Check any escalation or contact options shown in the support panel. 5. Save the changes and test the conversation flow across multiple pages. A good starting point is the first interaction. If Atloria provides suggested questions or conversation starters, use them to steer readers toward supported topics. These prompts work best when they match the actual documentation, such as setup steps, feature usage, or troubleshooting topics already covered in the project. Helpful interaction settings often include: - **Starting a new conversation** directly from the current documentation page - **Suggested questions** that help readers ask about supported topics - **Prompt text** that explains what the support agent can help with - **Escalation options** that direct readers to another support path when needed You should also review any visible contact or handoff options. If the support panel includes links or actions that send readers to human support, make sure those options appear only when they fit the documentation experience. For example, a customer-facing help center may benefit from a clear support path, while an internal draft documentation space may not need that option shown at all. Finally, check how the conversation behaves as readers move through the documentation. If Atloria keeps the session visible across pages, readers can continue the same thread while browsing. If the conversation resets more often, the experience may feel cleaner but less continuous. Choose the setting that fits your documentation structure and the kind of help readers usually need. ## Testing the Configuration in Your Documentation Experience After updating behavior, presentation, and availability, test the support agent from the reader’s point of view. In Atloria, this step is where you confirm that the embedded experience matches the settings you saved and that the agent behaves correctly on real documentation pages. 1. Open the documentation experience where the support agent should appear. 2. Check the launcher, panel placement, agent name, and welcome message. 3. Ask several sample questions based on the documentation. 4. Visit pages where the agent should appear and pages where it should stay hidden. 5. Publish or refresh the documentation experience if the changes are not visible. Start with the visual checks. Confirm that the launcher label, welcome text, and placement match the settings you selected. If the support agent should appear as a floating launcher, make sure it is visible in the expected corner or page area. If it should be inline or page-level, verify that it appears in the correct section of the layout. Next, test behavior with realistic reader questions. Ask about topics clearly covered in the documentation and then try a question outside the approved scope. The agent should stay within the boundaries you set, use the expected tone, and show the fallback response when it cannot answer. Then test visibility rules: - open pages where the agent should be available - open pages where it should be hidden - switch between reader types or audience views if your team uses them - compare draft and published views when rollout is staged If changes do not appear, check these items: - the settings were saved successfully - the documentation experience was published if required - you tested the correct environment - an older cached page is not still showing the previous embedded setup [SCREENSHOT: Published documentation page with embedded support agent visible and ready for testing] ## Overview - This guide focuses on the reader-facing side of support agents in Atloria: how the agent answers, how it looks, where it appears, and how readers interact with it inside documentation. - Use this document after the setup work covered in [Managing Support Agent Setup and Availability](doc:managing-support-agent-setup-and-availability). That earlier guide covers the broader setup path; this one focuses on fine-tuning the embedded experience. - The main settings to review are: - **Behavior settings** for tone, scope, fallback responses, and handoff rules - **Presentation settings** for the agent name, welcome text, launcher label, and placement - **Availability settings** for site, section, page, and audience visibility - **Interaction settings** for suggested prompts, conversation flow, and escalation options - In most teams, different people own different parts of this work: - Support Team Leads refine how the agent responds - Documentation Managers shape the embedded experience readers see - Project Administrators control rollout, visibility, and access conditions - Test every change in the actual documentation experience before considering the update complete. A saved setting does not always mean readers can already see it in the published view. ## Prerequisites - You should already have a support agent created and connected to the correct documentation source. If not, start with [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) and [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup). - You should already understand the basic setup and availability workflow covered in [Managing Support Agent Setup and Availability](doc:managing-support-agent-setup-and-availability). - Make sure you can access: - the support agent settings - the documentation experience or site settings where the agent is embedded - the relevant project or published documentation view for testing - Before editing behavior settings, prepare the decisions your team has already made about: - approved support topics - tone of voice - fallback messaging - when readers should be directed to human support - Before editing presentation or visibility settings, confirm: - which documentation sections should show the agent - which audiences should see it - whether your team is updating a draft experience or a published one If you are continuing the support agent documentation set, the next useful companion guide is [Chatting with Support Agents and Managing Conversations](doc:chatting-with-support-agents-and-managing-conversations). ## Opening a comparison between document versions In Atloria, start from the document you want to review rather than from the broader project list. Open the page from your content library, project documentation area, or the editor where you were already working on updates. If you need help getting back to a page and its editing workspace, use [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) and [Collaborating on Document Changes and Page Quality](doc:collaborating-on-document-changes-and-page-quality) as references. 1. Open the document page you want to check. 2. Look for the **Version history** area or the review toolbar that lets you work with saved document states. 3. Choose the two versions you want to compare. A common choice is the **current draft** and the **last published** version, but you can also compare a reviewed version against an approved version if that matches your workflow. 4. Click **Compare** to open the comparison view. 5. Before you begin reading changes, confirm which version is shown as the original and which version is shown as the updated revision. That last check matters more than it seems. If you reverse the selection, the same edits can look misleading because additions and removals will appear to be swapped. When you are preparing a release update, the safest baseline is usually the currently published page. When you are checking whether review feedback was applied, the baseline is often the earlier reviewed draft. [SCREENSHOT: Version history panel with two document versions selected and the Compare action highlighted] If Atloria shows labels for document status, use those labels to pick the right pair. Comparing **Draft** to **Published** helps you see reader-facing changes. Comparing **Reviewed** to **Approved** helps you focus on final editorial adjustments. Choose the pair that matches the decision you need to make. ## Reading additions, deletions, and modified content in the comparison view Once the comparison view opens, read it as a map of what changed between two saved document states. Atloria highlights inserted text, removed text, and rewritten content so you can quickly spot where the page changed without rereading every line from top to bottom. 1. Start by scanning the page for visual change markers that show edited areas. 2. Open each changed section and review the highlighted wording. 3. Switch between **side-by-side** and **inline** layouts if one view makes the edits easier to understand. 4. Check section headings and content blocks one by one so you do not miss small but important updates. 5. Review any separate metadata changes, such as a changed title or status, apart from the body text. The **side-by-side** layout is useful when you want to compare full paragraphs, headings, or ordered steps in their original and updated form. The **inline** layout is better when you want to read the page as one continuous flow and see exactly where words were inserted or removed. Pay attention to section-level indicators. These help you find which heading, paragraph, or content block contains edits before you read the details. On a long page, this saves time because you can jump directly to changed areas instead of manually checking every section. If the page title, publishing status, or other document details changed, Atloria may show those changes separately from the main body content. Treat those as part of the review. A page can look correct in the body while still carrying the wrong title or status. [SCREENSHOT: Comparison view showing highlighted additions, deletions, and a layout toggle between side-by-side and inline] When a paragraph appears heavily changed, slow down and compare meaning, not just wording. A small phrase change in a procedure step or warning note can affect how readers follow the page. ## Reviewing changes before editing or approving updates The comparison view is especially useful before you reopen a page in edit mode or mark work as ready for review. Instead of guessing whether a requested change was applied, you can verify it directly against the earlier version and confirm that the page still reads consistently from start to finish. 1. Open the comparison for the draft you plan to review. 2. Move through changed sections in order, starting at the top of the page. 3. Check that requested wording updates, terminology fixes, and link changes appear where expected. 4. Confirm that formatting still supports the content clearly, especially in headings, lists, and step-by-step instructions. 5. If your team uses review notes, comments, or approval steps, record your decision before leaving the comparison view. This step is helpful after a teammate updates a page based on feedback. Compare the current draft against the earlier reviewed or approved state and verify that each requested edit is visible in the changed sections. If a heading was renamed, make sure the wording also matches the body text below it. If a procedure was rewritten, check that the numbered steps still follow the same task flow and that no step was accidentally dropped. Use comparisons to support editorial review, not just final approval. For example, if a page was updated to align with a new product release, compare the draft against the approved or published version and read only the changed sections first. That keeps your review focused and reduces the chance of overlooking a meaningful update hidden inside a long page. If your workflow includes sign-off, add comments or review notes directly where your team expects them. Keep those notes tied to specific changes, such as a revised heading, a corrected instruction, or a screenshot update, so the next reviewer can act on them quickly. ## Using comparisons to prepare releases and publication updates When a document is close to publication, comparisons help you answer one practical question: what will readers actually see change when this version goes live? In Atloria, this is easiest when you compare the release candidate against the currently published page. 1. Open the version you plan to publish. 2. Compare it against the current **Published** version. 3. Review all changed sections with extra attention on headings, procedures, screenshots, and reader-facing labels. 4. Use the results to support release notes, stakeholder review, or final publication approval. 5. Confirm that the comparison contains only intended changes before moving the version to a released or published state. This review is most valuable for high-impact edits. Rewritten procedures can change how customers complete tasks. Updated screenshots can affect whether instructions still match the screen. Changed headings can alter navigation and make familiar pages harder to find. By comparing the release candidate to the live version, you isolate exactly what is new. [SCREENSHOT: Document comparison between a publish-ready version and the currently published version] A comparison can also support conversations outside the editor. If stakeholders want to know what changed since the last release, the comparison view gives you a focused list of edits without requiring a full page walkthrough. It is also useful when preparing release notes because you can quickly identify renamed sections, added steps, and removed guidance. Before you publish, make one final pass for accidental edits. These often include wording changes in unrelated sections, heading adjustments that were never intended for release, or screenshot replacements that belong to a later update. If the comparison shows more than the planned release scope, return to the draft, clean it up, and compare again. ## Getting reliable results from document comparisons A useful comparison starts with choosing the right versions. In Atloria, the clearest results come from comparing document states that represent real workflow milestones rather than random saved drafts. That makes the difference view easier to read and easier for reviewers to discuss. - Compare versions with clear status meaning, such as **Draft**, **Reviewed**, **Approved**, and **Published**. - Use the same baseline version across reviewers so everyone is discussing the same set of changes. - Review long documents section by section instead of trying to judge the whole page in one pass. - Separate formatting-only edits from content edits when both appear in the same comparison. - Re-run the comparison after major revisions so your review always reflects the latest saved state. If a page is large, do not try to absorb every change at once. Start with top-level headings, then move through each changed section in order. This is especially helpful for procedure pages, release notes, and long onboarding guides where a small wording change can affect several later steps. Formatting changes can also make a comparison feel busier than it really is. If Atloria highlights both wording and layout updates, first confirm whether the content meaning changed. Then review formatting changes on their own. This keeps cosmetic edits from distracting you during quality checks. A shared baseline is important when several people are reviewing the same page. If one reviewer compares the current draft to the published page and another compares it to an older reviewed draft, they may report different findings even though they are looking at the same document. Agree on the baseline first, then compare. For broader version planning and release-stage comparison work, [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) and [Working with Version Comparison Views](doc:working-with-version-comparison-views) provide the larger workflow around document-level checks. ## Fixing common problems when differences are hard to review When a comparison feels confusing, the issue is usually the version pair, the layout, or the saved state of the draft. In Atloria, you can usually fix the problem without leaving the document workflow. - If too many changes appear, return to **Version history** and confirm you selected the correct two versions. - If the page looks noisy because of formatting updates, switch between **inline** and **side-by-side** views. - If expected edits do not appear, make sure the latest draft was saved before you opened the comparison. - If reviewers disagree about what changed, have everyone compare the same baseline and updated version. - If a long page is difficult to read, review one changed heading or section at a time instead of scrolling through the entire comparison. A common mistake is comparing the current draft to the wrong earlier draft instead of the last approved or published version. That can make the page look far more changed than it really is. Go back to the version list, check the status labels, and choose the pair that matches your review goal. Another issue is formatting noise. A rewritten list, adjusted spacing, or heading restructure can make the comparison look dramatic even when the actual instructions barely changed. In that case, switch layouts and reread the affected section for meaning rather than visual density. If a teammate says a change is missing, confirm that the draft was saved into version history before the comparison was opened. Unsaved edits or edits made in a different draft state will not appear in the difference view you are reviewing. [SCREENSHOT: Comparison screen with layout toggle and version selectors visible for troubleshooting] When confusion continues, restart the comparison from the same two named versions for everyone involved. That shared reset usually clears up disagreements quickly. ## Overview Document comparisons in Atloria help you review what changed between two saved states of the same page. Instead of scanning an entire document manually, you can open a comparison and focus only on the sections that were added, removed, or revised. This is useful during routine editing, editorial review, release preparation, and final publication checks. You will typically use comparisons in a few common situations: - Checking a **Draft** against the last **Published** version to see what readers will notice. - Reviewing a revised draft against an earlier reviewed state to confirm feedback was applied. - Comparing a release-ready page to the current live page before publishing. - Verifying that only intended changes are included in a final approval pass. Atloria’s comparison view supports this work by showing changed sections visually and letting you review updates in either **side-by-side** or **inline** format. That makes it easier to spot rewritten procedures, renamed headings, removed instructions, and updated screenshots without losing track of the original wording. This guide focuses on document-level comparisons during content updates. It does not repeat the full editing workflow or team review process already covered in [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages), [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content), and [Collaborating on Document Changes and Page Quality](doc:collaborating-on-document-changes-and-page-quality). Here, the goal is narrower: helping you use comparison views to make better editing and release decisions. If you regularly update customer-facing documentation, comparisons become one of the fastest ways to catch unintended edits before they reach readers. They also give reviewers a shared view of what changed, which makes approval discussions much more precise. ## Prerequisites Before you start comparing document versions in Atloria, make sure you have access to the page and that the document already has at least two saved states worth comparing. Comparisons are most useful when the page has moved through clear workflow points, such as draft, reviewed, approved, or published. - You can open the relevant project and navigate to the document you want to review. - The document has more than one saved version or status state in **Version history**. - You know which comparison you need, such as **current draft vs published** or **reviewed vs approved**. - The latest edits have been saved before you launch the comparison. - If your team uses review or approval steps, you know whether you are checking changes for editing, review, or publication readiness. It also helps to be familiar with the document itself before opening the comparison. If you already know the page structure, section headings, and recent requested edits, you can review differences much faster and tell whether a change is meaningful or just cosmetic. For team-based review, agree in advance on the baseline version everyone should use. That avoids situations where one reviewer is comparing against the live page while another is comparing against an older draft. Shared version selection leads to clearer comments and faster decisions. If you need to brush up on how pages are edited and reviewed before using comparisons, revisit [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) and [Collaborating on Document Changes and Page Quality](doc:collaborating-on-document-changes-and-page-quality). After you finish working through document comparisons, continue with [Understanding Document Preview and Public Page Checks](doc:understanding-document-preview-and-public-page-checks) to validate how the updated page looks before publication. ## Opening the right document view before you review output When you review a page in **Atloria**, start by opening the output view that matches the decision you need to make. If you are checking how the page reads inside your working session, use **Preview**. This is the best place to confirm rendered headings, paragraph flow, lists, tables, screenshots, and linked content without leaving your editing workspace. If you need to see what readers will get outside the editor, use **View as Published** or **Open Public Page** when those actions are available from the document screen. Choose the view carefully because each one answers a different question: - **Preview** helps you review the current page rendering while you are still working. - **View as Published** helps you check the page in its published presentation rather than the editing context. - **Open Public Page** helps you confirm what a public visitor will actually see. Before you trust what is on screen, confirm the page is in the right state for review. Look for signs that you are still viewing draft work, unpublished edits, or older page details. If you recently changed the title, page description, slug, audience settings, or navigation placement, make sure those updates are reflected in the view you opened. A preview may show current edits, while a public page may still show the last released version. It is also important to confirm you are checking the correct **version**, **locale**, or other page variant if your project uses them. A page can look correct in one release and still be wrong in another. Open the document from the intended project workspace, verify the selected version, and only then begin your page check. [SCREENSHOT: Document page with Preview, View as Published, and Open Public Page actions highlighted] ## Reviewing how the document page is presented Once the rendered page is open, review it as a reader would. Start at the top of the page and confirm the **page title** and the main visible heading match the document you intended to publish. If the page shows a short description or other visible page details, check that they are current and written for readers rather than for internal review. Then scan the body content for presentation issues. In Atloria, the previewed page should make the structure obvious at a glance. Look for: - **Heading hierarchy** that moves in a clear order - **Paragraph spacing** that makes sections easy to read - **Bullet lists** and **tables** that align properly - **Callouts** that stand out without breaking the page flow - **Code blocks** or technical examples that remain readable in the rendered view Do not rely only on the editor appearance. A section that looks fine while editing can still render awkwardly in preview, especially around long tables, nested lists, or wide content blocks. Next, check every embedded asset that appears on the page. Images should load fully, stay aligned with the surrounding text, and display any captions exactly where expected. If the page includes attachments or linked media, open them from the rendered page instead of assuming they work because they were inserted successfully. If your team also shares printable or exported output, compare that output with the in-app preview. A page can look correct in the browser and still break in print or PDF-style output because of page width, spacing, or image scaling. Focus on visible differences that affect readability, not minor cosmetic changes. [SCREENSHOT: Rendered document preview showing title, headings, image placement, and table formatting] ## Checking navigation context around the document A page is not ready just because its content looks good on its own. In Atloria, you also need to confirm the page appears in the right place within the surrounding documentation. Open the rendered page and check the navigation elements around it, starting with any **breadcrumb trail**, **section label**, or visible parent page reference. These cues tell readers where they are, and they quickly reveal whether the page has been placed in the wrong section. Pay close attention to the page’s position in the sidebar or section navigation. The current page should be highlighted in the expected area, and nearby pages should make sense in that sequence. If the page belongs under a parent topic, the preview should reflect that relationship clearly. If the breadcrumb or sidebar points to the wrong section, the issue is usually with page placement rather than page content. From the rendered page, test the navigation elements readers are likely to use: - **Table of contents** links - **Anchor links** within the page - **Previous** and **Next** links - **Sidebar** navigation states - Links to related pages or category pages Follow each one from the previewed or public-facing page, not from the editor. This helps you confirm that cross-references resolve to the intended destination and that the reader journey makes sense. If your preview exposes broader discovery surfaces, also check whether the page can be found from those entry points. That may include a section landing page, topic index, or search result snippet. You do not need to repeat the comparison workflow covered in [Managing Document Comparisons During Content Updates](doc:managing-document-comparisons-during-content-updates), but you should confirm that the final page sits correctly inside the documentation structure readers will browse. [SCREENSHOT: Public or preview page showing breadcrumb, sidebar highlight, and table of contents links] ## Validating what public visitors will actually see After checking the internal preview, open the page’s public-facing version and compare it with what you just reviewed. In Atloria, this is the most important readiness check before release because the public page may differ from the internal preview. Use **Open Public Page** or **View as Published** from the document screen when available, then inspect the page without relying on editor cues. Look for differences caused by publication state or visibility rules. A preview may include working details that should never appear to readers. On the public page, confirm that items such as these are not visible: - **Draft** markers - Internal notes or review-only text - Editing controls - Unpublished navigation items - Any workspace-only context that belongs to writers, not readers Next, review the public page details that affect release quality. Confirm the page is using the correct **slug** or public path, and check that the visible page description and title are the ones you intend to share. If Atloria shows any status label or environment banner, decide whether it is expected for your current review setting or whether it signals that you are not looking at the final public experience. It is also worth checking the page as a visitor rather than as an editor whenever possible. If you stay inside an authenticated session, Atloria may show navigation or access that a public reader would not have. Open the public page in a clean browser session or another window where editor context does not affect the result. The page should load correctly, display its assets, and allow normal reading without depending on workspace navigation. [SCREENSHOT: Public page view compared with internal preview, showing reader-facing content only] ## Comparing preview output with release expectations A reliable release check in Atloria compares the same page across all views you use before publication. Instead of reviewing each view in isolation, keep a simple comparison list and use it every time you verify a document revision. This helps writers and documentation managers agree on what must match before a page is considered ready. Your comparison should include the three most common outputs: - **Internal preview** - **Published-style view** - **Public page** For each of those views, confirm the same core elements: - **Title** - Main **headings** - **Body content** order and formatting - **Links** and cross-references - **Images** and other media - **Navigation placement** - Visible **page description** or related metadata When you compare views, treat some differences as acceptable and others as release blockers. For example, it is normal for the internal preview to include editor context that the public page does not show. A staging banner or temporary review label may also be acceptable during internal checks. What should not differ is the reader-facing content itself. If the public page shows an older title, missing image, wrong navigation placement, or broken internal link, the page is not ready. Define sign-off around visible outcomes, not assumptions. A writer can usually sign off on page presentation, while a documentation manager may also confirm navigation context and public readiness. Keep the sign-off focused on what readers will experience: - The page looks correct - The page appears in the right section - The public view matches release expectations - No internal-only content is exposed This kind of comparison makes final review faster and reduces last-minute publishing surprises. ## Fixing common issues found during preview and public page checks When preview and public output do not match, start with the most visible causes. In Atloria, the first thing to verify is the page’s **publication state**. You may be looking at current draft edits in **Preview** while the public page still shows the last released version. Also confirm that you opened the correct **version** and any intended locale or page variant. If the content still looks outdated, refresh the page and reopen the public view to rule out a stale browser view. If the page appears in the wrong section, focus on its placement in the documentation structure. Check the page’s **parent page**, section assignment, and sidebar placement from the document organization controls. A wrong breadcrumb, missing sidebar highlight, or incorrect previous/next sequence usually points to a structure issue rather than a formatting issue. Formatting problems are easiest to catch in rendered output. If a table breaks, a list nests incorrectly, or an image pushes the layout out of place, return to the page content and inspect the affected block closely. Common trouble spots include: - Very wide tables - Oversized images - Mixed formatting pasted from another source - Content blocks that render differently in preview and published views For public pages that are missing content or fail to load correctly, check whether the page is actually available to public readers. A page may still be hidden because of visibility settings, or it may link to assets and related pages that have not been made available yet. If images, attachments, or linked pages are incomplete on the public side, review each one from the public page itself rather than from the editor. When you fix an issue, repeat the same check in **Preview**, **View as Published**, and the **Public Page** so you know the correction is visible everywhere it needs to be. ## Overview This guide focuses on the final visual and navigational checks you should make before releasing a documentation page in **Atloria**. The goal is not to rewrite content or repeat editing tasks. Instead, you use the rendered page views to confirm that readers will see the right title, formatting, navigation context, and public-facing details. The review in this guide centers on four practical checks: - Opening the correct output view for the page you are reviewing - Confirming the page presentation in rendered form - Verifying the page sits in the correct navigation context - Checking the actual public-facing result before release These checks matter because a page can be correct in the editor and still be wrong in the published experience. For example, the content may render differently, the page may appear under the wrong section, or the public page may still show an older version. Atloria gives you separate views such as **Preview** and **Open Public Page** so you can catch those differences before readers do. This guide also helps you separate expected differences from real problems. Internal preview views may include editor context, while public pages should show only reader-facing content. Knowing which differences are normal makes it easier to decide whether a page is ready. If you need help reviewing changes between document revisions before doing these final checks, use [Managing Document Comparisons During Content Updates](doc:managing-document-comparisons-during-content-updates). That comparison work comes before the preview and public validation covered here. ## Prerequisites Before you start these checks in **Atloria**, make sure you already have a page that is far enough along to review in rendered form. This guide assumes you are no longer drafting basic content and are instead verifying how the page appears to readers. You should already have: - Access to the relevant **project workspace** - A document page that has been created and edited - Content saved in the page you want to review - Permission to open preview and published-style views for that page It also helps if the page already has its key publishing details in place, such as its title, location in the documentation structure, and any linked images or related pages. Without those pieces, the preview check will be incomplete because you will not be able to judge navigation placement or public readiness accurately. For the smoothest review, be ready to access more than one view of the same page: - The in-workspace **Preview** - A published-style view such as **View as Published** - The **Public Page**, if the page is already exposed for reader access If your team works with multiple versions or localized content, confirm in advance which version or locale you are supposed to review. Many preview issues are simply the result of checking the wrong output. You will get the most value from this guide if you have already completed the earlier authoring tasks in [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) and [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content). After you finish the checks in this guide, continue with [Managing Document Previews Comparisons and Quality Checks](doc:managing-document-previews-comparisons-and-quality-checks). ## Confirming what audit records capture before you review a release Before you decide whether a document version is ready to publish or share outside your team, open the audit history view that tracks activity for the item you are reviewing. In Atloria, use the audit history associated with the project, document, version, or release-related record you are checking. If you already use exports for formal review, the process in [Reviewing Audit History and Exporting Compliance Records](doc:reviewing-audit-history-and-exporting-compliance-records) covers how to package those records afterward. Here, the focus is on reading the history first so you can confirm the release steps actually happened. When you scan the audit history, look for entries that match the release workflow you expect to see. The most useful record types are: - documentation edits, such as page title changes, body updates, metadata changes, or attachment updates - review actions, including review requests, comments tied to a decision, and approval or rejection actions - permission or visibility changes that affect who can access the content - release-related status changes, such as moving a version into a ready, approved, published, or shared state The audit trail is most useful when you pay attention to a small set of fields on every entry: | Field | What to confirm | |---|---| | Actor | Which person performed the action | | Action | What changed or what decision was recorded | | Timestamp | When the action happened | | Target item | Which document, version, or release item was affected | | Before/after values | What the previous value was and what it became | Read the entries in time order. That sequence is what lets you verify that editing happened before review, review happened before approval, and approval happened before publishing or external sharing. If those events appear out of order, stop and investigate before treating the release as complete. [SCREENSHOT: Audit history list showing actor, action, timestamp, target item, and changed values] ## Checking that documentation changes were completed and attributed correctly To confirm that the content itself is ready, start with the audit log for the exact page, document, or version being released. You are not just looking for “something changed.” You are checking that the final tracked edits match the release you intend to approve. 1. Open the project or document area in Atloria and go to the item being reviewed. 2. Open its audit history or activity record view. 3. Narrow the list so it shows content-edit activity only, such as title updates, body changes, metadata edits, or attachment-related changes. 4. Review the most recent entries first, then move backward if you need context. As you inspect each entry, compare the before and after values. This is the quickest way to confirm whether the final revision contains the expected wording, document title, metadata update, or file change. If the release depends on a specific correction, the audit entry should clearly show that the earlier value was replaced by the final one. Also verify who made the change. The user name on the entry should match the person responsible for the update, and the timestamp should fit the expected release timeline. If several people edited the same item, the sequence helps you separate routine draft work from the final pre-release update. For example, earlier entries may show ongoing drafting, while the last content-edit entry before review may show the exact change requested during release preparation. Pay close attention when content appears to have been edited after approval. If you see a later body, title, or metadata change after the approval entry, the release may need another review cycle. The safest pattern is a clear sequence: final content edit, then review activity, then approval or release action. [SCREENSHOT: Filtered audit history showing only content edits for a documentation page] ## Verifying that review and approval actions happened in the right order After confirming the content changes, move to the review and approval entries for the same document or version. This is where you verify that Atloria shows a complete decision trail rather than an informal handoff in comments or chat. 1. In the audit history, find entries related to review requests, approval decisions, sign-off actions, and status changes. 2. Group those entries around the same target item so you are not mixing actions from another document or version. 3. Read them in chronological order from the last content edit forward. 4. Confirm that the workflow sequence matches your team’s release process. In most release checks, the expected order is straightforward: 1. content is edited and saved 2. review is requested or a reviewer action is recorded 3. approval or release authorization is recorded 4. publishing or sharing happens afterward If the audit history shows repeated approvals, reversals, or changed decisions, do not rely on the first approval you see. Keep reading the later entries on the same item. A later rejection, withdrawn approval, or replacement sign-off changes the release picture. What matters is the latest valid decision before the publish or share action. You should also confirm that the approving person is the right one. The actor listed on the approval entry should match the expected reviewer, owner, or administrator for that release. If a different user approved the item, check nearby entries for clues such as reassignment, delegated activity, or an administrative action that explains the change. This step is especially important when several versions are active at once. Always verify the target item on the audit entry so you know the approval belongs to the exact version or release item you plan to publish. [SCREENSHOT: Audit history showing review request, approval, and status change entries in sequence] ## Using audit history to confirm release readiness before publishing or sharing Once edits and approvals are confirmed, use the audit trail to check the release event itself. In Atloria, this means reviewing the entries that show a document version moving into a release-ready or externally visible state. You are looking for proof that the right item was published or shared only after sign-off was complete. 1. Open the audit history for the version, release item, or document being prepared for publishing. 2. Find status changes related to readiness, approval, publishing, sharing, or visibility. 3. Check for any permission or audience-related changes that affect who can see the content. 4. Compare the timestamps of the final approval and the publish or share event. The key question is timing. The publish or external share event should appear after the final approval entry, not before it. If the timestamps are close together, compare them carefully and make sure you are reading the same item throughout. The target item field matters here because teams often work with multiple versions, and a valid approval on one version does not automatically confirm another. Also review visibility-related changes before external sharing. If the audit history shows that access, permissions, or sharing settings changed, make sure those changes happened intentionally and at the correct point in the release flow. A version can be approved but still not be ready for outside readers if the wrong visibility change was applied. Use the action details to verify exactly what was released. The audit entry should point to the correct document version or release artifact, not just the project in general. If the history shows the right approval but the wrong target item was published, treat that as a release issue and pause external sharing until it is corrected. [SCREENSHOT: Audit history comparing final approval time with publish or share event time] ## Collecting audit evidence for compliance reviews and stakeholder sign-off When a manager, compliance reviewer, or release owner asks for proof, do not export the entire audit history without sorting it first. Build a focused evidence set that shows the release path clearly from final content completion through approval and release. That makes sign-off faster and reduces back-and-forth questions. Start by selecting the exact entries that prove each required checkpoint was met: - the final content-edit entry showing the release-ready revision - the review request or review completion entry - the approval or sign-off entry - the publish, share, or visibility-change entry tied to the release For each selected entry, capture the fields that make the event understandable on its own: | Evidence field | Why it matters | |---|---| | Action name | Shows what happened | | User | Identifies who performed the step | | Timestamp | Confirms when it happened | | Affected object | Confirms which document, version, or release item was involved | | Changed values | Shows the exact status or content change | Arrange those records in the same order as your release checklist. For example, if your checklist requires final edit, review, approval, and publish, present the audit evidence in that same sequence. This makes it easy for stakeholders to compare the checklist against the audit trail without re-sorting entries themselves. If something is missing, call it out directly. A clean evidence pack is not just a list of successful events. It should also note gaps, such as a missing approval entry or a publish event that appears earlier than sign-off. If you need a broader export after this review, return to [Managing Audit Exports and Activity Records](doc:managing-audit-exports-and-activity-records) for the export-focused workflow. [SCREENSHOT: Selected audit entries organized in release-check order for stakeholder review] ## Resolving missing or inconsistent audit trails before release If the audit history does not line up cleanly, pause the release and work through the mismatch before publishing. Most issues come from filters, date ranges, item selection, or reading the wrong record rather than from a true loss of activity history. 1. If no approval event appears, first check the filters applied to the audit history. 2. Expand the date range so older review activity is included. 3. Confirm you are viewing the correct document, version, or linked release item. 4. Look for approval-related activity on a parent item if the release draws from a higher-level record. A missing approval entry often turns out to be a visibility issue in the audit list rather than a missing action. Review the target item carefully and make sure you are not looking only at content edits. If the publish timestamp appears earlier than review completion, compare the raw event times carefully before escalating. A timezone difference or a narrow date display can make two nearby events look out of order. Check the exact timestamps on both entries before deciding the release sequence is invalid. If an unexpected user appears in the audit trail, inspect the surrounding entries. Adjacent events may show delegated access, an administrative override, or another action that explains why a different person completed the step. If there is no nearby explanation, treat it as a release exception and ask for clarification before proceeding. When required content changes are missing from the history, confirm that the edits were saved to the tracked document version that is actually in scope for release. Teams sometimes update a draft or another version and assume those changes belong to the release candidate. The audit target item and changed values will help you spot that mismatch quickly. The next step in this workflow is [Reviewing Project Audit History and Export Readiness](doc:reviewing-project-audit-history-and-export-readiness), where you expand these checks from a single release decision to the broader project-level audit picture. ## Overview Use this guide when you need to decide whether a document version is truly ready for approval, publishing, or external sharing based on its recorded history in Atloria. The goal is not to teach basic audit exports again. Instead, this guide shows how to read audit records as release evidence: who changed the content, who reviewed it, who approved it, and whether the final publish or share action happened in the correct order. This workflow is most useful for documentation managers, project administrators, and reviewers who need to validate release controls before content leaves the team workspace. You will work mainly with the audit history tied to a document, version, or release-related item and focus on a small set of details that matter for release checks: actor, action, timestamp, target item, and changed values. You should use this guide when: - a version is about to be published - content will be shared externally - a stakeholder asks for proof of review and approval - you need to confirm that the final released item matches the approved one - the release timeline looks unclear and you need to verify the event order This guide builds on the export and audit review workflows you have already used. If you need help gathering or exporting audit records first, see [Exporting Audit and Version Records](doc:exporting-audit-and-version-records) and [Reviewing Audit History and Exporting Compliance Records](doc:reviewing-audit-history-and-exporting-compliance-records). Here, the focus stays on the release decision itself: reading the audit trail to confirm that the required checks happened before publishing or sharing. ## Prerequisites Before you use audit records for release and approval checks in Atloria, make sure you can access the workspace area where the document, version, or release item is managed and that you can open its audit history or activity records. You do not need every administrative screen, but you do need enough access to view the item being released and the related audit entries. Have these items ready before you begin: - the specific project, document, or version you are reviewing - the expected release path, such as final edit, review, approval, and publish or share - the name of the reviewer, approver, owner, or administrator expected to appear in the audit trail - the approximate timeframe when the final edits and approval happened - access to any release checklist your team uses for sign-off It also helps if you already know how your team handles version review and visibility decisions in Atloria. If you need a refresher on release states, approvals, or sharing controls, these guides are the best starting points: - [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) - [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review) - [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options) - [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness) If you are missing any of the expected names, dates, or release items, gather those first. Audit review is much faster when you know exactly which document version you are validating and which approval event should appear in the history. ## Identifying the activity signals that matter before a release Before you start a release review in Atloria, focus on the signals that tell you which pages may need attention. The most useful signals are the ones you can see directly in the project workspace: recently updated pages, pages with open review comments, topics that have not been updated in a long time, pages with broken or outdated links, and pages that show low recent views even though they belong to an important release area. These signals help you spot risk before the version moves into review or publishing. Documentation Managers and Technical Writers usually read these signals together rather than one at a time. A page with a recent edit is not automatically a problem, but a page with a recent edit plus unresolved comments is a stronger sign that the content may not be ready. In the same way, a stale topic is not always wrong, but if it sits in an area that changed for the upcoming release, it deserves a closer look. Atloria’s analytics views, page status labels, and activity feed give you this context in one place. Use these signals at three release checkpoints: - **Internal version review**: check whether pages are still changing, waiting for review, or carrying unresolved comments - **Publishing approval**: confirm that pages expected to ship are in the right status and do not show obvious warning signs - **Audience-facing release**: verify that the most visible pages are accurate and aligned with the version being released Treat activity signals as prioritization tools, not as a replacement for page-by-page review. Analytics can tell you where to look first, but they do not decide whether the wording, screenshots, structure, or version details are correct. If you need a refresher on reading project metrics before this step, use [Reading Project Analytics for Documentation Decisions](doc:reading-project-analytics-for-documentation-decisions). [SCREENSHOT: project analytics area showing page status labels, recent activity, and content signals before release] ## Reviewing project dashboards and activity feeds In Atloria, start from the project workspace and open the dashboard or analytics area for the release you are preparing. Look for panels that show recently updated pages, pages with open review comments, and any content tied to an upcoming release window. These areas help you narrow your attention to the topics most likely to affect release readiness. 1. Open the project workspace for the release you are planning. 2. Go to the dashboard or analytics view that shows project activity. 3. Review the panels for recently updated pages and note any topics changed close to the release date. 4. Open the activity feed and check who made the change, when it happened, and whether it happened after the last review cycle. 5. Apply available filters such as version, collection, or content owner so you are only looking at pages included in the upcoming release. 6. Compare page status labels across the filtered list to find pages still marked **Draft**, **In Review**, **Approved**, or **Published**. The activity feed is especially useful when a page looks ready at first glance but may have changed after approval. If a topic is marked **Approved** but the feed shows a late edit, that page should go back into your release discussion. If a page is still marked **Draft** while related pages are already **Approved**, that mismatch can delay the release even if the content itself looks complete. When you filter by version or collection, keep your release scope tight. This prevents older pages or unrelated work from crowding the list. Filtering by content owner is also helpful when you need to see which writer or reviewer still has open work. [SCREENSHOT: project dashboard filtered by version with recent updates, open comments, and page statuses visible] ## Using analytics to decide which content needs attention Once you have the right release scope on screen, use Atloria’s analytics to decide which pages deserve immediate review. Start with page-view trends. High-traffic pages usually need extra validation because any mistake will affect more readers after release. Low-traffic pages still matter, especially if they cover setup, permissions, or advanced tasks, but they may not need the same level of urgent review unless another signal points to risk. Search behavior can reveal gaps that page views alone do not show. If Atloria shows failed search terms or weak engagement on a page, that may mean readers are not finding the answer they expect. For release planning, this is a strong reason to inspect the page title, headings, version details, and links to related content. A page that readers search for often but do not engage with may need a clearer update before publishing. Also check for outdated content signals: - Old **Last updated** timing on a page in an area that changed for this release - Missing or inconsistent version labeling - Pages that have not changed even though the surrounding feature area has changed - Topics with recent edits but no matching review progress The most important pages are usually the ones where signals overlap. For example: | Signal combination | What it usually means for release planning | |---|---| | High views + unresolved comments | Review before publish | | Recent edit + already approved status | Recheck approval and content changes | | Low engagement + failed searches | Improve findability or fill a content gap | | Stale page + changed feature area | Validate accuracy before release | Do not rank pages by traffic alone. In Atloria, the best release decisions come from combining audience behavior, activity history, and page status. That gives you a practical list of pages that are both visible and potentially risky. ## Turning signals into a release-ready content priority list After reviewing the dashboard, activity feed, and analytics, turn what you found into a working priority list inside your release workflow. The goal is not to create a perfect report. The goal is to produce a short, clear list of pages that the team can act on before version review and publishing approval. 1. Filter the project view to show pages with open comments, stale review status, recent edits, or strong audience traffic. 2. Add the pages that matter to your release working list. 3. For each page, assign a release decision based on what you found. 4. Route each page to the correct owner or reviewer. 5. Record why the page was flagged so the team can understand the decision quickly during review. A simple release decision set works well in Atloria: | Release decision | When to use it | |---|---| | **Update now** | The page has clear issues that must be fixed before release | | **Review before publish** | The page may be correct, but recent activity or comments require a final check | | **Defer to next version** | The issue is real but outside the current release scope | | **Monitor after release** | The page is acceptable to ship, but usage should be watched closely | Use ownership fields, assignee columns, or team labels to send urgent pages to the right Technical Writer or reviewer. This is especially helpful when one release includes multiple collections or content areas. A page should not sit in a general list without an owner if you expect action before publishing. Always capture the reason for each priority call. For example, note whether the page was flagged because of high traffic, unresolved comments, a stale update date, or a late edit after approval. That short note gives version reviewers the context they need without reopening every page from scratch. [SCREENSHOT: release planning list with page title, status, owner, and priority decision] ## Coordinating version review and publishing decisions with the team A prioritized list is most useful when the whole team works from the same view in Atloria. During version review meetings, Documentation Managers can use that list to keep the discussion focused on pages with the highest release risk instead of reviewing every topic in the same depth. This helps the team spend time where it matters most: pages with late edits, unresolved comments, status mismatches, or strong audience impact. 1. Open the release-scoped page list during the version review meeting. 2. Start with pages marked **Update now** and **Review before publish**. 3. Ask the assigned writer or reviewer to confirm what action is needed on each page. 4. Update the page status, comments, or approval state as decisions are made. 5. Recheck the release view before moving the version toward publishing approval. Technical Writers should confirm the exact type of work required for each flagged page. In practice, that usually falls into one of these categories: - Content edits for accuracy or completeness - Metadata updates such as version details or page organization - Link fixes for broken or outdated navigation paths - Approval changes when a page was edited after review Keep the project workspace current while the meeting is happening. If a page moves from **Draft** to **In Review**, or from **In Review** to **Approved**, update that status right away. If a reviewer leaves a decision in comments, make sure the comment thread reflects whether the issue is still open. This keeps the release view trustworthy for everyone involved. For handoff, use one lightweight flow: flagged page review, content update if needed, approval confirmation, then publishing approval. Because the same activity signals stay visible throughout the process, the team can track whether a page still carries risk without switching to a separate planning method. ## Fixing common issues when activity signals are unclear or misleading Sometimes the signals in Atloria do not tell a clear story on the first pass. When that happens, the fix is usually to compare more than one view instead of trusting a single number or label. If analytics show low traffic for a page you know is important, first check your filters. The page may be outside the selected version, tied to a different audience segment, or affected by a recent page URL change. A page that moved or was renamed can appear quieter than expected if you are only looking at the latest path or a narrow version view. If a page looks release-ready but still feels risky, inspect the details behind the status label. Open the page and look for unresolved inline comments, pending approvals, or edits that happened after the last review timestamp. A page marked **Approved** is not truly ready if someone changed key content after that approval. When too many pages appear stale, reduce the scope so the team can act on the current release instead of the entire project history. Narrow the view by: - Release label - Content owner - Modified date - Collection or section included in the release If recent activity is visible but priorities are still unclear, combine the signals. A late edit on a low-impact page may not matter. A late edit on a high-traffic page with open comments probably does. In Atloria, the clearest priority decisions come from reading activity history together with page status and audience metrics. If you still have trouble deciding what belongs in the release conversation, return to the release scope and ask one practical question for each page: does this page create a meaningful risk for internal review, publishing approval, or the audience-facing release? That question usually separates background noise from real release work. ## Overview - This guide focuses on using visible project signals in Atloria to improve release planning for documentation work. - The main signals covered here are: - Recently updated pages - Open review comments - Stale topics - Broken or outdated links - Low recent views - Page status labels such as **Draft**, **In Review**, **Approved**, and **Published** - You use these signals during three key release checkpoints: - Internal version review - Publishing approval - Audience-facing release - The workflow in this guide builds on the analytics-reading approach from [Reading Project Analytics for Documentation Decisions](doc:reading-project-analytics-for-documentation-decisions). - In Atloria, the recommended process is: - Review the project dashboard and activity feed - Filter the release scope by version, collection, or owner - Compare analytics with page status and review history - Build a short priority list for the team - Update statuses, comments, and approvals as release decisions are made - This guide does not replace editorial review. It helps you decide where to look first so the team can spend review time on the pages most likely to affect release quality. [SCREENSHOT: release planning workflow in Atloria from analytics review to publishing approval] ## Prerequisites - You should already know how to read project-level analytics in Atloria. If needed, review [Reading Project Analytics for Documentation Decisions](doc:reading-project-analytics-for-documentation-decisions). - You need access to the project workspace that contains the upcoming release. - You should be able to open the project dashboard or analytics area and view the activity feed. - You need visibility into the pages included in the release, ideally with filters for: - Version - Collection - Content owner - The release workflow is easier to manage if your team is already using page status labels such as **Draft**, **In Review**, **Approved**, and **Published**. - You should also have access to the page comments or review history used by your team during version review. - This guide is most useful for: - Documentation Managers preparing version review - Technical Writers checking pages before publishing - Reviewers helping confirm release readiness across a project For the next step in this workflow, continue with [Using Project Analytics and Audit Signals for Ongoing Operations](doc:using-project-analytics-and-audit-signals-for-ongoing-operations). ## Preparing URLs and capture settings before you start Before you run a website capture in Atloria, decide exactly which page you want to document and how that image will be reused later. Start from the screenshot capture area used by your team and confirm you have the final page address ready to paste into the **URL** field. If you are documenting a public documentation page, a project page, or a release-specific view, make sure you are using the exact page version you want readers to see. Small differences in page state can create confusion later when the screenshot is reused in authoring or release review. Choose the capture scope based on the type of content you are creating. A full-page image is usually the better choice when you need to show a complete article, long settings page, or a full public documentation view. A visible-page capture is more useful when you only need the top section of a page for release notes, summaries, or short how-to content. If your team already covered the basics of taking screenshots, use that earlier workflow as your reference and focus here on preparing assets for reuse: [Capturing and Saving Screenshots for Documentation](doc:capturing-and-saving-screenshots-for-documentation). Before you start the capture, set a clear name pattern for the result. Use names that tell other writers what the screenshot shows, such as the page area, feature, or release context. This makes the image easier to recognize later when you save it into a shared library. Also confirm where the result should end up after review. In Atloria, this usually means choosing the correct project, folder, or shared asset collection used by your documentation team. Saving to the right location from the start prevents cleanup work later. [SCREENSHOT: Website capture screen showing the URL field, capture scope options, and destination selection] ## Capturing screenshots from a website URL 1. Open the website capture screen in Atloria and click into the **URL** field. 2. Paste the page address you want to capture. Double-check the address before continuing, especially if you are documenting a specific project page, public documentation page, or release-ready view. 3. Select the capture option that matches your goal, such as a full-page image or a visible-page image. If you are creating a reusable visual for long-form documentation, full-page capture is often the better choice. If you only need a focused image for a short article or release note, use the smaller page view that shows just the visible area. 4. Click the main capture action, such as **Capture** or **Take Screenshot**. Atloria will show an in-progress state while the image is being generated. Wait for that process to finish before leaving the screen. 5. Review the screenshot in the preview area as soon as it appears. Check that the page loaded correctly, the layout looks complete, and the important interface elements are visible. If the page includes navigation, banners, dialogs, or release-specific content, make sure those details match the scenario you are documenting. 6. If the result is not right, run the capture again. You may need to recapture when the page content changes, when a new release is ready, or when you need a different page state for another guide. 7. Repeat the same process for additional page addresses if you are building a set of screenshots for one project or release cycle. [SCREENSHOT: Capture results screen with a generated website screenshot preview and capture status] ## Reviewing capture results and selecting what to keep After Atloria generates one or more screenshots, use the capture results view to decide which images are worth keeping. This step matters because not every capture belongs in your reusable asset library. Some results are only useful for a one-time draft, while others should be saved for long-term use across guides, release notes, and version comparisons. Start by comparing the new screenshots side by side in the results list or preview area. Look for the image that best represents the page you want readers to understand. The strongest result is usually the one with complete page rendering, readable text, and the right feature state visible on screen. If you captured the same page more than once, choose the version that shows the cleanest layout and the least visual distraction. As you review, check for a few practical details: - The page is fully loaded and not cut off. - Key navigation or page sections are visible. - Any dialog, menu, or state shown matches the documentation scenario. - The screenshot reflects the correct release or current project state. - Text and interface labels are clear enough to recognize. Remove captures that are failed, outdated, or clearly weaker than the best version. Keeping too many similar results makes later version-preparation work harder, especially when teams are selecting visuals during review. If an image was only needed to confirm a page state during drafting, leave it out of the reusable library. Use this review step to separate temporary results from durable assets. One-off captures can stay tied to the immediate task, while screenshots that represent stable pages or important workflows should move forward into the shared asset library. [SCREENSHOT: Capture results list with multiple similar screenshots, one selected as the preferred version] ## Saving screenshots as reusable assets 1. In the capture results view, select the screenshot you want to preserve. 2. Click **Save as Asset**. This moves the image out of the temporary results area and into a location where it can be reused during document authoring and version preparation. 3. Enter the asset details shown on the save form. Use a clear **Title** that describes the page or workflow in plain language. If Atloria shows a **Filename** or internal label field, make it specific enough that another writer can recognize it without reopening the original capture job. 4. Choose the correct destination for the saved image. Depending on how your team organizes work in Atloria, this may be a project, a folder, or a shared collection for screenshots. Pick the location where authors already expect to find approved visuals. 5. Save the asset and wait for Atloria to finish the action. 6. Open the destination location and confirm the screenshot appears there. This is the most important check: if the image only exists in the capture results area, it may not be available later when someone is writing or updating documentation. A good saved asset should be easy to identify at a glance. Instead of using a vague label, use wording that reflects the actual page content, such as a project area, settings page, or public documentation view. This becomes especially important when multiple releases contain similar-looking screens. If you are preparing screenshots for shared use across a team, save only reviewed images. That keeps the reusable library focused on approved visuals rather than every draft capture created during testing. [SCREENSHOT: Save as Asset form showing title, filename or label, and destination selection] ## Organizing assets for document authoring and version preparation Once screenshots are saved, organize them so writers can quickly find the right image while drafting or updating documentation. In Atloria, the most useful structure is one that matches how your team already works: by project, by documentation set, by product area, or by release cycle. The goal is simple—when someone is editing a page, they should be able to locate the correct screenshot without opening old capture jobs or guessing which file is current. Group images in a way that reflects real writing tasks. For example, screenshots for project setup can live together, while public documentation images, admin workspace images, and release-specific visuals can each have their own folder or collection. This makes it easier to support both active authoring and future updates. Use consistent names so similar screenshots do not blur together. Include enough context to distinguish one image from another, especially when the same page changes between releases. Helpful naming patterns often include: - the page or feature shown - the audience or workspace context - the release or version indicator - whether the image is current, draft, or superseded Avoid storing the same image in several places just to make it easier to find. Instead, keep one approved saved asset in the right shared location and rely on clear names and folders to make retrieval easy. This reduces duplication and lowers the chance that a writer inserts an outdated image. Before you leave the asset library, verify that the saved screenshots are clearly separated from raw capture results. Reusable assets should look intentional and ready for insertion into documents, while temporary captures should remain part of short-term review work only. If your team manages screenshots across multiple projects or releases, the broader organization guidance in [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions) can help you standardize the structure. ## Fixing common problems with captures and saved assets When a website capture does not behave as expected, the issue is usually easy to trace if you check the capture result, the saved asset details, and the destination location in Atloria. If the page address opens but the screenshot is blank, partial, or missing important content, return to the capture screen and try again after confirming the page is fully loaded in the state you want to show. A page that is still rendering, loading navigation, or changing layout can produce an incomplete image. Recapturing the page often fixes this. If the image saves successfully but you cannot find it later, review the details you entered during **Save as Asset**. The most common causes are an unclear **Title**, an unexpected **Filename** or label, or saving into the wrong project, folder, or collection. Open the asset location you selected and confirm the screenshot is actually there. If several screenshots look nearly identical during version preparation, clean them up before authors start using them. Rename the approved asset with a release-specific identifier and remove outdated or duplicate capture results. This makes it much easier to choose the right visual during release review. If a screenshot appears in capture results but not during document authoring, it was likely never saved into the reusable asset library. Go back to the results area, select the image, and use **Save as Asset**. Temporary results are useful for review, but they are not the same as approved reusable assets. For larger cleanup and library issues, especially when teams share screenshots across projects, see [Troubleshooting Screenshot Availability Across Projects and Versions](doc:troubleshooting-screenshot-availability-across-projects-and-versions). [SCREENSHOT: Example of a capture result available in results but not yet saved to the reusable asset library] ## Overview This workflow in Atloria focuses on turning website captures into reusable documentation assets rather than leaving them as temporary screenshot results. You start with a page address, generate one or more screenshots, review the results, and then save the best image into a shared location that authors can use again later. That extra save step is what separates quick capture work from a reliable documentation asset workflow. This process is especially useful when the same page image may appear in multiple places, such as product guides, release notes, version comparisons, or review materials. Instead of recapturing the same page every time, your team can keep an approved screenshot in a project folder or shared collection and reuse it during drafting. That saves time and reduces the risk of mixing old and new visuals. The workflow also supports version preparation. When a release changes a page layout, navigation pattern, or feature state, you can capture the updated page, compare it with earlier results, and save the correct release-ready image with a name that clearly identifies its context. That makes it easier for reviewers and writers to tell which screenshot belongs to which release. If you need help with the broader screenshot library after saving assets, continue with [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). If you need a refresher on the capture process itself, return to [Capturing and Saving Screenshots for Documentation](doc:capturing-and-saving-screenshots-for-documentation). ## Prerequisites Before following this workflow in Atloria, make sure you have the basics ready: - You can sign in and open your project workspace or the screenshot area your team uses. 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 know how to run a basic screenshot capture. This guide builds on the earlier capture workflow and focuses on saving reusable assets rather than repeating the basics. Use [Capturing and Saving Screenshots for Documentation](doc:capturing-and-saving-screenshots-for-documentation) if you need that setup first. - You have the correct website page address ready to paste into the **URL** field. - You know which project, folder, or asset collection should store the approved screenshot after review. - You know whether the screenshot is meant for one-time use or should be kept as a reusable asset for future documentation work. - You have enough context to recognize the correct page state, such as the right release view, public page, or project screen. It also helps to prepare a simple naming approach before you begin. If your team captures many similar pages, decide how you will label screenshots so they stay easy to find later. A clear title and destination choice at save time will make the asset much easier to reuse during authoring and version preparation. ## Checking what you need before connecting a Git provider Before you open the **Git** integration area in Atloria, make sure you are working in the correct project and that you can access the project’s settings. Git connections are managed from the project settings area, so you need the level of access that lets you open **Settings** and work with **Integrations**. If you cannot see **Settings > Integrations > Git**, ask a Project Administrator to confirm your access before you continue. You should also know which Git provider you plan to connect. On the **Connect provider** screen, Atloria shows the supported provider options available for your workspace. Choose the one that matches the account where your project’s repositories are stored. If your team already decided on a provider during setup, follow that choice here rather than connecting a different account. Before starting the connection, confirm that you can sign in to the target Git account without needing help from someone else. The connection process sends you through the provider’s sign-in and approval window, and you must complete that step yourself. If you are already signed in with the wrong account in another browser tab, sign out there first or be ready to switch accounts during authorization. It also helps to confirm how your team organizes access on the provider side. Some teams work under a shared organization or workspace, while others use personal repositories. During authorization, you may need to approve access for a specific organization, workspace, or repository scope. If you are not sure which one your project should use, check your team’s setup notes from [Connecting Projects to Git Providers for Source Based Workflows](doc:connecting-projects-to-git-providers-for-source-based-workflows) before you connect. [SCREENSHOT: Project Settings with Integrations and Git selected] ## Connecting a project to a supported Git provider 1. Open the project in Atloria where you want to maintain the Git connection. 2. In the project navigation, open **Settings**, then go to **Integrations**, and select **Git**. This is the project-level area where Atloria shows the current provider connection or lets you start a new one. 3. Click **Connect provider**. Atloria opens a provider selection screen with the supported options available to your project. Choose the provider your team uses for this repository. 4. After you select the provider, Atloria starts the authorization flow. A sign-in or consent window opens for that provider. If prompted, sign in with the Git account that should be linked to this project. 5. Review the provider’s approval screen carefully. Depending on how your team manages source access, you may need to allow Atloria to work with a specific repository, a group of repositories, or an organization-level workspace. If the provider asks you to confirm organization or repository access, select the option that matches the project you are connecting. 6. Finish the approval flow and return to Atloria. When the connection is successful, the **Git** integration panel updates to show that the project has an active connection. 7. Confirm the provider card or connection panel now shows the linked provider and an active status. If Atloria still shows a setup prompt instead of a connected state, refresh the page once and check again. This process links the current Atloria project to the selected Git provider account. If you need help choosing the right provider for a new project, use [Connecting Projects to Git Providers](doc:connecting-projects-to-git-providers). [SCREENSHOT: Connect provider screen followed by provider authorization window] ## Reviewing connection status and linked account details Once a Git provider is connected, return to **Settings > Integrations > Git** whenever you want to confirm that access is still healthy. Atloria uses the Git integration status area to show whether the project is currently **Connected**, **Requires re-authorization**, or **Disconnected**. This is the first place to check if repository access stops working or if a teammate reports that Atloria can no longer reach the source repository. When the status is healthy, the provider panel should show **Connected** along with the provider name and the linked account details. Use this area to confirm you are connected to the expected account, especially if you manage more than one Git identity. A mismatch here can explain why the project cannot see the repository your team expects. Atloria may also show when access was last authorized. That detail helps you understand whether the current grant is recent or whether it may have gone stale after an account change. If your organization recently changed repository visibility, moved a repository into a different workspace, or updated who can approve integrations, the last authorization date can help you decide whether to reconnect or re-authorize. Pay attention to warning states. A status such as **Requires re-authorization** usually means Atloria can no longer use the original approval. This can happen after password resets, account membership changes, removed repository access, or expired provider-side approval. A fully **Disconnected** state means the project no longer has an active Git link at all. If you want a broader review of what these statuses mean in day-to-day work, continue with [Reviewing Git Connection Status and Access Health](doc:reviewing-git-connection-status-and-access-health). [SCREENSHOT: Git integration status card showing provider, account, and connection state] ## Re-authorizing access when the connection needs attention 1. Open the project in Atloria and go to **Settings > Integrations > Git**. 2. Look for a warning state such as **Requires re-authorization**. Atloria uses this status when the project still has a saved connection record, but the linked provider access is no longer valid enough to use normally. 3. Click **Re-authorize**. This is different from starting over with a new connection. Re-authorizing updates the existing project connection so you can restore access without replacing the integration unnecessarily. 4. Atloria opens the provider’s approval window again. Sign in with the same Git account your project should use, unless your team has intentionally moved the project to a different approved account. 5. Review the requested access carefully before you approve it. This step matters most when repository visibility changed, your team moved the repository into a different organization or workspace, or your account permissions were updated since the original connection. 6. Approve the request and return to Atloria. After the provider sends you back, wait for the **Git** integration panel to refresh. 7. Confirm the status changes back to **Connected**. Also check that the linked provider and account details still match the project you are maintaining. If the status does not change right away, refresh the page and review the connection panel again. If Atloria still shows a warning, repeat the re-authorization flow and make sure you completed the provider’s final approval step instead of closing the window early. For cases where you need to replace or remove the connection entirely, use [Reauthorizing and Disconnecting Git Integrations](doc:reauthorizing-and-disconnecting-git-integrations). [SCREENSHOT: Git integration panel with Requires re-authorization and Re-authorize button] ## Disconnecting a Git integration safely 1. Open the project in Atloria and go to **Settings > Integrations > Git**. 2. In the existing connection panel, click **Disconnect** or **Remove integration**, depending on the label shown in your workspace. Atloria uses this action to break the project’s current link to the provider account. 3. Read the confirmation prompt before you continue. Atloria should make it clear that the project will lose access to the linked Git provider account once you confirm. This is especially important if your documentation workflow still depends on repository access for updates or source-based work. 4. Confirm the action. Atloria removes the active connection from the project and updates the integration status. 5. Check the **Git** panel again and make sure the status now shows **Disconnected** or returns to the setup state where **Connect provider** is available. Disconnecting in Atloria removes the project’s active link, but your organization may also require a second cleanup step on the provider side. If your security policy calls for full removal, open the Git provider’s authorized applications or connected apps area and remove Atloria there as well. That provider-side cleanup is separate from the Atloria disconnect action, so do not assume one automatically completes the other. Use extra care before disconnecting a shared project. If multiple team members rely on the same repository connection, confirm with the project owner or documentation lead first. Removing the connection from the wrong project can interrupt source-based documentation work and force the team to reconnect later. [SCREENSHOT: Disconnect confirmation prompt in the Git integration settings] ## Verifying the project's Git access after connecting or updating permissions After you connect, re-authorize, or disconnect a provider, return to **Settings > Integrations > Git** and refresh the page once. The provider card should reflect the latest state. If you just completed a connection or re-authorization, look for **Connected** and confirm the linked account matches the one you intended to use. If you disconnected the integration, the page should show **Disconnected** or offer **Connect provider** again. When the project was re-authorized because of permission changes, verify more than the status label. Check that the project still has access to the intended repository scope, organization, or workspace that your team expects. A connection can appear active while still pointing to the wrong account or a narrower access scope than before. This is especially important after role changes or repository moves. If the status does not update after a successful approval screen, try these checks: - Refresh the **Git** integration page. - Reopen **Settings > Integrations > Git** and confirm the provider card changed. - Repeat the authorization flow and complete every step in the provider’s consent window. - Make sure you approved access with the correct Git account. If you disconnected the project but want to be certain access is fully removed, verify both sides: - In Atloria, confirm the project no longer shows an active provider connection. - In the Git provider account, confirm Atloria is no longer listed in the authorized applications area if your team requires provider-side cleanup. For a deeper review of ongoing connection health after setup, continue with [Reviewing Git Connection Status and Access Health](doc:reviewing-git-connection-status-and-access-health). [SCREENSHOT: Refreshed Git integration page showing final connected or disconnected state] ## Overview This document focuses on the day-to-day Git connection tasks you perform inside a project after your team has already decided to use a source-based workflow. In Atloria, those tasks happen in **Settings > Integrations > Git**, where you connect a provider, check whether access is still active, re-authorize a connection that needs attention, and disconnect a provider when the project should no longer use it. Use this guide when you need to answer practical questions such as: - Is this project currently connected to a Git provider? - Which provider account is linked to the project? - Why does the connection show a warning instead of **Connected**? - How do I restore access without creating a brand-new connection? - How do I remove the provider link cleanly? This guide does not repeat the earlier setup planning covered in [Connecting Projects to Git Providers for Source Based Workflows](doc:connecting-projects-to-git-providers-for-source-based-workflows). Instead, it assumes you already know why the project needs a Git connection and are now working with the actual integration controls inside the project settings. The most important screen throughout this process is the **Git** section under **Integrations**. That screen is where Atloria shows the provider card, the connection status, the linked account details, and the actions available for the current state, such as **Connect provider**, **Re-authorize**, **Disconnect**, or **Remove integration**. If you are troubleshooting access, start there before trying anything else. After you finish the steps in this guide, the next document to read is [Connecting Projects to Git Providers](doc:connecting-projects-to-git-providers), which continues with provider connection work in the broader Git Connections sequence. ## Prerequisites Before you work with a project’s Git connection in Atloria, make sure these basics are in place: - You can open the correct project in Atloria. - You have access to **Settings** for that project. - You can see **Integrations > Git** in the project settings. - You know which Git provider your team wants to use for this project. - You can sign in to the Git account that should be linked. - You are ready to approve access in the provider’s authorization window. A few checks can save time before you start: | What to confirm | Why it matters | |---|---| | Project Administrator access | You need enough access to open the project settings and manage integrations. | | Correct Git account | Connecting the wrong account can leave the project linked to the wrong repositories or workspace. | | Provider-side access | If you cannot access the target repository, organization, or workspace in the provider, Atloria cannot maintain the connection you need. | | Team scope decision | Some teams connect through a shared organization or workspace instead of a personal account. | | Browser session readiness | If you are already signed in to the wrong provider account, the authorization window may connect the wrong identity. | If your project has not been prepared for a Git-based workflow yet, go back to [Connecting Projects to Git Providers for Source Based Workflows](doc:connecting-projects-to-git-providers-for-source-based-workflows) before continuing. If you are already ready to move from preparation into the actual provider setup flow, the next guide in this sequence is [Connecting Projects to Git Providers](doc:connecting-projects-to-git-providers). ## Preparing to generate a new documentation version Before you start a new version in Atloria, open your project workspace and go to the **Versions** area for that project. This is the main place where you review existing versions, check their current status, and start a new generation run. If you are not already comfortable moving around the project workspace, use [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces) for navigation help and [Managing Project Version Workspaces](doc:managing-project-version-workspaces) for version-specific layout details. Take a moment to decide exactly what source the new version should represent. Your team may generate from a branch, a release snapshot, a revision, or another source option shown in the version form. In Atloria, the source you choose affects what content is pulled into the generated version, so make sure you are using the same source your team expects for review or release. If your project uses connected repositories or structured onboarding settings, confirm those details before you click the version action. Choose a version name that will stand out in the **Versions** list. A clear label makes it easier to find later during review, comparison, and approval. Use the same naming style your team already uses so reviewers can quickly tell whether the version is an internal draft, a release candidate, or a release-targeted build. This matters when several versions appear close together in the list. Also confirm the intended stage of the version before you generate it. In practice, that means deciding whether this run is only for internal checking, for formal review, or for release preparation. If you need a refresher on lifecycle expectations and status planning, see [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness). [SCREENSHOT: Project Versions screen showing existing versions and the action used to create a new version] ## Creating a documentation version 1. Open your project in Atloria and go to the **Versions** screen. 2. Click the action your workspace uses to start a new version, such as **New Version** or **Generate Version**. This opens the version form where you define what Atloria should generate. 3. Enter the **Version Name** exactly as you want it to appear in the versions list and later review steps. Pick a name that clearly identifies the release, milestone, or review cycle. 4. Complete the source selection fields shown on the form. Depending on how your project is set up, Atloria may ask you to choose a branch, release tag, source revision, or similar source reference. Select the source that matches the content snapshot you want documented. 5. Review any generation options available on the screen. These options may indicate whether the version is meant for internal review, broader review, or release preparation. Choose the option that matches your team’s workflow so the version enters the right path after generation. 6. Submit the form to start the generation run. After you save or confirm, Atloria returns you to the **Versions** list or opens the new version record. 7. Confirm that the new version appears in the list with an early processing state such as **Queued** or **In Progress**. This is your first sign that the request was accepted. If the version does not appear right away, refresh the **Versions** screen and look again. You should see the new entry with its name, current status, and updated timing details. For a broader walkthrough of starting versions, see [Generating New Documentation Versions](doc:generating-new-documentation-versions). [SCREENSHOT: New Version form with version name, source selection, and generate action] ## Monitoring generation progress 1. Stay on the **Versions** list after starting the run, or open the new version’s detail page from the list. Atloria uses the version status to show where the run currently stands. 2. Watch for status changes as the version moves through processing. Typical progress states include **Queued**, **Generating**, **Completed**, or **Follow-up Required**. These labels tell you whether Atloria is still working, finished successfully, or found something that needs attention. 3. Refresh the page or reopen the version record if the status has not changed for a while. The version detail view is the best place to check the latest processing state, updated timestamps, and any recent activity tied to the run. 4. Review any visible status messages, activity entries, or log-style details on the version page. These messages help you understand whether Atloria is still building the version, validating the output, or stopping because of a warning or failure. 5. Pay attention to timing. If a version remains in **Queued** or **Generating** much longer than other recent runs in the same project, that is a sign to investigate further. A healthy run usually shows steady movement from the initial state to a finished state. If you need a deeper explanation of progress tracking and result timing, refer back to [Monitoring Version Generation Progress and Results](doc:monitoring-version-generation-progress-and-results). That guide covers the status flow in more detail, so this page can stay focused on what to do while you are actively generating a version. When a version appears stalled, compare its latest timestamp with the last visible activity entry. If the time is old and no new messages appear after refreshing, treat the run as needing attention rather than assuming it will finish on its own. [SCREENSHOT: Version detail page showing status, timestamps, and processing messages] ## Reviewing generation results before approval or release Once a version reaches a finished state, open its detail page or results area and read the final status before passing it to reviewers. In Atloria, a completed run is not automatically ready for approval or release. You need to check what kind of completion you received and whether any warnings or validation issues were recorded. Start with the top-level result indicators: final status, completion time, and any links to the generated output. A status of **Completed** usually means the version finished processing, while **Follow-up Required** means Atloria found issues that still need action. If warnings are shown, read them carefully instead of assuming they are harmless. Some teams allow warning-level results for internal review, while others require a completely clean result before a version can move forward. Use the result details to decide what should happen next: - If the version completed cleanly, it may be ready for reviewer handoff. - If the version completed with warnings, decide whether those warnings are acceptable for the current stage. - If validation failed or follow-up is required, hold the version back until the issue is understood. - If the generated output does not match the intended source, plan to regenerate rather than forcing the current version through review. Compare what you see on the version record with your team’s release criteria. If your process requires a clean generation result before approval, do not send a warning-heavy version into the review queue. For comparison guidance after generation, use [Comparing Version Output and Release Readiness](doc:comparing-version-output-and-release-readiness) and [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review). [SCREENSHOT: Completed version showing final status, completion time, warnings, and generated output links] ## Handling versions that need follow-up When a version shows **Follow-up Required**, open the warning or error details first. In Atloria, that status means the run finished with issues that block normal progress. The details on the version page help you determine whether the problem is related to missing content, validation checks, broken links, or generation settings. Use those details to decide the next action. If the issue points to the source content itself, update the affected documentation pages, screenshots, or linked material before trying again. If the problem appears tied to how the version was generated, return to the version setup and correct the source selection or generation options. In some cases, the cleanest approach is to create a replacement version rather than trying to advance the current one through review. Make the reason visible to others working in the project. If Atloria provides notes, comments, assignments, or status updates on the version record, use them so reviewers know why the version is blocked and who is handling the fix. This prevents someone from treating a blocked version as ready simply because it appears in the versions list. After the issue is corrected, start a new generation run and monitor it until it finishes. Then compare the new result with the earlier failed or warning-heavy run. You want to confirm that the follow-up state is gone and that the new version reflects the intended source and output. If your team needs a structured handoff after the fixes are complete, continue with [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions) once the version is clean enough to move forward. [SCREENSHOT: Version with follow-up required status and visible warning details] ## Common issues and how to fix them A few generation problems appear often in Atloria, and the fix usually starts on the version record itself. - **The version stays in Queued or Generating too long** Open the version detail page and refresh it to check whether the status, timestamp, or activity messages have changed. If nothing updates, review any visible processing messages or log details. Compare the run with other recent versions in the same project. If this run is clearly not progressing, stop treating it as active and investigate before starting more review work around it. - **The version finishes with warnings** Read each warning on the results panel. Decide whether the warning is acceptable for the current stage. A version that is good enough for internal review may still be unsuitable for release preparation. If the warning affects content quality, validation, or output trust, fix the source and regenerate. - **The version cannot move toward release after generation** Check the final status and any validation-related messages on the version page. A generated version may still be blocked if required checks did not pass or if the version is not in the right state for approval. Review your team’s release criteria before sending it forward. - **A regenerated version still shows Follow-up Required** Compare the latest run with the earlier run side by side in the **Versions** list or by opening both version records. Confirm that you actually changed the source content or generation settings before rerunning. If the same issue appears again, the original cause was probably not resolved. For more help deciding whether a version is acceptable after generation, use [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). ## Overview Atloria’s version generation workflow centers on one practical goal: create a documentation version from the right source, watch it move through processing, and decide whether the result is ready for review or needs more work. The **Versions** screen is where that work begins and where most follow-up happens. From there, you can start a new version, track its status, open the detail page, and review the final outcome. The most important statuses to recognize are the early processing states and the final result states. Early states such as **Queued** and **Generating** tell you Atloria has accepted the request and is working on it. Final states such as **Completed** and **Follow-up Required** tell you whether the version can continue through the release workflow or needs intervention first. Those labels are not just informational—they determine whether the version should move to review, be held for fixes, or be replaced with a new run. This guide focuses on the moment where generation and monitoring overlap: you are not just creating a version, you are actively checking whether the run is healthy and whether the result meets your team’s standards. It does not repeat the deeper status-reading guidance from [Monitoring Version Generation Progress and Results](doc:monitoring-version-generation-progress-and-results), and it does not go deep into comparison decisions that belong in the next stage. Use this page when you need to move from “start a version” to “judge the result.” If your version completes successfully and you are ready to evaluate changes between runs before a release decision, continue with [Comparing Version Changes for Release Decisions](doc:comparing-version-changes-for-release-decisions). ## Prerequisites Before working through version generation in Atloria, make sure these basics are already in place: - You can sign in to Atloria and open the correct project workspace. - You can reach the project’s **Versions** area and view existing version entries. - You know which source the version should be generated from, such as the branch, release tag, or revision shown in your project’s version form. - You know your team’s version naming pattern so the new entry is easy to identify in the **Versions** list. - You understand whether the version is being created for internal review, review handoff, or release preparation. - You have already learned how to read generation progress and result states at a basic level from [Monitoring Version Generation Progress and Results](doc:monitoring-version-generation-progress-and-results). - If your team uses connected project sources or structured onboarding settings, those project details are already configured and available in the project workspace. It also helps to have a clear release context before you begin. If several versions are active at once, confirm which one should move forward so you do not generate from the wrong source or attach the wrong label. When the versions list contains many similar names, reviewers can easily pick up the wrong record unless naming and timing are clear. If you are still getting familiar with project-level navigation, review [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Managing Project Operations Across Project Home Tabs](doc:managing-project-operations-across-project-home-tabs) before starting a new generation run. ## Preparing the Information You Need Before Creating a Project Before you open **Projects** and start a new workspace, make sure you can actually create projects in your Atloria account. If you do not see the project area after signing in, or you can open **Projects** but do not see a way to start a new one, check with your administrator before you begin. Some setup decisions also depend on organization-level access, especially if your team controls publishing, connected sources, or reporting settings centrally through the admin area. You should also gather the details that will appear in the project from day one. At minimum, have the project name ready, along with any internal identifier your team uses to distinguish similar products, versions, or documentation sets. Decide who owns the project and who will maintain it after setup. If you plan to connect existing content, collect the source locations you will use during setup so you can choose the right creation path without stopping midway. Before creation, agree on how authors will work in the new project. In Atloria, this usually means deciding whether the team will start from imported source content, create pages directly in a structured documentation workspace, or combine both approaches. That choice affects how cleanly your project grows later, especially when you begin organizing pages, versions, and reusable content. It also helps to think one step ahead. If the project will later be published to one or more destinations, tracked in analytics, or organized by audience, language, or category, define those expectations now. Stable naming, consistent metadata, and clear ownership make later setup much easier. If you need help deciding on a setup approach first, review [Planning Project Structure Before Document Authoring](doc:planning-project-structure-before-document-authoring). [SCREENSHOT: Projects area showing the project list and the option to create a new project] ## Choosing the Right Project Creation Path When you click to create a project in Atloria, the most important early decision is how you want that project to begin. Your team may be able to start with a blank project, use a prepared template, or create the project from existing content sources. Each path leads to a usable project, but they support different kinds of work. A blank project is usually best when you want full control over the structure from the start. Choose this path if your team already planned the page hierarchy, metadata, and authoring approach and does not want inherited defaults. It gives you a clean starting point, but it also means you will need to define more settings yourself after the project is created. A template-based project is a better fit when your organization already has preferred structure, naming patterns, metadata expectations, or publishing defaults. Instead of rebuilding those choices manually, the template can give your team a ready-made starting point. This is especially useful when multiple projects need to follow the same documentation model or when consistency matters for reporting and publishing. Creating a project from existing content is the right choice when your documentation already lives somewhere else and you want Atloria to reflect that source early. This path matters because initial import decisions often shape how content is grouped, how sections are split, and how reusable material is handled later. If the source is organized poorly, that mess can carry forward into authoring and cleanup work. The tradeoff is speed versus control: | Creation path | Best when | Main tradeoff | |---|---|---| | Blank project | You want a custom setup | More manual configuration | | Template | You need consistency fast | Less flexibility at the start | | Existing content | You already have source material | Early import choices affect later cleanup | If you expect multiple publishing outputs, audience-specific content, or detailed analytics from the beginning, take the slower path and choose the option that gives you the strongest structure rather than the fastest launch. ## Creating the Project and Setting Core Options 1. Sign in to Atloria and open the **Projects** area from your main workspace. Look for the option to create a new project and open the project creation screen. 2. Enter the project’s main identifying details. Use the project name your team will recognize immediately, and complete any additional identifying fields shown during setup. If Atloria asks where the project should live, choose the correct workspace or organization so the right team can access it after creation. 3. Select how the project will start. Depending on what Atloria shows in your account, this may include a blank project, a template, or an option tied to existing content. After you choose, review any setup panels that appear. These may prompt you to connect a content source, upload material, or accept a starter structure for the new project. 4. Complete the core setup options shown on the screen. Pay close attention to fields that define the project’s default language, content organization, and required metadata. These choices affect how authors create pages later and how consistently content can be filtered, reviewed, and published. 5. Save the project when the required fields are complete. After saving, open the new project and review its initial settings page. In most cases, ownership, some descriptive details, and other administrative settings can still be adjusted later. However, the creation path, imported source shape, and other foundational setup choices may influence parsing, publishing, and analytics in ways that are harder to undo. Use the first save as a checkpoint, not the finish line. Once the project exists, confirm that the workspace looks right before inviting contributors or importing large amounts of content. [SCREENSHOT: New Project screen with project name, creation path options, and core setup fields] ## Configuring Decisions That Affect Authoring and Parsing The setup choices you make when the project is created shape what authors see later when they begin writing and organizing content. If you start with a structured content model, authors will usually work within a clearer page hierarchy and more predictable metadata requirements. If you begin from imported material, the imported structure may influence how topics are divided and how easy they are to edit afterward. A mixed workflow can work well, but only if your team is clear about which content should stay connected to source material and which content should be maintained directly in Atloria. If your project includes imported content, pay close attention to how source files or folders are mapped during setup. Early mapping decisions affect how content is segmented into pages or sections. A clean source arrangement usually leads to cleaner imported topics, while a confusing source layout can create unnecessary cleanup for writers. The same is true for extraction behavior: if content is brought in too broadly or split too aggressively, authors may spend more time repairing structure than writing. Naming and categorization choices also matter here. Consistent project naming, topic labels, and metadata defaults make it easier for contributors to find the right content later. They also reduce duplicate pages and inconsistent labels across the workspace. If Atloria shows required metadata during setup, treat those fields seriously. They are often the foundation for filtering, review, and publishing decisions later. Common setup mistakes that create rework include: - Choosing a source structure that does not match how the team plans to maintain content - Leaving required metadata undefined until after authors have already started writing - Mixing imported and manually authored content without clear ownership rules - Using inconsistent naming for sections, categories, or content groups A little extra care during setup saves a lot of cleanup once the project begins to grow. ## Setting Up Publishing and Analytics Readiness Project setup is not only about getting authors into a workspace quickly. It also determines how smoothly the project moves into publishing and how useful the reporting will be later. In Atloria, the way you organize content at creation time affects how easily that content can be grouped, filtered, and delivered through future publishing workflows. If the project will eventually support more than one publishing output, define the content organization carefully from the start. Clear section names, stable categories, and consistent metadata help you prepare content for different destinations without reorganizing everything later. If your team plans to publish for different audiences, products, or release tracks, those distinctions should be reflected in the project structure and metadata choices early. Analytics readiness depends on the same discipline. Reporting works best when the project has a stable identity and consistent categorization. If teams create similar projects with inconsistent names or apply labels differently across content, reporting becomes fragmented. That makes it harder to compare usage, activity, or performance across projects. For that reason, define project-level metadata and categorization fields early, especially if your team expects to review analytics by product line, documentation area, or audience. Not every publishing or reporting option has to be completed during the first creation screen. Use this rule of thumb: - Configure foundational items during creation: - Project name - Ownership context - Default language - Core content organization - Required metadata and categories - Configure follow-up items after the project is saved: - Detailed publishing destinations - Additional project administration settings - Analytics review screens and later reporting checks If you want to explore those project-level areas after setup, see [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options), [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls), and [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). ## Verifying Your Setup Before Authors Start Working 1. Open the new project and go through its settings and setup-related screens carefully. Confirm that the project was created in the correct workspace, that the selected creation path matches your original plan, and that any connected content source appears where expected. 2. Review ownership and administrative details. Make sure the right people can access the project and that the project is assigned to the correct team context. If your organization separates project administration from authoring, confirm those assignments before content work begins. 3. Check the metadata and structure defaults inside the project. Look for the categories, required fields, language settings, and content organization choices you expected to see. If those defaults are missing or inconsistent, fix them before contributors begin creating pages. 4. Run a small test using representative content. Create a sample page or import a small amount of source material instead of loading everything at once. Then review the result. Confirm that content is split sensibly, required fields appear where they should, and the project’s publishing-related options align with the structure you chose. 5. Validate reporting consistency. If the project will be measured in analytics later, confirm that the identifying fields, categories, and taxonomy values appear consistently across the sample content. This helps prevent reporting from splitting similar content into separate groups. 6. Resolve readiness issues before launch. The most common problems are missing permissions, incorrect source mapping, incomplete metadata requirements, and publishing-related options that are not yet available in the project. A short verification pass at this stage is much easier than correcting a live project after several authors have already started building content. [SCREENSHOT: Project settings or project home area showing ownership, content source, and setup-related options] ## Overview This guide focuses on the decisions that happen between planning and active content work in Atloria. By this stage, you should already have a rough structure in mind from [Planning Project Structure Before Document Authoring](doc:planning-project-structure-before-document-authoring). The goal here is to turn that plan into a project setup that supports the way your team will actually write, import, organize, publish, and measure documentation. The most important idea is that project creation is not just an administrative step. The choices you make on the **New Project** screen and in the project’s early settings influence several later workflows at once. The selected creation path affects whether the team starts from a blank workspace, a predefined structure, or existing content. Core setup fields influence how pages are grouped and how contributors enter metadata. Early source decisions affect how imported material is divided and maintained. Those same choices also shape how easily the project can be published and how cleanly it appears in analytics. This guide walks through four practical areas: - What information to gather before opening **Projects** - How to choose the right project creation path - Which core options to set during creation - How to verify setup readiness before authors begin working Use this guide when you are preparing a new documentation workspace and want to avoid cleanup later. It is especially useful for project administrators, documentation managers, and team leads who need the project to support both authoring and downstream workflows from the start. ## Prerequisites Before working through this setup process in Atloria, make sure the following are already in place: - You can sign in successfully and reach the main authenticated workspace - You can open the **Projects** area - You have permission to create a new project, or you know who can create it for you - You know which workspace or organization the project belongs to - You have already reviewed [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) if your team is still new to the initial project flow - You have already compared setup styles in [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup) if you are unsure whether to start from connected content or a more manual structure - You have already planned the broad content shape in [Planning Project Structure Before Document Authoring](doc:planning-project-structure-before-document-authoring) It also helps to have this information ready before you start: - The project name and any internal naming standard your team follows - The person or team who will own the project - The content source you plan to use, if the project will begin from existing material - The preferred authoring approach for the first release - Any required language, category, audience, or reporting expectations After your project is created and verified, continue with [Managing Project Structure and Content Planning](doc:managing-project-structure-and-content-planning) to refine the workspace for day-to-day authoring. ## Opening the docs and orienting yourself in the sidebar When you open public documentation in Atloria, the page is organized into three reading areas. On the left, you see the navigation sidebar. In the center, you see the current article. On the right, you may see a table of contents for the page you are reading. This layout makes it easy to move between topics without leaving the documentation view. The left sidebar is the main place to get oriented. It shows the documentation structure as a list of categories and pages. Some items act as section headers that can be expanded or collapsed, while others open a specific article. If you already know part of the topic name, use the search input in the sidebar to quickly narrow the list and jump to the page you want without guessing the page address. As you move through the docs, Atloria highlights the page you are currently reading in the sidebar. Parent sections stay open so you can see exactly where that page sits in the larger documentation structure. This is especially helpful when you arrive from a shared link and want to understand the surrounding topic area. You may notice three kinds of pages while browsing: - **Landing pages** introduce a broader documentation area. - **Category pages** collect related articles under one topic. - **Individual documentation pages** contain the full article content. If you need a refresher on basic public browsing before working across multiple sections, see [Understanding Public Navigation and Content Discovery](doc:understanding-public-navigation-and-content-discovery). [SCREENSHOT: Public documentation page showing left sidebar, article content in the center, and table of contents on the right] ## Browsing categories and moving between related pages Category pages help you move through related content without starting over from the top of the documentation each time. In Atloria, a category groups articles that belong to the same subject area, so you can begin with a broader page and then open more specific child pages from there. In the sidebar, categories usually appear as expandable items. When a category is collapsed, you only see the category label. When you expand it, the child pages appear underneath, often indented to show the navigation level. Some categories may contain additional nested levels, which helps organize larger documentation sets into smaller, easier-to-scan sections. You can move through a category in several ways: 1. Click the category name in the sidebar if it opens an overview page. 2. Expand the category and select a child page directly from the navigation tree. 3. Use links inside the current page to open related pages in the same section. 4. Use the **Previous** and **Next** links at the bottom of an article to continue through a sequence. Those **Previous** and **Next** links are especially useful when you are reading a guided set of articles in order. They let you continue to the next topic without reopening the sidebar after every page. As you browse, visible parent category names and the open navigation path help you understand where you are. If you move deep into a nested section, you can still look at the expanded sidebar and trace your way back to the broader topic. For more detail on finding pages inside published docs, see [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page). [SCREENSHOT: Expanded sidebar category with nested child pages and Previous/Next links at the bottom of an article] ## Using the table of contents to scan long pages On longer documentation pages in Atloria, the right side of the screen may show a table of contents. This panel is built from the headings inside the article, so it reflects the actual sections on the page you are reading. Instead of scrolling through the full article to find one topic, you can use this list to jump straight to the section you need. Each entry in the table of contents matches a heading in the article. When you click one of these entries, Atloria scrolls the page to that heading. This is useful when a page includes several tasks, examples, or reference sections and you only need one part of the article. As you scroll through the page, the table of contents also helps you keep your place. The heading for the section you are currently reading is highlighted, so you can tell where you are within the article at a glance. If the page has multiple heading levels, the table of contents may show a nested structure, making it easier to understand how sections relate to one another. You may not always see a table of contents. Short pages with only a title and a small amount of content may not have enough headings to generate one. On those pages, the right side may be empty or contain only a very short list. That does not mean anything is wrong with the page; it usually just means the article is brief. If you are working with public pages that include version context or technical reference sections, the table of contents becomes even more useful for jumping between larger blocks of content. Related reading: [Reading Versioned Documentation in Public Views](doc:reading-versioned-documentation-in-public-views). [SCREENSHOT: Right-side table of contents with the current section highlighted while reading a long article] ## Switching between documentation versions without losing context If a documentation set in Atloria includes multiple releases, you can switch between them using the version selector. This control appears in the public documentation header or page chrome and lets you choose which version of the docs you want to read. The version selector is useful when instructions differ between releases. For example, you might compare the current documentation with an older version or check a prerelease set before rollout. Each version is labeled so you can tell whether you are reading the current release, an earlier release, or a prerelease version. When you choose a different version, Atloria tries to keep you in the same place by opening the matching page in that version when it exists. This saves time because you do not need to manually browse back to the same topic after every switch. If the page is available in both versions, you stay on the equivalent article and can compare the content more easily. Sometimes the page you are reading does not exist in the version you selected. In that case, Atloria may open the version home page or the nearest available page instead. If that happens, check the sidebar after the switch. The active page highlight and expanded category path will help you confirm where you landed and whether you need to open a different article in that version. When comparing releases, always look at the version label before following instructions or sharing a link. If you want a deeper explanation of how version context affects public reading, see [Understanding Public Document Views and Version Context](doc:understanding-public-document-views-and-version-context). [SCREENSHOT: Version selector in the public documentation header with multiple release options] ## Sharing and revisiting the exact page you need Public documentation in Atloria is designed so you can return to the same place later or share it with someone else. Each article has its own page address, and when versioned documentation is in use, the selected version is part of that context. That means the link you copy can point to the exact article and, when applicable, the exact release you were viewing. If you want to share a specific section instead of the whole article, use the heading link from the page itself or from the table of contents. This is especially helpful on long pages where the person receiving the link only needs one section. A section link opens the page and jumps directly to the matching heading. Browser navigation also works well with public docs. If you click several pages in the sidebar, use an in-page heading jump, or switch versions, the browser **Back** and **Forward** buttons can help you retrace your steps. This is useful when you follow a related link and then want to return to the exact article or section you were reading before. Choose your bookmark based on what you need to revisit: - Bookmark a **category page** if you want a broad starting point for a topic area. - Bookmark an **article page** if you return to one guide often. - Bookmark a **version-specific page** if the instructions matter for one release. - Bookmark a **section link** if you repeatedly use one part of a long article. For more on moving through public content before sharing links, see [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation). ## Fixing common navigation problems readers run into Most public navigation issues in Atloria come down to page location, heading structure, or version context. If something does not look right, start by checking what page you are on, which version is selected, and what is highlighted in the sidebar. If a page seems to be missing from the sidebar, first check the version selector. You may be viewing a release where that page does not exist or where it was reorganized. Next, expand nearby categories in the sidebar and look for the page under a different section. Because Atloria keeps parent categories open for the current page, the navigation tree often gives you a clue about where related content now lives. If the table of contents is missing expected sections, look at the article itself. The table of contents is based on visible page headings. If the page is short or has only a few headings, the table of contents may be very small or absent. This usually reflects the structure of the page rather than a loading problem. If the version selector opens a different page than you expected, the exact article may not be available in the version you selected. Atloria may send you to the version home page or another nearby page instead. Use the sidebar and the active-page highlight to find the closest matching article in that release. If you lose your place after following links, try these options: - Use the browser **Back** button to return to the previous page or section. - Check the highlighted page in the sidebar to confirm your current location. - Look at the expanded category path to move back to the broader topic. - Reopen the section you were reading from the table of contents if you only lost your place within a long page. For audience-specific public reading patterns, see [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content). ## Overview This guide focuses on how readers move through public documentation in Atloria once the docs are already published and available to browse. The main navigation tools are the left sidebar, the article area, the right-side table of contents when present, and the version selector for documentation sets that include multiple releases. The sidebar helps you move across categories and articles, with the current page highlighted so you can always see where you are. Category pages give you a broader entry point into a topic, while individual pages let you read detailed instructions. On longer articles, the table of contents helps you jump to specific sections and keep track of your position as you scroll. When versioned docs are available, the version selector lets you compare releases without manually searching for the same topic again. This guide is most useful when you want to do one of the following: - Find a page from the public navigation tree - Move through related articles in a category - Jump to a section within a long article - Switch to another documentation version - Share or bookmark the exact page or section you need - Recover quickly when a page appears missing or opens somewhere unexpected It builds on the public reading concepts covered in [Understanding Public Navigation and Content Discovery](doc:understanding-public-navigation-and-content-discovery) and stays focused on practical navigation behavior rather than content authoring or publishing setup. ## Prerequisites Before using the navigation patterns in this guide, make sure you have access to a public documentation site in Atloria and can open at least one published article. You do not need editing access, project permissions, or admin tools for the tasks described here. This guide is written for readers using the public documentation experience. You will get the most value from this guide if the following are true: - You can open the public docs and see the left navigation sidebar - You can load an article page in the main reading area - You may have a right-side table of contents on longer pages - You may have a version selector available if the docs include multiple releases It also helps if you are already familiar with the basics of public browsing, including opening pages from the sidebar and recognizing category-based navigation. If you have not covered that yet, read [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) first. Use this guide when you are trying to navigate more efficiently across a larger documentation set, compare versions, or return to a specific page later. If you need help with audience-based public views instead, refer to [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience). ## Planning Which Screenshots to Capture for a Project Before you open the screenshot library or start capturing images, decide exactly which pages need visuals for the project and release you are documenting. In Atloria, this works best when you map each screenshot to a specific project workspace, a specific documentation version or release, and the exact document page where the image will appear. That keeps your screenshot work tied to the same release decisions you are already managing in your version workflow. If you need the broader release process, use [Managing Screenshot Workflows Across Documentation](doc:managing-screenshot-workflows-across-documentation) for the cross-team view. Start with a simple capture list that includes: - the project name - the release or version label - the document page title - the workflow step the screenshot supports - the screen state you need to show For each planned image, decide whether readers should see: - a draft workspace view - a published documentation view - a release-specific variation that changed between versions This matters when the same page looks different across releases. If your document explains a new setting, updated navigation label, or revised workflow, capture the version that matches the release being reviewed. It also helps to standardize names before capture. Use titles that combine the project, release, and page context so the screenshot library stays searchable later. For example, a title should clearly point to a settings screen, analytics page, or project workflow rather than a vague label like “image 1.” Before capture day, confirm that you can open the correct project workspace and the correct release-related views. If you cannot reach the right project or version context, you risk saving screenshots that belong to another release or another team’s documentation set. [SCREENSHOT: planning worksheet or screenshot list showing project, release, page, and screen state columns] ## Capturing and Uploading Screenshots to the Library When your capture list is ready, open the screenshot library from the relevant project workspace and begin a new upload or capture action. The most important step at this stage is choosing the correct project context before you save anything. In Atloria, screenshots belong to project-specific documentation work, so an image saved under the wrong project can be difficult for reviewers to find and easy for another team to misuse. 1. Open the project workspace where the documentation belongs. 2. Go to the screenshot library for that project. 3. Start a new upload or capture action. 4. Assign the screenshot to the correct project. 5. Select or tag the related release or version if that option is available in the upload form. 6. Enter a clear title and description before saving. 7. Review the preview image and then save it to the library. Your title and description should match the document task the screenshot supports. Good examples are task-based labels such as a project settings screen, a version review step, or a screenshot showing a publishing option. This makes the image easier to find later from search and easier to confirm during release review. Always check the preview before saving. Look for: - cropped menus or cut-off buttons - outdated labels from an older release - the wrong project or workspace content - missing details needed for the document step If the preview does not match the page you are documenting, replace it before it enters the shared library. That avoids cleanup later when writers are inserting screenshots into documents under deadline pressure. [SCREENSHOT: screenshot library upload form with project, release, title, description, and preview visible] ## Organizing the Screenshot Library by Project and Release As the screenshot library grows, organization becomes just as important as capture quality. In Atloria, keep screenshots separated by project first, then narrow your view by release when you are reviewing assets for a specific documentation version. This prevents one project’s screenshots from being reused in another project’s pages just because the screen looks similar. Use project-level organization to keep each documentation set clean. When you open a project’s screenshot library, review only the assets tied to that project before you insert anything into a document. If you are preparing a release update, apply release or version filters so you only see screenshots relevant to that release cycle. Consistent naming is what makes library search useful. Standardize the same details across titles, tags, and descriptions so related screenshots appear together in search results. | Library detail | What to include | Why it helps | |---|---|---| | Title | Project name, page or workflow name, release label | Makes the screenshot identifiable at a glance | | Tags | Feature area, document topic, release | Helps narrow search results quickly | | Description | What the screenshot shows and which step it supports | Helps reviewers confirm the correct image | Set aside time to review duplicate or older images. When you find multiple screenshots for the same page, decide whether to: - replace the older image with the current approved one - archive the old image for historical release coverage - keep both because each one supports a different release That decision should be based on release needs, not convenience. If an older screenshot still supports a published version, keep it clearly labeled rather than deleting it and breaking release history. For broader screenshot organization practices across teams, see [Organizing Screenshots for Documentation and Releases](doc:organizing-screenshots-for-documentation-and-releases). [SCREENSHOT: screenshot library filtered by project and release, with search and tags visible] ## Adding Library Screenshots to Documents When you are editing a document in Atloria, add screenshots from the screenshot library instead of uploading a one-off image directly into the page. Using the library keeps screenshots connected to the right project and release, and it makes later updates much easier when a screen changes. 1. Open the document page you want to edit. 2. Place your cursor where the screenshot should appear. 3. Use the image insert option and choose the screenshot library. 4. Search or filter for the screenshot by project, release, title, or tag. 5. Select the image that matches the document step you are describing. 6. Insert the screenshot and review how it appears in the page. 7. Save the document after confirming the image placement and text around it. Choose the screenshot that matches both the project and the release of the document version you are editing. A screenshot can look correct at first glance but still be wrong if it shows an older navigation label, a draft-only screen state, or a setting that changed in the current release. After inserting the image, review the surrounding content carefully: - Does the screenshot match the step-by-step instruction beside it? - Do visible labels in the image match the labels named in the text? - Does the image appear in the right place in the workflow? - Does the caption, if used, explain what the reader should notice? If a newer screenshot replaces an older library asset, return to the document and update the image reference so readers do not continue seeing outdated UI. This is especially important for release pages that are already under review, because the text may have been updated while the screenshot stayed behind. [SCREENSHOT: document editor with image picker open to the screenshot library] ## Reviewing Screenshot Versions Before Publishing Before you publish a documentation version, run a screenshot review that focuses on release accuracy rather than image collection. In Atloria, this means checking that every screenshot linked in the current document set matches the release being published and not an earlier draft, earlier release, or another project’s asset. 1. Open the documents included in the release you are preparing. 2. Review each inserted screenshot against the current release content. 3. Compare screenshots for changed pages against prior-release images. 4. Confirm that each image is the approved version for that page. 5. Check that labels shown in the screenshot match the wording in the document text. 6. Preview the document to make sure each screenshot renders correctly. 7. Resolve any outdated or mismatched images before publishing. Comparing current screenshots with prior-release images is especially useful when navigation, settings pages, analytics screens, or publishing options have changed. Even small label changes can confuse readers if the screenshot and the written instructions no longer match. This review is also where ownership matters. Writers, editors, and documentation managers should confirm: - who owns the screenshot update - whether the image was captured for the current release - whether the screenshot is approved for publication - whether any final UI changes happened after the image was added If you are coordinating release readiness across multiple pages, align this review with your version approval process so screenshots are checked before final sign-off. Related release guidance is covered in [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release). A final preview pass should always include visual checks inside the document itself. An image can be correct in the library but still appear too small, misplaced, or disconnected from the step it is meant to support once the page is rendered. [SCREENSHOT: document preview showing screenshot placement and release review comparison] ## Fixing Missing, Outdated, or Unavailable Screenshots When a screenshot is missing from the image picker or the wrong image appears in a document, start with project and release checks. In Atloria, most screenshot problems come from saving the image in the wrong project library, filtering the library too narrowly, or using an older release asset in a current document. If a screenshot does not appear in the picker, check: - that the screenshot was uploaded to the same project library as the document - that you are searching with the expected title, tag, or description words - that release or version filters are not hiding the image - that the screenshot still exists in the library If the wrong screenshot appears on the page, review the image’s release assignment and compare it with the document version you are editing. A page may still be pointing to an older screenshot even after a newer one has been uploaded. Use this process to correct the issue: 1. Open the affected document page. 2. Identify the missing, outdated, or incorrect screenshot. 3. Search the project screenshot library using the project name, page context, and release label. 4. Remove restrictive filters if the image does not appear. 5. Select the correct screenshot from the library. 6. Replace the outdated image in the document. 7. Save and preview the page to confirm the fix. If teammates cannot find a screenshot, naming consistency is usually the next thing to review. Titles and descriptions that do not include the project, release, or page context are much harder to locate during release work. If a screenshot has been removed or superseded, make sure the document was updated at the same time. Otherwise, the page may still reference an asset that is no longer available in the library. For more issue patterns, see [Troubleshooting Screenshot Availability Across Projects and Versions](doc:troubleshooting-screenshot-availability-across-projects-and-versions). [SCREENSHOT: screenshot picker with filters, search, and replacement action visible] ## Overview Managing screenshot operations across projects and releases in Atloria is mainly about keeping every image tied to the right project workspace, the right release, and the right document page. The screenshot library is most useful when teams treat screenshots as shared documentation assets instead of one-time files added directly into pages. This workflow usually follows five connected activities: - planning the screenshot list before writing or review - capturing or uploading images into the correct project library - organizing assets with consistent titles, tags, and descriptions - inserting library images into document pages - reviewing and replacing screenshots during release preparation Across multiple projects, the biggest risk is accidental reuse of the wrong image. Across multiple releases, the biggest risk is keeping an older screenshot after the written instructions have already been updated. Atloria helps reduce both problems when you work from the screenshot library and stay consistent about project and release labeling. This guide focuses on day-to-day screenshot operations for active documentation work. It is especially useful when you are maintaining several project workspaces, preparing release-specific documentation, or coordinating screenshot updates with other writers and reviewers. Use this guide alongside related screenshot documents when you need more detail on a specific part of the workflow: - [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) - [Managing Enterprise Screenshot Libraries](doc:managing-enterprise-screenshot-libraries) - [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions) Those guides cover the broader structure. This one stays focused on the operational work of making sure the right screenshots are captured, stored, inserted, reviewed, and corrected across release cycles. ## Prerequisites Before you manage screenshots across projects and releases in Atloria, make sure you have the right working context and enough information to choose the correct images. You should have: - access to the Atloria account you use for documentation work - access to the relevant project workspace - access to the document pages you need to edit or review - a clear release or version label for the documentation set you are updating - a screenshot list or page list showing which images are needed It also helps if you already know: - whether the page should show a draft workspace view or a published view - which screenshots are new for the current release - which existing screenshots may need replacement - how your team names screenshot titles and descriptions in the library If you are still getting set up in Atloria, refer to: - [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) - [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) - [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) If your work is tied to release preparation, these documents are also useful: - [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) - [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) For teams handling screenshots at scale, you may also want the library-focused references: - [Using Enterprise Screenshot Libraries for Documentation Teams](doc:using-enterprise-screenshot-libraries-for-documentation-teams) - [Managing Screenshot Workflows Across Documentation](doc:managing-screenshot-workflows-across-documentation) From here, you can move into your project workspace, open the screenshot library, and start working through the project and release-specific image set you need to maintain. ## Opening technical documentation from project and public views In Atloria, generated technical documentation can appear in two different reading contexts: inside a project workspace and in the public documentation site. The content may cover the same API reference pages and technical sections, but the surrounding navigation is different depending on where you open it. Inside a project, you usually enter the technical documentation flow from the project’s documentation area, where you can browse page lists and move through generated reference content alongside the rest of the project’s documentation structure. This project-scoped view keeps you inside the workspace, so you are reading documentation with the project context around you. That makes it easier to compare technical pages with other project materials and move between documentation sections without leaving the project. In the public documentation site, readers access the same published reference content through the public navigation experience. This view is focused on reading rather than managing. Public readers see the documentation structure, page titles, and section navigation, but they do not see project workspace controls. The page is presented as published documentation rather than as part of an internal project area. Use these differences to orient yourself while browsing: - **Project view** usually keeps you inside the project workspace and project navigation. - **Public view** presents the documentation as a reader-facing site. - **Both views** can include the same technical guides and API reference pages if that content has been published. When you are unsure which view you are in, look at the surrounding navigation and page framing rather than only the page content. The API page itself may look similar, but the project view includes project context while the public view is designed for external reading. [SCREENSHOT: Same API reference page shown once inside a project workspace and once in the public documentation view] For a broader explanation of where these pages appear, see [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views) and [Browsing Technical Documentation and Entity Reference Pages](doc:browsing-technical-documentation-and-entity-reference-pages). ## Moving between technical guides and API reference pages When you browse technical documentation in Atloria, you often need to move back and forth between explanatory guide pages and generated API reference pages. The fastest way to do that is to follow the documentation navigation rather than opening pages one by one from scratch. 1. Open the documentation area from your project workspace or from the public documentation site. 2. Use the left sidebar to find the section you want to read. Look for technical guide pages in the broader documentation structure and API reference entries grouped under their own reference section. 3. Click a guide page when you want explanation, workflow context, or narrative documentation. 4. Click an API reference page when you need request details, field definitions, or response information. 5. Use in-page links when a guide points you directly to a related API page. These links help you jump from explanation to reference without losing your place in the documentation set. 6. To return to a broader section, use the breadcrumb trail, the left navigation, or the parent section link if it is shown on the page. 7. Repeat this pattern as you verify that guide content and generated reference content match each other. This movement is especially useful for technical writers and reviewers. A guide page may explain when to use a feature, while the API reference page shows the exact request and response structure. By switching between the two, you can confirm that the written guidance still lines up with the generated reference details. Watch for grouped API sections in the navigation. These groups help you move from high-level technical content into more detailed reference pages without losing the overall documentation structure. If you need a refresher on how technical sections are arranged inside a project, see [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). [SCREENSHOT: Sidebar navigation showing a technical guide page and nearby API reference pages] ## Reading generated API reference pages A generated API reference page in Atloria is built for close reading. The page usually starts with a clear title for the operation, resource, or reference item, followed by identifying information such as a path, name, or other label that distinguishes that page from nearby entries. Near the top, you will also see summary text that explains what the page covers. As you scroll, the page typically breaks information into predictable sections. Request details are shown in a structured way so you can quickly see what must be sent and what is optional. Response details appear in separate blocks so you can understand what comes back after a request is processed. Use the page layout like this: 1. Start with the page heading to confirm that you opened the correct reference item. 2. Read the summary text under the heading to understand the purpose of the page before reviewing the details. 3. Look for request sections that list inputs such as parameters, request body fields, and named fields. 4. Check whether fields are marked as required or optional before comparing them with your guide content or implementation notes. 5. Move to the response section to review status codes, response body details, and any linked schema information. 6. Open linked schema or model references when you need more detail about a field structure that is only summarized on the current page. 7. Review example payloads and field tables to understand how the request and response are expected to look in practice. The table below shows the main page elements you will usually rely on while reading: | Page area | What to look for | Why it helps | |---|---|---| | Title and identifier | Operation name, resource name, path, or page label | Confirms you are on the right reference page | | Request details | Parameters, request body, field names, required or optional markers | Shows what information must be provided | | Response details | Status codes, response body structure, linked schema details | Shows what the API returns | | Examples | Example payloads and sample structures | Helps you interpret the reference more quickly | [SCREENSHOT: Generated API reference page with title, request section, response section, and linked schema area] ## Understanding how reference pages are organized Atloria groups generated reference pages so readers can move through large documentation sets without guessing where each page belongs. In most cases, API reference entries are collected under a dedicated reference area in the documentation navigation, while narrative technical pages stay in broader guide sections. This separation helps you tell whether you are reading explanation or generated reference content before you even open a page. You will usually notice a few common organization patterns: - Pages grouped by **API area** so related topics stay together - Pages grouped by **resource** so similar operations appear in one place - Pages grouped by **version** when the documentation set separates reference content by release - Nested pages for **schemas** or **models** under a related reference section These patterns matter because they shape how you browse. If several pages share a resource or topic, they are often listed together in the sidebar. If a page describes a data structure rather than an operation, it may appear under a schema or models section instead of beside guide pages. Page titles and navigation labels are your best clues. Technical guide pages usually read like instructional content, while generated reference entries are more likely to use concise labels tied to a specific API item. The title style, placement in the sidebar, and nearby pages help you understand what kind of content you are reading. Project and public views can show the same hierarchy with different surrounding controls. In a project workspace, the reference tree appears within the project context. In the public site, the same hierarchy is presented for reading, without project management controls around it. The page order and grouping should still feel familiar across both views, which makes it easier to review published output against the project source. [SCREENSHOT: Documentation sidebar showing guide sections, API groups, and nested schema pages] ## Finding the right page faster while browsing large documentation sets Large documentation sets can feel crowded if you scan every page title from top to bottom. In Atloria, the quickest approach is to narrow your view using the documentation structure first, then confirm the page type from the content on the page itself. 1. Start in the left sidebar and choose the top-level technical section that matches what you are looking for. 2. Expand only the relevant API group or technical section instead of scrolling through the full documentation tree. 3. Open a likely page and check the page heading immediately. A guide page usually reads like instructional content, while a generated API reference page usually opens with a more specific reference title. 4. Scan the body of the page for clues: - **Parameter tables** - **Request body sections** - **Response blocks** - **Schema references** These signs usually mean you are on a generated API reference page. 5. Use breadcrumbs or parent links to confirm where the page sits in the documentation hierarchy. 6. If you are reviewing documentation quality, compare the page title in the sidebar with the page heading on the page. Consistent naming makes it easier for readers to move between guide pages and API pages without confusion. 7. If the page is not the one you need, return to the sidebar and move sideways within the same group before jumping to a completely different section. This approach is especially helpful when you are reviewing generated documentation after updates. Instead of treating the documentation as one long list, use the structure Atloria already provides: top-level section, grouped reference area, then page-level confirmation. That keeps browsing predictable for both internal reviewers and public readers. For more page-reading patterns, see [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages). ## Common issues when browsing documentation and how to fix them When technical documentation and API reference content are spread across project and public views, a few browsing problems come up repeatedly. Most of them can be solved by checking the page’s location in the documentation structure and confirming how the content is being presented. 1. **An API reference page appears in the project view but not in the public view.** First, confirm that you are looking at the published documentation site rather than the project workspace. If the page exists inside the project but not publicly, review the publication or visibility setup for that generated documentation. A page can be available for internal review before it is visible to public readers. 2. **Readers cannot tell whether they are on a guide page or an API reference page.** Check the page title, breadcrumb trail, and left navigation label. A clear naming pattern helps readers understand whether they are reading explanatory content or generated reference content. If nearby pages use inconsistent labels, update the surrounding documentation structure so the distinction is easier to spot. 3. **Links between technical content and API pages feel incomplete.** Open the guide page and look for in-page links to the related API reference entries. Then check the API navigation group to make sure the target page is easy to find from the sidebar as well. Readers should be able to move both ways: from guide to reference and from reference back to the broader section. 4. **Reference pages seem to be in the wrong group or out of order.** Review the navigation hierarchy and compare page placement across project and public views. If a resource, version, or schema page appears under the wrong section, the documentation structure likely needs adjustment so grouped reference pages stay together. [SCREENSHOT: Example of breadcrumb trail and sidebar used to verify page location and type] If you are troubleshooting visibility or review context, the admin-facing areas in Atloria may also help you confirm what is available for readers. Related background is covered in [Using the Admin Workspace](doc:using-the-admin-workspace), [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls), and [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Overview This guide focuses on the reading experience for generated technical documentation in Atloria. The main goal is to help you move confidently between technical guide pages and generated API reference pages, whether you are working inside a project workspace or reviewing the published documentation site. The key ideas are straightforward: - Generated technical documentation can be read in both **project** and **public** views. - The same reference content may appear in both places, but the surrounding navigation and controls are different. - Technical guide pages and API reference pages usually sit next to each other in the documentation structure, so readers can move from explanation to detailed reference without leaving the documentation flow. - Page titles, breadcrumbs, sidebar groups, parameter sections, and response blocks help you quickly identify what kind of page you are viewing. This guide does not repeat the deeper page anatomy already covered in [Browsing Technical Documentation and Entity Reference Pages](doc:browsing-technical-documentation-and-entity-reference-pages). Instead, it concentrates on navigation: how to enter the documentation from different views, how to switch between page types, and how to find the right page faster when the documentation set grows. You will also find practical fixes for common browsing problems, such as a page showing up in a project but not in the public site, unclear page labeling, missing cross-links, or reference groups that feel out of order. These are common review tasks when teams are checking generated documentation before or after publication. If your job involves reviewing technical docs for clarity, this guide is especially useful because it shows how readers actually move through Atloria’s documentation structure rather than only describing what each page contains. ## Prerequisites Before using the steps and browsing patterns in this guide, make sure the following basics are already in place: - You can sign in to Atloria and open the relevant workspace. If needed, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). - You have access to a project that already contains generated technical documentation or API reference content. - If you plan to compare project and public views, the documentation has already been published so the public documentation site is available to read. - You are familiar with the basic project navigation and documentation areas in Atloria. If not, review [Exploring Technical Documentation Inside a Project](doc:exploring-technical-documentation-inside-a-project). - You understand the difference between a guide page and a generated reference page at a basic level. For that foundation, see [Reading API Reference Sections in Technical Documentation](doc:reading-api-reference-sections-in-technical-documentation) and [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation). It also helps if you already know why you are browsing the documentation. For example, you might be: - Checking whether published API pages match the project version - Verifying that guide pages link to the correct reference pages - Reviewing page organization before sharing documentation with readers - Comparing how the same content appears internally and publicly The next document in this sequence is [Browsing Entity Reference Pages and Related Details](doc:browsing-entity-reference-pages-and-related-details), which goes deeper into reading linked reference details once you have reached the right page. ## Understanding version workspaces and where status appears In Atloria, a version workspace is the working area for one documentation version inside a project. This is the screen your team opens when you need to review the current version label, check whether the version is still being edited, or confirm whether it has already moved into review or release. The most useful cues are usually at the top of the workspace: the workspace header, the version identifier, and the status badge. Together, these let you understand the state of the version without opening separate review screens. You will also see status information repeated in other places so you can track progress from list views. Teams commonly open a workspace from a version list, from a version or document detail page, or from a release tracking view that shows several versions together. In each of these places, the current status helps you decide what to do next. For example, a workspace that still shows an editable working state is usually where a writer continues updating content, while a workspace marked as review-ready signals that the version should be checked before release. A released state tells the team that the version has already reached its publication milestone. Different roles look at the same workspace for different reasons: - **Technical Writers** focus on whether the workspace is still open for editing. - **Documentation Managers** look for review-ready versions and confirm whether the status matches the actual review stage. - **Project Administrators** use the status badge and version label to watch release timing across multiple versions. If you need a refresher on how the workspace itself is organized, see [Understanding Documentation Version Workspaces](doc:understanding-documentation-version-workspaces). [SCREENSHOT: version workspace header showing version label and status badge] ## Moving a workspace through its status progression 1. Open the version workspace from the version list, the version detail page, or a release tracking view. 2. Look near the top of the workspace for the current status control. Depending on the screen, this may appear as a **Status** dropdown, an action menu, or a workflow button that lets you move the version to its next stage. 3. Review the current state before making a change. In most teams, the normal progression is: - an active editing state while content is still being updated - a review-ready state when the draft should be checked - a released or release-tracked state when the version is approved for release monitoring or has already been released 4. Choose the next status that matches the work that has actually been completed. For example: - Move from the editable state to a review-ready state when the pages, screenshots, and version content are ready for review. - Move from review-ready to a released or tracked release state when review is complete and the version should be treated as part of the release process. 5. Confirm any prompts that appear. Atloria may prevent the change if required workflow conditions have not been met or if your role does not allow that transition. If a required action is missing, finish the missing work first or ask someone with the right access to complete the change. After the update is accepted, the new status should appear right away in the workspace header. You should also see the same updated status in version lists and release tracking views. That immediate visibility is important because it tells the rest of the team that the handoff has happened. If you are managing timing and readiness across several versions, pair status updates with the guidance in [Managing Project Version Timelines and Status Decisions](doc:managing-project-version-timelines-and-status-decisions). [SCREENSHOT: status dropdown or workflow action in a version workspace] ## Comparing workspace versions from the available entry points 1. Start from the place where you already see the version you want to review. In Atloria, comparison tools are typically reached from: - a compare action on a workspace record - row actions in a version list - release tracking views that let you open a comparison directly from a tracked version 2. Select the versions you want to compare. Atloria may present these as source and target selectors, a baseline and current version choice, or side-by-side compare controls. Choose carefully: - Use the earlier or released version as the baseline when you want to measure what changed. - Use the current workspace as the target when you want to review the latest edits. 3. Open the comparison view and review the differences shown on screen. This view is most useful when you need to answer practical release questions, such as whether the version includes only expected updates or whether important pages changed since the last approved version. 4. Use the results to decide what should happen next. Comparison views help teams spot: - changed pages - modified content - differences between the current workspace and a released version For Technical Writers, the comparison view is a final check before moving the workspace into review. For Documentation Managers, it is often the fastest way to confirm whether a review-ready version is complete enough to advance. For Project Administrators, it helps explain why one version may still be held back while another is ready for release tracking. If you need more detail on reading compare results, use [Working with Version Comparison Views](doc:working-with-version-comparison-views) and [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). [SCREENSHOT: version comparison screen with source and target selectors] ## Tracking releases across workspaces and versions The release tracking view gives you a higher-level way to monitor multiple version workspaces at once. Instead of opening each workspace one by one, you can use this screen to scan version labels, current statuses, and release-related details together. This is especially useful when several versions are moving through editing, review, and release at the same time. In Atloria, release tracking typically presents versions in a grid or similar overview. Teams use the visible columns and status indicators to answer three questions quickly: which versions are still being worked on, which are waiting for review, and which are already released. When release-related fields are shown alongside the version label and status, you can judge readiness more accurately than by status alone. Common items users look for in the release tracking view include: | What to check | Why it matters | |---|---| | **Version label** | Confirms which release or documentation version you are reviewing | | **Status indicator** | Shows whether the workspace is still active, ready for review, or released | | **Release-related date or milestone information** | Helps you line up documentation work with the release schedule | Project Administrators and Documentation Managers often narrow the list with filters or sorting so they can focus on versions that are in review, blocked, or already released. Grouped views are especially helpful when you need to separate active work from completed releases. The release tracking view also acts as a navigation hub. When you spot a version that needs attention, open that record to jump back into the individual workspace. From there, you can update the status, review the version details, or launch a comparison. That connection between the high-level release view and the detailed workspace keeps status management practical instead of purely administrative. [SCREENSHOT: release tracking view with version labels, statuses, and release-related columns] ## Using statuses and release views to coordinate team responsibilities Statuses are most useful when everyone on the team treats them as shared signals rather than personal notes. In Atloria, the workspace state tells each role when to act and when to wait. That makes handoffs cleaner, especially when writers, reviewers, and release owners all work in the same project. A common responsibility pattern looks like this: - **Technical Writers** - Work mainly in workspace detail pages - Keep the version in an active editing state while content is still changing - Use comparison views before handing work off for review - **Documentation Managers** - Watch for workspaces that move into a review-ready state - Open comparison views to confirm what changed - Decide whether the version is ready to continue through the release process - **Project Administrators** - Use release tracking views to monitor several versions at once - Check whether version statuses match release timing - Focus on versions that are blocked, late, or already released The screens each role checks most often usually follow that same pattern: - workspace detail pages for editing and direct status updates - comparison views for review decisions - release tracking dashboards for schedule oversight Consistent status updates improve team coordination because they remove guesswork. A writer does not need to message a manager to say a draft is ready if the workspace clearly shows a review-ready state. A manager can see when a version is awaiting approval. An administrator can identify which versions belong to the active release window. Access can also affect what each person can do. Some users may be able to open workspaces and compare versions but not change the status. Others may be able to manage release tracking records or move versions into release states. If an option is missing, it is often related to role permissions rather than a problem with the version itself. For broader role setup, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Fixing common issues with status changes, comparisons, and release visibility When a version does not behave the way you expect, start by checking the screen you are on and the exact version you opened. Most problems with status changes, comparisons, and release tracking come from permissions, filters, or selecting the wrong version. - **The status control is unavailable or a transition option is missing** - Confirm that your role is allowed to update version status. - Check whether the workspace still needs a required workflow step before the next status becomes available. - If the version appears locked or unavailable for editing, reopen the workspace and verify that the record is not being held by another process. - **The compare view does not show the differences you expected** - Make sure you selected the correct source and target versions. - If the comparison is between a current workspace and an earlier version, confirm that you chose the right baseline. - Save your latest changes before opening the comparison again. Unsaved edits may not appear in the results. - **A workspace does not appear in release tracking** - Clear or adjust active filters in the release tracking view. - Confirm that you are looking at the correct project and version set. - Check whether the workspace status qualifies it to appear in the release view you are using. - **Release tracking shows an outdated status** - Refresh the workspace and confirm the status change was saved. - Return to the release tracking screen and refresh that view as well. - If the workspace header shows the new status but the release view does not, reopen the version from the tracking list to verify the latest record. When the issue is specifically about review progression, [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up) can help you tell the difference between a blocked workflow and a simple status mismatch. ## Overview Atloria gives you several connected ways to manage documentation versions as they move toward release. The version workspace is where you check the version label, review the current status badge, and make status changes when the draft is ready to move forward. Version lists and release tracking views extend that same information across multiple records so you can monitor progress without opening each workspace individually. The most important habit is to treat the workspace status as the shared signal for the whole team. Writers use it to show when editing is still active. Documentation Managers use it to identify versions that are ready for review. Project Administrators use release tracking views to line up version status with release timing. Because Atloria repeats status information in workspace headers, list rows, and release tracking screens, one update can immediately improve visibility for everyone involved. Comparison tools are the bridge between editing and release decisions. When you open a compare action from a workspace, a version list, or a release tracking record, you can review what changed between the current workspace and another version. That makes it easier to decide whether the version should stay in editing, move into review, or advance toward release. If you are working through the full version workflow, this guide fits best alongside: - [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) - [Coordinating Version Work Before Release](doc:coordinating-version-work-before-release) - [Understanding Documentation Version Workspaces](doc:understanding-documentation-version-workspaces) Use those guides when you need more detail on list-level management, release coordination, or the workspace layout itself. ## Prerequisites Before you manage workspace statuses and release tracking in Atloria, make sure the following pieces are already in place: - You can sign in to your Atloria account and open the main project area. If you need help getting into your account, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). - You already have access to a project that contains documentation versions. This guide assumes you can open version workspaces from project views, version lists, or related release tracking screens. - At least one version workspace already exists. If your team is still creating versions, review [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) or [Generating Documentation Versions for Release Cycles](doc:generating-documentation-versions-for-release-cycles). - You understand the basic layout of a version workspace, including where the version identifier and status badge appear. If that screen is still unfamiliar, read [Understanding Documentation Version Workspaces](doc:understanding-documentation-version-workspaces). - Your role includes the actions you need. Depending on your permissions, you may be able to view a workspace but not change its status, open comparison tools, or manage release tracking records. If access seems limited, check with your Atloria administrator and review [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). - Your team has agreed on how statuses are used for editing, review, and release. Atloria can show the current state clearly, but the status labels only help if everyone uses them consistently. If you are continuing through the Documentation Versions set, the next useful step is usually to return to your project and apply these status and tracking checks to the versions currently moving through review. ## Defining an audience strategy before you structure project content Before you build a page tree in Atloria, decide whether your project really needs audience targeting. Use audiences when readers need meaningfully different guidance, such as separate instructions for internal staff, customers, partners, or region-specific readers. If most readers follow the same workflow and only a few words change, keep one shared content path instead of splitting pages too early. That keeps navigation simpler and reduces extra review work later. Start with the reader groups you already identified in [Planning Audience Targeting for Documentation Projects](doc:planning-audience-targeting-for-documentation-projects), then turn those groups into concrete labels you will use inside the project. Good labels are short, specific, and stable. For example, choose one label and keep using it everywhere rather than mixing similar names in page discussions and planning notes. If your team says “Customers” in one place and “External Users” in another, it becomes harder to tell which pages belong together. As you plan, separate content into three buckets: - **Shared pages** for information every reader needs - **Audience-specific pages** for workflows, rules, or wording that truly differ - **Audience-specific sections** inside a shared page when only a small part changes This is the point where you prevent duplicate maintenance. If setup steps, screenshots, and outcomes are the same for all readers, keep them on one page. If the task changes by role, region, or entitlement, plan targeted content from the start. A simple planning table helps before anyone creates pages: | Audience label | Typical readers | Content type | |---|---|---| | Internal Staff | Support, operations, onboarding teams | Internal-only procedures | | Customers | End users of the product | Public help content | | Partners | Resellers, implementation partners | Partner workflows | | Region-specific readers | Readers in a specific market | Local policy or process differences | [SCREENSHOT: project planning notes showing audience labels matched to reader groups] ## Preparing your project so audience targeting stays manageable Once your audience labels are clear, confirm who is allowed to manage them in the project. In Atloria, audience planning works best when a small group owns the rules. The **Project Administrator** should control final audience setup and publishing decisions, while Technical Writers and Documentation Managers can prepare page structure, draft content, and flag pages that need audience review. If your team already uses approval steps for versions or content review, include audience assignment in that same process instead of treating it as an afterthought. Next, review the existing page tree in the project workspace. Look for sections that should stay visible to everyone, such as general introductions, shared setup steps, or common troubleshooting. Then mark sections that should be limited to a specific audience. Be careful with duplication: only create parallel branches when the wording, workflow, or policy actually changes. If two pages differ by one note or one screenshot, that is usually a sign the content should stay shared. Create a lightweight audience matrix before you reorganize anything. This does not need to be formal, but it should answer four questions for each audience: | Audience | Main page collections | Navigation label or section | Content owner | |---|---|---|---| | Internal Staff | Internal operations pages | Internal Guides | Documentation Manager | | Customers | Product help pages | Help Center | Technical Writer | | Partners | Enablement pages | Partner Docs | Partner documentation owner | This matrix gives your team one place to check where pages belong and who updates them. Finally, agree on review checkpoints for new content. For example: - New pages must be checked for audience assignment before they move forward for publication - Shared parent pages must be reviewed when new audience-specific child pages are added - Documentation Managers should confirm that navigation labels still make sense for every audience [SCREENSHOT: project content tree beside a simple audience ownership matrix] ## Applying audience targeting to pages and navigation When you start applying audiences in Atloria, begin with the content structure rather than the page title. Open the project’s content area and identify the parent section where audience-specific pages should live. This parent section should make sense even before a reader opens any child page. For example, a shared section can hold common overview content, while child pages underneath it can be assigned to different audiences when the task changes by reader type. Do not rely on page titles alone to tell readers who a page is for. A title like “Setup Guide” is too broad if multiple audiences need different instructions. Instead, use the page settings to assign the intended audience to each targeted page. The audience setting controls who should see that page, while the title should stay clear and readable in navigation. This combination is much more reliable than trying to signal audience only through naming. After assigning audiences, check the navigation tree carefully. You want each audience to see a clean path, not a structure filled with branches that lead nowhere. Review whether a shared parent page still makes sense when some child pages are hidden. If a parent page introduces three child pages but one audience can only see one of them, rewrite that parent page so it does not promise content the reader cannot access. Use this pattern when it helps: 1. Create a **shared parent page** for common background or entry guidance. 2. Add **audience-specific child pages** only where workflows truly split. 3. Review the navigation tree as each audience to confirm the branch still feels complete. 4. Rename sections if the path looks confusing or too broad. Avoid forcing readers through irrelevant content just to reach the page meant for them. [SCREENSHOT: page tree with a shared parent page and audience-specific child pages] ## Designing content patterns that prevent duplicate or conflicting guidance The easiest way to lose control of audience-targeted content is to copy the same instructions into several pages and edit them separately over time. In Atloria, plan content so shared guidance lives in one place, and only the differences are targeted. That usually means keeping baseline instructions together, then adding audience-specific variations only where the workflow, terminology, approvals, or prerequisites actually change. A useful decision point is whether the audience difference is small or large. If the page is mostly the same and only one section changes, keep one page and target only the section that differs. If the entire task changes from start to finish, create separate pages for each audience. This keeps readers from scanning through instructions that do not apply to them. Use the following approach when deciding between one page and multiple pages: | Situation | Better pattern | |---|---| | Same task, small wording differences | One shared page with audience-targeted sections | | Same task, different prerequisites or warnings | One shared page with clearly separated audience-specific sections | | Different workflow, different outcomes | Separate audience-specific pages | | Different terminology across the full page | Separate audience-specific pages | Keep titles, headings, and navigation labels aligned across variants. If one audience sees “Getting Started” and another sees “Initial Setup Process” for the same stage of work, readers and reviewers may think those are unrelated topics. Parallel pages should look intentionally connected. Ownership matters just as much as structure. For every audience-specific branch, decide who updates it. If one writer owns customer pages and another owns partner pages, make that explicit in your planning notes or review process. Otherwise, one branch gets updated while another quietly becomes outdated. [SCREENSHOT: two parallel pages with matching titles and clearly separated audience-specific content] ## Reviewing the public experience before you publish audience-targeted content Before you publish, review the project from the reader’s point of view rather than from the editor’s page tree. In Atloria, preview the documentation as each intended audience and walk through the visible navigation, landing pages, and links exactly as that reader would. This step often catches issues that are easy to miss while editing, especially when shared pages link into targeted branches. Start with the main navigation. Check whether each audience sees a complete and sensible page tree. A public reader should not land on a parent page that describes options they cannot open. If a section contains audience-limited child pages, make sure the shared introduction still reads naturally when some of those child pages are hidden. Then review links inside pages. Inline links, related content blocks, and “read next” style references can accidentally point to pages that are not visible to every reader. That creates a confusing public experience because the page appears to promise more information than the reader can reach. Remove or replace those links on shared pages if they only make sense for one audience. Search and browse paths also need attention. A title that is clear to your team may be misleading in public navigation if the page is hidden for some readers. Check that visible titles describe what the current audience can actually access. Use this review flow before publishing: 1. Preview the project as each planned audience. 2. Open the landing page and follow the main navigation path. 3. Test links inside shared pages and section introductions. 4. Confirm that hidden pages do not leave empty or misleading branches. 5. Adjust titles or parent-page wording where needed. For broader publishing checks, continue with [Applying Audiences to Public Documentation Experiences](doc:applying-audiences-to-public-documentation-experiences). [SCREENSHOT: public documentation preview showing different navigation for different audiences] ## Fixing common audience targeting problems in live projects Audience issues often show up after content has already been published, especially when several people are editing the same project. When that happens, fix the structure first, then update the wording. In Atloria, most reader confusion comes from the page being in the wrong place, the wrong audience being assigned, or shared content pointing into a restricted branch. If a page appears in the wrong navigation path, open that page and check two things: its assigned audience and its parent section. A correctly targeted page can still confuse readers if it sits under a section that suggests a different audience. Move it to a more suitable parent if needed, then review the navigation again from the reader view. If readers say instructions are missing, look for required steps that were placed on an audience-limited child page instead of a shared page. Core steps that everyone needs should stay on the shared page. Reserve child pages for audience-only variations, exceptions, or role-specific actions. If public readers see confusing links or labels, clean up the shared entry pages. Remove references to pages that only some audiences can see, and rewrite navigation labels so they describe the visible branch accurately. When teams are maintaining too many near-duplicate pages, consolidate them. Keep one shared page for the common workflow, then move only the real differences into targeted sections or separate audience pages. A practical troubleshooting checklist: - **Wrong page location:** review parent section placement - **Wrong visibility:** review the page’s audience assignment - **Missing shared steps:** move common instructions to a shared page - **Confusing public links:** remove restricted references from shared pages - **Too many duplicates:** merge common content and keep only true differences separate [SCREENSHOT: page settings and navigation tree used to correct audience placement] ## Overview Planning audience targeting for project content in Atloria is mainly about making the page tree easier to manage before your team creates too much parallel content. The goal is not to split every topic by reader type. The goal is to decide where targeted content genuinely improves the reading experience and where shared content is the better choice. A strong plan usually includes four decisions: - which audience labels the project will use - which sections stay shared for all readers - which pages need audience-specific visibility - who reviews and maintains each targeted branch This document focuses on content planning inside a project, not on creating audience definitions from scratch or setting organization-wide audience rules. For those topics, use [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). If you need help shaping the overall strategy before touching the page tree, return to [Planning Audience Targeting for Documentation Projects](doc:planning-audience-targeting-for-documentation-projects). Use the guidance here when you are: - reorganizing a project’s documentation structure - deciding whether to split one topic into multiple audience pages - reviewing navigation before publishing - cleaning up a live project with confusing audience paths The most effective audience plans in Atloria keep shared guidance centralized, use page-level targeting deliberately, and test the public reading experience before release. That approach reduces duplicate maintenance and gives each reader a clearer path through the documentation. ## Prerequisites Before you plan audience targeting for project content in Atloria, make sure these pieces are already in place: - You can open the project workspace and view its content structure. - Your team has already identified the audiences the project needs to support. - Someone with **Project Administrator** responsibility is available to confirm audience rules and publishing decisions. - Writers and reviewers agree on who owns shared pages and who owns audience-specific branches. - You have reviewed the earlier planning guidance in [Planning Audience Targeting for Documentation Projects](doc:planning-audience-targeting-for-documentation-projects). It also helps to gather a few working materials before you start restructuring pages: - the current page tree or section list - a list of reader groups such as internal staff, customers, partners, or region-based readers - notes on which pages are public, internal, or mixed - any existing review or approval checkpoints your team already uses If your project already contains published content, plan to test changes in preview before making broad structural updates. That is especially important when shared pages contain links to child pages that may only be visible to certain audiences. You do not need advanced setup to use this guide, but you should already be comfortable with: - navigating between project pages - editing page organization - reviewing page settings - checking how documentation appears before publication After your content plan is in place, the next step is to validate how those audience decisions appear in the published experience in [Applying Audiences to Public Documentation Experiences](doc:applying-audiences-to-public-documentation-experiences). ## Checking which version you are preparing to share Before you change any sharing or export setting in Atloria, open the version you plan to distribute and confirm you are on the correct version record. Start from the project’s versions area, open the version details view, and look at the version name first. This is the quickest way to catch cases where you are still viewing an older release or a working draft with a similar label. Next, check the status badge shown on the version record. If the badge shows a draft or another non-final state, pause before sharing it outside your team. If you expected to share a published or release-ready version, the badge should match that expectation. Also review the last updated timestamp so you can tell whether the version was changed recently. A recent update may mean content was still being edited after your last review. If Atloria shows who last worked on the version, use that information to confirm whether another editor may still be making changes. This matters when you are preparing a share link or export for customers, stakeholders, or internal reviewers. You do not want to send a version that changes again a few minutes later. Pay close attention to any labels or indicators related to sharing or export readiness. If the version already shows an access badge, visibility label, or export-related marker, compare that with your intended outcome before making changes. 1. Open the project and go to the version you want to share. 2. Confirm the version name in the version details view. 3. Check the status badge and last updated timestamp. 4. Review whether the version appears to be current, draft, or previously published. 5. Look for any sharing, visibility, or export indicators already attached to that version. [SCREENSHOT: Version details view showing version name, status badge, last updated timestamp, and visibility label] If you need a refresher on validating a version before release, use [Validating Version Access Before Public Release](doc:validating-version-access-before-public-release) before continuing. ## Setting version visibility and access rules Once you have confirmed the correct version, open its settings or sharing area and review the visibility control. In Atloria, this is where you decide whether the version stays private, is limited to a defined audience, or can be shared more broadly. Make this choice carefully, because the visibility state affects both the link behavior and what different readers can open. When you switch the version to a more shareable state, open the sharing dialog and review the available access options. Focus on who can open the version link and whether readers must sign in first. If the version is meant only for internal review, keep sign-in requirements in place. If the version is intended for external readers, make sure the selected access option matches that goal. Also review the permission labels shown in the same area. Atloria may distinguish between viewers, editors, and administrators. These labels help you confirm that people receiving the version will only have the level of access you intend. A reader who only needs to view the content should not receive editing access by mistake. After making changes, save them and watch for confirmation in the interface. This may appear as a success message, an updated access badge, or a changed visibility label on the version record. Do not assume the change applied until you see that confirmation. 1. Open the selected version’s settings or sharing panel. 2. Choose the correct visibility state for the version. 3. In the sharing dialog, review who can open the link. 4. Confirm whether sign-in is required. 5. Check the permission labels for viewers, editors, and administrators. 6. Save the changes and verify the updated badge or success message. A good follow-up here is [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) if you need more help choosing the right access state. ## Reviewing what readers will actually be able to see After saving access settings, switch from the editing view to the reader-facing preview. This step is essential because the version details screen may still show information that regular readers will never see. In Atloria, the preview helps you compare your working view with the final shared experience. Look through the version page by page and confirm that hidden sections stay hidden. If your team uses internal notes, draft-only blocks, or unpublished edits, make sure they do not appear in the reader preview. This is especially important when a version has been reviewed by multiple people and still contains comments or internal-only material that should not leave the project workspace. Check attachments, embedded media, and linked content one by one. A page may look correct at first glance, but a linked file or embedded item might still reveal something you did not intend to share. Open those items from the preview rather than from the editor so you can confirm the reader experience, not the author experience. If your team shares versions with both internal and external readers, test both outcomes. A signed-in team member may be able to open more content than an external reader using the same link. Compare those experiences so you know exactly what each audience will see. 1. Open the reader preview or shared-view preview for the version. 2. Compare the preview with the editing view. 3. Confirm hidden sections, internal notes, and unpublished edits are excluded. 4. Test attachments, embedded media, and linked content from the preview. 5. Check how the version appears for internal signed-in users and external readers. [SCREENSHOT: Reader preview beside the editing view, highlighting hidden content and visible shared content] For a broader explanation of reader outcomes, see [Understanding Version Access Modes and Reader Outcomes](doc:understanding-version-access-modes-and-reader-outcomes). ## Confirming export output matches the version you intend to distribute If you plan to send a file instead of a link, open the export options directly from the version you selected earlier. The most common mistake at this stage is exporting from the wrong version, especially when a newer draft exists alongside the version you actually want to distribute. Before generating anything, confirm the export source is the same version name you already reviewed. Next, check the export settings shown on the export screen. Pay attention to which sections are included, what file format you are generating, and whether restricted or hidden content is excluded. If the export options show any inclusion choices, review them carefully instead of accepting them automatically. Generate a test export before sending the final file. Open the exported file and compare it with the version preview inside Atloria. Check the title, headings, section order, and visible content blocks. If the export does not match the preview, return to the export options and review the source version and content inclusion settings again. Do not stop at the first page. Scroll through the full file and inspect images, attachments, and formatting. A version can look correct in preview but still produce an export with missing assets, unexpected internal content, or layout changes that affect how recipients understand the material. 1. Open **Export** from the selected version. 2. Confirm the export source matches the intended version. 3. Review included sections, file format, and restricted-content handling. 4. Generate a test export. 5. Compare the exported file with the version preview. 6. Check for missing assets, internal-only content, or formatting problems. If you need more detail on export decisions, use [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). ## Using access outcomes to decide whether the version is ready At this point, use the results of your testing to decide whether the version is truly ready to share. In Atloria, the most useful signals are the access outcomes you see during preview and link testing. These outcomes may appear as messages such as **can view**, **access denied**, **sign-in required**, or a restriction tied to permissions. Treat each outcome as a clue. If a reader can view the version successfully, the current visibility and sharing settings are likely aligned. If the screen shows **sign-in required**, the version may still be limited to authenticated users. If you see **access denied**, the issue may come from the selected visibility state, the share link scope, or the reader’s permission level. If content is missing even though the page opens, the cause may be unpublished material or hidden sections rather than a broken link. Where possible, test with more than one account or role. Compare how a Documentation Manager and a Project Administrator experience the same version. This helps you catch cases where internal reviewers can see content that external readers cannot, or where a version appears ready only because you tested it with elevated access. Use a short readiness check before release: | Check | What to confirm | |---|---| | Version selected | The version name matches the one you intend to share or export | | Visibility confirmed | The access badge and sharing settings match the intended audience | | Preview reviewed | Reader preview excludes hidden, draft, and internal-only content | | Export validated | Test export matches the preview and contains only intended material | If any one of these checks fails, revise the settings before distributing the version. For related testing guidance, see [Managing Version Access and Sharing Outcomes](doc:managing-version-access-and-sharing-outcomes). ## Fixing common sharing and export mistakes before release Most release problems come from a small set of avoidable mistakes. If a shared link opens the wrong content, return to the share dialog and verify which version was selected when the link was created. It is easy to copy a link from another version, especially when you have several versions with similar names. Open the version details view again and compare the version name against the link you plan to send. If readers see less or more content than expected, compare the reader preview with the editing view. Check whether some sections are hidden, still unpublished, or only visible to certain roles. This is often the reason a team member says “it looks fine for me” while an external reviewer reports missing content. When an export includes internal-only material, go back to the export options and review the inclusion settings. Then confirm the file was generated after the final visibility state was saved. If you changed access rules after creating the file, the export may no longer reflect the current version settings. If an external user cannot open the version at all, review the sign-in requirement and any restricted audience settings attached to the share link. Also confirm that the link you sent is still the active one for that version. - **Wrong version shared** - Reopen the version record and confirm the version name. - Create or copy the link again from that exact version. - **Unexpected content visibility** - Compare editor view and reader preview. - Recheck hidden content, unpublished edits, and role-based access. - **Export shows internal material** - Review export inclusion choices. - Generate a fresh export from the intended version. - **External reader blocked** - Check whether sign-in is required. - Confirm the version is allowed for the intended audience. - Verify the shared link is still active. Use [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness) if you need to revisit the setup behind these issues. ## Overview Preparing a version for sharing or export in Atloria means checking more than just the content itself. You need to confirm that the correct version is selected, that its visibility settings match the audience, that the reader preview shows only the intended material, and that any exported file matches what readers are supposed to receive. This document focuses on that final preparation step before you distribute a version outside the editing workspace. The process usually starts in the version details view, where you confirm the version name, status badge, and recent update information. From there, you move into the sharing or settings area to review visibility and sign-in requirements. After that, you test the reader-facing preview and, if needed, generate a test export to compare the file against the on-screen version. This guide does not repeat the earlier validation work covered in [Validating Version Access Before Public Release](doc:validating-version-access-before-public-release). Instead, it helps you turn those checks into a final go-or-no-go decision for sharing links and exported files. It is especially useful when you are preparing a release for customers, internal stakeholders, or a mixed audience that includes both signed-in and external readers. Use this guide when you are close to release and need to answer practical questions such as: - Are you sharing the right version? - Will readers see only the content intended for them? - Does the export match the approved version? - Do internal and external readers get the expected result? In Atloria, these final checks help prevent outdated links, incorrect permissions, and exports that reveal draft or internal-only material. ## Prerequisites Before you work through the sharing and export checks in this guide, make sure you already have the right version open in Atloria and that the version is far enough along in the release process to test meaningfully. You do not need every release task to be finished, but you should be beyond early drafting and close to a version that could realistically be shared. You should have: - Access to the project and its versions area - Permission to open the version details view - Permission to change sharing settings or open the sharing dialog - Permission to run or review exports for that version - A version that has content ready for preview and access testing It also helps if you have already completed the earlier validation work in [Validating Version Access Before Public Release](doc:validating-version-access-before-public-release). That earlier step is where you confirm the version is suitable for release. This guide assumes you are now focused on the final sharing outcome rather than basic release readiness. For the smoothest review, gather these items before you begin: - The exact version name you intend to distribute - The intended audience for the version, such as internal readers or external readers - A clear decision on whether readers should sign in - A plan for whether you will share a link, an export, or both - If possible, access to another user account or role for testing reader outcomes If your team manages version access across several releases, you may also want the related guidance in [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export) nearby while you work. ## Opening a project's audit history and understanding what each entry shows In Atloria, start from your project workspace and open the project you want to review. From there, go to the area that shows project activity, audit history, or related change records for that project. The goal is to work from the project itself so the activity you review stays tied to the correct documentation set, approvals, and release work. When the audit list opens, read each row as a record of one change. Most audit views are easiest to review when you focus on a few core details first: | What to look at | What it tells you | |---|---| | Timestamp | When the change happened | | User | Who made the change | | Action | What happened, such as created, updated, approved, or changed status | | Record or item | Which project item was affected | | Changed field or values | What was changed, including before and after details when available | Project-level activity usually covers changes to the project itself, such as project details, settings, or release-related updates. Related record activity covers items connected to that project, such as document edits, metadata changes, approval actions, or version-related updates. When you are preparing for export, this difference matters because some entries explain overall project decisions, while others prove that a specific document or approval step happened. Open a row, expand it, or use the details panel when you need the full context for one entry. That detailed view is where you can confirm whether the change is meaningful for release review or compliance evidence. If you already worked through release checks in [Using Audit Records for Release and Approval Checks](doc:using-audit-records-for-release-and-approval-checks), use that same decision-making approach here, but stay focused on what must be included in an export set. [SCREENSHOT: Project audit history list showing timestamp, user, action, affected item, and expanded change details] ## Filtering audit activity to find release-critical and compliance-relevant records Once you are in the audit history view, narrow the list before you review it in detail. A full project history can include routine edits that are useful for traceability but not important for a release package or compliance export. Filtering helps you isolate the records that matter. 1. Set the **date range** first. Use it to match the release window, approval cycle, or reporting period you are reviewing. This is the fastest way to remove older activity that does not belong in the current export. 2. Apply filters for **user**, **action**, or **record type** if those options are available. For release readiness, focus on actions such as approvals, status changes, document revisions, and controlled edits. For compliance review, include entries that show who changed what and when. 3. Use the search box to find a specific **project name**, **document title**, or **field label**. This is especially helpful when you need to confirm one missing approval, one corrected field, or one document revision. 4. Review the filtered results before moving on. Make sure the list now reflects the activity window and record types you actually need. A good filtered view often includes status transitions, approval actions, document updates, and key metadata edits, while excluding minor noise. If Atloria lets you keep or reuse a filtered view, use that option for recurring release reviews or scheduled compliance checks. That saves time when the same project needs repeated export validation across multiple versions or approval cycles. If your review is tied to a broader export process, you can pair this step with the export planning guidance in [Managing Audit Exports and Activity Records](doc:managing-audit-exports-and-activity-records). Use that document for export workflow decisions, and use this screen to make sure the underlying audit list is clean before you generate anything. [SCREENSHOT: Audit history filters for date range, user, action, record type, and search] ## Reviewing change details to confirm what must be included in an export workflow After filtering the audit list, inspect the entries that could affect release readiness or compliance evidence. This is the point where you move from “something changed” to “this change must be retained in the export.” 1. Open a change entry and compare the **before** and **after** values. Look for updates that affect controlled project information, release documentation, approval status, or important metadata. 2. Check status-related entries carefully. Changes such as **Draft**, **Review**, **Approved**, **Released**, or **Archived** can be central to proving how the project moved through its release cycle. 3. Review whether the entry references linked items such as documents, attachments, or approval records. If those related items are part of the release evidence, make sure they are represented in the audit history you plan to export. 4. Separate required evidence from informational activity. A field correction, approval action, signoff update, or release-state change usually belongs in the export review. A minor edit with no release or compliance impact may not. This review is easiest when you ask one question for each entry: does this record help prove what changed, who approved it, or why the project was considered ready for release? If the answer is yes, keep it in scope. Be especially careful with approval-related entries. A simple status label can show that something moved forward, but the detailed entry may show who made the decision and when. That extra context is often what downstream reviewers expect to see in an exported audit file. If you need a refresher on interpreting release-related audit records before deciding what to keep, refer back to [Using Audit History for Release Checks](doc:using-audit-history-for-release-checks) or [Reviewing Audit History and Exporting Compliance Records](doc:reviewing-audit-history-and-exporting-compliance-records). Those guides help you judge significance; this step is about turning that judgment into a clean export scope. ## Marking and organizing the audit records needed for release preparation Once you know which entries matter, organize them so the final export is easy to review. In Atloria, this usually starts in the audit list itself by selecting the rows you want to keep in scope for release preparation. 1. Use the row checkboxes or selection controls to mark the audit entries that belong in your release review set. 2. If Atloria shows tags, flags, review markers, or a saved selection option, use them to separate confirmed records from entries that still need follow-up. 3. Group your selected records in a way that matches how the release will be reviewed downstream. Common groupings include project phase, document set, approval cycle, or compliance category. 4. Recheck the selected list to confirm it covers the full story of the project: creation, important revisions, approvals, and final release actions. This organization step is valuable because a long audit export can be hard to read if it mixes unrelated edits together. Even when you plan to export a filtered list, a deliberate selection process helps you avoid missing one critical approval or including a large number of low-value changes. A practical way to review your selection is to scan for milestone coverage. Ask whether the selected entries show: - when the project or document set was created - when important revisions were made - when review or approval decisions happened - when the final release-related action was recorded If one of those milestones is missing, go back to the filters or search tools and locate the missing event before exporting. This is also a good checkpoint to compare your selected records with the release and approval expectations described in [Using Audit Records for Release and Approval Checks](doc:using-audit-records-for-release-and-approval-checks). [SCREENSHOT: Audit history list with selected rows and organized release-relevant entries] ## Preparing audit history for export-oriented workflows After you finish filtering and selecting records, move to the export action from the audit history view. In Atloria, look for an **Export** or **Download** option on the page toolbar or near the audit list controls. Open it only after your filters and selections are final, so the output matches the review you just completed. 1. Open **Export** or **Download** from the audit history screen. 2. Choose the export scope. Depending on the options shown, this may include the **current filtered results**, **selected records only**, or the **full project audit log**. 3. Review the fields included in the export. Pay close attention to whether the output contains **user names**, **timestamps**, **action labels**, **comments**, and **changed values**. 4. Choose the available output format, then generate the file. 5. Open the exported file and compare it with the audit list you reviewed on screen. The most important check is whether the exported file tells the same story as the filtered audit view. If your on-screen review highlighted approval actions, release-state changes, and document revisions, those same entries and columns should appear in the file. If they do not, stop and adjust the export settings before sharing the file with reviewers. This is also where you should confirm the export scope matches the audience. A release reviewer may only need the selected release-critical records, while a compliance reviewer may expect the broader filtered history for a defined period. If you need more guidance on choosing the right export approach, see [Exporting Audit and Version Records](doc:exporting-audit-and-version-records). [SCREENSHOT: Export menu from audit history with scope and field options] ## Fixing missing, incomplete, or misleading audit results before export If the audit list or exported file does not look right, correct it before sending anything out. Most problems come from filters, scope choices, or reviewing the wrong level of activity. 1. If expected events are missing, check the **date range** first. A narrow range can hide the creation event, approval step, or release action you expected to see. 2. Recheck the **project scope** and any **record type** filters. You may be looking only at one kind of activity while the missing event belongs to a related document, approval record, or linked project item. 3. If approval or release actions still do not appear, confirm those steps were completed in the correct project workflow and not in a different linked record. 4. If the export file is missing columns or values, compare the export field choices with the columns visible in the audit history view. 5. If the results include too much noise, tighten the filters to focus on status changes, approvals, and controlled document updates. A misleading export is often caused by mixing useful evidence with routine edits. For example, a large list of minor metadata changes can bury the few entries that actually prove release readiness. When that happens, refine the list and regenerate the file instead of expecting reviewers to sort it out manually. It also helps to compare the audit history screen with your release checklist from earlier review work. If the project should show a revision, an approval, and a release-state change, make sure all three appear before you export. For related troubleshooting patterns, use [Managing Audit Record Exports for Compliance](doc:managing-audit-record-exports-for-compliance) alongside this guide. ## Overview This guide focuses on the final review step before you export project audit history from Atloria. You use the project’s audit history view to confirm that the right activity appears, narrow the list to the correct release or compliance window, inspect individual changes, and prepare a clean export file for downstream review. The emphasis here is not on basic exporting. Instead, it is on making sure the audit history behind the export is complete, relevant, and easy to understand. That includes checking who made a change, when it happened, what was updated, and whether the entry reflects a release-critical event such as a document revision, approval, or status change. This document builds on the earlier Audit Export guides rather than repeating them. Use the earlier documents when you need help with: - choosing export types in [Exporting Audit and Version Records](doc:exporting-audit-and-version-records) - managing export activity in [Managing Audit Exports and Activity Records](doc:managing-audit-exports-and-activity-records) - evaluating compliance-focused output in [Managing Audit Record Exports for Compliance](doc:managing-audit-record-exports-for-compliance) - interpreting release evidence in [Using Audit Records for Release and Approval Checks](doc:using-audit-records-for-release-and-approval-checks) Here, the workflow is narrower: open the project audit history, isolate the right events, confirm the details, organize the records, and export only when the result matches the release or compliance package you intend to produce. This is the last step in the Audit Export set, so it is best used when you are already comfortable moving between project workspaces, release records, and audit-related review screens in Atloria. ## Prerequisites Before you review project audit history for export readiness in Atloria, make sure you have the following: - Access to the relevant **project workspace** - Permission to open the project’s **audit history**, **activity**, or related review screen - A clear release window, approval cycle, or compliance period to use with the **date range** filter - Enough context to recognize the records you are looking for, such as document titles, approval milestones, or release-related status changes - Permission to use the **Export** or **Download** action if you need to generate the file yourself It also helps if you have already completed the earlier review work covered in [Using Audit Records for Release and Approval Checks](doc:using-audit-records-for-release-and-approval-checks). That guide explains how to judge whether an audit entry supports release and approval decisions. In this guide, you apply that judgment to a project-specific audit list and prepare it for export. If your team uses recurring compliance reviews, gather the exact criteria before you start filtering. Typical examples include: - a specific date range - one project or document set - approval-related actions - status transitions tied to release readiness - document revisions or controlled metadata updates Have those criteria ready before opening the audit history screen. That makes it much easier to build a filtered view, verify the right entries, and generate an export that downstream reviewers can use without extra cleanup. ## Preparing the project for a release Before you create a release in Atloria, make sure the project itself is ready. Start from the project workspace and review the project settings that affect publishing, especially the current default version and any website or public documentation options already tied to the project. If the wrong version is marked as the main reader-facing version, your release can go live with the wrong entry point or confuse reviewers who are checking the version selector. Next, confirm that the right people can participate in the release. In Atloria, release work usually involves people with responsibilities such as **Documentation Manager**, **Project Administrator**, and **Technical Writer**. Check the user access area and confirm who can create versions, who can review and approve content, and who can publish to the public documentation experience. If a reviewer is missing access, fix that before the version is generated so approvals do not stall later. For broader access checks, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). Then inspect the draft documentation set itself. Open the page tree and look for pages that are still incomplete, pages with unresolved comments, and pages that have edits that were never finalized. A clean release starts with a clean draft. If you already use a structured publishing flow, keep this aligned with the release coordination steps in [Coordinating Project Publishing From Draft to Public Release](doc:coordinating-project-publishing-from-draft-to-public-release). Before moving on, verify the release inputs you plan to use: | Release item | What to check | |---|---| | **Version label** | Make sure the name matches exactly what readers should see | | **Release date** | Confirm your team is using the correct target release timing | | **Publication scope** | Check which pages, sections, or audiences are meant to be included | | **Source workspace** | Confirm you are releasing from the correct draft or approved content set | [SCREENSHOT: Project workspace showing settings, default version, and release-related controls] ## Updating draft content before versioning Once the project is ready, clean up the draft content that will feed the release. Open the draft pages in Atloria’s document editor and review each page title, description, slug, and navigation label. These details shape how the release appears in menus, search results, and shared links. If a page title changed during drafting but the navigation label did not, fix that now so the published navigation stays clear and consistent. Use the page tree to spot structural changes. Pay close attention to pages that were recently added, moved into a different section, or renamed. A release can look incomplete even when the content is correct if the page tree still contains outdated labels or misplaced pages. If your team has been reorganizing content heavily, compare the current tree against the intended reader journey and make sure the landing pages still point readers into the right sections. Review feedback is just as important as the page text. Open pages that show comments, review markers, or approval indicators and resolve anything that should not carry into the release candidate. If a page still has open discussion about wording, screenshots, or missing steps, settle that before creating the version. For more detailed review workflows, use [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) and [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up). Finish by checking links and assets inside the draft. Open key pages and test internal links, screenshots, and references to version-specific material. Watch for links that still point to older versions, draft-only pages, or outdated section names. If you use screenshots in release content, this is a good point to verify they are current and available in the right project context. 1. Open the draft page from the page tree. 2. Update the page content and metadata fields. 3. Check comments and approval markers on the page. 4. Test links, screenshots, and references. 5. Repeat for all pages included in the release. [SCREENSHOT: Draft page open in the document editor with page tree, metadata fields, and comments visible] ## Generating the release version When the draft is ready, move to the version area in Atloria and start the version creation workflow. Use the project’s release controls to create a new version, then enter the version name exactly as it should appear to readers in the version selector. This is not just an internal label. It becomes part of how teams and public readers identify the release, so check the spelling, numbering, and formatting carefully before you continue. Atloria may let you choose the source for the new version. Depending on how your team works, that source may be the current draft workspace or an already approved documentation snapshot. Choose the source that matches your release plan. If your team completed a formal review cycle, use the approved content source rather than a draft that may still contain late edits. If you need help deciding between active draft content and a locked review state, refer to [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle). As you continue, review what Atloria is carrying into the new version. The version creation process copies the page structure, navigation setup, and page details that define the release. This is the point where writers should understand what is being frozen into the release version and what remains editable in the ongoing draft workspace. That distinction matters when someone notices a typo after the version is created—fixing the draft alone may not update the release candidate you just generated. After the version is created, confirm it appears correctly in the versions list. Check the new entry for the version name, its release status, and any indicators showing whether it is still in review, approved, or ready for publication. 1. Open the project’s version or release controls. 2. Click the option to create a new version. 3. Enter the new version name exactly as it should appear. 4. Select the correct source content. 5. Finish the creation process. 6. Open the versions list and confirm the new version entry appears. [SCREENSHOT: Version creation screen showing version name field, source selection, and confirmation view] ## Reviewing the release and validating access After the version is generated, review it as a release candidate rather than assuming the draft carried over perfectly. Open the new version in preview or review mode and compare the most important pages against the draft source. Start with the landing page, top-level navigation groups, and any high-traffic pages your readers rely on first. This helps you catch missing sections, outdated page labels, or content that was still in progress when the version was created. Access validation is just as important as content review. In Atloria, a version can include pages with different visibility rules, so check whether internal-only pages, restricted sections, and public pages are appearing for the right audiences. If your project uses audience targeting or controlled access, test the release with the same visibility expectations you plan to use after publication. Helpful background is available in [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences). Also test the version selector and page links. Open several pages from the generated version and confirm the URLs lead to the intended release, not back to draft content or another published version. If inherited permissions are part of your setup, make sure they still behave correctly after version generation. A page that looks fine to an editor may still be hidden from the wrong audience after publication. Before you move to export or publication, collect final sign-off from the required reviewers. Check the approval indicators tied to the version and confirm that every required reviewer has completed their part. 1. Open the generated version in preview or review mode. 2. Compare key pages and navigation against the draft. 3. Test visibility for public, restricted, and internal content. 4. Check the version selector and page links. 5. Confirm all required approvals are present. [SCREENSHOT: Version review screen showing preview, approval status, and version selector] ## Choosing whether to export or publish directly Once the version is approved, decide how you want to deliver it. In Atloria, you may publish directly to the public documentation experience or create an export for controlled distribution. Direct publication is the right choice when readers should access the release through the public site, browse it with normal navigation, and switch versions using the version selector. Export is more useful when the release needs to be shared offline, archived, or distributed outside the public documentation portal. If you choose export, review the available export settings carefully. Check the output format, the pages included, and the version scope so the exported package matches the approved release. A common mistake is exporting only part of the documentation tree or using the wrong version when multiple versions are available. If your team relies on export workflows often, see [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records) and [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). Your choice also affects how readers experience access. A public release is discoverable through the published documentation area and follows the visibility rules configured for that version. An exported package is distributed separately, so readers do not use the same public navigation, version switching, or audience-based browsing experience. That difference matters if your stakeholders expect the release to behave like the live documentation site. Before final release, verify the output. For direct publication, use the publication preview if available and click through navigation, landing pages, and assets. For exports, open the generated output and confirm formatting, screenshots, and links behave as expected. 1. Decide whether the release should be public or distributed as an export. 2. If exporting, choose the correct format and included content. 3. If publishing, review the public-facing version preview. 4. Validate navigation, links, and assets before final release. [SCREENSHOT: Export or publish decision point with version scope and preview options] ## Publishing the release and fixing common issues When the approved version is ready, publish it from the version or release controls in Atloria. After publishing, confirm that the version appears as the intended visible release in the project’s version list and, if your project uses public documentation, on the public landing page. Open the published view and make sure readers are seeing the correct version first, especially if this release is meant to replace an older default version. If pages are missing after publication, start by checking whether those pages were actually included in the version snapshot. A page can be absent because it stayed in draft-only status, was excluded before version creation, or was hidden by navigation settings. Open the versioned page tree and compare it with the draft tree you reviewed earlier. If the page exists in draft but not in the released version, you may need to update the draft and generate a corrected version rather than editing the already published release. Access problems usually show up when reviewers can see content but public readers cannot. In that case, recheck visibility settings, audience rules, and public access configuration for the released version. If the project uses restricted sections, confirm those sections were not accidentally applied to pages that should be public. Related guidance is available in [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export). Broken links and missing assets are the other common post-publication issues. Open the affected page in the published version and test every version-specific link, screenshot, and attachment reference. If an asset was available in draft but not in the release, confirm it was included in the published version and not tied only to an earlier draft state. 1. Publish the approved version. 2. Open the public or released view and confirm the visible version. 3. Check for missing pages in the released page tree. 4. Recheck visibility and audience settings if access looks wrong. 5. Test links and assets on key published pages. [SCREENSHOT: Published version view showing version list, public landing page, and released navigation] ## Overview This guide focuses on the release stage of documentation publishing in Atloria: taking prepared draft content, turning it into a versioned release, validating access, and making the release available either through publication or export. It assumes your team is already working inside a project with draft documentation in progress and that you are close to the point where readers should receive a stable release. The workflow here is narrower than the broader publishing process covered in [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release). It also builds directly on [Coordinating Project Publishing From Draft to Public Release](doc:coordinating-project-publishing-from-draft-to-public-release), where the focus is on aligning people, timing, and review decisions across the release cycle. This document picks up at the moment when the content is nearly ready and you need to run the actual release steps in the correct order. You will work across the parts of Atloria that matter most during release: - The **project workspace** for release readiness checks - The **document editor** and **page tree** for final draft cleanup - The **versions list** and release controls for creating the release version - **Preview** or **review mode** for checking the generated version - **Export** or **public publication** options for final delivery Use this guide when you need to answer practical release questions such as: - Is the draft clean enough to version? - Which content source should become the release? - Are the right people able to approve and publish? - Should this release be exported or published directly? - Why is a page missing or hidden after publication? If you are already inside a version workspace and need deeper help with status handling, comparisons, or approvals, the related version guides in Atloria’s documentation set will be the best next reference. ## Prerequisites Before you follow this release workflow in Atloria, make sure the project and team are already set up for versioned documentation work. This guide does not cover first-time onboarding, repository connection, or initial project setup. If you still need to prepare the project itself, use [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) and [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). You should have the following in place: - A project with an active draft documentation set - Access to the project workspace and document editor - Permission to create versions, or a teammate who can do it - Reviewers assigned for approval decisions - A clear version name and release target - Agreement on whether the release will be published publicly or exported It also helps if you have already completed these checks: - The page tree reflects the intended published structure - Important pages have current titles, descriptions, and slugs - Review comments have been addressed on release-bound pages - Audience or visibility rules have been reviewed for the release - Screenshots and linked assets are available in the content you plan to release If your role is mainly administrative, you may want to confirm organization-level access and publishing permissions before starting. These topics are covered in [Using the Admin Workspace](doc:using-the-admin-workspace) and [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings). If you are ready to move beyond publication and start evaluating how readers use the released documentation, continue with [Using Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements). ## Opening the code parsing workspace In Atloria, open the **Code Parsing Workspace** from your project’s technical documentation area, then look for the four parts you will use most during a parsing run: - the **upload panel**, where you add code files - the **code snippet editor**, where you paste short samples - the **parse** or **run** controls, where you start analysis - the **results panes**, where Atloria shows symbols, dependencies, and the parsing summary The upload panel is best when you want Atloria to analyze real project files together. This is usually the right choice if you are checking how files relate to each other or if you want more complete symbol and dependency results. The code snippet editor is better for quick tests, such as checking whether a small block of code is recognized before you upload a larger set of files. Before you start a run, confirm which content Atloria should analyze. If you are using files, make sure the correct files appear in the upload area. If you are using the snippet editor, review the pasted code carefully and remove anything unrelated. Then use the main **Parse** or **Run** action to begin. After the run finishes, move through the results panes one by one. The **symbols list** shows the definitions Atloria detected in the uploaded content. The **dependency view** helps you see which files or code elements connect to each other. The **parsing summary** gives you the overall outcome, including whether the run completed successfully and how much Atloria recognized. If you already know how to read symbol and dependency details, this page focuses on the full upload-and-review workflow rather than repeating that material from [Reviewing Code Parsing Results Symbols and Dependencies](doc:reviewing-code-parsing-results-symbols-and-dependencies). [SCREENSHOT: Code Parsing Workspace showing upload panel, snippet editor, parse button, and results panes] ## Preparing files and snippets for parsing Atloria can work with several kinds of source material in the **Code Parsing Workspace**: - a single code file - multiple related code files - a short pasted snippet in the editor Choose the format that matches your goal. If you want a quick parser check, paste a short example into the snippet editor. If you want to understand relationships across a feature or section of a project, upload multiple related files together so Atloria can review them as one set. File names and file extensions matter because they help Atloria identify the language and structure of what you upload. A clearly named file with the correct extension usually gives better results than a renamed file or a pasted fragment with no surrounding context. Snippets can still be useful, but they work best when they include complete, readable code rather than isolated lines. Before you upload or paste content, check a few basics: - remove broken or unfinished fragments if possible - make sure the code matches the language you intend to analyze - keep related files together instead of uploading only one file from a larger connected group - avoid mixing unrelated samples in the same run when you want clear results For snippets, include enough surrounding code for Atloria to recognize the structure. For files, try to upload the actual source files rather than copied text saved under the wrong extension. If you manage a shared workspace, also confirm that you can access the project area where parsing is available. Project administrators should verify that the right people can open the workspace and that any file-type or upload-size rules used by their Atloria setup are understood before team members begin. If a file cannot be added, check those limits first instead of assuming the parser failed. [SCREENSHOT: File selection area with multiple uploaded files listed before parsing] ## Uploading code and starting a parsing run 1. Open the **Code Parsing Workspace** in Atloria and go to the **upload panel** if you want to analyze files. 2. Use the upload control to add one or more source files. After you select them, check the file list shown in the workspace. Make sure the files you expected to upload are all present and that you did not include unrelated files by mistake. 3. If you only want to test a small sample, switch to the **code snippet editor** instead of uploading files. Paste the code directly into the editor and review it for missing lines, cut-off sections, or extra text that is not part of the code. 4. Before starting the run, review the content shown on screen: - confirm the correct files appear in the upload list, or - confirm the snippet editor contains the exact sample you want Atloria to parse 5. Click the main **Parse** or **Run** action to start analysis. 6. Watch for any in-progress status shown in the workspace. Atloria may display a loading state, a running indicator, or a temporary status message while it processes the selected files or snippet. 7. Wait for the results panes to update before reviewing the output. Starting another run too quickly can make it harder to tell which results belong to which upload. If you are comparing parser behavior, run one clean test at a time. For example, first upload a related file set and review the results, then try a smaller snippet separately. That makes it easier to see whether missing symbols or dependencies are caused by the content itself or by the way it was submitted. [SCREENSHOT: Parse button selected with upload list visible and run status indicator in progress] ## Reviewing symbols and dependencies in the results 1. Start with the **symbols** panel. This area lists the definitions Atloria detected in the uploaded files or pasted snippet. Depending on the code you submitted, you may see items such as classes, functions, methods, or other named definitions. 2. Scan the list for the main items you expected Atloria to find. If an important definition is missing, compare the results with the original file or snippet you submitted. 3. Open the **dependency** view next. This area shows relationships between uploaded files, referenced modules, or linked code elements that Atloria recognized during the run. 4. Compare the dependency view with your upload set. If you uploaded several related files, you should be able to see whether Atloria connected them. If the dependency view looks sparse, that often means the run did not include all related files. 5. Return to the original uploaded content and verify that the structures shown in the results match what is actually in the source material. For technical writers and documentation managers, these two result areas are especially useful when planning coverage. The symbols panel helps you identify what named items exist and may need documentation. The dependency view helps you understand which files or features are connected, which is useful when you are mapping a documentation section to a real part of the codebase. If you need a deeper explanation of how to interpret individual symbol entries and relationship details, use [Reviewing Code Parsing Results Symbols and Dependencies](doc:reviewing-code-parsing-results-symbols-and-dependencies). In this workflow, the goal is to confirm that your upload produced a usable set of results before you move into documentation work. [SCREENSHOT: Results area with symbols list on one side and dependency view on the other] ## Interpreting parsing summaries and run outcomes After reviewing symbols and dependencies, check the **parsing summary** to understand the overall run. This summary is the fastest way to confirm whether Atloria processed the content as expected. Look for totals such as: - files processed - symbols detected - dependency counts - overall run status A successful run usually shows a completed status and meaningful totals in the summary. If you uploaded several files and Atloria reports multiple symbols and dependencies, that is a strong sign that the parser recognized the structure of your content. Partial results are different. In that case, Atloria may still show some symbols or relationships, but the summary may indicate warnings, incomplete processing, or fewer detected items than expected. This often happens when one file in the upload set is incomplete, unsupported, or missing related context. A failed run is usually easier to spot because the summary area will show an error state or a clear failure message. When that happens, review any warning or error messages attached to the file list, snippet area, or summary panel. These messages often point to the exact file or pasted sample that caused the problem. Use the summary to decide what to do next: - re-run with corrected files if one upload was incomplete - test a smaller snippet if you want to isolate a problem quickly - upload a more complete related file set if dependencies or symbols look too limited - remove unrelated files if the run included too much mixed content The summary is not just a status check. It helps you judge whether the results are complete enough to support your next documentation task, which you will build on in [Using Code Parsing Results to Improve Technical Documentation](doc:using-code-parsing-results-to-improve-technical-documentation). [SCREENSHOT: Parsing summary showing totals, run status, and warning messages] ## Fixing common upload and parsing problems When a parsing run does not give the results you expected, start with the message shown in the workspace and then check the content you submitted. **If file upload does not start**, review the basics first: - confirm the file type is allowed in your Atloria workspace - check whether the file may be too large - make sure you have access to use the Code Parsing Workspace in that project If the file never appears in the upload list, the issue is usually with the file itself or workspace access rather than the parsing step. **If a snippet parses with missing symbols**, look closely at what you pasted into the **code snippet editor**. Missing symbols often come from incomplete code blocks, cut-off declarations, or samples that depend on surrounding code that was not included. In that case, paste a fuller example or upload the actual file instead. **If dependencies look incomplete**, the most common cause is analyzing files in isolation. Atloria can only show relationships it can see in the uploaded set. If you upload one file from a larger feature, the dependency view may miss links that would appear if the related files were included in the same run. **If the parsing run fails or returns warnings**, read the run status message in the **parsing summary** and check whether a specific file or snippet is named. Then retry after correcting that item. A smaller test run can help you confirm whether the issue is limited to one file. When troubleshooting, change one thing at a time. For example: - first retry with the same files after removing one problematic file - then test a short snippet from that file - then upload the full related set again That approach makes it easier to see what fixed the problem. ## Overview This page walks through the complete basic workflow for using the **Code Parsing Workspace** in Atloria: adding source material, starting a parsing run, and reviewing the results that matter most for documentation work. The focus here is practical use inside the workspace rather than parser theory. You will work with four main areas in the screen: - the **upload panel** for adding files - the **code snippet editor** for quick pasted samples - the **Parse** or **Run** action for starting analysis - the results area for **symbols**, **dependencies**, and the **parsing summary** Use this workflow when you want to answer questions such as: - Did Atloria recognize the main definitions in these files? - Are related files connected in the dependency view? - Did the run complete successfully, partially, or with errors? - Is this result set strong enough to support technical documentation work? This guide does not repeat the deeper interpretation of symbol and dependency details already covered in [Reviewing Code Parsing Results Symbols and Dependencies](doc:reviewing-code-parsing-results-symbols-and-dependencies). Instead, it shows how to move from raw source material to a completed parsing run you can trust. For most teams, the best results come from uploading a clean, related set of files and then using the summary to confirm that Atloria processed them correctly. Short snippets are still useful, especially when you want to test a parser quickly or isolate a problem before running a larger upload. Once you are comfortable with this workflow, the next step is using these parsing results to shape clearer documentation structure, coverage, and reference planning in [Using Code Parsing Results to Improve Technical Documentation](doc:using-code-parsing-results-to-improve-technical-documentation). ## Prerequisites Before you begin in Atloria, make sure the following are in place: - You can open the **Code Parsing Workspace** in the project where you want to work. - You have source material ready to submit, such as: - a single code file - several related files - a short snippet for testing - Your files use the correct names and extensions so Atloria can identify them more accurately. - Your snippet, if you are using one, is complete enough to show the structure you want Atloria to detect. - You know the intended language or framework of the content you are submitting. - If you are uploading multiple files, you have grouped related files together instead of mixing unrelated samples. - You have already reviewed the earlier parsing guidance if you need background on workspace setup or result interpretation: - [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace) - [Managing Code Parsing Workspace Sessions](doc:managing-code-parsing-workspace-sessions) - [Uploading and Parsing Code for Documentation Workflows](doc:uploading-and-parsing-code-for-documentation-workflows) - [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage) If you are working in a shared team space, project administrators should also confirm that team members have the right workspace access and understand any file-type or upload-size limits used in that Atloria project. That helps avoid failed uploads before parsing even begins. For the smoothest first run, prepare one clean upload set or one clean snippet rather than testing several unrelated samples at once. ## Confirming access to agent knowledge and published documentation Before you connect published content to a support agent in Atloria, make sure you are working with a project that already has documentation available in its published view. Draft pages in the document editor are not enough for this workflow. Open the project and check the documentation area that shows the customer-facing published pages, not just the editing workspace. If you only see in-progress content, review your publishing workflow first in [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release). You also need access to the project area where support agent knowledge is managed. In Atloria, this is part of the project’s support agent setup and knowledge configuration. If you can open the project but cannot reach the support agent settings or knowledge source list, ask a Project Administrator to complete the connection step or adjust your access. For a fuller setup flow, see [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking). When you review the source that will be connected, confirm it points to the published documentation for that project. The goal is to use the same pages your customers read, not unpublished drafts, internal notes, or editing-only content. This keeps support answers aligned with public guidance and reduces the chance of the agent responding with instructions that have not been released. This workflow usually involves three roles: - **Project Administrator**: opens the support agent settings and connects the documentation source - **Documentation Manager**: reviews published pages and republishes updates when content changes - **Support Team Lead**: tests sample questions and checks whether answers match the published documentation [SCREENSHOT: Project view showing published documentation area and support agent knowledge settings] ## Preparing published pages for agent knowledge use Published pages work best as support agent knowledge when each page is clearly written, final, and easy for the agent to match to a user question. Start by opening the published documentation for the project and reviewing the pages you want the agent to use. Focus on page titles, section headings, and the final published wording. A page with a clear title and well-structured headings is much easier for the agent to use than a long page that mixes setup steps, troubleshooting, release notes, and policy details together. As you review the published content, look for outdated articles that are still live. If an older page contains instructions that have been replaced, update that page or remove it from the published set before you test the agent. Otherwise, the agent may answer from the older page because it is still available in the published documentation. This is especially important after product changes, renamed menu items, or revised workflows. It also helps to break broad topics into focused pages. For example, one page for signing in, another for project setup, and another for support agent configuration will usually produce better answers than one large article covering all three. Smaller, topic-specific pages give the agent a cleaner source to draw from and make your validation easier because you can tell which page should support each answer. Most importantly, republish your changes before testing. Editing a page in Atloria does not help the support agent if the updated version has not been published yet. The agent should be tested against the current published version, not the draft in the editor. Useful checks before linking: - Confirm each page has a stable, descriptive title - Use clear section headings for major tasks - Remove or revise outdated published pages - Split mixed-topic pages into focused articles where needed - Republish changes before running support agent tests [SCREENSHOT: Published documentation page with clear title and section headings] ## Linking the project documentation to support agents 1. Open the project in Atloria and go to the support agent configuration area for that project. If you have already linked other knowledge sources, look for the section that lists the current knowledge sources attached to the agent. 2. Find the knowledge source settings where documentation can be added. In this area, choose the project documentation source that represents the published documentation you want the agent to use. Be careful to select the published documentation location for the project, not an internal editing view or any source meant only for internal teams. 3. Select the documentation source and confirm the project or documentation label matches the content you reviewed earlier. This is your chance to verify that the source belongs to the correct project and reflects the customer-facing documentation set you intend to use for support answers. 4. Save the knowledge settings. After saving, Atloria should show the connected documentation source in the support agent’s knowledge list. Check the label carefully so you can confirm the right project documentation has been attached. 5. Review the saved knowledge list one more time. If the support agent uses multiple sources, make sure the published documentation appears alongside any other approved sources and is not confused with older or unrelated documentation. A successful connection should leave you with a visible entry in the knowledge source list that clearly identifies the project documentation now available to the support agent. If the source label is unclear, return to the project documentation and verify you selected the correct published content set before moving on to testing. If you need the broader setup process for adding or organizing knowledge sources, use [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking). [SCREENSHOT: Support agent knowledge source list showing connected project documentation] ## Controlling which published content agents can answer from Connecting only published documentation gives you a useful boundary: the support agent answers from customer-facing guidance instead of unpublished notes or internal working material. In Atloria, that boundary matters because support answers should reflect what customers are expected to see and follow. If the agent is limited to published pages, it is less likely to introduce internal-only wording, unfinished instructions, or steps that have not been approved for release. Scope also affects answer quality. A broad connection that includes all published project documentation may work well when your published site is tightly organized and consistently maintained. If your published content includes many unrelated topics, however, broad scope can make answers less precise. In that case, a narrower documentation set is often better. The more focused the connected content is, the easier it is for the support agent to stay on-topic. Some published pages should not drive support responses even if they are technically live. Review the connected content and consider excluding pages such as: - Release notes that describe older behavior - Temporary announcements - Internal process pages that were published for limited audiences - Broad update pages that mention many topics without clear task steps Ownership should stay clear after the initial setup. Documentation teams are responsible for keeping the published pages accurate, current, and well structured. Support leads should regularly test whether the connected knowledge still reflects real support scenarios. When a page is updated, removed, or replaced, the connected knowledge set may need review as well. If your team also manages audience-specific published content, make sure the pages included in the support agent’s knowledge match the audience you expect the agent to serve. Related guidance is available in [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences) and [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation). ## Testing agent responses against the intended documentation source 1. Open the support agent chat experience in Atloria and prepare a short list of questions tied to specific published pages. Choose questions where you already know which page should provide the answer. This makes it much easier to tell whether the agent is using the intended documentation source. 2. Ask direct questions based on published task pages. For example, if you have a published page about signing in, ask the support agent how to sign in or what to do after an invalid password message. Then open the matching published page and compare the response to the page title, headings, wording, and step order. 3. Check whether the response stays inside the published guidance. The answer should use the same terminology and should not introduce extra steps that do not appear on the published page. Small wording differences are normal, but the substance should match the customer-facing instructions. 4. Repeat the process with a few edge-case questions. Ask about topics that are only partially covered or not covered at all in the published documentation. In those cases, the support agent should respond cautiously or give a limited answer rather than inventing unsupported instructions. 5. Test across several page types, such as setup pages, troubleshooting pages, and policy-style pages. This helps you see whether the connected documentation set is balanced or whether some content areas are overpowering others. A simple validation table can help during testing: | Test question | Expected published page | What to check | |---|---|---| | Sign-in question | Sign-in page | Terminology and steps match the page | | Setup question | Setup page | Answer uses the correct published workflow | | Unsupported question | No matching page | Agent stays limited and does not invent details | [SCREENSHOT: Support agent chat beside a published documentation page for answer comparison] ## Fixing mismatched answers and stale documentation results When a support agent gives the wrong answer, start with the published page itself. If the answer reflects old instructions, open the page you expected the agent to use and confirm the corrected content is actually published. Updating a draft in the editor is not enough. The support agent should be connected to the published documentation, so the fix must be visible in the published view before you test again. If the answer points to the wrong topic, the connected documentation may be too broad or the page structure may be too vague. Large pages with mixed subjects often cause this problem. Split those pages into smaller articles with clear titles and headings so each support question maps to one obvious source. If needed, narrow the connected documentation set so the support agent is not searching across unrelated published content. When the support agent cannot answer a question that is already documented, verify three things: - The page is publicly published in the project’s documentation - The page is part of the connected knowledge source - The page title and headings clearly describe the topic users are asking about Another common issue is mixed public and internal guidance. If the support agent responds with language that sounds like internal process notes rather than customer instructions, review the knowledge source list and remove any source that is not meant for customer-facing support. The connected sources should be limited to approved published documentation for this workflow. After each change, rerun the same test questions you used before. That gives you a clean before-and-after comparison and helps confirm whether the issue came from page content, source selection, or documentation scope. If the problem continues, revisit the broader source setup in [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking). ## Overview Using published documentation as support agent knowledge in Atloria is the best fit when you want the agent to answer from the same guidance customers already see. Instead of relying on draft content or internal working notes, you connect the support agent to the project’s published documentation and then validate that its answers stay aligned with those live pages. This approach is especially useful for customer support teams that need consistency between self-service documentation and agent-assisted answers. The workflow has four main parts: - Confirm the project has published documentation available - Prepare the published pages so they are current, focused, and clearly structured - Connect that published documentation in the support agent’s knowledge settings - Test real questions to confirm the answers match the intended source This document focuses specifically on published documentation as a knowledge source. If you still need to set up the support agent workspace, organize knowledge sources, or link a project at a broader level, use [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking). In practice, the quality of support answers depends heavily on the quality of the published pages. Clear page titles, strong headings, and current published content make it easier for the support agent to return accurate, customer-facing responses. Poorly organized or outdated published pages usually lead to vague, stale, or mismatched answers. You should use this workflow when the support agent is expected to mirror your public documentation experience. If your goal is to answer only from internal team knowledge, this document is not the right setup path. For teams using public docs as the source of truth, though, this is the cleanest way to keep support responses aligned with what readers can already find in Atloria’s published documentation. ## Prerequisites Before you start, make sure these items are already in place in Atloria: - A project with documentation that has been published, not just saved in the editor - Access to the project’s support agent settings and knowledge source configuration - A support agent already created for the project, or an existing agent you can edit - Published pages that are intended for customer-facing support use - Permission to review and update published documentation if changes are needed It also helps to have the right people involved before testing begins: | Role | What they handle | |---|---| | Project Administrator | Connects the published documentation in the support agent settings | | Documentation Manager | Reviews page titles, headings, and published accuracy | | Support Team Lead | Tests questions and checks whether answers match published guidance | Before linking the source, confirm these content conditions: - The pages you want the agent to use are visible in the published documentation view - Outdated or superseded pages have been updated, removed, or clearly separated - Important support topics are not buried inside long mixed-topic articles - Recent edits have been republished so the published view reflects the latest approved content If you need help getting into Atloria, creating an account, or signing in before reaching the project workspace, see [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account), [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems), and [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). From here, the next useful step is usually [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability) so the agent not only uses the right knowledge, but also behaves the way your support team expects. ## Preparing a release with audience-targeted content Before you start validating audience-specific release views in Atloria, make sure the release already includes the audience targeting you expect to test. This means the release should already contain pages, sections, or messaging that differ by audience, along with any default content shown when no audience-specific rule applies. If you still need to confirm the release is ready for this stage, use [Validating Audience Specific Publishing Before Launch](doc:validating-audience-specific-publishing-before-launch) first. Gather the audience list you plan to review. In practice, this usually means noting the exact audience names used inside Atloria and the public-facing labels or route names that readers will see when they open the published documentation. Keep these names side by side while you test so you can quickly spot when a route is showing the wrong release view. You should also confirm that you can reach the three places used during validation: - the release preview for the version you are checking - the audience settings area where audience definitions are listed - the public documentation view or public audience route for each audience If any of those areas are unavailable, your review will be incomplete because you will not be able to compare preview and published output. Before opening routes one by one, write down the expected result for each audience. Include what should stay the same across all audiences and what should change, such as a different release title, a targeted callout, or audience-specific links. This gives you a simple pass/fail reference during review instead of relying on memory. [SCREENSHOT: release preview open beside a list of audience names and expected outcomes] ## Checking audience definitions before reviewing the release Open the audience settings used for the project or organization and review each audience entry carefully before you inspect the release itself. At this stage, you are not checking page content yet. You are confirming that the audience list Atloria will use during publishing matches the release plan you approved earlier in the workflow. For each audience, verify the exact audience name shown in Atloria. If your team uses a different public label in published documentation, note that too so you can match the internal audience to the correct public route during testing. Small naming differences are easy to miss and often lead to reviewing the wrong route. As you move through the audience list, check whether the audience is clearly intended for the release you are validating. Look for any audience entries that appear duplicated, outdated, or too broad. If two audiences seem to describe the same group, or if one audience is missing entirely, the release may show the wrong content to readers. Focus on these checks: - the audience name matches the release plan - the audience is active and available for current use - the audience is the one referenced by the targeted release content - the audience can be tied to a public route or public audience view you can test This is also the right time to identify overlap problems. If one audience could reasonably match the same readers as another, compare their intended purpose before moving on. Audience-specific validation works best when each route maps cleanly to one expected release view. Create a simple review note with the audience name and the public route you expect to open for it. That note becomes your checklist for the next stage. [SCREENSHOT: audience settings screen showing multiple audience entries ready for review] ## Reviewing the public audience routes for the release Once the audience definitions are confirmed, open each public audience route tied to the release and review what a reader would actually see. Work through the routes one at a time so you can compare them against your audience checklist instead of jumping between pages. 1. Open the public documentation view for the first audience route. 2. Confirm the page loads correctly and does not show an access problem, missing page, or unrelated content. 3. Check the audience label or route context shown on the page and make sure it matches the audience you intended to test. 4. Review the release content on that route, including the title, body content, callouts, and links. 5. Repeat the same check for every remaining audience route. As you compare routes, pay attention to what should remain unchanged and what should vary. Shared release information should stay consistent across audiences. Only the audience-targeted parts should change. For example, if all audiences should see the same release date and navigation, those elements should remain identical. If one audience should see a special onboarding note or a different linked resource, that difference should appear only on the matching route. You should also confirm that restricted messaging does not appear on routes meant for other audiences. If a route intended for one audience shows content approved for another, stop and note the mismatch immediately. That usually points back to the audience setup or the release targeting itself. A side-by-side review is helpful here. [SCREENSHOT: two public audience routes open side by side showing shared content and different targeted sections] ## Comparing what each audience sees in preview and published views After checking the public routes, compare them with the release preview in Atloria. This step helps you catch cases where the preview looks correct but the published audience route does not, or where the published route is current but the preview still reflects older release choices. 1. Open the release preview for the version you are validating. 2. Select or view the audience-specific version you want to inspect. 3. Compare that preview with the matching public audience route. 4. Note every difference, even if it seems minor. 5. Repeat for each audience and for the default, non-targeted view. Look closely at the parts of the release most likely to vary by audience: - release title or heading - introductory text - body sections - callouts or notices - linked resources - audience-specific navigation cues If Atloria uses a default release view when no audience applies, verify that default view separately. You want to know exactly what an unmatched visitor sees. In some cases, the correct result is the standard public release content. In other cases, targeted content should simply not appear. Do not assume the fallback is correct just because audience routes look right. A simple comparison table can help reviewers sign off without rechecking every screen from scratch: | Audience | Preview result | Public route result | Expected outcome | Status | |---|---|---|---|---| | Audience 1 | Matches targeted content | Matches targeted content | Targeted version visible | Pass | | Audience 2 | Missing callout | Callout visible | Targeted version visible | Review | | Default view | Standard release content | Standard release content | No targeted content | Pass | [SCREENSHOT: release preview next to the matching published audience route] ## Confirming the final release outcome for every audience When preview and published views have both been checked, run one final pass for every audience. This is the point where you confirm the release is ready to stand as the approved public result, not just a draft that looked correct during earlier review. 1. Start with your audience checklist and open the release preview for the first audience. 2. Confirm the preview matches the approved audience-specific result. 3. Open the corresponding public audience route and confirm it shows the same release outcome. 4. Mark that audience as passed only when both views match your expected result. 5. Repeat for each audience, then test the default public view with no audience-specific targeting applied. Be strict about what counts as a pass. The audience should only be marked complete when the displayed content matches the approved audience definition and the expected release outcome you documented earlier. If the title is correct but the links are wrong, or if the public route loads but shows default content instead of targeted content, leave it in review status until the mismatch is resolved. For audit or editorial sign-off, capture evidence as you go. Screenshots are especially useful when multiple reviewers need to confirm the same release behavior later. Capture: - the release preview for each audience - the matching public audience route - the default public view - any mismatch that required correction before approval [SCREENSHOT: reviewer checklist with pass marks beside each audience and saved screenshots for evidence] ## Fixing mismatched audience views and route problems If a route or release view does not match expectations, work backward from what you can see in Atloria. Most issues become clear when you compare the audience definition, the release preview, and the public route in that order. When a public audience route shows the wrong release variant, first return to the audience settings and confirm you are testing the correct audience name and route. Then review the targeted release content to make sure it was assigned to the intended audience. A route that displays the wrong variant often traces back to the wrong audience being used during setup. If a public route does not load, opens the wrong page, or shows content unrelated to the release, verify that you are testing the correct published route for the current environment. Also confirm the release is actually published and not only available in preview. A route problem is different from a content problem, so separate those two checks. When the preview is correct but the published route is different, the most likely cause is that the latest release changes are not yet reflected in the public view. Reopen the release, confirm the latest approved content is the version that was published, and then refresh the public route before testing again. If visitors with no matching audience still see targeted content, review the default release behavior. Check whether the release is supposed to fall back to a standard public view and whether a broad audience assignment is causing targeted content to appear more widely than intended. Use this quick guide during troubleshooting: | Problem you see | What to recheck in Atloria | |---|---| | Wrong audience content on route | Audience name, targeted content assignment | | Route does not load | Published route, current release state | | Preview and public view differ | Latest published release content | | Unmatched visitors see targeted content | Default release view and fallback behavior | [SCREENSHOT: audience settings, release preview, and public route reviewed together during troubleshooting] ## Overview Audience-specific release validation in Atloria is the final check that confirms readers see the right release content on the right public route. At this stage, you are not creating audiences or building the release. You are verifying the finished result across preview and published views so your team can approve the release with confidence. This workflow centers on three things: - the audience definitions used by the release - the release preview for each audience - the public audience routes readers will open The goal is to prove that each audience sees only the content intended for it. That includes confirming that shared release content stays consistent, targeted sections appear only where expected, and the default public view behaves correctly when no audience rule applies. This document builds directly on [Validating Audience Specific Publishing Before Launch](doc:validating-audience-specific-publishing-before-launch). If you have not already checked release readiness, audience assignments, and launch conditions, complete that validation first. The steps here assume the release is already prepared and ready for final audience-by-audience review. Use this guide when you need to: - compare audience preview output with published output - confirm public audience routes resolve correctly - verify fallback behavior for non-matching visitors - collect screenshots for editorial approval or audit review Because Atloria supports both internal workspace review and public documentation experiences, this final validation helps you catch the last visible issues before readers do. ## Prerequisites Before you validate audience-specific release views in Atloria, make sure these items are already in place: - You can sign in and open the project workspace that contains the release. - The release version has already been prepared for audience-specific publishing. - The audiences used by the release have already been defined and are available for review. - You can open the release preview for the version being tested. - You can access the public documentation view or public audience routes for the release. - You have a clear list of expected results for each audience, including the default public view. - You have already completed the checks in [Validating Audience Specific Publishing Before Launch](doc:validating-audience-specific-publishing-before-launch) if launch readiness still needs confirmation. It also helps to have a simple review sheet before you begin. Include: - each audience name used in Atloria - the matching public audience route or label - the expected release title, sections, and links for that audience - a place to mark pass, review, or failed - a place to store screenshots If you are working with another reviewer, agree in advance on what counts as a pass. For example, decide whether every audience-specific callout, link, and heading must match exactly before approval is given. That keeps sign-off consistent and avoids repeated review cycles caused by unclear expectations. ## Understanding How Audiences Shape the Public Reading Experience In Atloria, audiences control what a reader sees after your documentation is published. They affect three parts of the public experience: which pages appear in navigation, which published pages can be opened, and which documentation versions are available in the version selector. This means two readers can visit the same documentation site and see different menus, different page lists, and different version choices based on the audience rules you applied. Public access and audience-targeted access are not the same thing. A page can still be published and available in your project, but filtered out of the public experience for readers who do not match the selected audience. For example, a page meant for partners may remain published while staying hidden from general public readers. In the same way, a version can stay live for one audience while not appearing at all for another. You apply these settings in the places where readers actually experience the content: - On the page itself, using the page visibility or audience setting - In navigation setup, where menu items, section links, and sidebar entries are shown or hidden - In version publishing settings, where access to specific documentation releases is controlled If your public documentation supports audience-aware reading for signed-in users, Atloria can show different content depending on who the reader is. Anonymous visitors usually see the default public set. Signed-in readers may see additional pages, sections, or versions if their audience membership allows it. This is why audience planning matters beyond page editing alone. If you only tag pages but do not align navigation and version settings, readers may miss content or see links that lead nowhere. If you need help deciding which audience groups to use before you start assigning them, review [Planning Audience Targeting for Project Content](doc:planning-audience-targeting-for-project-content). ## Assigning Audiences to Pages and Navigation When you want a page to appear only for certain readers, start in the page editor. Open the documentation page you want to control, then find the visibility or audience setting for that page. In Atloria, this is the setting that determines whether the page is available to everyone or only to selected audience groups. If no audience is assigned, the page typically remains part of the general published experience. Once you select one or more audiences, the page becomes targeted to those readers. 1. Open your project and go to the documentation page you want to update. 2. In the page editor, locate the audience or visibility control. 3. Choose the audience values that should be able to read the page. 4. Save or publish the page changes. 5. Open the public documentation preview and confirm the page appears only for the intended audience. [SCREENSHOT: Page editor showing the audience or visibility setting for a documentation page] After updating the page, check the navigation that points to it. A common mistake is setting the page audience correctly but leaving the menu item visible to everyone. That creates a public menu link that leads readers to a page they cannot open. To avoid this, update the matching navigation item, section entry, or sidebar node so it uses the same audience rule as the page. Review these areas together: - The page audience setting - The sidebar or menu item for that page - The parent section that contains the page If a navigation item is visible but the page is hidden, edit the navigation entry and assign the same audience as the destination page. If the page is public but the menu item is restricted, readers may still reach it from a direct link but not discover it through browsing. The cleanest setup is to keep page visibility and navigation visibility aligned so the public site feels consistent. For broader audience setup inside a project, see [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). ## Controlling What Readers See Across Documentation Versions Audience targeting becomes more important when your project has multiple published versions. In Atloria, version access is not only about whether a version is published. It also affects whether that version appears in the version selector for a specific reader. If a version is intended only for a certain audience, readers outside that audience should not see it listed as an available choice. A page can also behave differently across versions even when the page title or URL path stays the same. For example, a page in one version may be public, while the same page in a newer version may be limited to customers or internal readers. In that case, Atloria treats access according to the rules of the version the reader is viewing, not just the page name. This is useful when a release introduces content that should only be shared with a narrower group. When you review versioned audience behavior, pay attention to: - Which versions appear in the version selector - Whether the same page is visible in every version - What happens when a reader opens a direct link to a restricted version - Whether in-page links point to pages or versions the reader can actually access If a reader tries to open a version they are not allowed to view, that version may be absent from the version selector and unavailable through normal browsing. If links inside a visible page point to hidden version content, the reading experience becomes confusing. Check those links during preview so readers are not sent from an allowed version into a restricted one. This setup lets teams create distinct reading tracks without rebuilding the entire documentation structure. You can keep one project and use audience rules to present beginner-friendly content, customer documentation, partner materials, or internal release notes through different version choices and page visibility rules. For release planning and version control, pair this work with [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences) and [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access). ## Designing Audience Rules for Clear Public Navigation Good audience targeting should make public navigation feel simpler, not more fragmented. In Atloria, readers should be able to move through top-level navigation, section landing pages, and child pages without running into empty categories or menu branches that contain nothing they can open. The best way to avoid that is to map audience rules across the full navigation path, not page by page in isolation. Start with your top-level sections. If an entire section is meant for one audience, apply the same audience to the section landing page and all of its child pages. This keeps the sidebar and section menus clean. Readers outside that audience will not see the section at all, which is usually better than showing a heading that opens to no visible content. Use more detailed audience splits only when the section itself should stay visible to everyone but some child pages should be limited. For example, a general “Getting Started” section may stay public while a few deeper pages are reserved for customers or partners. In that case, make sure the parent section still contains enough visible pages for each audience so it does not feel incomplete. A simple naming pattern helps teams assign the right audience quickly. Use labels that are easy to recognize at a glance, such as: - Public - Customer - Partner - Internal Avoid audience names that are too similar or too broad, especially when Documentation Managers and Technical Writers are updating pages across multiple versions. Before publishing, use a review workflow that checks: - The audience on each page - The audience on the matching navigation item - The audience on the parent section - The audience on the published version [SCREENSHOT: Public documentation navigation with section and child pages filtered by audience] If your team already planned audience structure at the content level, connect that work here by reviewing [Applying Audiences to Documentation Structure and Content Decisions](doc:applying-audiences-to-documentation-structure-and-content-decisions). ## Previewing the Site as Different Audiences Before you publish audience changes widely, preview the public site as each audience type you support. In Atloria, this is the fastest way to confirm that readers see the right navigation, the right pages, and the right versions. A page can look correct in the editor while still disappearing from the public site because of a parent section rule or a version-level filter, so previewing is essential. 1. Open the public documentation preview for your project. 2. Use the available audience preview or simulation control to switch between audience types. 3. Check the top navigation, sidebar, and section landing pages for each audience. 4. Open pages directly from the menu and confirm they load as expected. 5. Test direct page links for restricted pages to see whether they open, redirect, or stay hidden. 6. Open the version selector and confirm only the intended versions appear for that audience. [SCREENSHOT: Public documentation preview showing audience switching or audience-based viewing] Do not stop at menu browsing. Copy a direct page link for a restricted page and test it while previewing another audience. This helps you catch situations where a page is hidden from navigation but still opens from a saved link. Also test the same page across multiple versions if the audience assignment changes between releases. If your documentation supports signed-in readers with audience-based personalization, compare that experience with the anonymous public view. Anonymous visitors usually see only the broad public set. Signed-in readers may see additional sections or versions after Atloria recognizes their audience membership. That makes it important to test both states: - Anonymous visitor view - Signed-in reader view - Signed-in reader with a different audience assignment This side-by-side check helps you confirm that audience membership changes the public experience in the way you intended, especially for customer-only or partner-only documentation. For related reading on public browsing behavior, see [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience) and [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content). ## Fixing Common Audience Visibility Problems Most audience visibility issues in Atloria come from one of three places: the page setting, the navigation setting, or the version setting. When something looks wrong in the public site, check those in that order. If a page is published but does not appear in public navigation, review: - The page audience or visibility setting - The navigation item linked to that page - The parent section or category that contains it A hidden parent section can remove a page from browsing even when the page itself is published correctly. If the page should be visible, make sure the parent section allows the same audience. If readers can open a page from a direct link but cannot find it in the menu, the page and the navigation item are probably using different audience rules. Edit the menu entry, sidebar node, or section link so it matches the page audience. This is one of the most common causes of “missing” pages. If a version is missing from the version selector, check the version’s audience rules first. Then confirm that the selected audience can access at least one published page in that version. A version with no visible pages for that audience may not appear as a useful option in the public reading experience. If signed-in readers see the wrong content set after logging in, compare their audience membership with what you expected to test. Then repeat the check in preview mode or audience simulation, if available, to confirm whether the issue is with the audience assignment or with the reader account being used. [SCREENSHOT: Public documentation page visible in editor but hidden in navigation due to audience mismatch] When troubleshooting, it helps to test one page and one version at a time. Change a single audience rule, refresh the public preview, and confirm the result before adjusting anything else. That makes it easier to find the exact mismatch. For broader public-reading checks, use [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation). ## Overview - In Atloria, audiences shape the public reading experience by controlling page visibility, navigation visibility, and version availability. - A page can remain published while still being hidden from readers who do not match the assigned audience. - Audience rules need to stay aligned across the page, its navigation link, its parent section, and the published version. - Public readers and signed-in readers may see different content sets when your documentation uses audience-aware personalization. - Previewing the site as multiple audiences helps you catch hidden pages, empty navigation sections, and missing versions before readers do. This document focuses on applying audience decisions to the public documentation experience. If you still need to define the audience groups themselves, start with [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation). If your next step is validating the published reader journey, continue with [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience). ## Prerequisites - You have access to an Atloria project with published or publish-ready documentation. - Your project already includes audience groups that were created and organized for documentation use. - You can open documentation pages in the editor and update their visibility or audience settings. - You can review or edit public navigation for the project. - You have access to version publishing settings if your project uses multiple documentation versions. - You can open the public documentation preview to test what readers see. - If you are checking signed-in reader behavior, you have a reader account that belongs to the audience you want to test. If you have not completed the planning work yet, review [Planning Audience Targeting for Project Content](doc:planning-audience-targeting-for-project-content) before applying these rules to the public site. ## Opening an entity reference page from project and public documentation In Atloria, you can open an entity reference page in two places: inside a project workspace and in published documentation. The project view is the working area your team uses while reviewing generated technical documentation alongside drafts and unpublished content. The public view is the published reading experience that outside readers or broader internal audiences use after documentation is released. If you already worked through [Managing Technical Documentation Browsing and API Reading](doc:managing-technical-documentation-browsing-and-api-reading), the main difference here is that you are no longer just browsing section lists—you are opening one specific reference item and reading its full detail page. Common ways to reach an entity page include: - Clicking an item in an API reference list - Opening a result from search - Selecting an item from a namespace or module page - Following a linked type or member name inside another reference page - Choosing a related symbol from a member list In the project workspace, start from your project’s technical documentation area and open the API reference section. From there, select an item from the reference index or drill down through grouped pages until you see the entity name you want. In published documentation, use the public navigation, search, or linked names inside the page content to open the same kind of detail page. You can usually tell which context you are in by the page frame around the content. Project pages appear inside the project workspace navigation, while public pages appear in the published documentation layout. Breadcrumbs also help: project breadcrumbs keep you inside the project’s documentation structure, while public breadcrumbs reflect the published documentation path. [SCREENSHOT: Entity reference page opened from a reference list, showing breadcrumbs and page header in project view] When several items share similar names, use the breadcrumb trail and the page title together before you continue. That helps confirm you opened the right reference item. ## Reading the main details shown on an entity page At the top of an entity reference page in Atloria, the header gives you the fastest way to identify what you are looking at. Start with the entity name shown as the main title. Near that title, you may also see a kind label that tells you what sort of item it is, such as a type, method, property, event, or another reference item. Many pages also show a fully qualified path near the top, which helps distinguish similarly named items that belong to different modules, namespaces, or sections. A short summary may appear directly under the title area. Read this first before moving into the detailed sections. It usually gives the clearest one-line explanation of what the item represents or how it is used. Signature information is typically shown near the top of the page as a formatted block. Depending on the item, this block may include the item name, parameter list, return type, generic type parameters, and modifiers when Atloria has that information available. You do not need to interpret every symbol immediately. Focus on these questions: | What to check | Where to look | Why it matters | |---|---|---| | Item name | Main page title | Confirms the exact reference item | | Item kind | Label near the title | Tells you whether you are reading a method, property, type, or another item | | Path | Qualified path under the header | Separates similar names in different locations | | Summary | Intro text below the header | Gives quick meaning before deeper reading | Status indicators may also appear near the top or beside the item name. If you see labels such as deprecated, internal, experimental, or inherited, treat them as reading cues. They tell you whether the item is older, limited in visibility, still changing, or coming from a parent item rather than being defined directly here. Description and remarks sections usually appear below the signature. Inline links inside those sections often point to related items, letting you understand the current page without leaving the reference flow unless you need more detail. ## Interpreting related information attached to the entity Most entity pages in Atloria include grouped sections below the main header. These sections help you move from “what is this item?” to “how does this item connect to everything around it?” The exact sections vary by item, but you will commonly see details such as parameters, properties, methods, events, examples, or inherited members. When you read these sections, treat them as layers: - The header identifies the item - The description explains it - The related sections show how it behaves or what belongs to it For example, a page for a larger reference item may include a member list showing its properties or methods. A page for a callable item may include a parameters section and a return value area. If examples are available, read them after the summary and signature so the example has context. Type references inside these sections are often clickable. Selecting a linked type name opens another entity page so you can inspect that related item directly. Relationship labels help you understand why the link is there. A parent relationship points upward to the containing item. A child relationship points to members or nested items. Dependency-style links usually point to types or related items used by the current page. You may also see source-related details when Atloria exposes them. These can include package, module, namespace, file, or version information. Those labels help you place the item in the broader documentation structure, especially when names repeat across different areas. Status tags are especially important in related sections: | Tag | What it tells you | How to read it | |---|---|---| | Deprecated | Older item kept for compatibility | Prefer newer linked alternatives if shown | | Experimental | Still changing | Read carefully before relying on it | | Internal | Not meant for all readers | May appear only in project view | | Inherited | Comes from a parent item | Check the parent item for broader context | [SCREENSHOT: Related sections on an entity page showing parameters, members, examples, and status tags] ## Moving between related reference items on the page Long reference pages in Atloria are easier to use when you rely on the page’s built-in navigation instead of scrolling from top to bottom every time. Start with the table of contents or section links if they are shown. These let you jump directly to areas such as parameters, properties, methods, examples, remarks, or inherited members. Anchor links are especially useful when you are comparing several parts of one page. If a member list is long, click the member name in the list to jump directly to that member’s detailed section. This is faster than searching visually through repeated headings. You can also move outward from the current page by following linked names inside the content. Common links include: - Parameter types - Return types - Base classes - Implemented interfaces - Related members - Parent items in the breadcrumb trail These links help you build context one step at a time. For example, if a method returns a type you do not recognize, click the return type name to open that type’s page. If a property is inherited, use the parent link or breadcrumb to move up and inspect the containing item. Breadcrumbs are the quickest way to back out without losing your place. Use them to return to the containing namespace, module, package, or category page. From there, you can open sibling items—other items listed beside the one you are reading—to compare nearby reference entries without starting over from search. A practical reading pattern is: 1. Read the page header and summary 2. Jump to the section you need with the table of contents 3. Open linked types only when a term is unclear 4. Use breadcrumbs to return to the parent page 5. Open sibling items from the member list or side navigation [SCREENSHOT: Entity page with table of contents, member list links, and breadcrumb navigation highlighted] This approach keeps you oriented even when the reference set is large. ## Switching between project and public views without losing context In Atloria, the same entity can appear in both the project workspace and the published documentation view. The page content may look similar, but the surrounding navigation and available content can differ. When you switch between these views, your goal is to confirm that you are still reading the same reference item. Start by checking three identifiers on the page: | Identifier | Why it helps | |---|---| | Entity name | Confirms the item title matches | | Kind label | Confirms it is the same type of reference item | | Qualified path | Confirms it belongs to the same location in the documentation structure | If Atloria provides a view-switching control or separate navigation paths for project and public documentation, use those rather than manually retracing your steps. Matching breadcrumbs are also useful. In the project workspace, the breadcrumb trail keeps you inside the project’s documentation structure. In the public view, the breadcrumb trail follows the published structure. Even when the layouts differ, the entity name and path should still line up. Expect some differences between views. In the project workspace, you may see draft descriptions, unpublished items, or content still being reviewed. In the public view, those items may be hidden or filtered out. Public pages may also show only what has been released, which can make a member list look shorter than the project version. If something looks different, compare the page title, path, and nearby related links before assuming it is a different item. Stable names and linked relationships usually make the match clear. This matters most when you are checking whether published documentation reflects what your team sees internally. If the project page includes more detail than the public page, that often means the content has not been published yet rather than the reference item being missing entirely. ## Recognizing common navigation issues on reference pages When an entity page in Atloria does not look the way you expect, the issue is often the current view, the page path, or the amount of generated detail available for that item. One common problem is a missing related member list. If you expected to see more properties, methods, or inherited items, first check whether you are in the public documentation view. Public pages may exclude internal or unpublished content that is still visible in the project workspace. If the page is shorter in public view, switch back to the project documentation area and compare the same entity there. Another issue is opening the wrong item from a link. This usually happens when several items share a similar name. Before reading further, verify the fully qualified path, the breadcrumb trail, and the kind label near the page title. Those three details usually tell you whether you opened the correct item. You may also click a referenced type and find that there is no full detail page. In Atloria, that can happen when the linked name points to an external reference or to a symbol that does not have its own generated page. In that case, return to the previous page and continue using the local description, signature, and remarks for context. If the page feels incomplete, check whether the missing section was ever provided for that item. Some pages include examples, remarks, and source details, while others only include a title, signature, and short summary. Use this quick check when something seems off: - Missing members: compare project view and public view - Wrong item opened: confirm breadcrumb, path, and kind label - No detail page for a linked type: treat it as an external or undocumented reference - Thin page content: look for whether examples, remarks, or metadata are simply not available [SCREENSHOT: Entity page showing breadcrumb, kind label, and qualified path used to confirm the correct item] ## Overview This guide focuses on how to read a single entity reference page in Atloria and move confidently between related reference items. Unlike broader API reference browsing guides, the emphasis here is on the details that appear once you open a specific item: the page header, summary, signature block, related sections, status labels, and links to connected items. You will use this workflow in both major reading contexts: - Project documentation view for internal review and unpublished reference content - Public documentation view for released documentation that readers can browse after publication The most important habit is to orient yourself before diving into the details. On every entity page, begin with the entity name, kind label, and qualified path. Those three elements help you confirm that you are on the correct page, especially when multiple items have similar names. From there, read the summary, then move into the sections that matter most for your task, such as parameters, properties, methods, examples, or inherited members. This guide also explains how Atloria connects one reference item to another. Type links, member lists, breadcrumbs, and parent pages all work together so you can move through the reference set without restarting your search. That is especially useful when you are tracing relationships between items or comparing the internal project view with the published public view. If you need a refresher on broader reference navigation before focusing on individual entity pages, return to [Managing Technical Documentation Browsing and API Reading](doc:managing-technical-documentation-browsing-and-api-reading). The next step after this guide is [Reading API Reference in Project and Public Views](doc:reading-api-reference-in-project-and-public-views), which focuses on comparing the overall reading experience across both contexts. ## Prerequisites Before using this guide, make sure you can already open technical documentation in Atloria and move through API reference sections at a basic level. You do not need advanced technical knowledge, but you should be comfortable recognizing page titles, breadcrumbs, search results, and linked reference names. You will get the most value from this guide if the following are already true: | What you need | Why it matters | |---|---| | Access to a project workspace or published documentation | You need at least one place where entity pages can be opened | | Familiarity with API reference section lists | Entity pages are usually opened from those lists | | Basic comfort with breadcrumbs and search | These are the fastest ways to confirm location and reopen items | | Awareness of project vs public documentation views | Many navigation differences come from the current view | If you are still getting familiar with technical reference layouts, start with [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages). If your work happens mostly inside a project workspace, [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects) is the best companion for understanding internal navigation. If you often review released content, [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views) helps you understand how the same reference content appears in both contexts. You should also have at least one entity page available in Atloria—opened from a search result, reference index, namespace page, module page, or related symbol link—so you can follow the reading and navigation patterns described in the sections above. ## Opening the version comparison view for two releases To compare releases in Atloria, start from the **Releases** or version list inside your project workspace. This guide assumes you already know how to reach version records and monitor generation results from [Generating Documentation Versions and Monitoring Results](doc:generating-documentation-versions-and-monitoring-results). Before you begin, make sure you can open the release record for both versions you want to review. In the comparison view, teams usually work with two selections: - a **source release**, which acts as the baseline - a **target release**, which is the candidate being reviewed for approval or publishing In most release reviews, the **source release** is the last approved or published version, and the **target release** is the newer draft or generated version you want to evaluate. This makes it easier to answer the most important question: **what will change for readers if this release goes live?** Look for the release or version picker at the top of the comparison screen. Use it to choose the older release first, then the newer release. If your team compares the wrong direction, the results can still show changes, but the meaning of added and removed items may feel reversed during review. When choosing releases, pay attention to status labels shown in the version list or release record, such as: - **Draft** - **Published** - **Archived** A common review pattern is comparing a **Draft** candidate against the current **Published** release. Archived releases may still be useful as historical baselines, but they can introduce extra differences if they are not the most recent approved version. [SCREENSHOT: version comparison screen with source release and target release selectors highlighted] ## Reading what changed between the selected versions Once both releases are selected, Atloria shows a comparison view that helps you scan changes quickly before opening any page in detail. The main comparison area typically combines a results list with a content comparison panel so you can move from high-level review to page-level inspection without leaving the screen. Start with the changed-items list. This list groups documentation entries that differ between the two selected releases. Depending on your project structure, you may see changed pages, articles, navigation-linked content, or other documentation items. Each row in the list should help you identify the item by its title and related location information. Use the status labels in the results to understand the scope of the release: - **Added** means the page or content item exists in the target release but not in the source release - **Updated** means the item exists in both releases, but its content or details changed - **Removed** means the item existed in the source release and no longer appears in the target release - **Unchanged** helps confirm that an item was reviewed but did not change When you select an item, the comparison panel shows the difference in a side-by-side or diff-style layout. Look for visual highlights that mark inserted text, deleted text, and edited sections. This is especially useful for checking whether a page was lightly edited or substantially rewritten. Atloria may also surface metadata changes alongside body content changes. Watch for updates to fields such as: - **Title** - **Slug** or page path - **Last updated** - **Publish state** These details matter because a release can be affected by more than rewritten text. A renamed page, changed path, or different publish state can alter navigation, links, and reader access even when the body content looks similar. [SCREENSHOT: comparison results list showing Added, Updated, Removed, and Unchanged labels] ## Evaluating release readiness from the comparison results The comparison screen is one of the fastest ways to decide whether a candidate release is complete enough for approval. Instead of reviewing every page from scratch, use the changed-items list to confirm that the release includes the updates your team expected to ship. Begin by checking whether all planned documentation changes appear in the target release. If a feature launch was supposed to include a new getting started page, updated release notes, and revised setup instructions, each of those items should appear in the comparison results. Missing expected changes are often the first sign that the release is not ready. Pay close attention to three warning patterns: - **Missing removals** — old pages still appear even though they were supposed to be retired - **Unexpected additions** — new pages or entries appear that were not part of the release scope - **Incomplete edits** — a page shows as updated, but the actual content still looks partial or outdated Documentation Managers often review high-impact pages first because these pages shape the reader experience immediately. Prioritize items such as: - landing pages - navigation entries - release notes - setup or onboarding pages - pages linked from public navigation If these areas are wrong, the release can feel incomplete even when most supporting pages are correct. Technical Writers usually go one level deeper. They open updated pages and verify that the wording, structure, and coverage match the intended release scope. A page marked **Updated** is not automatically ready; it still needs to reflect the actual change set the team planned to publish. If the comparison shows the right pages, the right type of changes, and no obvious gaps, the release is usually in a strong position for formal review. For broader status and lifecycle context, pair this screen with [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). ## Using filters and detail views to investigate specific changes When a release contains many changed pages, filtering becomes essential. Atloria’s comparison view is most useful when you narrow the results to the type of work you need to review instead of scanning the full list repeatedly. Use the change-type filters to isolate items by status, such as: - **Added** - **Modified** or **Updated** - **Removed** This is especially helpful during focused review sessions. For example, if you are validating a cleanup release, filter to **Removed** first to confirm outdated pages were actually taken out. If you are checking a feature launch, filter to **Added** and **Updated** to review the new and revised pages together. Search within the comparison results when you need to find a specific item quickly. Search is useful for locating: - a page title - a path or slug - a known content entry under review After finding the item, open it from the results list to inspect the detailed differences. The detail view is where you can tell whether a change is minor editing or something more significant. For example, a small wording adjustment may only affect a few lines, while a structural change may alter headings, navigation labels, or page organization. If Atloria offers both a summary view and a detailed view, switch between them based on the review question: - use **summary** to understand release scope quickly - use **detailed view** to inspect exact wording and field-level changes This distinction matters during approval. Editorial fixes may be acceptable late in the process, while structural changes, path changes, or major content removals may require another review round before publishing. [SCREENSHOT: filtered comparison results with a search box and a selected page showing detailed differences] ## Supporting approval and publishing decisions with comparison data During release sign-off, the comparison view gives reviewers a shared, concrete view of what will change if the candidate version is published. Instead of relying on memory or scattered comments, the team can point to the exact pages and content differences shown in Atloria. Reviewers typically use the comparison screen to answer a few practical questions: - Does this release include all required documentation updates? - Are any unexpected pages being added or removed? - Do the changed pages match the approved release scope? - Are the changes small enough to approve now, or large enough to require more revision? This makes approval conversations more precise. A reviewer can open the candidate release, compare it against the current published release, and show exactly which landing pages, release notes, or setup pages changed. That evidence helps teams decide whether to move forward or pause. In general, teams tend to **approve immediately** when the comparison shows expected changes only, especially if high-impact pages are complete and the edits match the planned release. They may **request revisions** when the comparison reveals incomplete text, missing pages, accidental removals, or metadata changes that could break navigation. They may **delay publishing** when the release contains a large volume of unrelated edits or when the baseline comparison suggests the wrong release was used. Comparison results also support traceability. When reviewers discuss why a release was approved, rejected, or delayed, the comparison output serves as a record of what changed at that decision point. For teams with formal review practices, this works well alongside version review and approval workflows described in [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals) and [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval). ## Resolving common issues when comparing releases If the comparison view does not look right, the problem is often caused by the selected releases, active filters, or access limits rather than missing content. Start by checking the controls at the top of the comparison screen before assuming the release itself is wrong. If the comparison shows **no differences**, verify that the correct source and target releases are selected in the version picker. Teams sometimes compare a release against itself or choose two nearly identical drafts by mistake. Also confirm that you are comparing the intended baseline, usually the last approved or published release, against the candidate release. If an **expected page is missing** from the results, check two things: - whether the page belongs to the selected release - whether a filter is hiding it For example, if the results are filtered to **Removed**, you will not see pages that were only updated. Clear or adjust the change-type filter and search for the page title again. If you see **too many unrelated changes**, the baseline release may be too old. Comparing a current draft against an older archived release can make the candidate look much larger than it really is. Switch the source release to the most recent approved or published version to get a cleaner review. If a reviewer **cannot open comparison details**, the issue may be access-related. They may be able to see the release list but not open the changed content itself. In that case, confirm they have permission to view the release record and the related documentation entries. When comparison results still seem inconsistent, go back to the version list and confirm the status and identity of each release before restarting the review. ## Overview Atloria’s release comparison view is designed to help teams make publishing decisions based on visible, reviewable changes between two versions. Instead of checking pages one by one across separate tabs, you can compare a baseline release and a candidate release in one place and quickly see what was added, updated, removed, or left unchanged. The comparison workflow is most useful when you are close to approval and need confidence that the candidate release matches the intended scope. In practice, teams use it to: - compare the current **Published** release with a newer **Draft** - confirm that expected pages appear in the release - spot unexpected additions or removals - inspect detailed content differences before sign-off - support approval and publishing discussions with clear evidence The most effective review pattern is to start broad and then narrow your focus: - review the overall changed-items list - scan status labels such as **Added**, **Updated**, and **Removed** - prioritize high-impact pages like navigation entries and release notes - open detailed differences for any item that could affect release readiness This document focuses on the comparison stage only. If you need help generating versions or tracking generation progress before review, use [Managing Version Generation Jobs and Results](doc:managing-version-generation-jobs-and-results) and [Generating Documentation Versions and Monitoring Results](doc:generating-documentation-versions-and-monitoring-results). If you need broader guidance on version status and comparison workflows, see [Working with Version Comparison Views](doc:working-with-version-comparison-views). Used well, the comparison screen becomes the final checkpoint between a generated release and a publishing decision. ## Prerequisites Before comparing version changes in Atloria, make sure you already have access to the project workspace and can open the relevant release records. This task works best when the release has already been generated and is ready for review rather than still being created. You should have the following in place: - access to the project’s **Releases** or version list - at least two releases available to compare - permission to open release records and view documentation content - a clear understanding of which release is the current baseline and which is the candidate for approval In most teams, the baseline is the latest approved or published release, while the candidate is a newer draft under review. If you are unsure which versions to choose, confirm that before starting the comparison. Picking the wrong baseline can make the results misleading and create unnecessary review work. It also helps to know the intended release scope before opening the comparison view. Reviewers are much faster when they already know which pages, release notes, or navigation updates are expected. Bring that context into the comparison so you can quickly spot: - missing pages - unexpected removals - unrelated edits - incomplete updates If you have not yet generated the candidate version or checked its processing results, complete that work first using [Generating New Documentation Versions](doc:generating-new-documentation-versions) and [Monitoring Version Generation Progress and Results](doc:monitoring-version-generation-progress-and-results). After the comparison is complete and the release looks correct, the next step is usually formal review, approval, or publishing preparation. For that stage, continue with [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions). ## Opening Project Settings and Understanding What Can Be Changed After you finish project onboarding, the next place to work is the project’s **Settings** area. Open your project from the main workspace, then use the project navigation to go to **Settings**. This is where Atloria keeps the project options that can still be adjusted after the initial setup. If you already planned your project structure and content organization, keep that work in mind as you review settings here. For structure decisions, refer back to [Managing Project Structure and Content Planning](doc:managing-project-structure-and-content-planning). Inside **Settings**, look for grouped sections related to: 1. **Connected Services** or other connection-related options 2. **Website** settings for publishing destination and site behavior 3. **Operational** or control settings that affect syncing, publishing, and linked actions These sections are different from onboarding-only decisions. Onboarding helps you create the project and choose its starting setup path, but the **Settings** screen is where project administrators return later to update live behavior. If a choice is visible here as a field, switch, selector, or saved section, you can usually change it without recreating the project. As you move through the page, pay attention to how each setting is presented: - Text fields and dropdowns usually need **Save** - Toggles or switches may apply right away or may still require **Save** - Connection changes may require you to reconnect or reauthorize the linked service - Website changes may not be visible publicly until the project is published again [SCREENSHOT: Project Settings page showing Connected Services, Website, and Operational sections] Before changing anything, read the current values carefully. In Atloria, project settings often affect publishing destinations, connected accounts, and service behavior, so it helps to understand which section controls which part of the project before you start editing. ## Choosing Connected Setup Options for External Services Open the **Connected Services** or **Integrations** section in the project’s **Settings** area and review each listed connection one at a time. This section is where you manage how the project links to outside services used for publishing, syncing, or project-related workflows. Each connection may show its own status, selected account, workspace, endpoint, or authorization state. Use the available fields exactly as they appear on screen. Depending on what has been enabled for your project, you may see options such as a linked account selector, workspace selection, endpoint details, or other mapping choices that determine where the project sends or receives information. If a service is already connected, review the current values before changing them so you do not accidentally point the project to the wrong destination. 1. Open **Settings** in the project. 2. Select the **Connected Services** or similar connection section. 3. Click the service you want to review or edit. 4. Update the available fields, such as the linked account, workspace, or connection target. 5. Turn the connection on or off if that option is available. 6. Click **Save** if the section includes a save action. After saving, check the visible status on the same screen. Atloria may show a connection state such as connected, authorized, or another clear indicator that the service is ready. If the connection no longer shows as active after your change, reopen it and confirm that all required fields were selected correctly. When you disable one service, that should only affect that specific connection. You do not need to reconfigure unrelated project settings unless Atloria shows a warning that another linked option depends on it. [SCREENSHOT: Connected Services section with one service expanded, editable fields visible, and connection status shown] If you need broader guidance on organization-wide connections, see [Connecting and Managing External Integrations](doc:connecting-and-managing-external-integrations). ## Configuring Website-Related Project Behavior To control where your project publishes on the web, open the **Website** section inside the project’s **Settings** area. This is where Atloria shows the options that connect the project to its website presence and determine how documentation changes move from the project workspace to the published destination. Look for fields that identify the project’s web target. Depending on what your project uses, the screen may include a selected site, a publishing destination, a URL-related field, or environment-style choices that separate one web target from another. Use the values shown in the interface to confirm that this project is linked to the correct website location before you change publishing behavior. 1. Open the project and go to **Settings**. 2. Select the **Website** section. 3. Review the current site or publishing destination shown on the page. 4. Update the available website fields, such as the selected site or target destination. 5. Choose the publishing behavior shown in the available options. 6. Click **Save** to keep the changes. As you review publishing behavior, pay special attention to whether changes: - publish automatically - wait for review - remain unpublished until someone takes a separate publishing action Those choices affect how quickly project updates appear on the website. If your team uses approval steps or staged releases, make sure the website settings match that process. A project connected to the wrong site or set to the wrong publishing mode can send content to an unintended destination or make updates visible sooner than expected. After saving, stay on the page long enough to confirm the updated website value appears correctly. If Atloria shows the selected site, destination, or publishing state in a summary area, verify that it matches what you intended. [SCREENSHOT: Website settings section showing site selection and publishing behavior options] For more detail on broader website and publishing setup, see [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). ## Setting Operational Controls That Affect Publishing and Integrations The **Operational** settings in a project’s **Settings** area control how Atloria behaves when publishing, syncing, or responding to connected services. These controls are especially important when your project is linked to a live website or to services that can trigger updates automatically. Open the section that contains switches, checkboxes, or policy-style options related to publishing and syncing. Read each label carefully before changing it. Even a single toggle can change whether Atloria publishes automatically, waits for a manual step, or reacts to updates coming from a connected service. 1. Go to the project’s **Settings** page. 2. Open the operational control section. 3. Review each toggle, checkbox, or policy field before making changes. 4. Update only the controls related to the behavior you want to change. 5. Click **Save** if the section requires it. 6. Recheck the displayed state after saving. These controls often work together with your connected services and website settings. For example: - A service may be connected and authorized, but project controls may still prevent automatic actions - A website destination may be selected, but publishing may remain manual - A sync option may be available, but project rules may limit when updates are sent Because of that, do not assume a connected status means content will publish or sync immediately. Always compare the connection state with the project’s operational settings. If your project supports live publishing or external updates, coordinate changes with the people who manage documentation releases. A small change in operational behavior can affect when content appears publicly or when linked services begin acting on project updates. [SCREENSHOT: Operational settings area with publishing and sync-related toggles] If your project uses event-based connections, pair this review with [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). ## Managing Permissions and Safe Change Practices Before editing **Connected Services**, **Website**, or operational settings, make sure you have project administrator access. In Atloria, these settings affect how the project connects to outside services and how documentation may be published, so they should only be changed by people responsible for project-level administration. If you can open the project but cannot edit fields or save changes, your access level may not include these controls. In that case, work with someone who manages project permissions. For access guidance, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). When you are working on a live project, use a staged approach instead of changing several settings at once. Update one section, save it, and confirm the result before moving to the next. This makes it much easier to spot which change affected publishing or syncing behavior. Good change habits in Atloria include: - Write down the current values before you edit them - Change one connection or website option at a time - Save after each meaningful update instead of batching unrelated edits - Coordinate with other administrators so settings are not overwritten - Choose a low-impact time if the project is connected to a live site or active service A simple record can help a lot when multiple administrators work in the same project. Note the current connected account, selected site, publishing mode, and any operational toggles before saving new values. If the result is not what you expected, you can quickly compare the new setup with the previous one. [SCREENSHOT: Project settings page with editable fields highlighted for administrators] If a change could trigger syncing, republishing, or other downstream activity, tell the documentation manager before saving it. This is especially important when the project is already in active use and the published site is visible to readers. ## Verifying the Configuration After Saving Changes After you save any project setting, reopen the same **Settings** page and confirm the new values are still there. This is the quickest way to make sure Atloria accepted the update. Check each section you changed—**Connected Services**, **Website**, and operational controls—and compare the displayed values with the choices you intended to save. 1. Return to the project’s **Settings** page after saving. 2. Reopen each section you edited. 3. Confirm the saved values match your intended setup. 4. Review any visible status labels or indicators. 5. Perform a safe test action if your team allows it. 6. Confirm the result without changing unrelated settings. Look for visible status indicators that help confirm the project’s state. Depending on the section, Atloria may show signs such as: - connected - authorized - unpublished - pending sync - publish-ready These labels are useful because they tell you whether the project is merely configured or actually ready for the next action. For example, a service may be saved but still need reconnection, or a website target may be selected while the project remains unpublished. If possible, run a low-risk test. That might mean checking whether a small publishing action follows the selected behavior or confirming that a connected service reflects the updated project link. Keep the test narrow so you do not affect unrelated project settings or release work. If something does not look right: - check whether you clicked **Save** - reopen the section and confirm no field was left incomplete - reconnect the affected service if the authorization state changed - verify the project is linked to the correct website or destination [SCREENSHOT: Saved settings with visible connected and publishing status indicators] For broader publishing validation, continue with [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release). ## Overview This document focuses on the project settings you manage after onboarding is complete. In Atloria, those settings are centered around three practical areas: **Connected Services**, **Website**, and operational controls that influence publishing and sync behavior. The goal is not to repeat project creation or structure planning, but to help project administrators safely adjust the live configuration that controls where documentation goes and how linked services behave. You will use these settings when a project needs to point to a different website destination, when a connected service must be updated or reauthorized, or when publishing behavior needs to change from automatic to manual review. These are ongoing administration tasks, not one-time onboarding choices. If you need help with the earlier setup path that led to this point, refer to [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) and [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). This guide also emphasizes safe change practices. In many teams, project settings are shared responsibilities, and a small update can affect public publishing, background syncs, or service-triggered actions. Because of that, the guide shows how to review current values, save changes carefully, and confirm visible status indicators after each update. Use this page when you need to: - update a project’s connected service details - review or change website publishing targets - adjust project-level publishing or sync controls - verify that saved settings are active and behaving as expected If you are already comfortable with project structure and content planning, this guide is the next step in getting the project ready for controlled delivery and connected workflows. ## Prerequisites Before working through these settings in Atloria, make sure the project has already been created and onboarding is complete. This guide assumes you are no longer choosing the initial setup path and are now managing the project’s ongoing configuration. If you still need to finish those earlier steps, start with [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) and [Managing Project Setup Decisions After Onboarding](doc:managing-project-setup-decisions-after-onboarding). You should also have: - access to the correct project workspace - project administrator permission to edit **Settings** - a clear understanding of the project’s intended website or publishing destination - confirmation of which connected services the project is expected to use - awareness of any team process for review, approval, or scheduled publishing changes It also helps if you have already completed the planning work covered in [Managing Project Structure and Content Planning](doc:managing-project-structure-and-content-planning). That earlier planning does not control delivery settings directly, but it gives useful context when you decide how the project should publish and which connected services it should rely on. Before making changes, gather the information you will need from the current project setup screen itself. Review the existing connected account, selected website destination, and any visible publishing or sync controls. If multiple administrators work in the same project, align on who is making the update so one person’s changes do not overwrite another’s. If the project is already tied to a live website or active service connection, plan your edits for a time when a brief configuration change will have the least impact on documentation work or public visibility. ## Starting a Conversation with a Support Agent In Atloria, start from the support chat area you already used in [Chatting with Support Agents and Managing Conversations](doc:chatting-with-support-agents-and-managing-conversations). When the chat panel opens, look for the main message box at the bottom of the conversation area. This is where you type your question. Nearby, you should see the **Send** control and the current conversation area above it. Before you send the first message, check the top of the chat panel. The header is the easiest place to confirm whether you are in an existing thread or starting a fresh one. If Atloria shows an assigned support agent in the header or participant area, that tells you who is currently handling the conversation. If no earlier messages appear and the composer is empty, you are likely creating a new session. 1. Open the support chat from the in-app help or support entry point. 2. Review the conversation header to see whether an agent name, participant label, or session status is already shown. 3. Click into the message field and enter your request clearly. 4. If the conversation screen offers linked context, add it before sending so the agent can understand the issue faster. 5. Click **Send** to create the session and post your first message. After sending, watch the conversation area for status changes. A new session may first appear as waiting for a response, then move into an active back-and-forth once the agent replies. If Atloria marks the conversation as closed or resolved later, that status usually appears in the thread header, history list, or near the latest message. [SCREENSHOT: Support chat panel showing the message composer, send button, conversation header, and assigned agent area] ## Reviewing Messages and Conversation History When you need to revisit earlier support discussions, open the conversation history or session list from the support chat area. Atloria separates current work from older threads by showing each conversation as its own entry. The list is useful for spotting which sessions still need attention and which ones have already been completed. Open a conversation from the list and read the transcript from top to bottom. The message timeline normally shows your messages, agent replies, and the time each message was added. If Atloria displays status markers, you may also see labels that show whether the conversation is active, resolved, or otherwise completed. These markers help you decide whether to continue the same thread or begin a new one. Use the visible details around the transcript to understand the session at a glance: | What to look for | Where you may see it | Why it helps | |---|---|---| | Status label | History list or thread header | Shows whether the session is still open | | Assigned agent | Header or participant area | Confirms who handled the request | | Created date | Session details area | Helps identify older threads | | Last updated time | History list or details area | Shows recent activity | | Outcome or resolution label | Header, footer, or details area | Tells you how the conversation ended | If you send another message from inside an existing open thread, Atloria usually adds it to that same transcript. If the earlier session has already been closed, Atloria may place your new message into a separate session instead. For a fuller introduction to browsing and organizing threads, see [Managing Agent Conversations and Chat History](doc:managing-agent-conversations-and-chat-history). [SCREENSHOT: Conversation history list with active and completed sessions, plus an open transcript with timestamps] ## Following Up on an Existing Session A follow-up works best when you continue the same conversation instead of starting over. In Atloria, open the support history list, select the earlier session, and check whether the thread still accepts replies. If the conversation remains open, the reply field should still be available at the bottom of the transcript. 1. Open the support history list. 2. Select the conversation you want to continue. 3. Review the latest agent reply and the current status shown in the thread. 4. Use the reply field to add your update. 5. Click **Send** to keep the follow-up in the same thread. When writing a follow-up, refer directly to what already appears in the transcript. Mention the troubleshooting step you tried, the answer that did not solve the problem, or the part of the guidance that needs clarification. This keeps the conversation focused and makes it easier for the assigned agent to continue without repeating earlier questions. Atloria may handle follow-ups differently depending on the session state. If the thread is still open, your new message usually updates the same conversation and refreshes the last activity time in the history list. If the session is marked closed or resolved, Atloria may stop additional replies and prompt you to begin a new conversation instead. In some cases, a follow-up can also change the status back to active if the thread is reopened. You may also notice that the assigned agent changes after a follow-up. If Atloria reassigns the conversation, the updated agent name should appear in the thread header or participant area. That change is especially important when a question moves from a simple clarification to a more involved support issue. [SCREENSHOT: Existing support thread with reply box, status label, and updated last activity time] ## Resetting a Session When the Conversation Needs a Fresh Start Sometimes a conversation becomes too cluttered to be useful. This usually happens when several unrelated issues are mixed into one thread, when old troubleshooting steps no longer apply, or when the conversation has been routed to the wrong person. In those cases, use the reset or new-session option instead of continuing the existing transcript. Look in the conversation header or the overflow menu for a control such as **Reset**, **Restart**, or **New Session**. The exact label may vary, but the purpose is the same: start fresh without deleting the earlier record. 1. Open the conversation that is no longer useful. 2. Check the header or overflow menu for the reset or new-session option. 3. Select the option to start over. 4. Confirm the action if Atloria asks for confirmation. 5. Verify that a fresh thread opens with an empty message field. A session reset clears the active conversation context for the new exchange. That means the next message starts as a separate thread rather than continuing the earlier back-and-forth. Your previous conversation history should still remain available in the history list for reference, so you can look back at earlier answers without carrying that context into the new session. Support leads should recommend a reset when: - The thread contains multiple unrelated topics - The earlier troubleshooting path is outdated - The conversation was picked up by the wrong agent - The transcript has become too long to follow clearly - A resolved issue is being confused with a new request After the reset, confirm that Atloria shows a new session entry in the history list. The new thread should have its own activity record, while the older conversation remains visible as a separate item. [SCREENSHOT: Conversation header or menu showing the reset or new-session option and a fresh empty thread afterward] ## Using Conversation Outcomes to Improve Support Workflows Conversation follow-up is not only about finishing one support request. In Atloria, completed sessions can also show patterns that help documentation managers and support leads improve how support works overall. Start by reviewing the outcome shown on completed conversations. Depending on what Atloria displays, this may include a resolved status, a follow-up-needed label, an escalation result, or another closure marker attached to the session. When you review several completed threads together, look for repeated themes rather than isolated comments. For example, if many conversations end with follow-up needed, the original answers may not be clear enough. If you see frequent resets, users may be combining too many topics in one session or agents may not be steering the conversation toward a clean resolution. Repeated handoffs between agents can point to routing problems or unclear ownership. Documentation managers can use these patterns to improve content that supports the agent experience: - Update help pages that are repeatedly referenced in transcripts - Expand internal guidance where agents give inconsistent answers - Improve canned responses if the same explanation appears in many threads - Add missing troubleshooting steps to project documentation Support team leads can review session outcomes and agent-specific trends to improve day-to-day handling: - Check which agents receive the most follow-up messages - Compare resolved sessions with sessions that are repeatedly reopened - Identify where escalations happen most often - Adjust routing so similar questions reach the right agent sooner This kind of review works best when paired with the conversation practices covered in [Managing Agent Conversations and Chat History](doc:managing-agent-conversations-and-chat-history). Clean session records make outcome trends much easier to trust and act on. [SCREENSHOT: Completed conversation list showing status or outcome labels that can be compared across sessions] ## Fixing Common Problems with Conversation History and Session Follow Up Most conversation issues in Atloria come from session state, filters, or how the earlier thread was closed. When something looks wrong, start by checking what the conversation list is actually showing before assuming messages were lost. If conversation history seems missing or incomplete, make sure you are viewing the correct workspace and the right history list state. A filter can make older sessions disappear from view even though they still exist. Also confirm that you are signed in to the same Atloria account you used for the original conversation. If the wrong workspace or filtered list is open, the transcript you need may not appear. If a follow-up message starts a new thread unexpectedly, open the earlier conversation and check its status. A session marked closed, resolved, expired, or otherwise unavailable for replies may force Atloria to create a separate thread. This is expected behavior when the earlier session is no longer open for continuation. If you cannot find a reset or restart option, look at the current conversation state. Atloria may only allow reset actions on certain sessions. In some workspaces, the option may appear only while a thread is active. Permissions can also affect whether you see restart controls in the header or menu. If outcome data is not useful for reporting, the issue is often consistency rather than missing conversations. Review whether agents are ending sessions with clear status and closure details. If some conversations are left without a final outcome while others are marked resolved, the history list becomes harder to compare. Common checks: - Confirm you are in the correct account and workspace - Review any active filters in the conversation list - Check whether the earlier thread is closed or still open - Look in both the thread header and overflow menu for session actions - Make sure completed conversations include clear outcome labels ## Overview This guide focuses on what happens after you already know how to open and use support chat in Atloria. Instead of repeating the basics, it shows how to continue a conversation over time, return to older sessions, decide when to reply versus restart, and use completed conversations to improve support quality. The main areas covered are: - Starting a new support session from the chat panel - Reviewing earlier messages in the conversation history - Sending follow-up replies in the same thread - Resetting a session when the current thread is no longer helpful - Reading conversation outcomes to spot workflow issues - Fixing common problems with missing history or unexpected new threads This topic is especially useful for documentation managers, support team leads, and regular Atloria users who work with support agents more than once on the same issue. If you are handling ongoing questions about documentation, project setup, or support agent behavior, session follow-up helps you keep that work organized. Use this guide alongside: - [Chatting with Support Agents and Managing Conversations](doc:chatting-with-support-agents-and-managing-conversations) for the basics of sending messages and working in the chat area - [Managing Agent Conversations and Chat History](doc:managing-agent-conversations-and-chat-history) for browsing, sorting, and reopening earlier threads The goal is simple: keep each support thread clear, make follow-up easier for both sides, and turn completed conversations into useful signals for better documentation and better support handling. ## Prerequisites Before using the steps in this guide, make sure the following are already true in Atloria: - You can sign in to your Atloria account and reach the main workspace - You already know how to open the support chat area - You have access to at least one support conversation or can start a new one - You are comfortable reading the conversation list and opening a thread - You understand the basic chat workflow from [Chatting with Support Agents and Managing Conversations](doc:chatting-with-support-agents-and-managing-conversations) - You are familiar with reopening earlier threads from [Managing Agent Conversations and Chat History](doc:managing-agent-conversations-and-chat-history) It also helps if you can recognize the key parts of the conversation screen: - The thread header - The message timeline - The reply or message composer - The **Send** control - The history or session list - Any visible status or outcome labels If you are working as a support lead or documentation manager, you will get the most value from this guide when you can review multiple completed conversations rather than a single thread. That makes it easier to spot repeated resets, unresolved follow-ups, and common transcript themes that should feed back into your help content or support process. For related admin-side review of analytics and audit activity in Atloria, continue with [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Opening preview screens and understanding page status If you already know the basics of public checks from [Understanding Document Preview and Public Page Checks](doc:understanding-document-preview-and-public-page-checks), this section focuses on the review flow inside Atloria while you are preparing a release. From your project workspace, open the documentation page list and select the page you want to review. Writers usually enter preview in one of two ways: by opening a page-level preview from the page they are editing, or by switching into a release preview while reviewing a version. Use the preview option that matches your goal. A page preview helps you inspect one page quickly. A release preview helps you confirm how that page appears inside the selected version. [SCREENSHOT: page list with a selected documentation page and preview option] When the preview opens, check the header before you start reading. The header is your first confirmation that you are reviewing the correct content. Look for these details: | Header item | What to confirm | |---|---| | Document title | You opened the intended page | | Version or release label | You are in the correct release context | | Locale | You are viewing the right language variant | | Last updated information | You are not reviewing an older saved state | > **Tip:** If the page content looks unfamiliar, check the version or release label first. Many review mistakes happen because the preview is showing versioned content instead of the latest draft. Page status matters just as much as page content. In preview-related screens, look for signs that the page is still a draft, has changed since the last release, or is already published. Use those status cues to separate unreleased edits from content that readers can already see. Stay inside preview while you move through the documentation set. Use the table of contents, sidebar links, and nearby page links to move between related pages. This makes it easier to review flow, structure, and page order without jumping back to the main page list each time. ## Comparing page revisions before approving changes Before you approve a page for release, open its comparison view and make sure you are comparing the right two versions. In Atloria, this usually means checking the current draft against the last published page, or comparing one saved revision with another. The comparison screen is only useful when the comparison targets match your review question. Start by confirming the labels for both sides of the comparison. If one side is the draft and the other is the published version, you are checking what will change for readers. If both sides are saved revisions, you are checking how the page evolved during editing or review. ### Reading change markers Once the correct comparison is open, scan the change markers before reading line by line. Look for: - added text - removed text - heading changes - list changes - code block changes - moved or restructured sections These markers help you spot edits that affect meaning, page structure, or readability. A heading change can alter navigation. A list change can affect instructions. A code block change can affect technical accuracy for readers. ### Choosing the best comparison layout If Atloria offers more than one comparison layout, use the one that fits the page: 1. Use side-by-side comparison when you want to review wording and layout together. 2. Use inline comparison when you want to read the page in a single flow. 3. Switch views if a long section is hard to follow in the current layout. [SCREENSHOT: comparison screen showing two revision targets and highlighted changes] Do not stop with body text alone. Check whether links, screenshots, embedded media, or internal document links changed at the same time. A page may look almost identical in the text comparison while still containing updated assets or changed cross-references. Those non-text changes often affect release quality just as much as rewritten paragraphs. ## Reviewing multi-page changes in preview mode When a release includes more than one edited page, review the changed pages as a set instead of opening pages at random. In Atloria, use the preview page list or any changed-pages view available in the version workspace to narrow your review to pages modified since the last release candidate. This keeps your attention on content that actually needs approval. [SCREENSHOT: release preview showing a filtered list of changed pages] ### Checking structure across several pages As you move through the preview, verify that structural edits still make sense in the full documentation set. Focus on: - navigation labels in the sidebar - parent and child page relationships - page order in the table of contents - section names that appear in menus and links A page can read well on its own but still create confusion if it sits in the wrong place or uses a label that no longer matches nearby pages. ### Checking consistency between pages After structure, review repeated content patterns. Compare similar pages and make sure they render consistently. Look closely at: - heading levels - callout boxes - warning or note blocks - reusable snippets - screenshot placement - spacing around lists and tables > **Watch for this:** Reusable content can appear correct on one page and look broken on another. If a note box, snippet, or repeated instruction appears in several places, open more than one page in preview before marking the release ready. If your project uses more than one language or more than one release, test the selectors while you stay in preview. Switch the locale or version and confirm that the expected page variant appears. This is especially important when the same page title exists across multiple releases. You want to confirm that Atloria is showing the correct page, not just a page with a familiar name. ## Running quality checks before content enters a release Before content moves into a versioned release, review the quality check results in the release workflow. In Atloria, these checks help you catch issues that are easy to miss during visual review. Open the quality check panel or validation results and work through the flagged items one by one. Common issues to watch for include: - broken links - missing page titles - empty descriptions - unresolved references - pages that still need review These checks tell you whether the content is complete enough to move forward, even if the page looks fine at first glance. ### Checking visual rendering issues After reviewing the issue list, return to preview and inspect the page itself. Some problems only appear when the page is rendered. Look carefully for: - malformed tables - code blocks that overflow the page - missing images - incorrect heading order - content sections that look collapsed or misaligned [SCREENSHOT: quality check panel beside a page preview with flagged issues] ### Confirming release readiness Use the release readiness indicators in the version workspace to confirm whether the documentation set is ready for the next step. Reviewers and documentation managers typically look for all required checks to pass and for no pages to remain in an unreviewed state. If Atloria still shows unresolved issues, do not rely on visual review alone. When you find a problem, record the follow-up directly from the review flow if that option is available. Assigning or noting the fix while the issue is visible reduces the chance of missing it later. This is especially useful when the problem affects several pages, such as a repeated broken link or a missing description pattern across a section. ## Confirming what will appear in the versioned release The final review step is confirming the exact content that will appear in the upcoming release. This means switching from draft preview to release preview and checking the versioned view, not just the latest working draft. In Atloria, that distinction matters because a writer may still have unpublished edits that are not meant to ship. Start in the selected version or release workspace, then open the release preview. Read the page as a reader would see it in that release. Confirm the page body, sidebar placement, and page metadata together so you are not approving text without checking where and how it appears. ### Verifying version-specific details Pay close attention to version-related details in the preview header and navigation. Check: | Item to review | Why it matters | |---|---| | Release label | Confirms the page belongs to the intended release | | Canonical page path | Helps prevent publishing to the wrong page location | | Version switcher entry | Confirms readers will find the page under the right version | ### Separating release content from work in progress If you suspect a mismatch, compare the release snapshot against the current unpublished draft. This helps you separate work in progress from content intended for versioning. It is a useful check when a page has recent edits but only part of that work should appear in the release. > **Final review note:** Sign off only after you confirm that required pages, screenshots, embedded assets, and internal links are present in the release preview. A clean draft page is not enough if the release preview is missing supporting content. Use this step to make a final yes-or-no decision. Once the release preview matches your expectations, you can move into the broader release process described in [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval). ## Fixing common preview and comparison issues When preview or comparison results look wrong, start by checking the review context before assuming the page content is broken. In Atloria, many apparent issues come from opening the wrong preview type, comparing against the wrong revision, or reviewing a release snapshot instead of the latest draft. ### When preview does not match the editor If the preview does not match what you just edited, check whether you are looking at: - the latest draft - an older saved state - a release preview - a versioned snapshot A mismatch often happens when you switch from editing into a release view without noticing the release label in the header. ### When comparison results seem unexpected If the comparison screen shows changes you did not expect, verify the selected base revision first. You may be comparing the current draft to an older published page instead of the most recent saved revision. Also consider whether shared content changed. Reusable snippets, shared text blocks, or linked content can create differences on several pages at once. ### When images or assets are missing If screenshots, images, or embedded items do not appear in preview, confirm that the asset is available in the release or locale you are reviewing. Then check whether the page is pointing to the correct file and whether the selected preview context includes that asset. ### When quality checks fail but the page looks fine Some issues are not obvious in the visible page body. Review the flagged details for hidden problems such as: - broken anchor links - duplicate headings - blank metadata fields - unresolved internal references [SCREENSHOT: failed quality check list showing hidden page issues] For broader release comparison work, continue with [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). ## Overview This guide covers the review work that happens between editing and release approval in Atloria. It focuses on four connected tasks: opening the correct preview, comparing page revisions, checking multi-page changes, and confirming quality results before a version is finalized. Use this guide when you need to answer questions such as: - Am I reviewing the latest draft or the release snapshot? - What changed on this page since the last published version? - Did structural edits affect navigation or page order? - Are there unresolved issues that block release readiness? - Will the selected version include the correct pages and assets? This guide assumes you are already comfortable editing pages and using standard preview checks. If you need a refresher on basic preview behavior and public-facing checks, return to [Understanding Document Preview and Public Page Checks](doc:understanding-document-preview-and-public-page-checks). If you need help with page editing before review, see [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages). ### Table of contents - Opening preview screens and understanding page status - Comparing page revisions before approving changes - Reviewing multi-page changes in preview mode - Running quality checks before content enters a release - Confirming what will appear in the versioned release - Fixing common preview and comparison issues The goal is not just to read pages one by one. It is to confirm that the right content, structure, and supporting assets will appear in the right release, with no hidden issues left behind. ## Prerequisites Before you use the workflows in this guide, make sure you can already access the parts of Atloria involved in document review and release preparation. You should have: - access to the project workspace that contains the documentation pages - permission to open document previews and version-related review screens - at least one page draft, saved revision, or release candidate to review - familiarity with the documentation page list and project navigation - a basic understanding of version review from earlier guides Helpful background reading includes: - [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content) - [Managing Document Comparisons During Content Updates](doc:managing-document-comparisons-during-content-updates) - [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) - [Understanding Version Lifecycle and Release Readiness](doc:understanding-version-lifecycle-and-release-readiness) If your review also includes screenshots or other visual assets, it may help to keep these guides nearby: - [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) - [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release) For teams working across multiple releases, languages, or approval stages, it is also useful to understand the wider release process in [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review). ## Defining the Documentation Project Before You Start Writing When you reach project setup in Atloria, use the onboarding form to define the project clearly before you create any pages. This is where you set the basic details that shape the rest of your documentation work. Enter the **Project name** exactly as your team wants it to appear in project lists and related workspaces. If your setup flow includes ownership details or a project brief area, add the internal owner there so everyone knows who is responsible for decisions during setup, review, and publishing. Use the onboarding fields or project brief to record what this documentation project will cover. Be specific about which product areas, modules, or user workflows are included. Just as important, note what is out of scope so your page plan does not grow too early. If your team already worked through setup readiness in [Managing Project Creation Choices and Setup Readiness](doc:managing-project-creation-choices-and-setup-readiness), use those decisions here instead of redefining them. If Atloria shows fields for audience or project intent, use them to identify who the documentation is for. For example, you may be planning content for administrators, end users, or internal teams. This helps you choose the right page titles and section groupings later. Where contributor or team assignment options are available during setup, assign clear ownership for planning work. Typical responsibilities include: - A documentation lead for structure and publishing decisions - A writer for draft creation - A reviewer for validation - A project administrator for final setup control If a target release, launch date, or version label is available, enter it during onboarding so the project timeline matches the documentation plan. [SCREENSHOT: Project onboarding screen showing project name, owner, audience, and release planning fields] ## Building the Initial Page Hierarchy Once the project exists in Atloria, move to the page structure or navigation area and start building the first version of your documentation hierarchy. This is the best time to create the main sections users will expect to see when they browse the project. Keep the top level simple and task-focused. Common section patterns include onboarding, configuration, daily workflows, and administration. These labels help readers understand where to go without needing internal team knowledge. Follow these steps to build the first structure: 1. Open the project workspace and go to the page list, structure view, or navigation tree. 2. Create the top-level sections that represent the biggest user goals, such as getting started, setup tasks, routine work, and admin tasks. 3. Under each top-level section, add child pages for the specific tasks users need to complete. 4. Arrange the pages in the order you want readers to follow them. 5. If Atloria lets you drag and drop pages, use that control to move related topics under the correct parent page. 6. Leave lower-priority topics out of the main structure if they are not needed for launch, or keep them clearly marked as planned or draft if that option appears in the page list. Choose page names that describe what the reader will do. For example, a title built around an action is easier to scan than a title based on internal product language. This keeps the sidebar and page list useful from the start. As you build the structure, check whether each child page belongs under the correct parent page. If a page could fit in several places, rename it or move it until its purpose is obvious. [SCREENSHOT: Project page hierarchy with top-level sections and child pages arranged in order] ## Organizing Scope with Content Types and Ownership After the first hierarchy is in place, use Atloria’s page details, assignments, and status options to organize the work behind that structure. A page list is much easier to manage when each item has a clear purpose, a clear owner, and a clear status. This prevents the project from becoming a long list of untitled drafts with no review path. Start by classifying each planned page by content type if Atloria gives you template, type, or category choices. You may separate pages into groups such as onboarding, guide, reference, or troubleshooting. Even at the planning stage, this helps your team keep similar pages consistent. A getting-started page should not be structured the same way as a troubleshooting page, so this early sorting matters. Next, assign responsibility. Use assignment fields, contributor lists, or review settings in the project workspace to connect each page or section to the right person. A simple planning model looks like this: | Planning item | What to assign | |---|---| | Main section | Section owner | | Draft page | Writer | | Accuracy review | Reviewer | | Final release decision | Approver or project administrator | Then separate launch content from later content. If Atloria shows status labels such as **Planned**, **In Progress**, **Review**, or **Deferred**, use them consistently. Mark must-have launch pages first, and move lower-priority topics into a deferred group rather than mixing them into the active writing list. If your team works by release or milestone, group related pages into those buckets so the structure matches the rollout schedule. This makes it easier to see which pages support the next release and which pages can wait. [SCREENSHOT: Page list showing content type, owner, reviewer, and status columns] ## Making Early Decisions About Templates, Metadata, and Navigation Before anyone starts drafting, decide how pages should be structured and labeled in Atloria. Early consistency saves time later, especially when several contributors are creating pages in the same project. If Atloria lets you choose a page template when creating or planning a page, select the right one up front. A task guide, a reference page, and an onboarding page usually need different layouts, so choosing the right format early helps keep the project organized. Use page settings or planning fields to define the metadata every page should include. If these fields are available, make sure contributors know which ones are required and how they should be filled in. | Metadata field | How to use it during planning | |---|---| | Title | Use a task-based page name readers can scan easily | | Description | Add a short summary of what the page helps the reader do | | Audience | Identify whether the page is for administrators, end users, or internal teams | | Keywords | Add terms that match how readers search for the topic | | Version or release tag | Link the page to the correct release or launch cycle | Navigation planning matters just as much as page content. Review sidebar groupings, parent-child relationships, and landing-page links so readers can move naturally from onboarding into setup, then into daily tasks. If two pages seem to answer the same question, combine them or separate their purpose before drafting begins. Standardize naming as early as possible. Use one pattern for folders, one pattern for page slugs if Atloria exposes them, and one pattern for section headings. For example, if one page starts with “Setting Up…” and another starts with a product term only your team understands, rename them so the sidebar feels consistent. [SCREENSHOT: Page setup panel showing template choice and metadata fields] ## Reviewing the Plan with Stakeholders Before Authoring Begins Before writers begin filling pages with content, review the planned structure with the people who will depend on it. In Atloria, this usually means sharing the project workspace, page list, or navigation plan with product, support, training, and documentation stakeholders. The goal is to confirm that the structure reflects real user needs before your team spends time writing and reviewing drafts. Use a structured review process so the conversation stays focused: 1. Open the project workspace and display the current page hierarchy or page list. 2. Walk through each top-level section in reading order. 3. Confirm that every critical onboarding, setup, and operational workflow has a planned page. 4. Ask stakeholders to identify any missing user journey, duplicate topic, or misplaced page. 5. Review ownership and approval responsibilities for each major section. 6. Confirm who will handle draft review, technical validation, and publishing decisions. 7. Update the hierarchy, statuses, or assignments while feedback is still fresh. 8. Once the group agrees, treat that structure as the baseline plan for the project. This review is also the right time to decide how future changes should be handled. If your team wants tighter control, ask the project administrator to manage major structure changes after approval. That keeps the navigation stable while writers work. When you finish the review, make sure everyone understands which pages are approved for drafting now and which pages remain planned for later. A stable baseline helps prevent constant rework and keeps the project moving toward release. [SCREENSHOT: Stakeholder review of project hierarchy and page assignments in the project workspace] ## Fixing Common Planning Problems Early Even a well-planned project can become messy if you do not correct small structure problems early. Atloria makes these issues easier to spot when you review the page list, hierarchy, assignments, and statuses together. The sooner you fix them, the easier the writing phase will be. One common problem is having too many top-level pages. If the navigation tree feels crowded, merge overlapping sections and move detailed topics into child pages. Readers should not have to scan a long list of unrelated items at the top level just to find a basic task. Another frequent issue is unclear ownership. Open the page list and check the assignment or contributor fields. If a page has no writer, reviewer, or approver attached to it, assign one before drafting starts. Unowned pages often remain unfinished or get reviewed too late. Scope expansion is another risk. If new ideas keep appearing during planning, return to the project brief or onboarding notes and compare them against your in-scope and out-of-scope decisions. Move extra topics to a deferred status instead of adding them directly into the active launch structure. This keeps the first release realistic. Inconsistent naming also causes confusion. Scan the planned titles in the page list and look for mixed patterns. Rename pages so they follow the same style, especially in the sidebar. Task-based titles are usually easier for readers to understand than internal labels. Use this quick check when reviewing the structure: - Too many top-level pages: combine or nest related topics - Missing owner: assign a writer, reviewer, or approver - Expanding scope: move extra topics to **Deferred** - Mixed naming style: rename pages to follow one task-based pattern These small corrections make the project easier to review, easier to draft, and easier to publish later. ## Overview This stage of project setup in Atloria focuses on turning early onboarding decisions into a usable documentation plan. Instead of starting with draft pages immediately, you first shape the project structure so contributors know what to write, where each topic belongs, and who is responsible for it. The work in this stage usually happens inside the project workspace, page hierarchy, and page planning views. The main goal is to create a structure that readers can follow. That means defining the project clearly, building a sensible page hierarchy, assigning ownership, and deciding how pages should be labeled and grouped. It also means separating launch-critical content from topics that can wait until after release. If you have already completed the setup readiness work in [Managing Project Creation Choices and Setup Readiness](doc:managing-project-creation-choices-and-setup-readiness), this document helps you turn those decisions into a practical page plan. In Atloria, strong planning usually includes: - A clear **Project name** and ownership record - A page hierarchy with top-level sections and child pages - Status labels that show what is planned now versus later - Page assignments for writing, review, and approval - Consistent titles, metadata, and navigation labels This planning stage does not replace document authoring. It prepares the structure so authoring goes faster and produces a cleaner result. Once your hierarchy, ownership, and review path are stable, you can move on to the next setup decisions around delivery options and connected services in [Configuring Project Delivery Options and Connected Services](doc:configuring-project-delivery-options-and-connected-services). ## Prerequisites Before you work on project structure and content planning in Atloria, make sure the project has already been created and the earlier onboarding choices are settled. This document assumes you are not deciding whether to create a project or how to begin setup. It assumes you are ready to organize the documentation inside the project workspace. You should have the following in place before starting: - Access to Atloria with permission to open the project workspace - A project that has already been created during onboarding - Basic setup decisions already reviewed in [Managing Project Creation Choices and Setup Readiness](doc:managing-project-creation-choices-and-setup-readiness) - A rough understanding of the product areas, workflows, or modules the documentation should cover - The names of the people who will write, review, or approve content - A target release, launch window, or documentation milestone if your team is working to a schedule It also helps if you already know the main audience for the project, such as: - Administrators - End users - Internal teams If your team plans to use approvals, versioning, or publishing controls later, gather that information now so you can reflect it in page ownership and status planning. You do not need final page text yet, but you should be ready to create a page hierarchy, assign responsibilities, and identify which topics are required for launch. If you are still choosing how the project should be set up, return to [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup) or [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) before continuing. ## Preparing Your Workspace for Shared Prompt Templates Before your team starts creating prompt templates in Atloria, agree on who will manage them and where people should go to find them. This avoids duplicate templates, conflicting instructions, and outdated prompts being reused across documentation and support work. Start by deciding which team members will maintain shared templates. In most teams, this usually means: - a Documentation Manager who defines writing style and article structure - a Support Team Lead who sets response patterns for customer-facing replies - a Project Administrator who manages workspace-level setup and keeps the shared template area organized Next, choose one place in Atloria where your team will store reusable prompts. Your team may keep them in a shared prompt repository, a workspace template list, or a team knowledge base collection. What matters most is that everyone uses the same location instead of saving personal copies in different places. Before creating any template, agree on the fields every entry must include. A simple structure makes templates easier to review and update later. | Field | What to enter | Why it matters | |---|---|---| | Template name | A clear task-based title | Helps users pick the right template quickly | | Purpose | A short description of when to use it | Prevents misuse | | Prompt body | The full reusable instruction | Keeps output consistent | | Variables or placeholders | The parts users will replace for each request | Supports repeat use | | Owner | The person responsible for updates | Makes review easier | | Last-reviewed date | The most recent review date | Shows whether the template is current | Finally, decide which workflows to support first. In Atloria, common starting points include: - documentation drafting - article rewriting - support reply generation - escalation handoff responses [SCREENSHOT: Shared prompt template area showing template list, owner, and last-reviewed date] ## Creating Reusable Templates for Documentation and Support Work When you create a reusable prompt template in Atloria, build it around one specific task. A focused template is easier to use, easier to review, and more likely to produce consistent results. 1. Open the shared template area your team uses in Atloria and click the option to create a new template entry. 2. In the **Template name** field, enter a clear workflow label. Good examples include **Docs Article Draft**, **Support Refund Reply**, **Troubleshooting Summary**, or **Escalation Handoff**. The name should tell users exactly what kind of output they will get. 3. In the **Purpose** field, describe when to use the template. For example, you might note that one template is for first-draft help center articles, while another is only for customer support replies. 4. In the main prompt text area, write the base prompt body. Include the tone, expected structure, response length, and any limits the AI should follow. This is where you define the standard so users do not have to rewrite instructions every time. 5. Add reusable placeholders for the parts that change from one request to the next. These might include product name, issue summary, customer tier, article audience, feature area, or required response length. 6. Save the template and review how it appears in the shared list so the name and purpose are easy to scan. Keep separate templates for separate jobs. For example: - one template for troubleshooting articles - one template for article rewrites - one template for chat replies - one template for email responses - one template for escalation notes Avoid combining all of these into one large prompt. If users have to delete half the instructions before using a template, it is too broad. [SCREENSHOT: New prompt template form with Template name, Purpose, Prompt body, and placeholders] ## Organizing Templates So Teams Can Find the Right One Quickly As your template library grows in Atloria, organization becomes just as important as the prompt wording itself. If users cannot tell which template to choose, they will either pick the wrong one or write a new prompt from scratch. Start by grouping templates in a way that matches how your team works. A simple structure usually works best: - **Documentation** for article drafting, rewriting, and release notes - **Support** for chat replies, email replies, and escalation handoffs - **Onboarding** for setup guidance and first-use instructions - **Internal Operations** for summaries, internal notes, and handoff content Use a naming convention that makes the purpose obvious at a glance. A consistent pattern helps people scan the list quickly. For example, include: - team prefix - task type - output style Names such as **Docs - Draft - Help Center Article** or **Support - Reply - Refund Email** are much easier to understand than vague names like **General Prompt** or **Standard Template**. If your Atloria workspace supports tags or categories, use them to separate templates by channel or output type. Helpful labels include: - help center article - email reply - chat response - internal summary - escalation - rewrite - onboarding It is also important to show which templates are ready for everyday use. Mark templates clearly as: - approved for production use - draft - experimental That status matters because teams often test new prompt wording before adopting it broadly. If draft and approved templates look the same in the list, users may accidentally choose an unfinished version. [SCREENSHOT: Template library grouped by team with visible names, tags, and approval status] For broader workspace organization, see [Using the Admin Workspace](doc:using-the-admin-workspace). ## Maintaining Template Quality as Workflows Change Prompt templates should not stay untouched after they are created. In Atloria, the best template libraries are maintained the same way teams maintain documentation standards: with clear ownership, regular review, and visible revision details. Assign an owner to every template. The owner should be the person responsible for checking whether the wording still matches current documentation standards, support language, and team expectations. Without an owner, outdated prompts tend to stay in the shared list long after they should have been revised or removed. Track revision details directly in the template record whenever possible. Useful fields include: | Field | What it shows | |---|---| | Version | Which revision users are looking at | | Last-reviewed date | When the template was last checked | | Change notes | What was updated and why | | Owner | Who approved or maintains the template | These details help users decide whether a template is still safe to use. For example, if a support reply template has not been reviewed in a long time, the team can pause and confirm it still matches current policy language before using it again. Retire templates when they no longer fit the work. This is especially important when: - product terminology changes - support policies are updated - documentation structure standards change - teams split one workflow into several narrower workflows Do not leave outdated templates mixed in with active ones. If a template should no longer be used, mark it clearly as retired or remove it from the active library. Review your most-used templates on a regular schedule. Focus on whether they still produce the expected: - structure - tone - factual boundaries - level of detail If your team also manages AI settings centrally, see [Configuring AI Settings for Your Organization](doc:configuring-ai-settings-for-your-organization). ## Applying Templates Consistently Across AI Workflows Once your team has a shared template library in Atloria, the next step is using those templates the same way every time. Consistency comes from choosing the right saved template first, then changing only the parts that are meant to change. 1. Before starting a documentation draft, support response, or internal summary, open the shared template list and choose the template that matches the task. Do not start with a blank prompt if a saved template already exists for that workflow. 2. Review the **Template name**, **Purpose**, and any status label such as approved, draft, or experimental. Make sure you are selecting the approved version for live work. 3. Fill in the placeholders with task-specific details. Depending on the template, this may include the feature name, customer issue, target audience, customer tier, required response length, or call to action. 4. Submit the prompt using the saved structure rather than rewriting the core instructions. The template should already define the expected tone, formatting, and boundaries. 5. Compare results across multiple uses of the same template. If different team members enter similar details and receive wildly different output quality, review whether people are changing the base prompt instead of only filling the placeholders. The most important habit is to adjust only the variable fields for each request. If users keep editing the main prompt body, the template stops being a standard and becomes just a starting suggestion. This matters across both documentation and support workflows. A documentation draft template should always produce a similar article shape. A support reply template should always follow the same tone and response style. That consistency makes reviews faster and helps teams trust the output. [SCREENSHOT: User selecting an approved template and filling in placeholders before generating output] ## Fixing Common Problems with Reusable Prompt Templates When reusable prompt templates are not working well in Atloria, the problem is usually not the idea of templates itself. Most issues come from unclear ownership, weak naming, or users changing the wrong parts of the prompt. If outputs vary too much between users, first check whether people are editing the base prompt body. A shared template only stays consistent when the main instructions remain stable. Users should fill in the placeholders, not rewrite the standard wording each time. If needed, compare a few recent uses of the same template and look for changes in tone instructions, formatting rules, or response limits. If teams cannot find the right template, review how the library is organized. Common warning signs include: - multiple templates with nearly identical names - categories that overlap - tags that are too broad - vague titles such as **General Prompt** or **Standard Reply** Rename templates so the workflow is obvious at a glance, and group them more clearly by team or task. If responses feel outdated or no longer match current policy, open the template details and check the **Owner**, **Last-reviewed date**, **Version**, and **Change notes**. These fields help you confirm whether the template is still current before your team keeps using it. Another common problem is trying to reuse one template for unrelated tasks. If a single prompt is being used for documentation drafting, chat support, and email support, split it into narrower templates. Separate templates usually perform better because each one can define the right tone, structure, and output length for that specific workflow. For related guidance on support workflows, see [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) and [Chatting with Support Agents and Managing Conversations](doc:chatting-with-support-agents-and-managing-conversations). ## Overview Reusable prompt templates in Atloria help teams standardize how they work with AI across documentation and support tasks. Instead of writing fresh instructions every time, your team can save approved prompt formats and reuse them for common jobs such as article drafting, article rewriting, support replies, and escalation handoffs. A good template library gives users a reliable starting point. Each template should make its purpose clear through its name, describe when it should be used, and include a prompt body that already defines tone, structure, and output limits. Users then fill in the changing details, such as the feature name, issue summary, audience, or response length, without changing the standard wording. This approach is especially useful when multiple people contribute to the same workflows. Documentation teams can keep article drafts aligned with shared writing standards, while support teams can keep customer replies consistent across chat and email channels. It also reduces the risk of ad hoc prompts producing uneven results. In Atloria, reusable templates work best when they are: - stored in one shared location - grouped by team or workflow - named consistently - marked as approved, draft, or experimental - reviewed regularly by a clear owner Templates are not meant to be permanent and untouched. As product language, support policies, and documentation standards change, your team should update or retire templates so the shared library stays useful. If your work also includes project-based AI content, you may want to pair template management with project guidance in [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) and [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages). ## Prerequisites Before your team starts managing reusable prompt templates in Atloria, make sure a few basics are already in place. These steps keep the library organized from the beginning and make it easier for teams to follow the same standards. You should have: - access to the Atloria workspace where your team manages shared content - a defined location for prompt templates, such as a shared prompt repository, workspace template list, or team knowledge base collection - agreement on who will maintain templates, usually a Documentation Manager, Support Team Lead, or Project Administrator - a naming convention your team will follow for new templates - a short list of workflows you want to support first, such as documentation drafting, article rewriting, support replies, or escalation handoffs It also helps to agree on the fields every template must include before anyone starts creating entries. At minimum, your team should be ready to capture: - template name - purpose - prompt body - variables or placeholders - owner - last-reviewed date If your team plans to use templates across multiple groups, decide in advance how you will label them. Categories such as **Documentation**, **Support**, **Onboarding**, and **Internal Operations** are often enough to get started without making the library hard to browse. For teams working in larger shared workspaces, it is useful to review related admin guidance first: - [Using the Admin Workspace](doc:using-the-admin-workspace) - [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) - [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings) Once those basics are settled, your team can begin building templates that are easy to find, easy to maintain, and reliable to use across everyday AI workflows. ## Confirming the version is ready for final approval Before you send a version forward, open the project workspace in Atloria and go to the **Versions** list. Select the version you just finished reviewing, then check the version details screen carefully. At this stage, you are not looking for draft work anymore—you are confirming that the version record is complete enough for a final decision. If you need a refresher on the earlier review cycle, use [Requesting Review and Handling Version Decisions](doc:requesting-review-and-handling-version-decisions) instead of repeating those steps here. Start by checking the **Status** shown on the version record. The version should already be in a review-complete or approval-ready state, not in an earlier working state. If the status still suggests active edits or unresolved review work, stop here and finish those items first. Next, review the version details and make sure the core information is filled in. In practice, that means confirming fields such as the version title, version label, owner, and planned release date are present and accurate. If any of those details are missing or outdated, the final approver may reject the request simply because the release record is incomplete. Then check whether the version package includes the right content. Open the attached documents or included documentation items and verify that the latest approved revisions are the ones linked to this version. You do not want older drafts or partially updated pages included in the release package. Also look for any visible review comments, flagged items, or open follow-up notes on the version. If the screen still shows unresolved discussion or pending review concerns, treat the version as not ready for final approval. [SCREENSHOT: Version details screen showing Status, owner, release date, and attached documentation items] ## Resolving outstanding issues before sign-off Once the version looks complete, move to the part of the version record where review findings, issues, or follow-up items are listed. In Atloria, this is the place to clear anything that could block sign-off. The goal is simple: the final approval record should show that no important questions are still open. Filter the list so you can focus on items that still need attention, especially anything marked **Open**, **In Progress**, or **Blocked**. These are the entries most likely to delay approval. Read each one and decide whether it has been fixed, accepted, reassigned, or still needs work. If a note says a page was updated, open the related document and confirm the change is actually reflected in the version. For each item, update the fields that explain its outcome. Use the final disposition, resolution note, and closure status so anyone reviewing the version can see what happened without digging through older comments. Keep these notes specific. For example, if a reviewer asked for a screenshot update or wording correction, the issue entry should clearly show that the change was completed and the item is now closed. If ownership is unclear, update the **Assignee** field before the version moves forward. A version often gets stuck because everyone assumes someone else is handling the last task. Reassigning the item to the correct contributor or reviewer makes responsibility visible on the screen. Finally, check the activity history or comment thread tied to the version. You are looking for confirmation that required reviewers saw the final changes and acknowledged them. That confirmation matters when the approver wants proof that review feedback was addressed. For more detail on interpreting comments and statuses, see [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up). [SCREENSHOT: Issues or findings panel filtered to Open, In Progress, and Blocked items] ## Submitting the version for final approval After the version record is complete and all blocking items are closed, use the version actions menu to start the final approval step. On the version record, select **Submit for Approval**. This moves the version out of review wrap-up and into the formal approval workflow. 1. Open the target version from the **Versions** list. 2. Click **Submit for Approval**. 3. In the approval form, choose the final approver or approval group in the **Approver** field. 4. Confirm any due date or approval deadline shown in the form. 5. Add approval notes that summarize the final review outcome. 6. Submit the request and return to the version details screen to confirm the status changed. When you fill out the approval form, pay close attention to who is selected as the approver. If Atloria offers both an individual approver and an approval group, choose the option that matches your team’s release process. A wrong selection here can leave the version sitting in the wrong queue. Use the notes area to give the approver the context they need. Include a short summary of resolved issues, any important review decisions, and any release conditions that still need to be checked after approval. Keep the note focused on what changed and what the approver should know before signing off. After submission, return to the version status indicator and watch for the workflow state. Depending on the decision, Atloria may show the version as **Approved**, **Rejected**, or **Needs Changes**. If the status does not update as expected, reopen the approval details and confirm the request was sent correctly. For a broader explanation of approval decisions, see [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals). [SCREENSHOT: Submit for Approval form with Approver, due date, and approval notes] ## Handing off approved documentation for access validation Approval does not mean the version is ready to release immediately. After the version is approved, open the handoff area on the version record and move the package to access validation. This step makes sure the approved content is visible only to the right audiences before export or release. 1. Open the approved version from the **Versions** list. 2. Go to the handoff or release section on the version record. 3. Assign the package to the person responsible for access validation. 4. Review audience, role, or permission settings on the approved documents. 5. Add handoff notes describing what must be tested before release. 6. Mark the access validation checkpoint as complete when testing is finished. In the handoff notes, be specific about where the approved documentation will appear. If the version is intended for a particular audience, portal, or user group, record that clearly so the validator knows what to test. If restricted pages are included, mention them directly in the notes so they are checked before release. This is also the right time to confirm that the approved documents match the intended visibility rules. Open the related documents and review any audience or access settings attached to them. If a page should be limited to a certain reader group, make sure that restriction is still in place on the approved version. When validation is complete, update the checkpoint on the version record so everyone can see that access review is done. If you need more help with visibility checks, use [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export). [SCREENSHOT: Approved version handoff panel with assignee, notes, and access validation checkpoint] ## Preparing exports and release-ready deliverables Once access validation is complete, create the release package from the approved version. In Atloria, start from the approved version record and use the **Export** action. This is where you generate the files or deliverables that will be shared, archived, or passed to the release team. 1. Open the approved version record. 2. Click **Export**. 3. Choose the required output format for the release. 4. Confirm the export is based on the approved version, not a draft. 5. Save or store the exported deliverables in your team’s release location. 6. Link the completed export back to the version record and update the handoff status. Before you confirm the export, check that the package includes the final approved files, any required attachments, and the correct version identifiers. The version label should match the approved release record. If the export preview or summary shows draft content, stop and verify which revision is selected before continuing. After the export finishes, store the deliverables in the release location your team uses for handoff. Then return to the version record and add the export reference so there is a clear trail from the approved version to the release files. This traceability matters later if someone needs to confirm exactly what was delivered. Finally, update the handoff or release status on the version so project administrators can see that export preparation is complete. If your next step is release packaging or publication, related guidance is available in [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness) and [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release). [SCREENSHOT: Export action on an approved version with format selection and linked deliverables] ## Fixing approval and handoff problems If Atloria does not let you move forward, the version record usually tells you what is missing. Start with the most visible blocker on the screen and work from there rather than resubmitting repeatedly. | Problem you see | What to check in Atloria | What to do next | |---|---|---| | You cannot submit the version for approval | Missing version details, incomplete attachments, or unfinished review tasks | Reopen the version record and complete the required fields, confirm the right documents are attached, and close remaining review work | | Approval stays pending | Wrong approver, wrong approval group, or incorrect due date | Open the approval request, verify the **Approver** field and deadline, then correct and resubmit if needed | | Access validation fails | Audience, role, or permission settings do not match the release target | Review document visibility and audience settings on the approved version, then repeat the validation check | | Export is missing content | The export was created from a draft revision instead of the approved version | Return to the version record, confirm the approved revision is selected, and generate the export again | If a version returns as **Needs Changes** or **Rejected**, do not treat it as a new review cycle from scratch. Open the decision details, read the approval notes, and correct only the items that blocked sign-off. Then resubmit the version through the same approval action. When the problem is tied to access or visibility, compare the approved version’s audience and permission settings with the intended release destination. Many handoff issues happen because the content is correct, but the release target expects a different reader group than the one assigned on the version. For export problems, the safest fix is to regenerate the deliverable only after confirming the approved version label and included documents on the version record. If you need help with access or export checks, use [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). ## Overview This guide covers the final stretch between a completed review and a release-ready handoff in Atloria. At this point in the workflow, the version has already gone through review and decision handling. Your job now is to make sure the version record is complete, all remaining issues are closed, the final approver receives the right context, and the approved package is handed off cleanly for access checks and export. The process in Atloria usually happens across a few connected areas on the version record: the **Versions** list, the version details screen, the approval action, the handoff or release section, and the **Export** action. You will move between these areas to confirm readiness, resolve blockers, submit for approval, assign access validation, and prepare final deliverables. This guide does not repeat the earlier review request process. If you still need to send a version out for review or respond to reviewer decisions, go back to [Requesting Review and Handling Version Decisions](doc:requesting-review-and-handling-version-decisions). If you are still checking whether the version is generally ready for approval, [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval) is the better starting point. Use this guide when the version is nearly finished and you need a reliable handoff path from approved documentation to release preparation. The focus is on what you do in Atloria’s screens and fields so the approval trail, validation checks, and export record all stay aligned. ## Prerequisites Before you start the final approval and handoff steps in Atloria, make sure the version and its supporting records are already in good shape. You should have the following in place: - A project with an existing entry in the **Versions** list - A version that has already completed its main review cycle - Access to open the version details screen and use **Submit for Approval** - Permission to view or update issue lists, comments, and handoff details on the version - The final set of documents attached to the version package - Required version details completed, including title, version label, owner, and planned release date - Review comments, findings, or follow-up items already addressed or ready to close - A known final approver or approval group for the release - A person identified to handle access validation after approval - A release destination or storage location your team uses for exported deliverables It also helps if you already know which audiences, reader groups, or restricted content rules apply to the approved documentation. That makes the access validation step much faster because the handoff notes can be specific. If any of these items are still missing, pause here and finish the earlier workflow first. The most useful related guides are [Preparing Versions for Review and Approval](doc:preparing-versions-for-review-and-approval), [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions), and [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval). From here, your next work usually continues into release controls, publishing, or export validation depending on how your team releases documentation. ## Opening the AI usage dashboard and understanding what each metric means In Atloria, open the **Admin** workspace and select **Analytics** to reach the **Analytics & Insights** area. This screen is where administrators and team leads review usage statistics and performance metrics. Start by checking the date range shown at the top of the page or in the reporting controls if your workspace includes them. That date range determines which activity appears in every chart, summary card, and table you review, so confirm it before drawing conclusions from the numbers. The first items to review are the top summary cards. In most AI usage reviews, these are the fastest way to understand overall demand. Focus on values such as: - **Total AI requests** - **Total tokens** or **credits consumed** - **Estimated cost** - **Active users** or active teams during the selected period These numbers help you answer basic questions quickly: how much AI activity happened, how expensive it was, and how widely the usage was spread across your organization. Grouped views are useful when you need to compare behavior instead of just reading totals. Depending on the reporting options available in your Atloria workspace, review usage grouped by: - **Project** - **Team member** - **Model** - **Feature area** This makes it easier to spot whether one project is driving most of the cost, whether one user is generating unusually heavy traffic, or whether a specific feature is responsible for a usage increase. Trend charts help you judge whether activity is normal or unusual. A steady line usually points to predictable day-to-day use. A sudden spike can indicate a large documentation run, repeated retries, or a short-term burst of support activity. Low-activity periods may simply reflect quiet workdays, but they can also help you confirm that a rollout or team change reduced usage as expected. If you need a broader introduction to usage reporting before reviewing activity patterns, see [Monitoring AI Usage and Request Activity](doc:monitoring-ai-usage-and-request-activity). ## Filtering request history to find the activity you need to review Once you move from summary metrics into detailed review, open the request history view connected to your AI usage reporting area. This is where you narrow a large activity list into the exact requests you need to inspect. Begin with the same **date range** used on the dashboard so your detailed review matches the totals and charts you just examined. Use the available filters to reduce the list. In Atloria, common review filters include: - **Date range** - **User** - **Team** - **Project** - **Model** - **Status** - **Feature area** These filters are especially helpful when you are investigating one issue at a time. For example, if a team lead wants to review failed requests from a single project, you can combine **Project** and **Status** filters to isolate only those records. Search tools help when you already know what you are looking for. Use the search field or column-level filtering to find a specific prompt, a response snippet, a request identifier, or a user session. This is often the fastest way to locate one request mentioned in a support conversation or internal review. Sorting changes the order of results so you can match the list to your goal: 1. Sort by newest activity when you are checking recent behavior after a spike. 2. Sort by highest cost when you want to identify expensive requests first. 3. Sort by failed or incomplete activity when you are investigating reliability issues. If your Atloria workspace supports reusable filtered views, save combinations you use often, such as a weekly failed-request review or a monthly project cost review. Shared filtered views are useful for support leads and administrators because everyone can return to the same scope without rebuilding the filters each time. [SCREENSHOT: Request history screen showing date range, user, project, status, and model filters] ## Inspecting individual requests to review quality, cost, and outcomes After narrowing the request list, open a single request to review its details. Depending on your Atloria workspace, this may appear in a side panel or on a full detail page. Start with the top-level fields so you understand the context before reading the content itself. The most important fields to confirm are the **timestamp**, **requesting user**, **project** or workspace, **model used**, and **request status**. A request record usually includes both the prompt and the response. Review these together rather than separately. The prompt shows what the user asked Atloria to do, while the response shows what was returned. If your organization uses privacy controls, you may see signs that some content has been limited for review. Typical signs include redacted sections, shortened text, or controls that let you expand truncated content. When that happens, review what is visible first and avoid assuming the missing text indicates a broken request. The usage section is where cost and performance become clearer. Look for fields such as: | Field | What to review | |---|---| | **Input tokens** | How large the prompt or submitted content was | | **Output tokens** | How long the generated response was | | **Latency** | How long the request took to complete | | **Retries** | Whether Atloria had to try again before finishing | | **Estimated cost** | The likely cost of that single request | Outcome details help you judge reliability. A **Success** result usually means the request completed normally. **Error** or **Timeout** results point to failed or incomplete processing. If you see fallback model usage, that can explain why a request completed with different cost or quality than expected. If a request appears abandoned, review whether the user stopped the workflow before the response finished. When you need to compare request-level findings with broader patterns, return to [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history). ## Using activity patterns to manage spend and team behavior Request review becomes more valuable when you compare patterns over time. In Atloria, grouped reporting lets you compare usage by **user**, **team**, and **project** so you can see who is driving the highest request count or token consumption. This is often more useful than looking at organization totals alone, because one expensive project or one heavy user can change the overall picture. Start by comparing high-volume users and projects against the work they are expected to perform. A project with frequent documentation generation or support-agent updates may naturally produce more requests than a smaller team space. What matters is whether the usage pattern matches the work being done. If it does not, inspect the request history for repeated prompts, unusually long responses, or frequent retries. Certain patterns deserve closer attention: - **End-of-week spikes** can reflect scheduled content generation or review cycles. - **Repeated retries** can point to unclear prompts or unstable workflows. - **Very long responses** can increase cost quickly, especially when they happen often. - **Heavy use from one project** may suggest a team needs better guidance on when to run AI-assisted tasks. Model comparisons are also important. If one model consistently produces higher cost with little visible improvement in outcome, team leads may decide that a lower-cost option is enough for routine work. On the other hand, a higher-cost model may be justified for complex generation, sensitive review tasks, or high-visibility documentation output. Use these findings to make practical decisions. You might update prompt guidance, review shared templates, or set clearer expectations for when teams should use AI-assisted features. This is not only about reducing spend. It also helps improve consistency, reduce failed attempts, and make AI usage easier to explain during regular operational reviews. ## Sharing findings with administrators, managers, and support leads After you identify the activity you want to discuss, share the same scoped view so others can review the exact data you used. In Atloria, this usually starts by exporting the filtered request history or a usage summary from the reporting area. Before exporting, confirm the **date range**, **project**, **team**, and **status** filters so the report reflects the discussion you are preparing for. For recurring reviews, use any sharing options available in your workspace, such as a saved dashboard view, a scheduled report, or a copied filtered view. These are especially useful when project administrators, department managers, and support leads need repeatable visibility into the same slice of activity each week or month. A shared filtered view avoids confusion because everyone sees the same scope instead of rebuilding filters manually. In regular review meetings, keep the focus on a small set of metrics that are easy to compare over time: - **Request count** - **Cost trend** - **Failure rate** - **Top users** - **High-cost projects** These measures are usually enough to show whether usage is stable, growing, or becoming more expensive than expected. If a spike appears, attach a filtered request list so reviewers can move from summary numbers into individual examples without starting over. A lightweight review rhythm works well for most teams: 1. Review **weekly** failed requests and unusual activity spikes with support leads. 2. Review **monthly** cost and volume trends with administrators or managers. 3. Run an **ad hoc** review after any unexpected increase in spend or request failures. If your review needs to connect AI activity with broader admin reporting, see [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Resolving common issues when usage data looks incomplete or unexpected If the usage dashboard or request history does not look right, begin with the filters. The most common reason for missing activity is the selected **date range**. A narrow date window can make it appear that no requests were recorded when the activity actually happened outside the current range. Also check whether a **project**, **team**, or **user** filter is still active from an earlier review. If no requests appear at all, confirm that you are viewing a scope you are allowed to see. In Atloria, some users may only see activity for specific projects or teams rather than organization-wide usage. If your expected records are missing, compare your current view with the permissions and workspace access available to you. When totals do not match what you expected, check how the dashboard is grouped. A view grouped by **user**, **project**, or **model** can change how totals are presented. Also confirm whether failed requests and retried requests are included in the numbers you are reviewing. A cost total that includes retries may look higher than a simple completed-request count suggests. Sometimes a request detail opens without full prompt or response text. That does not always mean the record is broken. Atloria may limit what you can see because of retention settings, redaction rules, or privacy controls. If the request metadata is present but the content is shortened or hidden, review the visible status, model, timing, and usage details before deciding whether further follow-up is needed. If cost appears unusually high, inspect the most expensive requests first. Look for: - Large prompt sizes - Very long responses - Repeated retries - Use of a higher-cost model - Sudden increases in request volume These checks usually reveal whether the increase came from more activity, larger requests, or a more expensive model choice. ## Overview This guide focuses on the review side of AI activity in Atloria. It assumes you already know how to reach the reporting area and read the basic usage screens. Here, the goal is to move beyond simple monitoring and into practical review work: narrowing request history, opening individual records, comparing activity patterns, and sharing findings with other decision-makers. Use this guide when you need to answer questions such as: - Which projects are driving the most AI usage? - Why did estimated cost increase this week or month? - Which requests failed, timed out, or retried? - Are certain users or teams relying heavily on one model or feature area? - Does a spike reflect normal work or something unusual? The sections above walk through the main review flow most administrators and team leads follow: 1. Open the **Analytics** area in the **Admin** workspace. 2. Confirm the reporting date range and top-level metrics. 3. Filter request history to isolate the activity you need. 4. Inspect individual request details for quality, cost, and outcome signals. 5. Compare patterns across users, teams, projects, and models. 6. Share filtered findings for weekly, monthly, or ad hoc review. This document does not repeat the setup and monitoring basics covered earlier in the AI Usage set. If you need a refresher on general usage tracking, start with [Monitoring AI Usage and Request History](doc:monitoring-ai-usage-and-request-history). If you want a broader view of dashboard-based monitoring before doing detailed request review, use [Monitoring AI Usage and Request Activity](doc:monitoring-ai-usage-and-request-activity). [SCREENSHOT: Analytics & Insights page in the Admin workspace with summary cards and trend area] ## Prerequisites Before using this review workflow in Atloria, make sure the following conditions are met: - You can sign in to Atloria and open the main authenticated workspace. - You have access to the **Admin** workspace. - You can open **Analytics** from the admin area. - You have permission to view the projects, teams, or organization activity you are expected to review. - AI usage data already exists for the date range you plan to inspect. It also helps if you already understand the basic navigation patterns for the admin area. If you are still getting familiar with that workspace, read [Using the Admin Workspace](doc:using-the-admin-workspace). If your role includes reviewing user access and visibility, [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) explains how access scope can affect what appears in reporting screens. For the most useful review sessions, gather a clear question before you open the dashboard. Examples include: - Reviewing a recent cost increase - Checking failed requests for a support issue - Comparing AI usage across projects - Investigating one user’s recent request activity - Preparing a weekly or monthly usage summary You do not need to prepare external tools to complete the steps in this guide. Everything described here is based on the reporting and request-review views available inside Atloria. If your team also reviews security-related records alongside AI activity, pair this guide with [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls). ## Understanding How Audience-Specific Public Views Are Chosen In Atloria, a public documentation page is not always a single page shown the same way to every reader. The public reading experience depends on two choices working together: the **audience** being viewed and the **documentation version** being opened. When you validate a public page, check those two controls first before judging whether the content is correct. A reader can arrive in a tailored public view in several ways. They might open an audience-specific link, switch to a different release with the **version selector**, or land directly on a public page from a shared URL. In each case, Atloria opens the public reading view for that audience and version combination if that matching page is available. This is the view external readers use, and it opens without requiring sign-in. If Atloria cannot find a tailored page for the selected audience or version, the result may change. In some cases, the general public page appears instead of the audience-specific variant. In other cases, the page may not appear in navigation for that audience at all. That is why it is important to test both the page itself and the surrounding navigation, not just the URL. A page that exists for one release may fall back to a general version in another release, and a page that is visible to one audience may be hidden for another. Keep the public reading view separate from the editing workspace in your review process. The page record and editing screens help you manage content, audience assignment, and publication choices, but they do not show the exact experience an outside reader gets. When you need to confirm what customers, partners, or internal readers actually see, open the **public preview** or the published public page instead. If you already worked through [Validating Audience Targeted Release Views](doc:validating-audience-targeted-release-views), use that process as your release check and use this guide to focus on the actual reading experience once the page is open. ## Opening the Public Reading Experience for a Specific Audience and Version 1. Start from the documentation page you want to review in Atloria. Open the page record you use to manage the content, then choose the option that opens the **public preview** or the published public page. This is the safest way to move from authoring into the reader-facing view without guessing the correct public link. [SCREENSHOT: Documentation page with the public preview or published page option highlighted] 2. Once the public view opens, set the **audience** you want to test. If Atloria shows an **audience selector** or audience-specific page controls, switch to the intended audience before reviewing the page. Do this before checking the text, because the same page title or navigation label may lead to different content for different audiences. 3. Next, choose the correct release in the **version selector**. If your team uses version-specific public links, open the page through the version you want to inspect. Confirm that the selected version matches the release you are validating, especially when you are comparing a current release against an older one. 4. Review the visible page elements as a reader would: - **Page title** - **Body content** - **Navigation links** - **Breadcrumbs** - Any audience-limited sections or release-specific notes 5. Compare what you see against the intended audience/version combination. For example, a customer-facing page in one version may include simplified instructions, while another audience or release may show different wording or a different set of linked pages. If the page looks wrong, do not stop at the body text. Check whether the audience or version control changed while loading the page. Also confirm that the navigation menu matches the same audience and version. A correct page body with the wrong navigation still creates a broken reading experience for public visitors. ## Following the Reader Journey to Tailored Content Readers do not always begin on the exact page you are validating. In Atloria, they may enter tailored documentation through a homepage, a navigation menu, a search result, a shared page link, or a version-specific landing page. To review the full reading experience, trace the same routes a public reader would actually use. A common path starts on the public documentation homepage. From there, the reader uses the visible navigation, page cards, or landing sections to open content meant for their audience. When Atloria is set up correctly, those menus and page lists should expose only the pages intended for that audience. If a page should be hidden from one audience, it should not appear as a tempting navigation option in the first place. Shared links are another important entry point. A reader may open a direct public URL to a page without first browsing the site structure. When that happens, check whether the page opens as the correct audience-specific variant, falls back to a general page, or leads to a page that is not available in that version. This matters most when teams reuse the same page name across multiple releases. Version changes are especially important to test. A reader might land on a page in one release and then switch versions using the **version selector**. When they do, Atloria may keep them on the same page path if a matching public page exists in the selected release. If it does not, the reader may see a general public page instead, or the page may no longer be available in navigation. Review both outcomes so you know whether the experience is expected. Look for visible cues that help confirm the reader is in the right place: - **Version labels** - **Audience labels** - **Breadcrumbs** - Matching page titles - Navigation placement within the correct section These cues are often the fastest way to spot a mismatch before you read every paragraph on the page. ## Checking Which Pages Appear for Each Audience To confirm that Atloria is showing the right public structure, review one audience at a time. Open the public site, choose the target audience, and inspect the visible navigation tree, landing sections, and linked page lists. This is often more useful than checking isolated pages because audience mistakes usually show up first in menus and section lists. Start with one section of the public site and compare it across two audiences. For example, open the same documentation area for Audience A and then Audience B. Look for three possible outcomes: - A page appears for both audiences because it is shared - A page is hidden for one audience - A page is replaced by a different audience-specific variant When a page appears unexpectedly, go back to the page’s setup in Atloria and review its audience assignment and publication state. A page may be visible because it is published as a general public page rather than limited to a specific audience. When a page is missing, check whether it was excluded from public navigation, left unpublished for that version, or never assigned to the audience you are testing. Do not stop with the menu. Open the page and inspect its in-page links as well. Cross-links inside the content should lead to pages available to the same audience. If a customer-facing page links to a page that only another audience can access, the public reading experience becomes confusing even if the original page looked correct. A simple comparison table can help during review: | What to check | Audience A | Audience B | What to confirm | |---|---|---|---| | Navigation item | Visible or hidden | Visible or hidden | Matches intended audience access | | Page content | Shared or tailored | Shared or tailored | Correct variant opens | | In-page links | Working links only | Working links only | No links to unavailable pages | [SCREENSHOT: Public documentation navigation compared across two audience selections] ## Comparing Versioned Content Across Audiences Audience review becomes more important when you add versions. In Atloria, a page may be available to the same audience in one release but not in another, or it may keep the same page path while showing different content. Use the **version selector** to review the same page across multiple releases and confirm that each supported version shows the correct audience-specific result. Begin with a page that is known to be tailored by audience. Open it in the current release, then switch to an older release and compare: - **Page title** - **Body content** - **Navigation position** - **Linked pages** - Any release notes or warnings shown on the page Pay special attention to changes in page names or navigation placement between versions. A reader may use a bookmark or a shared link from a previous release, and the page may open differently depending on whether that release still contains an audience-specific variant. If the same page path now points to a general public page in an older version, note that as expected fallback behavior rather than treating it as a publishing error. You should also identify gaps. One audience may have a tailored page in the latest version, while another release only includes the general version or no public page at all. Record those combinations clearly so reviewers and support teams know what readers should expect. Check release-specific messaging carefully. Version warnings, deprecated content notices, and release-only instructions should appear only where they belong. If an older version shows guidance meant for the newest release, or if a customer audience sees internal release notes, the issue is usually easiest to catch by comparing versions side by side. If you need a broader release validation process, pair this review with [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). ## Verifying the Correct Public Pages Before Sharing Them 1. Build a small test matrix before you share public links. List the combinations you need to verify, such as one page across multiple audiences and versions. Then open each public URL or preview link one by one and confirm that the expected page resolves every time. This is the fastest way to catch a page that works for one release but not another. [SCREENSHOT: Reviewer checking the same public page across several audience and version combinations] 2. If the wrong page appears, recheck the basics in Atloria: - The selected **audience** - The selected **version** - The page’s **publication state** - Whether a general public page is appearing instead of a tailored variant 3. If a page is missing, inspect the surrounding structure as well as the page record. Confirm that: - The page is included in public navigation if it should be discoverable - The page is visible for that audience - A published page exists for that audience/version combination 4. Open the same public page in an **incognito** or signed-out browser window. This removes editor-only controls and helps you see the true public reading experience. It also helps you catch cases where your signed-in session makes a page seem available when a public reader would not see it. 5. Repeat the check from more than one entry point. Test the direct link, then reach the same page through navigation or another in-page link. A page that loads correctly from a saved URL may still be hard to find if the public menu is wrong. Before sending links to customers, partners, or internal teams, make sure the page body, version label, and surrounding navigation all agree. In audience-specific publishing, the page itself is only part of the experience. ## Overview This guide focuses on how to review the **public reading experience** in Atloria when documentation changes by **audience** and **version**. The goal is not to edit content, but to confirm that public readers reach the correct page, see the correct navigation, and stay within the right documentation path after they arrive. You will use this review when: - A page has audience-specific variants - A release includes different public content by version - You need to confirm what an external reader sees before sharing a link - A page appears correct in editing screens but may behave differently in public view The most important idea is that public pages should be checked as a reader would experience them. That means opening the **public preview** or published page, selecting the intended **audience**, switching the **version** when needed, and reviewing the visible result. A page can look correct in the documentation workspace while still leading readers to the wrong navigation path, the wrong version, or a fallback page. This guide also helps you spot problems that are easy to miss in page-by-page editing: - Hidden pages that still appear in public navigation - Shared links that open a general page instead of a tailored variant - Version switches that change the page unexpectedly - Cross-links that send readers to pages unavailable to their audience If you need help with setup decisions before this validation step, refer to [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences). If you need to confirm release targeting before checking the reading flow, use [Validating Audience Targeted Release Views](doc:validating-audience-targeted-release-views). ## Prerequisites Before you review audience-specific reading experiences in Atloria, make sure the basic publishing pieces are already in place. This guide assumes you are checking an existing public documentation setup rather than creating one from scratch. You should have: - Access to the relevant project in Atloria - At least one documentation page that is already available in **public preview** or published view - More than one **audience** defined if you plan to compare tailored experiences - At least one **documentation version** available if you plan to test release-specific behavior - Permission to review project content and public-facing pages It also helps if you already know: - Which pages are meant to be shared across all audiences - Which pages should be hidden or replaced for specific audiences - Which versions are currently supported for public readers - Whether your team expects a general public page to appear when a tailored variant is unavailable For the smoothest review, prepare a short list of pages and combinations to test before you begin. Include: - A shared page - An audience-specific page - A page that changed between versions - A page reached through navigation - A page reached through a direct shared link If you have not yet reviewed how audiences are defined or how public audience pages are organized, read [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation) first. Those guides cover the setup decisions that this reading-experience review depends on. ## Opening screenshots from a document or version review In Atloria, screenshot review usually starts from one of two places: a document page you are editing, or a version you are preparing for release. If you are checking images for one page only, open the document details page from your project workspace and go to the area where that page’s screenshots are listed. If you are reviewing a release candidate, open the version details page first, then move into the screenshot review area for that version. This helps you stay clear about whether you are checking one document or the full release set. Look for the screenshot-related areas that help you review images quickly: - A screenshots panel or screenshot section on the page - A thumbnail list showing each attached image - Status labels that show whether an image is ready, approved, missing, or still needs work - Release-readiness indicators or warning markers that show whether screenshots are blocking publication [SCREENSHOT: document details page with screenshot panel and thumbnail list] Document context and version context are similar, but they answer different questions. In document context, you are checking whether screenshots support the content on one page. In version context, you are checking whether the screenshots included in the release are complete and current across the version you plan to publish. A screenshot that looks fine on one page may still need review at version level if the release includes broader changes. Before you begin, confirm three things on screen: - You opened the correct document details page or version details page - The expected screenshots appear in the thumbnail list - The current review state is visible through status labels, warnings, or readiness markers If you need a refresher on earlier screenshot checks before this stage, see [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release) and [Reviewing Version Screenshots Before Release](doc:reviewing-version-screenshots-before-release). ## Checking whether screenshots are ready for release Once you are in the screenshot review area, work through each thumbnail one by one. Start with the thumbnail list, then open the full image preview for any screenshot that needs a closer look. In Atloria, the thumbnail helps you spot obvious issues quickly, but the full preview is where you confirm the details: the screen shown in the image, the visible text, and whether the screenshot still matches the current document content or release scope. 1. Open a screenshot from the thumbnail list. 2. Review the full image preview carefully. 3. Compare the image against the current document draft or the version you are preparing. 4. Check the screenshot status shown beside or under the image. 5. Use the available review control to mark the screenshot as ready, approved, or still needing updates. [SCREENSHOT: full screenshot preview with status label and review controls] As you review, focus on release accuracy rather than image quality alone. A screenshot is only ready if it belongs to the exact page or version being prepared. For example, if the document text describes a newer screen layout, but the screenshot still shows an older layout, the image should stay in a needs-update state until it is replaced. The same applies if a screenshot belongs to a different release than the one currently under review. Also confirm that every required screenshot is present. Watch for signs that an image should not move forward: - Empty spaces in the screenshot list - Draft or placeholder images still attached - Outdated screenshots that no longer match the page - Status labels showing incomplete review or pending updates - Release-readiness markers showing unresolved screenshot issues If any screenshot remains missing or outdated, do not treat the page or version as ready for publication. The goal is to make sure the screenshot set supports the exact content readers will see when the release goes live. ## Reviewing screenshots across document and version workflows Screenshot review in Atloria works best when you use both document-level and version-level checks together. At the document level, screenshot review is part of normal page editing and approval. When you update a single documentation page, you should review the screenshots attached to that page before the content moves forward. This is the best place to catch page-specific issues, such as a missing image, a screenshot with the wrong screen, or an outdated image that no longer matches the text. 1. Open the document details page for the page you are updating. 2. Review the screenshot thumbnails attached to that page. 3. Open any image that needs closer inspection. 4. Update the screenshot status so the page reflects its current readiness. Version-level review happens later, when you are preparing a release candidate. Here, the goal is wider: confirm that all screenshots included in the version are complete, current, and consistent across the release. This is where teams catch gaps that are easy to miss when reviewing pages one at a time, such as one updated page using new screenshots while another still shows older screens. 1. Open the version details page for the release candidate. 2. Review the screenshots grouped under that version. 3. Check for missing, outdated, or inconsistent images across the release. 4. Confirm that screenshot-related warnings no longer block publication. Use document context first when a writer is actively editing a page. Switch to version context when the release is being finalized and you need to confirm release-wide completeness. The two workflows support each other: if a writer replaces an image while working on a document, that change affects what reviewers see later in version review. In the same way, a problem found during version review may send the team back to a specific document page to correct the screenshot there. For release preparation, this document builds on the checks described in [Reviewing Version Screenshots Before Release](doc:reviewing-version-screenshots-before-release), but focuses on how those checks connect back to individual document pages. ## Updating missing or outdated screenshots before publishing When Atloria shows screenshot warnings during document review or version review, fix them before you move toward publishing. Missing screenshots usually appear as empty thumbnail spaces, incomplete review states, or warning markers on the document details page or version details page. Outdated screenshots often still appear in the thumbnail list, but the preview no longer matches the latest page content or release scope. 1. Open the document details page or version details page where the warning appears. 2. Select the screenshot entry that is missing an image or showing an outdated one. 3. Use the available upload or replace action to add the correct image. 4. Confirm the updated screenshot is attached in the correct document or version context. 5. Save the change and return to the screenshot list. 6. Open the preview again to make sure the new image is the one now displayed. 7. Update the screenshot status so it reflects the new review result. [SCREENSHOT: screenshot entry showing replace action and updated preview] Be careful about context when replacing images. If you are working from a document page, make sure the screenshot belongs to that page. If you are working from a version review, make sure the replacement is visible in the release you are preparing. A common mistake is updating an image in one place, then checking another context and assuming the release is fixed without confirming it there. After you replace a screenshot, run the review again. Check: - The thumbnail now shows the correct image - The full preview matches the current page or release - The screenshot status no longer shows a warning or needs-update state - Release-readiness markers no longer list screenshot issues as blockers Do not rely on the upload alone. The image is only truly ready when the preview, status, and publish-readiness indicators all show that the screenshot issue has been cleared. ## Coordinating screenshot approval between writers and managers In Atloria, screenshot approval is easiest when writers and documentation managers review the same signals but focus on different decisions. Writers usually work closest to the page content, so they handle image accuracy at the document level. Documentation managers usually review the release as a whole, so they confirm that screenshot readiness is complete across the version before publication. A practical split of responsibilities looks like this: | Role | Main focus | What to check in Atloria | |---|---|---| | Technical Writer | Page-level image accuracy | Screenshot thumbnails, full preview, page content match, needs-update status | | Documentation Manager | Release-wide completeness | Version screenshot list, missing-image warnings, outdated-image indicators, publish-readiness checks | Writers should review screenshots while editing or approving a page. That includes confirming the image matches the current text, replacing outdated screenshots, and setting the screenshot status so the page clearly shows whether it is ready. Managers should then use the version details page to confirm that all screenshots required for the release are present and that no screenshot-related blockers remain. Both roles should pay attention to the same visible review signals: - Screenshot status labels such as ready, approved, or needs update - Missing-image warnings in the document or version view - Outdated-image indicators when a screenshot no longer fits the current release - Publish-readiness checks that show whether screenshots are blocking release To keep approval clear, record decisions directly through the status and review controls available on the screenshot entry, document page, or version review screen. That way, anyone opening the document details page or version details page can immediately see whether the screenshot is still under review or already cleared for release. If your team reviews screenshots first at page level and then at version level, this visible status trail helps prevent duplicate review and last-minute publishing delays. ## Fixing common screenshot review problems Most screenshot review problems in Atloria come down to context, status, or an incomplete update. When a screenshot is missing from a document or version, first open the document details page or version details page where the problem appears. Check whether the screenshot was attached to the correct page or release. If the thumbnail list is empty or incomplete, the image may not have been fully added to that record. Reopen the screenshot entry and confirm the image appears in the list after saving. If a screenshot still looks outdated after you replaced it, open the full preview instead of relying on the thumbnail alone. The thumbnail may not be enough to confirm that the latest image is showing. Make sure the replacement was saved, then verify that you are reviewing the correct version context. An updated screenshot on a document page does not automatically prove that the release review is clear unless the version view also shows the expected image. When publication is blocked because screenshots are not ready, inspect every screenshot-related warning shown on the version details page. Look for: - Status labels still showing needs update or incomplete review - Missing-image warnings - Outdated-image indicators - Publish-readiness checks that still list screenshot issues [SCREENSHOT: version details page showing screenshot warning and publish blocker] Another common issue is seeing a screenshot in document review but not in version review. In that case, confirm that the image is included in the target version you are preparing. Then reopen the version review and check whether the screenshot list reflects the latest document changes. If the page-level screenshot is correct but the version still does not show it, keep your review focused on the version details page until the release view reflects the expected image set. For broader screenshot organization and maintenance, see [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) and [Troubleshooting Screenshot Availability Across Projects and Versions](doc:troubleshooting-screenshot-availability-across-projects-and-versions). ## Overview This stage of screenshot review in Atloria connects page editing with release preparation. Earlier checks help you confirm that screenshots exist and are generally ready for review. Here, the focus is narrower and more practical: make sure each screenshot is visible in the right context, matches the current content, and does not block publication when the version moves toward release. The key idea is that Atloria gives you two review lenses: - **Document context** for checking screenshots attached to one documentation page - **Version context** for checking screenshots grouped under a release candidate Use the document details page when you want to verify that a single page has the right images. Use the version details page when you need to confirm that the release as a whole is complete. These two views should support each other. A screenshot corrected during page editing should hold up later during version review, and a problem found during version review should lead you back to the page that needs attention. As you work through screenshot review, keep your attention on visible review signals inside Atloria: - Thumbnail lists that show what is attached - Full image previews for detailed checking - Screenshot status labels - Missing or outdated warnings - Release-readiness markers that affect publishing This document is meant to sit after [Reviewing Version Screenshots Before Release](doc:reviewing-version-screenshots-before-release). If you still need to confirm basic screenshot readiness before comparing document and version context, return to [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release). If you are moving on to broader screenshot maintenance across teams and releases, the next useful reference is [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). ## Prerequisites Before you review screenshots in document and version context, make sure you already have the right working setup in Atloria. This task assumes you are not starting from scratch. You should already be inside the correct project workspace and able to open the document details page or version details page that contains the screenshots you need to review. You should have these items in place: - Access to the relevant project workspace in Atloria - A document page or release version that is already created - Screenshots already attached, or a visible warning showing that screenshots are missing - Permission to review page content and release readiness - A clear understanding of which document or version is currently being prepared It also helps if you have already completed the earlier screenshot review steps covered in: - [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release) - [Reviewing Version Screenshots Before Release](doc:reviewing-version-screenshots-before-release) Before opening the screenshot panel, confirm the following on screen: - The document title or version name matches the item you intend to review - The screenshot section is visible from that page - Any current status labels, warnings, or readiness markers are visible - You know whether you are reviewing one page or a full release If you expect to replace screenshots during review, be ready to reopen the screenshot entry, confirm the updated preview, and save the review result afterward. If your role is release approval rather than page editing, make sure you are working from the version details page so you can see screenshot blockers that affect publishing. ## Opening the project settings administrators can change Before you edit project identity or delivery details in Atloria, make sure you are signed in with access to manage that project’s settings. If you can open the project workspace and see the **Settings** area, you can usually review the available options there. If the **Settings** area is missing or you can only view project content without editing controls, you will need a project administrator or someone with higher access to update these values for you. 1. Sign in to Atloria and open the project you want to manage. 2. From the project workspace, go to the project’s **Settings** area. 3. Look through the settings sections for the fields related to project identity, website presentation, and delivery setup. 4. Compare what belongs to the public-facing site with what is only used for internal project maintenance. In practice, these settings usually fall into two groups: - **Public presentation settings** affect how the project appears to readers, such as the project name, description, and website-facing details. - **Maintenance and delivery settings** affect where documentation is delivered and how published output is organized. If you recently worked through webhook setup, keep that separate from the identity and delivery work covered here. For webhook-specific controls, use [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). As you review the form, remember that not every saved change appears in the same place at the same time. Some updates show up right away inside the project workspace, especially visible labels such as the project name. Website-facing changes may not appear on the published site until the project is rebuilt, republished, or otherwise refreshed through your normal publishing flow. [SCREENSHOT: Project workspace with the Settings area highlighted] ## Updating the project name, description, and visible identity The project identity settings in Atloria control how your documentation project is recognized in project lists, headers, and public-facing views. Start by opening the project’s **Settings** area and locating the fields that define the project’s visible name and summary information. 1. In **Settings**, find the field used for the project title or name. 2. Replace the existing value with the updated project name. 3. Find the description or summary field and update the text so it matches the project’s current purpose. 4. If the settings form includes branding fields such as a logo or icon, add or replace those assets. 5. Save your changes and review the project header and related listings. A clear project name matters because Atloria uses it in places where team members identify the project quickly, including workspace headers and project lists. The description helps provide context in discovery-style views and project metadata areas, especially when several projects have similar names. If branding options are available in the same form, use them carefully. A logo or icon can make the project easier to recognize, but it should stay consistent with the name and description. After saving, check whether the updated identity appears in these places: - The project header inside the workspace - Project listings or dashboard views - Navigation labels tied to the project name - The generated or published project presentation, if your project has a website view If the project name changes significantly, review any related labels elsewhere in the settings so the public presentation still feels consistent. A new title with an old description or outdated branding can make the project look unfinished. [SCREENSHOT: Project identity fields showing name, description, and branding options] ## Configuring website-facing options for how the project is presented Website-facing settings control how the project is presented when readers access it through a web view or published documentation site. In Atloria, these options are typically managed from the same project **Settings** area as the identity fields, so it helps to review them together before publishing changes. 1. Open the project’s **Settings** area. 2. Locate the website-related section. 3. Review the fields that control whether the project is visible through a website or public view. 4. Update any display labels or website metadata shown in that section. 5. Save the settings and check the published result or preview. These options matter because they influence how readers discover and understand the project before they even open a page. Depending on what is available in your project settings form, you may see controls related to: | Setting area | What to review | |---|---| | Visibility | Whether the project is exposed through a website or public-facing view | | Display labels | The name or label readers see in website navigation or page headings | | Website metadata | Supporting text tied to how the project is presented on the web | | Publishing location details | Website values that shape where the project appears | If your project is already published, changes here can affect navigation labels, page titles, and how the project is identified in browser-facing views. If your team manages several documentation sites, consistent website labels are especially important so readers can tell projects apart. When you update website-facing settings, compare them with the identity details you changed earlier. The visible project name, website label, and description should support the same message. If they do not match, readers may see one name in the workspace and another on the published site, which creates confusion. For broader website and project presentation settings, you can also refer back to [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). ## Choosing delivery paths and output locations Delivery settings determine where Atloria places the generated documentation when the project is published. These values are especially important when your project is available under a specific website path, because the delivery location and the website path need to work together. 1. In the project **Settings** area, find the fields related to delivery or output location. 2. Review the primary path value used for published documentation. 3. If a base path or destination path is available, confirm it matches your intended publishing structure. 4. Save the changes before testing the published result. 5. Open the project’s published location and verify the pages load where you expect. A delivery path is not just an internal detail. It affects whether links resolve correctly and whether readers land on the right project section. If your project is published under a specific URL segment, the delivery path should support that same structure. For example, if the website settings point readers to a project-specific location, the delivery settings should not send the output somewhere that uses a different path pattern. Before you save, check for these common problems: - A path that duplicates another project’s destination - A base path that does not match the website-facing publishing location - A destination that would break existing links - Small formatting mistakes that create missing pages or incorrect paths After saving, test the result from the reader’s point of view. Open the published project, move through the main navigation, and confirm that pages open without path errors. If the homepage works but deeper pages fail, the delivery path and website path may not be aligned. [SCREENSHOT: Delivery path or output location fields in project settings] ## Managing connected controls that affect maintenance and publishing behavior Identity, website, and delivery settings should be treated as one connected group. In Atloria, changing one of these values often means you should review the others before the next release or republish. This is especially true when a project is already live and readers depend on stable labels and paths. 1. After changing project identity fields, review the website-related settings in the same **Settings** area. 2. After changing website-facing labels or visibility, check the delivery path fields. 3. If you change the publishing location, confirm the visible project name and website presentation still match. 4. Save the full set of updates, then test the project before your next release. The most common dependency is between the project’s visible identity and its website location. A renamed project may also need updated website labels. A changed website path may require a matching delivery path. If only one part is updated, the result can be inconsistent: the workspace shows one project identity, while the published site still reflects older naming or older path structure. For documentation managers, consistency matters across releases. Keep these items aligned: - Project name and website label - Description and public-facing summary text - Branding assets and the current project identity - Website path and delivery destination - Visibility settings and the actual published result This is also a governance issue. If your team publishes multiple versions or maintains several projects, use the same naming and path rules every time. That makes review easier and reduces the chance of broken links or confusing branding during release work. When planning changes that affect publishing behavior, coordinate them with your normal release process instead of updating them in isolation. ## Verifying the updated project presentation and delivery setup After saving your changes, take time to verify both the project workspace and the published result. In Atloria, a settings form can save successfully while the visible website still shows older information until the latest output is available. A quick review helps you catch mismatches before readers do. 1. Return to the project workspace and check the project header. 2. Confirm the updated project name and description appear where expected. 3. If branding assets were changed, verify the logo or icon displays correctly. 4. Open the website or published project view and test the main entry point. 5. Move through a few pages to confirm the delivery path is working correctly. 6. If something looks wrong, go back to **Settings** and compare the identity, website, and delivery fields side by side. Focus on what readers will actually see: - The project title in the workspace and site header - Description or summary text in visible project areas - Branding assets in navigation or header areas - The published path used to reach the project - Page-to-page navigation after the project loads Common issues usually fall into a few patterns. A missing logo often means the branding update did not carry through as expected. A correct project name with the wrong published path usually points to a mismatch between website settings and delivery settings. A saved change that does not appear on the site may mean the project still needs to be rebuilt or republished through your usual publishing workflow. If the public result does not match the form values, reopen the same settings screen and compare each related field carefully rather than changing values at random. Small differences in labels or path settings are often the reason the final presentation looks wrong. [SCREENSHOT: Published project view showing updated title, branding, and working path] ## Overview This section of project settings in Atloria is where project administrators keep the project’s identity and delivery setup aligned. The main goal is to make sure the project looks correct to both internal team members and public readers, while also ensuring the published output appears in the right location. The work in this area usually includes: - Updating the project name used in headers and project lists - Revising the project description or summary text - Adjusting visible branding such as a logo or icon, if those options are available - Reviewing website-facing settings that control visibility and presentation - Confirming delivery or output paths used for published documentation These settings are closely connected. A project rename can affect website labels. A website path change can affect where documentation should be delivered. A branding update can require a quick review of the published site to make sure the visual identity still matches the current project name and description. Because this document follows webhook configuration, it does not repeat those controls here. If you need to revisit that setup, use [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). Use this settings area whenever your team is preparing for a release, refreshing project branding, reorganizing published documentation paths, or correcting how a project appears to readers. The most reliable approach is to review identity fields, website options, and delivery settings together in one pass, then verify the result in the workspace and the published view. The next step in this sequence is [Managing Project Webhooks and Delivery Checks](doc:managing-project-webhooks-and-delivery-checks), which focuses on validating delivery behavior after these settings are in place. ## Prerequisites Before you start changing project identity or delivery options in Atloria, make sure these basics are in place: - You can sign in to Atloria and open the correct project workspace. - You have access to the project’s **Settings** area. - You know which project name, description, branding, and publishing path your team wants to use. - You are ready to verify the result in both the project workspace and the published project view. - If the project is already live, you understand that changes to labels or paths may affect what readers see. It also helps to prepare a few decisions before opening the settings form: | What to prepare | Why it matters | |---|---| | Final project name | Keeps workspace labels and published presentation consistent | | Updated description | Improves how the project is identified in visible metadata areas | | Branding assets | Helps the project display the correct visual identity | | Intended website path | Reduces the risk of path conflicts or broken links | | Delivery destination plan | Ensures the published output goes to the expected location | If your team has already been working through project setup, you may also want to confirm earlier configuration choices before editing these fields. For example, website-related decisions from [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options) can affect how you choose delivery values here. Avoid making identity and path changes without checking how they relate to your current publishing setup. Even when the form is simple, the visible result can span project headers, website labels, and published paths. Preparing those decisions first makes the update much smoother. ## Understanding how Git connections work in Atloria projects In Atloria, a Git connection is part of a project’s source-based setup. You can connect a repository while creating a new project, or return later and add it from the project’s settings. If you already worked through the earlier setup choices in [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup) or [Connecting Projects to Git and Maintaining Access](doc:connecting-projects-to-git-and-maintaining-access), this screen is where that choice becomes an active project connection. The connection happens in two parts. First, you connect Atloria to your Git provider account. That gives Atloria permission to see the repositories your account is allowed to access. Second, you choose the specific repository that belongs to this project. Connecting your provider account does not automatically attach every repository. You still need to pick the repository for the current project and save it. When you review the project’s source settings, pay attention to three different ideas that can appear in the interface: - **Provider connection**: whether your Git account is connected to Atloria - **Repository connection**: whether this project is linked to a specific repository - **Current status or health**: whether Atloria can still access that repository and use it for source-based actions These are related, but they are not the same. For example, your provider account can be connected while the project still has no repository selected. Or the repository may be selected, but Atloria may show that access needs attention if permissions changed. Project Administrators usually connect a repository during initial onboarding when they want documentation or project setup to follow source content from the start. You can also open the project later and update the source connection if the repository changes, ownership moves, or the original connection was skipped. [SCREENSHOT: Project source settings showing provider connection area, repository selector, and connection status] ## Preparing your project and Git account for connection Before you open the Git connection screen, make sure you can complete both sides of the setup: access in Atloria and access in your Git provider. In Atloria, you need Project Administrator rights for the project you want to connect. If you can open the project but do not see the source or repository settings, ask an administrator to update your access first. You also need enough permission in your Git provider account to authorize Atloria and view the repository you plan to use. If the repository belongs to a team or company account instead of your personal account, the provider may require extra approval before Atloria can list it. That is especially important when you expect to see an organization repository in the picker. Gather the repository details before you start so you can move through the setup without guessing. The most useful details are: | What to confirm | Why it matters | |---|---| | Provider account or organization | Helps you choose the correct owner in the repository picker | | Repository name | Lets you confirm you selected the right project source | | Default branch | Helps you verify Atloria is pointed at the expected source branch | | Personal or organization-owned | Tells you whether extra approval may be required | If the Atloria project does not exist yet, create it first from the project area before looking for source connection settings. If you already have a project, open that project and go to its settings or source connection area. It also helps to confirm with your team whether this repository is the long-term source for the project. Changing repositories later can affect source-based work already tied to the existing project setup, so it is better to confirm ownership, branch choice, and repository name before you connect. [SCREENSHOT: Project settings area where source or repository connection options are available] ## Authorizing Atloria with your Git provider 1. Open the project you want to connect in Atloria, then go to the project’s source or repository settings. Look for the option to connect a Git provider, such as **Connect Git Provider**. 2. Click **Connect Git Provider** to start the authorization flow. Atloria will show the supported provider options. Select the provider that hosts your repository. 3. Atloria sends you to the provider’s sign-in or consent screen. If you have more than one account with that provider, choose the account that can access the repository you need for this project. 4. Review the approval prompts carefully. Depending on the provider, you may be asked to: - confirm your account - allow Atloria to access repositories - choose whether access applies to all available repositories or only approved ones - request organization approval if the repository belongs to a company or team account 5. Complete the provider’s approval steps and return to Atloria. After the redirect finishes, go back to the project’s source settings and confirm that the provider account now appears as connected. If the connection does not appear right away, refresh the page and check the source settings again. A successful provider authorization usually means Atloria can now show repositories available to that account, but you still need to choose the correct repository for this project before the setup is complete. If you are asked to wait for organization approval, stop here until that approval is granted. Atloria cannot list or connect the organization repository until the provider finishes that approval step. [SCREENSHOT: Git provider authorization screen and return to Atloria with connected account shown] ## Selecting the repository and saving the project connection 1. After your provider account shows as connected, stay in the project’s source settings and open the repository picker. 2. If Atloria shows an account or organization selector, choose the owner that contains the repository. This is important when your connected provider account can access both personal repositories and organization repositories. 3. Select the repository you want to attach to the project. Read the repository name carefully before continuing. If your team uses similar names for staging, archived, or forked repositories, double-check that you picked the active one. 4. Complete any source details Atloria shows on the same screen. Depending on the project setup, this may include the branch Atloria should use or another source location setting tied to the repository. 5. Click **Save** or the project’s connection action to finish linking the repository. After you save, Atloria may show an immediate status such as connected, pending sync, or another access confirmation message in the source settings area. This status helps you tell the difference between “repository selected” and “repository ready for source-based work.” Be careful when changing an existing connection. Switching the repository for a live project can redirect future source-based actions to a different codebase or documentation source. That is why Project Administrators should confirm the account, repository name, and branch before saving any change. If you are replacing an older repository, review the project details first so you do not accidentally point the project to the wrong source. [SCREENSHOT: Repository picker with account selector, repository list, branch field, and Save button] ## Managing connected repositories during project maintenance Project Administrators can return to the project’s Git connection settings at any time to review the current provider account, reconnect access, switch repositories, or refresh authorization after a permission change. This is useful when the original connection is still listed in Atloria, but the repository owner, team access, or provider approval has changed since the project was first set up. Common maintenance situations include: - **Permissions changed in the provider account**: a repository may stop appearing or Atloria may no longer confirm access - **Provider consent was revoked**: Atloria may still show the previous connection details, but source-linked actions can stop working until you reconnect - **The project moved to a different repository**: you can reopen the source settings and select the new repository for the project - **An organization repository now requires approval**: reconnecting may be necessary after the provider updates organization access rules Source-based workflows in Atloria depend on the active repository connection. If your project uses repository-linked updates, imports, or other source-driven actions, those actions rely on the current connection remaining valid. When access breaks, the project may still exist normally in Atloria, but repository-based actions will not continue until the connection is restored. If you remove the repository connection entirely, Atloria no longer has a source repository attached to that project. The project itself remains available, but source-linked actions are unavailable until you connect a repository again. For teams that regularly maintain repository access, it helps to review this screen after any provider-side permission change or repository transfer. For broader project maintenance after connection, see [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). ## Verifying your setup Once the repository is saved, open the source settings again and confirm the details shown on screen. You should see the connected provider account, the selected repository name, and a current status that indicates whether Atloria recognizes the connection. This is the fastest way to catch a wrong account or similarly named repository before your team starts using source-based project actions. Next, look for the first source-linked action available in the project. Depending on the project, Atloria may show an initial sync, import, or another repository-based action. Use that first action, or watch for its status, to confirm Atloria can actually read the repository rather than only display the saved connection. If the project screen shows a pending state, wait for that first repository check to complete and then refresh the page if needed. Also verify that the selected branch or source location matches the structure your project is supposed to use. A project connected to the right repository but the wrong branch can still produce confusing results. Compare what you see in Atloria with the branch your team expects to use for the project’s source-based workflow. If the repository does not appear in the picker, check these items before trying again: - the correct provider account is connected - Atloria was granted repository access during authorization - organization approval has been completed for team-owned repositories - your Git account can view the repository directly in the provider - the repository belongs to the selected account or organization in the picker If access still looks wrong, reconnect the provider account from the same settings screen and repeat the repository selection. [SCREENSHOT: Source settings showing connected account, repository name, branch, and current connection status] ## Overview Connecting a project to a Git provider in Atloria means linking two things: your provider account and the repository that belongs to the project. You start from the project’s source or repository settings, connect the provider account through the authorization screen, return to Atloria, and then choose the repository from the available list. After that, you save the connection and confirm the status shown in the project settings. The most important detail to remember is that provider access and repository selection are separate steps. Seeing a connected provider account does not mean the project is fully connected yet. The project is only ready for source-based work after the correct repository is selected and saved. During setup, pay close attention to: - the provider account you authorize - whether the repository is personal or organization-owned - the repository name shown in the picker - the branch or source location selected for the project - the connection status shown after saving This screen is also where you return later if access changes. If a repository stops appearing, permissions are updated, or provider approval is revoked, Project Administrators can reopen the same settings and reconnect or switch repositories as needed. If you have already connected a provider and saved the repository, the next step is checking whether Atloria continues to recognize that connection over time. Continue with [Reviewing Git Connection Status and Access Health](doc:reviewing-git-connection-status-and-access-health). ## Prerequisites Before you connect a repository to a project in Atloria, make sure these items are in place: - You can open the target project in Atloria - You have **Project Administrator** access for that project - You know whether the project should use a personal repository or an organization repository - You can sign in to the correct Git provider account - Your Git provider account can view the repository you want to connect - You know the repository name your team expects Atloria to use - You know the branch or source location the project should follow, if Atloria asks for it during setup It is also helpful to confirm these details with your team before you click **Save**: - which provider account owns the repository - whether the repository has been moved, renamed, or transferred recently - whether organization approval is required before Atloria can access team-owned repositories - whether this is a first-time connection or a replacement for an existing repository If you still need to create the project itself, use [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding). If your team is deciding whether to connect a repository now or continue with a manual setup, review [Connecting Projects to Git and Maintaining Access](doc:connecting-projects-to-git-and-maintaining-access). These checks keep the connection process simple and reduce the chance of selecting the wrong repository or running into missing-permission issues halfway through authorization. ## Opening the Supported Languages Page To evaluate coverage in Atloria, start from the signed-in workspace and open the area where Atloria lists supported languages and frameworks. If you have already worked through [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage) or [Evaluating Supported Languages and Parser Availability](doc:evaluating-supported-languages-and-parser-availability), use the same support listing rather than checking project screens first. 1. Sign in to Atloria and enter your main workspace. 2. Open the documentation or code parsing area where Atloria shows supported languages. 3. Look for the page that presents a language support matrix or a structured list of languages and frameworks. 4. Confirm that the page shows each language as its own entry, with support details displayed beside it. 5. Review the headings at the top of the list before you begin comparing your stack. On this page, you are looking for three things: - A language name in each row or entry - A parser support indicator for that language - A framework coverage area that shows related frameworks or stack options The parser support indicator is the first checkpoint. It tells you whether Atloria can read and analyze source files for that language. The framework coverage area gives extra detail about common frameworks associated with that language. That second part matters when your team depends on a specific frontend or backend stack. [SCREENSHOT: Supported Languages page showing a table or list with language names, parser support status, and framework coverage details] Before making any decision, make sure you are reading the current support matrix on the page itself. Do not rely on memory from an earlier review, especially if your team is planning a new project import or code upload. If the page layout includes status labels, badges, or grouped sections, use those visible markers as your source of truth for the latest coverage shown in Atloria. ## Checking Whether a Language Has Parser Support Once you are on the Supported Languages page, read each language entry from left to right and focus first on parser support. This tells you whether Atloria can process files written in that language before you worry about framework details. 1. Find the language your project uses in the list. 2. Check the parser support label or status shown for that language. 3. Note whether the status appears as available, limited, or unavailable. 4. Read any nearby qualifier, badge, or note that changes how you should interpret that status. 5. Repeat this for every language used in your repository. A language marked as available means Atloria shows parser support for that language. A language marked as limited means Atloria may process only part of what your team expects, so you should treat results more carefully. If a language is shown as unavailable, Atloria is signaling that code in that language is not currently covered by the parser listing on this page. It is important to separate language support from framework coverage. A language can appear in the list with parser support, while a framework connected to that language may still have different coverage. When you read the page, do not assume that a supported language automatically means every framework built on top of it is equally covered. Use the visible status markers exactly as they appear on the page. If Atloria shows a support note, a qualifier, or a limited-status label, include that in your evaluation. Those details affect how complete the parsing results may be when you later upload code in the parsing workspace. If you need a refresher on how parser labels work, return to [Understanding Supported Languages Frameworks and Parser Availability](doc:understanding-supported-languages-frameworks-and-parser-availability) or [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility). Here, the goal is narrower: confirm whether each language in your stack has a parser status you can rely on for planning. ## Reviewing Framework Coverage for Your Stack After checking parser support for each language, move to the framework coverage area in the same row or entry. This is where Atloria helps you judge whether your actual stack matches the technologies shown on the support page. 1. Locate the language entry for your project. 2. Look under or beside that language for the listed frameworks. 3. Search the framework list for the exact framework your team uses. 4. Check whether Atloria marks that framework as fully covered, partially covered, or simply listed without a stronger status. 5. Compare every major framework in your stack, not just the primary one. Many projects use more than one framework. For example, your team may have one framework for the frontend and another for the backend. Review both against the page instead of stopping after the first match. If Atloria shows multiple frameworks under one language, compare them one by one and note any differences in coverage markers. When reading framework coverage, stay literal. If your framework appears in the list, that is a stronger signal than assuming a similar framework is covered. If your framework is not shown, do not treat a neighboring or related framework as a substitute unless Atloria clearly presents it that way on the page. [SCREENSHOT: A language entry expanded or visible with several framework names and coverage indicators] This step is especially useful when your repository uses a common language but depends on a specific development stack. A language may be supported broadly, while framework coverage gives you a more realistic view of how well Atloria can support documentation work for that stack. If your project combines several layers, such as web interface, server logic, and supporting tools, compare each visible framework entry separately so you can spot gaps before rollout. ## Comparing the Page Against a Real Project Technology Stack The most reliable way to use the Supported Languages page is to compare it against a written list of the technologies your project actually uses. This keeps you from making decisions based on only the most visible part of the repository. 1. Write down every main language used in the project repository. 2. Add the major frameworks used for the frontend, backend, and any other important layer. 3. Open the Supported Languages page in Atloria. 4. Match each language on your list to a language entry on the page. 5. Check the framework coverage shown for each matching language. 6. Mark any item that is missing, limited, or unclear. 7. Decide whether the stack looks fully supported, partially supported, or in need of follow-up. A simple comparison table can help your team stay aligned: | Project technology | Found on Supported Languages page | Visible support result | |---|---|---| | Primary frontend language | Yes or No | Available, limited, or unclear | | Primary frontend framework | Yes or No | Listed, partial, or not shown | | Primary backend language | Yes or No | Available, limited, or unclear | | Primary backend framework | Yes or No | Listed, partial, or not shown | As you compare, focus on the technologies that shape documentation output most directly. If a language is central to the repository, its parser status matters more than a minor supporting script. If a framework drives routing, component structure, or application behavior, its coverage matters more than a small helper library. When you finish, classify the stack in plain terms: - **Fully supported**: all major languages and frameworks appear with strong coverage signals - **Partially supported**: some major items are limited or missing - **Needs follow-up**: one or more core technologies are unclear, unlisted, or mixed across support levels This comparison gives Project Administrators, Documentation Managers, and Technical Writers a shared basis for deciding whether to move ahead with code parsing and documentation generation. ## Interpreting Gaps, Partial Coverage, and Mixed-Stack Results Not every project will line up neatly with the Supported Languages page. In Atloria, gaps and mixed results do not always mean you must stop, but they do mean you should plan more carefully. If a language is supported but your framework is not listed, treat that as a partial confidence result. Atloria may still be able to analyze source files in that language, but the framework-specific structure your team relies on may not be reflected clearly in the support matrix. That can affect how complete or organized the resulting technical documentation feels. If your repository combines supported and unsupported languages, review the stack by importance rather than by file count alone. A project may still be workable if the main documentation-driving language is supported and a smaller secondary language is not. On the other hand, if a major part of the product depends on a language or framework with limited coverage, expect uneven results. Partial parser support usually means Atloria can recognize some parts of the codebase but may not capture everything with the same depth or consistency as a fully supported stack. In practical terms, this can lead to documentation that is useful in some areas and thinner in others. That is why limited support should be treated as a planning signal, not just a label. Different roles can use these results in different ways: - **Project Administrators** can decide whether a rollout should proceed now or wait for clearer support. - **Documentation Managers** can estimate how much manual review or cleanup may be needed after parsing. - **Technical Writers** can identify where they may need to supplement generated content with hand-written pages. When support is mixed, record what is strong, what is partial, and what is missing. That shared view helps teams avoid overpromising what the first documentation pass will deliver. ## Resolving Common Questions When Coverage Is Unclear Some support decisions are straightforward, but others require a closer reading of the page. When coverage is unclear, use the visible language and framework indicators together instead of relying on only one part of the listing. If a language appears on the page but your framework does not, treat the language as supported only at the language level. Atloria is showing that it can work with that language, but it is not confirming framework-specific coverage for your exact stack. In that case, mark the framework as unconfirmed in your planning notes. If a framework is listed but the parser status for its underlying language is limited, the language status should guide your expectations. The framework listing is useful, but limited parser support means results may still be incomplete. Do not treat the framework name alone as proof of full readiness. If your project uses a custom or in-house framework, look for the underlying language first. Then compare the custom framework to any similar framework names shown on the page without assuming they are equivalent. If Atloria does not list your framework directly, record it as not listed rather than forcing a match. Mixed support levels across the stack are also common. For example, one part of the project may show strong language support while another shows limited framework coverage. In that situation, separate your evaluation into parts: - Core language support - Frontend framework coverage - Backend framework coverage - Any custom or unlisted layers [SCREENSHOT: Example of a support review where one language shows available parser support and another entry shows limited or missing framework coverage] This approach makes rollout readiness easier to judge. Instead of asking whether the whole project is simply supported or unsupported, ask which parts of the stack Atloria clearly covers and which parts may need extra review. That gives your team a more realistic basis for planning uploads, parsing, and documentation review. ## Overview Use the Supported Languages page in Atloria as a decision screen before you upload or parse a repository. The page is most useful when you read it in two layers: first by language, then by framework. That order helps you confirm whether Atloria can analyze the source files at all before you decide how well it matches the structure of your specific stack. Key points to keep in mind: - Start with the language entry, not the framework list - Check the parser status shown for each language - Review framework coverage separately for every major part of the stack - Treat limited or missing coverage as a planning signal - Compare the page against your real repository, not against assumptions This document builds on the earlier evaluation steps in [Evaluating Supported Languages and Parser Availability](doc:evaluating-supported-languages-and-parser-availability). That earlier guide explains how to read parser availability in more detail. Here, the focus is on combining parser status with framework coverage so you can make a practical support decision for a real project. A good evaluation result is not just “yes” or “no.” In many cases, the better outcome is a clear support profile: - Which languages are clearly supported - Which frameworks are explicitly covered - Which parts of the stack are only partially supported - Which items need follow-up before rollout That support profile is useful across project setup, code parsing, and documentation planning. It helps teams decide whether to proceed with confidence, prepare for manual review, or pause until they have clarified important gaps. The next document, [Using Language Support Information During Project Planning](doc:using-language-support-information-during-project-planning), shows how to turn this evaluation into rollout and documentation decisions. ## Prerequisites Before evaluating framework coverage in Atloria, make sure you have the basic information needed to compare your project against the Supported Languages page. You do not need deep technical expertise, but you do need a clear list of the technologies your team is using. Have these items ready: - Access to your Atloria workspace - Permission to view the Supported Languages page - A list of the main languages used in the repository - A list of the main frameworks used by the project - Enough project context to tell which technologies are core and which are secondary It also helps if you have already completed the earlier reading in this section, especially: - [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage) - [Evaluating Language and Framework Support in Atloria](doc:evaluating-language-and-framework-support-in-atloria) - [Evaluating Supported Languages and Parser Availability](doc:evaluating-supported-languages-and-parser-availability) Those guides explain how to find the support listing and how to read parser status labels. This document assumes you already know where the page is and how to identify the main support indicators. Before you begin, avoid these common mistakes: - Checking only one language in a multi-language repository - Assuming a listed language means every framework under it is covered - Treating a similar framework name as an exact match - Ignoring limited-status labels because the language itself appears on the page If your project includes a frontend, backend, and custom internal layer, gather all three before you review the page. The more complete your stack list is, the more accurate your support decision will be. Once you have that list ready, you can move directly from support evaluation into planning decisions in [Using Language Support Information During Project Planning](doc:using-language-support-information-during-project-planning). ## Finding the right project from the project list In Atloria, the **Projects** list is the fastest place to review many projects at once before you open any individual project. If you already know how project navigation is organized, use the patterns from [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces) and focus here on scanning the portfolio for the next item that needs attention. Look across each project row for the details that help you judge priority quickly. Documentation managers usually start with the **project name**, current **status**, assigned **owner**, and the **last updated** information. Those row details tell you whether a project is active, who is responsible for it, and whether work has moved recently. When several projects are in progress at the same time, this row-level information is often enough to decide which project needs a closer review. Use the search box when you want to find a project by name. If the list is crowded, apply the available filters to narrow what you see to the projects that matter for the current review. For example, you might focus on active work, projects that look at risk because they have not been updated recently, or items that changed most recently and may need follow-up. Sorting the list helps you bring the most relevant rows to the top, especially when you are checking ownership or recent updates. Visual status markers and row metadata are useful because they let you scan for changes without opening every record. A project with a clear status indicator and a recent update may only need a quick check, while a project with older activity may need deeper review. When you find the project you want, open it directly from the row to move from portfolio monitoring into project-level oversight. [SCREENSHOT: Projects list showing project rows with status, owner, and last updated details] ## Reviewing project status from the project home page The **Project Home** page is the main dashboard for one project. After opening a project from the **Projects** list, use this page to understand the project’s current state before jumping into a workspace. This saves time and helps you avoid opening the wrong area first. Start with the summary information shown near the top of the page. Documentation managers typically use this area to confirm the project identity, review ownership details, and check the current operational state. Project administrators often use the same page to confirm whether the right people, linked resources, and work areas are already attached to the project. If something looks incomplete here, that is often the first sign that follow-up is needed. The most useful parts of **Project Home** are the summary panels and linked sections that show what is connected to the project and what has happened recently. Look for high-level progress signals, ownership information, and any linked resources that point to where the work is actually happening. If you are deciding whether to review documentation progress, investigate a setup issue, or check recent changes, this page gives you the context to choose the right next step. Different users will focus on different parts of the page: - **Documentation managers** usually look for progress clues, recent work, and the linked workspace where documentation activity is happening. - **Project administrators** usually check ownership, project setup completeness, and whether the correct linked work areas are available. Once you have enough context, use the navigation on **Project Home** to open the linked workspace or supporting view that matches the task. If you need more detail on project-level controls, see [Managing Project Operations Across Project Home Tabs](doc:managing-project-operations-across-project-home-tabs). [SCREENSHOT: Project Home page with summary panels, ownership details, and linked sections highlighted] ## Opening the correct linked workspace for the task at hand From **Project Home**, use the **linked workspaces** area to move into the part of Atloria where the actual follow-up work happens. This section is especially important when one project connects to more than one work area and you need to choose carefully instead of opening the first link you see. Review each workspace entry before clicking it. The most helpful clues are the workspace name and any nearby details that explain its purpose or ownership. Those labels help you tell whether a workspace is intended for documentation work, project operations, or another related activity. If several workspaces are attached to the same project, pause long enough to confirm which one matches the task you are handling. 1. Open the project and go to **Project Home**. 2. Find the **linked workspaces** section. 3. Read the workspace names and any visible purpose or ownership details. 4. Click the workspace that best matches the work you need to do. 5. After the workspace opens, confirm you are in the correct project context before making changes. That last check matters. Make sure the workspace you opened clearly belongs to the project you intended to review. If the page content does not match your task, do not continue working there. Return to **Project Home** and choose a different linked workspace instead. This lets you switch paths without losing the project context you already gathered. If you need a refresher on how linked workspaces fit into the broader project structure, go back to [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). For daily oversight, the goal is simple: use **Project Home** as your decision point, then open the exact workspace that supports the next action. [SCREENSHOT: Linked workspaces section on Project Home with multiple workspace entries] ## Using recent activity to monitor day-to-day project operations The **Recent Activity** view helps you monitor what changed, when it changed, and who made the update. Use it when you want to check movement across projects or confirm whether work inside one project is still active. This view is especially useful after you review the **Projects** list and **Project Home**, because it adds a timeline to the status signals you already saw. Open **Recent Activity** from the project area and review the entries in order. Each activity item is most useful when you read it as a combination of three things: - **Timestamp** — when the change happened - **Actor** — who made the update - **Action type** — what changed Together, these details help you understand whether work is progressing, repeating, or stalling. For example, a cluster of recent updates may show active coordination, while a long gap in activity may suggest that a project needs follow-up. Repeated edits in the same area can also signal that a page, version, or workspace item still needs review. 1. Open **Recent Activity** from the project area. 2. Check whether you are viewing activity across projects or within the selected project. 3. Read the newest entries first, paying attention to the timestamp, actor, and action. 4. Look for patterns such as no recent updates, repeated changes, or newly completed work. 5. Open the related project or item from the activity entry when you need to investigate further. This view is not only for spotting problems. It is also a quick way to confirm that a handoff happened, that a workspace update was completed, or that a project has moved forward since your last review. When an entry looks important, use it as a shortcut back into the related project or workspace item so you can continue the investigation without starting over. [SCREENSHOT: Recent Activity view showing timestamps, user names, and action entries] ## Coordinating oversight across projects, homes, workspaces, and activity feeds Strong operational oversight in Atloria comes from using several screens together, not from relying on only one view. The most practical routine is to start broad, narrow your focus, take action in the correct workspace, and then confirm the result in **Recent Activity**. 1. Start in the **Projects** list to scan the portfolio. 2. Open a project that shows a status, ownership, or update signal worth reviewing. 3. Use **Project Home** to understand the project’s current context. 4. Open the linked workspace that matches the task. 5. Return to **Recent Activity** to verify that work is moving or to confirm the latest change. Documentation managers and project administrators often follow the same path but for different reasons. Documentation managers usually use this flow to track content progress, confirm where documentation work is happening, and decide which project needs editorial attention. Project administrators usually use it to check ownership, confirm operational follow-up, and make sure the right work areas are connected to the project. A repeatable review routine helps. Many teams begin with a quick portfolio scan in the **Projects** list, then open only the projects with meaningful signals such as older updates, unclear ownership, or recent activity that needs interpretation. If the list already answers your question, stay at the portfolio level. If the row signals are unclear, drill into **Project Home**. If the issue requires action, move into the linked workspace. If you need proof that something changed, check **Recent Activity**. This approach keeps you from opening too many screens too early. It also helps you separate monitoring from action: the **Projects** list shows where attention may be needed, **Project Home** explains the project context, linked workspaces are where updates happen, and **Recent Activity** confirms movement afterward. ## Resolving common issues when monitoring and opening project work areas When portfolio monitoring does not behave as expected, the problem is often caused by the current view rather than the project itself. Start by checking what is visible on the screen before assuming something is missing. If a project does not appear in the **Projects** list, review the search box first. A leftover search term can hide valid results. Then check any active filters and sorting choices. A project may be outside the current status view, assigned to a different owner than expected, or pushed lower in the list because of the selected sort order. Clear or adjust those controls and search again. If a linked workspace is missing or opens the wrong area, go back to **Project Home** and review the **linked workspaces** section carefully. Some projects may have more than one workspace attached, and similar names can make it easy to choose the wrong one. Read the visible labels before reopening the link. If the workspace does not match the task after it opens, return to **Project Home** and select a different entry. If **Recent Activity** does not show the update you expected, refresh the view and confirm that you are looking at the correct context. You may be viewing activity for a different project or a broader feed than intended. Also consider whether the action happened in a workspace that appears in tracked activity. If not, you may need to return to the related project or workspace and confirm the change there directly. If **Project Home** does not provide enough detail for oversight, review whether the project record appears complete. Missing ownership details, unclear status, or incomplete workspace links can make monitoring harder. In that case, compare what you see on **Project Home** with the project’s visible ownership, status, and linked work areas, then follow up in the appropriate workspace or admin area. ## Overview This guide focuses on the day-to-day oversight workflow used by documentation managers and project administrators in Atloria. Instead of concentrating on one project screen in isolation, it shows how four areas work together: the **Projects** list, **Project Home**, **linked workspaces**, and **Recent Activity**. Use the **Projects** list when you need a portfolio view across many projects. This is where you scan project rows, compare status and ownership, and decide which projects need attention. After that, open **Project Home** for a single project to review summary details, ownership information, linked resources, and the project’s current operating context. From there, move into the correct linked workspace to do the actual follow-up work. Finally, use **Recent Activity** to confirm changes, understand who updated what, and spot stalled or repeated work. This document builds on [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces), so it does not repeat the basic navigation model. Instead, it shows how to use that navigation for oversight and coordination across a portfolio. You will learn how to: - Find the right project quickly from the **Projects** list - Review project status from **Project Home** - Choose the correct linked workspace for the task - Use **Recent Activity** to monitor daily operations - Follow a repeatable oversight routine across multiple projects - Resolve common issues when projects, workspaces, or activity updates do not appear as expected If your goal is to keep projects moving without opening every workspace manually, this workflow gives you a practical way to monitor progress and intervene only where needed. ## Prerequisites Before using the oversight workflow in this guide, make sure you can access the core project areas in Atloria and that you are already comfortable moving between project-level screens. You should be able to: - Sign in to Atloria and open the main authenticated workspace - Access the **Projects** list - Open an individual project and view **Project Home** - Recognize the **linked workspaces** area on a project - Open **Recent Activity** from the project area This guide assumes you already understand how project navigation is structured. If you need help with that first, read [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). It also helps if your role includes regular monitoring responsibilities, such as: - Reviewing project ownership and status - Checking whether documentation work is progressing - Following up on recent changes - Opening the correct workspace for project or documentation tasks You do not need advanced setup knowledge to follow this guide. However, the workflow is most useful when the projects you monitor already have clear ownership, visible status information, and at least one linked workspace available from **Project Home**. If those details are incomplete, you can still use the guide, but some monitoring steps may require extra checking. For the next step in this learning path, continue with [Using Project Home to Coordinate Documentation Work](doc:using-project-home-to-coordinate-documentation-work). ## Understanding Where API Reference Appears In Atloria, you can read **API reference** content in two places: inside a project workspace and on the published public documentation site. The reference content may describe the same endpoints and schemas in both places, but the surrounding layout changes depending on where you open it. Inside a project, you reach API reference pages from the project’s **technical documentation** area. You typically use the **left navigation tree** to move through documentation sections and open a reference page from the same sidebar that also contains other technical pages. This view is useful when you are reviewing documentation as part of project work, comparing reference pages with nearby guides, or checking how API content fits into the rest of the project structure. On the public documentation site, readers arrive through the published docs navigation instead of the private project workspace. The page is presented as public-facing documentation, so the focus is on reading and sharing rather than working inside the project. Public visitors see the documentation content itself, along with the site navigation, page headings, and anchor links that help them move around long reference pages. In both places, the main reading pattern is similar: - A **left navigation area** or docs navigation for moving between pages - A **main content area** for the selected API reference page - Clear **endpoint** or **schema headings** - **In-page links** or heading anchors for jumping to sections on the same page - Links to related reference content, such as connected schemas If you already worked through [Browsing Entity Reference Pages and Related Details](doc:browsing-entity-reference-pages-and-related-details), think of this guide as the same reading process viewed across both private project docs and public published docs. [SCREENSHOT: API reference page showing left navigation, main content area, and in-page heading anchors] ## Browsing API Reference Inside a Project When you are inside a project in Atloria, open the project’s **technical documentation** area and use the **documentation navigation** on the left to find API reference pages. These entries appear as part of the project documentation structure, so you can move between regular technical pages and API-specific pages without leaving the project workspace. API reference pages are usually easiest to read when you treat the left navigation as your map. Resource groups, endpoint pages, and schema pages may be listed in the same documentation tree, and longer sections may appear under collapsible groups. If a section is expanded, you can quickly scan nearby entries to understand how the reference is organized before opening a page. Once a page is open, use the page structure instead of scrolling from top to bottom. Long API pages often include nested headings that break the content into practical sections, such as: - **Request parameters** - **Authentication** - **Request body** - **Responses** - **Schemas** or related models - **Examples** These headings are especially useful when Atloria shows a **table of contents** or linked heading anchors. Click the section name to jump directly to the part you need, rather than reading the full page in order. This is helpful when you only need to confirm a field name, check whether a parameter is required, or compare response details. Project view is also useful because nearby pages often connect reference content with explanatory docs. You may move from a task-focused page to an endpoint page, then follow a schema link to inspect field definitions more closely. Collapsible navigation groups, linked headings, and cross-links between technical guides and API reference pages make this much easier. [SCREENSHOT: Project technical documentation view with API reference entries expanded in the left navigation] ## Reading Published API Reference as a Public Visitor Published API reference in Atloria appears in the public documentation site layout. The content may mirror what exists inside the project, but the reading experience is designed for visitors who are browsing documentation rather than working in the private project workspace. As a public reader, you usually arrive in one of three ways: - By opening the published documentation home or section navigation - By selecting an API reference page from the public docs menu - By following a direct link to a specific reference page or anchored section The public view keeps the focus on reading. You use the visible documentation navigation, page headings, and anchor links to move through the content. If the public site includes browse or search controls, those can help you find a specific endpoint or schema page faster, especially in larger documentation sets. The biggest differences from project view are the surrounding context and presentation. In public view, you may notice: - Public-facing **branding** - A cleaner reader layout with no project workspace context - A **public page address** you can share directly - The absence of project-only surroundings and internal working context Even with those differences, the page content is still read the same way. Look for the endpoint title, grouped sections, and linked schemas. If you need to send someone to an exact part of the page, use the page’s heading anchor. When a heading has a linkable anchor, you can copy or share that anchored page address so the reader lands on the exact endpoint or schema section instead of the top of the page. This makes public API reference especially useful for external reviewers, customers, or partners who need direct access to a specific operation or schema definition without opening the full project workspace. [SCREENSHOT: Public documentation page showing API reference content with public navigation and anchored section links] ## Using the Information Shown on an API Reference Page An API reference page in Atloria is easiest to understand when you read it from the top down once, then return to the sections you need. Start with the main identifier for the operation or schema. On an endpoint page, this usually includes the **endpoint title**, the **HTTP method** label, the **path**, and a short description of what the operation does. Below that summary, the page usually breaks into grouped sections. For request details, pay attention to the labels that show where each value belongs: - **Path parameters** for values included in the URL path - **Query parameters** for optional or filtering values added to the request - **Headers** for required request headers - **Request body** for structured data sent with the request When Atloria shows field lists or schema tables, look for indicators that separate **required** fields from **optional** ones. This helps you understand which values must be included and which ones can be left out. If a field name is unclear, follow any linked schema or related model reference to inspect its full definition. Response sections are just as important. These often include: - **Status codes** - A **response body** structure - Field descriptions - Example responses Use the status code area to understand what kinds of outcomes the endpoint can return. Then read the response schema to see what data comes back and how fields are grouped. Example payloads are especially useful when you want to compare the field list with a realistic response. Some pages also show **authentication requirements** near the top or in a dedicated section. If authentication is listed, read that before reviewing request details so you understand whether the endpoint expects authorization information. Linked schemas and related reference pages help you connect one endpoint to the data structures it uses elsewhere in the documentation. ## Moving Between Conceptual Docs and Reference Content In Atloria, conceptual guides and API reference pages work best together. A task-based guide explains **when** to use something and **why** it matters. An API reference page gives the exact details, such as parameter names, request structure, response fields, and status codes. When you are reading technical documentation, move between these two page types based on the kind of answer you need. A common reading path starts on a guide page. You might be reading a workflow explanation, setup article, or integration walkthrough and then open a linked endpoint reference when you need exact request details. From there, you may follow links again to inspect a related schema and confirm what each field means. This is often the fastest way to move from general understanding to exact implementation details. Typical navigation patterns include: - Starting on a **task-oriented guide** - Opening a linked **endpoint reference** - Jumping to the **request body** or **responses** section - Following a linked **schema** to inspect field definitions - Returning to the guide after confirming the details For documentation managers, this same flow is useful when reviewing published navigation. Check whether public readers can discover API reference pages through the docs hierarchy, visible links inside guide pages, and the published page structure. If a guide mentions an operation but the related reference page is hard to find, readers may miss important details. Stay on a conceptual page when you need workflow context, explanations, or decision-making help. Switch to API reference when you need exact names and structures, including: - Parameter names - Header requirements - Payload fields - Response codes - Schema definitions For broader reading patterns across technical docs, see [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views) and [Exploring API Reference Sections Inside Projects](doc:exploring-api-reference-sections-inside-projects). ## Finding What You Need When a Reference Page Is Hard to Read Some API reference pages in Atloria are long, especially when they include multiple request sections, large schemas, or detailed response examples. When a page feels hard to read, stop scrolling and use the page structure to narrow your focus. Start with the **navigation tree** and the page’s **heading anchors**. If the page includes a table of contents or linked headings, use those links to jump directly to the section you need. This is usually faster than reading the full page in order. Focus on the section that matches your question: - **Request** details when you need to know what to send - **Authentication** when access requirements are unclear - **Responses** when you need to know what comes back - **Schemas** when a field definition is missing from the current section If a link or layout looks unfamiliar, check whether you are in **project view** or **public view**. The same API reference content can appear in both places, but the surrounding navigation, branding, and page framing may look different. In project view, you are reading inside the project documentation workspace. In public view, you are reading the published documentation site. When a field name appears without enough explanation, follow any linked schema or related endpoint. This is often where Atloria provides the missing context. A field may be briefly listed on one endpoint page but fully described on a linked schema page. For collaboration, use the page address or a **heading anchor link** to share the exact section with someone else. This is especially helpful during reviews, because you can send a reviewer straight to the relevant endpoint, response block, or schema definition instead of asking them to find it manually. [SCREENSHOT: Long API reference page with anchor links highlighted for request, responses, and schemas] ## Overview Reading API reference in Atloria is mainly about understanding **where you are** and using the page structure well. The same reference content can appear in a private project workspace and in published public documentation, but the reading tools stay familiar: navigation, headings, anchor links, and links to related schemas. The most important ideas to keep in mind are: - **Project view** is for reading API reference inside a project’s technical documentation structure - **Public view** is for reading the published version in a public-facing documentation site - The **left navigation** helps you move between reference pages and nearby technical docs - **Heading anchors** help you jump to request, response, authentication, and schema sections - **Linked schemas** and related pages provide missing context when a field or structure is not fully explained on the current page When you read an endpoint page, start with the top summary: method, path, and description. Then move to the section that answers your immediate question. If you need exact input details, go to request parameters or request body. If you need output details, go to responses and status codes. If a field is unclear, open the linked schema. This guide focuses on reading and navigation across project and public contexts. If you need a deeper refresher on entity-style reference pages and related detail views, return to [Browsing Entity Reference Pages and Related Details](doc:browsing-entity-reference-pages-and-related-details). If you want to continue from here into how broader technical reference sections are organized, the next guide is [Browsing Technical Reference Sections and Entities](doc:browsing-technical-reference-sections-and-entities). ## Prerequisites Before using this guide, you should already be comfortable moving around Atloria documentation pages and recognizing the difference between project documentation and published documentation. You do not need to create or edit reference content, but you should know how to open a project and browse documentation menus. It helps if you already know how to: - Open a project workspace in Atloria - Browse the **technical documentation** navigation inside a project - Open published documentation pages as a public reader - Use page headings and sidebar navigation to move between docs pages If those basics are still new, review these guides first: - [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages) - [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects) - [Reading Published API and Technical Documentation](doc:reading-published-api-and-technical-documentation) You will get the most value from this guide if you are trying to answer questions such as: - Where do I find API reference inside a project? - How does the same reference look in public docs? - How do I jump to a specific request or response section? - How do I share a direct link to one endpoint or schema section? You do not need admin access for the reading tasks described here. The guide is written for readers, reviewers, and documentation team members who need to navigate API reference content efficiently in both private and public documentation views. ## Opening project analytics and choosing the reporting scope In Atloria, open the project you want to review, then use the project navigation to go to **Analytics**. Make sure you are looking at the analytics view for that specific project, not an admin-wide reporting area. If you do not see **Analytics** in the project navigation, your account may not have access to project reports. In that case, ask an administrator to confirm your permissions in the admin workspace. Once the **Analytics** page opens, start with the date range control at the top of the report. Use it to switch between a recent window, such as the last few days or weeks, and a longer view that shows broader patterns. Short ranges help you review the impact of a recent release or content update. Longer ranges are better when you want to understand whether a trend is stable over time. [SCREENSHOT: Project Analytics page showing the project navigation and date range selector] Before reading any numbers, confirm the reporting scope is limited to the current project. This matters when your team manages several projects in Atloria. A project-only view helps you judge the performance of one documentation set without mixing in traffic from other teams or products. As you review the page, pay attention to how the report groups content. In many project analytics views, totals may reflect published documentation, versioned content, or release-related pages connected to the current project. If the screen offers grouping by version, section, or content area, use that grouping early. It gives you a cleaner starting point for deciding whether readers are finding the right release notes, setup guides, or reference pages inside this project. If you need a refresher on the broader project analytics workflow, see [Using Project Analytics and Audit Signals for Ongoing Operations](doc:using-project-analytics-and-audit-signals-for-ongoing-operations). ## Reading the core project metrics that show documentation performance At the top of the project **Analytics** view, start with the summary cards or headline metrics. Focus first on the numbers that show reach and usage, such as **Views**, **Unique Visitors**, and any engagement measure shown on the page. These top-level figures tell you whether people are finding the project documentation and whether they are spending meaningful time with it. Read these numbers together instead of one at a time. For example: - High **Views** with low **Unique Visitors** can suggest repeat use by a smaller audience. - Strong **Unique Visitors** with weak engagement can point to pages that attract clicks but do not hold attention. - Flat traffic with stable engagement may mean the content is serving a steady audience well, even without growth. Next, look for the change indicator beside each metric. Atloria may show whether the current period is up, down, or unchanged compared with the previous period. Use those comparisons to spot movement quickly. A rise in views after a release can be a healthy sign, but only if engagement also stays strong. If views increase while engagement drops, readers may be landing on the right pages but not getting what they need. Below the summary area, review the traffic trend chart. This chart helps you separate a one-day spike from a sustained pattern. A single sharp jump usually means a release event, announcement, or temporary burst of interest. A steady upward line is more useful when planning ongoing content investment. [SCREENSHOT: Top metric cards and traffic trend chart in the project Analytics view] If the analytics screen breaks performance down by **Version**, **Section**, or another content grouping, use that view to connect traffic to specific documentation areas. This is especially helpful when one release version is drawing most of the attention, or when a section such as setup, upgrade, or reference content is carrying most of the project’s reader activity. ## Finding weak spots by drilling into low-performing pages and sections After reviewing the top-level numbers, move down to the page list or performance table in the **Analytics** view. This is where Atloria becomes most useful for content decisions. Open the list of pages, sections, or grouped content items and sort it using the available columns, such as **Views**, **Engagement**, or similar performance measures shown on the screen. 1. Sort the list by **Views** to find pages that receive meaningful traffic. 2. Re-sort by **Engagement** to find pages where readers appear less involved. 3. Compare the two results to spot pages that attract attention but do not perform well once opened. 4. Use the page labels, section names, or path-style names in the list to identify where those pages sit in the project structure. This comparison helps you find weak spots that matter. A page with low traffic and low engagement may simply be new, niche, or not yet promoted. A page with high traffic and weak engagement is usually a stronger candidate for revision because readers are already arriving there and may be leaving without finding clear answers. Look closely at section or folder labels to see whether underperformance clusters in one area. You may notice patterns such as weaker setup guides, thin release notes, or version-specific pages that are not getting attention after publication. If the report includes version grouping, compare older and newer release content side by side. [SCREENSHOT: Analytics table with sortable columns for views and engagement] Before deciding a page is failing, cross-check timing. Newly published pages, recently renamed pages, or content added under a new release version often need more time before their numbers become meaningful. Use the project context you already know—recent launches, publishing dates, and version changes—to judge whether the issue is discoverability, release timing, or the content itself. ## Using analytics trends to support release planning decisions Project analytics are especially useful when you read them against your release calendar. In Atloria, use the date range control to look at the period before, during, and after a release. Then compare which pages or sections gained attention at each stage. This helps you understand what readers need earliest and what they return to after launch. 1. Set the date range to include a recent release window. 2. Review the traffic trend chart for spikes around the release date. 3. Open the page or section list and identify which release-related pages rose during that period. 4. Compare those results with another release period or a longer date range to see whether the pattern repeats. Pages that spike every time you ship a release are usually release-critical. These often include upgrade instructions, change summaries, feature availability notes, and pages that help readers move from one version to another. If those pages consistently draw traffic before release day, they may need earlier publication. If they surge only after release, readers may be searching for help after encountering issues, which can signal that the content needs clearer placement or stronger links from release announcements. Use version or section grouping, if available, to compare performance across release-related content. For example, one version’s release notes may draw strong traffic while the matching setup updates do not. That can mean readers know a change happened but cannot easily find the practical guidance that follows from it. When planning the next release, prioritize the documentation areas that historically attract the most reader activity. This does not mean chasing every temporary spike. Instead, look for recurring patterns across multiple release windows. Those patterns give you a more reliable basis for deciding which pages should be updated first, reviewed earlier, or highlighted more clearly in the upcoming release cycle. ## Turning project analytics into content improvement priorities Once you have identified strong and weak areas, turn those findings into specific editing decisions. In Atloria, the most useful pattern is often a page with high traffic but weak engagement. That combination usually means the page is important, but readers are not getting enough value from it in its current form. Use the analytics view to build a short list of pages that need attention. Focus on pages that show one or more of these patterns: - High traffic with weaker engagement than nearby pages - Repeated traffic during release periods but inconsistent reader follow-through - Strong performance in one version and weaker performance in the next - Section-level underperformance that affects a whole content area For each page or section, connect the analytics finding to a likely content action. A setup guide may need clearer steps. A release note may need better links to related documentation. A heavily visited reference page may need better examples or easier scanning. On the other hand, pages with very low traffic over a longer reporting window may be better candidates for merging, simplifying, or deprioritizing rather than expanding. [SCREENSHOT: Project Analytics view beside a content review or editing workflow] Record these decisions in your team’s normal review process. When you assign an update, note the specific analytics reason behind it, such as weak engagement on a high-traffic page or repeated release-period spikes on a page that lacks enough detail. This makes content planning easier to defend and easier to revisit later. After you publish the update, return to the same **Analytics** view in the next reporting period. Use the same project scope and a comparable date range so you can see whether the revised page shows stronger traffic, steadier engagement, or better performance relative to similar content. ## Resolving misleading analytics readings before making decisions Analytics are only useful when you are confident you are reading the right view. If the numbers in Atloria seem too low, too high, or inconsistent with what your team expects, check the report setup before changing content plans or release priorities. 1. Confirm the selected date range at the top of the **Analytics** page. 2. Make sure the report is showing the current project, not a broader workspace or admin reporting area. 3. Check any grouping or filtering options, such as **Version**, **Section**, or page grouping, to be sure you are comparing the same type of content. 4. Re-open the page list and verify that the pages you expect are included in the results. A page that looks underperforming may simply be too new to judge fairly. If it was recently published, moved to a different section, renamed, or added under a new release version, its traffic history may not yet reflect its long-term value. In those cases, compare a longer date range or wait until the next reporting period before making a final decision. Release-related traffic can also be misleading when you focus only on short-term spikes. A sudden jump around launch week may look important, but it may not represent lasting demand. Compare the short window with a broader range to see whether the page remains useful after the release rush passes. If stakeholders question the numbers, make sure everyone is reviewing the same project analytics screen with the same date window and the same grouping choices. Most disagreements come from looking at different scopes rather than from the content itself. Aligning those settings first makes the discussion much more productive. ## Overview This guide focuses on how to use the **Analytics** view inside a single Atloria project to make better content and release decisions. The goal is not just to read traffic numbers, but to connect those numbers to practical actions in your documentation workflow. You use this project-level view to answer questions such as: - Which pages are getting the most attention? - Which sections attract readers but do not keep them engaged? - Which release-related pages spike every time a new version goes live? - Which content areas deserve updates, expansion, merging, or less effort? The process starts by opening the project’s **Analytics** page and choosing the right date range and project scope. From there, you read the headline metrics, compare current results with the previous period, and use trend charts to separate temporary bursts from steady demand. The page list or performance table then helps you identify weak spots at the page or section level. This guide assumes you already understand the broader use of project analytics and audit information in day-to-day operations. If you need that wider context, review [Using Project Analytics and Audit Signals for Ongoing Operations](doc:using-project-analytics-and-audit-signals-for-ongoing-operations) before working through the steps here. What makes this guide different is its focus on decision-making. You are not just monitoring activity. You are using project analytics to decide what to improve before the next release, what to publish earlier, what to revise after launch, and what content may no longer justify continued effort. That makes the **Analytics** view a planning tool as much as a reporting screen. ## Prerequisites Before you use project analytics for content and release decisions in Atloria, make sure the following are true: - You can sign in to Atloria and open the project you want to review. - Your account can access the project’s **Analytics** view. - The project already has published or versioned documentation that readers can access. - Enough time has passed since publication or release for the analytics to show meaningful activity. - You know which release period, version, or documentation area you want to evaluate. It also helps to have some working knowledge of the project’s structure so you can recognize page names, sections, and release-related content when they appear in the analytics table. If your team uses versioned documentation, be ready to compare one version’s performance with another rather than looking only at total project traffic. For the most useful review, gather a small amount of context before opening the report: | What to have ready | Why it helps | |---|---| | Recent release dates | Lets you compare traffic before, during, and after a release | | Key documentation sections | Helps you recognize whether setup, release, or reference content is underperforming | | Recent page changes | Prevents you from misreading new, moved, or renamed pages | | Team review priorities | Makes it easier to turn analytics into editing decisions | If you are still getting familiar with project navigation, start with [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). After you finish this guide, continue with [Using Project Activity Signals to Prioritize Work](doc:using-project-activity-signals-to-prioritize-work) to turn these findings into a practical work queue for your team. ## Setting Up the Project and Assigning Roles Start in Atloria from the main signed-in workspace and open the project creation flow used for new documentation workspaces. On the project creation screen, enter the **Project Name** first, then choose the project’s visibility option based on whether the workspace should stay limited to internal team members or be prepared for later public release. If the screen includes default documentation choices, set them before you create the project so the team starts with the right structure instead of changing it after content work begins. After the project is created, move to the areas used for team access and administrative control. The **Project Administrator** should add the core team members and confirm each person has the correct level of access before onboarding starts. Use the user and permissions area to separate responsibilities clearly: | Role | Main responsibility | Access to set before work begins | |---|---|---| | Project Administrator | Owns project setup, settings, and release control | Full project settings access | | Documentation Manager | Organizes structure, review flow, and release preparation | Authoring and review access | | Technical Writer | Creates and updates documentation pages | Authoring access | This early setup matters because project settings and release controls should stay with the **Project Administrator**, while page creation and review tasks belong to the writing and documentation leads. If someone cannot see the project workspace, cannot open editing screens, or cannot participate in review, check project membership first. Before moving on, confirm the onboarding basics are complete: - The project appears in the user’s project list - Each team member can enter the workspace assigned to them - Required organization setup has already been completed - User profiles are active enough to sign in and reach the project area [SCREENSHOT: project creation screen showing project name, visibility, and default documentation options] If you need more detail on account access before this point, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) and [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Completing Onboarding and Preparing the Documentation Workspace Once the project exists, continue through the onboarding flow until Atloria shows the workspace in a project-ready state. The **Project Administrator** usually handles the setup choices that affect the whole project, while the **Documentation Manager** takes over the parts that shape the documentation workspace itself. Treat onboarding as the point where you turn an empty project into a usable writing environment. 1. Open the new project and follow the welcome and setup screens in order. 2. Complete the project-level choices first, especially any options related to workspace access, review behavior, and whether the project will eventually support public documentation. 3. Set up the initial documentation structure. This includes the starting page hierarchy, where pages appear in navigation, and any starter content Atloria creates during setup. 4. Review the workspace as a writer would. Make sure the editor opens correctly, draft creation is available, and the default version or branch setting is ready for day-to-day work. 5. Finish any final onboarding confirmations until the project shows as ready for use. The **Documentation Manager** should inspect the navigation area carefully at this stage. If Atloria creates starter pages, decide whether to keep them as placeholders, rename them, or replace them with real content. It is much easier to correct the page tree before writers begin than after review and version work are already underway. Also check the project-level settings that will affect later release work: - Access mode for the project workspace - Review requirements for content approval - Public documentation availability - Any default version behavior used for editing and release preparation [SCREENSHOT: onboarding flow with welcome step, workspace setup, and project-ready confirmation] If your team needs a deeper walkthrough of project setup choices, see [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) and [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). ## Authoring Content and Moving It Through Review With onboarding complete, the **Technical Writer** can begin creating pages in the content editor. Start by opening the documentation area and creating a draft page in the correct section of the navigation tree. As each page is created, fill in the page details shown in the editor, including the page title and any page metadata available on the editing screen. Then place the page in the right location in navigation so readers will find it in the expected order. 1. Open the documentation workspace and create a new draft page. 2. Enter the page title and complete any page details shown in the editor. 3. Write or paste the page content, then save the draft regularly while working. 4. Update the navigation tree so the page appears in the correct section. 5. When the content is ready, change its status or otherwise mark it ready for review. 6. Notify the **Documentation Manager** that the page is ready for review. The **Technical Writer** is responsible for clear instructions, accurate page content, and keeping the navigation structure aligned with the subject matter. The **Documentation Manager** is responsible for structural consistency across the project, checking that pages follow the expected organization, and deciding whether content is ready to move toward release. If reviewers leave comments or request changes, the writer returns to the draft, updates the page, saves the revision, and sends it back through review. A healthy review cycle usually looks like this: - Writer creates and saves draft content - Writer marks the page ready for review - Documentation Manager reviews wording, structure, and completeness - Feedback is returned for revision if needed - Writer updates the draft and resubmits it - Documentation Manager gives final approval when the page is release-ready [SCREENSHOT: content editor with draft page, page details, and navigation tree] For more detail on page editing and review workflows, use [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) and [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions). ## Generating a Version and Preparing the Release Candidate After the required pages have been reviewed and approved, the next step is to generate a documentation version that captures the approved state of the project. This is typically coordinated by the **Documentation Manager**, because version generation should reflect what is actually ready for release, not whatever writers are still editing in drafts. 1. Open the project area used for documentation versions. 2. Start a new version generation action. 3. Select the source content set that should be included in the release candidate. 4. Enter the release version name using your team’s naming standard. 5. Run the generation process and wait for the new version to appear in the version list. 6. Open the generated version and review its contents before handing it off for access checks. The generated version should include the approved page content, the navigation structure tied to that content, and the version-specific details Atloria stores with that release. This is the point where the **Documentation Manager** must be careful: if the wrong source is selected, the version may miss approved updates or include material that was still in progress. Compare the generated version against the latest approved pages rather than against active drafts in the editor. A simple handoff works well here: - **Technical Writer** confirms page work is complete and no required edits are still pending - **Documentation Manager** generates the version and validates that it matches approved content - **Project Administrator** reviews the release candidate only after the version is confirmed accurate [SCREENSHOT: version generation screen with source selection and version name] If your team manages multiple release cycles, [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Generating New Documentation Versions](doc:generating-new-documentation-versions) go deeper into version naming, comparisons, and release preparation. ## Validating Access and Releasing the Documentation Publicly Before publishing anything publicly, review the access settings attached to the generated version and the project itself. In Atloria, a version can only be shared correctly when the version visibility and the project’s publication controls support the same release goal. If the project is meant for public readers, confirm that the version is not still limited to internal-only access. 1. Open the generated version and review its visibility settings. 2. Check the project-level publication controls to confirm public documentation is allowed. 3. Open the published output or preview as a reader would see it. 4. Click through the navigation, open key pages, and verify the version selector behaves as expected. 5. Confirm that internal-only material is not visible in the public view. 6. When everything looks correct, complete the final publish action. The **Project Administrator** should perform the final release action because this step affects what outside readers can access. The **Documentation Manager** should assist by checking page order, navigation links, and whether the correct version is being shown. During verification, test the public experience like a real visitor: - Open the landing page and confirm it loads without elevated access - Check that expected pages appear in navigation - Open several pages to confirm content is available - Verify the selected version matches the intended release - Make sure restricted pages do not appear publicly [SCREENSHOT: published documentation view with navigation and version selector] If you need more detail on release visibility and audience access, see [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options) and [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation). ## Fixing Common Problems Before and After Release Most release issues in Atloria come from access setup, review permissions, or choosing the wrong source when generating a version. When something looks wrong, work backward from what the user can actually see: missing project access, missing approved pages, blocked review actions, or public pages that do not match the intended visibility. - **Project members cannot complete onboarding or enter the documentation workspace** Check that they were added to the project and given the correct role. If the project appears in the administrator’s workspace but not for writers or reviewers, the issue is usually incomplete project membership or missing permissions. Also confirm the user can sign in normally and reach the main Atloria workspace before troubleshooting the project itself. - **Approved content is missing from the generated version** Open the version details and compare the release candidate against the approved pages in the documentation workspace. If the version was generated from the wrong source state, it may exclude recent approved updates. Regenerate the version using the correct approved content set, then recheck the navigation and page list. - **Review cannot be completed** If writers cannot mark content ready, or managers cannot approve pages, review the assigned permissions for those users. The **Technical Writer** needs authoring access, and the **Documentation Manager** needs the ability to review and approve. Without those permissions, the workflow stalls even if the content itself is finished. - **Public visitors see access errors or hidden pages** Compare the project visibility settings with the generated version’s access settings. A public project with an internal-only version will still block readers. The opposite problem can also happen if page availability does not match the intended release setup. [SCREENSHOT: example of project access settings beside version visibility settings] For broader troubleshooting around access and release checks, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) and [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export). ## Overview This workflow in Atloria takes a project from initial setup through onboarding, writing, review, version generation, access validation, and public release. The key to keeping the process smooth is assigning the right work to the right role from the beginning. The **Project Administrator** controls project setup, team membership, settings, and the final public release decision. The **Documentation Manager** shapes the workspace, manages review flow, validates generated versions, and prepares the release candidate. The **Technical Writer** creates and revises the documentation pages that will eventually appear in the published site. Across the workflow, the main screens you will use are the project creation screen, the onboarding flow, the documentation editor, the navigation tree, the version area, and the published documentation view. Each stage depends on the previous one being complete. If onboarding is unfinished, writers may not have a usable workspace. If review permissions are missing, approved content never reaches release readiness. If the wrong source is selected during version generation, the published output will not match the team’s approved work. This guide focuses on the full project path rather than a single feature. Use it when you need to coordinate multiple people and move from an empty project to a public documentation release with clear checkpoints. For related admin-only areas such as **Analytics & Insights** or **Security & Audit**, note that those screens may be present in the admin workspace but are separate from the core project publishing flow described here. [SCREENSHOT: project workflow view showing setup, authoring, versioning, and published output] ## Prerequisites Before you run this workflow in Atloria, make sure the team can already access the account and workspace areas needed for project work. You do not need every advanced feature enabled, but you do need the basics in place so setup, review, and release actions are available to the right people. Use this checklist before starting: - An Atloria account that can sign in successfully - Access to the main authenticated workspace - Permission to create or manage a project - A defined **Project Administrator** - A defined **Documentation Manager** - At least one **Technical Writer** - Organization setup completed if your Atloria workspace requires it - Project membership assigned for everyone who will write, review, or release content It also helps to agree on a few working decisions before the first page is created: | Decision to confirm | Why it matters | |---|---| | Project visibility | Affects who can access the workspace and later public release options | | Review ownership | Prevents confusion about who approves content | | Version naming approach | Keeps release candidates easy to identify | | Public release intent | Helps you choose the right publishing and access settings | If your team is still at the account access stage, start with [Understanding Account Entry Points and Session Navigation](doc:understanding-account-entry-points-and-session-navigation). If project setup is not complete yet, pair this guide with [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding). The next step in this workflow is [Moving Document Updates into Versioned Releases](doc:moving-document-updates-into-versioned-releases). ## Opening the code parsing workspace and understanding what it accepts In Atloria, the code parsing workspace is the place where you prepare source code before turning it into technical documentation. If you already know how parsed results support writing work, use this page alongside [Using Code Parsing Results to Improve Technical Documentation](doc:using-code-parsing-results-to-improve-technical-documentation). This guide stays focused on the workspace itself: what you can load, what the screen is waiting for, and how to tell when you are ready to run parsing. When you open the code parsing workspace, look for four main areas: - an upload area for adding source files - a code snippet area for pasting a smaller block of code - a parse action that starts the workflow - a results area where Atloria shows the parsed output after the run finishes [SCREENSHOT: code parsing workspace showing file upload area, snippet editor, parse action, and results panel] Atloria accepts two main input types in this workspace: - **Uploaded files** when you want Atloria to read code from saved source files - **Pasted snippets** when you only need to analyze a focused section of code Before you start, prepare code that gives Atloria enough context to recognize structure clearly. Full source files are usually best when you want broader coverage. Focused excerpts work well when you only need one part of the code, but those excerpts should still be complete enough to stand on their own. You will usually move through a few simple workspace states before parsing begins: - **Empty workspace**: no file or snippet has been added yet - **Loaded input**: a file appears in the upload area, or the snippet box contains code - **Ready to parse**: the workspace has valid input and is ready for the parse action If the workspace is still empty, Atloria has nothing to process. Once your file or snippet is visible on the screen, you can move on to preparing it for a clean parsing run. ## Preparing files and snippets for successful parsing Good parsing starts before you click the parse action. In Atloria, the quality of the file or snippet you load has a direct effect on how useful the results will be in later documentation work. If you need help reviewing parsed coverage after a run, see [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage). Choose your input method based on what you want to document: 1. Use **file upload** when you want broader structure from a complete source file, such as all major code elements in one screen. 2. Use the **snippet area** when you want to isolate one specific section without bringing in unrelated code. 3. Keep each input focused on a single documentation target whenever possible. For the best results, make sure the code you provide is complete enough to be understood as a whole. In practice, that means: - include the full declaration rather than only a few lines from the middle - keep the original indentation and formatting - avoid cutting off the beginning or end of the code block - include nearby supporting lines when they are necessary to understand the main section Partial fragments often lead to output that is too thin or confusing to reuse. For example, a short excerpt taken from the middle of a larger file may leave Atloria without enough context to identify the structure you actually want documented. It also helps to separate unrelated code before loading it into the workspace. If one file or snippet mixes several different topics, the results area may be harder to review and reuse. Smaller, clearly grouped inputs are easier to trace back to their source and easier to apply in documentation drafts. Before uploading, quickly review file names and snippet content. Clear naming and clean organization make it much easier to recognize which parsed result belongs to which source, especially when you are comparing multiple runs. ## Uploading files or pasting code into the workspace Once your code is ready, add it to the workspace using the input method that matches your goal. Atloria supports both uploaded files and pasted snippets, so you can work from saved source code or from a smaller excerpt you copied for review. 1. In the code parsing workspace, use the **file upload** control to add one or more source files. 2. If you only need a focused section, click into the **snippet input** area and paste the code directly. 3. Check the workspace before parsing to confirm that the correct input is visible. 4. If you notice a mistake, replace or remove the input before starting the run. When you upload files, Atloria should reflect that change in the workspace by showing the loaded file. When you paste a snippet, the code should remain visible in the snippet area so you can review it before continuing. [SCREENSHOT: workspace with an uploaded file listed and a populated snippet area] Use file upload when your documentation work depends on the full structure of a source file. Use the snippet area when you want to test or document a narrower section without extra surrounding material. In either case, pause and confirm what Atloria is showing on screen. This is the easiest point to catch a wrong file, an incomplete paste, or a code block that includes too much unrelated content. If the wrong content was added, correct it immediately: - remove the current file and upload the right one - clear the snippet area and paste the full code again - replace a partial excerpt with a more complete block - reload the input if the visible content does not match what you intended to parse Do not move straight to parsing just because something is loaded. The workspace should show the exact file or snippet you want Atloria to interpret. A quick review here saves time and reduces unnecessary reruns later. ## Starting a parsing run and following workspace state changes After at least one valid file or snippet is loaded, you can start the parsing workflow. Atloria uses visible workspace states to show where the run stands, so the main thing you need to do is start the run and then watch for the state to change. 1. Confirm that your file or snippet is loaded and that the workspace is ready. 2. Click the parse action to begin the run. 3. Wait while Atloria processes the current input. 4. Review the final state to see whether the run completed successfully or failed. Most runs move through a simple sequence of states: | Workspace state | What it means | |---|---| | Ready | Your file or snippet is loaded and Atloria can start parsing | | Parsing in progress | Atloria is currently processing the input | | Parse completed | The results area is ready for review | | Parse failed | Atloria could not finish the run with the current input | [SCREENSHOT: parsing workspace showing an in-progress state indicator] While parsing is running, avoid changing the current input. Do not replace the file, clear the snippet, or paste a different code block until the current run finishes. If you realize you loaded the wrong content, wait for the current state to resolve first, then update the input and run parsing again. The completed state is your signal that the results area is ready to use. At that point, you can review how Atloria interpreted the code and decide whether the output is suitable for documentation. If the run fails, stay in the same workspace and correct the input before trying again. This state-based flow is especially useful when you are running several focused parsing attempts in a row. By waiting for each run to finish before making changes, you keep each result tied to a clear source input. ## Reviewing parsed output for documentation use When parsing finishes, move to the results area and compare the output with the file or snippet you loaded. Your goal is not just to confirm that Atloria produced a result, but to check whether the result matches the documentation target you had in mind. 1. Open the results area after the workspace shows **Parse completed**. 2. Compare the parsed output with the original file or snippet. 3. Check whether the output reflects the code elements you expected to document. 4. Decide whether to keep the result or rerun parsing with a better input. [SCREENSHOT: parsed results area showing structured output beside the original input] As you review the output, look for whether Atloria captured the intended structure from your source. Depending on what you loaded, that may include major code sections, named elements, grouped logic, or other recognizable parts of the input. The key question is simple: does this result support the documentation page you want to create or improve? Keep the current result when: - the parsed structure clearly matches the source you loaded - the output is focused enough to reuse in technical documentation - the source is easy to identify and trace back later Rerun parsing when: - the output is too broad because the file included unrelated material - the output is too partial because the snippet was cut too tightly - important surrounding context is missing - the result appears tied to the wrong source input If you need more guidance on turning accepted results into documentation work, continue with [Using Code Parsing Results to Support Technical Docs](doc:using-code-parsing-results-to-support-technical-docs). At this stage, the most important habit is keeping each accepted result connected to a clear source file or snippet. That makes later writing, review, and revision much easier. ## Fixing common parsing problems in the workspace Most parsing problems in Atloria come from the input itself rather than from the workspace screen. When a run does not start, produces weak results, or fails completely, the fastest fix is usually to review what you loaded and clean it up before trying again. If parsing does not start, check the workspace first: - make sure a file is actually listed in the upload area, or that code is visible in the snippet input - confirm the workspace is no longer empty - verify that the screen appears ready for parsing before you click the parse action If results are incomplete or inaccurate, the input is often too short or missing surrounding context. Replace a narrow fragment with a more complete code block. Include the full section you want Atloria to interpret, not just a few lines from the middle. Preserve indentation and avoid pasting code that starts or ends abruptly. If the wrong source was parsed, remove the current input and reload the correct one. This is especially important when you are switching between several files or testing multiple snippets in sequence. Always confirm the visible file or pasted content before starting a new run. If a parse run fails, review the source for common issues: - truncated code - malformed formatting - pasted content missing its beginning or ending - unrelated pieces combined into one confusing snippet [SCREENSHOT: workspace showing failed parse state with input still visible for correction] After you clean the input, run parsing again rather than trying to work from a failed or misleading result. If you repeatedly get weak output from the same material, split the source into smaller, more focused files or snippets and test them one at a time. That usually makes the results easier to review and more useful in documentation workflows. ## Overview This page covers the practical side of working in Atloria’s code parsing workspace: loading source material, starting a parsing run, watching the workspace state change, and checking whether the output is ready to support documentation. It is the hands-on companion to the earlier code parsing articles, especially [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace), [Managing Code Parsing Workspace Sessions](doc:managing-code-parsing-workspace-sessions), and [Using Code Parsing Results to Improve Technical Documentation](doc:using-code-parsing-results-to-improve-technical-documentation). The main ideas to carry forward are: - the workspace accepts either uploaded files or pasted snippets - the quality of the input strongly affects the quality of the parsed output - workspace states help you know when Atloria is empty, ready, processing, completed, or failed - parsed results are most useful when each run stays tied to a clear and focused source input This workflow is especially useful when you are preparing technical documentation for a specific page, feature, or reference section. Instead of loading everything at once, you can choose the right input method for the job, confirm what is visible in the workspace, run parsing, and review the result before moving into writing or revision work. If your next step is to apply the output inside a project’s technical documentation area, continue with [Exploring Technical Documentation Inside a Project](doc:exploring-technical-documentation-inside-a-project). If you need to work more deeply with coverage and structure, return to [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage). ## Prerequisites Before you start a parsing run in Atloria, make sure you have the basic materials and access needed to use the workspace effectively. - You can sign in to Atloria and reach your project workspace. If needed, use [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) or [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). - You know which project, documentation task, or reference page the parsing result will support. - You have source material ready in one of these forms: - a complete source file for broader parsing - a focused code snippet for a smaller, targeted run - Your code is clean enough to review before upload or paste: - complete where possible - properly indented - not obviously cut off at the beginning or end - You are prepared to rerun parsing if the first result is too broad, too partial, or tied to the wrong source. It also helps to decide in advance whether you are documenting a broad code area or a single focused section. That choice affects whether you should use the file upload area or the snippet input box. If you have not yet checked whether your language or framework is supported, review [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage) before loading code into the workspace. ## Understanding the technical reference landing page In Atloria, the **technical reference landing page** is the starting point for browsing structured reference content inside a project or in a published documentation view. If you already know how project and public reference views differ, use [Reading API Reference in Project and Public Views](doc:reading-api-reference-in-project-and-public-views) as a companion while you browse. At the top of the page, look for the **page title** and the short **introductory description**. These tell you which reference area you are in and what kind of content is grouped there. This opening text usually summarizes the section instead of showing every detail immediately. Below or beside that heading, Atloria presents the reference content as a set of **section links**, **entity links**, or grouped entries. Depending on the page layout, you may see: - A **left navigation panel** with section names - A main content area with **cards**, **lists**, or linked entry names - Short summary text under each entry - Visual grouping under a shared **section heading** The key thing to notice is the difference between an **overview page** and an **entity detail page**: - An **overview page** groups several related entries together - An **entity detail page** focuses on one specific entry Before opening an entry, you can usually identify: - The **entity name** - A brief **description** - Its place inside a broader **reference section** That preview helps you decide whether you only need to scan the section or open the full page. When you click into a dedicated entry, the **page heading** changes to that specific item, and the browser address also changes to reflect the new page. [SCREENSHOT: technical reference landing page showing page title, intro text, left navigation, and linked reference entries] ## Moving between reference sections When you want to switch from one part of the technical reference to another, use the navigation elements that stay visible around the content. In Atloria, this usually means the **left navigation**, a **reference index**, or links inside the page itself. The **left navigation** is the easiest place to start. It shows the larger reference structure and helps you move from broad topics to narrower ones. As you browse, pay attention to: - **Top-level section names** for major reference areas - **Nested items** under a section for more specific topics - The **highlighted or active item**, which shows where you are now - Expanded groups that reveal the current section’s child pages If the page includes **in-page section links**, you can use those to jump within the current section without leaving the page. This is useful when a section overview is long and contains several grouped areas. Some reference areas also include a **top-level index**. Use it when you want to step back and choose a different section entirely rather than moving one page at a time. This is especially helpful if you opened a detail page directly and want to reorient yourself. To move back up the hierarchy, check for **breadcrumbs** near the top of the page. Breadcrumbs let you return from a narrow subsection to the broader section that contains it. Parent links are useful when you know the current page is correct, but you want to see the larger group around it again. A good habit is to confirm your location before clicking further. Match these three things together: - The **active navigation item** - The **page title** - The **breadcrumb trail** When all three agree, you can move between sections without losing your place. ## Opening an entity detail page from an overview From a section overview page in Atloria, open a dedicated reference entry by selecting the linked **entity name** in a list, table, or card layout. The overview page is meant for scanning, so it usually shows only a short summary for each entry rather than the full reference. After you click an entry, confirm that the correct detail page has opened by checking a few visible cues: - The **page heading** now shows the specific entity name - The browser address changes to a more specific page - The page displays an **entity-specific summary** or metadata area - The surrounding navigation highlights the current entry or its parent section This matters because overview pages and detail pages serve different purposes. On the **overview page**, you typically see: - A grouped list of related entries - Short descriptions - Section-level context On the **detail page**, you are more likely to find the complete information for that one entry, such as: - Full definitions - Properties or members - Related items - Links to connected entries - Examples or structured subsections, if available If the page still looks like a list of multiple entries, you are probably still on the overview page. If the page focuses on one named item, you are on the dedicated detail page. To return without losing context, use whichever option is most visible: - The browser **Back** button - The **breadcrumb** link to the parent section - A **parent section** link on the page - The **left navigation** item for the overview [SCREENSHOT: overview page with one linked entity selected, followed by the entity detail page with updated title and breadcrumb] ## Reading relationships between overview pages and detailed entries The easiest way to understand technical reference browsing in Atloria is to think of it as a simple hierarchy: - A **technical reference section** - An **overview page** inside that section - One or more **entity detail pages** linked from the overview The **section** gives you the broad topic. The **overview page** acts like a directory for related entries. The **detail page** gives the full reference for one specific item. This structure helps you read efficiently. Stay on the **overview page** when you want to: - Scan what is available in a section - Compare several entries quickly - Find the right name before opening a full page - Understand how entries are grouped Open the **detail page** when you need exact information, such as: - A precise definition - A complete list of properties or members - Relationship details - Entry-specific examples - Links to closely related entries Overview pages are not meant to replace detail pages. They help you narrow your search. If you need complete reference information, click through to the dedicated entry instead of relying on the summary text. You may also see **cross-links** between related entries. These links let you move directly from one detail page to another connected page without returning to the section overview first. That is useful when you are tracing how two entries relate to each other inside the same reference area. To stay oriented while following those links, keep checking: - The **breadcrumb trail** - The **page title** - The **section label** in navigation If you need a refresher on how individual reference entries are structured, see [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation). ## Using page elements to stay oriented while browsing Atloria gives you several on-screen cues that help you keep track of where you are while moving through technical reference content. Use these cues together instead of relying on only one. Start with the **breadcrumbs** near the top of the page. Breadcrumbs show the path from the broader reference area to the page you are currently reading. They are especially helpful after following several related links. Pair that with the **page title**, which confirms the current section or entity, and the **section label** shown in navigation. The **left navigation** provides another important clue. Watch for: - Which section is **expanded** - Which item is **highlighted** - Whether the current page appears under a broader parent group An expanded navigation tree tells you which section contains the page you are viewing. If you open a detail page and the parent group remains open, that is a quick sign that you are still in the same reference branch. On longer entity pages, Atloria may show **in-page anchors** or a **table of contents**. Use these links to jump directly to parts of the page instead of scrolling through everything. Depending on the page, these links may point to areas such as: - Definitions - Members or properties - Relationships - Examples You may also notice **related links**, **previous** or **next** links, or a **parent reference** link. Treat these as navigation aids. They help you move through connected content, but they do not mean you have left the technical reference area. When the page starts to feel unfamiliar, pause and compare: - The **breadcrumb path** - The **current page heading** - The **active item in the side navigation** Those three elements usually tell you exactly where you are. ## Fixing common navigation problems in the reference If a reference link opens a page you did not expect, first check the visible page markers instead of guessing. In Atloria, compare these items right away: - The **section heading** - The **breadcrumb trail** - The **page title** If the page title names a different entry than the one you meant to open, you likely followed a related link or selected a similarly named item from another section. The breadcrumb trail will usually reveal that immediately. When you lose your place in the hierarchy, use the fastest route back to a familiar point: - Click a **breadcrumb** to return to the parent section - Reopen the correct branch in the **left navigation** - Go back to the **technical reference index** or section landing page If an overview page does not show enough detail, that is usually expected. Overview pages summarize entries; they do not replace the full reference page. Open the linked entity entry to see the complete information for that item. Similarly named entries can be confusing. To confirm whether two entries are actually different, compare: - Their **parent section** - Their **page heading** - Any visible **metadata** or summary block on the page Two entries may share a similar name but belong to different parts of the reference. The parent section is often the quickest way to tell them apart. If you have been moving through project and public views and are unsure whether the layout change is affecting what you see, revisit [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views). A practical recovery pattern is: - Return to the **parent section** - Reconfirm the **active navigation item** - Open the entity again from the correct overview page That usually gets you back on track without restarting your search. ## Overview When you browse technical reference content in Atloria, the main goal is to understand how **section pages**, **overview pages**, and **entity detail pages** fit together. The landing page or section page gives you the broad category. The overview page helps you scan related entries. The detail page gives you the full information for one specific item. Keep these browsing patterns in mind: - Use the **page title** and **introductory description** to understand the current reference area - Use the **left navigation** and **breadcrumbs** to move between broader and narrower pages - Open a linked **entity name** when you need more than the short summary shown on an overview page - Check the **page heading** and browser address after opening a detail page to confirm you are in the right place - Use **related links** and **parent links** to move through connected entries without losing the larger context The most useful distinction is simple: - **Overview pages** are for scanning and choosing - **Detail pages** are for exact reference reading If you are still building confidence with the overall reference layout, it helps to pair this guide with [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects) and [Reading API Reference in Project and Public Views](doc:reading-api-reference-in-project-and-public-views). Those guides explain where these pages appear and how the browsing experience changes depending on where you opened the documentation. Once you are comfortable moving between section overviews and entity pages, continue with [Using Technical Reference Pages During Documentation Work](doc:using-technical-reference-pages-during-documentation-work). ## Prerequisites Before this browsing flow makes sense, you should already be comfortable opening technical documentation in Atloria and recognizing the difference between project-based and published reading views. You do not need advanced setup or admin access for this topic, but you should know how to reach a technical reference area and move around basic documentation navigation. You are ready for this guide if you can already do the following: - Open a project’s documentation workspace or a published documentation view - Recognize the **left navigation**, **page title**, and **breadcrumb trail** - Open an API or technical reference section from the documentation menu - Read a linked reference entry without confusing it with regular document pages It also helps if you already understand the basics covered in these related guides: - [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages) - [Exploring API Reference Sections Inside Projects](doc:exploring-api-reference-sections-inside-projects) - [Viewing Technical Entities and Related Reference Details](doc:viewing-technical-entities-and-related-reference-details) If you have not worked with project and public reference views yet, review [Reading API Reference in Project and Public Views](doc:reading-api-reference-in-project-and-public-views) first. This guide assumes you already know how to enter those views and want to focus specifically on browsing within the reference hierarchy. You do **not** need to use Atloria’s admin screens, analytics area, or security pages for this task. The only things you need are access to documentation that includes technical reference content and enough familiarity with Atloria’s navigation to move between sections, overview pages, and detailed entries. ## Opening the project webhook settings page Before you start, make sure you have **Project Administrator** access for the project you want to review. In Atloria, webhook settings are managed at the project level, so you need permission to open the project’s **Settings** area and work with its delivery options. 1. Open the target project from your project list or workspace. 2. In the project sidebar, click **Settings**. 3. Inside **Settings**, open the **Webhooks** area. [SCREENSHOT: Project sidebar with Settings selected and Webhooks highlighted] On the **Webhooks** page, look for the main parts of the screen that help you monitor delivery behavior: - A **webhook list** showing the webhooks configured for this project - **Status indicators** that help you spot whether a webhook is active or having delivery problems - A **recent delivery** or **delivery history** area for checking recent attempts - **Action buttons** that let you open details, inspect a delivery, or retry a failed attempt This page is focused on the current project only. Use it to confirm whether this specific project is sending events to the right destinations and whether those deliveries are succeeding. If your team also manages broader admin settings in Atloria, keep in mind that the **project Webhooks** page shows project-scoped webhook behavior rather than organization-wide admin tools. If you need help getting to the right project workspace first, see [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). That guide covers the general project settings area, while this page focuses on checking webhook behavior and delivery results after setup. ## Reviewing configured webhooks and their current behavior Once you are on the **Webhooks** page, start by reading through each webhook entry in the list. The goal is to confirm that every webhook shown belongs in this project and is set up to react to the right project activity. 1. Scan the webhook list and open each entry one at a time. 2. Check the destination shown for that webhook. 3. Confirm whether the webhook is **enabled** or **disabled**. 4. Review the events or triggers attached to that webhook. 5. Open the webhook details to inspect its latest delivery information. [SCREENSHOT: Webhook list showing destination, status, subscribed events, and last delivery result] In the details view, pay attention to the delivery-related information Atloria shows for the webhook. This usually includes the most recent delivery result, the latest response code, and when the last attempt happened. These details help you quickly tell whether the webhook is healthy or whether it has stopped receiving useful traffic. Compare what you see with the way your project actually works. For example, if your team expects notifications when documentation changes, version activity happens, or other project events occur, the webhook should be subscribed to those matching events. If the event list does not match the workflow your team depends on, the webhook may appear healthy while still missing the updates you expect. You can often spot problems without opening every delivery record. Common warning signs include: - A webhook that is **disabled** when it should be active - Repeated failed results in the latest delivery information - A **last delivery** time that is much older than expected - A response code pattern that suggests the receiving service is rejecting requests If the webhook setup itself needs broader review, refer back to [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). Use this page to verify behavior, not to repeat the original setup process. ## Checking delivery controls and recent delivery activity After confirming the webhook list looks correct, open an individual webhook and move to its delivery activity area. This is where you check whether Atloria is actually sending events and whether the receiving destination is responding successfully. 1. Click a webhook in the **Webhooks** list. 2. Open the section that shows **recent deliveries** or **delivery history**. 3. Review the most recent entries in order. 4. Open a specific delivery record to inspect its details. 5. Use any available retry or redelivery action if you need to test again after a fix. [SCREENSHOT: Webhook detail view with recent deliveries list and a selected delivery record] The recent deliveries area helps you answer a simple question: did a project action produce a webhook attempt? If your team recently changed documentation, updated project content, or performed another subscribed action, you should see a matching delivery entry appear soon after. Open individual delivery records to inspect the details Atloria shows for each attempt. Focus on the fields that are easiest to compare across attempts: | Field | What to check | |---|---| | Status | Whether the delivery succeeded or failed | | Response code | Whether the destination accepted the request | | Delivery time | When Atloria sent the event | | Error message | Any message returned when the attempt failed | If Atloria offers a **Retry**, **Redeliver**, or similar action, use it after the receiving destination has been corrected. This is especially useful when the original failure was caused by a temporary issue. A successful retry tells you the webhook setup is likely correct and that the problem was with the destination’s availability or response at the time of the first attempt. When several recent entries show the same failure pattern, treat that as a sign of an ongoing issue rather than a one-time interruption. ## Confirming that webhook deliveries are working as expected The best way to confirm a webhook is working is to trigger a project action you can recognize easily, then check whether a new delivery appears in the webhook’s history. 1. Perform a known action in the project that should trigger the webhook. 2. Return to **Settings** > **Webhooks**. 3. Open the relevant webhook. 4. Refresh or review the **recent deliveries** list. 5. Match the new delivery entry to the action you just performed. [SCREENSHOT: Recent deliveries list with a newly added event highlighted] When you inspect the new entry, compare the **timestamp** and **event type** with the action you just completed. The timing should line up closely enough that you can confidently say the new record came from your test. This is the quickest way to verify that Atloria is not only configured to send events, but is also sending the right event at the right time. Look for success indicators in the delivery record. In most cases, a successful delivery will show a delivered or successful status and a response code in the **2xx** range. If you see that result after your test action, the webhook is behaving as expected for that event. Do not rely on a single successful attempt if you are investigating a recurring problem. Repeat the check with more than one event so you can tell the difference between: - a one-off failure, - a temporary destination outage, or - a persistent configuration problem. If one event succeeds but another expected event never appears, the issue may be with the webhook’s event selection rather than the destination itself. If every test event fails in the same way, focus on the destination response shown in the delivery details. This verification step works especially well after changes made in earlier project setup work, including the delivery options covered in [Configuring Project Identity and Delivery Options](doc:configuring-project-identity-and-delivery-options). ## Using delivery details to diagnose operational problems When a webhook is not behaving correctly, the delivery details view gives you the clearest picture of what is going wrong. Instead of guessing, use the fields shown in Atloria to narrow the issue down. 1. Open the affected webhook from **Settings** > **Webhooks**. 2. Select a failed or suspicious delivery entry. 3. Read the status, response code, attempt time, and any response message. 4. Compare that delivery with earlier and later attempts. 5. Note the exact pattern before you escalate the issue. [SCREENSHOT: Failed delivery detail showing status, response code, attempt time, and response message] These fields help you separate different kinds of problems: - **Status** tells you whether Atloria considers the delivery successful or failed. - **Response code** helps you see whether the destination accepted the request or rejected it. - **Attempt time** helps you match the failure to a real project action. - **Endpoint response message** can reveal whether the destination returned a useful explanation. Use the webhook’s overall state together with the delivery history. For example: - If the webhook is **disabled**, missing deliveries may be expected. - If the webhook is enabled but there are **no recent deliveries**, the triggering event may not have happened or the webhook may not be subscribed to that event. - If deliveries appear but each one includes an error response, the destination is likely receiving the request and rejecting it. The sequence of attempts matters. A single failed record surrounded by successful ones usually points to a temporary interruption. A repeating pattern across every recent event suggests a persistent problem. Intermittent success and failure often means the destination is unstable or only failing under certain conditions. Before you hand the issue to the team that manages the receiving destination, record the exact webhook entry, the failing event, the delivery time, and the response details shown on screen. That gives them something specific to investigate. ## Fixing common webhook and delivery check issues Most webhook problems in Atloria fall into a small number of patterns. Use the **Webhooks** page to confirm which pattern you are seeing before making changes or asking another team to investigate. 1. Open the affected webhook in **Settings** > **Webhooks**. 2. Review its enabled state, subscribed events, and recent deliveries. 3. Compare the latest delivery details with the project action you expected to trigger it. 4. Retry delivery only after you have corrected the likely cause. 5. Recheck the delivery history to confirm whether the issue is resolved. Here are the most common situations and what to verify: - **No recent deliveries appear** - Confirm the webhook is **enabled**. - Make sure a subscribed project event actually happened. - Check whether you are looking at the correct webhook for that event. - **Deliveries keep failing** - Open the latest failed delivery. - Review the response code and any error message. - Correct the destination issue, then use **Retry** or **Redeliver** if Atloria shows that option. - **An expected event is missing from history** - Compare the webhook’s event subscriptions with the action you performed. - If the action does not match the selected events, Atloria will not create a delivery for it. - **Delivery checks are unclear** - Run more than one test event. - Compare timestamps across the recent deliveries list. - Look for a pattern: always failing, sometimes failing, or not appearing at all. [SCREENSHOT: Webhook detail page with failed delivery selected and retry action visible] If the webhook configuration itself seems incomplete, revisit [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). If the project settings page shows the webhook is configured correctly but the destination keeps rejecting deliveries, share the exact delivery details with the team responsible for that receiving endpoint. ## Overview This page in Atloria is where you verify that project webhooks are not only configured, but also actively delivering project events to the correct destination. The **Webhooks** area inside project **Settings** helps you review each configured webhook, inspect recent delivery attempts, and determine whether delivery failures are isolated or ongoing. Use this page when you need to answer questions like: - Is the webhook enabled for this project? - Is it listening for the right project events? - Did a recent project action create a delivery attempt? - Did the destination accept or reject that delivery? - Can the failed delivery be retried after the destination issue is fixed? The most useful parts of the screen are the webhook list, the detail view for each webhook, and the recent delivery history. Together, these let you compare expected project activity with actual delivery records. If your team recently updated webhook setup, changed project delivery behavior, or connected a new receiving destination, this page is the fastest place to confirm the result. This guide focuses on monitoring and troubleshooting from the project’s **Webhooks** settings page. It does not repeat the broader setup steps already covered in [Configuring Project Identity and Delivery Options](doc:configuring-project-identity-and-delivery-options) and [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). Instead, it shows how to read the delivery information Atloria presents and how to use that information to verify successful behavior or diagnose failures. If you are responsible for release readiness or operational checks, reviewing webhook delivery history here can help you catch missing notifications, repeated delivery failures, or event subscription mismatches before they affect downstream workflows. ## Prerequisites Before working through delivery checks in Atloria, make sure the following are true: - You can open the target project and access its **Settings** area. - You have **Project Administrator** access for that project. - At least one webhook has already been configured on the project’s **Webhooks** page. - You know which project action should trigger the webhook you want to test. - You can identify the correct webhook entry by its destination and subscribed events. It also helps to have a recent project action available for testing. For example, if you are checking whether a webhook reacts to a specific project event, you should be ready to perform that action and then return to the **recent deliveries** list to confirm a new entry appears. Before starting, gather these details from the webhook entry you plan to review: | Item to confirm | Why it matters | |---|---| | Enabled or disabled state | Disabled webhooks will not send deliveries | | Subscribed events | The webhook only sends deliveries for selected project activity | | Last delivery result | Helps you see whether the webhook has been working recently | | Latest timestamp | Shows whether delivery activity is current or stale | If you have not yet reviewed the project settings area itself, start with [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). If you need to revisit how project webhook options were originally configured, use [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). After you have confirmed webhook delivery behavior, the next step in the Project Settings sequence is [Planning Project Structure and Content Governance](doc:planning-project-structure-and-content-governance). ## Understanding how editor changes become part of a release In Atloria, editing a page and releasing that page are two separate parts of the workflow. A change you make in the document editor is only a draft update until it is reviewed and attached to a versioned release. That separation matters when your team needs to control what readers can see, compare release candidates, or hold updates for approval before they go live. An in-progress change starts in the document editor, where you update the page content, structure, or page details and then save. At that point, the update belongs to the working draft of the document, not to a released version. To move it forward, you use the document’s version history or revision view to find the saved update and compare it with the currently released content. From there, you use the available review or approval controls to mark the update as ready for release work. Once the change has been reviewed, you add it to a version entry or release record. This is the point where Atloria starts treating the page update as part of a specific release candidate rather than just a saved draft. In practice, that means you will usually move between four areas: - The **document editor** to make and save the change - The **version history** or comparison view to confirm what changed - The **review or approval controls** to move the update out of draft work - The **release management** area to include the reviewed page in a versioned release Use a versioned release when you want readers to see a controlled set of updates together. If you are already following a full project release flow, keep using the process described in [Running a Project from Setup to Public Documentation Release](doc:running-a-project-from-setup-to-public-documentation-release). This guide focuses on the document-level path from saved edit to release-ready version. [SCREENSHOT: document editor beside version history and release list in Atloria] ## Preparing the document change in the editor 1. Open the project in Atloria and go to the document you want to update. Before you edit anything, check the page title and confirm you are on the correct document. If your team manages similar pages across versions, this quick check helps prevent updating the wrong page. 2. Make your content changes in the editor. Update the text, headings, page sections, or other visible content on the page. As you work, pay attention to the page layout and any fields that affect how the page appears in navigation or release views. If the editor shows a current draft state, keep working there until the page reflects the exact update you want to send forward. 3. Save the page. In Atloria, saving is what turns your work into a recorded draft or pending revision. If you leave the page without saving, the release workflow cannot pick up the latest changes. After saving, stay on the page long enough to confirm the save completed and that the latest draft is now the current working version. 4. Use the preview or compare view if it is available from the page. This is the best place to verify the exact wording, structure, and page flow before review. Compare the newly saved draft against the current released version and look for unintended edits such as missing headings, moved sections, or outdated wording that should not be part of the release. A careful editor check at this stage saves time later. Before you leave the page, confirm: - The correct document is open - The new content is saved - The draft reflects the intended change - The preview or compare view matches what you expect readers to see in the next release [SCREENSHOT: document editor with saved draft and preview or compare option] ## Reviewing and versioning the updated document 1. Open the document’s **version history**, **revision history**, or similar change-tracking area. Find the most recent saved update you just created. Look for the latest entry by its position in the list and confirm it matches the page you edited. 2. Compare that latest revision with the current released version. This step is where you confirm that the release candidate includes the right text, page structure, and any page-level details that changed. If Atloria shows side-by-side comparison or a revision view, use it to verify what was added, removed, or updated. 3. Move the revision into the review process using the available action on the page, such as a review, approval, or status-change control. The exact button label may vary by workspace, but the goal is the same: change the document from a saved draft into a reviewed item that can be included in a release. If your team uses approval decisions, make sure the revision reaches the required status before you continue. 4. Assign the reviewed revision to a version entry or release candidate. This links the document update to a named version instead of leaving it as a standalone draft change. Once attached to a version, the update becomes part of a trackable release package that can be reviewed alongside other documentation changes. Use this stage to answer one question clearly: “Is this the exact revision we want in the release?” If the answer is not clear, go back to the comparison view before assigning it to a version. For broader guidance on version lists and review states, see [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions). [SCREENSHOT: revision history with latest document update selected and compared to current release] ## Adding the reviewed change to a versioned release 1. Go to the release or version area for your project. Open an existing release if the document update belongs in a release already in progress, or create a new release record if this change starts a new release candidate. Choose the release that matches your team’s timing and scope. 2. In the selected release, open the section that lists included content. Depending on your workspace, this may appear as release contents, included documents, or a version selection area. Add the reviewed document version from the available list, making sure you choose the reviewed revision rather than an older saved draft. 3. Check the release details before you move on. The release record may include fields such as version name, release notes, access settings, and publication scope. Review those details carefully because they determine how this document update will be grouped, labeled, and shared. | Release detail | What to check | |---|---| | **Version name** | Matches your team’s naming for this release | | **Release notes** | Describes the document update clearly if notes are used | | **Access settings** | Reflects who should be able to view the release | | **Publication scope** | Confirms whether the release is internal, staged, or intended for publication | 4. Confirm the document now appears in the release contents with the correct status. The release should show the page as included, and the included revision should match the reviewed version you selected earlier. If the release view shows status information, make sure it reflects the expected review state before you treat the release as ready. This is the point where a page stops being “just updated in the editor” and becomes part of a managed release. If you need more detail on release visibility and export-related controls, see [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options). [SCREENSHOT: release details screen showing included documents and version information] ## Checking access and publication readiness for the release 1. Open the release record and review its access settings. In Atloria, a release can be prepared before it is broadly available, so confirm who can view it at this stage. If the release is meant for internal review only, keep it restricted. If it is intended for a wider audience, make sure the visibility settings match that goal. 2. Verify that three things line up: the document’s approval status, the release membership, and the selected document version. A release can look complete while still pointing to the wrong revision or holding an item that has not reached the required review state. Check each included document entry carefully. 3. Use preview or staged access options to see the release the way readers will see it. This is the safest way to confirm that Atloria is showing the released version of the page rather than the editor draft. Read through the updated page in the release preview and confirm the title, body content, and page structure all match the approved revision. 4. Decide whether the release should remain restricted or move to a published state. Keep it restricted when the release is still under internal review, waiting for sign-off, or being checked by a limited audience. Promote it only when the included documents, access settings, and release details are all final. A release is publication-ready when: - The correct reviewed revision is included - The release shows the expected version name and notes - Access settings match the intended audience - Preview shows the released page correctly - The release state matches your team’s decision to keep it staged or publish it For a deeper look at reader access and validation before sharing, use [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export). [SCREENSHOT: release preview with access settings and publication state visible] ## Fixing problems when a document update does not appear in the release If the latest editor change is missing from the release, start with the document editor. Open the page and confirm the update was actually saved. A change that was typed into the editor but never saved will not appear in version history and cannot be added to a release. After saving, return to the document’s revision list and check whether a new entry now appears. If the wrong content appears in the release, compare the revision attached to the release against the latest saved revision in version history. In many cases, the release is still pointing to an older reviewed revision. Open the release contents, select the included document, and verify that the chosen revision matches the exact text and structure you intended to release. If Atloria does not let you add the document to the release, check the review or approval status first. Some release workflows only allow reviewed or approved items to be included. Go back to the document’s review controls and make sure the page has moved out of draft or pending work and into the required status. If users cannot access the updated document after the release has been created, inspect the release access settings and publication state. The release may exist, but still be restricted to internal viewers or held in a staged state. Also confirm that readers are opening the release view or published version, not the editor draft. Use this quick troubleshooting map: - **Missing update in release**: save the page, then confirm a new revision exists - **Wrong page content in release**: compare the included revision with version history - **Cannot add page to release**: check review or approval status - **Readers cannot see update**: review access settings, visibility, and publication state When release problems affect multiple documents, compare your steps with [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) and [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness). [SCREENSHOT: release contents showing selected revision and access status] ## Overview This workflow in Atloria is about moving a single document update through the controlled release path rather than treating a saved edit as immediately publishable. You begin in the document editor, where you update a page and save it as a draft or pending revision. From there, you use version history to confirm the exact change, move the revision through review or approval, and attach that reviewed revision to a versioned release. The key idea is that Atloria separates editing from release management. A saved draft is useful for ongoing work, but it is not the same as a reviewed release candidate. The release record is where you group approved document changes, apply release details such as version name and notes, and decide who can see the result. That makes versioned releases especially useful when your team needs to coordinate several page updates, limit access before publication, or validate a release before readers see it. This guide fits after the broader project release flow in [Running a Project from Setup to Public Documentation Release](doc:running-a-project-from-setup-to-public-documentation-release). Instead of repeating project setup or public publishing basics, it focuses on the document-level handoff between editor work and release control. You will work across these Atloria areas: - **Document editor** for page updates - **Version history** for revision checks and comparison - **Review or approval controls** for status changes - **Release management** for versioned release membership and access settings The next step in this sequence is [Using Analytics Audit and Exports in Release Operations](doc:using-analytics-audit-and-exports-in-release-operations), where you will use tracking and export tools to support release decisions and recordkeeping. ## Prerequisites Before you move a document update into a versioned release in Atloria, make sure the basic release workflow is already in place for your project. You do not need to repeat project setup here, but you should be working inside a project that already has documents, versioning activity, and a release process your team is using. You should have access to the parts of Atloria involved in this guide: - A project workspace with at least one editable document - The **document editor** - The document’s **version history** or revision view - The available **review** or **approval** controls for that document - The project’s **release** or **version** area It also helps if you have already completed the broader release walkthrough in [Running a Project from Setup to Public Documentation Release](doc:running-a-project-from-setup-to-public-documentation-release). That guide covers the full project path, while this one focuses on moving a specific page update into a controlled release. Before you start, confirm these working conditions: - You know which document page needs to be updated - You know which release the change should belong to, or whether you need to create a new one - Your team’s review expectations are clear, especially if a page must be approved before release inclusion - You can open the release preview or staged view to verify what readers will see If you are unsure whether you have the right access for release and approval tasks, check the related admin guidance in [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) or [Using the Admin Workspace](doc:using-the-admin-workspace). ## Opening the project performance view To review documentation performance across projects in **Atloria**, start from the signed-in workspace and open the reporting area available to your role. If you work in the administrative workspace, look for the **Analytics** area from the admin navigation. In some workspaces, project reporting may also be available from a project analytics screen. The key is to open the view that shows **project-level metrics** rather than a single project’s details. When the analytics screen opens, first confirm you are looking at a **Projects** view, a **project grouping**, or a table/chart that lists multiple projects together. If the screen offers a grouping or comparison selector, switch it to **Projects** before you start reviewing results. This keeps your comparison focused on project performance instead of broader totals. Before reading any numbers, check the **date range** control. Set it to the exact reporting period you want to review, such as the current month, quarter, or another period your team uses for reporting. If you compare projects with the wrong date range selected, the results can look inconsistent even when the underlying work is healthy. Next, review any visible filters. Clear **Project**, **Team**, and **Status** filters unless you intentionally want a narrower view. A filtered dashboard is useful for targeted reviews, but it can distort comparison if you forget a filter is still active from an earlier session. Use this quick check before you continue: - Open **Analytics** - Switch to **Projects** or the project comparison view - Set the correct **date range** - Review **Project**, **Team**, and **Status** filters - Confirm the screen is showing multiple projects in the same reporting context [SCREENSHOT: Analytics screen showing a project comparison view with date range and filters highlighted] ## Reading project-level documentation trends Once the project performance view is open, read the screen one project at a time before drawing conclusions across the full list. In Atloria, this usually means scanning a **project table**, **summary cards**, or a **trend chart** that shows how each project is performing during the selected period. Focus on the metrics shown on screen, such as **documentation output**, **completion rate**, **quality score**, or **engagement trend**, depending on what your workspace includes. A single low value does not always mean a project is struggling. The **trend visualization** is often more useful than one isolated number because it shows whether the project is slipping briefly or declining over a longer period. A short dip may reflect a recent release cycle or a temporary pause in content work. A steady downward line across the full date range is a stronger sign that the project needs attention. Sorting helps you review faster. If the project table allows sorting, click the column for the metric that matters most to your review. For example, sort by **completion rate** to bring the weakest projects to the top, or sort by **quality score** to find projects that may need editorial support. Re-sort as needed to look at the same set of projects from different angles. If a project row can be opened, select it to view a **detail panel** or project-specific analytics screen. Compare the **current period** with the **previous period** if that comparison is shown. This helps you tell the difference between a project that has been weak for several periods and one that is already recovering. Useful review habits include: - Scan the full list before focusing on outliers - Sort by one metric at a time - Use trend lines to confirm whether change is temporary or sustained - Open project details when a row looks unusually strong or weak [SCREENSHOT: Project analytics table with sortable columns and a trend chart beside the selected project] ## Comparing outcomes across teams and projects After you understand the project list, shift to team comparison. In Atloria, use the **Team** filter or any **group by** control that separates projects by owning team. This lets you compare projects in the same reporting view without jumping between unrelated screens. If you recently reviewed enterprise and project reporting differences, use that context here rather than repeating setup steps from [Comparing Enterprise and Project Reporting for Documentation Programs](doc:comparing-enterprise-and-project-reporting-for-documentation-programs). When team grouping is active, compare the same metrics across each team’s projects. Look for side-by-side columns or charts that show differences in **output**, **quality**, and **timeliness**. One team may publish a high volume of documentation but show weaker quality results. Another may produce less content but maintain stronger completion or engagement patterns. Reading these measures together gives a more balanced picture than relying on a single score. Sorting is especially helpful inside team views. Change the sort order so the highest- or lowest-performing projects appear first within each team grouping. This makes it easier to spot whether one team has a single problem project or whether several projects are trending in the same direction. If the list is long, compare the top and bottom projects in each team before reviewing the middle. Keep your comparison fair by holding the reporting setup steady. Use the same: - **Date range** - **Status filters** - **Project scope** - **Team selection rules** If one team is shown for the current quarter and another is effectively narrowed by an extra filter, the results will not be comparable. Before presenting findings, glance back at the filter bar and confirm every team is being measured under the same conditions. [SCREENSHOT: Team-grouped project performance view with side-by-side metrics and shared filters visible] ## Finding projects that need support or investment A useful project review does more than identify winners and lagging teams. It helps you decide where to direct support. In Atloria, start by looking for projects with **declining trend lines**, **low completion results**, or weaker outcomes than similar projects in the same team. These are often the first candidates for follow-up. Use the signals visible on the dashboard to flag projects for review. Depending on the screen, this may include low rows in a sorted table, negative period-over-period movement, or visual indicators that show a drop from the previous period. A project with weak results in several areas at once usually deserves more attention than a project with one isolated low metric. To decide what kind of help a project needs, compare **output metrics** against **quality** or **engagement** measures: - If output is low and quality is also low, the project may need broader operational support. - If output is high but quality or engagement is weak, the project may need content improvement rather than more volume. - If quality is strong but output is consistently behind, the team may need workflow support to publish more reliably. - If several projects owned by the same team show the same weakness, the issue may be team-wide rather than project-specific. Open the project’s detail view when possible and compare the current period with the previous one. This helps confirm whether the project is in a temporary slowdown or part of a wider pattern. Also check whether the same team has multiple underperforming projects. Repeated weakness across a team often points to process issues, while one isolated project may need targeted content investment. [SCREENSHOT: Low-performing projects highlighted in a project table with trend changes and team ownership visible] ## Filtering the data to answer specific management questions Broad comparisons are useful, but management reviews often need narrower answers. In Atloria, use the filter controls at the top of the analytics screen to narrow the dashboard to the projects you want to examine. Start with **Project** filters when you need to review a specific portfolio, ownership group, or business area. This is especially helpful when leadership wants to discuss one segment without the noise of unrelated projects. Adjust the **date range** to match the question you are trying to answer. A shorter period can reveal recent changes in output or completion, while a longer period is better for spotting sustained patterns. If your review includes multiple meetings, keep the same date range across each session so your comparisons stay consistent. Use **Status** or activity-based filters when you want to separate active work from projects that are completed or no longer in focus. This prevents archived or inactive projects from lowering averages or cluttering the list. If your workspace includes team ownership filters, combine them carefully so you can answer questions like: - Which active projects are slipping this month? - Which team’s current projects have the weakest completion trend? - Which portfolio shows strong output but weak engagement? - Which projects improved after a recent process change? Some Atloria workspaces may support saved or reusable reporting views. If you see an option to save the current view, use it for recurring leadership reviews so you do not have to rebuild the same filter set each time. If no save option appears, record the filter combination you used and keep it consistent for future reviews. [SCREENSHOT: Analytics filter bar showing project, team, status, and date range selections] ## Resolving misleading comparisons in the dashboard When a comparison looks wrong, check the reporting setup before assuming the projects themselves changed. In Atloria, the most common cause of misleading results is an inconsistent **date range**. If one widget, chart, or table appears out of step with the rest of the screen, confirm the selected period is applied everywhere in the current view. A mismatched period can make one project appear to drop sharply when you are actually looking at different time windows. If a team appears to be missing projects, inspect the active filters first. A leftover **Project**, **Team**, or **Status** filter can remove rows from the comparison without making the issue obvious at a glance. Also review whether the project grouping you selected is showing only a subset of projects rather than the full list. Trend lines can also be misleading when the selected period is too short or does not include enough historical activity. If a chart looks incomplete, widen the **date range** and check again. A longer reporting window often makes the trend easier to interpret and reduces the impact of one unusual week or release cycle. When one project appears unusually strong or weak, open its detail panel instead of relying only on the summary row. Look for signs of a recent content spike, a reporting gap, or a sudden change limited to the current period. This extra check helps you avoid overreacting to outliers. Before sharing your conclusions, run through these checks: - Confirm the same **date range** is used across the view - Review all active **filters** - Check whether the chart includes enough history - Open unusual projects in their **detail view** - Compare outliers against the previous period before escalating For a broader admin perspective on reporting areas, see [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Overview Atloria includes an **Analytics** area in the admin workspace, but the current **Analytics & Insights** screen is presented as a **coming soon** area rather than a fully populated reporting dashboard. You can still use the screen to understand where project-level reporting is intended to live and how it fits into the wider administrative workspace. From the **Admin** area, you can open the card labeled **Analytics**. The card description refers to **usage statistics and insights**, which signals that this is the place to look for cross-project reporting when that view is available in your workspace. The screen header reads **Analytics & Insights**, with supporting text about **usage statistics and performance metrics**. This confirms that the area is meant for reviewing higher-level reporting rather than editing project content. What you can reliably identify on the current screen: - The page title is **Analytics & Insights** - The page sits within the **Admin** workspace - The purpose of the page is **usage statistics and performance metrics** - The current state is a **coming soon** notice rather than a detailed report Because the visible screen is a placeholder, you may not yet see live charts, project tables, team comparisons, or saved reporting views in every Atloria environment. If your workspace includes a more complete analytics experience, use the guidance in the sections above to review projects consistently. If your screen only shows the placeholder message, treat this document as preparation for the reporting workflow Atloria is introducing. [SCREENSHOT: Admin workspace showing the Analytics card and the Analytics & Insights page header with the coming soon notice] For related project-level analysis patterns, see [Analyzing Documentation Performance Across Projects](doc:analyzing-documentation-performance-across-projects). ## Prerequisites Before you try to review documentation performance across projects in Atloria, make sure you can access the parts of the workspace where reporting is exposed. The most important requirement is that you can sign in successfully and reach the authenticated workspace. If you need help with account access, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). You should also be comfortable moving through the **Admin** workspace, since the available reporting entry point in the provided workspace appears there. Open the **Admin** area and confirm you can see the main cards, including **Users & Permissions**, **Organizations**, **Documents**, **Projects**, and **Analytics**. If the **Analytics** card is not visible, your role may not include access to that area. Before starting a comparison review, it helps to have: - Access to the **Admin** workspace - Visibility of the **Analytics** entry point - A clear reporting period you want to review - Familiarity with the projects or teams you are comparing - Permission to open project areas if you need to validate a result in more detail Because the current **Analytics & Insights** page may still be in a placeholder state, you may not be able to complete every comparison task in all workspaces yet. In that case, use this guide to prepare your review method and to recognize the controls to use once project-level reporting is available in your Atloria environment. If your goal is to move from comparison into action planning, continue with [Turning Analytics into Documentation Improvement Actions](doc:turning-analytics-into-documentation-improvement-actions). ## Opening the Git connections view for your project Before you review connection health in Atloria, make sure you are signed in with a role that can manage project settings. If you can open the project workspace but do not see connection or integration settings, you may need Project Administrator access. If access itself is the issue, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If you still need to connect a repository for the first time, use [Connecting Projects to Git Providers](doc:connecting-projects-to-git-providers). 1. Sign in to Atloria and open the project you want to review. 2. Go to the project area where connected services and repository links are managed. Depending on your workspace setup, this may appear under project settings, integrations, or the repository connection area. 3. Open the Git connection details for that project. On this screen, look for the section that shows the current linked source. This is the area you will use to confirm whether the project is still connected correctly. You should expect to see details such as the Git provider, the connected account, and the repository that Atloria is using for documentation sync. [SCREENSHOT: Project Git connection screen showing provider, connected account, and repository details] Some projects show a single project-level connection. Others may display more than one linked repository or source entry. If your project has multiple connected repositories, review each one separately instead of assuming the overall project is healthy. A single broken repository link can still interrupt imports, updates, or branch-based documentation work for part of the project. If you are unsure how your project was originally linked, refer back to [Connecting Projects to Git Providers for Source Based Workflows](doc:connecting-projects-to-git-providers-for-source-based-workflows). For this review, stay focused on what the connection screen currently shows rather than reconnecting anything yet. ## Reviewing which Git account and repository are currently connected Once you are on the Git connection screen, start by confirming that Atloria is pointing to the correct source. The most important items to review are the connected account, the Git provider, and the repository details shown in the connection panel. 1. Find the connected account section and read the account name exactly as shown. 2. Check the Git provider listed for the connection. 3. Review the repository owner and repository name. 4. Confirm the branch or sync target shown for the project. These details help you catch a common problem: a project that is technically connected, but connected to the wrong place. For example, the repository name may look familiar while the owner or organization is different from the one your team expects. That can lead to imports from the wrong source or missing updates from the right one. Use any visible account labels to tell similar connections apart. Atloria may show identifying details such as a username, organization name, or installation label. These clues are especially useful when your team has both personal and organization-managed Git access. If the connected account belongs to an individual when your team expects a shared organization connection, that is worth reviewing before it causes access problems later. A quick comparison table can help during this check: | What to review | What to confirm | |---|---| | Git provider | Matches the provider your team uses for this project | | Connected account | Belongs to the expected person, team, or organization | | Repository owner | Matches the correct organization or account | | Repository name | Matches the project’s actual documentation source | | Branch or sync target | Points to the branch your team expects Atloria to use | If any of these details do not match your team’s expected setup, treat that as a connection health issue even if the status still appears connected. ## Checking whether access is still valid After confirming the connection points to the right repository, check whether Atloria can still use that connection successfully. A connection can look correct but still fail because access has expired, permissions changed, or the repository is no longer available to the linked account. 1. Locate the connection status area on the Git connection screen. 2. Read the current status shown for the linked account and repository. 3. Review any timing details shown nearby, such as the last successful sync, last access check, or authorization time. 4. Click the available action to refresh, recheck, or test the connection. 5. Wait for the status to update and read the result carefully. [SCREENSHOT: Connection health panel with status indicator and recheck action] A healthy connection usually shows a clear connected or active state. If Atloria displays a recent successful sync or access check, that is a good sign that the link is still working. If the last successful activity is old, the connection may need attention even before a full error appears. When you run a fresh check, focus on the exact result message shown on screen. Common outcomes include: - **Connected**: Atloria can still reach the linked repository with the current account. - **Authorization expired**: The linked account needs to be reauthorized. - **Repository not found**: The repository may have been removed, renamed, transferred, or the account may no longer have access. - **Insufficient permissions**: The account is still linked, but it no longer has the access Atloria needs. If the status changes after you run the check, trust the latest result rather than an older status label. This is the fastest way to confirm whether the project is healthy right now, especially after team changes, repository moves, or provider-side permission updates. ## Spotting warning signs that the connection needs attention Not every problem appears as a full disconnection right away. In Atloria, early warning signs often show up before documentation workflows stop completely. Reviewing these signs regularly helps you fix access issues before authors notice missing updates or failed imports. Watch the Git connection screen for visual indicators such as warning badges, alert banners, degraded status labels, or messages that call out limited access. These usually mean the project is still linked, but something about the connection is no longer fully healthy. Pay close attention to issues like: - Missing branch access - Revoked or removed installation access - Expired account authorization - Repository transfer or rename messages - Failed sync notices - Repeated import errors - A last synced time that is much older than expected - A connected account that no longer matches the current team setup [SCREENSHOT: Warning banner on a Git connection showing degraded access or failed sync] A stale sync timestamp is one of the easiest warning signs to miss. If your team expects regular updates from Git but the last sync is old, Atloria may no longer be receiving changes even if the connection has not fully failed. The same is true if the repository owner shown on screen no longer matches your organization after a team restructure or repository move. Also review whether the connected identity still makes sense. A project may still be linked through a former administrator’s account or an outdated organization installation. That can leave the project vulnerable to sudden failure when that person loses access or the installation is removed. If you see any mismatch between the displayed account, repository owner, branch access, or recent sync activity, treat it as a sign that the connection needs review rather than waiting for a complete break. ## Understanding how connection health affects documentation workflows Git connection health directly affects how current your project documentation stays in Atloria. When the linked account loses access or the repository connection becomes unstable, Atloria may no longer be able to pull in source changes, follow branch updates, or keep connected documentation workflows current. A broken or degraded connection can affect several parts of your team’s work: - Repository sync may stop updating project content - Imports from the connected source may fail - Branch-based documentation updates may stop appearing - Review work may continue against outdated content - Publishing decisions may be made using stale project information This does not always happen all at once. Some issues are informational and give you time to act. For example, a warning about aging authorization or an account mismatch may not block work immediately, but it signals that the connection is at risk. Other issues need immediate attention, especially messages that say authorization expired, repository not found, or insufficient permissions. Those usually mean Atloria cannot reliably access the source your project depends on. For project administrators, the goal is to catch these problems early. A quick status review can prevent confusion later when authors expect new content to appear and it does not. It also helps avoid delays in review and release work, since documentation versions may depend on current source content being available. If your team uses connected project workflows heavily, make connection checks part of routine project administration. This is especially important after repository ownership changes, team membership updates, or provider-side access changes. Early review on the Git connection screen is often enough to spot a problem before it turns into a visible documentation gap. ## Common connection health issues and how to fix them Most Git connection problems in Atloria fall into a small set of patterns. The fix depends on what the connection screen is showing, so start with the exact status message or warning banner before making changes. 1. **Authorization expired** Open the project’s Git connection settings and use the reconnect or reauthorize option shown on that page. After reauthorizing, run the connection check again and confirm the status returns to a healthy state. 2. **Repository access removed** Confirm that the linked account still has access to the repository your project uses. If your team uses organization-managed access, make sure the repository is still included there. Then return to Atloria and run a fresh connection check. 3. **Repository moved or renamed** If the repository owner or repository path changed, update the project connection so it points to the current location. A repository that has been transferred to a different owner may appear connected at first but fail validation until the link is updated. 4. **Sync status stays stale after reconnecting** Run the refresh or test action again and verify that the project is using the correct linked account. If the account is valid but the wrong repository or branch is selected, Atloria may still show old sync activity. Use this quick reference while reviewing the status: | Issue shown in Atloria | What to do | |---|---| | Authorization expired | Reauthorize the connected Git account | | Repository not found | Confirm the repository still exists and the path is unchanged | | Insufficient permissions | Restore repository, branch, or organization access for the linked account | | Old last synced time | Run a fresh check and confirm the correct account and repository are selected | If you need to replace the connection entirely, the next guide covers that process: [Reauthorizing and Disconnecting Git Integrations](doc:reauthorizing-and-disconnecting-git-integrations). ## Overview Reviewing Git connection health in Atloria is a quick administrative check that helps you confirm a project is still linked to the right source and that Atloria can still reach it. The most useful information is all on the Git connection screen: the provider, connected account, repository owner, repository name, branch or sync target, and the current status result. This review is not the same as creating a new connection. You are verifying an existing one and looking for signs that it may no longer be reliable. A project can appear connected while still having a hidden problem, such as an expired authorization, a renamed repository, outdated branch access, or a linked account that no longer belongs to the right team setup. As you review the screen, focus on three questions: - Is this the correct Git account for the project? - Is this the correct repository and branch? - Does Atloria show that access is still valid right now? If the answer to all three is yes, your project’s connected documentation workflow is in a healthy state. If any answer is unclear, use the status check tools on the page before authors begin reporting missing updates. This guide fits after the initial connection setup covered in [Connecting Projects to Git and Maintaining Access](doc:connecting-projects-to-git-and-maintaining-access). It is especially useful for project administrators who manage ongoing access, team changes, or repository ownership changes. The goal is simple: confirm that the project’s Git link is still healthy before it affects sync, review, or publishing work. ## Prerequisites Before you review Git connection status in Atloria, make sure these conditions are true: - You can sign in to Atloria successfully. - You have access to the project whose Git connection you want to review. - Your role includes permission to open project settings or integration settings. - The project has already been connected to a Git provider. - You know which repository, owner, and branch your team expects the project to use. It also helps to have basic context from the earlier setup guides, especially if you are checking a project you did not originally connect: - [Connecting Projects to Git Providers for Source Based Workflows](doc:connecting-projects-to-git-providers-for-source-based-workflows) - [Connecting Projects to Git Providers](doc:connecting-projects-to-git-providers) If you are reviewing access after an internal team change, repository transfer, or provider-side permission update, be ready to compare what Atloria shows against your team’s current expected source. That includes the connected account name, repository owner, repository name, and branch. Without that reference point, it is easy to miss a connection that is valid technically but pointed at the wrong source. You do not need to make changes before starting this review. The goal is to inspect the current connection first, run a fresh status check, and only then decide whether reauthorization or reconnection is needed. If the review shows that the connection needs to be replaced or removed, continue with [Reauthorizing and Disconnecting Git Integrations](doc:reauthorizing-and-disconnecting-git-integrations). ## Reviewing language support before defining project scope When you start planning a new project in Atloria, review the language and framework support information before you decide what the project will include. This is the point where you compare your team’s real source material against what Atloria can work with directly. If you already reviewed the broader support list in [Evaluating Supported Languages and Framework Coverage](doc:evaluating-supported-languages-and-framework-coverage), use that as your reference and focus here on planning decisions. 1. Open the area in Atloria where you review supported languages and frameworks for code parsing and source coverage. 2. List the repositories, codebases, and existing documentation sources your team wants to include in the project. 3. For each item, check whether its primary language or framework appears in the supported list. 4. Separate your planned sources into three groups: - supported for direct source connection - supported for code parsing - not clearly supported 5. For each repository or content source, decide whether Atloria will analyze it directly, use it only as authored documentation input, or leave it out of automated analysis. 6. Record that decision in your project notes before anyone starts setup. This review helps you avoid defining a project scope that depends on unsupported inputs. For example, one repository may be a good fit for code upload and parsing, while another may only contribute existing written documentation. A mixed project is often the most realistic option. [SCREENSHOT: language and framework support list open beside a project planning worksheet] As you review each source, stay specific. Do not mark an entire product as “supported” unless the actual repository, language, and documentation source all match what Atloria can use. That level of detail makes later onboarding much smoother and reduces confusion when the team begins connecting sources or uploading code. ## Deciding when to connect source content and when to upload code After you confirm what Atloria supports, decide how each source should enter the project. The main planning choice is whether to connect a source that Atloria can keep in sync, upload code for parsing as a snapshot, or use both methods for different parts of the same project. 1. Review each planned source and identify what it contains: - authored documentation - source code - both code and written docs 2. For sources your team updates regularly, decide whether ongoing connection matters for the project. 3. For codebases you mainly want to inspect for structure or technical reference material, check whether code upload and parsing is the better fit. 4. If a framework is supported for parsing but the team’s authored content is not available as a direct connection option, plan to upload code while managing written docs separately in Atloria. 5. Mark each source with one of these planning decisions: - connect source content - upload code - use a mixed approach 6. Review the list with the people responsible for project setup so everyone agrees before work begins. Use direct source connection when the team needs ongoing updates from a supported content source. Use code upload when the goal is point-in-time analysis of a codebase that Atloria can parse. A mixed approach works well when your team wants live documentation content from one source and parsed technical insight from another. [SCREENSHOT: project planning notes showing connection method choices by repository] This decision should be based on practical workflow needs, not preference alone. If a repository changes every day and the team expects documentation to stay aligned, connection planning matters more. If the team only needs a one-time technical pass for a release, uploading code may be enough. Making that distinction early keeps your project setup realistic. ## Planning documentation coverage around supported and unsupported technologies Once you know which languages and frameworks Atloria supports, use that information to shape documentation coverage. This is where planning becomes more than a yes-or-no support check. You are deciding which areas of the project can benefit from parser-driven discovery and which areas will still need manual documentation work. 1. Group your planned repositories by primary language and framework. 2. Mark which groups are supported for parsing and which are not. 3. Identify the documentation outputs you expect from each group, such as technical reference material, code-informed structure, or manually written guides. 4. For unsupported or mixed-support repositories, plan manual writing work instead of assuming Atloria will generate structure from code. 5. Prioritize the repositories that combine: - strong language support - important product coverage - high documentation value 6. Move lower-value or unsupported repositories into a later phase if needed. This approach helps you set realistic expectations. Supported codebases may help your team move faster when creating technical reference content or exploring implementation details inside a project workspace. Unsupported languages, custom frameworks, or heavily mixed repositories usually require more manual review and more input from subject matter experts. [SCREENSHOT: repository list grouped by support status and documentation approach] Be especially careful with mixed-language repositories. One part of the codebase may fit Atloria’s parsing support well, while another part may not. Instead of treating the whole repository the same way, plan coverage by component, directory, or product area. That gives Documentation Managers a clearer picture of what can be accelerated and what still needs hands-on authoring. ## Aligning project roles on scope and ingestion decisions Language support planning works best when the Project Administrator and Documentation Manager review the same decisions before the project is created. In Atloria, this alignment prevents setup delays and avoids assumptions about what connected sources or parsed code will deliver. 1. Have the Project Administrator review each planned source and confirm whether the team can actually use the intended setup path, such as source connection or code upload. 2. Have the Documentation Manager review the same list and mark which documentation sets can rely on parsed code insight and which will depend on existing written material. 3. Create a shared planning record for every repository or source with one clear status: - connect source content - upload code for parsing - exclude from automated analysis 4. Review any mismatches immediately. For example, one person may expect live sync while another is planning a one-time upload. 5. Finalize scope only after both roles agree on the source method and expected documentation outcome. A simple shared record is often enough, as long as it is specific. The important part is that each repository has one agreed path in Atloria. Without that agreement, teams often promise parser-based outputs for unsupported frameworks or assume a source can stay synced when the plan only supports a one-time code upload. [SCREENSHOT: shared project planning document with repository decisions and owner notes] Keep the conversation tied to actual project assets. Instead of discussing support in general terms, review each repository, documentation source, and expected output one by one. That makes it easier to spot planning gaps before anyone starts onboarding the project or preparing source material. ## Estimating effort for projects with partial language support Projects rarely fit into a single support category. In Atloria, some repositories may be fully supported for parsing, others may only contribute written documentation, and some may need entirely manual treatment. A simple planning table helps you estimate effort without overpromising speed or automation. Use a table like this during planning: | Repository | Primary language | Framework | Support status | Ingestion method | Documentation approach | |---|---|---|---|---|---| | Customer portal | Supported language | Supported framework | Supported for parsing | Upload code | Use parsed results plus editor review | | Help center content | Existing documentation source | Not applicable | Source-based planning | Connect source content | Keep synced written docs | | Legacy service | Unsupported language | Custom framework | Not supported | Exclude from automated analysis | Manual documentation | | Shared library | Mixed | Partial support | Partial support | Mixed approach | Split by component | When you fill out this table, estimate lower effort for repositories where Atloria can help with code-informed discovery. Those areas may move faster because the team can work from parsed structure and technical reference material. Estimate more time for unsupported languages, generated code, or proprietary frameworks, because those areas usually require manual review, interviews, and existing internal documents. The table also helps you separate planning into two work types: - accelerated work supported by connected sources or parsed code - manual work that depends on human review and writing [SCREENSHOT: planning table with repositories, support status, and documentation approach] This kind of estimate is especially useful when you need to phase a project. Start with the repositories that offer the best combination of support coverage and business value, then schedule manual-heavy areas after the first release or onboarding cycle. ## Handling common planning issues with language support information Even with a support list in front of you, planning questions still come up. Most of them happen when teams assume support means more than it actually does, or when a repository does not fit neatly into one category. In Atloria, the best response is to turn each issue into a clear planning decision before setup begins. 1. If a required repository uses a language or framework that is not listed as supported, remove parser-based expectations from the project plan. 2. Decide how that repository will be documented instead, such as using existing written material or manual authoring in Atloria. 3. If the team is unsure whether to connect a source or upload code, compare the real need: - continuous updates and synchronization - one-time code analysis 4. If a repository contains multiple languages, split the plan by component, directory, or product area instead of giving the whole repository one support label. 5. If stakeholders expect complete automation, review exactly which parts of the workflow Atloria can accelerate and which still require editorial review. Common issues usually fall into a few patterns: - **Unsupported technology:** plan manual documentation and avoid promising generated technical coverage. - **Unclear ingestion path:** choose based on ongoing sync needs versus snapshot analysis. - **Mixed-support repository:** break planning into smaller parts. - **Overstated expectations:** explain that support helps with discovery and acceleration, not automatic completion of all documentation work. [SCREENSHOT: project planning notes showing risks, unsupported items, and chosen fallback approach] When you handle these issues early, project scope stays credible. That matters most when multiple teams are involved, because unclear support assumptions can affect timelines, staffing, and release expectations long before any content is created. ## Overview - This guide focuses on using Atloria’s language and framework support information to make project planning decisions before setup begins. - Use it when you need to decide: - which repositories belong in scope - whether a source should be connected or uploaded - which areas can benefit from code parsing - which areas require manual documentation planning - This guide builds on [Evaluating Supported Languages and Framework Coverage](doc:evaluating-supported-languages-and-framework-coverage), so it does not repeat the full support review process. - The main planning outcome is a per-repository decision that clearly states whether the team will: - connect source content - upload code for parsing - use a mixed approach - exclude the source from automated analysis - Atloria planning is most effective when support status is reviewed alongside real project inputs such as repositories, documentation sources, and expected deliverables. - Use [SCREENSHOT: support list beside repository planning notes] if you want to show stakeholders how support information translates into scope decisions. ## Prerequisites - Before using this planning approach in Atloria, make sure you have: - reviewed the current supported languages and frameworks - a list of repositories, codebases, or documentation sources the project may include - a rough idea of the documentation outputs the team expects - It helps to involve both of these roles during planning: - **Project Administrator** - **Documentation Manager** - Gather the following details for each planned source: - primary language - framework, if relevant - whether the source changes frequently - whether the team needs ongoing sync or one-time analysis - If your team is still comparing support coverage at a general level, read [Evaluating Supported Languages and Framework Coverage](doc:evaluating-supported-languages-and-framework-coverage) first. - After you finish scope planning, continue with [Understanding Parser Availability Before Code Upload](doc:understanding-parser-availability-before-code-upload) to confirm what to check before uploading code into Atloria. ## Identifying Which Project Signals Matter for Daily Prioritization In Atloria, the most useful prioritization signals usually come from three places users already check: the project activity view, version and release areas, and admin-facing status screens such as **Analytics & Insights** and **Security & Audit**. Even though **Analytics & Insights** and **Security & Audit** currently show a coming-soon message, the project workspace still gives you enough visible signals to decide where attention belongs first. The key is to separate “something changed” from “something needs action.” Start by looking for signals tied to visible work: - recent edits in project activity - newly created documentation items - reopened work that had already been reviewed - version movement tied to release work - delayed or unresolved follow-up items - missing ownership on active work These signals do not all mean the same thing. High activity means a project area is moving quickly. That often points to pages that may need review, but it does not automatically mean the content is wrong. High risk means the work is closer to release, blocked, or changing without clear ownership. Low performance signals usually show up as stalled progress, repeated reopen cycles, or work sitting too long without moving forward. Different roles use the same signals in different ways: - **Documentation Managers** look for patterns across projects so they can decide where the team should spend time first. - **Technical Writers** focus on recent edits, changed pages, and version-related movement that could affect published documentation. - **Project Administrators** watch for ownership gaps, delayed follow-up, and status inconsistencies that can block the rest of the team. A simple way to map signals to decisions is: - **Activity feed** → check whether content needs review - **Version or release status** → decide whether a release needs documentation attention - **Status, assignee, and due-date fields** → decide whether operational follow-up is needed [SCREENSHOT: Project workspace showing recent activity, version status, and ownership fields used for prioritization] ## Reviewing Project Activity to Decide What Content Needs Updates When you need to decide what content should be reviewed first, open the project workspace and go to the area that shows recent project movement. Focus on visible changes: recent edits, newly created items, and work that has been reopened after review. Those are the clearest signs that a page, section, or version may no longer match the current state of the project. As you scan the activity list, compare each item against the details shown beside it. The most useful fields are usually: - **Status** - **Last updated** - **Owner** or **Assignee** A recent timestamp by itself is not enough. If an item was updated today but is still in a stable state with the same owner and no related release movement, it may only need monitoring. If an item was reopened, reassigned, or changed repeatedly in a short period, that is a stronger signal that the related documentation should be checked. Use patterns, not single events, to decide urgency. For example: - several updates in one content area over a few days often point to active product change - one isolated edit may be routine cleanup - reopened work usually deserves faster review than a simple timestamp change - new items created near active release work often need documentation coverage sooner A practical way to turn this into action is to build a simple review queue: 1. **Immediate updates**: reopened work, high-change areas, or items tied to active release work 2. **Monitor only**: recent edits with no clear impact yet 3. **No action needed**: minor updates with stable status and no release connection If you are comparing multiple projects, look for clusters of activity rather than the busiest list. A project with fewer updates but more reopened work may need more attention than a project with many routine edits. For broader interpretation of project trends, use [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity) alongside your daily review. ## Using Release Indicators to Focus Attention on the Right Versions Release-related signals help you decide which versions deserve immediate documentation attention and which ones can wait. In Atloria, this usually means reviewing version areas for releases that are upcoming, recently shipped, delayed, or showing a sudden increase in related activity. A version does not become important only when it is published; it becomes important when its status and surrounding activity suggest readers may soon depend on it. Start with the versions closest to change. The strongest release indicators are: - an upcoming release date - a version marked as in progress - a recently completed or shipped version - delayed milestones - a spike in edits, comments, or reopened items connected to one version These indicators matter because release timing changes the cost of waiting. If a version is moving toward release, even small content gaps can become urgent. If a version is active but details are still changing quickly, you may need to monitor first and update once the scope is clearer. When several releases compete for attention, weigh them in this order: | Signal | What it suggests | Priority effect | |---|---|---| | Release timing | A version is close to shipping or just shipped | Raises urgency | | Related activity volume | Many recent changes tied to the version | Raises review need | | Unresolved follow-up | Open blockers, missing owners, or delayed tasks | Raises risk | Use these signals together. A high-visibility release with little confirmed change detail may not need immediate page edits, but it does need close monitoring. A smaller release with heavy project movement and unresolved follow-up may deserve faster writer attention. A good rule is: 1. Update content now when the version is active and the affected areas are clear. 2. Monitor closely when the version is important but details are still unstable. 3. Escalate follow-up when release work is delayed because ownership or status is unclear. If you already use release analytics to support content planning, connect this process with [Reading Project Analytics for Content and Release Decisions](doc:reading-project-analytics-for-content-and-release-decisions) instead of repeating a full release review from scratch. ## Spotting Operational Follow-Up from Performance and Status Signals Not every urgent-looking signal belongs to the writing team. Some signals point to operational follow-up instead of content work. In Atloria, you can usually spot these by checking visible status fields and work-tracking details in the project workspace: stalled items, overdue work, unresolved blockers, repeated reopen cycles, and tasks that are active but have no clear owner. The most useful fields for this review are: - **Assignee** - **Due date** - **Priority** - **Status** These fields tell you who should act next. If a page is outdated because product work changed, that is usually a writer task. If a release task is overdue with no assignee, that is usually a manager or project administrator issue. If an item stays in review too long, the problem may be the review process rather than the content itself. Use the signals to separate content work from operational work: - **Content work**: recent product-related edits, changed version scope, reopened documentation items - **Operational follow-up**: overdue tasks, blocked work, missing owners, status values that do not move for long periods - **Mixed cases**: active release work with both content gaps and ownership problems A practical follow-up path looks like this: 1. Update content directly when the documentation impact is clear and the item already has an owner. 2. Request clarification from the project team when activity is visible but the content impact is uncertain. 3. Escalate ownership gaps when active or overdue work has no assignee, unclear priority, or a stalled status. Repeated reopen cycles deserve special attention. They often mean the team is not aligned on what “done” means, and that can create unnecessary documentation churn. Likewise, items stuck in review can delay release readiness even when the content itself is nearly complete. For admin-level follow-up, pair project signals with the broader controls described in [Reviewing Security and Audit Controls](doc:reviewing-security-and-audit-controls) and [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). ## Turning Multiple Signals into a Repeatable Prioritization Workflow The easiest way to make prioritization consistent is to run the same triage routine on a schedule. In Atloria, this works well as a weekly review and again before major release checkpoints. The goal is not to inspect every item in detail. The goal is to combine activity, release status, and work health into one short decision pass that tells the team what to do now, what to watch, and what to escalate. Use this routine: 1. Open the project workspace and review recent activity for changed, new, or reopened items. 2. Check the related version or release area for versions that are in progress, recently completed, or delayed. 3. Review visible work fields such as **Status**, **Assignee**, **Due date**, and **Priority** to find blockers or ownership gaps. 4. Sort each item into one of three buckets: urgent content update, monitor, or operational follow-up. 5. Record the decision where the team already works, such as project notes, task comments, or status updates. A simple priority model keeps the team aligned: | Priority level | Typical signals | Usual action | |---|---|---| | Urgent | Active release, reopened work, clear content impact | Update or validate content now | | Medium | High-change area, recent edits, uncertain impact | Monitor and schedule review | | Operational | Blocked, overdue, missing owner, stalled review | Escalate or reassign | Each role contributes differently: - **Documentation Managers** decide the threshold for what counts as urgent and what can wait. - **Technical Writers** confirm whether the visible project movement actually changes reader-facing content. - **Project Administrators** correct status problems, ownership gaps, and inconsistent tracking details. Keep your notes brief but specific. A short comment like “monitor until version scope stabilizes” or “update release notes after reopened setup page review” helps everyone understand why work was promoted or deferred. If your team already reviews project trends regularly, this workflow fits naturally beside [Using Project Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements). ## Resolving Common Prioritization Problems When Signals Conflict Conflicting signals are common in Atloria, especially when one part of the project is moving quickly and another part is not. The safest approach is to treat conflicting signals as a reason to verify, not a reason to panic. You are trying to confirm impact before you move work to the top of the queue. If a project shows heavy recent activity but no clear documentation impact, check whether the changes are clustered around pages, versions, or workflows readers actually use. A busy activity list can come from internal cleanup, ownership changes, or routine maintenance. In that case, place the item in **monitor** instead of **urgent** until a related page, version, or release area shows a stronger signal. If a release has high visibility but low confirmed change detail, do not rush into broad edits. Mark the release for close review, watch for reopened work or version-specific updates, and wait until the affected content areas are clearer. This avoids unnecessary rewriting when implementation details are still shifting. If overdue or blocked items look urgent but are unrelated to published content, route them as operational follow-up. They may still matter to the project, but they should not automatically displace reader-facing updates. Signal quality matters too. When **Last updated** values look stale, **Assignee** is blank, or **Status** values are inconsistent, your first task is to correct the tracking information. Poor data creates false urgency. Ask the project owner or administrator to update the visible fields before you reprioritize. Use this rule of thumb: - unclear activity → monitor - clear release impact → update - ownership or workflow problem → escalate - unreliable status data → correct the record first When signals stay inconsistent across several reviews, rely on direct project clarification instead of guessing from the dashboard. That keeps prioritization tied to real work rather than noisy indicators. ## Overview - This guide focuses on using visible project signals in Atloria to decide what deserves attention first. - The main signal groups are: - recent activity in the project workspace - version and release indicators - status-based follow-up such as overdue, blocked, or unassigned work - The goal is to separate three kinds of action: - content updates that should happen now - items that should be monitored until details are clearer - operational follow-up that needs reassignment, clarification, or escalation - Different roles use the same signals differently: - **Documentation Managers** set priority rules and review team-wide impact - **Technical Writers** confirm whether project movement changes reader-facing content - **Project Administrators** correct ownership, status, and workflow gaps - This document builds on the release and content interpretation covered in [Reading Project Analytics for Content and Release Decisions](doc:reading-project-analytics-for-content-and-release-decisions). Here, the focus is turning those signals into a repeatable prioritization routine. - In Atloria, useful prioritization decisions often come from combining several visible cues instead of reacting to one field alone. For example, a recent edit becomes more important when it appears beside an active version, a reopened item, or a missing owner. - The **Analytics & Insights** and **Security & Audit** areas are visible in the admin workspace, but they currently present a coming-soon message. For day-to-day prioritization, rely mainly on the project workspace, version areas, and visible work status details. [SCREENSHOT: Atloria project workspace with recent activity, version status, and work-tracking details highlighted] ## Prerequisites - You should be able to sign in to Atloria and open the main project workspace. If needed, review [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). - You should already know how to move around project areas, including project lists, dashboards, and version-related screens. If navigation is still unfamiliar, use [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). - You should have access to at least one project where you can view: - recent activity - version or release information - visible work details such as **Status**, **Assignee**, **Due date**, or **Priority** - This guide assumes you already understand how to read project analytics at a basic level and want to turn those signals into action. For the earlier interpretation step, see [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). - If you are working with release-driven priorities, it also helps to know how your team manages version work in Atloria. Use [Managing Project Version Workspaces](doc:managing-project-version-workspaces) or [Managing Project Version Timelines and Status Decisions](doc:managing-project-version-timelines-and-status-decisions) if you need that context first. - If you are reviewing priorities as an administrator, familiarity with the admin workspace is useful, especially the **Analytics & Insights** and **Security & Audit** entries in the admin area. For that navigation, see [Using the Admin Workspace](doc:using-the-admin-workspace). ## Opening a project and reading the project home status Open your project from the main **Projects** area in Atloria, then select the project name to enter the project itself. When you first arrive, use the main project screen as your coordination point instead of jumping straight into a document, version, analytics page, or technical reference area. This project home view keeps the full project context visible so you can quickly understand where work stands before you open a specific workspace. At the top of the page, look for the project header. This is where Atloria shows the **project name** and the main project identity for the workspace you are viewing. Around that header, you will typically use the surrounding summary area to understand overall project status at a glance. This is the best place to confirm that you opened the correct project before reviewing activity or assigning follow-up work. Below the header, review the project home cards or summary panels. These panels are useful because they bring together project-wide signals in one place instead of making you open each workspace one by one. Focus on items such as: - linked workspaces connected to the project - recent activity across the project - progress indicators that reflect project-wide documentation work [SCREENSHOT: Project home showing the project header, status area, and summary cards] Project home is different from a single workspace because it is designed for coordination, not deep editing. A content workspace is where you write and organize documentation. A version workspace is where you review release progress and version status. An analytics workspace is where you review usage and performance information. A technical documentation workspace is where you browse generated technical reference material. Project home sits above all of these and helps you decide where to go next based on current status. If you need a refresher on finding projects from the broader project list, see [Managing Project Portfolio and Operational Oversight](doc:managing-project-portfolio-and-operational-oversight). ## Moving between project home tabs to find the right work area Inside project home, use the tab navigation to move between the main project views without leaving the current project. This is one of the most useful parts of working in Atloria because you can compare several kinds of project information while staying anchored to the same project record. Instead of reopening the project each time, you switch tabs and keep the same project scope throughout your review. 1. Open the project from **Projects**. 2. Stay on the main project area and look for the tabs near the top of the page. 3. Click a tab to switch views inside the same project. 4. Review the information on that tab, then move to another tab as needed. Different tabs support different coordination tasks. In practice, you will use them to review project details, check linked workspaces, look at recent activity, and move into reporting-oriented views when you need a broader picture of progress. The exact tab names may vary by project setup, but the purpose stays the same: each tab helps you inspect one part of the project without losing the overall project context. This matters when several teams are working at once. For example, a documentation manager may compare activity and workspace status across tabs before deciding whether to open the content workspace or the version workspace. A project administrator may stay in project home longer to review status across areas before making changes elsewhere. Stay in project home when you need to: - compare progress across multiple work areas - review recent updates before assigning follow-up work - confirm which linked workspace needs attention Open a linked workspace when you need to: - edit documentation content - review or manage versions - inspect analytics in detail - browse technical documentation pages [SCREENSHOT: Project home tabs with one tab selected and others visible] Using tabs this way keeps your review efficient and avoids losing track of which project you are working in. ## Tracking linked workspaces from one project context One of the main jobs of project home is helping you track every workspace connected to the current project. Look for the linked workspaces section, card list, or panel on the project home screen. This area shows the workspaces that support the project and gives you a quick way to move between them without going back to the main navigation. As you review the list, identify the type of work each linked workspace supports. In Atloria, documentation teams commonly coordinate across these workspace types: | Workspace type | What you use it for | |---|---| | Content workspace | Writing, editing, and organizing documentation pages | | Version workspace | Reviewing version status, release readiness, and version-related tasks | | Analytics workspace | Checking usage statistics, performance trends, and reporting views | | Technical documentation workspace | Browsing technical reference material connected to the project | Use the linked workspace list to confirm that the project has the work areas you expect. This is especially helpful when you manage several projects and need to verify whether a project already has the right documentation spaces connected. Pay attention to any status or health signals shown beside each workspace. These indicators help you spot where work may be incomplete, delayed, or waiting for review. For example, if one workspace looks less active than the others, that may be the area to inspect next. If a workspace appears connected but shows limited progress, open it and confirm whether work is still in progress or simply not reflected in the summary yet. To move between areas, click the linked workspace name from project home. After reviewing or updating that workspace, return to the project home area to continue your cross-project check. This back-and-forth pattern is useful because it lets you make a targeted update without losing sight of the overall project. [SCREENSHOT: Linked workspaces panel showing content, versions, analytics, and technical documentation entries] ## Coordinating content, versions, analytics, and technical documentation work Project home is most useful when you need to coordinate several kinds of documentation work at the same time. Instead of treating content, versions, analytics, and technical documentation as separate streams, use the project home screen to compare them side by side and decide what needs attention first. A practical workflow in Atloria looks like this: 1. Open the project and review the project home status. 2. Check the summary panels and linked workspaces to see which area needs follow-up. 3. Open the relevant workspace directly from project home. 4. Make the needed update in that workspace. 5. Return to project home and confirm whether the overall project picture now looks aligned. This approach works well because project home gives you a shared starting point. A documentation manager can review whether content work is moving forward, whether version work is ready for review, whether analytics suggest a documentation gap, and whether technical documentation needs attention. A project administrator can use the same project context to coordinate across teams without managing each area in isolation. For example, if recent activity shows content updates but version progress still appears behind, open the version workspace next. If analytics suggest readers are relying heavily on a certain area, you may decide to open the content workspace or technical documentation workspace to improve that material. If technical reference pages need review before a release, project home helps you move there quickly without losing track of the broader release picture. This coordination style is especially helpful when deadlines shift. Technical writers can start from project-level status, identify the exact workspace that is blocking progress, and move directly into that area. For deeper guidance on the individual work areas themselves, use the related guides such as [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages), [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle), and [Exploring Technical Documentation Inside a Project](doc:exploring-technical-documentation-inside-a-project). ## Using project home to monitor progress and recent activity Use project home as your regular check-in screen when you need to understand what changed across the project most recently. The progress indicators and activity summaries on this page are designed to help you review project movement without opening every workspace one at a time. For weekly reviews, handoffs, and status meetings, this is often the fastest place to start. Begin with the project-wide progress area. This part of the page helps you judge whether work is moving evenly across the project or whether one area is falling behind. Then review the recent activity section to see which workspace had updates and what kind of work changed. Even a short activity list can tell you a lot when you are coordinating multiple contributors. When reading recent activity, look for signals such as: - which linked workspace was updated - whether the update relates to documentation work, version work, analytics review, or technical documentation - whether activity appears recent enough to match the team’s expected progress [SCREENSHOT: Project home recent activity section with project-wide progress indicators] Project home is especially useful during handoffs. A documentation manager can open the project home screen during a meeting and quickly point to recent updates, then decide whether the next conversation should happen in the content workspace, version workspace, analytics area, or technical documentation view. This keeps status discussions tied to visible project information instead of relying on separate notes. Some signals mean you should go deeper into a linked workspace: - progress looks uneven across work areas - recent activity appears in one workspace but not another related area - a workspace shows little or no movement when work should already be underway - a summary panel suggests incomplete or stalled work When that happens, use project home as the launch point for a closer review. It gives you enough context to know where to investigate next without forcing you to search through the project from scratch. ## Common issues when coordinating work from project home If project home does not show what you expect, start by checking whether you are in the correct project and whether you are still on the main project area rather than inside a specific workspace. Many coordination problems come from opening the right project but the wrong view, especially when local workspace navigation looks similar to project-level navigation. A common issue is a missing linked workspace. If you do not see the workspace you expected, first confirm that you opened the correct project record from **Projects**. Then review the linked workspaces area again. If the workspace is still missing, the current project may not have that workspace connected, or your access may not allow you to open it. Another issue is project status that looks incomplete or outdated. In that case, refresh the project home page and compare the summary panels with the most recent work you know was completed. Sometimes updates were made inside a linked workspace, but the project home summary does not yet match what you expected to see. Refreshing the view is the quickest first step before escalating the issue. If you can open project home but not the workspace you need, check whether your role includes access for the work you are trying to open. In Atloria, documentation managers, technical writers, and project administrators may have different levels of access depending on the project setup. If a workspace opens for a teammate but not for you, this usually points to a permission difference. If the tabs do not show the information you expected: - confirm you are on the main project home screen - check whether you accidentally opened a linked workspace with its own navigation - return to the project’s main page and use the project home tabs again For more on access and admin-level setup, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). ## Overview Use project home in Atloria as the central coordination screen for a documentation project. It brings together the project name, project-level status, linked workspaces, and recent activity so you can understand the current state of work before opening a specific area. This is especially useful when several teams are contributing to the same project and you need one place to compare progress. The most important parts of project home are: - the project header, which confirms which project you are viewing - the tab navigation, which lets you switch between project-level views - the linked workspaces area, which shows the connected spaces for content, versions, analytics, and technical documentation - the recent activity and progress summaries, which help you spot changes and delays quickly Project home is not meant to replace the detailed workspaces. Instead, it helps you decide where to go next. Use it when you need to review overall status, compare work across areas, prepare for a handoff, or guide a status discussion. Then open the linked workspace that needs action and return to project home when you want to confirm the broader project picture again. This guide focuses on using project home as a coordination layer. If you need detailed instructions for project lists, dashboards, or broader portfolio oversight, refer back to [Managing Project Portfolio and Operational Oversight](doc:managing-project-portfolio-and-operational-oversight). From there, this guide picks up at the project level and shows how to manage work once you are already inside a specific project context. The next step is [Navigating Project Workspaces and Linked Tools](doc:navigating-project-workspaces-and-linked-tools), which goes deeper into moving through the connected work areas after you leave project home. ## Prerequisites Before using project home to coordinate documentation work, make sure you have the basics in place so the project-level information in Atloria is meaningful and actionable. You should have: - access to Atloria with permission to open projects - at least one project visible in the **Projects** area - a project that already includes one or more linked workspaces - the appropriate role for the work you need to review, such as documentation manager, technical writer, or project administrator access - familiarity with opening projects from the project list It also helps if the project already has active work underway. Project home is most useful when there is recent activity to review, linked workspaces to compare, and progress signals that help you decide what to do next. If a project is brand new, the project home screen may have less information to coordinate. Before relying on project home for status reviews, make sure you can: - open the project from **Projects** - recognize the project’s main home area - switch between project-level tabs - open and return from a linked workspace If you are still getting familiar with project navigation, start with [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces). Those guides explain how to find projects and recognize the difference between project-level navigation and workspace-level navigation, which makes this coordination workflow much easier to follow. ## Opening a Project Workspace and Reading the Navigation Areas In Atloria, you usually enter a project workspace from the main signed-in area after selecting a project from your project list or dashboard. If you have already worked through [Using Project Home to Coordinate Documentation Work](doc:using-project-home-to-coordinate-documentation-work), this is the same project context, but here the focus is on moving between the linked tools inside that project without getting lost. 1. Open your project from the project list, dashboard, or any project card that takes you into the workspace. 2. Look at the project header at the top of the page. This area identifies the current project and helps confirm that you are working in the right place before you open documents, versions, or settings. 3. Use the project navigation area on the left side or in the project tabs to move between the linked sections available for that project. The project navigation is where Atloria groups the workspaces tied to the current project. Depending on your access, you may see links such as **Documents**, **Versions**, **Analytics**, **Audit History**, **Settings**, **Technical Documentation**, and **Onboarding**. These links keep you inside the same project, even though the screen content changes. [SCREENSHOT: project workspace showing the project header and navigation links for Documents, Versions, Analytics, Audit History, Settings, Technical Documentation, and Onboarding] Pay attention to the difference between changing sections and leaving the project entirely. When you click a project navigation link, Atloria opens another area connected to the same project. The project name in the header should stay consistent. If a linked tool opens in a different layout, panel, or browser tab, check the header or breadcrumb trail right away so you can confirm you are still viewing the same project. If you need to move to another project, use the project list or project switcher area available from your broader workspace navigation rather than using document or version links inside the current project. That helps you avoid mixing content from two different projects. ## Moving Between Documents and Version History The **Documents** area is where most day-to-day writing and review work starts. From the current project workspace, open **Documents** in the project navigation to see the document list for that project. This list is your starting point for opening pages, checking what exists, and moving into version-related work without leaving project context. 1. Click **Documents** in the project navigation. 2. Review the document list and use any visible **Search** field or filters to narrow the list if you need a specific page. 3. Select a document from the list to open its detail view or editing screen. 4. From that document view, open the related **Versions** tab, version panel, or linked version area to review its history. Inside version history, look for the details that help you understand what changed over time. Atloria may show version labels, revision dates, timestamps, and the name of the person who made the update. Use the version selector to switch between the current version and earlier versions. This is especially helpful when you need to confirm whether a change is new, already reviewed, or part of an earlier release cycle. [SCREENSHOT: document page with document list on one side and a linked version history panel or tab] When comparing versions, focus on: - The selected version name or revision entry - The date and time of the change - The person associated with the update - Any status or history details shown alongside the version record To return without losing your place, use the document title link, the **Documents** tab, or the breadcrumb trail if it is visible. If you opened version history from a document, return to that parent document first rather than jumping back to the full project list. That keeps your navigation smooth and avoids reopening the same project from scratch. For deeper version workflows, use [Managing Project Version Workspaces](doc:managing-project-version-workspaces) and [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons). ## Using Analytics and Audit History to Understand Project Activity Atloria includes linked project views that help you understand what is happening around your documentation work, not just the content itself. Two of the most useful are **Analytics** and **Audit History**. Open each one from the project navigation so you stay within the same project while reviewing activity. 1. Click **Analytics** from the project workspace navigation. 2. Review the page header to confirm you are still in the correct project-related workspace. 3. Use the available charts, summaries, or activity indicators to understand project performance and usage. 4. Switch to **Audit History** to trace specific actions in time order. The **Analytics** area is intended for usage statistics and performance metrics tied to the current project. Use it when you want a higher-level view of activity, such as documentation trends, project usage, or overall performance signals. Analytics helps you step back from individual pages and see the bigger picture. If your Atloria workspace currently shows a coming-soon message in **Analytics**, that means the section exists in navigation but detailed project metrics are not yet available on that screen. The **Audit History** area is different. It is for event-by-event tracking. In audit records, look for: - Timestamps showing when something happened - User names showing who performed the action - Event descriptions showing what changed This is the best place to confirm edits, status changes, settings updates, and other recorded actions. If a document looks different than expected or a project option changed, the audit trail helps you trace the sequence. [SCREENSHOT: project analytics page header and a separate audit history list with timestamps and user actions] Use **Analytics** for patterns and **Audit History** for exact actions. If you need broader administrative reporting, see [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). If you are focused on project-level reporting, continue with [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). ## Updating Project Settings Without Losing Your Place The **Settings** area lets you adjust options tied to the current project while staying connected to the rest of the workspace. Open **Settings** from the project navigation when you need to review project details, workspace options, or connected features that belong to this project rather than the whole organization. 1. From the current project workspace, click **Settings**. 2. Confirm the project name in the header before making changes. 3. Open the settings section you need and update the available fields or options. 4. Click **Save** if the page includes a save action. 5. Use the breadcrumb trail, project header, or project navigation to return to **Documents**, **Versions**, or **Analytics**. Project settings are different from organization-wide administration. If you are changing something from inside a project, treat it as project-specific unless the screen clearly takes you into a broader admin area. For example, project metadata, project options, and linked project tools belong to the current workspace. Broader user access or organization administration belongs in the admin workspace, which is covered in [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings). As you work, keep an eye on the navigation state. Atloria may keep the **Settings** section highlighted while you are editing. After you save, the page may remain in **Settings** so you can continue reviewing options, or you may choose another project link yourself. Use the project header and navigation links rather than the browser back button when possible, because that makes it easier to stay in the same project context. [SCREENSHOT: project settings screen with project header, save action, and navigation links back to Documents and Versions] If you need help with specific project configuration tasks after onboarding, the next document in this sequence goes deeper into that work: [Managing Project Setup After Initial Onboarding](doc:managing-project-setup-after-initial-onboarding). ## Opening Technical Documentation and Onboarding Resources from the Project Some project links in Atloria are not for editing day-to-day documents. They support the people working on the project by giving them reference material and setup guidance. The two key areas are **Technical Documentation** and **Onboarding**. 1. In the current project workspace, click **Technical Documentation** when you need project-specific reference material. 2. Click **Onboarding** when you need setup guidance or first-use instructions for contributors. 3. Use the breadcrumb trail, project header, or project navigation to return to your active project area when finished. Use **Technical Documentation** when you need implementation-focused material tied to the project. This may include structured reference content, schemas, internal notes, or other technical guidance that supports documentation work. Documentation Managers and Technical Writers often use this area while checking terminology, validating reference details, or reviewing source material before updating published content. If you want a deeper walkthrough of this area, see [Exploring Technical Documentation Inside a Project](doc:exploring-technical-documentation-inside-a-project). Use **Onboarding** when the goal is getting someone started. This area is more appropriate for first-time contributors, Project Administrators, or team members who need setup instructions, role-based guidance, or a checklist of what to do next inside the project. It is the better choice when the question is “How do I begin?” rather than “What does this project contain?” [SCREENSHOT: project navigation with Technical Documentation and Onboarding links highlighted] A simple way to choose between them: - Use **Technical Documentation** for reference and project knowledge - Use **Onboarding** for setup and first-use guidance - Return to **Documents** when you are ready to write or review content - Return to **Versions** when you are checking release-related changes If either area opens in a linked view, use the visible project name, breadcrumbs, or related-resource links to get back to the same project workspace instead of starting over from the main dashboard. ## Fixing Common Navigation Problems Across Linked Workspaces When project navigation does not behave the way you expect, start by checking the visible project context before assuming content is missing. Most navigation issues in Atloria come from being in the wrong project, opening a linked workspace in a separate tab, or not having access to a section. If links such as **Documents**, **Versions**, **Analytics**, or **Audit History** are missing: - Check whether you are inside a project workspace and not in a broader admin or dashboard view - Look at the project header to confirm a project is actually open - Refresh your view by returning to the project list and reopening the project - If the link still does not appear, your access level may not include that section If a linked tool opens with unexpected content or an empty screen: - Confirm the project name in the header - Compare it with the project you intended to open - Return to the project list or dashboard and reopen the correct project - If you used a browser bookmark or an older tab, it may be pointing to a different project workspace If you cannot open **Settings**, **Technical Documentation**, or **Audit History**: - This usually means your current role does not allow access to that area - Ask a project administrator or organization administrator to confirm your permissions - If you need help with access management, use [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) If you lose the breadcrumb trail or open a linked workspace in a new tab: - Use the project name in the header to confirm where you are - Reopen the main project workspace from your project list if needed - Avoid switching projects from old tabs without checking the header first [SCREENSHOT: example of a linked workspace open in a separate tab with the project name visible in the header] When navigation problems affect setup-related areas, continue with [Managing Project Setup After Initial Onboarding](doc:managing-project-setup-after-initial-onboarding), which covers the next stage of working inside a project after you have found the right workspace. ## Overview This guide focuses on how to move around a single project in Atloria without losing track of where you are. The goal is not to explain every project feature in detail, but to help you recognize the linked workspaces that belong to the current project and move between them confidently. Inside a project workspace, Atloria groups related work into clear navigation areas. The most important sections for everyday use are **Documents** and **Versions**, where you review content and its history. Supporting areas such as **Analytics**, **Audit History**, **Settings**, **Technical Documentation**, and **Onboarding** help you understand project activity, adjust project options, and find guidance without leaving the project context. This guide is especially useful if you: - Open a project and are unsure which link to use next - Need to move from a document into version history and back again - Want to check project activity without opening organization-wide admin screens - Need to open settings, technical reference material, or onboarding help and return to your current work quickly You will also learn how to tell whether you are still inside the same project when a linked tool opens in a different view, panel, or tab. That is important when several projects have similar content or when you are switching between writing, review, and project administration tasks. For background on the project home itself, use [Using Project Home to Coordinate Documentation Work](doc:using-project-home-to-coordinate-documentation-work). For broader project navigation patterns, [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces) is the best companion document. ## Prerequisites Before using the navigation patterns in this guide, make sure you have the basics in place so the project links and workspace areas make sense. You should have: - An Atloria account that can sign in successfully - Access to at least one project workspace - Permission to open the project areas relevant to your role - A basic understanding of the project home and project list Helpful background reading: - [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) - [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) - [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) - [Using Project Home to Coordinate Documentation Work](doc:using-project-home-to-coordinate-documentation-work) It also helps if you already know what kind of task you are trying to complete. For example: - Choose **Documents** if you want to open or review documentation pages - Choose **Versions** if you want to inspect revision history or release-related changes - Choose **Settings** if you need to adjust project-specific options - Choose **Technical Documentation** if you need project reference material - Choose **Onboarding** if you are helping a new contributor get started If some navigation links are not visible after you open a project, that usually means one of two things: you are not in the project you expected, or your role does not include access to that area. In that case, confirm the project name in the header and then check with your project administrator before continuing. ## Defining the project workspace before adding content Before your team creates pages, use the project setup screens in Atloria to lock down the basic decisions that affect navigation, publishing, and ownership. This is where you make sure the project name, workspace identity, and access direction are stable enough that writers are not building on top of moving targets. If you still need help with the broader project setup flow, see [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). 1. Open your project, then go to the project settings area where you manage the project name, URL settings, and language options. Set the **Project Name** exactly as you want teams to recognize it across project lists, dashboards, and internal navigation. 2. Review the project’s **URL slug** or published path setting. Choose a short, durable naming pattern and avoid changing it later unless you are intentionally restructuring published documentation. This helps keep links, navigation paths, and shared references consistent. 3. Set the project’s default language or locale in the language setting used for the workspace. Pick the primary language your team will use for page titles, navigation labels, and published content so new content starts from the correct default. 4. In the audience or access-related settings for the project, decide whether the documentation is meant for internal teams, external readers, or a mix of both. This choice should match how you plan to publish and who should see the content. 5. Decide how the project will be organized before any pages are created. Choose whether you are building: - one shared knowledge base, - several major content sections inside one project, or - a versioned documentation set with separate releases. 6. Open the members, users, or permissions area for the project and confirm who will manage structure decisions, who will coordinate documentation work, and who will write content. Make sure the people responsible for approvals and publishing already have the right access before the first draft is created. [SCREENSHOT: Project settings screen showing project name, URL slug, default language, and member access areas] A clear workspace definition prevents later cleanup. It also makes the rest of your governance rules much easier to enforce. ## Designing the navigation and content boundaries Once the workspace basics are set, plan the content map your team will follow. In Atloria, this means thinking about the sidebar, parent pages, section landing pages, and how readers will move between guides, reference material, and release information. The goal is to make the structure obvious before writers begin adding pages in different styles or locations. 1. Start by listing the top-level sections you expect to show in project navigation. Common examples in Atloria projects include product guides, setup instructions, API documentation, release notes, policy content, and troubleshooting. Keep the top level broad enough for readers to scan quickly. 2. In the navigation structure or page tree, decide which items should be section containers and which should be actual reading pages. Use parent pages or landing pages for broad topics, and place detailed task or reference pages underneath them. 3. Set a rule for what belongs inside this project and what should be split into a separate project. Use practical boundaries such as: - a different audience, - a separate product line, - a different publishing schedule, - or content that should not be visible to the same readers. 4. Create naming rules for sections and pages. For example, use section names for broad categories and action-based page titles for task content. This keeps the sidebar readable and helps search results make sense. 5. Plan how shared topics will be linked. If a page applies to several sections, choose one main location for it and link to it from related pages instead of copying the same content into multiple places. 6. Decide how related articles should connect across the project. If your team uses cross-links heavily, agree on when to link to onboarding, integration, or policy pages so readers can move between sections without losing context. If you are also working through webhook and delivery planning, keep that material aligned with the structure decisions here rather than rebuilding it in multiple places. For those controls, refer back to [Managing Project Webhooks and Delivery Checks](doc:managing-project-webhooks-and-delivery-checks). [SCREENSHOT: Project page tree or sidebar structure showing top-level sections and nested pages] A strong boundary plan keeps the project from becoming a catch-all workspace that is hard to navigate and harder to maintain. ## Assigning ownership and review responsibilities A well-structured project still breaks down if nobody knows who owns each section. In Atloria, ownership should be visible in the project’s member access, review flow, and page management habits. You do not need a complicated process, but you do need clear responsibility for drafting, reviewing, and publishing. 1. Divide the project into major sections such as onboarding, product guides, integrations, compliance, or release notes. For each section, assign one primary owner who is responsible for keeping that area accurate and current. 2. Open the project’s access or permissions area and confirm who can create drafts, who can review changes, and who can publish updates. These responsibilities should match how your team actually works, not just job titles. 3. Decide how page-level ownership will be recorded. If your team uses an owner field, review assignment, or internal tracking note, make sure every important page has a named person attached to it rather than a shared team label only. 4. Set expectations for review timing. For example, decide which pages need regular review dates and which pages only need review when a release changes. This helps prevent “evergreen” pages from becoming outdated without anyone noticing. 5. Define what happens when a page no longer has an active owner. Your team should know whether the section owner, project lead, or an administrator takes over when content becomes unowned or stale. 6. Clarify how different contributors participate in the workflow: - Writers create and update drafts. - Subject matter experts check technical accuracy. - Editors improve clarity and consistency. - Approvers or publishing leads decide when updates are ready to go live. 7. If your team uses formal review and approval steps in Atloria, align those steps with the people above so there is no confusion about who gives final sign-off. For a deeper walkthrough of review decisions and publishing readiness, use the version and approval guides linked throughout the Project Settings and version management documentation set. [SCREENSHOT: Project members or permissions screen with roles and section ownership notes] Ownership works best when it is simple, visible, and tied to actual screens your team already uses. ## Setting rules for versions, audiences, and publishing This is where governance becomes visible to readers. In Atloria, version settings, audience targeting, and publish state decisions shape what people can see and when they can see it. If these rules are unclear, teams often publish the right content to the wrong readers or leave important updates hidden in draft. 1. Decide whether this project will use versioned documentation. If it will, define which releases should appear in the version selector, such as **v1**, **v2**, or **Latest**. Only create version entries that readers will actually need to switch between. 2. Set a rule for what belongs in a versioned release versus what stays outside versioning. For example, release-specific setup instructions may belong in a version, while company policy or support contact process pages may stay unversioned if they apply everywhere. 3. Review audience settings for the project and decide which pages are: - internal only, - visible to customers, - or limited to a specific audience group. 4. Match those audience decisions to your content structure. If an entire section is internal, keep it grouped clearly so writers do not accidentally mix internal-only pages into customer-facing navigation. 5. Define how your team will use content states. Agree on what **Draft**, **Scheduled**, and **Published** mean in practice. For example: - **Draft** for work in progress, - **Scheduled** for approved content waiting on a release date, - **Published** for content that should appear in live output. 6. Confirm where the project will be published. Depending on your setup in Atloria, this may be a public documentation site, a help center experience, or a private documentation area. Your publishing destination should match both the audience settings and the navigation plan. 7. Before finalizing these rules, preview a few likely reader journeys. Make sure a customer sees customer content, an internal user sees internal material, and version switching does not expose the wrong pages. If you need the detailed setup steps for webhook-related delivery controls, use [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls) instead of repeating those checks here. [SCREENSHOT: Version selector and audience visibility settings in a project] These rules should be written once and reused often so every release follows the same visibility pattern. ## Creating governance rules writers can follow consistently Good governance only works if writers can apply it without guessing. In Atloria, that means turning your planning decisions into repeatable page standards: what metadata to fill in, how to name pages, when to use templates, and how to avoid duplicate content across sections. Start by defining the fields every page should include. A simple standard is easier to enforce than a long checklist, so focus on the items that directly affect search, ownership, and publishing. | Page requirement | What to standardize | Why it matters | |---|---|---| | Title | Use a clear reader-facing page title | Keeps navigation and search results understandable | | Description | Add a short summary of the page | Helps readers identify the right page quickly | | Owner | Assign a named owner | Makes maintenance responsibility clear | | Audience tag | Mark internal, customer, or other audience use | Prevents visibility mistakes | | Version tag | Apply when the page belongs to a release | Keeps versioned content organized | | Review date | Set a review expectation where needed | Helps catch stale content | After that, standardize templates for the page types your team creates most often. Task guides should follow one structure, overview pages another, release notes another, and reference pages another. When writers open a new page, they should already know whether they are creating a landing page, a how-to page, or a reference page. Also agree on rules for reused content. If the same explanation appears in several places, choose one canonical page or shared content source and link back to it rather than maintaining multiple copies. This is especially important for setup instructions, policy language, and recurring product definitions. Finally, document naming conventions for: - page titles, - sidebar labels, - section names, - and URL paths. Use predictable wording so readers can scan the sidebar and know what to expect. For example, action pages should start with verbs, while category pages should describe a topic area. [SCREENSHOT: Example page editor showing title, description, ownership, and visibility-related fields] When writers follow the same rules on every page, review becomes faster and the published project feels consistent. ## Verifying the project setup before teams start publishing Before your team begins publishing regularly, run a final check inside Atloria using real pages, real permissions, and real preview behavior. This step turns your planning rules into a practical test. If something is unclear now, it will become a larger problem once dozens of pages and multiple contributors are involved. 1. Open the project sidebar or content tree and compare it to the structure you planned. Check that top-level sections, parent pages, child pages, and landing pages appear in the right order and use the correct names. 2. Open a sample section and review whether the page layout matches your intended boundaries. Make sure onboarding content, product guides, release notes, and other major areas are not mixed together in ways that will confuse readers. 3. Go to the project’s members or permissions area and confirm access with actual user roles. Verify that writers can create drafts, reviewers can review and approve changes, and publishing rights are limited to the people you selected. 4. Test version behavior by opening content in the project and checking the version selector. Confirm that only the intended releases appear and that pages are assigned to the correct version where applicable. 5. Test audience visibility by previewing content from the perspective of different reader types if that option is available in your workflow. Confirm that internal-only pages stay hidden from customer-facing views and that customer-visible pages appear where expected. 6. Open a sample page in the editor and review its metadata. Check the **Title**, **Description**, ownership details, audience setting, version assignment, and current publish state. This is the fastest way to see whether your governance rules are being followed in practice. 7. Publish or preview a small set of representative pages and review the result as a reader would. Look for broken structure, unclear labels, misplaced pages, or visibility mistakes before the full team starts contributing. [SCREENSHOT: Final project review showing sidebar, page metadata, and preview output] A short verification pass at the start saves a great deal of cleanup later, especially once versions and audience-specific content begin to grow. ## Overview - This guide focuses on planning decisions you should make before large-scale content creation begins in Atloria. - It covers how to define the project workspace, organize the sidebar and section boundaries, assign ownership, and set rules for versions, audiences, and publishing. - It also explains how to create repeatable governance standards for page metadata, templates, naming, and reused content. - The final section helps you verify that your structure, permissions, and visibility settings work correctly before your team starts publishing regularly. - This guide is intended to complement earlier Project Settings documents rather than repeat them: - For project-level setup and website options, see [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options) - For webhook setup, see [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls) - For delivery checks, see [Managing Project Webhooks and Delivery Checks](doc:managing-project-webhooks-and-delivery-checks) ## Prerequisites - You should already have access to a project workspace in Atloria. - You should be able to open project settings, the page tree or sidebar structure, and the project’s member or permissions area. - If your team uses versioned documentation, audience targeting, or controlled publishing, those features should already be part of your project plan. - Gather the people who will make governance decisions before you begin, such as: - the project owner, - documentation leads, - reviewers or approvers, - and the people responsible for publishing. - It helps to complete the earlier setup guides first so the project’s core settings are already in place: - [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options) - [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls) - [Managing Project Webhooks and Delivery Checks](doc:managing-project-webhooks-and-delivery-checks) With those pieces in place, you can use this guide to turn a basic project into a documentation workspace your team can manage consistently over time. ## Checking whether your Git connection needs reauthorization In Atloria, start from the project workspace and open the area where the project’s Git connection is shown. This is the same project-level connection area you used when reviewing connection health in [Reviewing Git Connection Status and Access Health](doc:reviewing-git-connection-status-and-access-health). Look for the connected provider name first so you can confirm whether the project is linked to the expected Git account and source. If the project already has a Git provider connected, Atloria shows that provider in the source connection section along with its current status. A healthy connection appears as connected. A connection that needs attention is typically shown as expired, invalid, disconnected, or with a prompt such as **Reauthorize**, **Reconnect**, or a similar action. If you see one of those prompts beside the current provider, Atloria is telling you that the project remembers the connection, but access is no longer valid. This is different from a project that has never been connected. If there is no provider listed and no existing connection details, you are not reauthorizing an expired connection—you are dealing with a project that does not currently have a Git source linked at all. Before you change anything, review what this project depends on. If the project uses a selected repository, a branch, or source-based update actions, those workflows rely on the current Git connection being active. Reauthorizing usually restores those actions. Disconnecting stops Atloria from using that linked source for the project. [SCREENSHOT: Project Git connection panel showing provider name, connection status, and a Reauthorize or Disconnect action] ## Confirming you can update the project's source connection Before you click **Reauthorize** or **Disconnect**, make sure you are signed in with the right Atloria access level for this project. You need Project Administrator access to manage the project’s Git integration settings. If you can open the project settings area but do not see controls for changing the source connection, your access may be limited, or the page may still be loading the current connection details. Next, confirm which Git provider account you intend to use. This matters most when you have more than one provider account signed in within the same browser. During reauthorization, the provider’s sign-in or consent screen may automatically pick the account already active in that browser tab. If that is the wrong one, Atloria may reconnect the project to an account that does not have access to the repository you expect. It also helps to review the project’s current source details before making changes. Check whether the project is tied to a specific repository and branch. If you disconnect the provider, repository-based actions in that project can stop until the connection is restored or replaced. If you are only refreshing access for the same account, those settings usually remain in place, but you should still note them before proceeding. When you are ready, expect Atloria to open a provider approval screen, a pop-up window, or a redirect page outside the project workspace. That external step is where you confirm access for Atloria. Keep the Atloria project tab open so you can return and verify the result immediately after approval. - Confirm you are in the correct project. - Confirm you have Project Administrator access. - Confirm which Git account should be used. - Review the current repository and branch details before changing the connection. ## Reauthorizing an expired Git provider connection 1. Open the project’s Git integration settings and find the connected provider shown for the project. If Atloria marks the connection as expired, invalid, or disconnected, click **Reauthorize**, **Reconnect**, or the similar action displayed next to that provider. 2. Atloria sends you to the provider’s approval screen. If the provider asks you to sign in, choose the account that should manage this project’s repository access. If more than one account appears, take a moment to verify you are selecting the one that already has access to the repository used by this project. 3. Review the access request on the provider screen and approve it so Atloria can regain repository access. Complete every step in that flow until you are returned to Atloria. If you close the provider window too early, Atloria may continue to show the connection as expired. 4. After you return to Atloria, go back to the project’s source connection area and check the status again. The provider should now show as connected rather than expired or disconnected. If the page still shows the old state, refresh the page once and review the status again. 5. Finally, confirm that the project still points to the expected repository and branch. Reauthorization is meant to restore access to the existing connection, not create a brand-new setup. If the provider is connected but the repository details no longer match what the project should use, review the source settings before continuing with repository-based work. [SCREENSHOT: Reauthorization flow from Atloria to the Git provider approval screen and back to the project connection panel] If you need help recognizing the normal connected state after this step, refer back to [Reviewing Git Connection Status and Access Health](doc:reviewing-git-connection-status-and-access-health). ## Disconnecting a Git provider without losing track of project impact 1. Open the project’s source connection settings in Atloria and locate the current provider. To remove the link safely, use the **Disconnect**, **Remove connection**, or similar action shown in Atloria. Start here rather than removing access only from the provider side first, because Atloria’s own disconnect action updates the project record and makes the change visible in the project workspace. 2. Read the confirmation message carefully before you continue. Atloria may warn that disconnecting the provider will stop repository access and source-based actions for this project. This is the point to pause and confirm whether anyone on your team is currently relying on repository-linked work in the same project. 3. Confirm the disconnect action. Once the provider is removed, Atloria updates the project from a connected source state to a disconnected state. The provider name may disappear from the active connection area, or the status may change to show that no active Git connection is available. 4. After disconnecting, review the project workspace so you understand what changed. Existing project content, documentation records, and previously created project items remain in Atloria. What stops working is the live link to the repository. Any action that depends on Atloria reaching the connected Git source will remain unavailable until you reconnect a provider or set up a new source connection. Use disconnect when you intentionally want to remove the project’s current Git link. If your goal is only to refresh expired access, reauthorization is usually the better choice because it keeps the same project connection in place. [SCREENSHOT: Disconnect confirmation dialog warning about repository access and source-based sync impact] ## Understanding what changes at the project level after reauthorizing or disconnecting Reauthorizing and disconnecting may look similar because both start in the project’s Git connection area, but they affect the project very differently. When you reauthorize the same provider connection, Atloria restores access to the repository that was already linked to the project. In most cases, this means the project keeps its existing source setup, including the selected repository and branch. You are not starting over—you are renewing Atloria’s permission to use the connection that the project already knows about. Disconnecting does the opposite. It breaks the active link between the project and its Git provider. After that, Atloria still keeps the project itself and its existing documentation records, but repository-backed actions for that project stop because there is no longer an approved source connection behind them. If you reconnect using a different provider account, review the source details carefully. Even if the provider name is the same, a different account may not have access to the same repository, or it may expose a different set of repositories and branches. After reconnecting with a different account, check that the project still points to the correct repository and branch before resuming source-based work. A helpful way to think about it is: | Change you make | What it usually means in Atloria | What you should review | |---|---|---| | Reauthorize the same connection | Restores access to the existing project source | Provider status, repository, branch | | Disconnect the provider | Removes the active Git link from the project | Which source-based actions will stop | | Reconnect with a different account | Replaces the access context behind the project connection | Repository selection, branch, source settings | If you are unsure whether you need a simple access refresh or a full replacement of the project’s source connection, compare the current connection state first and then decide which action matches your goal. ## Fixing common problems with reauthorization and disconnecting If you complete the provider approval flow and Atloria still shows the connection as expired, start by refreshing the project integration page. In some cases, the provider approval finished successfully, but the project screen has not yet updated. If the status still does not change, repeat the reauthorization flow and make sure you completed the provider’s final consent step before returning to Atloria. If the wrong Git account becomes connected after reauthorization, the issue is usually caused by an existing provider session in your browser. Sign out of the provider account you do not want to use, return to the project’s Git connection settings in Atloria, and start the reauthorization flow again. When the provider asks you to continue, choose the correct account explicitly rather than accepting the default account automatically. If the **Disconnect** option is missing or does not respond, first confirm that you are signed in as a Project Administrator for that project. Then wait a moment and make sure the project settings page has fully loaded the current source connection details. If the connection area is still loading, Atloria may not yet show the correct actions. If project features stop working after disconnecting, that is usually expected for any repository-dependent workflow. The project still exists, but source-linked actions remain unavailable until you reconnect the provider or set up a new source connection for that project. Common checks: - Refresh the project connection page after reauthorization. - Confirm the provider approval flow was fully completed. - Retry with the correct Git account if the wrong one was used. - Verify Project Administrator access if connection actions are unavailable. - Reconnect the provider if the project needs repository-based features again. ## Overview This guide focuses on two project-level actions in Atloria: restoring access to an existing Git connection and removing that connection from a project. Use it when a project already has a Git provider listed, but the connection is no longer valid, or when you intentionally want to stop using that provider for the project. The most important distinction is the difference between a connection that needs reauthorization and a project that has no active Git connection at all. Reauthorization is for a project that still shows a remembered provider but has lost valid access. Disconnecting is for removing the active link between the project and that provider. If you need help understanding the normal connection status indicators before making changes, review [Reviewing Git Connection Status and Access Health](doc:reviewing-git-connection-status-and-access-health). This guide stays focused on what you do in the project’s source connection area: checking the provider status, confirming you have the right access, completing the provider approval flow, and understanding what changes in the project after you disconnect. It also explains what usually remains in place, such as existing project records, and what stops working, such as repository-backed actions. Use this guide when you need to: - restore an expired or invalid Git connection - confirm you are reconnecting with the correct provider account - safely disconnect a provider from a project - understand the effect of that change on repository-linked project workflows [SCREENSHOT: Project source connection area with provider status, reauthorization action, and disconnect action] ## Prerequisites Before you reauthorize or disconnect a Git integration in Atloria, make sure these conditions are true: - You are signed in to Atloria and can open the correct project workspace. - You have Project Administrator access for that project. - The project already has, or previously had, a Git provider connection shown in its source connection settings. - You know which Git provider account should be used for this project. - You are ready to complete the provider’s sign-in or approval screen outside Atloria if reauthorization is required. It is also helpful to confirm a few project details before you begin: - Review the current provider name shown in the project’s Git connection area. - Check whether the project is tied to a specific repository and branch. - Make sure you understand whether your goal is to refresh access or fully remove the connection. - If multiple Git accounts are signed in within your browser, decide which one should be used before starting the approval flow. If you are not yet comfortable finding the project connection status or identifying whether access is healthy, read [Reviewing Git Connection Status and Access Health](doc:reviewing-git-connection-status-and-access-health) first. If you need broader help with project setup and project-level controls, [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home) gives useful context around where these settings fit inside the project workspace. ## Reviewing the analytics signals that should trigger documentation changes In Atloria, start from the **Analytics & Insights** area in the admin workspace when it is available to your team, and combine that with the project-level analytics views you already use in [Reviewing Documentation Performance Across Projects](doc:reviewing-documentation-performance-across-projects). The goal here is not to look at every number. It is to find the signals that clearly point to a documentation problem you can fix. Review page-level reports first. Focus on pages that show a mismatch between attention and results, such as: - high page views with weak engagement - pages where readers leave quickly - pages that attract traffic but do not help readers continue to the next step - articles tied to repeated support questions Compare the main page signals together instead of reading them one by one: - **Views** tell you whether people are reaching the page - **Bounce rate** helps you spot pages readers leave without exploring further - **Time on page** helps you judge whether readers are skimming, struggling, or finishing quickly - **Task completion indicators** help you see whether the article supports the intended action Then move to search reporting. The most useful fields are: - **Top queries** - **Zero-result searches** - **Query-to-click rate** These help you spot missing terms, unclear page titles, weak headings, or missing troubleshooting content. For example, if readers search for an upgrade error using one phrase but your article uses different wording, the page may exist but still stay hard to find. Before deciding what to change, cross-check the analytics with nearby evidence: - support ticket categories - release issue patterns - repeated escalation themes from support agents - version-related confusion after a release [SCREENSHOT: Analytics report showing page views, exits, search queries, and support-related trends side by side] When the same issue appears in page analytics, search behavior, and support activity, that is usually the strongest signal that the documentation needs an update. ## Classifying findings into content, audience, release, and support actions Once you have a short list of problem pages, sort each finding into the type of action it needs. In Atloria, this step helps you avoid making the wrong fix. A page with high traffic and low engagement does not always need more text. Sometimes it needs clearer audience targeting, version guidance, or better support links. Use **content actions** when readers are reaching the page but not getting through it successfully. These are the most common fixes for pages with strong traffic and weak engagement. Typical content actions include: - rewriting the opening paragraph so the purpose is clear immediately - restructuring headings so the steps are easier to scan - adding missing setup steps or prerequisites - moving troubleshooting details closer to the step where the problem happens Use **audience actions** when one group succeeds and another struggles. If a page performs well for administrators but poorly for end users, or if support agents use a page that was written for customers, the issue is often targeting rather than quality. In that case, improve: - navigation labels - role-specific entry points - audience labels on landing pages - separate paths for different reader types Use **release actions** when analytics show version confusion. Common signs include: - spikes in searches right after launch - repeated visits to upgrade pages - readers landing on outdated instructions - support volume increasing after a release These findings usually point to missing release notes, weak version banners, unclear compatibility guidance, or missing known issues content. Use **support actions** when the same issue keeps appearing in escalations or long support conversations. That usually means the internal knowledge base needs: - symptom-based troubleshooting - decision trees - issue-specific notes - direct links from support workflows to the right article section A simple way to sort findings is with a tracker like this: | Finding | Best action type | Typical update | |---|---|---| | High traffic, low engagement | Content | Rewrite intro, reorder steps, add missing details | | Good results for one role, poor results for another | Audience | Split content path, relabel navigation, add role cues | | Post-release confusion or version spikes | Release | Add version banner, release notes, known issues | | Repeated escalations or long support handling | Support | Add troubleshooting flows and support-facing notes | ## Turning page analytics into concrete content updates When a page clearly needs a content fix, open the page performance view in Atloria and choose one article to work on first. Pick a page with a strong signal, such as high views combined with low completion, or a page where readers often leave after the same section. This keeps your work focused on pages that can produce visible improvement. 1. Open the page performance report and select the target article. Look for pages with high traffic, high exits, or weak completion signals. If several pages qualify, start with the one tied to the most important workflow, such as setup, publishing, approvals, or version release. 2. Review the article structure against the behavior signals. Check the page title, the main heading, the table of contents, callout blocks, screenshots, and the order of the steps. If readers drop off early, the opening may be too vague or missing prerequisites. If they leave midway, the problem is often a missing step, unclear instruction, or a gap between headings and what readers searched for. 3. Match the update to the signal: - Add prerequisites when readers exit before starting the task - Add screenshots when readers fail at a specific step repeatedly - Expand troubleshooting when the page is linked to support-heavy issues - Rename headings when search terms do not match the words on the page - Break long sections into shorter procedures when readers stop halfway through 4. Record the planned update in your editorial tracker so the work does not disappear after the analytics review. Use a tracker with fields like these: | Field | What to record | |---|---| | Page | The article you are updating | | Issue type | Low completion, high exits, search mismatch, support-heavy topic | | Proposed update | What you will change on the page | | Owner | Who is making the update | | Review date | When you will check results again | [SCREENSHOT: Page analytics view beside an editorial tracker with issue type, owner, and review date] This approach turns a vague result like “this page underperforms” into a specific edit you can publish and measure. ## Adjusting audience targeting when the wrong readers reach the page Sometimes the content is accurate, but the wrong people are landing on it. In Atloria, you can usually spot this by comparing referral sources, entry pages, and any available role or persona filters in your analytics views. If a page meant for administrators is attracting end users, or a support-focused troubleshooting article is being used as customer-facing guidance, the fix should focus on audience targeting. 1. Confirm who is reaching the page. Check the entry page, referral source, and any audience or role filters available in your analytics reports. A page that performs poorly may simply be attracting readers who should have started somewhere else. 2. Make the intended audience obvious before the article opens. Update navigation labels, landing page copy, and page titles so readers can tell whether the content is for administrators, end users, or support teams. If the label is too broad, readers often click into the wrong article and leave quickly. 3. Split mixed-purpose content when one page serves different roles. For example, if one article combines customer setup instructions with internal diagnostic steps, separate those into distinct pages or clearly separated sections. Readers should not have to scan past unrelated guidance to find the path that applies to them. 4. Add audience cues inside the article itself. Use clear labels such as: - **Who should use this** - **Prerequisites** - **Permissions required** - **Use this procedure if** These cues help readers decide quickly whether they are in the right place. [SCREENSHOT: Documentation page showing role-specific labels, prerequisites, and separate navigation entries] Audience targeting updates are especially useful when a page gets steady traffic but inconsistent outcomes. If one reader group succeeds and another does not, changing the wording, labels, and entry points often works better than rewriting the full article. If you need a broader approach to audience structure, use this together with [Applying Audiences to Documentation Structure and Content Decisions](doc:applying-audiences-to-documentation-structure-and-content-decisions). ## Using analytics to improve release readiness and support coverage Analytics become especially valuable around releases, because they show where readers hesitate, search repeatedly, or return to the same guidance after launch. In Atloria, compare pre-release and post-release patterns to see whether your documentation prepared readers properly or left gaps that support teams now have to fill. 1. Review version-specific search activity and traffic spikes. Look for sudden increases in visits to upgrade instructions, compatibility topics, migration steps, and known limitation pages. Repeated searches around the same release term usually mean readers cannot find the right version guidance quickly enough. 2. Check whether readers are revisiting the same release-related pages several times. That often signals uncertainty rather than success. If readers keep returning to upgrade content, they may need clearer release notes, a checklist, or a better explanation of what changed. 3. Create or update release-readiness content based on what the analytics show. The most common assets to improve are: - release notes - upgrade checklists - compatibility tables - known issues pages - version banners on affected articles 4. Compare support activity with documentation usage. If support tickets, escalation tags, or agent conversations cluster around the same issue, check whether the internal knowledge base already covers it. If it does not, add support-facing content that helps agents move faster and answer consistently. Prioritize support updates such as: - symptom-based troubleshooting pages - issue triage flows - links from support macros to exact article sections - internal notes for recurring release problems [SCREENSHOT: Release-related analytics showing traffic spikes alongside support issue trends] This is where analytics stop being just reporting and start guiding operational work. If a release creates confusion, the right response is not only to update the public documentation, but also to strengthen the internal support material that agents rely on during the same period. For related release workflows, connect this work with [Preparing a Version for Final Release Review](doc:preparing-a-version-for-final-release-review). ## Validating that your documentation changes improved the right outcomes After you publish updates in Atloria, return to the same reporting window and measure the exact outcomes you were trying to improve. Do not switch to a different report or a different time frame unless you have to. The cleanest comparison comes from checking the same page, the same search terms, and the same support topic before and after the change. 1. Reopen the original page and search reports. Check whether the updated article shows better search success, fewer exits, stronger task completion signals, or lower support demand. The metric you watch should match the problem you were fixing. 2. Watch for misleading improvements. A traffic increase alone does not prove the page is better. Release-week spikes, seasonal usage, and URL changes can all distort the numbers. If a page moved or was renamed, make sure you are comparing the correct article history. 3. If traffic improves but outcomes do not, revisit the diagnosis. The original issue may not have been content clarity. It may have been: - an audience mismatch - release confusion - weak troubleshooting depth - poor navigation into the article 4. Add the page back into a recurring review cycle if the result is still unresolved. Set an owner, a review date, and a threshold that tells your team when the page should return to the analytics queue. A simple review rhythm might include: - weekly checks for release-related pages - monthly checks for high-traffic evergreen content - scheduled follow-up after major edits - shared ownership between documentation and support leads [SCREENSHOT: Before-and-after analytics comparison for an updated documentation page] If the numbers improve in the right place, keep the change and move to the next priority. If not, refine the action and test again. That same habit of checking outcomes against the original problem is what turns analytics into a repeatable documentation improvement process. ## Overview Atloria gives you several places to spot documentation problems, but the real value comes from turning those signals into specific actions. This guide focuses on that last step: deciding what to change after analytics reveal weak content performance, audience confusion, release friction, or support knowledge gaps. Use this workflow when you already know how to review project and cross-project reporting and need to decide what to do next. Instead of treating analytics as a dashboard you glance at occasionally, use it as a working list for documentation updates. In practice, that means identifying a problem page or topic, classifying the issue, making the right type of change, and then checking whether the result improved. This guide covers how to: - identify the analytics signals that deserve action - sort findings into content, audience, release, or support work - turn page-level metrics into concrete edits - adjust navigation and labels when the wrong readers reach a page - improve release-readiness content and support-facing knowledge - validate whether your updates actually solved the problem You do not need every report in Atloria to use this process well. A smaller set of reliable signals is usually enough: - page performance trends - search behavior - version-related traffic changes - support-linked issue patterns If you need help reading those reports first, go back to [Reviewing Documentation Performance Across Projects](doc:reviewing-documentation-performance-across-projects) and [Using Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements). Those guides explain how to identify patterns; this one shows how to turn those patterns into editorial, audience, release, and support actions your team can assign and track. ## Prerequisites Before you use this workflow in Atloria, make sure you have access to the reporting and content areas needed to both review the issue and act on it. You do not need every admin feature, but you do need enough visibility to connect analytics with the pages, versions, and support topics involved. You should already be able to: - open the relevant **Analytics** views for your project or admin workspace - review documentation pages and their structure - identify the affected version, release, or audience path - update content directly or hand changes to the person who owns the page - compare documentation trends with support or release patterns used by your team It also helps if you already have: - an editorial tracker or shared work list - a clear page owner for major documentation areas - a release review process for version-specific content - a way to capture recurring support issues Have these inputs ready before you start: - the page or topic you want to review - the date range you are comparing - the key metric that triggered concern - any related search terms, support themes, or release notes - the team member responsible for the update This guide works best after you have already reviewed broader performance patterns in Atloria. If you have not done that yet, start with: - [Analyzing Documentation Performance Across Projects](doc:analyzing-documentation-performance-across-projects) - [Using Analytics Reporting Across Enterprise and Project Views](doc:using-analytics-reporting-across-enterprise-and-project-views) - [Reviewing Documentation Performance Across Projects](doc:reviewing-documentation-performance-across-projects) From there, you can move directly into action planning: choosing the right fix, publishing the update, and checking whether the change improved the outcome you were targeting. ## Checking what parser support means before you upload code In Atloria, **parser availability** means the code parsing workspace can recognize the **programming language** you plan to upload and, when relevant, the **framework** used in that codebase. You usually confirm this before you move forward with **repository selection**, **source file upload**, or the action that starts parsing. If you skip this check, you can end up uploading code that Atloria cannot fully interpret. A quick support check helps you answer two separate questions: - Is the **language** listed as supported in the parser selection area? - If the project depends on a specific **framework**, is that framework also available for the selected language? Those two checks matter because **language support** and **framework support** are not always the same. Atloria may support a language in a general way, while only supporting certain frameworks built on that language. For example, you might see a language available in the list, but not see the framework your team actually uses. In that case, parsing may still be possible, but the results may be more limited than expected. Use the parser selection screen as your decision point. Before you click the button that continues to upload or connect code, compare the options shown in Atloria with the stack you already identified for the project. [SCREENSHOT: Parser selection screen showing language list and framework options] Checking support first helps you avoid: - **Failed parsing attempts** - **Incomplete analysis results** - **Choosing the wrong parser for the repository** - **Rework during project onboarding** If you already reviewed support coverage at a higher level, use that earlier planning work here rather than repeating it. For broader evaluation guidance, see [Using Language Support Information During Project Planning](doc:using-language-support-information-during-project-planning). ## Gathering the language and framework details for your project Before you open the upload flow in Atloria, collect the exact stack details for the codebase you want to parse. This is especially important when a repository includes more than one language or when different folders use different tools. The goal is to identify what Atloria should parse **first**, not to describe every technology used across the entire project. Start by identifying the **primary language** in the part of the repository you plan to upload. In mixed repositories, the main language is usually the one used in the largest portion of source files or in the module you want documented first. If your team works in a monorepo, do not assume one language choice will fit every folder. Then confirm the **framework or runtime** that shapes how the code is organized. This might be a web framework, mobile framework, or build-oriented framework. The framework matters because Atloria may show different parser options depending on the language you choose. Useful places to verify this before upload include: - **Project manifest files** - **Dependency files** - **Workspace or package files** - **Folder structure and module names** - **Existing project setup notes** As you review those files, focus on what is actually present in the repository rather than what the team informally calls the project. A team may describe a codebase by a broad technology label, while the uploaded folder uses a different framework or no framework-specific structure at all. If the repository contains several supported stacks, decide which one will be parsed in the first pass. That may mean narrowing the upload to: - One **repository** - One **module** - One **service** - One **folder path** [SCREENSHOT: Project workspace showing upload area before parser selection] This preparation makes the parser selection step much easier because you can match Atloria’s labels to the real contents of the code you are about to upload, instead of guessing after the upload has already started. ## Reviewing supported languages and frameworks in the parser selection interface When you reach the parser selection step in Atloria, use the options on that screen as the final confirmation before upload. This is where you check whether the stack you identified earlier appears exactly as an available choice. Do not rely on memory or team shorthand here—use the names shown in the interface. Look first for the **language list**. This list tells you which languages Atloria can currently parse in that workflow. Select the language that matches the code you plan to upload. After choosing it, check whether Atloria also shows a **framework field** or **framework selector**. If it does, review the available framework entries tied to that language. As you compare your project stack with the screen, pay attention to support signals such as: - **Enabled options** you can select - **Unavailable entries** that cannot be chosen - **Compatibility messages** shown after a language is selected - Changes in the **framework list** when you switch languages These details help you confirm whether Atloria supports the exact combination you need. A close match is not enough. If your team uses one framework and Atloria shows a different framework with a similar name, treat that as a separate option rather than assuming it will work the same way. A careful review at this stage helps prevent two common mistakes: - Choosing a supported **language** and assuming every framework under it is also supported - Picking a framework that sounds familiar but does not match the repository you are uploading [SCREENSHOT: Language dropdown expanded with a framework selector below it] If the screen shows only a language choice and no framework field, use that as a sign to confirm whether your upload will rely on **language-only parsing**. If you need more context on how parser coverage affects results, refer to [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility) and [Evaluating Supported Languages and Framework Coverage](doc:evaluating-supported-languages-and-framework-coverage). ## Deciding how to proceed when your stack is fully supported, partially supported, or unavailable After checking the parser selection screen in Atloria, place your project into one of three support situations: **fully supported**, **partially supported**, or **unavailable**. This gives you a clear basis for deciding whether to continue to upload or pause and adjust your plan. When your stack is **fully supported**, both the **language** and the **framework** appear as available choices in the parser selection area. In that case, you can move ahead with confidence to the next step, such as selecting the repository or uploading source files. This is the best case for teams expecting framework-aware parsing results. When your stack is **partially supported**, the **language** appears in the list but the **framework** does not. In this situation, you need to decide whether **generic language parsing** is acceptable for the first pass. That decision usually depends on what you need from the parsing results and whether missing framework-specific interpretation would affect your documentation scope. When your stack is **unavailable**, neither the language nor the framework appears as a usable option. If that happens, stop before uploading code. Uploading anyway can create confusion, wasted setup time, and expectations that Atloria will produce results it cannot support for that stack. Use these support states to guide planning conversations: - **Fully supported**: proceed with normal onboarding and parsing expectations - **Partially supported**: note possible limits in output and review scope carefully - **Unavailable**: pause the upload plan and reconsider what codebase to parse first [SCREENSHOT: Parser selection screen showing available and unavailable support states] Support status also affects timelines. If parsing is central to project onboarding, a partially supported or unavailable stack may change what documentation can be generated first, which teams can review results, and what stakeholders should expect during setup. Treat this as a planning decision before any parsing job begins, not as something to sort out after upload. ## Recording parser availability decisions for project planning Once you confirm support in Atloria, write down the decision where your team tracks project setup details. This keeps future uploads consistent and helps other team members understand why a particular parser choice was made. The most useful notes are short, specific, and tied to the exact repository or folder being onboarded. Record the following details from the parser selection step: - The selected **language** - The selected **framework**, if one was available and chosen - The observed support status: **fully supported**, **partially supported**, or **unavailable** - The repository, module, or folder included in the first parsing pass If Atloria supports only the language and not the framework, note that clearly. That distinction matters later when someone revisits the project and assumes framework-aware parsing was used. A simple note such as “language-only parsing selected for first upload” can prevent confusion during review. It also helps to document anything intentionally left out of the first upload, such as: - Modules using a different stack - Folders with unsupported frameworks - Parts of a monorepo postponed to a later phase - Repositories excluded from the initial onboarding scope [SCREENSHOT: Project notes or planning document alongside parser selection choices] When parser availability affects scope or schedule, include any approval details from the people overseeing project setup. In many teams, that means noting whether a **Project Administrator** or other decision-maker agreed to proceed with language-only parsing, delay certain modules, or narrow the onboarding target. These notes become especially valuable when the project moves from setup into documentation work. They give reviewers context for why some reference coverage appears first and why other areas were intentionally deferred. For related onboarding decisions, see [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) and [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace). ## Fixing common parser availability checks before starting an upload Most parser availability problems in Atloria come from checking the wrong stack, checking the wrong screen, or treating a mixed repository as one upload target. Before you start an upload, use the parser selection area to resolve these issues while changes are still easy to make. If the **selected language does not appear** in the parser list, first confirm that you are on the correct upload or parser selection screen. Then verify the project’s primary language again using the repository contents you plan to upload. In mixed codebases, users often choose the language of the overall product instead of the language used in the specific folder or module being parsed. If the **framework option is missing after choosing a language**, do not assume Atloria failed to load it. Recheck whether that framework is actually used by the repository. Teams sometimes describe a project by its deployment tooling, hosting setup, or company standard, even when the uploaded code does not use that framework directly. If the **repository contains multiple stacks and support looks inconsistent**, break the validation into smaller parts. Instead of treating the whole repository as one parser target, review support by: - **Module** - **Service** - **Folder** - **Repository segment planned for first upload** This usually makes the parser choice much clearer. If users are **ready to upload despite unclear support status**, pause the workflow. It is better to delay the upload than to start parsing with the wrong expectations. A quick confirmation in the parser selection screen can save time that would otherwise be spent reviewing weak or incomplete results. [SCREENSHOT: Upload flow paused at parser selection while reviewing language and framework choices] For additional help comparing support options before upload, use [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage) and [Evaluating Language Support Before Parsing Code](doc:evaluating-language-support-before-parsing-code). ## Overview Use this document when you are at the point in Atloria where a code upload is about to begin and you need to confirm whether parsing is likely to work for the stack you selected. The focus here is not broad research into every supported technology. Instead, it is the practical check that happens immediately before you continue from parser selection to repository connection or file upload. The main idea is simple: confirm the exact **language** and, when relevant, the exact **framework** shown in Atloria before you upload code. That check helps you avoid starting a parsing workflow with the wrong assumptions. This guide is most useful when: - You are onboarding a new project into Atloria - You are preparing the first parsing pass for a repository - Your repository includes more than one language or framework - Your team needs to decide between framework-aware parsing and language-only parsing - Project scope depends on what Atloria can parse right now The sections above walk through the key decisions in order: - Understand what **parser availability** means in Atloria - Gather the real stack details from the codebase - Review the **language** and **framework** options shown in the parser selection interface - Decide whether the stack is fully supported, partially supported, or unavailable - Record that decision for project planning - Fix common issues before clicking through to upload If you need the broader planning context behind these checks, use the earlier Supported Languages documents rather than repeating that evaluation work here, especially [Using Language Support Information During Project Planning](doc:using-language-support-information-during-project-planning). From here, the next practical step is usually the upload workflow itself in [Uploading and Parsing Code in the Workspace](doc:uploading-and-parsing-code-in-the-workspace). ## Prerequisites Before using this parser availability check in Atloria, make sure you have enough project information to compare your codebase with the options shown in the parser selection screen. You do not need deep technical expertise, but you do need a clear understanding of what you are about to upload. Have these items ready before you begin: - Access to the **project workspace** where the code upload will start - The repository, source files, or code location selected for the first parsing pass - The project’s primary **language** - The project’s **framework**, if one is relevant to how the code is structured - Basic visibility into project files that confirm the stack, such as dependency or manifest files - A decision-maker available if support status could change onboarding scope or schedule It also helps if you already completed the earlier support review work covered in the previous documents in this section. In particular, you should already be familiar with: - How Atloria presents supported languages - How parser coverage differs from full stack compatibility - How support information affects project planning If you have not done that review yet, start with [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage) and [Evaluating Language and Framework Support in Atloria](doc:evaluating-language-and-framework-support-in-atloria). You are ready to use this guide when you can answer these questions before upload: - What codebase, module, or folder are we parsing first? - What language does that code actually use? - Does that code rely on a specific framework? - Are we prepared to proceed if Atloria offers language-only support? With those details in hand, you can use the parser selection screen in Atloria as a reliable checkpoint before starting the upload. ## Preparing the release workspace and confirming access to analytics, audit history, and exports Before you start validation, make sure you are working from the correct project and release context in Atloria. If you have already moved content into a versioned release, use the same release candidate you prepared in [Moving Document Updates into Versioned Releases](doc:moving-document-updates-into-versioned-releases). Open the project workspace, then confirm the release header shows the version or release label you intend to review. This matters because analytics, activity records, and exported files are only useful if they match the exact release you plan to share. 1. Open the target project in Atloria and go to the release or version you want to validate. 2. Check the page header for the active release label, version name, or project context so you know you are reviewing the right content set. 3. Open the **Analytics** area for that project or release and confirm you can view the dashboard. 4. Open the **Audit History** or activity log view and make sure entries load for the same project. 5. Find the **Export** action in the project view, release view, or related toolbar and confirm export options are available. 6. Decide the scope of your review before you continue. For example, you may be validating one documentation version, one release branch, or one published set. 7. Confirm the export outputs you need are available from the menus you can access, such as a metrics export, an audit log export, or a documentation package export. [SCREENSHOT: Project release view showing the release label in the header, with Analytics, Audit History, and Export actions visible] If one of these areas is missing, stop and confirm you are in the correct workspace. In Atloria, release checks are most reliable when the same project and release context is used across all three areas. ## Reviewing project analytics to confirm the release is ready to share Use the Analytics view to judge whether readers are finding and using the documentation the way you expect. In Atloria, the **Analytics & Insights** screen is available from the admin area, and project analytics may also be available from the project context depending on your workspace. When you open analytics, start by checking the filters at the top of the screen. If there is a date range, release filter, version selector, or similar control, set it before reading any numbers. That keeps your review focused on the release candidate instead of older project activity. 1. Open **Analytics & Insights** from the relevant project or admin workspace. 2. Set the date range, release filter, version selector, or other visible filter so the dashboard reflects the release you are validating. 3. Review the summary cards and charts for signs that the updated documentation is performing as expected. 4. Look closely at reader-facing patterns such as page views, search activity, completion trends, or pages with noticeably low engagement. 5. Compare newly updated pages with pages that were not changed in this release. A large difference can point to missing links, unclear titles, or content that still needs revision. 6. Narrow the dashboard using any available filters, segment controls, or module selectors so you are reviewing only the documentation set included in this release. 7. Note any unusual results that may need a second check in the audit trail, such as a sudden drop in engagement or unexpected search behavior. [SCREENSHOT: Analytics dashboard with date range and release filters highlighted] Treat analytics as evidence of release readiness, not just a traffic report. If readers are not reaching important pages, or if search behavior suggests they cannot find updated content, pause before approving the release. Those signals often become easier to explain once you compare them with the activity records in the next step. ## Checking audit history to verify what changed in the release After reviewing analytics, switch to the **Audit History** or activity log for the same project. This view helps you confirm exactly what changed, who changed it, and when the change happened. The most useful audit review is narrow and deliberate. Instead of scanning the full timeline, filter the records so they match the same release, date range, and content scope you used in analytics. That makes it much easier to verify whether the final approved edits are the ones actually included in the release. 1. Open the **Audit History** or project activity log from the same project or release context. 2. Apply filters such as release version, date range, user, or content item so the list matches the release candidate under review. 3. Review entries for important release actions, including page edits, metadata changes, permission updates, publication events, and export-related actions if they appear in the log. 4. Open individual audit entries when more detail is available and check the timestamp, the user name, and the affected content item. 5. Confirm that the latest approved changes appear in the timeline and that they happened before the release was prepared for sharing. 6. Look for unexpected activity after final review, such as a late page edit, a visibility change, or a permission update that could affect what readers see. 7. Record any entries that need clarification before release approval. [SCREENSHOT: Audit History view filtered by date range and release, with entry details panel open] A clean audit trail should support the release story you expect: the right pages were updated, the right people made the changes, and no unplanned edits appeared afterward. If the timeline does not match the release you reviewed in analytics, adjust the filters and check the project header again before moving on. ## Cross-checking analytics and audit records before approving the release This is the point where release validation becomes a decision rather than a review. Analytics tells you how the documentation is being used or discovered, while the audit trail tells you what changed behind that result. In Atloria, you should compare both views using the same release label, page title, and date range whenever possible. If you switch between broad project data and release-specific activity, it becomes much harder to judge whether a problem belongs to the current release or to older content. 1. Keep the same project and release selected while moving between **Analytics** and **Audit History**. 2. Match unusual analytics patterns to related activity records. For example, if a page suddenly loses engagement, check whether it was renamed, moved, hidden, or replaced in the audit timeline. 3. Use the same page title, release label, or documentation item name in both views so you are comparing the same content. 4. Check whether search activity points to pages that were recently edited or replaced. 5. Confirm that the pages receiving attention are the pages you intended to promote in the release. 6. Decide whether the release is ready based on combined evidence: analytics should support discoverability and usefulness, and audit history should confirm the approved change set. 7. Write down any mismatch that requires follow-up before sharing the release. A few examples of discrepancies worth pausing on: - Analytics shows traffic going to an older page, but the audit trail shows a replacement page was published. - Search activity increases for a topic, but the audit trail shows the related page title or metadata changed recently. - A key page has very low engagement, and the audit trail shows it was moved or updated late in the cycle. - Audit records show permission or visibility changes that may explain why readers are not reaching the intended content. When both views support the same conclusion, you have stronger evidence that the release is ready to share with stakeholders. ## Exporting validation evidence for stakeholders and release records Once the release checks are complete, export the evidence you need for review, approval, or archiving. In Atloria, use the **Export** action from the project view, analytics view, or related release area, depending on where the export options are available to you. The most important part of this step is applying filters before you export. If you export first and filter later, you may end up sharing files that include unrelated projects, older releases, or extra activity that confuses reviewers. 1. Open the **Export** menu from the current project, release, or analytics view. 2. Choose the export type that matches your review need, such as a metrics export, an audit log export, or a packaged documentation export. 3. Before generating the file, apply the release-specific filters shown on screen, including the version, date range, page selection, or activity scope. 4. Create separate exports when stakeholders need both performance evidence and a change record. 5. Download each file and confirm the contents reflect the release candidate you reviewed. 6. Save the files using the release identifier shown in Atloria so each export can be traced back to the correct version. 7. Share the exported files with reviewers or store them with your release records according to your team’s process. [SCREENSHOT: Export menu open with release-specific filters visible before download] A simple naming pattern helps when you are handling multiple release candidates. Include the visible release label from Atloria in each saved file name so reviewers can match the export to the exact candidate under discussion. If you are exporting both analytics and audit evidence, keep them as separate files unless your team has a standard package format for release reviews. ## Fixing common issues when analytics, audit data, or exports do not match the release When the numbers, activity records, or exported files do not line up, start with the visible filters and the release label in the header. In Atloria, mismatches usually come from reviewing the right project with the wrong date range, or the right release with the wrong export scope. Before you assume the release data is incorrect, confirm that every screen is pointed at the same version and time window. Use the checks below to resolve the most common problems: - **Analytics does not reflect the current release** - Reopen the **Analytics** view and verify the selected date range. - Check for a release filter, version selector, or project scope control. - Make sure you are not looking at full project history when you only need the current release. - **Audit history is missing expected changes** - Review the filters in **Audit History**. - Expand the date range if the final edits happened earlier than expected. - Check whether the log is filtered to the wrong user or content item. - **Exported files contain too much or too little information** - Return to the source screen and reapply the version, page, and date filters before exporting again. - Confirm you selected the correct export type for what you need to prove. - If you need both performance data and change records, export them separately. - **Stakeholders question whether the export is current** - Compare the export timestamp with the latest visible audit entry. - Check the active release label in the project header. - Regenerate the export if the file was created before the most recent approved change. [SCREENSHOT: Side-by-side view of release header, filters, and export timestamp for validation] If the mismatch remains after you verify filters and release context, repeat the review from the project header outward: release label first, then analytics filters, then audit filters, then export settings. That order usually reveals where the scope changed. ## Overview This document focuses on one release task in Atloria: proving that a documentation release is ready to share. Instead of relying on a single approval signal, you use three connected areas of the workspace together: - **Analytics** to understand how readers are finding and using the documentation - **Audit History** to verify what changed, who changed it, and when - **Export** actions to capture evidence for stakeholders, release records, or approval discussions This workflow is most useful after your content has already been prepared as a release candidate. If you still need to move edits into a versioned release, return to [Moving Document Updates into Versioned Releases](doc:moving-document-updates-into-versioned-releases) before using the steps here. The release validation process in Atloria is not just about checking whether pages exist. You are confirming that the intended pages are the ones readers can discover, that the final approved edits are the ones recorded in the activity timeline, and that you can produce clear evidence for anyone reviewing the release. This is especially helpful when a documentation manager, project administrator, or stakeholder needs a record of why a release was approved. You will work across project and admin views that expose **Analytics & Insights**, **Security & Audit** or **Audit History**, and **Export** actions. Some workspaces may show these tools in different navigation areas, but the goal stays the same: keep the release scope consistent across all three. When the release label, filters, and exported files all match, you have a dependable release record that can support publication, review, and follow-up decisions. ## Prerequisites Before you begin, make sure the following conditions are true in Atloria: - You can sign in and open the target project workspace. - The documentation release already exists as a version, release candidate, branch-based release, or published set that you can identify by name in the header. - You know which release you are validating and which pages or documentation area belong to that release. - You can open the **Analytics** area relevant to your project or admin workspace. - You can open **Audit History**, the activity log, or the related audit view for the same project. - You can access the **Export** action from the project, release, or analytics context you are using. - You know what evidence your reviewers need, such as analytics results, audit records, or a documentation package export. It also helps to have these details ready before you start: | Item to confirm | Why it matters | |---|---| | Release label or version name | Keeps analytics, audit review, and exports tied to the same candidate | | Date range for review | Prevents older activity from being mixed into current release checks | | Pages or content scope | Helps you focus on the exact documentation set being approved | | Reviewer expectations | Tells you whether to export metrics, audit records, packaged docs, or all three | If you need help getting into Atloria or moving through sign-in and session access, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). After you finish the validation workflow in this guide, continue with [Coordinating Technical Reference and Authored Content Workflows](doc:coordinating-technical-reference-and-authored-content-workflows). ## Understanding What Technical Reference Pages Add to Authored Documentation When you write or review documentation in Atloria, you usually work with two different content sources at the same time: - **Authored documentation pages**, such as task guides, setup instructions, onboarding content, and conceptual pages - **Technical reference pages**, which list structured details such as API operations, configuration keys, command options, schemas, response fields, and similar reference material These two sources serve different purposes. Authored pages explain **what someone is trying to do**, **when to do it**, and **which steps matter most**. Technical reference pages provide the exact details behind those workflows, including the official names and allowed values that need to stay accurate. A Technical Writer usually checks a technical reference page while drafting instructions that mention exact details. For example, if a guide tells readers to send a request, run a command, add a configuration value, or use a specific field name, the writer should confirm those details against the matching reference entry before publishing. This is especially useful for checking endpoint paths, command flags, request fields, response properties, and exact product terminology. A Documentation Manager uses the same reference pages differently during review. Instead of checking one sentence at a time, they compare the reference coverage with the published guides to spot gaps. That often reveals features that exist in the reference but are not explained anywhere in the authored documentation, or naming differences between a workflow guide and the official reference entry. The goal is not to turn every guide into a long reference page. In Atloria, the best documentation combines both: the guide explains the workflow, and the technical reference page confirms the exact details. Used together, they help you validate terminology, close content gaps, and keep documentation complete without making task-based content harder to read. [SCREENSHOT: An Atloria documentation page open beside a technical reference page for the same feature] ## Locating the Reference Details You Need While Drafting When you are editing a documentation page in Atloria, start by identifying the parts of the draft that need exact verification. These are usually the places where the text mentions something readers must enter, select, call, or copy exactly. Common examples include command syntax, option names, request body fields, environment variables, response fields, and labels that appear in the product. Once you know what needs checking, open the matching technical reference page for that feature area. If you are already familiar with browsing reference sections, use the same navigation approach covered in [Browsing Technical Reference Sections and Entities](doc:browsing-technical-reference-sections-and-entities). The key difference here is your purpose: you are not browsing to learn what exists, but to confirm a specific detail before updating a guide. Use the navigation tools on the reference page to jump directly to the right item. Depending on the page, this may include: - A page table of contents - A search box - An endpoint list - A command list - A schema section - A configuration table - An index of documented items Match your guide text to the exact reference entry. If your draft mentions an API call, compare it with the operation heading on the reference page. If it mentions a command, check the usage section and option list. If it mentions a field, confirm the spelling and structure in the parameter table or schema area. Before you return to the draft, capture the canonical term exactly as shown. Pay attention to capitalization, hyphenation, spacing, and whether the name is singular or plural. Small differences can create confusion, especially when a guide mixes a conversational label with a formal reference term. [SCREENSHOT: A technical reference page showing a search box, section navigation, and a detailed entry highlighted] ## Using Reference Pages to Validate Terminology and Naming One of the most valuable uses of technical reference pages in Atloria is terminology validation. Even strong workflow content can become unreliable if it uses names that do not match the official reference pages. During writing and review, compare the terms in your guide against the names shown in reference headings, field tables, property lists, value lists, and command sections. This matters most when a guide uses a friendly or marketing-style label, but the technical reference page presents a different official name. For example, a guide might describe a feature in broad language, while the reference page shows the exact resource name, configuration key, or command wording readers will actually see in technical documentation. When that happens, use the official reference term as your source of truth and adjust the guide so the wording stays consistent. You should also standardize how literal names appear in prose. If a guide mentions a request field, query parameter, header, or environment variable, keep that name in a literal style instead of rewriting it into plain language. Readers need to recognize the exact item when they move from the guide to the reference page. A sentence can still be easy to read while preserving the exact field or option name. Technical reference pages are also useful for catching outdated names. If an older authored page still mentions a removed option, a legacy endpoint, or a previous property name, compare it with the current reference entry. If the old term no longer appears there, the guide likely needs revision. A practical review habit is to scan for these mismatch types: - Different capitalization for the same item - Singular wording in one place and plural wording in another - Older labels that no longer appear in current reference pages - Natural-language rewrites of exact field or option names - Multiple names used for the same concept without clarification Using the reference page as the naming standard keeps Atloria documentation easier to trust, search, and maintain. ## Filling Documentation Gaps from APIs, Commands, and Configuration References Technical reference pages are often the fastest way to find missing documentation coverage. While guides focus on workflows, reference pages show the full set of available details. In Atloria, that makes them useful for spotting items that exist in the product documentation set but are not yet explained in authored content. As you review a reference page, look for entries that appear important to real users but are missing from task-based pages. These may include newly added request parameters, command options, response fields, webhook events, or configuration settings. The question is not whether every item deserves its own guide paragraph. Instead, ask whether a user following a workflow would need to know that the item exists, when to use it, or how to choose between available options. A helpful way to decide what belongs where is to separate **workflow guidance** from **full reference detail**: - Put required steps, decision points, and common choices in authored guides - Leave exhaustive lists, complete schemas, and long option tables in the technical reference page - Add a direct link from the guide to the exact reference section when readers may need advanced detail For example, a guide should explain which option a user must choose during setup and why it matters. It does not need to repeat every possible option if the reference page already lists them clearly. In that case, link to the exact operation, command section, schema definition, or configuration row that expands the detail. This approach also improves completeness without overloading the guide. If the reference page lists a setting that changes behavior in an important workflow, add a short explanation in the guide about when someone would use it. If the setting is purely advanced detail, keep the guide focused and point readers to the reference entry. [SCREENSHOT: A task guide with a link to a specific technical reference section for advanced details] ## Reviewing Coverage Across the Documentation Set Technical reference pages can also act as a coverage checklist for your documentation set. Instead of reviewing one guide at a time, compare the major categories shown in the reference area with the guides already published in Atloria. This helps you see whether important topics are fully supported by workflow content or only listed in reference form. Start by grouping the reference content into broad categories such as: - API operations - Commands and options - Configuration keys - Events - Schemas and fields - Other documented technical items shown in the reference navigation Then compare those categories with your authored pages. You are looking for high-risk gaps, especially where a user could complete a task incorrectly because a guide leaves out a required detail that appears clearly in the reference. Typical examples include setup instructions that never mention required environment variables, task pages that skip mandatory request fields, or troubleshooting content that does not mention errors documented in the reference. To keep this review manageable, track findings in a simple audit table. | Reference item | Current authored page | Missing explanation | Update owner | |---|---|---|---| | Specific operation, command, field, or setting | Guide that should mention it | What the guide is missing | Writer or reviewer responsible | This kind of audit list helps Technical Writers and Documentation Managers prioritize updates instead of relying on memory or scattered review comments. It is also worth checking whether links work in both directions where that would help readers. A workflow guide should point to the exact reference entry for deeper detail. In some cases, the reference page may also point back to a guide that explains when to use the item in a real workflow. If you need a refresher on moving through these reference sections efficiently, see [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects) and [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views). ## Fixing Common Problems When Reference Pages and Guides Do Not Match When a guide and a technical reference page do not agree, treat that mismatch as a review signal rather than a formatting issue. In Atloria, these differences usually point to one of three problems: the guide is outdated, the reference page is incomplete, or the content needs clearer context. A common case is a guide that mentions a field, option, or flag that no longer appears on the current reference page. Start by checking whether the guide is older than the current reference content or whether the item belongs to a different version. If the guide is outdated, update the wording and remove the old reference. If the item should still exist but is missing from the reference page, flag that gap for follow-up rather than silently leaving the mismatch in place. The reverse problem also happens: the reference page lists a parameter, option, or setting, but no authored documentation explains when someone would use it. In that case, decide whether the item needs workflow context. Sometimes a short note in an existing task page is enough. In other cases, the best fix is a direct link from the guide to the exact reference section so advanced readers can explore it without cluttering the main instructions. You may also find that the product interface, command wording, and reference terminology use different names for the same concept. When that happens, choose the canonical term readers are most likely to encounter in the product or the current reference page, then add a brief clarifying phrase if an alternate name still appears elsewhere. Signs that completeness still needs work include: - Missing links to exact reference sections - Guides that mention advanced options without examples - Reference entries with no workflow context anywhere in the docs - Tables or schema sections that are never linked from related guides - Older pages that still use legacy names For a broader review approach, pair this work with [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation) and [Viewing Technical Entities and Related Reference Details](doc:viewing-technical-entities-and-related-reference-details). ## Overview Use this workflow when you are actively writing, editing, or reviewing documentation in Atloria and need to make sure narrative pages stay accurate without becoming overloaded with raw reference detail. The core idea is simple: keep workflow pages focused on what the reader is trying to accomplish, and use technical reference pages to verify the exact details behind those instructions. This is especially useful in these situations: - You are drafting a task page and need to confirm exact names before publishing - You are reviewing an older guide for outdated terminology - You are checking whether newly documented technical items are reflected in user-facing guidance - You are auditing a project’s documentation set for missing coverage - You are deciding whether a detail belongs in a guide or should remain in the reference page In practice, the work usually follows a repeatable pattern: 1. Open the authored page you are writing or reviewing. 2. Mark the statements that depend on exact technical wording. 3. Open the matching technical reference page. 4. Confirm names, paths, fields, options, and values against the reference entry. 5. Update the guide with the official term and add a direct reference link where deeper detail is useful. 6. Record any uncovered gaps for follow-up if the reference page and guide still do not align. This document focuses on how reference pages support documentation work after you already know how to browse them. If you need help navigating the reference area itself, return to [Browsing Technical Reference Sections and Entities](doc:browsing-technical-reference-sections-and-entities). From there, you can come back to this workflow and apply that navigation knowledge during real writing and review tasks. [SCREENSHOT: An Atloria project documentation workspace with an authored page and related technical reference page open for comparison] ## Prerequisites Before you use technical reference pages during documentation work in Atloria, make sure you already have access to the content areas you need and enough context to compare authored pages with reference material effectively. You should have: - Access to the relevant project workspace in Atloria - Permission to open the authored documentation pages you are reviewing or editing - Access to the project’s technical reference section - A specific page, workflow, or feature area you want to validate - Basic familiarity with navigating reference sections and entity pages It also helps if you already know which type of detail you are checking. For example, you may be validating: - API paths and request details - Command names and options - Configuration settings - Field names and response properties - Product terminology used across guides and reference pages If you have not yet worked through the earlier reference-reading material, review these first: - [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages) - [Exploring API Reference Sections Inside Projects](doc:exploring-api-reference-sections-inside-projects) - [Browsing Technical Reference Sections and Entities](doc:browsing-technical-reference-sections-and-entities) You may also want nearby documentation pages open while you work, especially if you are reviewing coverage across a larger set of guides. Keeping the authored page and the matching technical reference page visible at the same time makes it much easier to compare wording, spot naming mismatches, and decide where a direct cross-link would help readers most. From here, the next useful step is usually to apply the same review method to live project updates, version reviews, or release preparation work elsewhere in your Atloria documentation process. ## Opening an Existing Project from the Administration Area After a project has been created in Atloria, you do not need to go through the original setup flow again to make changes. Instead, open the existing project from the **Projects** area or switch to it from your current project navigation, then use the project’s administration screens to update what you need. If you are not able to edit settings, check that you have a project role with administration access. People with view-only or contributor-level access may be able to open the project but not change setup details. 1. Open **Projects** and select the project you want to update. If you are already inside another project, use the project switcher to move to the correct one. 2. Once the project opens, look for the administration entry points used for project setup. In Atloria, these may appear as tabs or menu items such as **Settings**, **Structure**, **Delivery**, **Integrations**, and **Readiness**. 3. Open each area to confirm what can still be changed. Basic setup details are usually managed from these screens after onboarding is complete. 4. If a field cannot be edited, Atloria may show it as read-only or simply not offer an edit control. That usually means the value is fixed after the project is created, or only a higher-level administrator can change it. Use this approach when you need to revisit setup without creating a replacement project or repeating earlier steps from [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding). [SCREENSHOT: Project administration area showing Settings, Structure, Delivery, Integrations, and Readiness navigation] Before you start changing anything, it helps to review how the project is currently organized by using the navigation patterns covered in [Navigating Project Workspaces and Linked Tools](doc:navigating-project-workspaces-and-linked-tools). That makes it easier to see where each setup area lives and how your changes will affect the project workspace. ## Refining the Project Structure The **Structure** and **Settings** areas are where you adjust the project’s core setup after onboarding. This is the right place to update the project’s identifying details and tidy up how work is grouped for your team. Depending on what your workspace shows, you may be able to edit items such as the project name, description, owner, and internal reference details directly in the project form. 1. Open the project and go to **Settings** or **Structure**. 2. Review the main project details. If the fields are available, update the **Project Name**, **Description**, **Owner**, or any internal identifier shown on the screen. 3. In the structure area, add or rename the organizational items tied to the project. These may appear as teams, workspaces, folders, workstreams, or documentation spaces. 4. Open the **Members** or **Permissions** screen to review who can manage, edit, or view the project. Update role assignments where needed so the right people have the right level of access. 5. Click **Save** after each set of changes, then return to the project navigation to confirm the updated names and structure appear as expected. A few changes are worth checking immediately after saving: | Area you changed | What to review afterward | |---|---| | Project details | Header name, project summary, and any project listing cards | | Structure items | Left-side navigation, workspace grouping, and content locations | | Roles and access | Who can open the project, edit content, or manage setup | [SCREENSHOT: Project Structure or Settings screen with editable project details and member access options] If you are reorganizing documentation spaces rather than learning the workspace layout for the first time, keep this focused on cleanup and maintenance. For broader navigation behavior, refer back to [Navigating Project Workspaces and Linked Tools](doc:navigating-project-workspaces-and-linked-tools). ## Changing Delivery and Operational Options Use the **Delivery** or **Operations** area when you need to revise choices that affect how the project runs after onboarding. These settings are especially important when the project has moved from initial setup into active documentation work. Atloria may present these options as dropdown lists, switches, or confirmation panels, depending on the project configuration. 1. Open the project and select **Delivery** or the related operations settings area. 2. Review the current options that were chosen during onboarding. Look for editable controls such as dropdowns, toggles, or selection cards. 3. Update the available delivery settings shown on the page. These may include items such as environment, delivery method, schedule, region, or service mode if those choices are part of your project setup. 4. Check for operational preferences on the same screen or a nearby tab. Where available, update notification behavior, default assignees, approval-related settings, or maintenance timing. 5. Click **Save** or confirm the change when Atloria asks you to apply the update. If you are changing settings on a live project, watch for warning messages. Atloria may show a notice before applying a delivery-related change that affects current work, linked options, or readiness status. Read those messages carefully before confirming. Some changes apply as soon as you save them, while others may update only after Atloria finishes a background check or sync. [SCREENSHOT: Delivery settings screen with dropdowns, toggles, and a warning message before saving changes] After saving, return to the project header or status area and confirm that the revised delivery choices are reflected there. If a change affects approvals or workflow timing, you may also want to compare it with the project’s current operating process described in [Managing Project Operations Across Project Home Tabs](doc:managing-project-operations-across-project-home-tabs). ## Managing Connected Options and Integrations The **Integrations** or **Connected Options** area shows which outside services are linked to the project. This is where you maintain connections after onboarding instead of disconnecting and rebuilding the project. In Atloria, these connections may include linked repositories, external workspaces, communication tools, or other supported services used by the project. 1. Open the project and go to **Integrations** or **Connected Options**. 2. Review the list of currently linked services. Each item may show a status, an on/off switch, a **Connect** button, or a settings panel. 3. To change an existing connection, open its settings and update the available details. Depending on the connection, this may include a linked workspace, selected account, sync preference, or other connection-specific choices shown on screen. 4. Enable or disable optional connections using the toggle or action button provided for that service. 5. Save your changes and watch for any messages that explain how the update affects the rest of the project. Some connected options influence other setup areas. For example, a linked service may affect what appears in **Delivery**, who can access certain project functions, or whether the project is marked ready in **Readiness**. Atloria may display notes or warnings directly in the integration panel when one connection depends on another setting being complete. [SCREENSHOT: Integrations screen showing connected services, status indicators, and provider-specific settings] If you need deeper guidance on specific linked tools, use [Connecting and Managing External Integrations](doc:connecting-and-managing-external-integrations) for the connection process and [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls) if your project includes webhook-based setup. For this stage, the goal is simply to maintain and adjust what is already attached to the project. ## Preparing the Project for Ongoing Use Once you have updated structure, delivery, and connected options, open the **Readiness** or setup status area to see what still needs attention. This screen helps you move from “created” to “ready for active use” without guessing which setup items remain incomplete. In Atloria, readiness information may appear as a checklist, status badges, or highlighted items that still require action. 1. Open the project’s **Readiness** area or any setup status panel shown in the project administration menu. 2. Review incomplete items one by one. Focus on the tasks Atloria marks as required or blocking. 3. Complete the remaining setup work shown on screen. This may include assigning required owners, confirming documentation locations, enabling notifications, or validating connected services. 4. Save each update and return to the readiness view to see whether the item changes from incomplete to complete. 5. Continue until the project status shows that setup is ready for ongoing work, or until only optional items remain. A readiness screen is especially useful after several people have updated the project over time. It gives you one place to confirm that the project still has the minimum setup needed for day-to-day use. Pay attention to labels such as partially configured, incomplete, or ready, since those indicators tell you whether Atloria still expects action. [SCREENSHOT: Readiness screen with checklist items, status badges, and completion indicators] Not every change updates instantly. Some items switch to complete as soon as you click **Save**, while others may wait for a sync, validation, or connection check. If a checklist item does not clear right away, refresh the page after a short wait and check whether Atloria has finished processing the update. ## Verifying Your Setup After making setup changes, take a few minutes to confirm they are working the way you expect. This final review helps catch small problems before they affect the rest of the team. In Atloria, verification usually means checking that saved values remain in place, access changes behave correctly, and at least one updated connection or delivery-related action responds normally. 1. Reopen **Settings**, **Structure**, **Delivery**, and **Integrations** to confirm your updated values are still there after saving. 2. Open the **Members** or **Permissions** area and check that the revised roles match what you intended for administrators, contributors, and viewers. 3. Ask a team member with one of the updated roles to open the project, or verify access using the role assignments shown in the project access screen. 4. Test one updated connected option or delivery-related setting. For example, open the linked connection panel and confirm it still shows as connected, or revisit the delivery screen and make sure the new selection remains active. 5. If Atloria shows an error, open the affected screen and correct the issue before leaving project administration. Common issues to look for include: - Required fields left blank - Changes not saved before leaving the page - Permission limits that prevent editing - Connection problems that require reauthorization - Warnings that were dismissed without completing the required follow-up [SCREENSHOT: Saved project settings with success message and visible role or connection status] If the project still does not behave as expected, compare the current setup with the related project management guidance in [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home) and [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). ## Overview Managing setup after onboarding in Atloria is about maintaining an existing project, not starting over. Once a project is live, the administration area becomes the place where you adjust the project’s structure, update delivery choices, maintain connected services, and confirm readiness for ongoing documentation work. This is especially useful when the project has changed owners, expanded to new teams, or needs updated operational settings after the initial launch. From the user side, the process usually centers on a few key screens: **Settings**, **Structure**, **Delivery**, **Integrations**, and **Readiness**. Together, these screens let you review what was originally configured and make targeted updates without recreating the project. You might rename the project, reorganize documentation spaces, revise role access, reconnect a linked service, or clear remaining readiness items that were skipped during onboarding. This guide focuses on those post-onboarding adjustments. It does not repeat the original project creation flow covered in [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding), and it does not re-explain general workspace navigation already covered in [Navigating Project Workspaces and Linked Tools](doc:navigating-project-workspaces-and-linked-tools). Instead, it shows how to return to administration later and make practical changes safely. Use this guide when: - The project already exists in Atloria - You need to update setup choices after onboarding - You want to confirm the project is still ready for active use - You need to maintain permissions, structure, or linked options over time [SCREENSHOT: Existing project open in Atloria with administration tabs visible] The next step after setup is usually release work. Once your project configuration is in good shape, continue with [Running a Documentation Release from Project Workspaces](doc:running-a-documentation-release-from-project-workspaces). ## Prerequisites Before you begin updating project setup in Atloria, make sure you can open the project and access its administration screens. Post-onboarding changes are usually made by someone with project-level administrative rights or another role that includes permission to edit settings. If you can view the project but do not see editable controls in **Settings**, **Structure**, **Delivery**, or **Integrations**, your access level may be limited. You should also have the project already created and available in the **Projects** list or project switcher. This guide assumes the onboarding process is complete and that you are returning later to adjust existing choices. If you still need to create the project or finish first-time setup, use [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) instead. Before making changes, it helps to have the following ready: - Access to the correct project in Atloria - Permission to edit project administration settings - A clear idea of which area you need to update: **Structure**, **Delivery**, **Integrations**, or **Readiness** - Any team decisions needed for ownership, access, or connected options - Enough time to review warnings and save changes carefully A few practical checks can prevent confusion: - Confirm you are editing the correct project, especially if several projects have similar names - Review the current setup before changing it, so you can spot what has been updated - If the change affects other team members, coordinate role or structure updates before saving - If a connected service is involved, be ready to recheck its status after the update [SCREENSHOT: Project selected from the Projects list with administration options available] If you need help understanding where project tools are located before making setup changes, refer to [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). ## Confirming the project workspace is ready for a release cycle Before you start a release in Atloria, open the target project from the main project area and review the workspace as a whole rather than jumping straight into publishing. If you already completed the setup work covered in [Managing Project Setup After Initial Onboarding](doc:managing-project-setup-after-initial-onboarding), this is the point where you confirm that setup is complete and usable for a release. Start by checking the project’s document list and version-related areas to make sure the release scope is clear. Look for documents that are still being edited, still marked as in progress, or not yet connected to the version you plan to release. A release workspace should not contain uncertainty about which pages belong in the release candidate and which ones are staying behind for later work. Next, review the project details that support the release itself. Confirm that the version label you plan to use is already decided, that the publish timing is understood by the team, and that any release notes content exists in the project documents that will be included. If your team tracks ownership inside the workspace, make sure each release-bound document has a clear owner so unresolved questions do not stall the final review. Permissions matter just as much as content. Open the project areas used for document work, review, and publishing, and confirm that the right people can access them. Documentation managers need full release visibility, reviewers need access to the documents assigned to them, approvers need access to decision screens, and the person publishing needs access to the final publish controls. Watch for blockers such as: - documents still locked for editing - documents still checked out by another teammate - missing reviewer or approver assignments - pages that appear in the project but are not tied to the intended release version [SCREENSHOT: Project workspace showing document statuses, version labels, and release-related filters] ## Bringing project documents into a release-ready state Once the workspace is organized, move through the documents one by one and bring each item to a release-ready status. In Atloria, that means checking both the content itself and the workflow status attached to it. A page can look finished but still be blocked because it has not moved into review or approval. 1. Open the document list in the project workspace and sort or filter by status so you can quickly find items still in draft or active editing. 2. Open each release-bound document and confirm that the current revision is the one intended for the release. If a newer draft exists but the approved revision is older, decide which one belongs in the release before you continue. 3. Review attachments, linked assets, and related content that appear with the document. Make sure they match the same release candidate instead of mixing older approved items with newer draft material. 4. Check for open comments, unresolved review notes, and incomplete tasks. If a document still has feedback waiting for action, it is not truly ready even if the page status looks close to complete. 5. Move finished items into the next required step, such as review or approval, based on your team’s release path in Atloria. Consistency across the workspace is important. Use the same naming pattern, version numbering, and document relationships throughout the release set so readers see one coordinated release rather than a mix of unrelated updates. This is especially important when several pages describe the same feature area or when release notes point to updated documents. If you need more detail on handling document content or version preparation, use [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages), [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content), and [Coordinating Version Work Before Release](doc:coordinating-version-work-before-release) alongside this release workflow. [SCREENSHOT: Document list filtered to show draft, in review, and approved items in one project workspace] ## Running review checkpoints across the workspace A release becomes manageable when you track review progress from the workspace level instead of opening documents at random. In Atloria, use the project’s review views, document status filters, and approval-related screens to find exactly which pages are waiting for technical review, editorial review, or final approval. 1. Open the project workspace and filter the document list by review status to find items waiting for action. 2. Check each document’s assigned reviewers and confirm that the right people are listed for the current checkpoint. 3. Review due dates where they are shown, especially for pages that are holding up the release. 4. Separate documents into three groups: approved, returned for changes, and still pending. 5. Follow up on anything returned for changes before you move the release forward. This workspace-level pass helps you avoid a common release problem: assuming the document set is approved because most pages are complete, while a small number of required pages are still waiting on decisions. Keep a close eye on documents that support navigation, release notes, or key feature explanations, since those often affect the visibility and usefulness of the full release. As review results come in, record the release decision clearly in the project workspace. That can include confirming which documents are approved for this release, noting any exceptions, and identifying pages that are intentionally deferred. A deferred document should be clearly separated from the current release candidate so it does not get published by mistake. If your team needs a deeper walkthrough of review decisions, statuses, and follow-up, refer to [Managing Version Review Requests and Decisions](doc:managing-version-review-requests-and-decisions), [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up), and [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval). [SCREENSHOT: Workspace review view showing documents grouped by pending, approved, and changes requested] ## Validating access and publish permissions before release Before you publish, confirm that the release team can actually use every part of the workflow. In Atloria, a release can appear ready from the document side but still fail if the people handling review, approval, or publishing do not have access to the right project areas. Start inside the project workspace and test the full path used during release work. The people involved should be able to open source documents, view version history where needed, access review and approval areas, and reach the publishing controls without hitting permission barriers. If someone can review a page but cannot open the final publish area, that issue should be fixed before release day. Then check audience-facing access. Review who should see the published output after release. Some documentation may be meant for internal readers only, some for external readers, and some for selected audiences. Make sure the release set matches those visibility decisions before publishing. This is especially important if the project includes targeted documentation for different reader groups. Also confirm that the person performing the publish action has permission to publish all selected content, including related assets and navigation updates. A release can publish incompletely if the main pages are available but linked content or supporting assets are not. Pay attention to inherited and project-specific access. A document may look ready in the workspace but still fail at publication or viewing because its access settings differ from the rest of the project. Check these areas before publishing: - access to source documents - access to version history and review decisions - access to publish controls - visibility settings for the intended audience - permission to publish linked assets and navigation changes For related guidance, see [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access), [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export), and [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences). [SCREENSHOT: Project publishing area with document access, audience visibility, and publish controls visible] ## Publishing the coordinated project release When the document set is approved and access is confirmed, publish from the project workspace as a coordinated release rather than as isolated page updates. In Atloria, this means confirming exactly which approved documents and related items belong in the release before you run the publish action. 1. Open the project workspace and select the approved document set for the release. 2. Verify the exact version of each included page so the release uses the intended approved content. 3. Check whether linked assets, attachments, and navigation updates are included with the release. 4. Confirm the release version label that should be applied to this publication. 5. Run the publish action from the project workspace. 6. Watch the publish progress closely and review the result for each item in the release set. 7. Capture the final release record in the workspace so the team has a clear reference for what went live. Do not assume a single publish action means every item succeeded. Review the outcome document by document and asset by asset. Look for anything marked as failed, skipped, or only partially published. If the release includes navigation changes, confirm that the updated pages appear in the correct structure after publication. After publishing, record the release details in the workspace. The useful details are the publish date and time, the version identifiers used for the release, and any documents that were intentionally excluded. This gives your team a reliable release record for follow-up reviews, support questions, and future version comparisons. If you are coordinating this with broader version work, [Managing Project Version Workspaces](doc:managing-project-version-workspaces) and [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness) are the best companion guides. [SCREENSHOT: Publish confirmation view showing selected documents, release label, and per-item publish results] ## Fixing release blockers from workspace reviews and publishing Most release blockers in Atloria fall into a few repeatable patterns, and you can usually resolve them by checking the workspace status, review assignments, and access settings together. If documents cannot enter the release, first look at their current status. Pages still in draft, still checked out, or still waiting for a required approval step will not behave like release-ready content. Open the document, clear any editing lock, complete the missing workflow step, and then return it to the correct review or approval path. Version mismatches are another common issue. You may see an older approved page sitting beside a newer draft revision that your team actually intended to release. When that happens, compare the document revisions and decide which one belongs in the release candidate. The goal is a single coordinated version set, not a mix of “latest draft” and “last approved” content. Review checkpoints can also stall because the assigned reviewer cannot access the project or does not have permission to complete the approval step. If a review sits untouched longer than expected, check the reviewer’s project access before assuming the delay is content-related. Publishing problems often show up as missing pages, missing assets, or incomplete navigation after the publish action finishes. In most cases, the cause is one of these: - the document was not included in the selected release set - the page was approved but not visible to the intended audience - linked assets were not publishable with the current permissions - navigation updates were not included with the release action When a blocker affects multiple pages, step back to the workspace level and use filters to find every item with the same problem. For more detailed troubleshooting around versions, reviews, and visibility, use [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions), [Managing Version Review Decisions and Approvals](doc:managing-version-review-decisions-and-approvals), and [Checking Screenshot Readiness Before Version Release](doc:checking-screenshot-readiness-before-version-release). ## Overview This guide focuses on the final release run inside a project workspace in Atloria. It assumes your project already exists, your working documents are in place, and your team is ready to move from active documentation work into a coordinated release. The main goal is to help you turn a collection of project documents into a controlled, publishable release set. The release workflow in Atloria usually spans five connected checks: - confirming the workspace is organized for release - moving all release-bound documents into the right review and approval state - tracking review checkpoints across the project - validating access and publish permissions - publishing the approved release set and recording the result This guide stays focused on the workspace actions that happen at release time. It does not repeat project creation, onboarding, or early configuration steps already covered in [Managing Project Setup After Initial Onboarding](doc:managing-project-setup-after-initial-onboarding). It also does not replace the deeper guides for document editing, review workflows, version comparisons, or audience planning. Instead, it shows how those pieces come together when you are ready to publish a project release. Use this guide when you need to answer practical release questions such as: - Which documents are actually ready to ship? - Are all required reviewers and approvers finished? - Do the right people have access to publish? - Will the intended audience be able to see the released content? - What should you check if some pages publish and others do not? If you are managing a release across many pages, this workspace-first approach helps you catch gaps before publication instead of discovering them after readers start using the new documentation. ## Prerequisites Before you run a documentation release from a project workspace in Atloria, make sure these conditions are already in place: - You can sign in and open the target project workspace. - The project has an established document set that is already being managed in Atloria. - The release candidate documents, attachments, and related assets are present in the workspace. - Your team has already completed the project setup and release planning needed for this cycle. If not, review [Managing Project Setup After Initial Onboarding](doc:managing-project-setup-after-initial-onboarding). - Reviewers and approvers are identified for the documents included in the release. - The person handling publication can access the project’s publishing controls. - The intended release version or release label has been decided before you publish. - Any audience-specific visibility decisions have been made for the content being released. It also helps if you have already worked through these related areas in Atloria: - [Managing Project Version Workspaces](doc:managing-project-version-workspaces) - [Coordinating Version Work Before Release](doc:coordinating-version-work-before-release) - [Preparing Versions for Final Approval](doc:preparing-versions-for-final-approval) - [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness) If your release includes screenshots, linked assets, or audience-targeted pages, confirm those parts are ready before you begin the publish step. Small gaps in those areas often become release blockers late in the process. This is the last guide in the Project Management sequence. From here, most teams continue into the version, review, publishing, or audience-specific guides depending on what needs attention in the release. ## Defining the audiences that drive your documentation plan Before you change a page outline, sidebar, or section order in Atloria, make sure your team is working from a clear audience list. In most teams, that means reviewing the audience definitions already set up for the project and confirming they still match the documentation you are about to write. If you need help creating or editing those audience records first, use [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). A useful audience record should capture more than just a name. Your team should agree on details that affect writing and publishing decisions, including: | Audience detail | What to record | Why it matters in Atloria | |---|---|---| | Audience name | The label used in the project | Keeps page tags and navigation labels consistent | | Role | Who the content is for, such as Documentation Managers or Technical Writers | Helps you choose the right tasks, examples, and terminology | | Product knowledge level | Beginner, intermediate, or advanced | Affects whether pages start with definitions, context, or direct steps | | Publishing target | Internal, customer-facing, or partner-only | Determines where the page should appear when published | | Access type | Internal vs external | Helps prevent the wrong content from appearing in public documentation | Store these decisions wherever your team already maintains content planning details in Atloria, such as page metadata, project audience settings, or the content brief used before drafting. The important part is consistency: the audience name used in the brief should match the audience label used on the page. Before writers reorganize headings, split content into separate paths, or add audience-specific notes, get approval from the people who own documentation structure. That usually means the project lead, documentation manager, or another reviewer responsible for publishing decisions. [SCREENSHOT: audience settings and content planning notes side by side in a project workspace] ## Mapping audience needs to page structure Once the audience is defined, use it to shape the page before you start writing full paragraphs. In Atloria, this usually happens in the page outline, content brief, or navigation planning view. The goal is to decide what kind of page each audience needs first: explanation, setup guidance, or a direct task flow. 1. Start by identifying the main reader for the page. If the page is for a beginner audience, place definitions, context, and basic orientation near the top. If the page is for an experienced audience, move quickly to procedures, settings, or reference details. 2. Decide how the page should open. Some audiences need a short explanation of why a task matters before they begin. Others need prerequisites first, especially when the page covers setup, permissions, or publishing choices. 3. Separate shared sections from audience-specific sections. For example, one page might include a shared introduction for all readers, followed by one heading for Documentation Managers and another for Technical Writers. 4. Label the outline clearly. In your headings, navigation notes, or content brief, mark which sections belong to each audience so reviewers can see the split before the page is published. 5. Set an order that matches reader confidence. Newer readers usually need “what this is” and “when to use it” before steps. Experienced readers often prefer “do this now” instructions first, with explanation below. This structure work is especially important when one project serves multiple groups. A mixed page becomes easier to scan when each section has a clear audience purpose instead of blending policy, setup, and writing guidance together. In Atloria, that also helps when you later assign audience metadata and decide where the page should appear in navigation. [SCREENSHOT: documentation outline with audience-labeled headings] ## Choosing what each audience should see on the page After the page structure is set, decide which parts of the content should be visible to each audience. In Atloria, this is where audience planning becomes practical: you are no longer deciding only who the page is for, but also which paragraphs, notes, examples, and media belong in front of that reader. 1. Review the page section by section and mark what every reader should see. Shared items often include the main procedure, a standard definition, or a common workflow that applies across roles. 2. Identify content that should appear only for a specific audience. This may include administrator-only setup notes, writer guidance, internal release timing, or examples written for a partner workflow rather than a customer workflow. 3. Check the page title and introduction. Some pages can use one shared title with audience-specific context below it. Others need a more specific opening paragraph so readers immediately know whether the page applies to them. 4. Review procedure steps and screenshots. Keep one canonical step sequence when the task is the same for all readers, then add audience-specific notes before or after the steps instead of duplicating the full procedure. 5. Remove internal-only details from external content. Editorial reminders, unpublished feature notes, and internal approval instructions should stay out of customer-facing or partner-facing outputs. This approach helps you avoid maintaining several near-identical pages. In Atloria, it is usually better to keep one shared procedure where possible and surround it with audience-specific explanation, warnings, or examples. That way, when the task changes, your team updates the core instructions once instead of correcting multiple copies. When you review embedded media, apply the same rule. A screenshot that shows internal workspace details may be appropriate for internal readers but not for public documentation. [SCREENSHOT: page editor showing shared content with audience-specific notes and media blocks] ## Preparing metadata and publication rules for targeted delivery Audience planning is not complete until the page is tagged correctly for publishing. In Atloria, your page structure and content choices need to match the metadata used to control where the page appears. If the metadata is wrong, the right content can still end up in the wrong place. 1. Open the page settings or content properties and assign the audience information your team uses, such as audience tags, channel, product, or access level. 2. Confirm that the audience labels match the project’s approved audience names. Small differences in naming can create confusion when pages are filtered into navigation or publication outputs. 3. Check where the page is supposed to appear. A page meant for internal readers should route to the internal documentation experience, while customer-facing or partner-only pages should appear only in their intended collections. 4. Review navigation rules. Make sure audience-tagged pages appear only in the correct sidebar, landing page, or filtered view so readers do not see links that lead to content outside their access level. 5. Validate the page before publishing. Compare the page metadata, visible content, and publication destination together to make sure they all point to the same audience. This is also the stage where teams catch mismatches such as a customer-facing page that still carries an internal audience tag, or a partner-only page that appears in a general navigation group. In Atloria, those issues are easier to fix before publication than after a version is released. If your team uses the same source content for more than one destination, double-check that the page properties support that setup and that each output respects the intended audience filters. [SCREENSHOT: page settings panel with audience tags, access level, and publication destination] ## Reviewing audience decisions with writers and stakeholders Audience-based planning works best when writers and reviewers check it before the page moves too far into drafting or publication. In Atloria, this review usually happens in the content brief, page draft, or project review workflow. The purpose is to confirm that the page is written for the intended reader, not just tagged for them. 1. Review the outline first. Check whether the section order fits the audience definition and whether beginner, intermediate, or advanced readers will encounter the right level of context at the top of the page. 2. Read the terminology closely. Make sure the page uses the language that audience expects. Documentation Managers may need governance and workflow language, while Technical Writers may need drafting and structure guidance. 3. Compare examples and screenshots against the audience. A public-facing example should not rely on internal team knowledge, and an internal guidance page should not hide important review or publishing details. 4. Confirm publication intent with stakeholders. Reviewers should agree on whether the page is internal, customer-facing, or partner-only before the page is approved for release. 5. Record the decision in the content brief or planning notes. Capture the approved audience, visibility rules, and publication destination so future edits do not accidentally change the page’s purpose. This review step is especially helpful when a page serves two nearby audiences that need different levels of detail. A side-by-side review of drafts or outlines can show whether one version is too broad, too technical, or missing the governance detail expected by reviewers. In Atloria, keeping these decisions in the page’s planning record makes later revision work much easier, especially when a new writer inherits the page. [SCREENSHOT: draft review view with comments about audience fit, terminology, and publication destination] ## Fixing common problems in audience-based content planning Even with a good plan, audience-based pages can drift over time. In Atloria, the most common problems appear when a page tries to serve too many readers at once, when metadata no longer matches the content, or when internal details slip into public outputs. Fixing these issues usually starts with a focused page review. 1. Split mixed-purpose sections when one heading tries to serve different readers at the same time. If a section combines internal policy, writer guidance, and end-user steps, break it into separate audience-specific headings or separate pages. 2. Correct mismatched tagging. If the page sits in a customer-facing navigation area but contains internal review notes, update the metadata, move the page, or remove the restricted content so structure and visibility match. 3. Reduce duplication. When your team has copied the same procedure into several audience versions, keep one shared procedure and move only the audience-specific explanation, warnings, or examples into separate surrounding sections. 4. Review hidden and visible content before release. Check that internal-only notes, release timing details, and unpublished guidance are not included in external outputs. 5. Reconfirm the audience with stakeholders if the page has changed over time. A page that started as internal guidance may now belong in a partner collection or a customer-facing help set. A quick quality check in Atloria should compare three things together: the page content, the audience metadata, and the navigation location. If those three do not align, readers will have a confusing experience even if the writing itself is strong. When a page keeps causing confusion, it is often better to create cleaner audience-specific deliverables than to keep adding exceptions inside one crowded page. That keeps maintenance manageable and makes publishing decisions more reliable. [SCREENSHOT: page review showing incorrect audience placement and corrected navigation assignment] ## Overview Applying audiences to documentation structure and content decisions in Atloria means turning audience definitions into visible choices on the page. Instead of treating audience planning as a label added at the end, you use it to decide how a page is organized, which sections appear first, what examples are shown, and where the page is published. The main areas to review are: - **Audience definitions**: Confirm the approved audience name, role, knowledge level, and publishing target before drafting. - **Page structure**: Decide whether the page should begin with context, prerequisites, or a direct task sequence. - **Content visibility**: Choose which notes, examples, screenshots, and warnings belong to all readers and which should appear only for a specific audience. - **Metadata and publishing**: Match the page’s audience tags, access level, and destination so the right readers see the right content. - **Review and maintenance**: Record approved decisions so later edits preserve the same audience logic. If you have already created or updated project audiences, this document helps you apply those definitions to actual page planning. For the setup side of that work, refer back to [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). In practice, the strongest audience-based pages in Atloria are easy to scan because they do not force every reader through the same path. A beginner reader can get context and definitions first, while an experienced reader can reach procedures and reference details quickly. That balance depends on clear planning, accurate metadata, and careful review before publication. ## Prerequisites Before you apply audience decisions to page structure and content in Atloria, make sure these items are already in place: - You can access the relevant project workspace in Atloria. - Your project already has audience definitions created or reviewed. If not, start with [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation). - You know where your team records planning details, such as page briefs, page settings, or audience metadata fields. - You are working on a page, outline, or draft that will be organized for one or more defined audiences. - You know the intended publication destination for the content, such as internal documentation, customer-facing documentation, or a partner-only collection. - The writer, documentation manager, or reviewer responsible for approving audience decisions is identified before major structural changes are made. It also helps to have these materials ready while you work: - A current page outline or draft - The project’s approved audience names - Any navigation plan or sidebar structure used for the documentation set - Existing screenshots or examples that may need audience review If your team is still deciding how audiences should fit into the broader documentation plan, the next step is [Planning Audience Targeting for Documentation Projects](doc:planning-audience-targeting-for-documentation-projects). ## Deciding Which External Connection Fits Each Project When you open a project in Atloria and move to its integration or connection area, the most important choice is the **External connection** selector. This choice determines which outside account the project can use and what linked project details you can add afterward. If you need help creating or managing those shared connections first, use [Connecting and Managing External Integrations](doc:connecting-and-managing-external-integrations). Choose the connection that matches the real workspace where your team already works. For example, if your project needs to link to a specific repository, board, folder, or external project record, pick the connection that already has access to that exact location. After you choose it, Atloria can show project-level fields such as an external project ID, workspace, board, repository, folder, or sync scope. If you choose the wrong connection, those follow-up fields may point to the wrong account or may not match the records your team expects to use. A shared connection works best when several Atloria projects should use the same outside account and the same ownership model. This is usually easier to maintain because updates such as credential changes happen once and continue to support every linked project. A dedicated connection is better when one project needs separate ownership, separate permissions, or its own external account. Think beyond setup. The connection you choose affects who maintains access later, who updates credentials, and whether sync activity continues smoothly after staffing changes. If a connection belongs to one person and that person loses access, every project tied to it can be affected. A well-chosen connection keeps project mapping stable and reduces rework when teams change. [SCREENSHOT: Project settings showing the External connection dropdown and project-specific mapping fields] ## Reviewing What You Need Before Assigning a Connection Before you assign an external connection to a project, make sure you can actually edit the project and view the available connections. In Atloria, open the project and confirm that you can reach the project settings or integration area and interact with the **External connection** list. If the list is visible but you cannot change it, ask an administrator who manages organization settings or user access. Related guidance is available in [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). You should also gather the details the connection may rely on. Atloria can support project mappings that depend on information such as an account URL, workspace name, tenant name, API key, client ID, service account details, repository name, board name, folder name, or an external project ID. You may not need every item for every connection, but you should know which values your team expects to use before you start filling in the project form. Check the outside workspace before assigning the connection. Confirm that the target project, customer area, task board, repository, or folder already exists if your workflow depends on linking to an existing record. If the outside structure is missing or named differently, you can end up saving a project with incomplete mapping details or linking it to the wrong destination. It also helps to decide ownership before setup is finished. Identify: - Who will maintain the shared connection - Who can update credentials if access changes - Who watches for sync failures or mapping problems - Where your team records project-specific connection notes This preparation prevents delays when the project is already active and someone needs to fix a broken link quickly. [SCREENSHOT: Project settings access with integration area and editable External connection field] ## Connecting a Project to an External System 1. Open the project you want to connect in Atloria. 2. Go to the project’s **integration** or **connection** area, then find the **External connection** dropdown or picker. 3. Select the correct connection from the list. Use the connection name that matches the outside account your team intends to use for this project. 4. Complete any project-level fields that appear after you make the selection. Depending on the connection, Atloria may show fields for: - **External project ID** - **Workspace** - **Board** - **Repository** - **Folder** - **Synchronization scope** 5. Review each value carefully before saving. These fields control which outside record Atloria links to for this specific project. 6. Click **Save**. After saving, look for confirmation on the project screen. Atloria may show a connection status indicator, the linked account name, or a last sync detail that confirms the project is tied to the selected external connection. If those details do not appear, reopen the connection area and confirm that all required mapping fields were completed. Record any exceptions while the setup is still fresh. For example, note whether this project uses manual sync instead of automatic updates, whether the mapping is read-only, or whether certain project details should stay in Atloria and not be pushed out. Keep those notes with the project so the next administrator does not assume the workflow behaves like every other connected project. If you are connecting a newly created project, this step usually fits naturally after the onboarding work described in [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding). [SCREENSHOT: Project connection area after selecting an External connection and filling in mapping fields] ## Understanding How the Connection Affects Project Setup and Ongoing Work Once you attach an **External connection** to a project, Atloria may change what the project requires before it can be saved or used normally. Fields such as **External project ID**, **Workspace**, **Repository**, **Board**, or **Folder** can become part of the project’s required setup. In some cases, choosing the connection also narrows the list of linked resources you can select, because Atloria is now working within one outside account instead of showing unrelated options. That connection choice can also shape how the project behaves over time. Project creation details, task-related updates, status changes, or file activity may be sent to the linked outside workspace or pulled back into Atloria, depending on how the project mapping was set up. If your team expects synchronization, the project’s linked resource details need to stay accurate. A renamed workspace, moved folder, or replaced repository in the outside tool can interrupt the workflow even if the project itself still looks complete in Atloria. Connection rules also matter when you reuse project structure. If your team creates projects from templates or copies existing projects, check whether the external mapping fields were copied too. Reused values can accidentally point a new project to an old external record. The same caution applies to archived projects and child records created after the connection is in place. Be especially careful when changing a connection on an active project. Switching the **External connection** after work has already started can require remapping the project to a different external project ID, board, repository, or folder. If you skip that review, Atloria may continue using outdated links or create duplicate links in the outside workspace. For active projects, treat connection changes as a controlled update rather than a quick dropdown change. ## Keeping External Connections Reliable Over Time A project connection is not something you set once and forget. In Atloria, review connected projects on a regular schedule and look for visible health signals such as **connection status**, **last successful sync**, and any recent error message shown in the project’s integration area. A quick review helps you catch problems before a team member notices that updates are no longer reaching the linked workspace. Credential updates need a planned process. If your organization rotates API keys, tokens, or service account access, update the shared connection in a way that protects active project mappings. The goal is to refresh access without changing the project-level fields such as **External project ID**, **Workspace**, **Repository**, **Board**, or **Folder** unless those records truly changed. If you manage shared connections centrally, one update can keep many projects working without editing each project individually. Regular audits are also useful after team or organization changes. Review projects for: - Stale external project IDs - Renamed workspaces - Deleted folders or repositories - Connections still owned by someone who changed roles - Projects linked to a connection that is no longer the team standard Consistency matters just as much as repair work. Standardize how your team names connections, who owns them, and when a project should use a shared connection versus a dedicated one. When new projects follow the same connection rules from the start, setup is faster and troubleshooting is easier. For broader project maintenance habits, pair this work with [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options), especially if several administrators share responsibility for long-running projects. [SCREENSHOT: Connected project showing status, linked account name, and last successful sync details] ## Fixing Common Connection Problems in Project Workflows When a project will not save after you select an external connection, start with the connection itself. In the project’s integration area, confirm that the chosen item still appears in the **External connection** list and has not been removed or made inactive. If the connection exists but the project still cannot be saved, review whether required mapping fields such as **External project ID**, **Workspace**, **Board**, **Repository**, or **Folder** are blank. If sync activity fails after the project was already working, compare the current project mapping with the outside workspace. Check whether the linked project, board, repository, or folder still exists and still uses the same name or identifier. A moved or deleted record outside Atloria can break the link even when the project’s saved values look unchanged. When updates are reaching the wrong external record, review how the project was created. This often happens when someone copied a project template or duplicated an existing project and left the old external identifier in place. Open the project, inspect every mapping field, and confirm that each value belongs only to this project. If two projects share the same external project ID or folder by mistake, correct the mapping before more updates are sent. Permission errors usually point to the account behind the selected connection. Confirm that the linked account still has access to the external project area your workflow depends on. If the owner changed roles or lost access, the project may still show the connection name while sync actions fail behind the scenes. If the problem is wider than one project, review the shared connection first using [Connecting and Managing External Integrations](doc:connecting-and-managing-external-integrations). If the issue is tied to project setup, compare the project’s mapping details with similar working projects in Atloria. ## Overview This guide focuses on the project-level side of external integrations in Atloria: choosing the right **External connection** for a project, filling in the mapping details that appear after selection, and keeping those links dependable as projects change over time. It assumes the connection itself already exists in Atloria. If you still need to add, authorize, or manage the shared connection record, start with [Connecting and Managing External Integrations](doc:connecting-and-managing-external-integrations). The main decision point is the **External connection** selector inside a project. That single choice affects which account the project uses, which mapping fields become available, and how the project connects to outside records such as repositories, boards, folders, workspaces, or external project entries. Because of that, connection setup is not just an admin formality. It directly affects project onboarding, template reuse, sync reliability, and long-term maintenance. You will also see how to prepare before assigning a connection, what to verify after saving, and what to review when a project starts failing to sync correctly. The guide stays focused on what project administrators do on project screens rather than on organization-wide connection creation. Use this document when you are: - Assigning an external connection to a new project - Reviewing whether a project should use a shared or dedicated connection - Updating project mapping details after outside workspace changes - Troubleshooting a project that no longer syncs as expected For related project setup decisions, continue with [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). ## Prerequisites Before you work through project connection setup in Atloria, make sure the basic access and project details are already in place. This guide does not cover account sign-in or creating shared connections from scratch. You should have: - Access to sign in to Atloria and open the target project - Permission to edit the project’s settings, integration area, or connection settings - At least one available item in the **External connection** list - The correct outside workspace details for the project you are linking - A clear owner for ongoing connection maintenance It is also helpful to confirm the following before you begin: | What to confirm | Why it matters | |---|---| | The project already exists in Atloria | You need an existing project record to assign a project-level connection | | The shared connection is already available | You can only choose from connections that have already been added to Atloria | | The outside project structure is ready | Mapping fields such as workspace, repository, board, or folder are easier to complete accurately | | Your team knows who maintains the connection | Problems are resolved faster when ownership is clear | If you still need help getting into Atloria, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If you need to create the project first, use [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding). If the shared connection has not been added yet, return to [Connecting and Managing External Integrations](doc:connecting-and-managing-external-integrations). ## Choosing the reporting view for portfolio or project decisions Use the **Admin** workspace when you need a portfolio view across multiple documentation efforts, and use a single project’s **Analytics** screen when you need to understand what is happening inside one project. In Atloria, these two views answer different questions. The enterprise view helps you judge overall documentation program health, while the project view helps you explain why one team, one documentation set, or one release cycle is performing differently. 1. Open the **Admin** area from the main navigation when you want to compare multiple projects or review reporting across a broader documentation program. 2. Select **Analytics** from the admin options to open the enterprise reporting area. This is the right place to look for rollup numbers such as overall documentation volume, active project count, overdue work, and completion progress across the selected scope. 3. Open a specific project from the project list or dashboard when you need local detail. Inside that project, use the **Analytics** view to focus on that project’s own activity, review progress, and content performance. 4. Use the scope selector in the reporting area to switch between a broad view and a narrower one. Depending on how your Atloria workspace is organized, this may let you focus on all documentation programs, a smaller documentation set, or one project. 5. Set the same **date range** or reporting period in both views before comparing results. If one view is showing a different time window, the numbers will not line up in a meaningful way. 6. Read KPI cards based on their purpose. Portfolio health cards are most useful in the enterprise view because they summarize the bigger picture. Project-only measures are more useful in the project analytics view because they depend on local workflows and day-to-day team activity. [SCREENSHOT: Enterprise Analytics screen with scope selector, date range control, and KPI cards highlighted] If you need a refresher on moving between enterprise and project analytics screens, see [Managing Enterprise and Project Analytics for Documentation Performance](doc:managing-enterprise-and-project-analytics-for-documentation-performance). ## Reviewing enterprise metrics across all documentation programs The enterprise reporting view is where documentation managers can scan the health of the full portfolio without opening each project one by one. In Atloria, start with the top KPI area and then move down into trend charts and the project list or rollup table. That reading order helps you move from broad signals to specific problem areas. 1. Open **Admin** and select **Analytics**. 2. Review the top KPI tiles first. Focus on rollup measures such as **total pages**, **active projects**, **overdue work**, and **completion rate**. These tiles help you understand whether the documentation program is growing, staying current, or falling behind. 3. Narrow the results with the available filters in the enterprise dashboard. Use filters such as **organization**, **team**, or **program** to focus on one part of the portfolio without leaving the page. 4. Check the trend charts below the KPI area. Compare the current reporting period with earlier periods to see whether output is increasing, backlog is shrinking, or review throughput is slowing down. 5. Move to the project list or rollup table. Scan for projects with unusually high backlog, low completion, or declining activity. These rows often explain why a top-level KPI has moved up or down. 6. Open the rows that stand out and note whether the issue appears isolated or repeated across several projects in the same group. When you read enterprise metrics, look for patterns rather than single numbers. For example, a high total page count can still hide weak review performance if overdue work is also increasing. A healthy completion rate can also hide one struggling project if the rest of the portfolio is strong enough to balance it out. The enterprise dashboard is best used to identify where you need a second look, not to explain every cause by itself. [SCREENSHOT: Enterprise reporting dashboard showing KPI tiles, trend charts, and project rollup table] ## Inspecting project analytics to explain unusual portfolio results Once the enterprise dashboard points to an outlier, switch to that project’s **Analytics** screen to understand the cause. The project view gives you the local detail that a rollup cannot show. This is where project administrators and documentation managers can confirm whether a spike in overdue work, a drop in completion, or weak output is tied to one team’s actual workflow. 1. In the enterprise report, click the project name or the project row that looks unusual. 2. Open the project’s **Analytics** screen. 3. Review the project-specific charts and summary areas. Look for signs such as slower content production, longer review cycle time, more unresolved issues, or missed milestones during the selected period. 4. Check the active filters in the project view. Make sure settings such as **owner**, **content type**, **status**, and **date range** are not narrowing the project data in a way that makes it look different from the enterprise rollup. 5. Compare the current period with the previous period shown in the project analytics view. This helps you decide whether the problem is new, temporary, or part of a longer pattern. 6. Note whether the issue is concentrated in one part of the project, such as one owner, one content category, or one review stage. This step is especially important when the enterprise dashboard shows a sudden change. A project may appear to be underperforming at portfolio level, but the project analytics view may show that the issue is limited to one review bottleneck or one missed milestone window. On the other hand, a project that has looked weak for several periods in a row may need more than a short-term correction. [SCREENSHOT: Project Analytics screen with charts, filters, and period comparison visible] ## Comparing enterprise and project numbers without misreading the data Enterprise and project reporting can both be accurate and still look different. In Atloria, the safest way to compare them is to make sure both views are using the same reporting rules before you draw conclusions. Most mismatches come from comparing different scopes, different periods, or different calculation styles. 1. Match the **date range** in both the enterprise dashboard and the project’s **Analytics** screen. 2. Confirm that the same **status** filters are applied in both places. If one view includes all work and the other only includes a narrower status set, the totals will differ. 3. Check the inclusion rules for the enterprise view. Some rollup views may exclude archived projects or only include projects inside the selected organization, team, or program. 4. Compare like with like. If the enterprise dashboard shows a total count, compare it to a total count in the project view. If it shows a percentage or average, do not treat it as a raw count. 5. Read outliers carefully. One project’s overdue reviews can be hidden inside a healthy portfolio if the enterprise view is averaging results across many projects. 6. If the numbers still seem off, check whether one view has refreshed more recently than the other. The table below shows how the same reporting topic can lead to different conclusions depending on how the numbers are displayed: | Reporting style | What it tells you | What to watch for | |---|---|---| | Total | Overall volume across the selected scope | Large portfolios can make one project’s issue look small | | Average | Typical result across projects | Strong projects can hide one weak project | | Percentage | Share of work meeting a target | A good percentage can still include a serious raw backlog | | Project count | Number of affected projects | Does not show how severe the issue is inside each project | When comparing views, remember that rollup metrics are designed for portfolio decisions, while project metrics are designed for local action. Use each one for the question it answers best. ## Turning reporting gaps into project actions and portfolio priorities After you compare the enterprise dashboard with project analytics, the next step is deciding whether the issue needs a broad documentation program response or a local project fix. Atloria helps you make that distinction by showing both rollup KPIs and project-level detail. The goal is not just to spot a gap, but to turn that gap into a clear action. 1. Start in the enterprise reporting view and identify the KPI that is moving in the wrong direction, such as growing overdue work or falling completion rate. 2. Check whether the issue appears across several projects or only in one or two. If the same pattern appears in multiple rows, treat it as a portfolio priority. If it is limited to one project, handle it locally first. 3. Open the affected project’s **Analytics** screen and identify the likely cause. Look for owner imbalance, backlog growth, delayed reviews, unresolved issues, or missed milestones. 4. Turn the finding into a practical action. Examples include reassigning owners, reducing backlog, tightening review schedules, or focusing effort on the content type that is slipping. 5. Decide which project metrics you will watch after the change. Use the same measures that exposed the problem so you can confirm whether the action is working. 6. Return to the enterprise dashboard during your next reporting cycle and check whether the project improvement is starting to change the portfolio picture. A regular review cadence makes this easier. Many teams compare enterprise KPIs with project dashboards before internal status reporting so they can explain both the portfolio signal and the local cause. If you already use enterprise and project analytics together, this step extends the workflow described in [Managing Enterprise and Project Analytics for Documentation Performance](doc:managing-enterprise-and-project-analytics-for-documentation-performance) by focusing on decision-making rather than navigation. [SCREENSHOT: Side-by-side example of enterprise KPI trend and matching project analytics detail] ## Fixing mismatched totals and missing outliers in reports When enterprise totals do not match project reports, the problem is usually in the filters or reporting setup rather than the underlying work. In Atloria, you can usually resolve these differences by checking the selected scope, time period, and inclusion settings in both views. - If the enterprise total does not match the sum of project reports, compare the **date range** first. A monthly enterprise view and a shorter project period will never align. - Check the active **status** filters in both places. If one view includes completed and in-progress work while the other only shows one status group, the totals will differ. - Confirm whether archived projects are included in the enterprise dashboard. If archived work is excluded from the rollup, the enterprise total may be lower than a manual project-by-project sum. - If a project looks healthy in the portfolio but unhealthy in its own analytics view, check whether the enterprise dashboard is showing an **average** or **percentage** instead of a raw count. Averages can soften the impact of one struggling project. - If an expected outlier is missing from the enterprise view, verify that the project belongs to the selected **organization**, **team**, or **program** filter. - If trend lines look inconsistent, compare the reporting period style in each view. A broader period can smooth spikes that are very visible in a more detailed project chart. - Review any saved filter presets that may reopen the dashboard with older settings. When you troubleshoot, work from broadest settings to narrowest settings: scope, date range, status, and then project membership. That order helps you eliminate the most common causes quickly. If a mismatch remains after those checks, reopen the enterprise dashboard and the project analytics page side by side and compare each visible filter one at a time. [SCREENSHOT: Filter bar in enterprise and project reporting views with date range and scope settings highlighted] ## Overview Atloria gives documentation managers and project administrators two reporting perspectives: an enterprise reporting view for portfolio-wide monitoring and a project **Analytics** view for local investigation. This document focuses on how to compare those two perspectives without confusing rollup signals with project detail. Use the enterprise reporting dashboard when you need to understand overall documentation program health across multiple projects. This is where you review top-level KPI tiles, trend charts, and project rollups to see whether output, backlog, review throughput, and completion are moving in the right direction. Use a project’s **Analytics** screen when you need to explain why one project is pulling the portfolio up or down. The key to a useful comparison is alignment. Before comparing numbers, make sure both views use the same date range, similar status filters, and the same scope rules. Once the views are aligned, use enterprise reporting to spot unusual patterns and project analytics to confirm the cause. That approach helps you separate broad program issues from isolated project problems. This guide does not repeat the navigation basics already covered in [Managing Enterprise and Project Analytics for Documentation Performance](doc:managing-enterprise-and-project-analytics-for-documentation-performance). Instead, it shows how to move from a portfolio signal to a project explanation, how to avoid common reading mistakes, and how to turn reporting gaps into practical documentation actions. ## Prerequisites Before you compare enterprise reporting with project analytics in Atloria, make sure the following are in place: - You can sign in to Atloria and open the main workspace navigation. - You have access to the **Admin** area and its **Analytics** option for enterprise-level reporting. - You have access to at least one project and can open that project’s **Analytics** screen. - You know which documentation program, team, organization, or project you want to compare. - You have a reporting period in mind so you can apply the same **date range** in both views. - You are familiar with the project and enterprise analytics workflow from [Managing Enterprise and Project Analytics for Documentation Performance](doc:managing-enterprise-and-project-analytics-for-documentation-performance). It also helps to know what question you are trying to answer before you begin. For example: - Are you checking overall portfolio health? - Are you investigating one project with unusual backlog or low completion? - Are you validating whether a local project issue is large enough to affect program reporting? - Are you preparing status reporting and need enterprise and project numbers to tell the same story? If your goal is to compare results across multiple projects after identifying the right reporting scope, continue with [Reviewing Documentation Performance Across Projects](doc:reviewing-documentation-performance-across-projects). ## Understanding how Git connections support connected projects In Atloria, a Git provider connection is what lets a project use repository-based content during connected project setup and later source-based documentation work. You use this connection when your team wants Atloria to work from a repository instead of relying only on manually entered project details. The connection links Atloria to the Git provider account that can access the repository your project depends on. It helps to separate two actions that often happen close together: - **Connecting a Git provider** gives Atloria permission to reach your Git account or organization. - **Choosing a repository** tells Atloria which specific repository the project should use. These are related, but they are not the same step. You can think of the provider connection as the access pass, and the repository selection as the actual source you want to use for the project. An active connection matters after setup as well. Ongoing tasks that depend on it can include: - keeping the project linked to its repository - allowing Atloria to continue using source-based project setup - maintaining repository access when permissions change - supporting future source-backed documentation work tied to that connected project The main places you will use in Atloria are the project area where connected setup is managed, the project settings or integration area where the provider appears, the visible connection status, and the controls for **Re-authorize**, **Reconnect**, or **Disconnect** when access changes. If you are still deciding whether to use a connected setup or a manual project setup, read [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). [SCREENSHOT: Project settings or source setup screen showing Git provider connection status and repository connection area] ## Checking access requirements before you connect a provider Before you start the connection flow in Atloria, make sure you are signed in with a role that can manage project-level setup and integrations. For most teams, that means a role such as **Project Administrator** or **Documentation Manager**. If you can open the project settings area and see connection controls, you likely have the right level of access. If those controls are missing, ask a project admin to review your permissions. You also need access on the Git provider side. The account you use during sign-in must be able to reach the repository, workspace, or organization that owns the source content for the project. If the repository belongs to a team or company account rather than your personal account, confirm that you can view it there before starting the connection in Atloria. During the provider approval screens, you may be asked to grant access to repositories or organizations. Read those choices carefully. If you approve the wrong account or skip repository access, Atloria may show the provider as connected but still not be able to use the repository your project needs. Before connecting, confirm these points: - You are signed in to Atloria. - You can open the correct project. - You have permission to manage project setup or integrations. - You know which Git provider hosts the repository. - You can sign in to the correct provider account or organization. - You are ready to approve repository or organization access if prompted. It also helps to identify the exact project that will use the connection. If your team manages several projects in Atloria, open the intended project first so you do not connect the provider in the wrong workspace. For help getting into your account or resolving sign-in issues first, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). ## Connecting a Git provider to a project 1. In Atloria, open the project you want to use for source-based documentation work. Go to the area where connected setup or project integrations are managed. Look for the option to connect a Git provider. 2. In the connection area, choose the provider you want to use from the available options. Atloria will start the authorization flow and send you to the provider sign-in and approval screens. 3. Sign in with the Git provider account that has access to the repository your project needs. If the provider asks you to choose an account, organization, or repository scope, select the one that matches the project’s source location. 4. Review the consent screen carefully, then approve access. If the provider asks whether Atloria can access repositories or organization content, allow the access needed for the project you are connecting. 5. After approval, return to Atloria automatically or through the browser flow. Back in the project area, check the connection section again. 6. Confirm that the provider now appears as connected. The project’s integration or source setup screen should show that the authorization step completed successfully. A successful connection usually means you can move forward with repository selection or continue a connected project setup that depends on source access. If the provider appears, but the repository you need is still unavailable, the most common cause is that the wrong provider account was approved or repository access was not included during consent. Use this screen to confirm: - the provider name is shown - the status indicates an active connection - the project is ready for the next source-based step [SCREENSHOT: Git provider selection screen in a project] [SCREENSHOT: Connected status shown after returning from provider authorization] ## Reviewing connection status and repository access Once a provider is connected, the next thing to check is the visible status in the project settings or connected project configuration screen. This status tells you whether Atloria can still use the provider for repository-backed work. You may see status labels such as these: | Status shown in Atloria | What it means for you | |---|---| | **Connected** | The provider connection is active and ready to use. | | **Authorization Required** | Atloria needs you to approve access again before source-based work can continue. | | **Disconnected** | There is no active provider connection for this project. | When the status is **Connected**, review the connection details shown on the screen. Check that the connected provider account matches the repository owner, team, or organization your project depends on. This matters most when you belong to multiple provider accounts or organizations. A connection to the wrong account can look valid at first but still fail when Atloria tries to work with the intended repository. Look for visible details that help confirm the setup, such as: - the connected provider name - the current connection state - whether authorization is still valid - whether the project is still linked for connected source-based work If the screen shows **Authorization Required**, do not assume the project is fully usable just because a provider name is listed. That status means Atloria recognizes the previous connection, but you need to refresh access before continuing. If you want a deeper walkthrough focused on health checks and warning states, continue with [Reviewing Git Connection Status and Access Health](doc:reviewing-git-connection-status-and-access-health). [SCREENSHOT: Connection status area showing Connected, Authorization Required, and Disconnected examples] ## Re-authorizing a Git provider when access changes 1. Open the project in Atloria and go to the same connection area where the provider status is shown. If the status reads **Authorization Required**, or if the screen indicates expired access or missing permissions, select **Re-authorize** or **Reconnect**. 2. Atloria will send you back through the provider approval flow. Sign in with the correct provider account, especially if you have access to more than one account or organization. 3. On the provider consent screens, approve the access Atloria requests. If your team recently moved the repository, added a new organization, or changed repository permissions, make sure you grant access to the newly required location. 4. Finish the approval flow and return to Atloria. Go back to the project connection area and refresh the page if needed. 5. Confirm that the status changes from **Authorization Required** back to **Connected**. Re-authorization is useful when the original connection still belongs to the right project, but the access behind it has changed. In that case, you usually do not need to rebuild the project from scratch. Instead, you refresh the existing connection so Atloria can continue using the same connected setup. This is especially helpful when: - repository permissions were updated - your team changed which organization owns the repository - the provider asked for approval again - Atloria reports that access is no longer valid After re-authorizing, verify that the project can continue with the same repository-backed workflow. If the status returns to **Connected**, the existing setup should remain in place without creating a brand-new project connection. For a fuller guide to ongoing access maintenance, see [Connecting Projects to Git and Maintaining Access](doc:connecting-projects-to-git-and-maintaining-access). ## Disconnecting a provider and verifying the project setup 1. In Atloria, open the project and go to the Git provider connection controls in the project settings or connected setup area. 2. Select **Disconnect** from the available connection actions. Atloria may show a confirmation message before completing the change. 3. Read the confirmation message carefully. This is where Atloria explains how disconnecting affects connected project setup and any source-based work that depends on repository access. 4. Confirm the disconnect action. After the action finishes, stay on the same screen and check the updated status. 5. Verify that the provider now shows as **Disconnected**. After disconnecting, review the project setup to understand what changed. A disconnected provider means Atloria no longer has active access to the repository through that project connection. If your project depends on repository-backed documentation workflows, those tasks will usually require a new connection before they can continue. Use the project screen to confirm: - the provider is no longer marked as connected - connection actions now offer a way to reconnect - the project no longer has an active source access link Disconnecting can be the right choice if the project is moving to a different provider account, if the wrong account was connected, or if your team no longer wants the project tied to that repository access. If you only need to restore access, use **Re-authorize** instead of disconnecting so you can keep the existing connected setup intact. If you need to remove and later restore access safely, the next documents in this section cover those follow-up tasks in more detail, including [Reauthorizing and Disconnecting Git Integrations](doc:reauthorizing-and-disconnecting-git-integrations). [SCREENSHOT: Disconnect confirmation message and resulting Disconnected status] ## Overview This document focuses on the project-level workflow for using Git provider access in Atloria’s connected project setup. The key idea is that a provider connection gives Atloria permission to work with a repository-backed project, while the repository choice determines which source the project actually uses. Both parts matter, but they happen as separate actions in the interface. The screens you will use most often are: - the project area where connected setup begins - the project settings or integration area - the Git provider status section - the **Re-authorize**, **Reconnect**, and **Disconnect** controls Across those screens, you will typically complete four tasks: - connect a provider for the first time - confirm the connection is still active - re-authorize access when permissions change - disconnect the provider when the link is no longer needed This guide stays focused on what you can see and do in Atloria. It does not cover provider-specific account administration outside the approval screens, and it does not repeat the broader project onboarding flow. If you need the full setup path before reaching the Git connection step, start with [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding). If you are comparing setup styles before you commit to a repository-backed workflow, use [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). If your project is already connected and you mainly need to monitor status or fix access drift, the follow-up documents in this Git Connections section will take you through those maintenance tasks in order. The next step after this guide is [Connecting Projects to Git and Maintaining Access](doc:connecting-projects-to-git-and-maintaining-access). ## Prerequisites Before you connect a Git provider in Atloria, make sure the project and your access are ready. This keeps the connection flow short and helps avoid the most common problems, such as approving the wrong account or connecting from the wrong project. Have these items in place: - You can sign in to Atloria successfully. - You can open the correct project workspace. - Your role allows you to manage project setup or integrations. - You know which Git provider hosts the repository. - You can sign in to the correct provider account. - You have access to the repository owner or organization if the repository is team-managed. It is also worth checking a few details before you click **Connect**: | What to confirm | Why it matters | |---|---| | Correct project is open | Prevents connecting the provider in the wrong workspace | | Correct provider account will be used | Avoids linking a personal account when the repository belongs to a team | | Repository or organization access can be approved | Ensures Atloria can actually use the source needed by the project | If your team uses several Atloria projects, pause and verify the project name before starting the provider flow. If you belong to several Git organizations, verify which one owns the repository so you can choose the right account during sign-in and consent. You do not need to complete advanced admin setup to follow this guide, but you do need enough project access to see the connection controls. If those controls are unavailable, review your project permissions with an administrator. For broader admin navigation, see [Using the Admin Workspace](doc:using-the-admin-workspace). ## Preparing the source material for a coordinated documentation cycle Start the cycle in the project workspace where your team keeps both authored documentation and technical reference content. Before anyone edits pages, confirm which project and which release you are working on. In Atloria, this usually means agreeing on the target version in the project’s version area, the current documentation branch or working copy your team is updating, and the exact set of reference pages that will be reviewed during this cycle. Your source material should include the latest technical reference output your team is using for review. Depending on how your project is maintained, that may come from the code parsing workspace, API reference pages inside the project, or manually reviewed technical pages. The goal is to make sure everyone is looking at the same reference baseline before authored guides are updated. It helps to gather the working materials in one place before the first edit begins: | Item | What to confirm | Why it matters | |---|---|---| | Project | The correct project in Atloria | Prevents edits in the wrong workspace | | Target version | The version label for this release | Keeps updates tied to the right release | | Reference source | Parsed results, reviewed reference pages, or both | Gives writers a verified source | | Draft materials | Notes, comments, and page drafts | Keeps follow-up work organized | Next, assign clear ownership. One person should confirm technical accuracy in the reference pages. Another should update authored guides and task-based pages. A reviewer or approver should check the final version package before publication. If your team also prepares release notes, decide who owns those at the start. [SCREENSHOT: Project workspace showing version area, technical reference section, and authored documentation list] Keep review comments, reference diffs, draft page changes, and version notes together so the same materials can be reused during approval and publication. ## Reviewing technical reference changes before authored updates Open the latest technical reference pages in Atloria and compare them with the currently published version of the same content. If your team uses the code parsing workspace, review the newest parsed output alongside the existing reference pages. If your team reviews technical pages manually, compare the updated page content against the public baseline. The purpose of this step is to isolate what actually changed before writers begin editing task guides. Focus first on changes that affect what readers do. A renamed field, a new required setting, a changed permission requirement, or a different response example can all make an authored guide inaccurate. By contrast, wording cleanups that do not change meaning can usually wait until later. Separate these two types of changes so your writing team can prioritize the updates that affect instructions, prerequisites, and release notes. As you review, capture each meaningful change in a simple review log. For every change, note which authored pages are affected and whether the change also needs a version note. This makes handoff much easier because the writer can move directly from the review log to the correct pages in Atloria. A practical review log can include: | Reference change | Impact on readers | Authored page to update | Include in version notes | |---|---|---|---| | Renamed field | Steps and screenshots may no longer match | Setup or task page | Yes | | New required option | Prerequisites and examples must change | Configuration guide | Yes | | Deprecated behavior | Add warning or replacement guidance | Existing workflow page | Yes | | Wording only | No task impact | Optional cleanup | Usually no | If you already use analytics or audit records to support release decisions, keep this review step aligned with the process in [Using Analytics Audit and Exports in Release Operations](doc:using-analytics-audit-and-exports-in-release-operations). That earlier workflow helps you support these findings with release evidence instead of relying on memory. ## Updating authored documentation from validated reference findings Once the technical review log is complete, move into the authored pages that were flagged for updates. In Atloria, open each affected documentation page and revise the parts readers rely on most: task steps, prerequisites, explanations, examples, and links to supporting reference pages. Work from the validated review notes rather than editing from memory, so every change in the guide matches the approved technical source. Start with the pages that describe user actions. If a field name changed, update the step where readers enter that value. If a required option was added, revise the prerequisite section and the procedure itself. If a path, command option, or authentication requirement changed in the reference material, make sure the authored page reflects that change everywhere it appears, including examples, screenshots, and linked follow-up pages. Cross-links matter here. After updating the written guidance, check that each link still points readers to the correct technical reference page inside the same project and version. A task page should lead to the exact supporting reference page, not a general section that forces readers to search again. Use this checklist while editing: - Update page titles or headings if terminology changed - Revise step-by-step instructions to match current labels and inputs - Replace outdated examples and expected results - Review prerequisites for new access or setup requirements - Check links between authored pages and technical reference pages - Add a note in the draft if any source detail is still unclear If something in the technical source is incomplete or inconsistent, do not guess. Mark the gap directly in the draft and send it back for clarification before release approval. That is especially important when the reference pages and the authored workflow appear to conflict. It is better to pause one page than to publish a polished guide that sends readers down the wrong path. [SCREENSHOT: Documentation editor with an authored page open beside linked technical reference content] ## Preparing versioned documentation for release After the authored pages and technical reference pages are aligned, decide where the update belongs in Atloria’s version structure. Some changes fit into the current documentation version, while others belong in a new release or must be applied to more than one maintained version. Use the scope of the change to guide that decision. A small wording correction may stay in the current version, but a renamed option, new requirement, or changed workflow often needs version-specific handling. Open the target version and confirm that both authored pages and technical reference pages are assigned consistently. This is where version labels, availability notes, compatibility statements, and deprecation notices need to match. If one page says a feature is available in a release but the linked reference page does not, readers will lose confidence quickly. Before packaging the release, test the versioned reading experience inside Atloria. Move through the left navigation, open key pages, and use in-page links to make sure readers stay inside the intended version. Pay special attention to links from task guides into technical reference pages, because those are the easiest places for version mismatches to appear. Review these release elements together: | Release element | What to verify | |---|---| | Version label | Matches the target release everywhere | | Availability notes | Appear on both authored and reference pages when needed | | Deprecation notices | Clearly shown on affected pages | | Navigation links | Stay within the correct version | | Version notes | Explain the reader-facing changes | When the checks are complete, assemble the release package: approved authored updates, reviewed or regenerated technical reference pages, and version notes that explain what changed. If your team needs a broader refresher on version handling, use [Moving Document Updates into Versioned Releases](doc:moving-document-updates-into-versioned-releases) alongside this workflow. ## Publishing the coordinated update to the public site With the release package assembled, run a final publication check before making the update public. In Atloria, review the target version as a complete set rather than checking pages one by one. Confirm that the authored guides, technical reference pages, navigation items, and version notes all appear together and reflect the same release state. Start with link and navigation validation. Open the main landing page for the version, move through the section menu, and test links from authored pages into reference pages. Then confirm that the updated version metadata is visible where readers expect it. If your team uses search and version selectors, check that the new content appears in the correct public location and does not point readers back to an older release. A final publication review should cover: - Broken or outdated links - Missing technical reference pages - Navigation items that do not include the new content - Incorrect version labels or availability notes - Search results that still favor old pages - Landing pages that do not surface the updated release [SCREENSHOT: Version review screen showing navigation, page list, and publication-ready content] Once the version is approved, publish the coordinated content set together. Avoid releasing authored pages separately from the technical reference pages they depend on. Publishing only part of the package is one of the fastest ways to create inconsistent public documentation. After publication, record the release details in your team’s publication history. Include the release date, the published version identifier, the approver, and links to the review notes or supporting artifacts used during the cycle. If you later need to explain a change, verify what was published, or decide whether to roll back, that record becomes the source of truth. ## Fixing common handoff and release problems When technical reference review and authored updates are handled by different people, the most common problem is a broken handoff. If the technical reference changed but the authored guide did not, go back to the review log and confirm that each flagged change was assigned to a page owner. In Atloria, open the affected project pages and compare the reviewed reference content with the current draft or published guide. If the guide still uses old wording, the handoff likely stopped between review and editing. Another common issue is outdated terminology inside authored guidance. A guide may still mention an old field name, option, or requirement even though the linked technical reference page is correct. Fix this by updating all related content together: the procedure, prerequisites, examples, screenshots, and any nearby cross-links. Partial updates usually create more confusion than the original mistake. If versioned pages point to the wrong release of the technical reference content, inspect the version assignment for both page types. A task guide in one release should not send readers to a reference page from another release. Check the target version, the page links, and any redirects before republishing. When the public site shows only part of the update, the publication package is usually incomplete. Confirm that all of the following were included in the same release: | Problem | What to check in Atloria | Likely fix | |---|---|---| | Authored page updated, reference page missing | Publication package contents | Republish with both page sets | | Reference page updated, guide still old | Review log and assigned draft pages | Complete the authored update | | Wrong version opens from links | Version labels and page links | Correct version mapping | | Navigation missing new pages | Version navigation and page inclusion | Rebuild and republish the release set | For broader release troubleshooting, it can also help to revisit [Running a Project from Setup to Public Documentation Release](doc:running-a-project-from-setup-to-public-documentation-release), especially if the issue affects the full publishing path rather than a single page handoff. ## Overview This workflow is for teams who need to keep technical reference material and authored documentation in sync during the same release cycle. In Atloria, that usually means reviewing updated technical pages first, then using those findings to update task-based guides, version notes, and public-facing documentation before publication. The goal is not just to refresh content, but to make sure readers see one consistent story across project pages, reference pages, and the published site. A coordinated cycle usually moves through four connected areas in Atloria: | Area | Purpose in the workflow | Typical output | |---|---|---| | Technical reference content | Identify validated changes | Reviewed reference findings | | Authored documentation pages | Update instructions and explanations | Revised task guides | | Version workspace | Group pages into the right release | Release-ready version | | Public publication view | Confirm what readers will see | Published documentation set | This guide focuses on the handoffs between those areas. You will review technical changes, update authored pages based on confirmed findings, prepare the correct version, and publish both content types together. That is especially useful when a release includes renamed inputs, changed requirements, or updated workflows that affect both reference pages and reader-facing instructions. If you need help with only one part of that process, use the related guides for deeper detail. For version handling, see [Moving Document Updates into Versioned Releases](doc:moving-document-updates-into-versioned-releases). For release evidence and audit support, see [Using Analytics Audit and Exports in Release Operations](doc:using-analytics-audit-and-exports-in-release-operations). This guide brings those pieces together into one coordinated publishing workflow. ## Prerequisites Before you begin, make sure you can access the Atloria areas used in this workflow. You need access to the project workspace that contains the documentation pages you are updating, the technical reference content your team uses for review, and the version area where the release will be prepared. If your team separates responsibilities, confirm who can edit pages and who can approve or publish the final version. You should also have the source materials for the release ready before opening drafts. At minimum, gather the latest reviewed technical reference changes, the list of authored pages affected by those changes, and the version or release label your team plans to publish under. If your team keeps release notes, changelog entries, or review comments in Atloria, have those available as well so they can be attached to the same cycle. Use this readiness list before starting: - Access to the correct project workspace - Access to the technical reference pages or parsed results under review - Permission to edit authored documentation pages - Permission to review or publish the target version, if that is part of your role - A confirmed release label or target version - Review notes that identify which pages need updates It also helps if you are already familiar with Atloria’s project and version navigation. If you need a refresher, read [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces) and [Managing Project Version Workspaces](doc:managing-project-version-workspaces). Those guides explain how to move between the project workspace, version views, and related documentation areas without losing track of the release you are preparing. ## Understanding How Support Agents Appear in Documentation In Atloria, reader-facing support agents are presented as part of the documentation experience rather than as a separate workspace. Readers typically encounter the agent in one of three visible forms: a collapsed help launcher, an open chat panel, or an embedded conversation area attached to the documentation page. The collapsed state gives readers a lightweight entry point so they can continue reading without interruption. When they open it, the panel becomes the main place for asking questions, reviewing answers, and following documentation links. The support agent experience should stay tied to the page the reader is already viewing. In practice, that means the conversation should reflect the current article, section, and documentation context instead of answering in a broad or disconnected way. If a reader opens the agent from a specific help article, the answers should stay grounded in that topic and point back to related documentation pages when possible. This is especially important in versioned documentation, where readers expect guidance that matches the version they are currently reading. Readers may also see several status changes while using the chat experience: - **Collapsed launcher** when the chat is available but not open - **Open conversation panel** after the reader starts or resumes a chat - **Loading state** while Atloria prepares a response - **Escalation or handoff state** when the answer should move to a support route instead of chat - **Unavailable state** when the support agent is not offered on that documentation surface From the reader’s point of view, the most important actions are simple and direct: - Type a question in free text - Choose a suggested prompt or starter question - Open linked articles from the response - Continue the conversation with follow-up questions [SCREENSHOT: Documentation page with collapsed help launcher and open support chat panel] ## Preparing the Documentation Experience for Reader-Facing Support Before you make a support agent visible in Atloria documentation, decide exactly where readers should see it. This is a content and operations decision, not just a placement choice. Some teams want the agent available on article pages only, while others also expose it on landing pages or section home pages where readers are still deciding where to go next. You should also separate public documentation from authenticated documentation so the support experience matches what readers are actually allowed to access. Use this checklist to prepare the experience: 1. **List the documentation surfaces where the agent will appear.** Include article pages, landing pages, and any authenticated documentation areas. 2. **Decide whether public readers and signed-in readers should see the same support experience.** If the content differs by audience, the chat experience should follow that same boundary. 3. **Confirm which knowledge sources are approved for reader-facing answers.** Limit the agent to published documentation, version-specific pages, and any support-approved knowledge collections already used by your team. 4. **Exclude draft or internal-only material.** If a page is not ready for readers, it should not shape the support answers they receive. 5. **Assign ownership.** The Documentation Manager should review article quality and freshness, while the Support Team Lead should review escalation coverage, answer tone, and reader impact. 6. **Define off-limits topics.** In a documentation context, the agent should not handle account-specific changes, billing updates, or requests that require a verified support workflow. If you already set up the agent’s workspace and knowledge sources, use that work as your starting point rather than repeating it here. For setup details, refer to [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup). If you still need to refine tone, behavior, or availability rules, review [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability). [SCREENSHOT: Documentation planning view showing public docs, authenticated docs, and approved knowledge sources] ## Configuring Reader Interactions and Escalation Paths Once you know where the support agent will appear, shape the conversation so it feels relevant to the documentation section the reader is viewing. The first message matters: it should help the reader understand what kinds of questions they can ask and what will happen if the agent cannot answer directly. In Atloria, this usually means tailoring the welcome message, conversation starter text, and suggested questions to the current documentation area rather than using one generic message everywhere. Follow these steps to configure the reader experience: 1. **Set the welcome message** so it matches the current documentation area. On a setup guide, the opening text should invite setup questions. On a troubleshooting page, it should encourage problem-focused questions. 2. **Add suggested questions** that reflect common reader needs. Good examples are task-based prompts that help readers start quickly and stay inside the published documentation flow. 3. **Review direct-answer rules.** The support agent should answer when the documentation clearly covers the topic and the response can point to the right article. 4. **Define escalation triggers.** Use escalation when the answer is uncertain, when the documentation does not fully cover the request, or when the reader clearly needs human review. 5. **Choose the escalation destination** shown in the chat. This may be a support form, a ticket submission step, or another reader-facing support option already used in your documentation workflow. 6. **Check how documentation links appear in answers.** Readers should be able to move from the chat response back into the relevant article without guessing which page to open. 7. **Review citations and recommended articles** to make sure they support the answer instead of distracting from it. A strong embedded support experience does not try to solve every problem inside the panel. It should answer what the documentation supports, then guide the reader to the next best action when chat is not the right path. [SCREENSHOT: Embedded support chat showing welcome message, suggested questions, and escalation option] ## Operating the Agent in a Live Documentation Environment After launch, the support agent becomes part of your day-to-day documentation operations. The most useful signals come from the questions readers ask repeatedly from specific pages. If the same question appears on a setup article, release note, or troubleshooting page, that usually points to a documentation gap. In Atloria, use these conversation patterns to decide whether the article needs clearer steps, better headings, stronger cross-links, or updated version guidance. Use this operating routine to keep the experience healthy: 1. **Review common questions by documentation area.** Focus on pages that trigger repeated support requests or long follow-up threads. 2. **Check answer quality regularly.** Look for responses that are accurate, easy to follow, and clearly tied to the article the reader opened. 3. **Verify citation usefulness.** A linked article should actually help the reader complete the task, not just mention the same topic. 4. **Flag unanswered or weakly answered topics.** These are strong candidates for new articles, article revisions, or improved support prompts. 5. **Coordinate updates between documentation and support owners.** When your team publishes new content, retires old workflows, or changes version coverage, the reader-facing support experience should reflect that change quickly. 6. **Watch escalation patterns.** A high escalation rate from one article often means the page is missing key instructions or the support boundary is too strict. 7. **Track repeated follow-up questions.** If readers keep asking for clarification after the first answer, the article may be technically correct but hard to use. Operational review is most effective when you compare chat behavior with the actual reading experience. Open the same article, ask the same question a reader would ask, and confirm that the response truly helps someone move forward. [SCREENSHOT: Support operations review showing common reader questions and linked documentation pages] ## Setting Reader Expectations and Safety Boundaries Readers should understand from the start that they are interacting with an automated support experience inside Atloria documentation. The disclosure text near the launcher or at the top of the chat panel should make that clear in plain language. It should also set expectations about what the support agent can and cannot do. This is especially important in documentation, where readers may assume the chat can inspect their account, change settings, or confirm environment-specific details even when it cannot. Use these boundaries when defining the reader-facing experience: - The support agent may provide: - Product guidance based on published documentation - Troubleshooting steps already documented for readers - Links to canonical documentation articles - Suggested next reading when the current page is not enough - The support agent should not provide: - Account-specific changes or access decisions - Billing changes or subscription actions - Legal advice or policy interpretation - Guidance for unsupported product versions - Confirmation of tenant-specific settings it cannot verify The chat experience should also redirect or refuse requests in clearly defined cases. If a reader asks for help involving personal data, account ownership, permissions, or actions that require identity verification, the response should move them to the approved support route instead of continuing in chat. The same applies when a reader asks the support agent to perform an action on their behalf. When the agent reaches a boundary, the wording should stay useful. Instead of stopping abruptly, it should explain the limitation and point the reader to the correct next step, such as a support form or documentation article that explains the supported process. [SCREENSHOT: Chat header with automated support disclosure and response showing safe redirection] ## Validating the Experience Before Making It Available Before you release the support agent in Atloria documentation, test it in the same places and conditions your readers will use. Validation should cover both the visible chat experience and the quality of the answers. Do not limit testing to one article type. A support agent that works well on a general overview page may behave differently on a version-specific article, a troubleshooting guide, or a public landing page. Run this validation process before launch: 1. **Open representative documentation pages** across your planned surfaces, including article pages, landing pages, and any authenticated documentation areas. 2. **Confirm the launcher appears correctly** and that the chat panel opens without covering essential page content in a confusing way. 3. **Ask page-specific questions** to verify that responses stay tied to the current documentation topic. 4. **Test high-risk prompts** such as unsupported requests, account-specific questions, and topics that should trigger escalation. 5. **Check documentation links in responses.** Open each linked article and confirm it resolves the reader’s task or at least moves them meaningfully forward. 6. **Verify public and authenticated behavior separately.** Make sure the support experience does not point public readers to content they cannot access. 7. **Review escalation paths.** Confirm that each escalation option works and that the reader does not lose the documentation context that led them there. 8. **Capture failure cases** such as empty answers, irrelevant citations, repeated fallback wording, or unavailable support channels. A short validation table can help your team review results consistently: | Test area | What to confirm | What to flag | |---|---|---| | Launcher and panel | Opens correctly on target pages | Missing launcher, broken panel, blocked page content | | Answer relevance | Response matches current article topic | Generic answer, wrong topic, weak context | | Links and citations | Linked article supports the answer | Broken link, irrelevant article, access issue | | Escalation | Correct route appears when needed | Missing handoff, wrong destination, lost context | [SCREENSHOT: Pre-launch test session on multiple documentation page types] ## Overview This document focuses on the reader-facing side of support agents in Atloria documentation. The goal is not to explain how to create a support agent from scratch, but how to place it into documentation experiences where readers can use it while browsing articles, landing pages, and other help content. In this context, the support agent becomes part of the documentation journey: readers open a launcher, ask a question, review an answer, and move back into the article flow through linked pages and recommended content. The most important decisions in this stage are operational. You need to decide where the agent appears, what published content it can rely on, which questions it should answer directly, and when it should hand the reader off to another support path. You also need to define the visible boundaries of the experience so readers understand they are using an automated assistant and not a human support channel. That includes disclosure text, refusal rules, escalation routes, and answer quality review. This guide also treats validation as part of setup. Before making the support agent available, test how it behaves on real documentation pages and with realistic reader questions. Confirm that the launcher and panel work correctly, that answers stay tied to the current article, and that links and citations lead readers to useful documentation rather than dead ends or unrelated pages. If you need help with the earlier setup work behind the reader experience, refer back to [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents), [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup), and [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability). ## Prerequisites Before working through this document, make sure these pieces are already in place in Atloria: - A support agent has already been created for your documentation use case - The agent’s knowledge sources have already been reviewed and connected to the correct documentation content - Behavior and availability settings have already been defined for the audiences and documentation surfaces you plan to support - You know which documentation areas are public and which are only available to signed-in readers - Your team has agreed on the approved escalation route for questions the support agent should not answer directly - A Documentation Manager and Support Team Lead are both available to review the reader-facing experience before launch - You have access to the documentation pages where the support agent will appear so you can test the launcher, chat panel, and linked articles - You have representative reader questions ready for testing, including normal help requests, unclear questions, and out-of-scope requests It is also helpful to prepare a small review set before testing: - A general article page - A task-based article with step-by-step instructions - A troubleshooting article - A version-specific documentation page - One page in any authenticated documentation area you plan to support If those earlier setup tasks are not complete, start with [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup) and [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability). After you finish the reader-facing work in this guide, continue with [Managing Support Agent Setup and Availability](doc:managing-support-agent-setup-and-availability). ## Understanding enterprise and project analytics views In Atloria, you can review reporting in two places: the **Analytics & Insights** area in the admin workspace for broader reporting, and the analytics page inside an individual project for project-specific detail. Use the admin-side view when you want to look across your documentation program as a whole. Use the project analytics page when you need to understand how one documentation set is performing without the noise of other projects. The main controls are the same idea in both places, even though the scope is different. Start by setting the **date range** so everyone is looking at the same reporting window. If your team uses comparison reporting, turn on the **comparison period** so Atloria shows the selected range beside the previous matching period. When you need to narrow the view, use the **project selector** to move from organization-wide reporting into a single project. This is especially useful when you spot a change in the broader view and want to confirm whether it came from one project or several. Across analytics dashboards, focus on the core documentation signals your team already uses: **page views**, **unique visitors**, **search activity**, and **engagement trends** over time. These numbers help you answer different questions. Page views show overall traffic, unique visitors show reach, search activity shows what readers are trying to find, and engagement trends help you judge whether people are actually using the content. If you already worked through [Using Analytics Reporting Across Enterprise and Project Views](doc:using-analytics-reporting-across-enterprise-and-project-views), the next step is consistency. Keep the same **date range** and **comparison period** selected as you move from the enterprise view into a project page. That way, the project detail stays aligned with the broader report instead of forcing you to mentally recalculate what changed. [SCREENSHOT: Enterprise Analytics view with date range, comparison period, and project selector highlighted] ## Comparing project performance across reporting periods Use this workflow when you want to compare documentation performance across time and across projects. 1. Open the analytics reporting area in Atloria and set the **date range** for the current reporting window. Choose the exact period your team uses for review, such as the current month or quarter. Before you compare anything, confirm that everyone is using the same range. 2. Turn on the **comparison period** so Atloria shows the selected range against the previous matching period. This helps you see whether current results are actually improving or only look strong because you are viewing them without context. A month-over-month comparison is often easier to explain in stakeholder reviews than isolated totals. 3. Use the **project selector** or project comparison controls to review projects side by side. Look at the same metrics for each project rather than switching between different measures. For example, compare **page views** across all selected projects first, then review **unique visitors**, then **search activity**, and then **engagement trends**. 4. Read the change indicators carefully. A positive delta in traffic may show growing interest, but it does not always mean the documentation experience improved. A drop in search activity might mean readers are finding answers faster, or it might mean fewer people are using the project. Pair the change number with the trend chart before drawing conclusions. 5. Flag projects that moved sharply in either direction. Projects with rising traffic and stronger engagement may contain patterns worth repeating. Projects with declining traffic, weaker engagement, or unusual search behavior usually need a closer review at the project level. When you compare projects this way, Atloria helps you separate normal variation from meaningful movement. The key is to keep the same reporting window and comparison logic across every project in the review. [SCREENSHOT: Analytics comparison view showing current period and previous period side by side for multiple projects] ## Reading activity trends to understand documentation usage Trend charts in Atloria are most useful when you read them as behavior signals, not just as lines going up or down. A sharp spike usually means something changed in how people were using the documentation during a short period. That could be a release, a rollout, or a temporary surge in interest. A drop-off can point to reduced usage, but it can also mean readers no longer need to search as much because the content became easier to navigate. A steady upward pattern is often more meaningful than a single high point because it suggests sustained demand. Look at **search activity** beside **page consumption** whenever possible. If searches rise but page engagement stays weak, readers may be trying to find answers and failing to land on useful pages. If one or two pages receive repeated visits over time, those pages may be high-value reference content that deserve extra attention, clearer navigation, or updated examples. If traffic spreads across many pages with stable engagement, the documentation set may already be supporting broader exploration well. Project-level trend views help you decide whether a change is local or widespread. If the enterprise view shows a decline, open individual project analytics pages using the same **date range** and **comparison period**. If only one project shows the same drop, the issue is probably isolated to that documentation set. If several projects move together, the change is more likely tied to a broader documentation program pattern. Be careful with percentage changes. Those numbers only make sense in relation to the selected filters. If you change the **date range** or comparison setting, the trend line and the percentage indicator can tell a very different story. Always confirm the reporting window before discussing whether usage improved, declined, or stayed flat. [SCREENSHOT: Project analytics trend chart with page views and search activity over time] ## Turning analytics findings into documentation improvement work Analytics become useful when you turn them into specific documentation tasks. In Atloria, start by looking for pages or projects with **low engagement** and **declining activity trends**. Those patterns often point to content that is outdated, hard to navigate, too fragmented, or no longer aligned with what readers need. Instead of treating low numbers as a general warning, use them to decide what kind of update is needed: restructure a page, refresh examples, merge overlapping topics, or remove content that no longer serves a clear purpose. A strong signal to watch is **high search activity** combined with weak engagement. That usually means readers are actively looking for answers, but the content they reach is not solving the problem. In practice, this can lead to several actions: - Add missing pages for common topics - Rename pages so they match the terms readers search for - Improve page titles and structure so answers are easier to scan - Consolidate duplicate content that splits traffic and weakens clarity Use the enterprise view to decide where to focus first. If one project is falling behind others on traffic and engagement, move into that project’s analytics page and confirm the pattern with project-level trends. This combination helps Documentation Managers prioritize across the portfolio while giving Project Administrators enough evidence to act inside a single workspace. A simple monthly review workflow works well: - Open enterprise analytics and set the monthly **date range** - Review comparison changes across projects - Select the projects with the biggest declines or the most unusual search patterns - Open each project analytics page with the same reporting window - Record the affected pages, searches, or trend changes - Turn each finding into a backlog item for content updates For a broader prioritization approach, pair this process with [Using Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements). ## Sharing analytics insights with project stakeholders Different stakeholders need different analytics views in Atloria. **Documentation Managers** usually get the most value from the enterprise-level **Analytics & Insights** view because it helps them report on portfolio-wide performance, compare projects, and identify where documentation investment is paying off. **Project Administrators** usually need the analytics page inside a single project because they are making day-to-day content decisions based on what is happening in one documentation set. When you prepare an update, keep the reporting structure consistent. Start with what changed in the selected **date range**. Then show which projects moved the most compared with the **previous matching period**. After that, point to the trend charts or project findings that explain the movement. This sequence makes it easier for stakeholders to understand both the result and the likely reason behind it. A practical structure for stakeholder updates is: - **Reporting period:** the exact date range used in Atloria - **Biggest changes:** which projects increased or declined most - **Key metrics:** page views, unique visitors, search activity, and engagement trends - **Evidence:** trend chart patterns or project-level findings - **Planned actions:** the documentation updates the team will make next Use enterprise analytics when the conversation is strategic, such as deciding which projects need more documentation support, where adoption is growing, or which teams need follow-up. Use project analytics when the conversation is operational, such as deciding which pages to revise, which topics need expansion, or whether a recent documentation change improved usage. If you need more detail on the admin side of reporting, see [Monitoring Administrative Analytics and Activity](doc:monitoring-administrative-analytics-and-activity). [SCREENSHOT: Stakeholder-ready analytics view showing top metrics and project comparison cards] ## Fixing common issues when analytics data is hard to interpret Most analytics confusion in Atloria comes from comparing numbers that were not filtered the same way. If the enterprise dashboard and a project analytics page seem inconsistent, first check the **date range** on both screens. Then confirm the **comparison period** is the same. A project can look stronger or weaker simply because one screen is showing a different reporting window. Another common issue is using an unusual previous period as the baseline. For example, if the earlier period included a release push or a one-time traffic surge, the current period may look like a decline even when normal usage is healthy. Before you label a project as underperforming, ask whether the comparison period reflects a normal baseline. If not, adjust the date range and review a more representative period. Trend spikes can also be misleading. A single sharp increase in page views or searches does not automatically mean long-term documentation improvement. Look for repeated patterns across the chart rather than reacting to one high point. Sustained growth is usually more meaningful than a short-lived spike. Teams also struggle when findings stay too general. Statements like “engagement is down” are hard to act on. Move from the enterprise view into the affected project and identify the specific pages, searches, or time periods connected to the change. That gives the team something concrete to discuss. When results are hard to align, use this checklist: - Match the **date range** across both views - Match the **comparison period** - Check whether the previous period was unusual - Separate one-time spikes from ongoing trends - Tie findings to a specific project, page pattern, or search pattern If your team still disagrees on what the numbers mean, return to the project-level view and anchor the discussion in one documentation set at a time. ## Overview This guide focuses on how to work between Atloria’s broader analytics reporting and project-specific analytics so you can manage documentation performance with less guesswork. The goal is not just to read charts, but to use the same reporting controls across views and make better decisions about where documentation needs attention. You will work mainly with the **Analytics & Insights** area in the admin workspace and the analytics page inside each project. The most important controls are the **date range**, **comparison period**, and **project selector**. These controls shape every metric you see, so they should be set before you start comparing projects or discussing performance changes with other teams. The guide also centers on a small set of metrics that are practical for documentation teams: - **Page views** for overall traffic - **Unique visitors** for audience reach - **Search activity** for unmet or active information needs - **Engagement trends** for ongoing content usage patterns If you already reviewed [Using Analytics Reporting Across Enterprise and Project Views](doc:using-analytics-reporting-across-enterprise-and-project-views), this guide builds on that foundation by showing how to compare reporting periods, read trend movement more carefully, and turn findings into content work. It is especially useful for Documentation Managers overseeing multiple projects and for Project Administrators responsible for improving a single documentation set. Because the **Analytics & Insights** page in the admin workspace is currently presented as a reporting area for usage statistics and performance metrics, some teams may use it first as a navigation point into deeper project review rather than as a complete decision-making screen on its own. That still makes it valuable for spotting where to investigate next. ## Prerequisites Before using this workflow in Atloria, make sure you have the right access and know where you will review reporting. - You can sign in to Atloria and reach the authenticated workspace. If needed, use [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). - You can open the admin workspace and see the **Analytics & Insights** area, or you can open an individual project and access its analytics page. - You know which reporting window your team wants to review, such as a month, quarter, or release period. - You are prepared to compare the same metrics across views instead of changing measures mid-review. - You have enough familiarity with your projects to recognize whether a spike or decline lines up with a release, publishing change, or other documentation event. It also helps to have these roles involved: - **Documentation Managers** for enterprise-level comparison and prioritization - **Project Administrators** for project-level follow-up and content changes For the smoothest review session: - Agree on one **date range** before opening multiple analytics views - Decide whether you will use a **comparison period** - Review enterprise analytics first, then move into project analytics for detail - Capture findings in a backlog or planning list as you go After you are comfortable moving between these views, continue with [Comparing Enterprise and Project Reporting for Documentation Programs](doc:comparing-enterprise-and-project-reporting-for-documentation-programs). ## Opening the Export Center and Choosing an Export Package Type In Atloria, start from the workspace where you are already managing documentation versions or release records, then open the **Export Center**. The Export Center is where you prepare, generate, and track export packages instead of exporting files one by one. If you need help deciding which export is appropriate before you begin, use [Choosing the Right Export for Review Release and Retention](doc:choosing-the-right-export-for-review-release-and-retention). When the Export Center opens, focus on four areas: - the **export type** selector - the **package list** - the **version** or **source** selector - the **validation status** area The **export type** selector is the first decision point. This choice controls what Atloria expects you to provide next. For example, a package meant for documentation sharing will usually center on a selected documentation version and its related files, while a review bundle is aimed at review work and may include review-related materials. A release record archive is used when you want a more complete record package for storage or handoff. As soon as you change the export type, the rest of the screen may shift to match that workflow. Required selections, included content, and the final package structure depend on that choice, so it is worth confirming the export type before you fill in the rest of the form. The **package list** helps you monitor existing entries. Documentation Managers and Project Administrators can use this list to see which packages already exist, who created them, when they were last generated, and whether they are ready, still in progress, or need attention. This is especially useful when several people are preparing exports for the same project or release. [SCREENSHOT: Export Center showing export type selector, package list, source selector, and validation status area] ## Preparing Documentation Versions and Release Records for Export Before you generate anything, make sure the source material is complete. In the Export Center, use the **version picker** or **source selector** to choose the documentation version you want to package. Pay close attention to the version’s status. In Atloria, draft, approved, and published versions are not equivalent for export purposes. A draft version may still be changing, an approved version is usually better for formal review, and a published version is typically the safest choice for external sharing or archival packaging. After choosing the version, select the related **release record** or **documentation set** if the export type requires it. This step matters because the package may pull information from both the version and the release record. Before continuing, verify that the visible metadata is complete. At minimum, confirm the package source shows a clear **title**, **version label**, and **release date** where those details are part of the selected record. Missing labels or dates can make the final export hard to identify later. Next, review the linked materials that Atloria will package with the export. Depending on what is attached to the selected source, this may include: - attached files - generated documents - release notes - other supporting records shown with the version or release entry If something important is missing here, stop and correct the source record before exporting. The Export Center is best used after the documentation version and release details are already in a stable state. Also confirm that you have access to the selected content. If a version is restricted, incomplete, or no longer available in the current workspace, Atloria may block the export or produce an incomplete package. For a more detailed readiness check, see [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). [SCREENSHOT: Version picker with draft, approved, and published versions visible] ## Configuring What Goes into the Export Package Once you have selected the correct source, move to the **package configuration** area. This is where you decide exactly what Atloria should place inside the export package. The available options depend on the export type you chose earlier, but the configuration panel is where you include or exclude the main content groups. Common package components include: - document files - release metadata - attachments - review artifacts Choose only what fits the purpose of the package. For example, a reviewer may need document files and review materials, while an archive package may need a broader record that includes metadata and attachments. You should also set the output details so the finished file is easy to recognize later. Look for options such as **package name**, **version naming pattern**, and **destination format**. Use a naming pattern that clearly identifies the documentation version or release record, especially if your team generates multiple exports for the same project over time. Some exports also let you control supporting content. Review any inclusion settings carefully, especially if you see options related to unpublished notes, historical versions, or supplemental attachments. Including too much can make the package harder to review, while excluding too much can leave out important context. Before you generate the export, use the **package contents preview** if it is available. This preview is your best chance to confirm the package will contain the expected records and that the file structure matches your goal. | Option area | What to check | Why it matters | |---|---|---| | Package name | Clear, recognizable title | Helps reviewers and archive owners identify the file | | Version naming | Correct version label | Prevents confusion between similar releases | | Included components | Documents, metadata, attachments, review items | Ensures the package matches its purpose | | Supporting content | Notes, older versions, supplemental files | Avoids missing context or unnecessary clutter | | Preview | Final contents and structure | Confirms what will actually be generated | [SCREENSHOT: Package configuration panel with inclusion options and contents preview] ## Generating and Downloading Export Outputs After the package settings look right, start the export by clicking **Generate** or **Export**, depending on the action shown in your workspace. Atloria will create the package in the background, and the package status will update as it moves through the process. Watch the status in the package list so you can tell whether the export is still waiting, actively processing, or finished. 1. Open the prepared package entry in the **Export Center**. 2. Click **Generate** or **Export**. 3. Watch the **status** in the package list until it changes to a completed state. 4. Reopen the generated package from the **export history** or package list. 5. Click the available **download** action to save the output file. When you reopen a completed package, review the visible output details before downloading. Atloria may show information such as: - file name - creation date and time - source version - export type These details are useful when you have several exports for the same project. They help you confirm that you are downloading the correct package, especially if one version was generated for review and another for archive storage. If the source documentation changes after an export is generated, return to the same package entry or create a new one, depending on your team’s process. Regenerating after source changes is often appropriate for active review work, but for release archives you may want to keep the earlier package untouched as part of the record. Use the package list and export history to distinguish older outputs from newer ones instead of replacing them casually. [SCREENSHOT: Completed export package with status, file name, timestamp, and download action] ## Validating Packages Before Sharing, Review, or Archiving Before you send a package to reviewers, share it outside your team, or store it as a release archive, use the **validation status** area in the Export Center. This area helps you confirm that the package includes the required documentation files, release details, and attachments expected for that export type. Start by checking whether Atloria shows any warnings or missing items. Common problems include incomplete metadata, missing attachments, or a source version that is not in the right state for the intended use. A package may generate successfully and still be unsuitable for review or archive if important content was excluded or never added to the source record. After the package is generated, open it and inspect the contents directly. Confirm that the folder structure, document names, and version identifiers match what you selected in the package configuration. This is especially important when the package will be handed to people who are not working inside Atloria and will rely entirely on the exported files. Use a simple validation approach based on the destination: - **Reviewer handoff** - Confirm the correct documentation version is included - Check that review-related materials are present if needed - Make sure file names are easy to recognize - **External sharing** - Verify only the intended files are included - Check that version labels and release details are clear - Confirm no internal-only notes were added by mistake - **Long-term archive** - Confirm release details are complete - Check attachments and supporting records are present - Verify naming is stable and easy to trace later If you need a broader export-readiness process before packaging begins, refer back to [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records) and [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). ## Fixing Failed Exports and Incomplete Package Contents When an export fails or the finished package does not contain what you expected, start by reopening the package entry in the Export Center and reviewing the visible source details. Most issues come from three places: incomplete source records, package settings that excluded needed content, or selecting the wrong export type for the job. If Atloria shows validation errors, check the source version and release record first. Missing version metadata, unpublished content, or required attachments that were never added to the selected record can all prevent a complete package. Return to the documentation version or release record, fill in the missing details, then come back and generate the package again. If the package fails during generation, confirm that the export type matches the selected source. A release archive and a review bundle do not expect the same inputs. Also make sure you still have access to the selected documentation version and that it is still available in the workspace. If the version has changed, been replaced, or is no longer accessible to you, the export may not complete. For unexpected contents, open the package configuration again and review every inclusion setting. Look closely at options that control attachments, review artifacts, unpublished notes, and historical versions. Also confirm the selected source version one more time. Many content mismatches happen because a similarly named version was chosen by mistake. When you see duplicate or outdated exports in the package list, compare these details before downloading or redistributing anything: - package timestamp - version label - export type - package name - last generated date Use those details to decide whether you should regenerate the package or keep the earlier file as part of the release history. If you are managing several export rounds for the same version, keep older archive packages separate rather than treating them as disposable copies. ## Overview Atloria’s **Export Center** is the place to assemble complete export packages for documentation versions and release records. Instead of downloading individual files from different screens, you can build a package around a selected source, choose what should be included, generate the output, and then validate it before sending it to reviewers or storing it as part of a release record. This workflow is most useful when you need consistency. A package can combine the main documentation files with release details, attachments, and other supporting materials so the exported result matches a specific purpose. In practice, teams usually use export packages in three ways: - to share documentation with stakeholders - to prepare a review bundle for approval or release work - to preserve a release record archive The key screens and controls in this process are the **Export Center**, the **export type** selector, the **version** or **source** picker, the **package configuration** panel, the **package list**, and the **validation status** area. Together, these controls let you decide what the package is for, which documentation version it should use, what files it should contain, and whether the result is complete enough to distribute. This guide focuses on package management rather than export selection strategy. If you still need help deciding between export approaches, use [Choosing the Right Export for Review Release and Retention](doc:choosing-the-right-export-for-review-release-and-retention). If your main concern is whether a version is ready before packaging starts, see [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions). ## Prerequisites Before you manage export packages in Atloria, make sure the source material and your access are already in good shape. Export packaging works best when the documentation version and any related release record are already organized, labeled, and stable. Check these items before you begin: - Access to the relevant project workspace and its **Export Center** - Permission to view the documentation version or release record you want to export - A selected documentation version that is clearly identified as draft, approved, or published - Required source details such as **title**, **version label**, and **release date** where those fields are part of the record - Any needed attachments, generated documents, and release notes already linked to the source - A clear decision on whether you are creating a sharing package, review bundle, or archive package It also helps if you have already completed the earlier export planning steps covered in: - [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records) - [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving) - [Choosing the Right Export for Review Release and Retention](doc:choosing-the-right-export-for-review-release-and-retention) If you are preparing a formal release package, make sure the version is no longer actively changing before you generate the final export. If you are preparing a review bundle, confirm that the version selected in the **version picker** is the one reviewers are actually expected to assess. Small mistakes at this stage usually lead to duplicate exports, missing files, or review confusion later. ## Finding the Atloria language support pages Before you create a parsing job or start a documentation project, open the **Supported Languages** area in Atloria’s documentation workspace and find the exact technology pages you need. If you already reviewed parser coverage in [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility), use that as background and focus here on locating the right support pages for your current project. In Atloria, users typically rely on two page types: - **Programming language support pages** - **Framework support pages** Start with the language you expect in the repository, then move to the related framework if the project uses one. For example, if your team is documenting an application built with a specific framework, first find the page for the underlying language and then open the page for the framework itself. Use the documentation search and any available navigation filters to narrow the list. Look for the exact page title that matches the technology name instead of relying on memory or team shorthand. This matters when similar technologies appear close together in search results. A reliable way to check that you are on the correct page is to confirm: - The **page title** matches the language or framework you plan to analyze - The page includes **support status** or **parser availability** details - The page appears inside Atloria’s current documentation area, not from an old saved tab If you opened a bookmark, shared note, or older internal reference, refresh your search from within Atloria and reopen the page from the current navigation. That helps you avoid planning work from an outdated support entry. [SCREENSHOT: Supported Languages area showing search results for a language and its related framework] ## Checking whether a language is supported for parsing work Once you open the language support page, look first for the **support status** shown on that page. This is the quickest way to confirm whether Atloria can use that language in code analysis and technical documentation workflows. Do not assume support based only on team experience or a previous project. Always verify the current language page before uploading code or planning automated documentation. On the language page, review the parser details carefully. Focus on what the page says about: - **Parser availability** - **Supported versions** - **Recognized file extensions** - **Known limitations** These details help you decide whether your repository is a good fit for parsing. A language may be supported in general, but your project can still run into issues if it uses a version outside the listed coverage or stores important code in file types that are not included on the page. Compare the language page with the actual codebase your team plans to analyze. Check whether the main source files in the repository match the language listed in Atloria. If the project includes multiple languages, make sure the one you are reviewing is truly the primary language for the documentation work you want Atloria to perform. This is especially useful when teams inherit older repositories or mixed-code projects. In those cases, the project name may suggest one language while the current implementation uses another. The language support page gives you a practical reference point before you move into parsing. If the page shows limitations, note them early and share them with the team. That prevents confusion later when generated technical documentation covers only part of the codebase. [SCREENSHOT: Language support page highlighting support status, parser availability, and file type notes] ## Confirming framework coverage before documenting an application After you confirm that the base language is supported, open the related framework support page. In Atloria, framework coverage depends on the underlying language parser, so checking the framework page without confirming the language first can lead to the wrong expectations. On the framework page, look for whether the framework is marked as: - **Supported** - **Partially supported** - **Not available** That label tells you how much framework-aware structure Atloria is likely to recognize when you parse the repository. A framework page can also include notes about the conventions Atloria understands. These notes are important because framework support is often tied to recognizable project patterns rather than just package names. Review any framework-specific details about items such as: - **Routing patterns** - **Component structure** - **Configuration files** - **Dependency layout** - **Project organization conventions** These notes help you judge whether Atloria will identify the application in a framework-aware way or whether it will only read the code at the language level. That difference matters when you expect generated documentation to reflect application structure instead of just individual files. For example, if the framework page shows only partial support, Atloria may still parse source files successfully but miss some framework-level relationships. In that case, your team may need to review generated output more closely and add manual explanation where needed. Use the framework page as a planning tool, not just a yes-or-no check. If the framework is fully supported, you can move forward with stronger expectations for structured parsing. If support is partial, you can still proceed, but with a narrower scope and a more careful review plan. [SCREENSHOT: Framework support page showing status label and framework-specific recognition notes] ## Interpreting support details before starting a project Support pages are most useful when you read beyond the headline status. Before your team starts a project in Atloria, make sure everyone understands the difference between **full support**, **partial support**, and **unavailable**. Those labels shape what Atloria can reasonably produce during parsing and documentation work. Use the support details to interpret the likely outcome: - **Full support** usually means Atloria is ready to parse the language or framework with broad expected coverage - **Partial support** means some patterns are recognized, but important gaps may remain - **Unavailable** means you should not plan parser-dependent work for that technology Read the notes under the status carefully. They may mention limits such as: - Unsupported language constructs - Incomplete framework detection - Version-specific gaps - Reduced recognition for certain project layouts These notes are where planning decisions become practical. If the page shows partial support or important limitations, you may still proceed, but you should adjust the repository scope or prepare for more manual documentation work. For example, your team might choose to parse only the supported part of a mixed project and document the rest by hand. It also helps to record the confirmed status in project kickoff materials. Include the exact language and framework support result for the project so administrators, project managers, and writers all work from the same expectation. That avoids later disputes about why a parsing run did not produce framework-aware output. When you need a shared reference during planning meetings, the support page itself should be the source of truth. Use the page title, status label, and notes directly rather than relying on verbal summaries. ## Using support information to plan parsing and documentation scope Once you confirm language and framework support in Atloria, use that information to define what will actually be included in the parsing and documentation effort. This is where support pages become part of project planning rather than just a pre-check. Start by mapping confirmed support to the code areas your team wants to bring into Atloria. If your project includes several repositories, modules, or application areas, identify which ones use supported technologies and which ones do not. This helps you avoid assigning automated documentation work to code that Atloria cannot reliably interpret. As you plan scope, flag any gaps early: - **Unsupported languages** - **Partially supported frameworks** - **Mixed-technology repositories** - **Code areas that need manual review** This is especially important for teams working across multiple products or shared repositories. One part of the codebase may be a strong fit for parsing, while another part may require manual documentation from the start. Treat those as separate planning tracks instead of assuming one support result applies to the entire project. Use the support pages to decide whether you should: - Include the full repository in parsing - Limit parsing to supported folders or technologies - Split work across separate projects - Assign manual writing for unsupported areas These decisions also help with staffing. Writers, reviewers, and project leads need to know what Atloria can extract automatically and what still needs human explanation. If the support page shows only partial framework coverage, plan extra review time for structure, relationships, and terminology in the generated output. A short support summary in the project brief can save time later. List the confirmed language page, the framework page, and any limitations that affect scope so everyone starts with the same assumptions. ## Resolving common support-check mistakes A few common mistakes can make a supported technology look broken when the real issue is a mismatch between the repository and the support page. When parsing results do not match expectations, return to the language and framework pages in Atloria and compare the details carefully. If a language appears supported but parsing still fails, check whether the repository actually uses the version or file types listed on the language page. Support may apply only to certain versions or recognized file extensions. A team can easily assume support based on a language name while overlooking the exact coverage notes. If a framework does not appear in results, verify two things: - The **base language** is supported - The **framework page** does not mark support as partial A partially supported framework may allow parsing to run while still missing framework-aware relationships or structure in the output. In that situation, the result is not necessarily wrong—it may simply match the limits described on the page. Disagreements often happen during project planning when one team member says a technology is supported and another says it is not ready. Resolve that by using the exact status and notes on the current Atloria support page as the shared reference. Avoid relying on screenshots from older discussions or copied notes from previous projects. If a required language or framework is not listed at all, stop any parser-dependent planning for that part of the project. Instead: - Record the technology gap in the project notes - Plan manual documentation coverage for that area - Share the gap with the team for product feedback or roadmap discussion [SCREENSHOT: Support page comparison showing language status, framework status, and limitation notes side by side] ## Overview Atloria’s language and framework support pages help you answer three practical questions before parsing code: **Is the language supported? Is the framework recognized? What level of output should the team expect?** This document focuses on using those pages as planning tools inside real documentation workflows. The most important ideas to carry forward are: - Start with the **language support page** - Check the related **framework support page** second - Read the **status label** and the **notes**, not just the title - Use support details to define project scope and review effort These pages are especially useful when your team is preparing a new project, validating repository readiness, or deciding how much of the documentation can be generated automatically. They also help align writers, project leads, and administrators around a shared expectation before work begins. In Atloria, support information is not just reference material. It directly affects how you plan: - Parsing jobs - Documentation coverage - Review effort - Manual writing for unsupported areas If you need broader background on how parser coverage relates to technology fit, return to [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility). For the next step, continue with [Evaluating Language Support Before Parsing Code](doc:evaluating-language-support-before-parsing-code), which builds on these support-page checks and helps you decide whether a specific repository is ready for parsing. ## Prerequisites Before using this workflow in Atloria, make sure you have a few basics in place so the support pages are meaningful for your project planning. You do not need to start a parsing job yet, but you should know what technology you are trying to verify. Have the following ready: - Access to your Atloria workspace and documentation area - The name of the **programming language** used in the repository - The name of the **framework**, if the project uses one - A basic understanding of which repository, module, or code area the team wants to document It also helps if you already know whether the repository contains one technology or a mix of several. That makes it easier to compare the support pages against the actual project structure. Before reading this document, you should already be familiar with parser coverage concepts from [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility). That earlier guide explains the broader meaning of coverage and compatibility. Here, the focus is narrower: finding the correct support pages and using their status details to make planning decisions. You are ready to use this guide if you can answer these basic questions: - Which language is the main implementation language? - Which framework, if any, sits on top of that language? - Which codebase does the team want to parse in Atloria? With that information in hand, you can use Atloria’s support pages to verify parser availability, confirm framework coverage, and set realistic expectations before moving on to [Evaluating Language Support Before Parsing Code](doc:evaluating-language-support-before-parsing-code). ## Opening the enterprise and project analytics pages In Atloria, you can work with analytics from two places: the **Analytics & Insights** page in the admin area and the analytics page inside an individual project. Use the admin workspace when you want to review activity across multiple projects. Open a project analytics page when you need to investigate one documentation workspace in detail. To reach the enterprise view, open the main app area, go to the admin workspace, and select **Analytics**. The page header shows **Analytics & Insights**, which confirms you are looking at reporting for the broader organization view rather than a single project. From there, you can review overall usage statistics and move into project-specific follow-up work. To reach a project analytics page, open **Projects**, choose the project you want to review, and then open its analytics area. If you already worked through project-level reporting in [Comparing Project Performance in Enterprise Analytics](doc:comparing-project-performance-in-enterprise-analytics), use the same project navigation path here and focus on how those project results compare with the enterprise view. When both views are available, look for the page-level reporting controls before you compare anything. In Atloria, this usually means checking the selected reporting period first, then confirming whether you are viewing all projects or one project. Metric cards and charts only make sense when both pages are using the same time window. Keep this distinction in mind: - **Enterprise analytics** shows combined reporting across projects. - **Project analytics** shows activity for one selected project only. If Atloria keeps your current reporting period as you move between views, confirm that the same date range still appears after switching pages. If the project page opens with its own separate date filter, set that filter manually before comparing totals, trends, or engagement results. [SCREENSHOT: Enterprise Analytics & Insights page header and a project analytics page with the reporting period highlighted] ## Reading performance metrics in the enterprise view The enterprise analytics page is where you read broad documentation performance across Atloria workspaces. Start with the summary cards at the top of the page. These cards are designed to give you a quick read on overall activity, including measures such as total views, unique visitors, searches, and engagement-related results. Read these cards together instead of in isolation. For example, high views with weak engagement can point to content that attracts attention but does not help readers continue. Below the summary area, use the charts to understand movement over time. Enterprise charts combine activity from multiple projects into one reporting view, so they are useful for spotting spikes, drops, and steady patterns across the organization. When you move your pointer over a point, bar, or other chart marker, Atloria reveals the exact value for that period. This is the easiest way to confirm whether a change is minor or large enough to investigate. The date range control is especially important in the enterprise view. Change the reporting window from a shorter period, such as the last 7 days, to a broader period, such as the last 30 days, and watch how the cards and charts update. This lets you compare recent movement against a longer baseline without leaving the page. If a project looked unusually strong or weak in a short window, the longer range helps you see whether that result is part of a trend or just a temporary spike. If the enterprise page includes ranked lists or tables, use them to identify where follow-up work matters most. These lists often surface projects with the highest traffic or the weakest performance. That makes them a practical starting point when you need to decide which project to open next for a closer review. [SCREENSHOT: Enterprise analytics summary cards and trend chart with a hovered value tooltip] ## Drilling into a project to investigate changes Once you spot a change in the enterprise view, move into the related project analytics page to find the cause. In Atloria, you may start this drill-down from a project list, a ranked table, or a project selector, depending on what is shown on the enterprise page. Open the project that stands out, then review its analytics using the same reporting period you used in the broader view. Begin with the project-level metric cards. These should help you answer a simple question: is the enterprise change really coming from this project? Compare the project’s views, visitors, searches, and engagement indicators against what you noticed in the enterprise dashboard. If the project cards show the same rise or decline, you have likely found a meaningful source of the broader trend. If they do not, return to the enterprise page and check another project from the ranked list. Next, move down to the project charts and content-level reporting. Project analytics is where you can see whether the trend is tied to specific documentation pages, repeated searches, or reader actions inside that project. For example, a traffic increase might come from one highly visited page, while a drop in engagement might be tied to a small group of pages that readers leave quickly. Search activity can also reveal missing topics when the same terms appear repeatedly without strong follow-up engagement. Before you draw conclusions, verify the date range again. A project page may carry over the enterprise reporting period, but it may also open with its own saved or default date filter. If the enterprise page is showing the last 30 days and the project page is showing a shorter period, the comparison will be misleading. Matching the reporting window is the fastest way to avoid false conclusions. [SCREENSHOT: Project analytics page with summary cards, trend chart, and content-level table] ## Comparing projects to find where improvement work matters most Use the enterprise view when you need to compare projects side by side and decide where documentation work will have the biggest effect. Start with ranked metrics, project filters, and trend charts. These views help you separate projects that are simply busy from projects that are both busy and performing well. A project with high traffic is not automatically healthy if readers are searching repeatedly, leaving quickly, or showing weak engagement after landing on key pages. Look for patterns such as these: - High traffic with weak engagement - Strong search volume with signs that readers are not finding answers - Declining usage in one project while similar projects remain stable - One project consistently underperforming in the same period where others improve When you find an outlier, switch from enterprise totals to that project’s analytics page. This confirms whether the issue is isolated to one documentation set or reflects a broader pattern across Atloria. For example, if several projects show the same drop, the problem may be larger than a single project. If only one project shows the decline, the issue is more likely tied to its content, structure, or recent changes. A practical review flow for Documentation Managers is: 1. Open **Analytics** in the admin workspace and set the reporting period. 2. Review summary cards, charts, and ranked project results to spot outliers. 3. Open the project analytics page for the project with the clearest risk or opportunity. 4. Confirm whether the project-level cards and charts support the enterprise signal. 5. Prioritize the project where the combination of traffic and weak performance suggests the largest documentation impact. This approach keeps your review focused on the projects where improvement work is most likely to help the most readers. ## Using analytics signals to prioritize documentation updates Analytics becomes useful when you turn it into specific documentation work. In Atloria, start by connecting a weak metric to a visible content problem. If a page attracts traffic but readers do not continue, that page may need clearer instructions, better structure, or stronger links to related topics. If the same searches appear repeatedly, the project may be missing content that readers expect to find. If engagement drops after a navigation change, the project structure may need adjustment. For Project Administrators, the project analytics page is the best place to decide what kind of update to make. Use page-level and search-level results to choose between actions such as: - Updating a single article that draws traffic but does not hold attention - Reorganizing navigation when readers appear to struggle across several related pages - Adding missing content when repeated searches point to unanswered questions - Reviewing version or publishing decisions if usage changed after a release Documentation Managers should use the enterprise view differently. Instead of focusing on one article, look for patterns that repeat across projects. If several projects show the same weakness, the fix may be broader than a single page. You may need a shared content standard, a navigation rule, or a cross-project review process. Enterprise reporting helps you decide whether to invest in one project, a recurring documentation pattern, or a governance issue affecting multiple teams. When you record your decision, keep the baseline consistent. Note the reporting period, the metrics you compared, and the projects affected. That way, your next analytics review uses the same frame of reference and you can tell whether the update actually improved performance rather than simply reflecting a different date range. ## Fixing mismatched results between enterprise and project reports If enterprise and project results do not line up, start with the simplest explanation: the two pages are not showing the same scope. In Atloria, enterprise reporting can include multiple projects, while a project analytics page shows only one project. A difference in totals does not always mean something is wrong. When enterprise totals do not match a project page, check these items first: - The selected **date range** on both pages - Whether the enterprise view includes additional projects - Whether you opened the correct project from the project list or selector - Whether the pages are showing the same chart interval, such as day, week, or month A project that appears to have no activity often turns out to be the wrong project selection or the wrong reporting period. Reopen the project from the list, confirm the project name, and make sure the selected period includes time when the documentation was actually published and used. If the date range is too narrow, the page can appear empty even when the project has meaningful activity outside that window. If trend lines look inconsistent, compare the chart grouping. One page may summarize activity by day while another shows a wider weekly or monthly grouping. The shape of the trend can look different even when the underlying activity is related. Hover over chart points or bars to compare exact values instead of relying only on the line shape. You may also notice that a metric changes after switching views. This can happen because enterprise reporting uses combined calculations, while the project page may show more detailed content tables underneath. Review both together: the enterprise page tells you where to look, and the project page explains what inside that project is contributing to the result. [SCREENSHOT: Enterprise and project analytics pages side by side with matching date ranges and project selection highlighted] ## Overview This guide focuses on using the **Analytics & Insights** page in the admin workspace together with analytics inside individual projects. The goal is not just to read numbers, but to move between both views in a way that helps you understand where documentation performance is changing and what deserves attention first. Use the enterprise view when you need a broad picture across projects. That page is best for spotting traffic shifts, comparing projects, and identifying outliers that deserve follow-up. Use the project view when you need detail. That is where you can inspect the pages, searches, and project-specific trends behind a change you first noticed at the enterprise level. This document builds on the comparison approach introduced in [Comparing Project Performance in Enterprise Analytics](doc:comparing-project-performance-in-enterprise-analytics). Here, the focus is narrower: how to move between enterprise totals and project detail without losing track of reporting scope, date range, or the reason you started the review. The most effective workflow in Atloria is usually: 1. Set a reporting period in the enterprise analytics page. 2. Review summary cards, charts, and project rankings. 3. Open a project with unusual performance. 4. Confirm the same reporting period in the project analytics page. 5. Use project-level detail to decide what documentation work should happen next. This approach helps both Documentation Managers and Project Administrators make decisions based on the same reporting window and the same set of visible indicators. It also reduces the risk of acting on a misleading comparison caused by different filters or a different project selection. ## Prerequisites Before you use this workflow in Atloria, make sure you have access to both the admin analytics area and the projects you need to review. If you can open **Analytics** in the admin workspace and also open individual projects from **Projects**, you have the navigation access needed for this guide. You will get the most value from this process if the following are already in place: - You can sign in to Atloria and reach the main app area - You can open the admin workspace and see **Analytics & Insights** - You can open at least one project and access its analytics page - Your projects already have published documentation or reader activity to review - You are comfortable switching between enterprise reporting and project workspaces It also helps to decide on a reporting period before you begin. For example, you might review the last 7 days for short-term changes or the last 30 days for a broader trend check. Using one agreed period across both pages makes your comparisons much more reliable. If you need help getting into Atloria or moving around the admin area first, see: - [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) - [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems) - [Using the Admin Workspace](doc:using-the-admin-workspace) - [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity) For the next step in this analytics reporting sequence, continue with [Managing Enterprise and Project Analytics for Documentation Performance](doc:managing-enterprise-and-project-analytics-for-documentation-performance). ## Reviewing the parsing outputs that feed documentation In Atloria, the parsing workspace gives documentation teams a source-based view of what was found in the uploaded code. After you have already uploaded code and reviewed the initial results in [Uploading Code and Reviewing Parsing Results](doc:uploading-code-and-reviewing-parsing-results), the next step is to focus on the result details that directly affect your documentation. Look for the parsed symbol list, the symbol type or kind, the source file location, the declaration details, any available comments from the source, and the relationship or dependency views tied to each item. These result sets help you separate what came directly from the source from what Atloria later turns into generated reference content. The parsed results are the raw extracted facts. Generated reference pages are the reader-facing pages built from those facts. Names, declaration details, source locations, and source comments should stay aligned between both views. If a generated page shows something different, that is a sign you need to review the parsing results before updating documentation. When you inspect relationships, use the symbol detail view to see how one item connects to another. This is where writers can understand whether a source item belongs under a larger module area, whether it contains child items, or whether it depends on other parts of the codebase. Relationship views are especially useful before drafting a guide, because they show whether a topic stands alone or needs links to related reference pages. Dependency views add another layer. They help you see which files or packages feed into a source item and which ones rely on it. If one item has many incoming or outgoing connections, it usually needs stronger explanation, clearer related links, or a broader conceptual page. [SCREENSHOT: Parsing results screen showing symbol list, source file column, comments, and relationship panel] ## Mapping symbols and relationships to documentation coverage To improve documentation coverage in Atloria, start by turning the parsing results into a working inventory. The goal is not to document every parsed item in the same way. Instead, use the parsed list to sort what belongs in public reference content, what belongs only in internal team review, and what appears to be exported but still has no documentation coverage. This gives you a practical way to compare source reality against what readers can actually find in your project. A simple coverage review usually works best when you group parsed items into categories like these: | Coverage group | What to look for in Atloria | Documentation action | |---|---|---| | Public reference items | Exported items that appear in generated reference sections | Verify names, details, and links | | Internal-only items | Parsed items that should not appear in reader-facing docs | Confirm they stay excluded | | Missing coverage | Exported items with no matching page or mention | Add reference coverage or feature guidance | Parent-child relationships help you decide where content belongs. If one parsed item clearly contains several related child items, that often points to a reference page with subsections. If a larger source area connects to several behaviors or workflows, that may belong in a conceptual guide or task-based article instead of a narrow reference page. Relationship views also help you avoid scattering related content across too many pages. Use dependency links to spot features that span multiple files. A reader may see one public item in a reference page, but the parsing results may show that it relies on shared configuration, supporting types, or other linked source areas. That is often a sign to add cross-links, expand a feature guide, or include a short explanation in a project-level technical page. As you review, compare parsed exported items against your reference navigation, existing technical pages, and manually written guides. This creates a reliable coverage checklist based on the code already present in Atloria. ## Checking generated reference pages against the source material Generated reference pages in Atloria should reflect the latest parsing results as closely as possible. When you open a reference page, compare what readers see with the parsed source details that feed that page. Focus on the visible fields that matter most to readers: the item name, declaration details, listed inputs or parameters, returned values, inheritance or implementation notes, source comments, and related links. If any of those differ from the parsing results, the page may be outdated or incomplete. 1. Open the generated reference page for the item you want to verify. 2. Open the matching parsed result in the code parsing workspace. 3. Compare the displayed name and declaration details between both views. 4. Check whether listed parameters, return information, and relationship notes still match the parsed result. 5. Review any source comments or descriptive text that Atloria pulled into the page. 6. Confirm that related links point to real, current items that still exist in the parsed results. 7. If you find a mismatch, update the parsing run or documentation workflow before publishing changes. This check becomes especially important after refactors, renames, or file moves. A generated page may still exist in navigation even though the source item changed location or structure. If the parsing results show the latest declaration but the page still shows an older version, treat the parsed result as the source of truth for validation. You should also watch for stale relationship details. If a page says an item extends, implements, or links to another source item, confirm that the same relationship still appears in the parsed results. This helps prevent broken reference trails and misleading “See also” sections. [SCREENSHOT: Side-by-side view of a generated reference page and the matching parsed result] ## Using dependency views to strengthen cross-references and architecture docs Dependency views in Atloria are useful well beyond reference validation. They also help you decide where your documentation needs stronger cross-references and where architecture-focused content is missing. When one source area has many incoming references, that usually means it plays a central role in the project. Those high-traffic areas often need clearer explanation in technical guides, stronger ownership notes, and better links from surrounding pages. 1. Open the dependency view for a parsed item or source area you are reviewing. 2. Look for items with many incoming references, since these often need stronger conceptual coverage. 3. Review outgoing dependencies to see what supporting items must be understood alongside the main item. 4. Add or improve links between reference pages, setup guides, and architecture pages where those connections matter. 5. Flag dense or circular dependency patterns for documentation follow-up, especially if readers would struggle to understand the flow without extra context. Outgoing dependency chains are especially helpful when you are writing onboarding or architecture content. They show that a reader may need more than one page to understand how a feature works in practice. If a source area depends on several supporting packages or shared utilities, your documentation should not leave that context hidden inside reference pages alone. Instead, connect the detailed page to a broader explanation that shows setup order, integration points, or shared responsibilities. Dense dependency clusters can also reveal documentation gaps. If several important items all connect through a shared utility or adapter layer, but that shared layer has little or no explanation in Atloria, readers may struggle to understand the bigger picture. Use those patterns to improve cross-links between technical reference pages, project architecture content, and task-based tutorials. [SCREENSHOT: Dependency view highlighting a central source area with multiple incoming and outgoing connections] ## Building a repeatable review workflow for writers and documentation managers A one-time parsing review is useful, but Atloria works best when your team turns that review into a repeatable documentation workflow. The most reliable approach is to review parsing results whenever your team reaches a release point, completes a major merge, or refreshes generated reference content. That way, documentation quality does not depend on someone noticing a mismatch by chance. 1. Set a regular review point after major merges, release preparation, or reference regeneration. 2. Rerun parsing for the project workspace at that review point. 3. Compare the latest parsing results with existing reference pages and technical guides. 4. Flag newly added exported items, removed items, and changed declarations for documentation review. 5. Assign follow-up work to the right people based on the issue type. 6. Check publishing criteria before approving updated documentation. In practice, writers and documentation managers usually focus on different parts of the review. Writers can inspect missing descriptions, weak related links, and gaps between parsed source items and reader-facing pages. Documentation managers can track coverage by project area, module area, or documentation section and decide whether the release is ready to publish. A simple acceptance checklist inside your team process should include: - No undocumented public-facing parsed items that are meant to appear in reference content - No broken source links in generated pages - No visible declaration mismatches between parsed results and published reference pages - No missing cross-links for major related items Store your coverage reports, review notes, and parser snapshots with the rest of your documentation work in Atloria. That history makes it easier to see when a page stopped matching the source and to explain why a change was made. ## Fixing common mismatches between parsing results and published docs When parsing results and published documentation do not match in Atloria, the fix usually starts with identifying which visible part is wrong: the parsed result, the generated page, the relationship links, or the coverage report. Most issues fall into a few repeatable patterns, and each one can be checked from the screens your team already uses for parsing review and documentation publishing. 1. If a generated reference page shows outdated declaration details, rerun parsing for the project and then review the refreshed reference output. 2. If the same item still looks outdated, check whether the source file location in the parsed results matches the current source file you expect. 3. If a documented item is missing from the reference set, review whether it appears in the parsed results at all before changing the documentation page. 4. If related links point to the wrong pages, inspect the current relationship view and confirm the linked items still exist in the latest parsed results. 5. If coverage reports show items that should stay internal, review your team’s inclusion and filtering decisions before adding public documentation. Use this table to guide your review: | What you see | Where to check in Atloria | Likely next action | |---|---|---| | Outdated declaration details on a reference page | Parsed result and generated page | Rerun parsing and refresh generated content | | Missing documented item | Parsed symbol list and coverage view | Confirm the item is included in parsing results | | Wrong related links | Relationship view and dependency view | Rebuild or correct linked documentation paths | | Internal-only item flagged as missing coverage | Coverage report and reference inclusion rules | Exclude it from public documentation targets | When you work through mismatches this way, you avoid editing the wrong page first. Always confirm what the latest parsing results show before deciding whether the problem is in the source-derived content, the generated reference page, or the coverage rules your team is using. ## Overview This guide focuses on how documentation teams use code parsing results inside Atloria to improve technical documentation quality. It assumes you already know how to upload code and inspect the first round of parsing output, as covered in [Uploading Code and Reviewing Parsing Results](doc:uploading-code-and-reviewing-parsing-results). Here, the emphasis shifts from “What was parsed?” to “How do we use those results to improve what readers see?” In Atloria, parsing results are useful for three documentation jobs: checking coverage, validating generated reference pages, and improving cross-links between technical pages. The parsed symbol list helps you see what source items exist. Relationship views help you understand how those items connect. Dependency views help you identify which topics need broader explanation because they sit at the center of a feature or architecture area. This guide also helps you distinguish between source-derived parsing output and the generated reference pages built from it. That distinction matters because a page can look complete while still being out of date. By comparing the parsed results with published or draft reference content, you can catch stale names, outdated declaration details, missing related links, and gaps in coverage before those issues reach readers. You will also see how to turn parsing review into a repeatable team workflow. Instead of treating code parsing as a one-off import step, Atloria lets writers and documentation managers use it as an ongoing quality check for technical documentation. The result is more accurate reference content, clearer architecture guidance, and better navigation between related technical topics. ## Prerequisites Before using this workflow in Atloria, make sure you already have access to the project workspace where code parsing results are available. You should also be comfortable opening parsed results, reviewing generated technical pages, and moving between project documentation areas. If you have not done that yet, start with [Uploading Code and Reviewing Parsing Results](doc:uploading-code-and-reviewing-parsing-results). You will get the most value from this guide if the following are already in place: - A project in Atloria with completed code parsing results - Access to the code parsing workspace for that project - Existing generated reference pages or technical documentation to compare against parsing results - Permission to review or update documentation content in the project - A basic understanding of your team’s documentation structure, such as reference pages, feature guides, and architecture pages It also helps if your team already has a release or review rhythm. This guide includes a repeatable review process, and that process works best when you can tie parsing checks to regular documentation updates, version work, or release preparation. If you are reviewing documentation with other team members, agree in advance on which parsed items should appear in public-facing technical content and which ones should stay out of reader navigation. That makes coverage checks much faster and reduces confusion when Atloria shows parsed items that are not meant to become published reference pages. From here, continue with [Uploading Code and Running Parsing Workflows](doc:uploading-code-and-running-parsing-workflows) to connect this review process to a broader parsing routine. ## Defining a Shared Screenshot Library Structure In Atloria, a shared screenshot library works best when your team organizes images the same way every time. Start by separating screenshots at the highest level by the categories your writers actually search for most often: product, release or version, language, and interface theme. For example, teams usually look for a screenshot based on the feature area and release first, then narrow it down by language or light and dark theme. If your library includes folders or collections, keep those top-level groupings broad and predictable so writers do not have to guess where a reusable image belongs. A consistent naming pattern makes the library easier to search, especially when the same screen appears in several guides. A practical format is **product-area-screen-state-version-language**. That pattern helps writers recognize whether an image shows a dashboard, settings page, dialog box, or completed workflow state before they open it. Naming is most useful when it reflects what a person sees on the screen, such as a navigation panel, setup page, or confirmation dialog. Keep different image types in separate library locations so writers can choose the right file quickly: - **Source captures** for original, unedited screenshots - **Edited versions** for screenshots with callouts, highlights, or masking - **Web-ready exports** for optimized images used in published documentation Metadata matters just as much as folders. When Atloria shows fields for asset details, use them consistently. The most useful fields for reusable screenshots are: | Field | What to record | Why it helps | |---|---|---| | Owner | The person responsible for the image | Helps writers know who to ask before reusing or replacing it | | Capture date | When the screenshot was taken | Makes outdated images easier to spot | | Product release | The release shown in the image | Prevents reuse in the wrong version | | Approval status | Draft, approved, superseded, or archived | Shows whether the image is safe to publish | [SCREENSHOT: Shared screenshot library showing folders by product, version, language, and theme] If your team already uses project-based screenshot workflows, keep that process aligned with the shared library rather than replacing it. For project and version coordination, refer to [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). ## Setting Up Roles, Permissions, and Contribution Rules A shared library only stays useful when everyone follows the same contribution rules. In Atloria, your team should decide who can upload screenshots, who can edit metadata, who can approve assets for reuse, and who can archive outdated images. These responsibilities usually follow documentation team roles rather than project ownership. A common setup looks like this: | Role | Typical access in the library | |---|---| | Documentation Manager | Approve, replace, archive, and manage folder structure | | Technical Writer | Upload, edit details, and submit assets for review | | Reviewer | Check accuracy, metadata, and approval status | | Designer | Upload edited variants and maintain annotation consistency | Before anyone uploads a screenshot, require a contribution check so the library does not fill up with inconsistent images. Your checklist should cover the visible quality of the image and the information entered with it. Useful checks include: - Approved image resolution - Browser or device label - Redaction review for hidden or masked fields - Alt text entry - Correct version or release label - Correct language and theme - Clear title and searchable tags Use restricted folders or approval-only collections for screenshots that are still under review. This prevents unreviewed images from being reused in published pages just because they appear in search results. If Atloria shows approval status in the asset details, make sure only approved items are treated as reusable team assets. Set one rule for replacements and one for new versions. A Documentation Manager may replace an existing approved asset when the screenshot is clearly the same screen in the same context and only needs a current refresh. Writers should create a new version instead when the workflow, layout, menu labels, or release context has changed enough that teams may still need the older image for another guide. That approach preserves image history and avoids breaking documentation that still depends on an earlier release. [SCREENSHOT: Screenshot asset details showing approval status, tags, owner, and restricted collection placement] ## Capturing and Uploading Screenshots for Reuse When you capture a screenshot for the enterprise library in Atloria, focus on whether another writer could reuse it without asking follow-up questions. The image should match the intended documentation scenario exactly, including the correct product version, the right user role, and sample data that looks realistic but safe to share. If the screen changes based on permissions, make sure the visible menus, buttons, and page content match the audience for the guide you are supporting. 1. Open the target page in the correct version and confirm the screen shows the right workflow state, such as an empty form, completed setup, confirmation message, or selected menu. 2. Capture the image with the expected browser or device view your team has agreed to use. 3. Edit the image before upload if needed. Crop away browser chrome if your team does not document it, mask sensitive values, and only add callouts when the guide truly needs them. 4. Upload the screenshot to the shared library in Atloria. 5. Complete the required asset details so other writers can find and trust the image later. When Atloria prompts for image details, fill in every field your team relies on for search and reuse. The most helpful fields usually include: - **Title** - **Tags** - **Product area** - **Release number** - **Usage notes** - **Language** - **Theme** - **Owner** - **Approval status** Place the image in the collection or folder that matches the feature area, not just the project where you captured it. For example, if the screenshot shows a settings page used across several documentation sets, store it with other settings-related assets instead of burying it under one project name. That makes the library useful across teams, not just for the original author. Use usage notes to explain anything another writer cannot see directly in the image, such as “captured with admin-level navigation visible” or “shows onboarding after final confirmation step.” [SCREENSHOT: Upload screen for a screenshot asset with title, tags, product area, release number, and usage notes fields] ## Finding Approved Images Across Multiple Documentation Projects In Atloria, the fastest way to reuse screenshots across projects is to search with a combination of folder location, tags, and metadata filters instead of browsing one project at a time. Start with the feature area or screen type, then narrow the results by version, language, and theme. If your team documents both light and dark interface styles, always check the theme filter before selecting an image. The same is true for localized content—an approved English screenshot may not be suitable for a guide in another language. When you open a screenshot record, compare the available variants before adding it to a page or knowledge base article. Many teams keep three related versions of the same image: - The original source capture - An annotated version with callouts or highlights - The latest approved reusable version Look at the asset details and confirm that the approved version matches your guide’s release and audience. If the image includes notes about user role, setup state, or hidden fields, read those before reusing it. This is especially important when a screen looks similar across several workflows but the visible buttons or menu labels differ slightly. To avoid duplicate captures, search the library before taking a new screenshot. Check for matching navigation screens, dialogs, setup pages, and completed workflow states. Writers often create duplicates because they search by project name instead of by feature area or screen purpose. A shared library works better when teams search for the screen itself, not the document it originally supported. Usage notes and linked project references are your final check. If an asset record shows where the screenshot has already been used, you can judge whether it is safe to reuse in another publication. A screenshot already used in multiple approved guides is often a better choice than a newly uploaded image with no review history. [SCREENSHOT: Library search results filtered by version, language, theme, and approval status] ## Keeping Screenshot Libraries Current as Products Change A screenshot library becomes unreliable quickly if nobody reviews it after product updates. In Atloria, treat screenshots as versioned documentation assets, not one-time image files. Each time your team prepares content for a new release, compare existing screenshots against the current interface. Pay close attention to renamed menu items, updated icons, changed button labels, new page layouts, and revised forms. Even small visual changes can make a guide feel outdated. Use version labels and replacement workflows to keep the library current without losing history. When a screenshot is no longer the best choice for current documentation, do not simply overwrite it without review. Instead, update its status and connect the replacement image clearly so writers can see which asset is current. Archive folders are useful for older screenshots that still need to remain available for previous releases or older published versions. High-change areas need a regular review cadence. Teams usually review these areas more often: - Dashboards - Settings pages - Onboarding flows - Navigation menus - Multi-step setup screens A simple status model helps everyone understand what to use: | Status | Meaning | |---|---| | Draft | Uploaded but not ready for reuse | | Approved | Cleared for use in current documentation | | Superseded | Replaced by a newer approved image | | Archived | Retained for history, not for current content | When Atloria shows status in the asset record, use it consistently. Writers should only insert screenshots marked **Approved** for the correct release. Reviewers and managers should move older assets to **Superseded** or **Archived** as soon as a newer image becomes the standard. This prevents outdated screenshots from continuing to appear in search results as if they were current. [SCREENSHOT: Screenshot library asset history showing approved, superseded, and archived statuses] ## Fixing Common Library Management Problems Most screenshot library problems in Atloria come from inconsistent naming, incomplete metadata, or unclear approval status. When duplicate assets appear, compare the file names, tags, capture dates, and release labels first. If several images show the same screen and one is already approved, treat that approved item as the master image. Update usage so writers reuse the approved record instead of continuing to upload near-identical copies. Inconsistent screenshots are another common issue. A guide may look uneven when one image uses a dark theme, another uses a light theme, and a third was captured at a different zoom level or with different sample data. Fix this by enforcing capture presets and checking those details during review. If a screenshot does not match the team standard, return it for correction before approval rather than letting the inconsistency spread across more pages. Writers also struggle when they cannot find assets that already exist. In most cases, the problem is not the image itself but the library details attached to it. Review these fields when search results seem incomplete: - Folder or collection placement - Tags - Product area - Version or release field - Language - Theme - Approval status If those details were entered incorrectly, update the asset record so the screenshot appears in the right searches and filters. This is often faster than creating a replacement image. For outdated screenshots already used in published documentation, trace where the superseded asset is still referenced and replace it with the current approved version. Linked usage references are especially helpful here because they show which pages, projects, or documentation sets still depend on an older image. Once those references are updated, move the old screenshot to **Archived** if it is no longer needed for past releases. If your team is dealing with missing or mismatched screenshots across versions, the troubleshooting steps in [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions) are the best companion reference. ## Overview This guide focuses on how documentation teams use a shared screenshot library in Atloria to support multiple projects, versions, and publications without recreating the same images repeatedly. The goal is not just to store screenshots, but to make them easy to find, safe to reuse, and clearly marked so writers know which image belongs in current documentation. You will work with a few core practices throughout this guide: - Organizing screenshots by product, version, language, and theme - Applying consistent titles, tags, and usage notes - Separating source captures from edited and web-ready images - Using approval status to control what can be reused - Replacing or archiving outdated screenshots as the interface changes This guide assumes your team is already working with screenshot processes at the project and version level. If you need help with that foundation first, read [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). That guide explains how screenshot work fits into release-based documentation workflows. Here, the focus is broader: building a reusable enterprise library that supports many writers and many doc sets at once. In Atloria, this work usually involves the screenshot library views, asset detail screens, upload forms, folder or collection organization, and approval status tracking. You do not need to set up every rule at once, but your team should agree on naming, metadata, and review rules before the library grows too large. A well-managed library saves time, reduces duplicate captures, and helps teams keep screenshots visually consistent across documentation. ## Prerequisites Before using a shared screenshot library in Atloria, make sure your team has a few basics in place. This guide assumes you already have access to the areas where screenshots are uploaded, reviewed, and reused. It also assumes your team has agreed on at least a simple documentation workflow for how screenshots move from capture to approved reuse. You should have: - Access to Atloria with permission to view the screenshot library - The ability to upload screenshots or edit screenshot details, if that is part of your role - A team standard for image naming, version labels, and approval status - Agreed rules for themes, languages, browser or device views, and annotation style - Sample data that is appropriate for screenshots and safe to share in documentation - A clear understanding of which screenshots are source captures and which are edited or web-ready variants It also helps if your team already knows how screenshots are used inside documentation pages and release workflows. If you need that background, start with [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) and [Organizing Screenshots for Documentation and Releases](doc:organizing-screenshots-for-documentation-and-releases). For teams working across many projects, you may also want to confirm who is responsible for approvals, replacements, and archiving before you begin. Without that ownership, libraries tend to fill up with duplicate or outdated images. If your organization manages permissions centrally, the related admin guidance in [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) may help you align screenshot contribution rules with team responsibilities. The next step in this screenshot series is [Managing Screenshot Workflows Across Documentation](doc:managing-screenshot-workflows-across-documentation), which expands this library-focused approach into broader documentation operations. ## Reviewing project health from the Analytics dashboard In Atloria, open your project workspace and go to the **Analytics** area for that project. This screen is where you review activity patterns and spot documentation areas that may need follow-up. If your project includes both project-wide and page-focused views, start with the broader project view to understand overall health, then move into page-level results to see which pages are driving the numbers. [SCREENSHOT: project Analytics screen showing project-level summary and page-level results] Look for the main indicators at the top of the Analytics screen or in the first summary cards. Focus on counts that help you judge documentation health, such as: - total pages in the project - recently updated pages - stale content - unresolved issues These numbers help you answer practical questions quickly. A healthy project usually shows steady recent updates, a manageable stale-content count, and unresolved issues moving down rather than up. If the stale content number is high, or if recently updated pages are low compared with the total page count, that is a sign to investigate further. Use the **date range** control before you interpret the results. Set the current review period, then compare it with the previous review period so you can tell whether activity is improving or slowing down. This is especially useful before release reviews, weekly maintenance checks, or ownership meetings. When the Analytics screen includes sortable cards, tables, or lists, sort for the highest-risk items first. Prioritize pages or sections showing: - low engagement - high issue volume - older last-updated timing - weak recent activity If you already worked through release planning signals in [Using Project Activity Signals to Improve Release Planning](doc:using-project-activity-signals-to-improve-release-planning), use this dashboard review as the operational follow-up: less about planning the release window, and more about deciding what needs attention right now. ## Filtering analytics to find content that needs attention The Analytics screen becomes much more useful once you narrow the results. Instead of reviewing every page in the project, use the available filters to focus on the content that needs action. Start by selecting the **project** if you work across more than one workspace. Then apply the filters that match your review goal, such as **team**, **owner**, **status**, or **date range**. For routine maintenance, page status filters are especially helpful. Use them to isolate groups such as: - draft pages that have not moved forward - published pages that may be aging - archived pages that should stay out of current review - overdue or maintenance-related items if those appear in your Analytics view This makes it easier to answer targeted questions. For example, if you want to know whether published content is being maintained, filter to **Published** and set a recent date range. If you want to find work that is stuck, filter to **Draft** and sort by oldest update. Where Atloria offers grouping or segmented views, switch the results by **owner**, **section**, or **content type**. Grouping by owner helps you see whether one person is carrying most of the maintenance load. Grouping by section helps you spot neglected parts of the documentation set. Grouping by content type helps you tell whether problems are concentrated in reference pages, guides, or release-related content. For recurring reviews, save the filter combination if Atloria provides a saved-view option. A saved weekly documentation health view might include: - the current project - published content only - a recent date range - grouped by owner or section [SCREENSHOT: Analytics filters with project, owner, status, and date range selected] Using saved filtered views keeps your operational review consistent. It also makes team meetings easier because everyone is looking at the same slice of data instead of rebuilding the filters each time. ## Using audit activity to understand what changed and who changed it When analytics tells you *that* something changed, the audit activity view helps you understand *what* changed and *who* changed it. In Atloria, open the project’s **audit activity**, **history**, or similar activity feed and review the most recent entries around the pages or project records you are monitoring. This is especially useful when freshness drops unexpectedly, edit volume spikes, or a release suddenly becomes unstable. Read each audit entry using the visible fields on the screen. The most useful fields are usually: | Field | What to look for | |---|---| | **Actor** | Who made the change | | **Timestamp** | When the change happened | | **Action type** | What kind of action took place | | **Affected page or record** | Which page, version, or project item was changed | Start with normal activity patterns. Routine updates often appear as expected edits, status changes, or publishing actions tied to release work. Those entries usually match planned team activity. What you are looking for are signals that suggest operational risk, such as repeated permission changes, frequent rollbacks, or publishing activity that appears outside the expected review cycle. For example, if analytics shows a sudden burst of edits in one section, check the audit feed for repeated changes on the same pages. If stale-content counts improve but engagement drops, the audit feed may show that pages were updated quickly without broader review. If a release-ready section suddenly looks unstable, the activity feed may reveal several last-minute status changes. [SCREENSHOT: project audit activity feed showing actor, timestamp, action, and affected page] Use the Analytics screen and the audit feed together. Analytics gives you the pattern; audit activity gives you the explanation. That combination is what turns raw activity into a clear operational decision. ## Turning analytics and audit signals into release and maintenance decisions Operational reviews matter most when they lead to clear decisions. In Atloria, use the Analytics screen and the audit activity feed together before a release checkpoint, during weekly maintenance, and whenever content quality is in question. The goal is not to collect more numbers. The goal is to decide whether documentation is ready, risky, or in need of follow-up. 1. Start with the Analytics view and check stale-page counts, unresolved issues, and recent edit volume. If stale content is high or unresolved issues are climbing, treat the release as needing more review. If recent edit volume is unusually high close to release, that can also signal risk because late changes often need extra validation. 2. Open the audit activity feed for the same project or section. Look for last-minute edits, repeated status changes, or unusual publishing activity. A burst of changes right before release may be acceptable if it matches planned work, but it should still trigger a closer review. 3. Flag sections that need attention before release. Focus on areas where analytics shows low coverage, aging content, or issue concentration, especially if the audit feed also shows repeated changes on the same pages. 4. Turn those findings into a maintenance list. Pages with ownership gaps, older updates, and repeated activity often need a clearer owner and a scheduled review rather than another quick edit. 5. Bring evidence into team review meetings. Use screenshots from the **Analytics** screen and the **audit activity** view, or use exported views if your team shares records outside the live workspace. [SCREENSHOT: Analytics summary beside audit activity entries used in a release review] This approach works well alongside [Using Project Activity Signals to Improve Release Planning](doc:using-project-activity-signals-to-improve-release-planning). That earlier work helps you plan; this step helps you decide what is safe to move forward and what needs maintenance first. ## Setting up a repeatable operational review process A repeatable review process keeps project health from depending on memory or last-minute checks. In Atloria, build a simple routine around the **Analytics** screen and the project **audit activity** feed so your team reviews the same signals on the same schedule. 1. Set a review cadence that matches your team’s pace. Many teams use a weekly documentation health check and a separate pre-release review. Weekly checks help you catch stale content and unresolved issues early. Pre-release reviews focus on whether recent activity introduces risk. 2. Create a standard review checklist using the screens your team already uses. Include the current **date range**, key Analytics indicators, and a quick pass through recent audit activity. Keep the checklist tied to visible items such as stale content, unresolved issues, recent updates, status changes, and publishing activity. 3. Assign clear responsibilities. Documentation Managers can review content health, stale pages, and unresolved issues. Project Administrators can review ownership gaps, permission-related activity, and unusual project-level changes. If your team uses approvals, include who decides whether a section is ready for release review. 4. Record recurring findings in a shared meeting note or exported review pack. If the same pages or sections appear every week, that is a signal to address ownership, structure, or workflow problems rather than only fixing individual pages. 5. Compare results over time. Use the same saved filters and date windows so you can tell whether stale content is dropping, issue counts are improving, and risky activity patterns are becoming less common. [SCREENSHOT: recurring weekly review using saved Analytics filters and recent audit activity] A repeatable process makes operational reviews faster and more objective. It also gives your team a shared way to discuss documentation health without relying on guesswork. ## Resolving common issues when analytics and audit data do not match expectations Sometimes the numbers or activity records in Atloria do not line up with what you expected to see. Before treating that as a content problem, check the screen settings and scope you are using. If the **Analytics** view looks incomplete, first review the active filters at the top of the screen. A narrow **date range**, a selected **owner**, or a status filter can remove pages from the results without making it obvious at first glance. Also check whether you are looking at a project-wide view or a narrower page-level view. If archived pages are excluded from the current view, totals may appear lower than expected. If the **audit activity** feed shows unexpected changes, look closely at the **actor**, **timestamp**, and **action type** columns. Confirm that the person listed is the one you expected, and check whether recent permission updates changed who could edit or publish. Also review whether the activity feed includes automated records alongside user actions. That can explain entries that appear unusual at first. If metrics do not reflect recent edits, check three things: - the reporting window on the Analytics screen - whether the page changes were fully saved or published - whether the screen needs a refresh to show the latest data [SCREENSHOT: Analytics screen with filters highlighted and audit feed with recent entries] A practical troubleshooting order is: 1. Confirm the project and date range. 2. Check status and owner filters. 3. Compare the affected page in Analytics and audit activity. 4. Refresh the screen and review the newest entries again. If the mismatch remains after those checks, capture screenshots of both views before you escalate the issue internally. That gives your team a shared record of what Atloria is showing at the time of review. ## Overview This guide focuses on the operational side of project analytics in Atloria. Instead of using analytics only for broad performance review, you will use the **Analytics** dashboard and the project **audit activity** feed together to monitor documentation health, investigate unusual changes, and support release and maintenance decisions. The main workflow in this guide is practical: - review project health in the **Analytics** screen - narrow the results with filters such as **project**, **owner**, **status**, and **date range** - open the project **audit activity** feed to understand who changed what and when - use both views together to decide what needs review before release or maintenance follow-up This document builds on the earlier guidance in [Using Project Activity Signals to Improve Release Planning](doc:using-project-activity-signals-to-improve-release-planning). That document covered how activity signals can shape release planning. Here, the focus is ongoing operations: weekly health checks, pre-release validation, and identifying risky patterns such as stale content, unresolved issues, repeated status changes, or unexpected publishing activity. You will also see how to make this review process repeatable by using saved filters, consistent date ranges, and shared review evidence such as screenshots or exported views. If you are responsible for documentation quality, release readiness, or project administration, these steps help you move from “something looks off” to a clear, evidence-based action. Use this guide when you need to answer questions like: - Which parts of the project are aging? - Where are unresolved issues building up? - What changed before this release review? - Which pages or sections need follow-up first? ## Prerequisites Before you start, make sure you can open the parts of Atloria used in this guide and that you have a project ready to review. You should have: - access to a project workspace in Atloria - permission to open the project **Analytics** view - permission to view the project **audit activity** or history feed - a project with existing documentation pages and recent team activity - enough familiarity with project navigation to move between the project workspace, Analytics, and related project records It helps if you have already worked through these related guides: - [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity) - [Using Project Activity Signals to Improve Release Planning](doc:using-project-activity-signals-to-improve-release-planning) You do not need advanced setup for this guide, but it is easier to follow if your project already has: - multiple pages or sections to compare - a mix of recently updated and older content - visible issue or maintenance patterns in the Analytics screen - recent edit, status, or publishing activity in the audit feed If you review projects as part of an admin role, you may also want access to the broader **Admin** workspace, including **Analytics & Insights** or **Security & Audit**, where available. In the current Atloria interface, those admin screens may appear as placeholders rather than full working review tools, so this guide centers on the project-level Analytics and audit views you can use today. From here, continue with [Reading Project Analytics for Content and Release Decisions](doc:reading-project-analytics-for-content-and-release-decisions) to turn these operational signals into specific content and release choices.