Managing Screenshot Workflows Across Projects and Versions

Understanding How Screenshot Workflows Span Enterprise, Projects, and Versions

In Atloria, screenshot work does not live in just one place. Teams usually work across three connected layers: the enterprise screenshot library, project-level screenshot collections, and documentation versions inside each project. The enterprise library is where broadly reusable, approved screenshots are kept for shared use. Project screenshot collections hold images that belong to one project workspace. Version-specific screenshot use matters when a page for one release needs a different image than another release, even if both pages cover the same feature.

A typical workflow starts when you open the screenshot workflow area and create or upload a screenshot for a specific project and documentation version. During that process, you add details that help other writers find and trust the image later. After upload, the screenshot moves into review, where a reviewer checks whether the image matches the current interface, version, locale, and page context. Once approved, the screenshot can be inserted into documentation pages and reused where appropriate. If the interface changes later, a replacement screenshot can be linked so the older image stays available for older versions while the newer one becomes current.

Ownership depends on where the screenshot is saved and how it is approved. An enterprise-approved screenshot may be reused across multiple projects if the screen is identical. A project-owned screenshot is usually tied to that project’s content and release cycle. If a version introduces a changed layout, wording, or navigation path, that version may need a new capture instead of reusing the existing one.

The most useful fields to keep accurate are:

If you need naming and library basics first, review Organizing Screenshots for Documentation and Releases.

Capturing and Storing Screenshots for the Right Project Version

When you capture or upload a screenshot in Atloria, start by choosing the correct context before you add the image. This is the step that keeps screenshots tied to the right documentation set instead of becoming hard-to-find files later. In the screenshot workflow screen, select the enterprise context if the image is meant for broad reuse, then choose the project workspace and the documentation version that the image belongs to. If you skip this and upload first, you increase the chance that the screenshot ends up in the wrong library or appears in the wrong search results.

1. Open the screenshot workflow area from your project workspace or screenshot library.
2. Select the target enterprise library or project collection.
3. Choose the correct project.
4. Choose the documentation version the screenshot should support.
5. Add the screenshot or start the capture process.
6. Fill in the asset details before saving.
7. Confirm the screenshot is stored under the selected project and version.

As you save the screenshot, record the details writers rely on later:

• Screen name
• Feature area
• Locale
• Viewport or resolution
• Whether the image is new or a replacement for an existing screenshot

Use clear, consistent titles so the screenshot is reusable later. Good labels usually combine the screen name, UI area, release number, and platform or viewport. The goal is not to make the title long, but to make it searchable. If your team documents multiple releases at once, version labeling is especially important because the same page title may exist in more than one release.

Before leaving the screen, verify that the screenshot is attached to the selected project/version pair. If it is saved only at the enterprise level when it should be version-bound, writers may accidentally reuse it in the wrong release.

Reviewing, Approving, and Replacing Screenshot Assets

After a screenshot is uploaded, the next step is review. In Atloria, review status is what tells writers whether an image is ready to use, still waiting for approval, or should no longer appear in active documentation. The most common status flow is Pending review, Approved, Rejected, and Superseded. These labels are important because search results and page editors often depend on them when writers look for usable screenshots.

1. Open the screenshot record from the library or project collection.
2. Check the image against the intended project, version, locale, and screen name.
3. Compare it with the screenshot currently used in the published or active documentation version.
4. Update the Status field based on the review decision.
5. Add reviewer comments explaining the decision.
6. If the image replaces an older screenshot, link it as the replacement and mark the older image as Superseded.

When you compare a new screenshot with the current one, focus on what a reader would notice: changed labels, moved buttons, updated navigation, different page states, or language changes. If the screen is the same and only the file is newer, replacing the existing asset may be the right choice. If the screenshot only applies to one release, keep it version-specific instead of replacing the shared image.

Reviewer comments matter because they explain why a screenshot was approved or rejected. Use the comments area to note issues such as outdated navigation, incorrect locale, wrong viewport, missing page state, or a mismatch with the current release. Those notes help the next writer avoid repeating the same mistake.

Replacement history is just as important as the current status. Writers need to see which screenshot is current for the active version and which older screenshots remain archived for earlier documentation. That history makes it possible to update new docs without breaking older published versions that still rely on the earlier image.

Reusing Approved Screenshots Across Projects and Documentation Versions

Atloria makes screenshot reuse practical only when writers can quickly tell which images are safe to reuse. The best way to do that is by searching the screenshot library with filters instead of browsing manually. When you open the library, narrow the list by Project, Version, Feature area, and Approval status. If your team works in more than one language, include Locale in your search before you reuse anything.

A screenshot can usually be reused across projects when it has already been approved at the enterprise level and the screen is visually identical in each project. This works well for shared Atloria interface areas that do not change by project. A project-specific variant is better when the screen includes project names, project settings, release-specific labels, or content that only exists in one workspace. A version fork is the right choice when one release introduces visible UI changes but older documentation still needs the previous image.

When you reuse a screenshot, keep it linked to its original asset record rather than treating it like an unrelated copy. That source link helps everyone see whether the original image has been updated, deprecated, or replaced. If the source screenshot is later marked Superseded, writers using dependent pages can spot that change and decide whether their page also needs an update.

Before reusing any image, check three things carefully:

• Version compatibility: the screenshot must match the release your page describes
• Locale: labels and interface language must match the audience version
• UI changes: even small layout or navigation changes can make a reused screenshot misleading

Reusing screenshots saves time, but only when the image still matches the page exactly. If there is any doubt, create a version-specific screenshot instead of forcing reuse.

