> ## Documentation Index
> Fetch the complete documentation index at: https://docs.threataware.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Snapshot Actions

> Time-bound projects with fixed scope, deadlines, and progress tracking

For the conceptual overview, page layout, and metric tables, see [Action Center](/automation). This page focuses on Snapshot-specific patterns, deadlines, and project-flow.

## What makes a Snapshot Action different

A **Snapshot Action** captures the set of devices matching at **creation time** and tracks them to remediation. New devices that later match are *not* added. The Action ends when all snapshotted devices resolve, or when you close it manually.

It's the right choice for:

* **OS migrations** — "1,234 Windows 10 devices must be on Windows 11 by Q4"
* **Decommissioning waves** — "these 87 devices are scheduled for replacement"
* **Compliance pushes** — "these audit-flagged devices must be resolved by Friday"
* **Acquisition integration** — "these 412 newly-acquired devices need our baseline"

It's the wrong choice for ongoing hygiene (use [Continuous Actions](/actions-continuous)).

## Tags drive the Snapshot cohort

Most Snapshot Actions are built from a tag-anchored query (`tags:Acme-Acquired`, `tags:Stock`, `tags:End-User AND osVersion:Windows 10`). Because the snapshot is fixed at creation time, the tag membership at that moment defines the project scope. If you later need a different cohort, create a new Snapshot — don't mutate the existing one. See [Tags & Logic Engine](/tags-and-logic-engine).

## Status colour-coding

The progress bar uses three colours based on progress vs. deadline:

| Colour    | Meaning                                                    |
| --------- | ---------------------------------------------------------- |
| **Green** | On track — well within the deadline at current pace        |
| **Amber** | At risk — deadline approaching with significant unresolved |
| **Red**   | Overdue — past deadline with unresolved devices            |

This makes the page scannable: green = ignore, amber = check in, red = action needed.

## Creating a Snapshot Action

<Steps>
  <Step title="Build the query in Devices">
    Filter to the cohort. For a Windows 10 → 11 migration: `os:Windows AND osVersion:Windows 10` (plus other constraints — region, owner, etc. — confirm field values via autocomplete).
  </Step>

  <Step title="Click Create Action">
    From the bottom of the grid.
  </Step>

  <Step title="Choose Snapshot type">
    The set of matching devices is captured immediately — they won't grow or shrink unless devices resolve or you manually add/remove.
  </Step>

  <Step title="Set deadline">
    The visual status uses this date for amber / red transitions.
  </Step>

  <Step title="Assign owner">
    Often a Team (the people who own delivery), sometimes an individual.
  </Step>

  <Step title="Configure automation">
    For Snapshot Actions, automation typically fires:

    * **On creation** — to seed tickets, notify owners
    * **Periodically** — weekly status email to leadership
    * **On deadline approach** — escalation alerts

    More often than Continuous, automation for Snapshot is reporting-heavy rather than remediation-heavy (the remediation usually happens through existing channels — Intune deployments, manual upgrades, scheduled maintenance).
  </Step>

  <Step title="Save">
    Action goes live. Initial automation fires.
  </Step>
</Steps>

## Common Snapshot patterns

<AccordionGroup>
  <Accordion title="OS migration tracker">
    ```
    Created from: os:Windows AND tags:End-User AND osVersion:Windows 10
    Snapshot:     1,234 devices
    Deadline:     2026-12-31
    Automation:   Weekly status email to migration lead;
                  ServiceNow subtask per device for the field team
    Resolution:   osVersion changes off "Windows 10" (devices fall out of the snapshot scope)
    ```
  </Accordion>

  <Accordion title="Acquisition integration">
    ```
    Created from: tags:Acme-Acquired
    Snapshot:     412 devices
    Deadline:     +90 days from acquisition close
    Automation:   Per-device Microsoft Intune enrolment ticket;
                  weekly progress to acquisition program lead
    Resolution:   system.microsoft_intune.deployed:true AND system.microsoft_intune.functioning:true AND system.crowdstrike.deployed:true AND system.crowdstrike.functioning:true
    ```
  </Accordion>

  <Accordion title="Audit remediation">
    ```
    Created from: A list of devices uploaded after an external audit
    Snapshot:     67 devices
    Deadline:     2 weeks (auditor-mandated)
    Automation:   Immediate ticket + daily email to compliance lead
    Resolution:   All flagged controls = Healthy
    ```
  </Accordion>

  <Accordion title="Decommissioning wave">
    ```
    Created from: A scope built from your tag rules (e.g. tags:Stock plus a
                  manually uploaded device list of replacement candidates)
    Snapshot:     87 devices
    Deadline:     End of replacement cycle
    Automation:   Lifecycle workflow per device (data backup → user prep → reclaim)
    Resolution:   Devices move to Inactive when the source tools stop reporting them
    ```
  </Accordion>
</AccordionGroup>

## Managing in-flight Snapshot Actions

| Operation                | When to use                                                                                                                 |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| **Update deadline**      | If scope shifts or external dependencies extend the project                                                                 |
| **Add devices manually** | Rare — but possible for ad-hoc additions                                                                                    |
| **Remove devices**       | When a device is genuinely out of scope (e.g. decommissioned mid-project)                                                   |
| **Mark as complete**     | Even if some devices are unresolved — useful when a project ends and remaining devices roll into ongoing Continuous Actions |
| **Pause**                | If the project is on hold (organisational reasons) — preserves metrics, stops automation                                    |

## Reporting Snapshot progress

Snapshot Actions are leadership-friendly:

* **Progress bar** is the headline visual
* **N / Total** is concrete
* **Deadline** sets context
* Trend over time (in [Reporting](/reporting)) shows velocity

Build a Reporting app that surfaces all active Snapshots as a roadmap view — typically what programme management wants.

## Snapshot vs. Continuous decision tree

Two questions:

1. **Is the work bounded in time?** Yes → Snapshot. No → Continuous.
2. **Do new matching devices show up over time and need handling?** Yes → Continuous. No → Snapshot.

When in doubt, ask "will I want a fixed set or a self-updating set?"

## See also

<CardGroup cols={3}>
  <Card title="Action Center" icon="bolt" href="/automation">
    Conceptual overview
  </Card>

  <Card title="Continuous Actions" icon="arrows-rotate" href="/actions-continuous">
    Ongoing hygiene counterpart
  </Card>

  <Card title="Automation Templates" icon="grid-2" href="/automation-templates">
    Pre-built starting points
  </Card>

  <Card title="Tags & Logic Engine" icon="tags" href="/tags-and-logic-engine">
    Define the snapshot cohort
  </Card>
</CardGroup>