## Understanding how editor changes become part of a release
In Atloria, editing a page and releasing that page are two separate parts of the workflow. A change you make in the document editor is only a draft update until it is reviewed and attached to a versioned release. That separation matters when your team needs to control what readers can see, compare release candidates, or hold updates for approval before they go live.

An in-progress change starts in the document editor, where you update the page content, structure, or page details and then save. At that point, the update belongs to the working draft of the document, not to a released version. To move it forward, you use the document’s version history or revision view to find the saved update and compare it with the currently released content. From there, you use the available review or approval controls to mark the update as ready for release work.

Once the change has been reviewed, you add it to a version entry or release record. This is the point where Atloria starts treating the page update as part of a specific release candidate rather than just a saved draft. In practice, that means you will usually move between four areas:

- The **document editor** to make and save the change
- The **version history** or comparison view to confirm what changed
- The **review or approval controls** to move the update out of draft work
- The **release management** area to include the reviewed page in a versioned release

Use a versioned release when you want readers to see a controlled set of updates together. If you are already following a full project release flow, keep using the process described in [Running a Project from Setup to Public Documentation Release](doc:running-a-project-from-setup-to-public-documentation-release). This guide focuses on the document-level path from saved edit to release-ready version.

[SCREENSHOT: document editor beside version history and release list in Atloria]

## Preparing the document change in the editor
1. Open the project in Atloria and go to the document you want to update. Before you edit anything, check the page title and confirm you are on the correct document. If your team manages similar pages across versions, this quick check helps prevent updating the wrong page.

2. Make your content changes in the editor. Update the text, headings, page sections, or other visible content on the page. As you work, pay attention to the page layout and any fields that affect how the page appears in navigation or release views. If the editor shows a current draft state, keep working there until the page reflects the exact update you want to send forward.

3. Save the page. In Atloria, saving is what turns your work into a recorded draft or pending revision. If you leave the page without saving, the release workflow cannot pick up the latest changes. After saving, stay on the page long enough to confirm the save completed and that the latest draft is now the current working version.

4. Use the preview or compare view if it is available from the page. This is the best place to verify the exact wording, structure, and page flow before review. Compare the newly saved draft against the current released version and look for unintended edits such as missing headings, moved sections, or outdated wording that should not be part of the release.

A careful editor check at this stage saves time later. Before you leave the page, confirm:

- The correct document is open
- The new content is saved
- The draft reflects the intended change
- The preview or compare view matches what you expect readers to see in the next release

[SCREENSHOT: document editor with saved draft and preview or compare option]

## Reviewing and versioning the updated document
1. Open the document’s **version history**, **revision history**, or similar change-tracking area. Find the most recent saved update you just created. Look for the latest entry by its position in the list and confirm it matches the page you edited.

2. Compare that latest revision with the current released version. This step is where you confirm that the release candidate includes the right text, page structure, and any page-level details that changed. If Atloria shows side-by-side comparison or a revision view, use it to verify what was added, removed, or updated.

3. Move the revision into the review process using the available action on the page, such as a review, approval, or status-change control. The exact button label may vary by workspace, but the goal is the same: change the document from a saved draft into a reviewed item that can be included in a release. If your team uses approval decisions, make sure the revision reaches the required status before you continue.

4. Assign the reviewed revision to a version entry or release candidate. This links the document update to a named version instead of leaving it as a standalone draft change. Once attached to a version, the update becomes part of a trackable release package that can be reviewed alongside other documentation changes.

Use this stage to answer one question clearly: “Is this the exact revision we want in the release?” If the answer is not clear, go back to the comparison view before assigning it to a version. For broader guidance on version lists and review states, see [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions).

[SCREENSHOT: revision history with latest document update selected and compared to current release]

## Adding the reviewed change to a versioned release
1. Go to the release or version area for your project. Open an existing release if the document update belongs in a release already in progress, or create a new release record if this change starts a new release candidate. Choose the release that matches your team’s timing and scope.

2. In the selected release, open the section that lists included content. Depending on your workspace, this may appear as release contents, included documents, or a version selection area. Add the reviewed document version from the available list, making sure you choose the reviewed revision rather than an older saved draft.

3. Check the release details before you move on. The release record may include fields such as version name, release notes, access settings, and publication scope. Review those details carefully because they determine how this document update will be grouped, labeled, and shared.

| Release detail | What to check |
|---|---|
| **Version name** | Matches your team’s naming for this release |
| **Release notes** | Describes the document update clearly if notes are used |
| **Access settings** | Reflects who should be able to view the release |
| **Publication scope** | Confirms whether the release is internal, staged, or intended for publication |

4. Confirm the document now appears in the release contents with the correct status. The release should show the page as included, and the included revision should match the reviewed version you selected earlier. If the release view shows status information, make sure it reflects the expected review state before you treat the release as ready.

This is the point where a page stops being “just updated in the editor” and becomes part of a managed release. If you need more detail on release visibility and export-related controls, see [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options).

[SCREENSHOT: release details screen showing included documents and version information]