Keeping Screenshot Libraries Organized for Writers and Managers

A screenshot library only stays useful if teams fill in the same core fields every time. In Atloria, writers and managers should standardize the details that make screenshots searchable, reviewable, and safe to reuse. At minimum, every screenshot record should include a clear Title, Project, Version, Locale, Status, Owner, Last reviewed date, and Source page. When these fields are missing or inconsistent, approved screenshots become difficult to find and duplicate uploads become more common.

Library structure also matters. Keep enterprise-wide screenshots in a shared library for reusable, approved assets. Keep project-maintained screenshots in project collections so release-specific images stay close to the pages they support. This separation makes it easier to search confidently and reduces accidental reuse of project-only images in unrelated workspaces.

Good governance usually includes:

• Regular duplicate checks before approving new screenshots
• Scheduled reviews of older screenshots using Last reviewed date
• Marking replaced screenshots as Superseded instead of leaving them active
• Removing retired screenshots from active documentation use while keeping their history for older versions

Permission levels should also be clear. Technical Writers typically upload screenshots, add metadata, insert approved images into pages, and request replacements. Documentation Managers usually handle final approval decisions, replacement confirmation, cleanup of duplicates, and deletion of records that should no longer remain in the active library. If your team also works in the Admin area, see Using the Admin Workspace for broader workspace management context.

Fixing Common Problems with Missing, Outdated, or Misassigned Screenshots

When a screenshot seems to be missing in Atloria, start with search filters. Many “missing” screenshots are simply hidden because the current filters do not match the asset record. In the screenshot library, check Project, Version, Locale, and Approval status first. A screenshot marked Pending review or saved under a different version will not appear where you expect if your search is limited to approved assets for the current release.

If a screenshot was saved to the wrong project or enterprise context, open the screenshot record and review its ownership details. Confirm whether it belongs in the enterprise library for shared reuse or inside a specific project collection. Also check that the screenshot is linked to the intended documentation version. Misassigned ownership is one of the main reasons writers reuse the wrong image or fail to find the right one later.

Outdated screenshots can continue appearing in pages when the replacement chain is incomplete. If a newer screenshot exists but the older one still shows in documentation, verify three things:

• The newer image is linked as the replacement
• The older image is marked Superseded
• The page is referencing the current approved screenshot rather than the archived one

Duplicate screenshots are another common issue, especially when several writers capture the same UI state. Before publishing a new screenshot, compare its metadata with existing approved assets. Look at the Title, Project, Version, Locale, Status, and review history. If an approved screenshot already covers the same screen and release, reuse it instead of adding another copy. If the images look similar but one includes updated labels or layout changes, document that difference in the comments and keep the records clearly separated.

For deeper troubleshooting around search, reuse, and availability, continue with Troubleshooting Screenshot Availability Across Projects and Versions.

Overview

This guide focuses on how screenshot work moves through Atloria when multiple projects, releases, and shared libraries are involved. Instead of treating screenshots as one-off uploads, Atloria organizes them as managed documentation assets. That means each screenshot can belong to an enterprise library, a project collection, or a specific documentation version, and each image can carry review status, ownership, and replacement history.

You will use this workflow when your team needs to:

• capture screenshots for a specific release
• reuse approved screenshots across projects
• review and approve screenshots before writers place them in pages
• replace older screenshots without losing history for previous versions
• keep screenshot libraries clean enough for teams to search confidently

This document does not repeat the naming and release-organization basics already covered in Organizing Screenshots for Documentation and Releases. Instead, it builds on that foundation by showing how screenshots move between shared enterprise use, project-specific use, and version-bound documentation work.

The main areas covered here are:

• choosing the correct project and version before capture or upload
• saving screenshots with the right metadata
• moving screenshots through review and approval statuses
• replacing outdated screenshots while preserving archived assets
• reusing approved screenshots safely across projects and versions
• correcting common problems such as missing, outdated, duplicate, or misassigned screenshots

If you manage documentation across several teams, this workflow helps you keep screenshot decisions visible. Writers can see whether an image is approved, managers can track what replaced it, and reviewers can tell whether a screenshot is safe to reuse in another release. The result is a cleaner screenshot library and fewer mistakes in published documentation.

Prerequisites

Before you work through screenshot workflows across projects and versions in Atloria, make sure you already have access to the parts of the workspace where screenshots are managed and reviewed. You do not need every administrative permission, but you do need the ability to open the relevant project workspace, view screenshot libraries, and work with documentation versions.

You should have:

• An Atloria account that can sign in and open your team workspace
• Access to at least one project where documentation versions are already available
• Permission to upload screenshots or start a screenshot capture
• Permission to view screenshot details such as status, project, version, and locale
• Access to documentation pages where approved screenshots are inserted
• A basic understanding of how your team organizes screenshot names and release labels

It also helps if you are already familiar with:

• project navigation and workspace structure
• documentation versions and release-specific content
• screenshot organization practices from Organizing Screenshots for Documentation and Releases
• basic screenshot capture work from Capturing Screenshots from Web Pages or Capturing Website Screenshots for Documentation

If you are responsible for approvals or library cleanup, you should also be able to update screenshot status fields and review replacement history. Teams that separate writer and manager responsibilities may limit approval and deletion actions to documentation managers, while writers focus on upload, tagging, and page insertion.

The next document in this section, Using Enterprise Screenshot Libraries for Documentation Teams, goes deeper into how shared screenshot libraries support team-wide reuse and governance.