## Preparing URLs and capture settings before you start
Before you run a website capture in Atloria, decide exactly which page you want to document and how that image will be reused later. Start from the screenshot capture area used by your team and confirm you have the final page address ready to paste into the **URL** field. If you are documenting a public documentation page, a project page, or a release-specific view, make sure you are using the exact page version you want readers to see. Small differences in page state can create confusion later when the screenshot is reused in authoring or release review.

Choose the capture scope based on the type of content you are creating. A full-page image is usually the better choice when you need to show a complete article, long settings page, or a full public documentation view. A visible-page capture is more useful when you only need the top section of a page for release notes, summaries, or short how-to content. If your team already covered the basics of taking screenshots, use that earlier workflow as your reference and focus here on preparing assets for reuse: [Capturing and Saving Screenshots for Documentation](doc:capturing-and-saving-screenshots-for-documentation).

Before you start the capture, set a clear name pattern for the result. Use names that tell other writers what the screenshot shows, such as the page area, feature, or release context. This makes the image easier to recognize later when you save it into a shared library.

Also confirm where the result should end up after review. In Atloria, this usually means choosing the correct project, folder, or shared asset collection used by your documentation team. Saving to the right location from the start prevents cleanup work later.

[SCREENSHOT: Website capture screen showing the URL field, capture scope options, and destination selection]

## Capturing screenshots from a website URL
1. Open the website capture screen in Atloria and click into the **URL** field.

2. Paste the page address you want to capture. Double-check the address before continuing, especially if you are documenting a specific project page, public documentation page, or release-ready view.

3. Select the capture option that matches your goal, such as a full-page image or a visible-page image. If you are creating a reusable visual for long-form documentation, full-page capture is often the better choice. If you only need a focused image for a short article or release note, use the smaller page view that shows just the visible area.

4. Click the main capture action, such as **Capture** or **Take Screenshot**. Atloria will show an in-progress state while the image is being generated. Wait for that process to finish before leaving the screen.

5. Review the screenshot in the preview area as soon as it appears. Check that the page loaded correctly, the layout looks complete, and the important interface elements are visible. If the page includes navigation, banners, dialogs, or release-specific content, make sure those details match the scenario you are documenting.

6. If the result is not right, run the capture again. You may need to recapture when the page content changes, when a new release is ready, or when you need a different page state for another guide.

7. Repeat the same process for additional page addresses if you are building a set of screenshots for one project or release cycle.

[SCREENSHOT: Capture results screen with a generated website screenshot preview and capture status]

## Reviewing capture results and selecting what to keep
After Atloria generates one or more screenshots, use the capture results view to decide which images are worth keeping. This step matters because not every capture belongs in your reusable asset library. Some results are only useful for a one-time draft, while others should be saved for long-term use across guides, release notes, and version comparisons.

Start by comparing the new screenshots side by side in the results list or preview area. Look for the image that best represents the page you want readers to understand. The strongest result is usually the one with complete page rendering, readable text, and the right feature state visible on screen. If you captured the same page more than once, choose the version that shows the cleanest layout and the least visual distraction.

As you review, check for a few practical details:

- The page is fully loaded and not cut off.
- Key navigation or page sections are visible.
- Any dialog, menu, or state shown matches the documentation scenario.
- The screenshot reflects the correct release or current project state.
- Text and interface labels are clear enough to recognize.

Remove captures that are failed, outdated, or clearly weaker than the best version. Keeping too many similar results makes later version-preparation work harder, especially when teams are selecting visuals during review. If an image was only needed to confirm a page state during drafting, leave it out of the reusable library.

Use this review step to separate temporary results from durable assets. One-off captures can stay tied to the immediate task, while screenshots that represent stable pages or important workflows should move forward into the shared asset library.

[SCREENSHOT: Capture results list with multiple similar screenshots, one selected as the preferred version]

## Saving screenshots as reusable assets
1. In the capture results view, select the screenshot you want to preserve.

2. Click **Save as Asset**. This moves the image out of the temporary results area and into a location where it can be reused during document authoring and version preparation.

3. Enter the asset details shown on the save form. Use a clear **Title** that describes the page or workflow in plain language. If Atloria shows a **Filename** or internal label field, make it specific enough that another writer can recognize it without reopening the original capture job.

4. Choose the correct destination for the saved image. Depending on how your team organizes work in Atloria, this may be a project, a folder, or a shared collection for screenshots. Pick the location where authors already expect to find approved visuals.

5. Save the asset and wait for Atloria to finish the action.

6. Open the destination location and confirm the screenshot appears there. This is the most important check: if the image only exists in the capture results area, it may not be available later when someone is writing or updating documentation.

A good saved asset should be easy to identify at a glance. Instead of using a vague label, use wording that reflects the actual page content, such as a project area, settings page, or public documentation view. This becomes especially important when multiple releases contain similar-looking screens.

