Saving and Organizing Captured Screenshots

Choosing Where Captured Screenshots Are Stored

After you capture a screenshot in Atloria, move it into your team’s agreed storage location right away. Do not leave working files in Downloads, on your Desktop, or inside a temporary screen capture folder, because those locations make screenshots hard to find later and easy to lose during doc updates. If your team is still capturing images, follow the capture workflow from Capturing Website Screenshots for Documentation, then store the image in the shared location your documentation team uses for active work.

Most teams use one of these storage approaches:

• Shared cloud folder
  Best when writers, reviewers, and release owners all need quick access. This works well for folders arranged by product, version, and document set.
• Repository image folder
  Best when screenshots are managed alongside documentation files for a specific project or version. This is useful when images are tightly tied to one documentation workspace.
• Asset library used by the docs team
  Best when your team needs searchable metadata, approval tracking, and a reusable screenshot library across multiple projects.

Choose one canonical location for final screenshots and use it consistently. A clear path structure helps everyone store files the same way, such as:

• /Product-Name/2026.1/User-Guide/
• /Admin/Users/2026.1/
• /Release-Notes/2026-Q2/
• /Project-Docs/Approved-Screenshots/

Set permissions before your library grows. In practice, teams usually separate access like this:

If more than one person can rename, move, or delete approved images, agree on that process first. That prevents one writer from replacing a screenshot another writer already used in a published guide.

Creating a Folder Structure Authors Can Reuse

A reusable screenshot library starts with a folder structure that matches how your team writes in Atloria. Keep current work, release work, and older screenshots separate so authors do not accidentally insert outdated images into a document. If your folders are flat or inconsistent, searching becomes slower every time you update a guide or prepare a release.

Start with a few top-level folders that clearly separate active and historical work:

• Active-Docs
• Release-Screenshots
• Archive
• Deprecated-UI

Inside those folders, organize screenshots by the same product areas and workflows your team documents in Atloria. For example:

• Active-Docs/Admin/Users/
• Active-Docs/Billing/Invoices/
• Active-Docs/Projects/Onboarding/
• Release-Screenshots/2026.1/
• Archive/2025.4/
• Deprecated-UI/Admin/Old-Navigation/

Then add one more level to distinguish screenshot status:

• Source-Captures for original images
• Edited for cropped or annotated working files
• Approved for publication-ready images

That gives you a structure like:

• Active-Docs/Admin/Users/Source-Captures/
• Active-Docs/Admin/Users/Edited/
• Active-Docs/Admin/Users/Approved/
• Release-Screenshots/2026.1/Approved/

This separation matters. A raw image from a browser session should not sit beside the final image used in a guide, especially when multiple writers are updating the same Atloria project. When someone opens the Approved folder, they should only see screenshots that are ready to place into documentation or release notes.

Use the same archive pattern every time. For example, move older screenshots into Archive/2025.4/ or Deprecated-UI/ instead of leaving them mixed into active folders. That keeps historical screenshots available for comparison without cluttering current searches when you are updating live documentation.

Naming Screenshot Files So They Are Easy to Find

A good filename should tell another writer exactly what the screenshot shows before they open it. In Atloria documentation work, filenames are most useful when they follow a stable pattern built from the screen area, the task, the screen state, and the version only when needed. That makes it much easier to search, sort, and reuse screenshots across projects and releases.

A practical naming format looks like this:

product-area_workflow_screen-state_version.png

Examples:

• admin_users_list_2026-1.png
• billing_create-invoice_draft_2026-1.png
• projects_onboarding_repository-connected.png
• documents_editor_approval-dialog_2026-1.png

Use names that reflect what a user actually sees in Atloria, such as:

• page name
• dialog name
• tab label
• status value
• workflow step

Avoid generic filenames like:

• screenshot-12.png
• image-final.png
• final2.png
• latest.png

Those names become meaningless as soon as a second version exists. If the screen has not changed between releases, you may not need a version marker at all. Add the version only when it helps distinguish one interface state from another. For example, if the Users & Permissions screen changed in a new release, include 2026-1 or 2026-2 so both files can exist without confusion.

Add extra tags only when your team maintains multiple variants of the same screenshot. Common examples include:

• _fr-FR for language variants
• _dark-mode for theme variants
• _macos or _windows for platform-specific captures

Keep the order of filename parts consistent across the whole library. If one writer starts with the product area and another starts with the version, search results become messy. A shared naming pattern lets Atloria authors quickly find the right image when updating a page, reviewing a version, or collecting screenshots for release preparation.

Tagging and Tracking Screenshots During Authoring

Folders and filenames help, but they are not enough once your team starts reusing screenshots across multiple Atloria guides. To keep images traceable during writing and review, record a small set of metadata for every screenshot. You can do this in your asset library, a shared tracking sheet, or the fields available in your documentation workflow.

Track the details that help authors decide whether a screenshot is safe to use:

This tracking makes a big difference during authoring. If a writer opens a screenshot and sees it marked Raw, they know it still needs cleanup. If it is marked Approved, they can place it into a guide with more confidence. If it is marked Obsolete, it should stay out of current work even if the image still looks familiar.

Link each screenshot to where it is used. For example, connect it to:

• a user guide page
• a specific section heading
• a release-preparation checklist item
• a feature update note

