## Choosing the Right Export for Review or Archive
In Atloria, the best export choice depends on what you need to do with the file after download. When you open a documentation version, the export options usually center on two decisions: whether to export only that version’s content, and whether to include related records such as attachments and linked version details. A version-only export is the simplest option when you need a clean copy for someone to read, compare, or sign off on. An export that includes related records is better when the package needs to travel with supporting material.

For review work, choose the export option that keeps the documentation easy to read and clearly tied to the version label. This is useful when a reviewer needs to inspect a fixed version without opening the live workspace. Review packages are usually best when they focus on the document structure itself and include only the supporting items needed for that review cycle.

For archiving, choose a broader export scope. Include the documentation version together with attachments, approval notes, and linked metadata when those records are part of the official history of the version. This creates a more complete handoff package for long-term storage, audit support, or release retention.

You may export from different record scopes depending on where you start:

- A single documentation version from its detail page
- Multiple versions selected from a versions list
- One version together with attachments and linked metadata

Clear naming matters once files leave Atloria. Before exporting, check that the version label, title, and date fields are accurate. These details help you tell apart draft, approved, and older superseded packages after download, especially when several exports from the same project are stored together.

[SCREENSHOT: Documentation version page showing export choices for version-only and version-with-related-records]

## Checking That a Documentation Version Is Ready to Export
Before you click **Export**, review the documentation version carefully so the downloaded file reflects the right state of the record. In Atloria, start with the version status shown on the version record. A version that is still in draft may be useful for internal review, but it may not be appropriate for stakeholder sharing or archive storage. A version marked ready for review is usually a better choice for formal feedback, while a finalized version is the safest option for long-term retention.

Next, confirm that the identifying fields on the version record are complete. Missing version details make exported files harder to recognize later and can create confusion if several packages are downloaded from the same project.

Check these fields before exporting:

| Field | Why it matters |
|---|---|
| **Title** | Helps identify the document package after download |
| **Version Number** | Distinguishes one release or draft from another |
| **Publication Date** | Shows when the version was prepared or released |
| **Owner** | Identifies who is responsible for the version |

You should also review the related records linked to that version. If you plan to include attachments, approval notes, or project details in the export, make sure those records are already saved and up to date. A package exported too early may leave out supporting files or include outdated notes.

Pay special attention to unfinished work. If the version still has open edits, pending approvals, or incomplete supporting records, the exported package may not be suitable for external review or compliance retention. If you already worked through readiness planning in [Managing Export Center Workflows](doc:managing-export-center-workflows), use that same decision process here and focus on the final record check before export.

[SCREENSHOT: Documentation version detail page with status, title, version number, publication date, and owner visible]

## Exporting a Single Documentation Version
Use a single-version export when you need one specific documentation package from Atloria. This is the most direct option for sending a version to a reviewer, preparing a release handoff, or saving a final copy for records.

1. Open the documentation version detail page for the version you want to export. Review the header area and confirm you are on the correct version by checking the **Title**, **Version Number**, and status.
2. Find the **Export** action in the page toolbar or in the actions menu. If you do not see it, stop and review the version status and required fields before continuing.
3. Choose the export scope. Select whether you want to export only the version content or include related records and attachments as part of the package.
4. Review the export options before starting. Pay close attention to the file name, version label, and any inclusion settings so the downloaded file is easy to identify later.
5. Start the export. Atloria will begin generating the file.
6. Watch the export until it finishes and the download becomes available. If the page shows an in-progress state, wait for completion before leaving the screen.

A single-version export works best when you need a fixed snapshot of one documentation version rather than a collection of records. If the version is intended for review, keep the package focused and readable. If it is intended for archive storage, include the supporting records that belong with that version.

After the file downloads, open it and confirm that the version label and contents match the record you exported. This quick check is especially important when several versions have similar names.

[SCREENSHOT: Export menu on a documentation version detail page with scope and naming options]

## Exporting Multiple Versions and Related Records in Bulk
Bulk export is the better choice when you need to download several documentation versions at once. In Atloria, this starts from the documentation versions list, where you can select multiple rows and run one export action across the whole selection. This is useful for release reviews, milestone handoffs, and archive preparation when several versions need to be collected together.

1. Open the documentation versions list view for the project or workspace you are working in.
2. Use the row checkboxes to select each version you want to include. Before moving on, compare the selected rows with the visible version titles and labels so you do not miss a record.
3. Open the bulk **Export** action.
4. Choose how the export should be packaged. If Atloria offers separate files per version, use that when each version needs to stand on its own. If it offers a combined package, use that when you want one bundle for review or storage.
5. Set the inclusion options for the whole batch. If you need attachments, linked references, or approval history, apply those choices consistently across all selected versions.
6. Start the bulk export and monitor its progress until the package is ready to download.
7. After download, compare the completed package with your original selection and verify that every chosen version is included.

Consistency matters more in bulk exports than in single exports. If one version includes attachments and another does not, reviewers may assume something is missing. Before starting the export, make sure the selected versions are at a similar stage and that the same related records should travel with each one.

If you are deciding whether to create separate files or one combined package, use the guidance in [Choosing the Right Export for Sharing Review or Archiving](doc:choosing-the-right-export-for-sharing-review-or-archiving) to match the export type to your audience.

[SCREENSHOT: Documentation versions list with multiple row checkboxes selected and bulk Export action open]

## Using Exported Files for Review, Handoff, and Archiving
Once a file is downloaded from Atloria, treat it as a fixed copy of the documentation version at that moment. For review, this is helpful because reviewers can inspect the package without needing access to the live version record or worrying that the content will change while they are reading it. A clean export is especially useful for structured review cycles, sign-off meetings, or external feedback.

For stakeholder handoff, project administrators often use exported files as a formal package. A versioned file name, clear version label, and included metadata make it easier for recipients to understand what they received. When attachments and approval notes are included, the package becomes more useful for milestone reviews, release evidence, and audit requests because the supporting context travels with the documentation itself.

For archiving, keep finalized exports together with the records that explain why that version mattered. In practice, that usually means storing the documentation export alongside approval evidence, supporting attachments, and any retention label or archive naming convention your team uses. The goal is not just to save the content, but to preserve enough context that someone can identify the package later without reopening Atloria.

After every download, validate the package before sharing or storing it:

- Confirm the **Version Number** matches the intended documentation version
- Check that the file name clearly reflects the version label or date
- Verify that attachments and related records are present if you selected them
- Open the package and make sure the contents are complete and readable
- Compare the downloaded package with the version record if anything looks incomplete

This validation step is quick, but it prevents confusion later when several review and archive packages exist for the same project.

## Fixing Common Export Problems
Most export issues in Atloria come from record readiness, selection choices, or missing inclusion settings. Start by checking the version record itself before assuming the export failed.

If the **Export** action is unavailable on a documentation version, first review the record status. A version that is incomplete or not in the right stage may not be ready for export. Then check the required identifying fields such as **Title**, **Version Number**, **Publication Date**, and **Owner**. If those details are missing, update the version record and try again. If the button is still unavailable, your access level may not include documentation export.

If the downloaded package is missing attachments or linked records, the most common cause is that those items were not included in the export settings. Reopen the export options and confirm that the package is set to include related records. Also verify that the attachments, approval notes, or linked details were saved on the version before you started the export.

If a bulk export finishes with fewer files than expected, compare the completed package to the rows you selected in the versions list. Check whether any versions were filtered out, not actually selected, or not eligible for export. This is easiest to spot when you review the selected rows before starting the bulk action.

If file names are hard to recognize after download, fix the record details before exporting again. Update the version label, publication date, and naming pattern so each package is easy to identify later. This is especially important when you are exporting drafts, approved versions, and superseded versions from the same project.

For a deeper readiness check before rerunning an export, refer to [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions).

## Overview
This guide focuses on the practical side of managing documentation exports in Atloria after you have already planned your export workflow. Here, the emphasis is on choosing the right export scope, checking whether a documentation version is actually ready, running exports from both the version page and list view, and confirming that the downloaded files are complete enough for review or archive use.

The main export situations covered in this guide are:

- Exporting one documentation version from its detail page
- Exporting several versions together from a list view
- Including related records such as attachments, approval notes, and linked metadata
- Preparing files for reviewer access, stakeholder handoff, or long-term retention
- Correcting common issues when exports are incomplete or hard to identify later

This guide does not repeat the workflow planning covered in [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records) or [Managing Export Center Workflows](doc:managing-export-center-workflows). Instead, it assumes you already know when an export is needed and helps you complete the export accurately from the screens where you work with documentation versions.

As you follow the steps, keep your attention on the visible details that travel with the file after download: the version label, the publication date, the included attachments, and the related records selected in the export options. Those details are what make an exported package useful once it leaves Atloria and is shared with reviewers, stakeholders, or archive owners.

[SCREENSHOT: Export Center workflow moving from version selection to completed download package]

## Prerequisites
Before managing exports in Atloria, make sure the documentation version and its related records are in good shape. Export problems are much easier to prevent than to fix after files have already been shared.

You should have the following in place:

- Access to the project workspace that contains the documentation versions you need
- Permission to open documentation version records and use the **Export** action
- At least one documentation version with complete identifying details
- Related records already saved if you plan to include them in the export
- A clear decision on whether the export is for review, handoff, or archive storage

Check these version details before you begin:

| Item to confirm | What to look for |
|---|---|
| Version status | Draft, ready for review, or finalized, depending on your purpose |
| Record details | **Title**, **Version Number**, **Publication Date**, and **Owner** are filled in |
| Related records | Attachments, approval notes, and linked metadata are present if needed |
| Selection scope | You know whether you are exporting one version or multiple versions |
| Naming clarity | Version labels and dates are clear enough to identify after download |

If you are working with several versions, it also helps to review the versions list first so you can select the correct rows for a bulk export. If you are preparing a formal release or retention package, confirm that approvals and supporting records are complete before you export.

The next guide, [Choosing the Right Export for Review Release and Retention](doc:choosing-the-right-export-for-review-release-and-retention), helps you decide which export style fits each delivery or archive scenario.