Managing Project Content from Drafts to Published Pages

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

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.

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.

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.

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.

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

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

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
• Familiarity with content review and organization concepts from 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 or 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 and Managing Documentation Versions Across the Release Cycle.