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

# Action Center on ThreatAware 3.2

> How Action Center works on ThreatAware 3.2: Continuous and Snapshot Actions with email, ticket, Teams/Slack, Power Automate and webhook automation

> [!WARNING]
>
> **This page is for tenants still on ThreatAware 3.2.** ThreatAware 3.3 replaces this Action Center with a node-based flow editor, and tracking devices in a saved view moves to Tracked Views. See [Action Center](https://docs.threataware.com/automation.md) for 3.3.

> [!NOTE]
>
> **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 ThreatAware'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](https://mintcdn.com/threatawareltd/IwzdezxNqgZB-5I4/images/core/action-center-landing.png?fit=max\&auto=format\&n=IwzdezxNqgZB-5I4\&q=85\&s=8e3614aef4f578bf8908d38014c6801a)

### Page layout

| Region | What's there |
| - | - |
| **Top filters** | `Active ▾` (state) • `All ▾` (severity) • `All / Important / Critical` chips |
| **Top-right** | `+ Create Action` (green) |
| **Continuous (N)** | Always-on actions, with per-row metrics |
| **Snapshot (N)** | Time-bound actions with deadlines and progress |
| **Right panel — Automation Templates** | Pre-built templates: Security Notification, Move to Blocked Security Group, Alert Non-Compliant Device, Reboot Device, Isolate Device, Create Incident |
| **Right panel — Automation Log** | Every automation execution with success/failure |

## 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:

| Metric | Meaning |
| - | - |
| **Name** | Action title |
| **Priority** | Important / Critical / standard |
| **Owner** | Assigned user or team |
| ⚡ **time ago** | When the Action last triggered |
| **UNRESOLVED** | Devices currently in the matching set |
| **SUCCESS %** | Of devices that have ever entered, what proportion have resolved |
| **DAY MTTR** | Mean time to remediation in days |
| ✉️ icon | Automation channel(s) configured |
| `>` | Drill-down |

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

| Element | Meaning |
| - | - |
| **Name** | Action title |
| **Priority** | Critical / Important / standard |
| **Owner** | Assigned user or team |
| **Due date** | Configured deadline |
| **N / Total** | Resolved / Total devices |
| **Progress bar** | Visual progress with green / amber / red |

Three examples:

| Action | Owner | Due | Progress |
| - | - | - | - |
| Upgrade of... (Critical) | Gavin Watkins | 25/06/2026 | 134 / 182 |
| Migration to Microsoft... | *Everyone* (team) | 27/07/2026 | 40 / 290 |
| Machines with no Tags | *Everyone* | 23/07/2026 | 114 / 243 |

### 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):

```text theme={null}
tags:End-User AND system.crowdstrike.required:true AND system.crowdstrike.deployed:false
```

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](https://docs.threataware.com/tags.md) 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](https://docs.threataware.com/user-inventory.md), or [Issues](https://docs.threataware.com/issues.md), 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](#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

**Email**

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.

**Tickets (ITSM)**

Create tickets in **ServiceNow**, **Halo Service Desk**, **Freshservice**, or **Datto Autotask PSA (Professional Services Automation)**.

* Ticket type / category
* Priority
* Assignment group
* Title / description templates (with `{{Field}}` interpolation)
* Custom fields

For ServiceNow, two-way sync: closing the ticket resolves the device automatically.

Best for: *"this gap is real work, route to the team that owns it"*.

**Teams / Slack**

Webhook-based notifications to a Microsoft Teams channel or Slack channel.

* Channel webhook URL
* Message template (Markdown / Adaptive Card)

Best for: *"team awareness with low friction"* — typically pairs with another channel like tickets.

**Power Automate**

Send the device payload to a Power Automate flow. From there, you can chain anything in the Microsoft 365 ecosystem — Intune deployments, AD attribute updates, SharePoint workflows, approval flows.

The Action calls a "When HTTP request is received" trigger. Pass the device fields as JSON; the flow does the rest.

Best for: *"complex remediation with conditional branches"*.

**Custom webhook**

POST the device payload to any URL.

* Method (POST by default)
* Headers (including auth)
* Body template with `{{Field}}` interpolation
* JSON / form encoded

Best for: *"connecting to systems we don't have a first-class template for"* — Tines, Demisto, AWS Lambda, internal APIs.

## 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](https://docs.threataware.com/automation-templates.md) for the full catalogue, defaults, and customisation guidance.

## Advanced configuration

> **Minimum Time in View**
>
> 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)

> **Resolution Criteria**
>
> 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:
>
> ```text theme={null}
> Trigger:    system.crowdstrike.required:true AND system.crowdstrike.deployed:false
> Resolution: system.crowdstrike.deployed:true AND system.crowdstrike.functioning:true AND system.crowdstrike.configuredCorrectly:true
> ```
>
> Forces the Action to wait for a *good* state, not just *any* state.

> **Additional Fields**
>
> 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

| # | Stage | When |
| - | - | - |
| 1 | Action created | Settings → Action Center |
| 2 | Device matches query | Hourly evaluation |
| 3 | Minimum-time-in-view countdown | Configurable per Action |
| 4 | Automation fires | Email / Ticket / Webhook |
| 5 | Device receives remediation | Manual or automated |
| 6 | Resolution criteria met | Next sync evaluation |
| 7 | Device leaves Action | Success Rate ticks up |
| 8 | MTTR recalculated | Visible on Action card |

## Pausing and disabling automations

Two levels of kill switch are surfaced in the live Action Center:

| Scope | Where | Notes |
| - | - | - |
| **Global — all Continuous Actions** | Action Center → top of the Continuous section → **Pause All** button | Halts every Continuous Action in the tenant. Snapshot Actions do not have a Pause All button (they are time-bound and resolve naturally). |
| **Per-Action** | Open an Action → header → **Pause** / **Edit** / **Archive** / **Delete** | An individual Action can be paused, edited, archived, or deleted. Paused Actions still appear in the list but do not fire automations. |

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

> **Email first, automation second**
>
> 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.

> **Always set minimum time in view**
>
> 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.

> **Define explicit resolution criteria**
>
> Default resolution is "no longer matches" which silently equates offline with fixed. Always specify a positive resolution state for safety.

> **Use Snapshot for projects, Continuous for hygiene**
>
> OS migrations, decommissioning, compliance pushes — Snapshot. Always-on coverage validation, broken-agent recovery, drift detection — Continuous.

> **Weekly review of the Automation Log**
>
> 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](https://docs.threataware.com/actions-continuous.md)**
>
> Deep dive

> **[Snapshot Actions](https://docs.threataware.com/actions-snapshot.md)**
>
> Deep dive

> **[Automation Templates](https://docs.threataware.com/automation-templates.md)**
>
> Pre-built starting points

> **[Issues](https://docs.threataware.com/issues.md)**
>
> The detection source

> **[Security Monitoring](https://docs.threataware.com/security-monitoring.md)**
>
> Vitals drives most queries

> **[Tags](https://docs.threataware.com/tags.md)**
>
> Target the right cohort

> **[Integrations](https://docs.threataware.com/integrations.md)**
>
> Configure outbound channels


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.