## Checking access and publication readiness for the release
1. Open the release record and review its access settings. In Atloria, a release can be prepared before it is broadly available, so confirm who can view it at this stage. If the release is meant for internal review only, keep it restricted. If it is intended for a wider audience, make sure the visibility settings match that goal.

2. Verify that three things line up: the document’s approval status, the release membership, and the selected document version. A release can look complete while still pointing to the wrong revision or holding an item that has not reached the required review state. Check each included document entry carefully.

3. Use preview or staged access options to see the release the way readers will see it. This is the safest way to confirm that Atloria is showing the released version of the page rather than the editor draft. Read through the updated page in the release preview and confirm the title, body content, and page structure all match the approved revision.

4. Decide whether the release should remain restricted or move to a published state. Keep it restricted when the release is still under internal review, waiting for sign-off, or being checked by a limited audience. Promote it only when the included documents, access settings, and release details are all final.

A release is publication-ready when:

- The correct reviewed revision is included
- The release shows the expected version name and notes
- Access settings match the intended audience
- Preview shows the released page correctly
- The release state matches your team’s decision to keep it staged or publish it

For a deeper look at reader access and validation before sharing, use [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export).

[SCREENSHOT: release preview with access settings and publication state visible]

## Fixing problems when a document update does not appear in the release
If the latest editor change is missing from the release, start with the document editor. Open the page and confirm the update was actually saved. A change that was typed into the editor but never saved will not appear in version history and cannot be added to a release. After saving, return to the document’s revision list and check whether a new entry now appears.

If the wrong content appears in the release, compare the revision attached to the release against the latest saved revision in version history. In many cases, the release is still pointing to an older reviewed revision. Open the release contents, select the included document, and verify that the chosen revision matches the exact text and structure you intended to release.

If Atloria does not let you add the document to the release, check the review or approval status first. Some release workflows only allow reviewed or approved items to be included. Go back to the document’s review controls and make sure the page has moved out of draft or pending work and into the required status.

If users cannot access the updated document after the release has been created, inspect the release access settings and publication state. The release may exist, but still be restricted to internal viewers or held in a staged state. Also confirm that readers are opening the release view or published version, not the editor draft.

Use this quick troubleshooting map:

- **Missing update in release**: save the page, then confirm a new revision exists
- **Wrong page content in release**: compare the included revision with version history
- **Cannot add page to release**: check review or approval status
- **Readers cannot see update**: review access settings, visibility, and publication state

When release problems affect multiple documents, compare your steps with [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) and [Controlling Version Sharing and Export Readiness](doc:controlling-version-sharing-and-export-readiness).

[SCREENSHOT: release contents showing selected revision and access status]

## Overview
This workflow in Atloria is about moving a single document update through the controlled release path rather than treating a saved edit as immediately publishable. You begin in the document editor, where you update a page and save it as a draft or pending revision. From there, you use version history to confirm the exact change, move the revision through review or approval, and attach that reviewed revision to a versioned release.

The key idea is that Atloria separates editing from release management. A saved draft is useful for ongoing work, but it is not the same as a reviewed release candidate. The release record is where you group approved document changes, apply release details such as version name and notes, and decide who can see the result. That makes versioned releases especially useful when your team needs to coordinate several page updates, limit access before publication, or validate a release before readers see it.

This guide fits after the broader project release flow in [Running a Project from Setup to Public Documentation Release](doc:running-a-project-from-setup-to-public-documentation-release). Instead of repeating project setup or public publishing basics, it focuses on the document-level handoff between editor work and release control.

You will work across these Atloria areas:

- **Document editor** for page updates
- **Version history** for revision checks and comparison
- **Review or approval controls** for status changes
- **Release management** for versioned release membership and access settings

The next step in this sequence is [Using Analytics Audit and Exports in Release Operations](doc:using-analytics-audit-and-exports-in-release-operations), where you will use tracking and export tools to support release decisions and recordkeeping.

## Prerequisites
Before you move a document update into a versioned release in Atloria, make sure the basic release workflow is already in place for your project. You do not need to repeat project setup here, but you should be working inside a project that already has documents, versioning activity, and a release process your team is using.

You should have access to the parts of Atloria involved in this guide:

- A project workspace with at least one editable document
- The **document editor**
- The document’s **version history** or revision view
- The available **review** or **approval** controls for that document
- The project’s **release** or **version** area

It also helps if you have already completed the broader release walkthrough in [Running a Project from Setup to Public Documentation Release](doc:running-a-project-from-setup-to-public-documentation-release). That guide covers the full project path, while this one focuses on moving a specific page update into a controlled release.

Before you start, confirm these working conditions:

- You know which document page needs to be updated
- You know which release the change should belong to, or whether you need to create a new one
- Your team’s review expectations are clear, especially if a page must be approved before release inclusion
- You can open the release preview or staged view to verify what readers will see

If you are unsure whether you have the right access for release and approval tasks, check the related admin guidance in [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) or [Using the Admin Workspace](doc:using-the-admin-workspace).