The four-boolean model
Every Vital — one integration’s view of one device — is exposed in the query language as four boolean fields:true or false across the four fields.
Composite states explained
The composite badges shown on a device’s Vitals panel map to the four booleans like this. Badge labels are taken verbatim from the live UI (device detail → VITALS section):
Scanner-type integrations (Qualys, Lansweeper, etc.) use a different two-state pair: Detected and Not Detected Recently.
In conversation we use Not Healthy as an umbrella for any required-but-not-Healthy state (
required:true AND (deployed:false OR functioning:false OR configuredCorrectly:false)).
The Protect API surfaces some of these counts under slightly different names (e.g.
configurationCompliant for the configuredCorrectly boolean). See API → Vitals for the API field names; the query language always uses the four field names listed above.Query expressions
The corresponding query language clauses (using CrowdStrike as the example):How each boolean is computed
required
required
Driven by tag rules. In each integration’s configuration (Devices column gear → Configure Mode), you tick which tags require this control. A device whose tags match makes
required:true.Devices with required:false are not in scope for this control — they don’t fail Vitals on it.deployed
deployed
true when the integration sees this device in its inventory at all. Computed by comparing the device’s presence across all your tools — if Microsoft Intune knows about the device but CrowdStrike doesn’t, system.crowdstrike.deployed:false.This is “is the agent installed?”.functioning
functioning
true when the integration’s per-device data is reasonably fresh relative to the device’s general activity. If the device is clearly online (recent activity in other tools) but this integration’s last-seen is stale, functioning:false.This is silent-failure detection — broken agents that look healthy in their own console but stopped protecting weeks ago.configuredCorrectly
configuredCorrectly
true when the configuration checks you’ve defined match what the source tool reports. Each integration exposes different fields (prevention policy, tamper protection, signature freshness, encryption settings, etc.) and you tick which ones to enforce per tag.A device that passes deployed and functioning but fails any required configuration check is configuredCorrectly:false.The dashboard visualisation
The Integration Control panel on the Dashboard shows the composite for each integration:- N/M Healthy count = devices where all four booleans are favourable, out of the devices where
required:true - Percentage = N/M as a percentage
- Trend arrow = change vs last period
- NOW / 7D / 1M / 3M / 1Y buttons = time range for the displayed value
Per-integration nuances
The four-boolean model is consistent, but what each boolean considers varies by integration:
If a configuration check you need isn’t available, that’s typically because the vendor’s API doesn’t expose the field. Open a request — Protect engineering adds checks as vendor APIs evolve.
Common saved-view patterns
See also
Security Monitoring
The conceptual model
Vitals Configuration
Setup walk-through
Query Syntax
Full grammar