Skip to main content
Tier: Action Center (including automatic ticket creation) is included in the Protect tier. Customers on Connect or Discover can build saved views and export them, but cannot create Continuous or Snapshot Actions.

​
The Action Center

The Action Center at /action-center is Protect’s automation hub. It transforms “we have a list of devices to fix” into “these devices are auto-tracked through to remediation, with MTTR and Success Rate reported.” Action Center showing filter chips, Create Action button, Continuous (5) section with metrics, Snapshot (3) section with progress bars, Automation Templates panel on the right

​
Page layout

​
Continuous Actions

A Continuous Action runs forever. Devices entering the matching query are added automatically; devices leaving are removed. The classic example is “any End-User laptop without CrowdStrike.”

​
Per-row metrics (Continuous)

Each Continuous Action shows:

​
Use cases for Continuous

  • Coverage hygiene — “ensure every End-User device has CrowdStrike”
  • Broken-agent recovery — “alert when an Endpoint Detection and Response (EDR) agent stops reporting”
  • New-device onboarding — “every device under 7 days old should hit baseline by day 14”
  • Configuration drift — “any device that loses BitLocker should trigger a ticket”

​
Snapshot Actions

A Snapshot Action captures the set of devices matching at creation time and tracks remediation against that fixed set. New devices that later match aren’t added. Useful for projects with a fixed scope.

​
Per-row layout (Snapshot)

Three examples:

​
Use cases for Snapshot

  • OS migrations — “1,234 Windows 10 devices need to be on Windows 11 by Q4”
  • Decommissioning waves — “these 87 devices are scheduled for replacement”
  • Compliance remediation — “this batch of devices flagged in audit must be resolved by Friday”
  • Acquisition integration — “these new acquired devices need our security baseline”

​
Tags drive Action targeting

Tags are how you scope an Action to the right cohort. tags:End-User, tags:Server, tags:Acme-Acquired — these clauses make the difference between an Action that catches the right devices and one that fires noise. Most well-designed trigger queries combine a tag clause (the population) with a Vital clause (the failure condition):
Because tag membership is rule-driven, new devices joining the tag are automatically picked up by the Continuous Action that targets it — no manual maintenance. See Tags & Logic Engine for how to design tag rules that hold up under estate growth.

​
Creating an Action

The flow always starts with a query:
1

Build the query

In Devices, Users, or Issues, build the filter that captures the cohort you want to remediate.
2

Click Create Action

The footer’s Create Action button (sometimes the green + Create Action on the Action Center page).
3

Configure basics

  • Name — descriptive, mentioning the target outcome (Deploy CrowdStrike to End-User Laptops)
  • Priority — Critical / Important / standard
  • Type — Continuous (always-on) or Snapshot (fixed scope)
  • Deadline (Snapshot only)
  • Owner / Assigned Team
4

Choose automation

Tick one or more channels (see Automation Types below).
5

Set advanced options

  • Minimum time in view — debounce so devices in transient state don’t trigger
  • Resolution criteria — explicit definition of “fixed” beyond just leaving the query
  • Additional fields — extra device properties to include in automation payloads
6

Save & activate

Save the Action. It starts immediately — first cycle runs within minutes.

​
Automation types

The simplest path. Send an email per device entering the Action, or a daily/weekly digest.
  • Recipient(s) — comma-separated
  • Subject — supports {{FieldName}} interpolation
  • Body — supports {{FieldName}} interpolation and the {{DeviceLink}} shortcut
  • Optional: digest mode (one summary email instead of per-device)
Best for: “alert the security team when a new gap appears” — no ticketing system needed.

​
Automation templates

The right-hand panel ships with pre-built configurations for common automation patterns — Security Notification, Move to Blocked Security Group, Alert Non-Compliant Device, Reboot Device, Isolate Device, Create Incident. Click any template to start a Create Action flow with that automation pre-filled. See Automation Templates for the full catalogue, defaults, and customisation guidance.

​
Advanced configuration

Debounce against transient state. A device must stay in the query for X hours before the automation fires.Typical settings:
  • Agent offline triggers — 48 hours (agents update; brief absence shouldn’t fire)
  • New device baseline — 24 hours (deployment may still be in progress)
  • Configuration drift — 4 hours (policy propagation time)
  • Critical alerts — 0 (fire immediately)
Default resolution = “device no longer matches query”. Sometimes that’s wrong — a device leaving the query because it went offline isn’t actually fixed.Use explicit resolution criteria:
Forces the Action to wait for a good state, not just any state.
Device fields to include in the automation payload — useful when downstream systems need context.Common picks:
  • metadata.serial_number — for warranty lookup
  • lastUser.email — to notify owner
  • lastUser.department — for ticket routing
  • lastUser.jobTitle — for context in escalations
  • publicIp — for network troubleshooting

​
Action lifecycle

​
Pausing and disabling automations

Two levels of kill switch are surfaced in the live Action Center: There is no Snapshot-section equivalent of Pause All in the current build — pause Snapshot work item-by-item, or delete the Action to halt it entirely.

​
Automation Log

The right-panel Automation Log records every automation execution:
  • Action name
  • Device acted on
  • Channel (email / ticket / webhook)
  • Success / failure
  • Response from external system (for tickets, the ticket number; for webhooks, the response code)
  • Retry count
Filter by:
  • Action name
  • Channel
  • Success / failure
  • Time range
Use for debugging webhooks (was the payload accepted?), reconciling against the destination system (did the ticket appear?), and SLA reporting (how many automations fired this week?).

​
Best practices

The first version of any Action should send an email. Validate the cohort is correct, then layer in tickets / webhooks once you trust the query.
For all triggers tied to “stopped reporting” or “configuration changed”, set at least 24-48 hours. Saves you from chasing devices that recover on their own during maintenance windows.
Default resolution is “no longer matches” which silently equates offline with fixed. Always specify a positive resolution state for safety.
OS migrations, decommissioning, compliance pushes — Snapshot. Always-on coverage validation, broken-agent recovery, drift detection — Continuous.
Set a recurring slot to scan failed automations. Patterns of failure (one ticket type always failing, one webhook always timing out) point to systemic issues you’d otherwise miss.

​
Cross-references

Continuous Actions

Deep dive

Snapshot Actions

Deep dive

Automation Templates

Pre-built starting points

Issues

The detection source

Security Monitoring

Vitals drives most queries

Tags & Logic Engine

Target the right cohort

Integrations

Configure outbound channels