Publishing a Project from Setup to Public Release

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

If you want more detail on project creation choices before you begin, use Creating Projects and Completing Onboarding and 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.

For a deeper look at project settings and administration, see Managing Project Settings and Website Options and 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.

For more detailed editing guidance, use Creating and Editing Documentation Pages and 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.

If you need more detail on version workflows, see Generating New Documentation Versions, Managing Documentation Versions Across the Release Cycle, and 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.

For more on review decisions and approvals, see Reviewing and Approving Documentation Versions, Managing Version Review Decisions and Approvals, and 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.

For related guidance on visibility and public access, see Controlling Version Visibility and Export Options, Managing Version Visibility and Reader Access, and 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.

If you need more help with permissions, settings, or release validation, use Managing User Access and Administrative Permissions, Validating Version Access Before Sharing or Export, and 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.