Filter Field Reference

Several parts of Athena let you describe machines with rules instead of hand-picking them: dynamic collections, automatic tagging rules, device monitors, and the report column picker. They all draw from one shared catalogue of filter fields. This page lists every predefined field, its data type, and the operators you can use against it, so you can write a rule once and know it will resolve.

Anatomy of a filter#

A single filter is a three-part comparison: a field path (which agent value to read), an operator (how to compare it), and a value (what to compare against). For example, OperatingSystem · Equals · Windows matches every Windows machine. Multiple filters are combined by the builder you are using (for example, a dynamic collection matches agents that satisfy all of its filters).

Each field has a type — String, Number, Boolean, or DateTime — and the type determines which operators are valid (see Operators). Values are compared as the field's type: numbers numerically, dates as timestamps, booleans as True/False, and strings textually.

Operators#

Ten operators are available. Which ones apply to a field depends on the field's type — for instance, Contains is a string operator, and GreaterThan only makes sense for numbers and dates.

The default operator offered for a new filter is Contains for String fields and Equals for Number, Boolean, and DateTime fields.

Predefined fields#

The fields below are always available, grouped by the category they appear under in the picker. Field paths that contain a dot (for example HardwareInfo.Disks.FreeSizeGB) read into a nested or multi-valued area of a machine's inventory.

Agent#

Agent Status#

System Type#

Hardware#

Disk fields match if any of a machine's own fixed drives satisfies the condition — so "Disk Free Space (GB) below 500" flags a machine when any one of its drives drops under 500 GB. Removable drives (such as USB sticks) and mapped network drives are ignored, as are boot/recovery stubs, so a plugged-in flash drive can't skew the result.

Software#

Installed-software fields match if any installed application satisfies the condition — for example, "Software Name contains Chrome" matches any machine that has Chrome installed.

Services#

Windows service fields match if any service on the machine satisfies the condition.

Network#

Security#

Security: Secure Boot 2023 certificate update#

These fields are also in the Security category. They track the Windows Secure Boot 2023 certificate rollout on each Windows machine. See Secure Boot 2023 Certificate Update for what each state and event means.

An agent that reports no Secure Boot servicing data (for example a Linux agent, a legacy-BIOS machine, or an older agent) has no value for these fields. As with every field, it then matches only NotEquals and NotContains. So to target machines that still need the update, use SecureBootUpdateState · Equals · NotStarted rather than NotEquals · Updated, which would also match those machines.

System Information#

Advanced#

Scan-discovered fields#

In addition to the predefined fields above, Athena offers filterable fields discovered from your own PowerShell scan results. Once an enabled scan has returned data, each property it reports becomes an additional field you can filter on, using the path form:

Scan.<scanDefinitionId>.<fieldName>

These appear in a category named after the scan (for example Scan: Disk Health). Scan fields are offered as String fields, so all string operators apply. A field is offered as soon as it appears in any recent result across the fleet — so a property that only some machines report is still selectable.

Module fields#

Add-on modules contribute their own filter fields to the same catalogue. They use the path form:

Module.<moduleId>.<fieldName>

In the picker, module fields appear in a category named after the module (for example Sysmon, BitLocker, Power Management, BIOS Configuration or Restart Policies). Because they come from the shared catalogue, you can use them in dynamic collections, automatic tagging rules, device monitors, and report filters, just like the predefined fields.

Types and operators#

Sysmon#

These fields report each agent's Sysmon state, as shown on the agent's Sysmon tab. See Sysmon Configuration.

BitLocker#

These fields come from the BitLocker volume status each Windows agent reports. See BitLocker Management. Most of them describe the OS drive, and have no value for an agent that has not reported an OS volume. A drive counts as encrypted only once it is fully encrypted. A drive that is still encrypting does not count yet.

SyncStatus has no value for an agent that has never been evaluated. Such an agent is not Unmanaged. So Module.bitlocker.SyncStatus · Equals · Drift lists exactly the agents that the Drift tile on the BitLocker settings tab counts. Like any field, NotEquals also matches agents that have never been evaluated.

Power Management#

These fields compare each agent's reported power settings with the power policy that applies to it. See Power Management.

Unlike most fields, DriftState, Managed and HasBattery always have a value. An agent that has never reported power settings is NotReported, and an agent no policy manages is Unmanaged. So Module.power.DriftState · Equals · Drift lists exactly the machines to fix. PolicyName is the one field that can be empty. To ask whether anything manages a machine, filter on Managed instead.

BIOS Configuration#

These fields compare each Windows agent's last BIOS read with the BIOS baseline that governs it. Drift is worked out when the rule is evaluated, never stored. See BIOS Configuration.

ComplianceState, Compliant and DriftCount always have a value, so Module.bios.ComplianceState · NotEquals · Compliant matches only agents that really have that state, Linux and macOS included as NotSupported. To find the machines to fix, use Module.bios.ComplianceState · Equals · Drifted.

Restart Policies#

These fields come from the restart state each agent last reported for Restart Policies, on Windows, Linux and macOS. An agent that has never reported its restart state has no value for any of them.

Use Contains on Reasons, because one machine can have several reasons: Module.restart.Reasons · Contains · OsUpdate. To find machines no restart policy on this server governs, use Module.restart.Policy · Equals with an empty value. To alert on machines that have gone too long without a reboot, use Module.restart.UptimeDays · GreaterThan · 30 in a device monitor. The Agents list also takes these fields in its address, for example /agents?field=Module.restart.State&value=Overdue.

Things to know#

• Licensed modules. Sysmon, BitLocker, Power Management, BIOS Configuration and Restart Policies are sold separately. If your license doesn't include a module, its fields don't appear in the picker, and any existing rule that uses them matches no agents. License changes take effect the next time a rule is evaluated. See Licensing.
• Unknown paths match nothing. A Module. path that names a module or field that isn't loaded matches no agents, even with NotEquals. The server log records a warning for it.
• Agents with no value. For a known field, an agent with no value (for example, one that hasn't reported yet) fails every operator except NotEquals and NotContains. So Module.sysmon.State · NotEquals · InSync also matches agents that have never reported. This is the same rule the predefined fields use.

Getting the live list#

The builders read this catalogue live, so it always reflects your current scan fields. You can fetch the same list from the API:

Where these fields are used#

• Dynamic collections — membership is every agent that matches the collection's filters.
• Automatic tagging rules — apply tags to agents that match a rule.
• Device monitors — raise alerts when a condition over these fields is met.
• Reports — choose these fields as report columns and filters.