Coordinating Project Publishing From Draft to Public Release

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 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

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 and Organizing and Reviewing Document Content.

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 and Generating New Documentation Versions go deeper into those screens.

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 and Managing Version Review Decisions and Approvals.

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, Validating Version Access Before Sharing or Export, and Publishing Documentation for Specific Audiences.

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 and Reviewing Audience-Specific Pages in Public Documentation are useful follow-ups.

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. If your next task is to manage the version release process in more detail, continue with 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
• Organizing draft pages in Creating and Editing Documentation Pages
• Managing release candidates in Managing Documentation Versions Across the Release Cycle
• Handling approvals in 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.