Priority¶

Priority ranks entities by business importance. It is one of the most widely leveraged classifications in TrackMe — alerting, virtual groups, automation, and the UI all use it to decide which entities to act on or surface first. You can set it by hand or assign it automatically with priority policies.

A priority policy rule with a regex / lookup / SPL method

The priority levels¶

Level	Meaning
critical	The highest business importance.
high
medium
low	The lowest business importance.
pending	A “not yet triaged” / discovery bucket — not the highest priority despite sorting last.

Newly discovered entities take the tenant’s default priority (medium unless you change it).

Where priority is used¶

Priority is classification, not scoring — it never changes an entity’s score or state (see Impact scoring & thresholds). Instead, it is the lever many features use to decide which entities to notify on, surface, or act on:

Alerting & notification routing: Stateful alerting can route by priority. The alert action’s priority_levels_emails and priority_levels_commands settings choose which entities actually send emails and run commands — so you can, for example, email only critical and high entities while everything is still tracked and recorded. An entity off the list still alerts internally; only its email/command notifications are suppressed. (The ingest channel is not priority-gated.) The entity’s current priority is read at alert time and shown in the email and on the incident record. See Stateful alerting.
Notable events: Every TrackMe notable event carries the entity’s priority as a field, so your Enterprise Security or correlation logic can prioritise and route on it.
Virtual Groups: A virtual group can be scoped to chosen priority levels (for example only high and critical), and its card shows a priority breakdown across the tenants it aggregates.
Finding and focusing in the UI: Priority is a filter and search axis on every entity table. Tenant cards show a red-by-priority breakdown, and a High-priority overview highlights entities that are red at high or critical priority — the fastest “what should I look at first?” view.
Automation scoping: Several features can be limited to chosen priority levels: auto-label rules, ML outlier detection (train and score only where it matters), and AI Advisor automated actions (so autonomous tuning only touches the entities you trust it with). AI investigations and chat also include the entity’s priority in the context they send to the model.

Setting priority¶

Manually, per entity — a manual priority is flagged as such and is never overwritten by a policy. Clear the manual flag to return the entity to policy control.
By policy — a priority policy assigns a level automatically, using one of three resolution methods (see below).

When several priority policies match one entity, the highest level wins.

Priority policies¶

Priority is one of the three policy-driven classifications (with tags and SLA). A policy matches entities using one of three methods, which you can mix in a single policy set:

Method	How it matches
regex	A regular expression against a field such as `object_id`, `index`, `sourcetype`, or `host`. Matching uses `re.search` — an unanchored pattern matches anywhere.
lookup	A Splunk lookup (CSV or KV Store); the priority value can be pulled from a lookup column.
SPL search	The results of a saved search.

Policies are per component (DSM / DHM / MHM / FLX / FQM / WLK). Removing a policy auto-cleans the assignments it made on the next cycle. The add/edit modal can preview matches so you can test a regex or search before saving.

Every priority change is audited — review an entity’s history in the Audit tab of its main screen. You can also set priority in bulk from SPL, e.g. | trackme url="/services/trackme/v2/splk_dsm/write/ds_update_priority" mode="post" body="{'tenant_id': 'mytenant', 'priority': 'high', 'object_list': '<entity1>,<entity2>'}". In high-scale environments, roll out priority progressively and pair it with tiered alerting to reduce alert fatigue.

Note

pending is a discovery state, not an escalation — do not assume it ranks above critical. And because conflicts resolve by level, not by policy order, adjust the levels (or narrow the policies) if the “wrong” policy wins. Prefer lookups over SPL for static data — SPL policies add a little search load each cycle.