Running a Documentation Release from Project Workspaces

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

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, Organizing and Reviewing Document Content, and Coordinating Version Work Before Release alongside this release workflow.

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, Understanding Version Review Feedback and Follow Up, and Preparing Versions for Final Approval.

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

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 and Controlling Version Sharing and Export Readiness are the best companion guides.

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, Managing Version Review Decisions and Approvals, and 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. 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.
• 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
• Coordinating Version Work Before Release
• Preparing Versions for Final Approval
• 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.