QUICK START - Cross-tenant domain views with Virtual Groups¶
Aggregate entities from multiple tenants into unified domain views — without any new monitoring infrastructure
This quickstart guides you through the design and implementation of Virtual Groups in TrackMe — a powerful approach to creating cross-tenant, read-only aggregation views that appear alongside your regular tenant cards in the Virtual Tenants grid.
The key idea: tags policies distribute your entities across logical domains (cloud, infra, network…), and Virtual Groups surface exactly those domains as first-class cards — spanning multiple tenants at once.
This quickstart is built around a concrete example with two tenants and ~10,000 entities, culminating in four Virtual Group cards each scoped to a distinct business domain.
Prerequisites: An existing TrackMe deployment with at least one Virtual Tenant, discovered entities, and a lookup file (CSV or KVstore) containing knowledge about your environment.
Hint
For detailed reference documentation on tags policies, refer to Accessing, defining and managing tags policies.
The goal: what we are building¶
Before diving into the steps, here is what the end result looks like. Two tenants — hosts-monitor (Data Host Monitoring) and secops (Data Source Monitoring) — hold roughly 10,000 entities between them. After this quickstart, the Virtual Tenants grid will show four Virtual Group cards, each aggregating entities from both tenants, scoped to a specific business domain:
Each group card shows:
The number of tenants contributing entities to the group
The total entity count (aggregated across all tenants and components in scope)
The number of alerting entities (red/orange state)
A context menu to open the group overview, refresh, edit, or delete
The design relies on a single, elegant building block: tags. Every entity is tagged with its business domain by a lookup-based tags policy. Virtual Groups then use a free-form filter expression (tags="cloud", tags="infra" OR tags="os", etc.) to pick up exactly the right entities — automatically, from any tenant.
Our scenario¶
We start with two tenants in the Virtual Tenants grid, no Virtual Groups yet:
hosts-monitor — Data Host Monitoring (DHM) tenant. Monitors ~5,000 data hosts.
secops — Data Source Monitoring (DSM) tenant. Monitors ~5,000 data source entities.
Both tenants share the same domain taxonomy: each entity belongs to one or more of these domains — cloud, infra, os, net, firewall, syslog, web, identity. This knowledge lives in a single lookup file: example_cmdb_indexes.csv, which maps index patterns (for DSM) and host patterns (for DHM) to tags.
The plan:
Create a lookup-based tags policy on
hosts-monitor(DHM) to tag all data hostsCreate a lookup-based tags policy on
secops(DSM) to tag all data sourcesCreate one Virtual Group per domain, referencing both tenants
Step 1 — Tag entities in hosts-monitor (DHM)¶
From the hosts-monitor Tenant Home, open Actions → Manage tags policies and create a new Lookup based policy.
Configure the policy wizard:
Step 1: Select the lookup transform
example_cmdb_indexes (csv)Step 2: Field mapping — map lookup field
indexto entity fielddata_index, match mode WildcardStep 3: Tags field — select
tags
Run the policy simulation before saving. The simulation scans the entire entity collection and previews which entities would be matched and what tags would be assigned. For hosts-monitor, 80 entities are matched and 8 distinct tags are discovered (infra, net, firewall, cloud, os, syslog, web, identity):
Click Add this new policy, then Execute tracker to apply the tag assignments immediately.
Step 2 — Tag entities in secops (DSM)¶
Repeat the same process on the secops tenant. The same lookup example_cmdb_indexes (csv) is used — the lookup preview confirms the mapping of index patterns to tags:
With 5,000 data sources in scope, the simulation confirms all entities are matched and 8 distinct tags are discovered. The result summary at the bottom of the simulation output confirms the coverage:
Execute the tracker. All data sources in secops are now tagged with their business domain.
Result: entities distributed across domains¶
With both tags policies applied, every entity across both tenants is now tagged. The Tenant Home Group by Tags view makes this immediately visible — entities are cleanly distributed across 8 domain buckets:
This is the foundation Virtual Groups build upon. The tags are the single source of truth — Virtual Groups simply reference them.
Step 3 — Create Virtual Groups¶
Now we create one Virtual Group per domain. Each group spans both tenants and both components (DHM + DSM), filtered by the relevant tag(s).
Creating the “Cloud” group¶
Open the Administration menu (top-right) and select Create a virtual group. The wizard opens.
Step 1 — Group Identity: Give the group a human-readable alias and an auto-generated ID:
Step 2 — Tenants & Components: Add both tenants to the scope. For each tenant, select the relevant monitoring components. Here we include DHM from hosts-monitor and DSM from secops:
Step 3 — Priority Filter: Optionally restrict the group to entities of specific priority levels. Leaving all priorities enabled means all entities matching the domain filter are included — the most common choice for a full domain view:
Step 4 — Additional Filters: This is where the domain scoping happens. Enter a free-form filter expression using entity fields. For the Cloud group, the expression is simply tags="cloud":
Hint
The filter syntax supports wildcards (*, ?), logical operators (AND, OR), and parentheses for grouping. Comparisons are case-insensitive. Any entity field is supported — tags, data_index, alias, priority, component, and more. Leave the field blank to include all entities (after applying the Priority Filter above).
Step 5 — RBAC: Define which Splunk roles can see this Virtual Group. By default, all three TrackMe roles are pre-populated. You can remove roles to restrict visibility to specific teams:
Step 6 — Simulate: Before creating the group, run a simulation to preview how many entities will be included across each component. For the Cloud group, 312 entities are found across 2 components (DHM and DSM), confirming the filter is correct:
Step 7 — Review & Create: A final summary confirms all settings before creation. Click Create Group:
Creating the remaining groups¶
Repeat the wizard for each remaining domain. The only things that change between groups are the alias and the filter expression.
For example, the Infra & OS group aggregates three related domains into one view — useful when infra, os, and syslog are managed by the same team and benefit from a consolidated perspective:
The Net & Firewall and Web groups follow the same pattern with their respective tag expressions (tags="net" OR tags="firewall" and tags="web").
Step 4 — The final result¶
With all four groups created, the Virtual Tenants grid now shows a dedicated Virtual Groups section beneath the tenant cards. Each group card displays the aggregated entity count and alert status at a glance:
All four groups are live, sourcing their data from both tenants simultaneously. The cards update automatically alongside the rest of the Virtual Tenants grid — no manual refresh required.
Exploring a Virtual Group¶
Double-click any Virtual Group card (or click Open in its context menu) to open the Virtual Group Overview. The overview provides a tabbed, per-component breakdown of all aggregated entities.
The active filter expression is shown at the top so it is always clear which entities are in scope. Charts give an immediate sense of the health distribution (by priority and by state) for each component, followed by the full entity table:
From the entity table, clicking on any entity opens its full Entity Overview — the same deep-dive view available from a regular Tenant Home, with event latency, delay, volume and hourly count charts, key information panel, and AI assistant access:
Managing Virtual Groups¶
Each Virtual Group card has a context menu (right-click or the ⋮ icon) with four actions:
Open — opens the Virtual Group Overview modal
Refresh — triggers an immediate re-fetch of entity counts for this group
Edit group — reopens the creation wizard pre-populated with the current configuration (admin only)
Delete group — removes the Virtual Group definition (admin only); no entity data is deleted
Summary and best practices¶
Key takeaways
Tags are the foundation. Virtual Groups do not move or copy entities — they reference them by tag. Invest in a clean, consistent tagging strategy and your groups will always stay up to date automatically.
One lookup, many groups. A single lookup-based tags policy per tenant can feed any number of Virtual Groups. Add a new domain? Add a row to the lookup, run the tracker, create a new group — done.
Compose domains freely. The filter expression supports full boolean logic (
AND,OR, parentheses, wildcards). You can combine multiple tags to represent composite domains (e.g.,Infra & OS), add priority constraints, or filter by any entity field.Cross-tenant by design. A single Virtual Group can span any number of tenants and any combination of monitoring components (DSM, DHM, MHM, FLX, FQM, WLK). This is its core value: one view, many sources.
Read-only aggregation. Virtual Groups do not participate in alerting, scoring, or the decision maker. They are pure visibility constructs — no monitoring side-effects.
Simulate before creating. The Simulate step in the wizard lets you verify entity counts before committing. Use it to catch typos in filter expressions and confirm that both components contribute the expected entities.
RBAC per group. Different groups can have different visibility rules. Use this to surface domain-specific views only to the teams that need them, without exposing the full tenant scope.
Priority filter for focused views. When a domain contains thousands of entities, consider creating a companion group with
Priority Filter = Critical + Highonly — giving on-call teams a laser-focused alert view alongside the full domain view.