If you are preparing screenshots for shared use across a team, save only reviewed images. That keeps the reusable library focused on approved visuals rather than every draft capture created during testing.

[SCREENSHOT: Save as Asset form showing title, filename or label, and destination selection]

## Organizing assets for document authoring and version preparation
Once screenshots are saved, organize them so writers can quickly find the right image while drafting or updating documentation. In Atloria, the most useful structure is one that matches how your team already works: by project, by documentation set, by product area, or by release cycle. The goal is simple—when someone is editing a page, they should be able to locate the correct screenshot without opening old capture jobs or guessing which file is current.

Group images in a way that reflects real writing tasks. For example, screenshots for project setup can live together, while public documentation images, admin workspace images, and release-specific visuals can each have their own folder or collection. This makes it easier to support both active authoring and future updates.

Use consistent names so similar screenshots do not blur together. Include enough context to distinguish one image from another, especially when the same page changes between releases. Helpful naming patterns often include:

- the page or feature shown
- the audience or workspace context
- the release or version indicator
- whether the image is current, draft, or superseded

Avoid storing the same image in several places just to make it easier to find. Instead, keep one approved saved asset in the right shared location and rely on clear names and folders to make retrieval easy. This reduces duplication and lowers the chance that a writer inserts an outdated image.

Before you leave the asset library, verify that the saved screenshots are clearly separated from raw capture results. Reusable assets should look intentional and ready for insertion into documents, while temporary captures should remain part of short-term review work only. If your team manages screenshots across multiple projects or releases, the broader organization guidance in [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions) can help you standardize the structure.

## Fixing common problems with captures and saved assets
When a website capture does not behave as expected, the issue is usually easy to trace if you check the capture result, the saved asset details, and the destination location in Atloria.

If the page address opens but the screenshot is blank, partial, or missing important content, return to the capture screen and try again after confirming the page is fully loaded in the state you want to show. A page that is still rendering, loading navigation, or changing layout can produce an incomplete image. Recapturing the page often fixes this.

If the image saves successfully but you cannot find it later, review the details you entered during **Save as Asset**. The most common causes are an unclear **Title**, an unexpected **Filename** or label, or saving into the wrong project, folder, or collection. Open the asset location you selected and confirm the screenshot is actually there.

If several screenshots look nearly identical during version preparation, clean them up before authors start using them. Rename the approved asset with a release-specific identifier and remove outdated or duplicate capture results. This makes it much easier to choose the right visual during release review.

If a screenshot appears in capture results but not during document authoring, it was likely never saved into the reusable asset library. Go back to the results area, select the image, and use **Save as Asset**. Temporary results are useful for review, but they are not the same as approved reusable assets.

For larger cleanup and library issues, especially when teams share screenshots across projects, see [Troubleshooting Screenshot Availability Across Projects and Versions](doc:troubleshooting-screenshot-availability-across-projects-and-versions).

[SCREENSHOT: Example of a capture result available in results but not yet saved to the reusable asset library]

## Overview
This workflow in Atloria focuses on turning website captures into reusable documentation assets rather than leaving them as temporary screenshot results. You start with a page address, generate one or more screenshots, review the results, and then save the best image into a shared location that authors can use again later. That extra save step is what separates quick capture work from a reliable documentation asset workflow.

This process is especially useful when the same page image may appear in multiple places, such as product guides, release notes, version comparisons, or review materials. Instead of recapturing the same page every time, your team can keep an approved screenshot in a project folder or shared collection and reuse it during drafting. That saves time and reduces the risk of mixing old and new visuals.

The workflow also supports version preparation. When a release changes a page layout, navigation pattern, or feature state, you can capture the updated page, compare it with earlier results, and save the correct release-ready image with a name that clearly identifies its context. That makes it easier for reviewers and writers to tell which screenshot belongs to which release.

If you need help with the broader screenshot library after saving assets, continue with [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). If you need a refresher on the capture process itself, return to [Capturing and Saving Screenshots for Documentation](doc:capturing-and-saving-screenshots-for-documentation).

## Prerequisites
Before following this workflow in Atloria, make sure you have the basics ready:

- You can sign in and open your project workspace or the screenshot area your team uses. If needed, review [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account) and [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems).
- You already know how to run a basic screenshot capture. This guide builds on the earlier capture workflow and focuses on saving reusable assets rather than repeating the basics. Use [Capturing and Saving Screenshots for Documentation](doc:capturing-and-saving-screenshots-for-documentation) if you need that setup first.
- You have the correct website page address ready to paste into the **URL** field.
- You know which project, folder, or asset collection should store the approved screenshot after review.
- You know whether the screenshot is meant for one-time use or should be kept as a reusable asset for future documentation work.
- You have enough context to recognize the correct page state, such as the right release view, public page, or project screen.

It also helps to prepare a simple naming approach before you begin. If your team captures many similar pages, decide how you will label screenshots so they stay easy to find later. A clear title and destination choice at save time will make the asset much easier to reuse during authoring and version preparation.