Review details are especially useful before publication. A Documentation Manager can sort by Last verified date or Approval status to find screenshots that need refresh. If a screenshot was verified against an older UI build, it can be flagged for recapture before the next version is approved in Atloria.

Finding the Right Screenshot When Updating Docs or Preparing a Release

When you update documentation in Atloria, start by searching the existing screenshot library before capturing anything new. Many workflows repeat across guides, release notes, and version updates, so the screenshot you need may already exist in an approved folder. Reusing an approved image saves time and keeps visual language consistent across your documentation set.

Use three search methods together:

1. Search by filename pattern
   Look for terms such as admin_users, projects_onboarding, or documents_editor.
2. Browse by folder path
   Open the product area and workflow folders where that screenshot would normally live.
3. Filter by metadata
   Narrow results by version, owner, approval status, or document name.

If your library includes archived material, filter that out first. When you are updating a current guide, you usually want to exclude anything in Archive, Deprecated-UI, or items marked Obsolete. That keeps older screenshots from appearing beside current approved assets.

Before taking a new screenshot, check whether the workflow already exists in the library. This is especially important for repeated paths such as:

• signing in
• opening project settings
• reviewing version details
• using the Users & Permissions area
• moving through common admin screens

For release work, gather screenshots into a version-specific set. Search for all images tagged to the target release, changed features, or release notes deliverables. That gives you a clean collection for review without digging through unrelated screenshots from earlier work.

This approach is especially helpful when one Atloria feature appears in several documents. Instead of recapturing the same screen for every guide, you can confirm whether an approved image already exists and reuse it wherever the UI and version still match.

Fixing Common Organization Problems in Screenshot Libraries

Even a well-planned library gets messy over time. Writers save duplicate files, approved images end up beside raw captures, and older screenshots stay in active folders long after the interface changes. When that happens, fix the library in place instead of working around the mess. A few cleanup habits make Atloria screenshot searches much more reliable.

Start with duplicate files. Compare screenshots using:

• filename pattern
• modified date
• version marker
• approval status

If two files show the same screen, keep one canonical image in the correct folder and remove or archive the extra copy. In most cases, the approved and most recently verified image should remain. If both are still in use, rename them clearly so the difference is obvious.

Next, fix screenshots with missing context. If a file is already circulating in your team but has a vague name, rename it and add the missing details in your tracking fields. At minimum, backfill:

• topic or document name
• product version
• owner
• approval status

Mixed raw and final assets are another common problem. Move files into the correct folders:

• raw browser captures into Source-Captures
• cropped or annotated work into Edited
• publication-ready images into Approved

Then update any links in your authoring workflow so writers stop pulling from the wrong location.

Before a release, look for outdated screenshots by filtering for old version tags or stale verification dates. Assign each outdated image to an owner for recapture or review. This is much faster than waiting until final release checks to discover that a guide still shows an older Atloria screen.

Overview

This guide focuses on what happens after you capture a screenshot for Atloria documentation. The goal is to make every image easy to store, identify, review, and reuse across guides, release notes, and version updates. If your team already knows how to capture screenshots, this is the step where those images become part of a reliable documentation workflow instead of scattered files saved in personal folders.

You will use this guide when you need to:

• move screenshots out of temporary local folders
• place them into a shared team library
• organize them by product area, workflow, and release
• name files so other writers can find them
• track approval and verification details
• clean up duplicate or outdated images before publication

This topic builds directly on Capturing Website Screenshots for Documentation. That earlier guide covers how to capture the right screen. Here, the focus shifts to what your team does next so those captures remain useful during authoring and release preparation.

In Atloria, screenshot organization matters because the same feature can appear in multiple places: project guides, admin documentation, release notes, and version review work. Without a clear storage location and naming pattern, writers often recapture screens that already exist or accidentally use outdated images. A shared structure avoids that problem and helps Documentation Managers review visual assets faster.

By the end of this guide, you should have a practical way to store screenshots in one canonical location, separate raw images from approved ones, and find the right screenshot quickly when you update documentation. The next document, Capturing and Saving Screenshots for Documentation, continues that workflow by connecting capture habits and storage habits into one repeatable process.

Prerequisites

Before you organize screenshots, make sure you already have the basics in place for your Atloria documentation workflow. This guide assumes you are not starting from zero. You should already know how your team captures screenshots and which documentation areas those screenshots support.

Have these items ready:

• Access to the shared location your team uses for screenshot storage, such as a cloud folder, repository image folder, or asset library
• Permission to upload files into active documentation folders
• A set of recently captured screenshots that need to be sorted, renamed, or approved
• A clear understanding of which Atloria project, guide, or release the screenshots belong to
• Your team’s current naming and approval rules, if they already exist

It also helps if you can identify the Atloria screen shown in each image. For example, you should know whether the screenshot belongs to Users & Permissions, Projects, Documents, Analytics & Insights, or Security & Audit. That makes it much easier to place the file into the correct folder and give it a useful name.

If you are working with release screenshots, gather any version details your team uses during review, such as the release number and the last verified date. If you are cleaning up an existing library, be prepared to compare older files and decide which image is the approved one.

You may also want a shared tracking place for screenshot details, especially if several writers work in the same Atloria workspace. That can be an asset library view or a team-maintained tracking sheet with fields for owner, version, and approval status.

If you still need help with the capture step itself, return to Capturing Website Screenshots for Documentation before organizing your files.