## Understanding how screenshot folders map to active docs and releases
In Atloria, screenshot organization works best when you treat **current draft content** and **published release content** as two separate working areas. Your active document screenshots belong to the page you are still editing in the project workspace. These images change as the draft changes. Release screenshots belong to a specific published documentation version and should stay fixed, even after the draft page is updated later.

A simple structure keeps this clear:

- One folder for the document itself, using the document slug or page name
- Inside that, an **active** area for current work
- Separate folders for release versions such as **v1.0**, **v2.3**, or another release label your team uses

For example, a page about settings might have one document folder, then an **active** set for the current draft and release folders for each published version. This prevents a new screenshot from replacing an older image that still belongs to a live version of the docs.

File names should describe the exact screen or step shown. Good examples include:

- `settings-overview.png`
- `create-user-dialog.png`
- `api-token-step-3.png`

These names make it easier to match an image to a heading, a task, or a step in the document editor. If a page has several screenshots, consistent naming also helps reviewers spot missing images quickly.

Use the **active document folder** when you are still writing, revising, or reviewing a page. Once that page is being finalized for a release, copy the approved screenshots into the **release-specific folder** that matches the version being published. If the published page must continue to show the older interface, leave those release screenshots in place and update only the active set.

[SCREENSHOT: Example screenshot library showing one document folder with an active folder and separate release folders such as v1.0 and v2.3]

## Setting up a screenshot library for a new document
When you start a new page in Atloria, create a screenshot folder that matches that document alone. Use the page slug or the document title so screenshots for one guide never get mixed into another. If you already organize documentation by project, keep the screenshot folder inside the same project area so writers and reviewers can find it without searching across unrelated content.

For a straightforward page, one folder may be enough at first. If the page covers several parts of the product, add subfolders based on the workflows readers will see. Common groups include:

- `onboarding`
- `settings`
- `reports`
- `admin-console`

This is especially useful for longer guides where one page includes multiple tasks, such as opening a menu, completing a form, and reviewing a confirmation screen. Grouping by workflow keeps the library readable and reduces the chance of inserting the wrong image into the wrong section.

Save your first captures with names that describe the exact interface state, not just the screen name. For example:

| Screenshot name | What it helps identify |
|---|---|
| `draft-editor-toolbar.png` | The editor toolbar while the page is still being edited |
| `publish-confirmation-modal.png` | The confirmation window shown before publishing |
| `version-status-badge.png` | A page or version status label used in the workflow |

These names are much more useful than generic file names such as `image1.png` or `screenshot-final.png`.

It also helps to note which product version produced the images. If your team tracks release numbers in the document workspace, keep that release label with the screenshot set so reviewers can confirm the images match the correct UI. This becomes important when a page moves from draft work into version review.

If you need a broader setup pattern for shared assets across teams, use this guide together with [Managing Enterprise Screenshot Libraries](doc:managing-enterprise-screenshot-libraries).

[SCREENSHOT: New screenshot folder for a document with subfolders for onboarding, settings, and admin-console]

## Reviewing image coverage against the page content
Before a page is approved, compare the document content with the screenshots you have saved. In Atloria, the easiest way to do this is to review the page heading by heading and check whether each important task or screen state has a matching image. You do not need a screenshot for every sentence, but the main UI moments in the guide should be visible somewhere in the page.

Look closely at sections that describe actions in the interface. If the text tells the reader to open a menu, complete a form, confirm a dialog, or check a status badge, there should usually be a screenshot that supports that step. Useful image targets often include:

- Navigation menus
- Dialog boxes
- Form fields
- Status badges
- Confirmation messages
- Empty states
- Warning banners
- Completed workflow screens

A heading-by-heading review helps you spot gaps quickly. For example, a guide may explain how to publish a documentation version and mention a confirmation message, but the screenshot set may only show the page before publishing. That is a coverage gap. Another common gap is when the document mentions an empty-state view or a warning banner, but no image shows that state.

You should also check for outdated images. A screenshot is outdated if the visible labels no longer match the current draft. Common signs include:

- Button text has changed
- A menu item has moved
- Panel layout looks different
- A badge or status label uses a new name
- The page path described in the text no longer matches the image

Mark these files clearly in your review notes or move them out of the working set so they are not inserted by mistake. This review is especially important before version approval, because once a screenshot is tied to a release, it should match the published wording and workflow exactly.

[SCREENSHOT: Document editor beside a screenshot folder list, showing a reviewer checking headings against image files]

## Keeping release screenshots aligned with published versions
The key handoff point in Atloria is when a draft page stops being edited for the current release and moves into final version review. At that stage, the screenshots used in the page should be treated as frozen for that release. Copy those approved images into the folder for the exact release label, such as **v1.0** or **v2.3**, so the published version always points to the correct visual set.

This matters because active documentation keeps changing. A writer may update button labels, replace steps, or capture a redesigned screen for the next release. If those newer files overwrite the images used by a published version, readers of the older release may see screenshots that no longer match the text on the page.

Release-specific folders solve that problem. Each published version keeps its own screenshot set, even if several versions of the same document remain available to readers. That means:

- The active folder can continue to change
- Older published versions keep their original images
- Reviewers can compare one release at a time without confusion
- Teams avoid breaking live documentation when preparing the next update

Before finalizing a version, run one last check across three items:

1. The published page text
2. The release number
3. The screenshot set stored for that release

