User Activity Monitoring¶
Who is doing what on your Splunk: one tenant watches every account through the audit trail, the introspection and the REST API catalogs, raises findings from sixteen built-in policies and your custom policies, groups them by account, lets you investigate, assign and email the people concerned, and maps which indexes are read, by whom, and what the unread data costs.
about 48 minutes · 48 slides. Each slide is followed by a description of what it shows — read top to bottom, this page is the walkthrough.
Overview¶
User Activity Monitoring (UAM) is a dedicated tenant type of TrackMe, generally available since 2.4.19. One tenant watches every account of a deployment: their searches, their cost and the knowledge objects they own. It raises findings from a policy catalogue, groups them by account, and lets operators talk to the people concerned.
Everything shown here was captured live on TrackMe 2.4.21 and 2.4.22: on a tenant watching two search head tiers of one indexing layer, on a second lab tenant for the screens that need a longer history, and on a Splunk Cloud tenant with seven thousand accounts. The accounts that appear, alice.moreau, jane.doe, ben.okafor, svc-siem and others, are fictitious names of a small platform team. Five parts follow: setup, reading and grouping, communicating, tuning and operating, and Data usage.
The other half of the platform¶
Data monitoring sees the feeds. A Splunk platform is also hundreds of saved searches and knowledge objects, dozens of accounts and the automation behind them, and their behaviour has no owner. Three cards name the symptoms: searches nobody reviews, knowledge objects that grow (a CSV lookup rewritten every hour until it weighs hundreds of MiB) and cost without a name (one account taking a large share of the search CPU).
UAM reads the audit trail and the introspection of one indexing layer, catalogues every search head tier through the REST API, classifies every account as system, human or service, and evaluates sixteen built-in policies, who holds high privileges included, plus custom policies. It never edits, disables or dispatches what it observes.
From sources to Finding groups¶
Five stages make the model. Sources: the audit trail, the introspection, and the REST API of every search head tier. Reports: catalogs per tier, three indexing-layer trackers (Audit activity, Resource usage, Account signals), policies every fifteen minutes and a bounded backfill. Evidence: compact trackme:uam:* records in the tenant indexes. Classes: system, human or service. Finding groups: the sixteen built-in and the custom policies raise findings, and an account with its saved searches forms one Finding group.
On top of the findings sit the triage, assignment, notifications, emails to the account concerned, findings actions and the UAM AI Agent. An account is the one Splunk reports in its audit trail, not a verified person, and collection never drops data: what a run cannot do carries over.
Five parts, one tenant¶
The walkthrough has five parts. Setup creates the tenant from the User Activity Monitoring card, with two search head tiers, the route account and a 30-day backfill, then checks the collection health. Read and group covers the findings and Finding groups, the investigation, the accounts with their classes and owner catalogs, and the privileged users.
Communicate covers the menus, the email communication and the notifications. Tune and operate covers the policy catalogue, a custom policy in SPL, the UAM AI Agent and the scheduled searches. Data usage shows where the data goes, value and cost, an index in depth, the knowledge objects and an account’s data accesses. Every screen is the product as shipped.
Part 1 — Setup¶
The first part creates the tenant and follows its first collection: the User Activity Monitoring card, the search head tiers and the route account, the historical backfill, then the tenant card, the status strip and the collection health on day one.
The wizard has four steps. Within minutes of the creation the catalogs of every tier are published and the first activity records arrive, and Collection health shows every report at work.
Choosing the tenant type¶
Virtual Tenants, Actions, Create a tracking tenant opens the chooser. The User Activity Monitoring card is the first of the dedicated workspaces, after the Splunk data monitoring components; What it does sums up its scope: the accounts, searches, cost and knowledge objects of one indexing layer, with policy findings grouped by account. Select opens the UAM wizard: Basics, Configure UAM, Indexes & RBAC, Review.
A tenant is either an entity tenant or a UAM tenant, never both. A UAM tenant has no entities, no decision maker and no scoring: its object is the finding. It requires any licence beyond Foundation: Enterprise, Unlimited, trial or developer.
Tiers, route account and backfill¶
Configure UAM shapes the tenant. Search head tiers lists the local search head plus any TrackMe remote account as another tier of the same indexing layer, up to ten. Every remote tier is tested when selected (here prd5, reachable), and creation waits until each one answers. The route account is the tier through which the indexing-layer searches run (audit, introspection, capacity), once for the whole tenant.
The historical backfill collects none, 7, 14, 30, 60 or 90 days of audit and resource history before the live start; 30 days are chosen here, so that classification and the first findings are meaningful on day one. The optional activity scope restricts the collected search heads by host name patterns.
Status at a glance¶
On the Virtual Tenants page, the tenant card shows the open Finding groups and findings (10 groups, 36 findings), the high or critical ones, and the collection status, here the backfill at 16 %. Selecting the card opens the workspace; a double-click opens a read-only overview.
Inside the workspace, the status strip summarises the collection: the tiers with the route marked, the age of the inventory, Audit activity, Resource usage, Account signals and policies runs, the checkpoint lag and the coverage. Refresh and Collect now sit on the right; Collect now runs every report on demand.
Day one in Collection health¶
Collection health answers one question: is UAM collecting what it should, and if not, why and what to do. The Status view gives the verdict, here Collection is healthy: every tracker ran on schedule with full coverage, or names the trackers that need attention with their reasons. Flow and Check again sit beside it. The Configuration Guardian alert UAM collection health reads the same assessment, so the page and the alert never disagree.
Problems in the last 24 hours lists the failed or incomplete runs of each tracker, recovered or not, with their diagnostics and receipts. Every diagnostic opens its meaning, its source and what to do; a code that only describes a recovered run stays neutral. The other views are Trackers, Data & storage and Troubleshoot & help.
Every tracker in one table¶
The Trackers view lists every UAM report with its status, its live schedule read from Splunk, last run, last collected, duration and diagnostics, filtered by name, family or status. Per search head tier come the inventory, the full listing and one catalog per knowledge-object family, read from the REST API: users and roles every 15 minutes, the other families hourly, each published on its own so one slow family never blocks the others.
Once per tenant, through the route account, three trackers read the indexing layer: Audit activity and Resource usage every 5 minutes, Account signals every 15. Run now dispatches a tracker (List now for the full listing), and a row expands to its checkpoint, windows, scans or datasets and the exact searches of its last run.
The collection pipeline¶
Flow, opened from the Status view, draws how the tenant collects, stores and judges, left to right: the sources (each search head tier through its REST API, and the indexing layer through the route account), the collectors, the stores they write (the KV collections and the indexes) and the policies with the findings, Finding groups and finding events they produce.
Each node is coloured by the same assessment as the Status view: failing, needs attention, running now, healthy, not run yet or off. The list beside the canvas names where it fails; here nothing fails and every node is healthy. The view exports as a PNG.
Part 2 — Read and group¶
The second part is about reading what the tenant found: the Findings tab and its Finding groups, the investigation with its evidence and the triage of the group, then the accounts, their classes, their activity and the knowledge objects they own.
Findings about the same account and the saved searches it owns form one Finding group, decided on together.
The findings backlog¶
The Findings tab is the backlog. The tiles count Finding groups: here 9 open groups holding 12 findings, 7 of them high or critical, with the groups new in the range, assigned to the current user, resolved and dismissed. Finding transitions charts the reobserved, unobserved and updated findings over the last 24 hours.
By severity shows where the weight is across low, medium and high. By policy shows which policies raised what: accounts that ran all-time searches, scheduled searches owned by a human account and repeated resource-intensive searches. Below the charts come the filters and one row per Finding group.
One decision per account¶
All findings about the same account and the saved searches it owns automatically form one Finding group. Each row is a group, for example account: tom.hendricks with 4 findings; the group carries the status, the assignee and the severity, and expands to its members, each with its policy and its own evidence.
The condition column says whether the latest complete evaluation still observes the condition; a finding that is no longer observed stays listed until a person resolves it. The jane.doe group combines an all-time search no longer observed, a custom policy and the CSV lookup footprint. Selecting rows merges them into a manual group; an object’s findings always move together.
The investigation view¶
Investigate opens the whole case. The header names the Finding group, account: jane.doe with 3 findings, with its severity, status, observed count and assignee. Findings in this group lists each member with its severity and whether it is still observed; selecting one shows it below.
For the CSV lookup footprint finding, the subject section shows the account, its class (human, detected), its tier and environment, with Open account view. What happened gives the severity, the policy, the first and last seen times and the episodes. The suggested action is advisory: UAM never deletes a file nor changes the replication. Copy id, Open record in search, Open events in search and Ask the AI Agent complete the view.
Evidence and triage of the group¶
The CSV lookup footprint policy came with 2.4.19. The evidence totals 1,102.29 MiB of CSV lookups attributed to jane.doe against a 500 MiB allowance, with a largest file of 662.21 MiB against 100 MiB. Every attributed file is listed: the recorded owner is nobody, and the attribution is probable writer, the account that wrote the file according to the audit evidence. Writer attribution is an audit-based estimate, not proof of authorship; the recorded owner is the fallback.
Below the evidence, the triage applies to the whole Finding group: status, assignee, severity (Members means the highest of its findings) and notification snooze. A finding dismissed on its own keeps its decision.
Every account in one table¶
The Users tab is the account-centric view. The tiles count the accounts in range, the inventoried users, the classified accounts (human, service, system) and the unclassified ones. Each row shows the email address, collected from Splunk per tier or set by an administrator as a manual override; that address is where notifications to users and email communications are sent.
The class column shows human (detected from interactive activity), service (by rule or sustained automation) or system. Findings, audit records, executions, last seen and apps complete the row. Search knowledge objects opens a search over every catalogued object across owners and tiers.
Activity and cost of one account¶
The account view gathers everything about one account, here svc-siem, a service account, over the last 24 hours. The top shows its class, the activity range and the scope, then the tiles: 1,983 executions, 2,481 audit records, one open finding and 2h 11m of run time, with the executions over time by search type and the app it works in.
Further down, the resource usage tells what the account costs: 8m 56s of CPU time, 411 MB peak memory and 0.2% of the environment, with CPU over time and the most expensive searches ranked by CPU time. Searches the resource records could not measure are counted and shown, never estimated. Seven catalog tabs list what the account owns.
What an account owns¶
The seven catalog tabs of the account view (Saved searches & alerts, Dashboards, Macros, Event types, Fields, Lookups, Tags) answer the question every offboarding asks: what does this account own? A name or wildcard pattern and a search head tier narrow the list; here three objects are owned by alice.moreau, each with its app, sharing and tier.
Expanding a saved search shows its definition: schedule, dispatch window, alert settings and SPL. The data comes from the latest completed catalog collection, not from a live call, and private objects depend on the permissions of the collection account.
Finding objects across owners¶
Search knowledge objects runs one search across the catalogued objects of every tier and owner. The name *john* finds the two CSV lookup files behind jane.doe’s footprint finding; the object type, owner, app and search head tier narrow the 12,480 catalogued objects.
Each row shows the owner, app and sharing, here recorded owner nobody, app search, global sharing. For lookup files, the expanded row adds the size and the last modification: 662.21 MiB, modified at 18:21. The files are owned by nobody and were written by jane.doe, which is exactly the case the writer attribution resolves.
The raw audit evidence¶
The Activity tab is the raw evidence: one record per search and window rather than one line per audit event. The time range and scope sit on top; Exclude TrackMe activity leaves out the searches run in the trackme app. Evidence switches between the audit records and the executions correlated per search id, and the account and app filters narrow the view, here to alice.moreau.
The chart shows the records over time by account source, with history from the backfill. The table lists the 500 most recent records with search id, outcome, run time and evidence state; Inspect opens a record. This is the material every activity policy is evaluated on.
Account classification¶
Settings, Account classification decides who each policy looks at: activity policies judge human accounts by default, resource policies classified accounts. Detection classifies an account as human from interactive activity in Splunk Web and as service from sustained automation.
Automatic assignment rules are ordered exact or wildcard rules where the first match wins; the rule svc-* to Service classifies every service account that will ever be created. Preview classifications shows the effect on the known accounts before saving. Manual overrides take precedence over rules and detection, and Automatic removes one. Precedence is always manual class, Splunk system defaults, the first matching rule, then detection.
Who holds high privileges¶
The Privileged users tab reads the users and roles catalogs UAM already collects and makes no call to Splunk. The counters show 9 privileged accounts of 7,025, 17 privileged roles, 8 privileged capabilities in use and 6 privileged accounts active in the last 24 hours. Charts show why accounts are privileged (a role, a capability or both), their classes and the accounts holding each privileged capability.
An account is privileged when one of its roles, or a role that role imports however indirectly, is a privileged role or grants a privileged capability. The table lists every privileged account with its tiers, class, roles, capabilities and each reason in words, for example uam_gen_rtsearch grants list_settings.
Four policies on privileges¶
Four privileged policies build on that assessment, all off by default. Account became privileged reports once per change an account created privileged, given a privileged role, or holding a role that now inherits one, with who made the change when Splunk audited it. Role gained a privileged capability reports once, on the role whose own definition changed, the roles that inherit it and the accounts newly privileged.
Privileged account is dormant reports a privileged account with no search, no Splunk Web login and no reported login for 7 to 365 days, once the evidence covers the period. Privileged accounts differ from the reference compares the accounts with the declared privileged accounts, typed names and Splunk lookup tables: undeclared at high severity and, optionally, stale references at low severity.
One change, one finding¶
A role finding opened in Investigate. The role’s own capabilities changed: uam_gen_rtsearch gained list_settings, a privileged capability. The finding lists the roles that inherit the change and the accounts newly privileged through it, here alice.moreau, and the audit record of who made the change, the action, when, and the capabilities before and after.
Inheritance is transitive: one change reaches every role that inherits it, and the finding is about the role whose definition changed, its descendants listed rather than reported again. A role finding forms its own Finding group, and there is no account to email.
Part 3 — Communicate¶
The third part is about talking to the people behind the accounts. It covers the finding and Finding group menus, a reviewed email to the account a finding is about, notifications to users on new detections, and notifications to operators on the transitions of the findings.
A one-off communication is reviewed before it leaves; automatic notifications to users work independently of the operators’ notifications.
The finding and group menus¶
Two menus carry the decisions. The menu of a single finding offers Send email communication, Investigate, Notes, Dismiss only this finding (the group and its other findings stay as they are), Exclude owner from this policy (which adds the owner to the policy exclusions), Copy finding id, and Open record and events in search.
The Finding group menu offers Send email communication for every finding of the group, Investigate, Notes and Open account view, then the group decisions: mark investigating, resolve, dismiss, assign to me or to an assignment group. Snooze notifications pauses the emails without changing the status.
A reviewed email to the account¶
Send email communication prepares a private preview of one email for the account concerned. The recipient is resolved from the account override or the inventoried addresses and can be changed for this email only. From a Finding group, every finding is included, here three, a custom policy among them, under the subject [Splunk] 3 user activity findings.
The email carries the common banner and introduction, then each policy with its evidence in plain words, such as 1,102.29 MiB of CSV lookups against 500 MiB. Nothing leaves before Confirm and send email; the email is sent from a search process and never retried blindly. It changes neither the findings nor their notification lifecycle.
Automatic emails to account owners¶
Notifications to users email each account about its own findings at its inventoried address. Enable user notifications is off by default, and the first enable sets a baseline so that no backlog is sent. Events are New detection and Condition cleared; a closure needs two successful clear evaluations.
A delivery account (a TrackMe email account with its allowed-domain rules, or the local MTA) and a reply-to address send them. Address coverage shows 13 manual overrides; service, unclassified and system accounts are excluded by default. The common template holds the banner, introduction, footer and support link, while each policy has its own subject and body. Limits protect the mailboxes: at most 50 per run and 3 per user per hour.
Emails to the operators¶
Notifications to operators email the transitions of the findings, behind one switch for the tenant that is off by default. The events are new finding, reopened, severity raised and resolved, with dismissed and assigned optional. A minimum severity (medium by default) and a policy list (every policy by default) narrow them.
A delivery account sends them to up to 50 recipients, and Send test email checks the delivery. The mode is either a digest, one email per policies run, or one threaded email per finding transition. Emails link straight to the finding in its investigation.
Part 4 — Tune and operate¶
The fourth part covers tuning and operating: the built-in policy catalogue with its insight and email templates, a custom policy written in SPL, previewed and published, the UAM AI Agent, the scheduled searches and the collection health.
The catalogue ships with defaults that fit a busy platform; a rule that is not in it can be written as a custom policy.
The policy catalogue¶
The Policies tab lists the custom policies of the tenant first, then the sixteen built-in policies, seven of them on by default and the four privileged ones off, as cards, compact cards or a list. The families are inventory (schedules and CSV lookups), activity (audit records), resource (CPU and memory) and privileged (accounts and roles).
Each row shows the status and severity (Account ran all-time searches is high by default, personal schedules low), the settings in force (thresholds, automatic budgets from the measured capacity, the account scope), the last evaluation (complete, incomplete or learning) and the matched, unknown and excluded counters; Edit opens the policy. Resource policies learn for 24 hours before they judge anyone, and a policy never resolves a finding.
Explaining one evaluation¶
The policy insight opens from the Last evaluation pill. For Account ran all-time searches the verdict reads Complete: every applicable account was judged, 3 evaluated and 3 matched. The counters show evaluated, matched, unknown, excluded and not applicable.
What the run saw splits the population by outcome, and the last 7 days chart repeats the counters for every policies run since 6 October. Activity left out lists the excluded apps, here trackme, whose searches never count against the rule. Show this policy’s findings jumps to the findings the policy raised.
Policy email templates¶
The edit modal of a policy has four tabs: General settings, Email template, Actions and Automations. Email template holds the words sent to the account. Notify users for this policy is on for every built-in policy except the unclassified schedule.
Each email event (New detection or Condition cleared) has its own subject and body, in plain text with placeholders such as account, policy, search, app, environment, summary, action and window. Restore policy default reverts the text, and Preview email renders it with sample data under the common banner and introduction; a test recipient receives a synthetic test email.
Writing a custom policy¶
When the catalogue lacks a rule, a custom policy adds it: an SPL search plus a mapping of its results to findings. This one, Account searched every index, flags accounts that searched index=* in the last 24 hours. The remediation text is shown with every finding. The search source is the route for account policies, while saved-search policies may use any tier, and the app context resolves the macros and lookups of the search.
Below the SPL, the policy defines its window, a cron, and the mapping of the results to findings: subject type (account or saved search), identity, dimensions, evidence, count and time fields. A tenant holds up to 100 definitions and 25 enabled policies.
Preview, publish and enable¶
Preview runs the search as the author, asynchronously, and publishes nothing. The execution result reads healthy, complete evaluation, 6 rows and 6 candidate findings. Each candidate is a card with its subject, dimensions, severity, occurrences and first and last event; the evidence is a bounded sample, not the full search result.
Publish freezes an immutable revision, and Enable installs its scheduled report; every saved draft stays in the version history. Once enabled, the findings of the custom policy appear in the Findings tab and join the Finding groups of the accounts concerned, next to the built-in policies.
Assessments and the decision log¶
Ask the AI Agent on a finding reads the evidence of the Finding group and returns an assessment, here a true positive of medium severity with its evidence and reasoning trace, and recommends a decision, Mark investigating. In inspect mode nothing changes until Run its recommendations is selected.
The AI Agent tab logs every review, asked or scheduled, with its mode, decision, outcome and rationale. Scheduled triage runs hourly and is off by default, critical and high findings first; in act mode it applies only the decisions the tenant allows and never overrides an operator decision.
The scheduled-search inventory¶
The Scheduled searches tab lists every schedule of every tier with its owner, owner class, schedule and enablement; a name opens the saved search view. Here, a detection search of the svc-siem service account is enabled, scheduled on the local tier and shared globally.
Over the last 24 hours it ran 291 times for 7m 13s of CPU, with a longest run of 2m 33s and a peak memory of 411 MB. The definition from the inventory shows a cron of */5 and a dispatch earliest of -1h. Fetch definition reads the saved search live from its search head with the caller’s permissions; nothing is stored.
Backfill and recovery¶
The backfill shows the configured range in 5-minute buckets collected newest first, with what is covered and the estimated time for the rest. The retention edges show where the audit and resource history end because the sources’ retention ends there, and the counters show the audit records and resource records written so far.
Pause and Cancel backfill control the run; a stopped run is recovered after five minutes on the same member, or on demand. The backfill never collects a span twice, and a bucket that fails is held, split and resumed, never skipped; it retires itself once the range is covered. The Configuration Guardian check uam_collection_health surfaces whatever stays wrong and clears itself.
Part 5 — Data usage¶
Data usage, new in TrackMe 2.4.22, resolves every audited search to the indexes it names, through its macros, event types, saved searches and data models, and weighs that against what each index ingests and costs, read from linked VOL and DSM tenants.
One rule runs through every view: an absence of reads is a claim, made only when the evidence supports it. The part covers where the data goes, value and cost, an index in depth, knowledge objects declared against observed, and an account’s data accesses.
From ingestion to readers¶
The Overview opens on one sentence: of 6.60 GB per day ingested, 1.73 GB is read by name, 1.52 GB only through wildcards and none by no one so far, since the collection is a day old. The flow runs from data families, indexes sharing a name prefix, to their usage and then to the accounts that read them; widths are average daily volume.
The usage classes (Read by name, Wildcard only, No reader, Excluded apps only, TrackMe’s own) are decided across the whole indexing layer, never per tier. A wildcard such as index=cribl_* is a reference, not a read. The Flow and Treemap switch shows the same volume as tiles sized by daily volume.
Weighing volume against reads¶
Value & cost opens with the coverage card: the collection start and the date from which an index can be called unread. Ingestion by usage shows the daily volume as a treemap coloured by usage class. Volume against reads places one dot per index on log scales, with a shaded corner for the indexes larger than the median and read fewer than ten times.
Cost of disuse prices what is not read by name: here 1.52 GB per day, 1.29 USD per day, reached only by wildcards. The cost comes from the linked VOL tenant’s costs when they are enabled; otherwise no cost is shown rather than a guessed one.
From the map to decisions¶
The Decisions list gives one row per index, largest first, with its daily volume and cost, usage, readers, reads per GB, the knowledge objects that declare it and a suggested step, such as confirming that wildcard searches need the data or scoping them by name.
To review gathers the indexes with no reader, those only wildcards or excluded apps reach, and the least accessed: the quarter of the indexes read by name that are read the least for their volume, ranked only when at least four such indexes exist. An empty list says why, and every index name opens its detail.
One index, its readers and paths¶
The webserver detail opens on Source references: 78 source reads, 16 indirect references, 4 sourcetypes reported, 1.73 GB per day at 1.47 USD, 58 searches the indexers received and 11 knowledge objects that declare it. One row per account, app, sourcetype and path shows who read it and how: by literal term, through a macro or through a data model, with Fetch SPL examples on demand.
Sourcetypes are reported on a best-effort basis and never receive a verdict. On a distributed deployment, the indexers’ record of the expanded search sits beside the search head’s figures, never added to them. The Access timeline tab charts the named reads in clock-aligned buckets.
Declarations checked against runs¶
The Knowledge objects view sets each published saved search, macro, event type, dashboard and data model against what ran. Tiles count the states: 45 in use, 98 not run, 2 not due in this period, 12 disabled, building blocks used or not seen, and dashboards viewed or not.
Each object lists the indexes its definition declares, wildcards expanded across the index catalog, next to the indexes its searches read; an undeclared read is outlined. Not run is dated from when saved search runs began to be recorded, and a schedule with a longer gap than the period is not due, never not run.
An account’s indexes over time¶
The account view of lea.fontaine has a Data accesses tab: the named reads of the account per index over the period, then one lane per index with a marker for each group of nearby observations. Markers are not search durations. Selecting one shows the app, the usage origin and the read and write claims; opened from an index, the same lanes show who used it.
Every Data usage view reads through the caller’s own Splunk search jobs, followed by the UI and cancelled when the selection changes or the view closes. There is no time budget: a long period takes longer and is complete when it is shown.
Evidence and supply links¶
Evidence shows what supports the figures: one coverage card with the collection start and any fault with its cause, the indexed fact records, the collection runs and their outcome, the index catalog of every tier, and the searches whose indexes could not be resolved, each with its reason and the steps to fix it.
In Settings, Data usage links each search head tier to the VOL tenant that gives its volumes and to the DSM tenants that give its incoming data, matched automatically on the same route. It also sets the excluded apps and the resolution limits. A link grants no access: every read repeats the caller’s visibility.
Where we are¶
In five parts, a tenant was created over two search head tiers with a 30-day backfill and catalogs of every knowledge object per tier. Its findings were grouped by account into Finding groups and investigated, with the CSV lookup footprint evidence, and the accounts holding high privileges were reviewed with their policies. A reviewed email went to the account concerned, next to the notifications to users and to operators. A custom policy was written in SPL, previewed, published and enabled, and the AI Agent gave an assessment on demand. Data usage mapped which indexes are read, by whom and through which path, against what each index ingests and costs.
Three things make it work: one decision per account through Finding groups, rules beyond the built-in catalogue through custom policies, and plain-language communication with the people behind the accounts.