Skip to main content
For the conceptual overview, page layout, and metric tables, see Action Center. 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).

​
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.

​
Status colour-coding

The progress bar uses three colours based on progress vs. deadline: This makes the page scannable: green = ignore, amber = check in, red = action needed.

​
Creating a Snapshot Action

1

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).
2

Click Create Action

From the bottom of the grid.
3

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.
4

Set deadline

The visual status uses this date for amber / red transitions.
5

Assign owner

Often a Team (the people who own delivery), sometimes an individual.
6

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).
7

Save

Action goes live. Initial automation fires.

​
Common Snapshot patterns

​
Managing in-flight Snapshot Actions

​
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) 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

Action Center

Conceptual overview

Continuous Actions

Ongoing hygiene counterpart

Automation Templates

Pre-built starting points

Tags & Logic Engine

Define the snapshot cohort