All three should match. If the page says a reader should click **Publish**, the screenshot should show **Publish**, not an older label. If the version being released is **v2.3**, the page should not still be drawing images from the active draft set or from **v2.2**.

This release check is especially important for pages that stay live across several versions. Keeping each release folder intact gives your team a reliable visual history of what readers actually saw at publication time.

[SCREENSHOT: Release review view showing a document version label and its matching release screenshot folder]

## Managing updates when the interface changes
When Atloria’s interface changes, review the screenshot set before you update the document text. Even small changes can make an image misleading. Common examples include renamed buttons, moved navigation items, redesigned forms, or updated confirmation windows. If readers see one label in the screenshot and another in the instructions, confidence drops immediately.

Start by identifying exactly what changed on the page. Then compare those changes against the screenshots already used in the guide. If only one part of the workflow changed, replace only the affected files. For example, if the save confirmation window has a new layout but the rest of the page still looks the same, keep the unchanged screenshots and update only the image for that confirmation step. This saves time and preserves the parts of the guide that are still accurate.

When the workflow itself changes, a partial update is usually not enough. If the published version shows a process that no longer matches the current product behavior, create a new screenshot set for the next release rather than editing the older release files. That keeps the published release accurate while allowing the active draft to move forward.

As you update, clean out duplicate and obsolete files. These are often the source of mistakes during editing. Watch for:

- Older copies with nearly identical names
- Generic file names that do not show which step they belong to
- Draft captures that were replaced but never removed
- Images saved in the wrong document or release folder

A tidy library makes it much easier for writers to choose the right image in the document editor. If your team supports multiple versions at once, keeping old release folders untouched and updating only the active set is the safest pattern.

[SCREENSHOT: Screenshot folder showing updated files for one workflow step while older release folders remain unchanged]

## Fixing common screenshot organization problems
A few screenshot problems show up again and again in Atloria, and most of them come from unclear folder structure or vague file names. The fastest way to fix them is to trace the image back to the document page, the release it belongs to, and the exact UI state it is supposed to show.

If a **published page shows the wrong UI version**, first check whether the page is using images from the active document folder instead of the release-specific folder. This usually happens after a draft is updated for a newer release. Move the published page back to the correct release image set, then confirm the release label and screenshot folder match.

If **writers cannot tell which screenshot matches a section**, rename the files so the screen state is obvious. A file named `step2-final-new.png` does not help anyone. A name like `publish-confirmation-modal.png` or `settings-navigation-menu.png` makes the correct placement much clearer.

If **multiple teams overwrite each other’s images**, separate the files by both document slug and release label before anyone updates them. Shared screenshot areas become risky when different pages or versions use the same generic file names. A clear document folder, plus release folders inside it, usually solves this.

If **image coverage is inconsistent across a guide**, run a heading-by-heading review. Compare each section in the page with the available screenshots and look for missing images in key moments such as:

- Opening a menu
- Completing a form
- Seeing a warning
- Reaching a success message
- Viewing an empty or first-use screen

This kind of review is often enough to reveal whether the problem is missing captures, outdated files, or screenshots saved in the wrong place. If screenshots still seem unavailable or mismatched across versions, continue with [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions).

## Overview
This guide focuses on how to keep screenshot files organized so they stay accurate in both active documentation and published releases in Atloria. The main idea is simple: do not treat all screenshots as one shared pile. Instead, organize them by document, then separate current draft images from release-specific images.

The most reliable structure uses:

- A folder for each document
- An **active** area for in-progress work
- A separate folder for each published release label

Within those folders, use descriptive file names that match the exact screen state shown in the page. Names such as `create-user-dialog.png` or `api-token-step-3.png` are much easier to review than generic names. For longer guides, subfolders based on workflows or page areas can make the library easier to scan.

This guide also explains how to review screenshot coverage against the page itself. That means checking whether the document’s headings, steps, menus, forms, and confirmation states are actually illustrated. It also covers how to spot outdated images when labels, layouts, or menu paths change.

Most importantly, it shows how to preserve screenshots for published versions without blocking updates to the active draft. That separation is what lets teams support multiple documentation versions at the same time. If you have already worked through [Managing Enterprise Screenshot Libraries](doc:managing-enterprise-screenshot-libraries), this guide takes the next step by showing how to organize screenshot sets at the document and release level.

## Prerequisites
Before you organize screenshots for a document or release in Atloria, make sure you already have the basic pieces in place. You do not need a complex setup, but you do need enough structure to keep images tied to the right page and version.

You should have:

- Access to the project workspace where the documentation page is being edited
- A document or page that already has a clear title or slug
- A screenshot set that belongs to that document, even if it is still incomplete
- A release label or version name if the page is being prepared for publication
- A way to review the current draft page beside its screenshot files

It also helps if you already know whether the page is still in active editing or is close to release review. That decision affects where the screenshots should live. Draft images should stay in the active area until the page is ready to freeze for a version. Once the page is being finalized, move or copy the approved images into the release-specific folder.

If your team shares screenshots across many projects or departments, review [Managing Enterprise Screenshot Libraries](doc:managing-enterprise-screenshot-libraries) first so your document-level organization fits the larger library structure. If you are still capturing images rather than organizing them, [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) is the better starting point.

After your document folders, release labels, and file naming approach are in place, you can move on to cross-project coordination in [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions).