Continuous Actions

For the conceptual overview, page layout, metric tables, and lifecycle, see Action Center. This page focuses on the design patterns and operational nuances specific to Continuous Actions.

What makes a Continuous Action different

A Continuous Action runs forever. It’s the right choice when:

The condition you care about is ongoing (not a one-off project)
New matching devices should automatically be added to the Action
Resolved devices should automatically leave
You want metrics over time: MTTR, Success Rate, devices currently unresolved

It’s the wrong choice for time-bound projects (use Snapshot Actions).

Reading the metrics: a rising MTTR means remediation is slowing down (process issue, not visibility). A falling Success Rate means automation isn’t actually resolving devices — devices may be churning in and out without ever hitting the resolution criteria.

Tags drive Continuous Action scope

Almost every Continuous Action begins with a tag clause: tags:End-User, tags:Server, tags:Acme-Acquired. Tags determine which devices a Vital applies to in the first place (Tags & Logic Engine), so a Continuous Action without a tag clause typically over-fires (chasing devices where the control isn’t even required).

Anatomy of a well-designed Continuous Action

Name:             Deploy CrowdStrike to End-User Laptops
Priority:         Important
Type:             Continuous
Owner:            SecOps team

Trigger query:    tags:End-User
                  AND system.crowdstrike.required:true
                  AND system.crowdstrike.deployed:false

Min time in view: 24 hours
                  (gives Microsoft Intune time to push the deployment)

Resolution:       system.crowdstrike.deployed:true
                  AND system.crowdstrike.functioning:true
                  AND system.crowdstrike.configuredCorrectly:true
                  (not just deployed — actually working AND configured per policy)

Automation 1:     Email to user
Automation 2:     ServiceNow ticket (after 48h in view)
Automation 3:     Power Automate flow to push Intune install (after 72h)

Three things this design gets right:

Tag-scoped — only End-User devices
Respects required — devices where CrowdStrike isn’t required (BYOD, Stock, etc.) don’t get caught
Strict resolution — devices only leave when CrowdStrike passes all four Vital booleans, not just deployed:true

Standard Continuous Action patterns

EDR coverage hygiene

Trigger:     tags:End-User AND system.crowdstrike.required:true AND system.crowdstrike.deployed:false
Min in view: 24 hours
Resolution:  system.crowdstrike.deployed:true AND system.crowdstrike.functioning:true
Action:      Email + ticket

The bread and butter. Catches gaps as they arise. Substitute system.microsoft_defender_atp or system.sentinelone for other EDRs.

Broken agent recovery (silent failure)

Trigger:     system.crowdstrike.deployed:true AND system.crowdstrike.functioning:false
Min in view: 48 hours
Resolution:  system.crowdstrike.functioning:true
Action:      Email user → ticket after 72h → Power Automate reinstall after 7 days

Catches silent failures. The 48-hour minimum prevents firing on agents that recover during maintenance windows.

MFA enrolment chase

Build a query using the User Inventory autocomplete to discover MFA-related fields in your tenant, then compose:

Trigger:     (MFA-related field per your tenant's user schema, set via autocomplete)
             AND tags:End-User
Min in view: 7 days
Resolution:  (inverted MFA state)
Action:      Email user + manager weekly until resolved

Microsoft Intune configuration drift

Trigger:     tags:End-User
             AND system.microsoft_intune.functioning:true
             AND system.microsoft_intune.configuredCorrectly:false
Min in view: 24 hours
Resolution:  system.microsoft_intune.configuredCorrectly:true
Action:      Ticket assigned to desktop engineering

SLAs and MTTR

Continuous Actions are the natural home for SLA tracking:

Metric	Target
MTTR < 7 days	Most security gaps
MTTR < 24 hours	Critical agent failures
Success Rate > 95%	Coverage hygiene
Success Rate > 80%	Drift / configuration

Plot these in a Reporting dashboard for leadership visibility. When MTTR trends up, that’s a process issue (not a visibility issue) — surface it before it becomes systemic.

Pause / archive

Lifecycle	Effect
Pause	Action stops adding/removing devices and firing automations. Metrics frozen. Resume restores.
Archive	Hides from default view. Metrics retained. Useful for retired-but-historical Actions.
Delete	Permanent. Use only after you’re sure.

Action Center

Conceptual overview

Snapshot Actions

Time-bound counterpart

Automation Templates

Pre-built starting points

Tags & Logic Engine

Scope the cohort

ThreatAware Protect

Getting Started

Inventory

Tags & Logic Engine

Vitals & Issues

Action Center

Integrations

Reporting

Access & Admin

Reference

Trust & Security

What makes a Continuous Action different

Tags drive Continuous Action scope

Anatomy of a well-designed Continuous Action

Standard Continuous Action patterns

SLAs and MTTR

Pause / archive

See also

Action Center

Snapshot Actions

Automation Templates

Tags & Logic Engine

​What makes a Continuous Action different

​Tags drive Continuous Action scope

​Anatomy of a well-designed Continuous Action

​Standard Continuous Action patterns

​SLAs and MTTR

​Pause / archive

​See also

Action Center

Snapshot Actions

Automation Templates

Tags & Logic Engine

What makes a Continuous Action different

Tags drive Continuous Action scope

Anatomy of a well-designed Continuous Action

Standard Continuous Action patterns

SLAs and MTTR

Pause / archive

See also