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