TrackMe App on SOAR — in depth

Tip

This is the in-depth reference for the TrackMe App on Splunk SOAR. For the readable overview, start with TrackMe App on SOAR. This page covers compatibility, installation, the asset configuration, the action catalogue, and event ingestion — the recommended way to bring TrackMe alerts into SOAR.

About TrackMe App on SOAR

• TrackMe App on SOAR is an application for Splunk SOAR that allows you to automate tasks and interact with TrackMe transparently from your SOAR environments.

• With the TrackMe App on SOAR, you can automate various actions in TrackMe, such as retrieving TrackMe entities’ realtime statuses, updating their key behavior parameters, or interacting with TrackMe features such as the Machine Learning capabilities and the AI advisors.

• The app also ingests TrackMe alert events into SOAR natively, so a playbook can react to a TrackMe alert and call straight back into TrackMe to act on it.

• Working in collaboration with TrackMe, SOAR users can leverage the TrackMe App on SOAR to extend and enrich the workflow and fulfill any kind of sophisticated requirements.

Compatibility and requirements

Requirement	Details
Splunk SOAR	7.0.0 or later (the minimum product version declared by the app)
Python	3.13 (the app also declares 3.14 compatibility)
TrackMe	A TrackMe deployment reachable over the Splunkd management API, normally on port 8089
Authentication	A Splunk bearer token for a TrackMe service account — see The service account and its RBAC
Ingestion (optional)	The service account must additionally be allowed to run searches and to read the indexes holding TrackMe’s alert events

Warning

Splunk SOAR releases from early 2026 require apps to be Python 3.13 compatible; apps that have not been updated fail to execute. Version 2.0.0 of the TrackMe App on SOAR is the Python 3.13 release and therefore requires SOAR 7.0.0+. If you are running an older SOAR release, remain on the 1.x app until you can upgrade the platform.

Installation

Download the application package from:

• our release website: https://downloads.trackme-solutions.com/trackme-app-on-soar

• our GitHub repository: https://github.com/trackme-limited/trackme-app-on-soar

• Splunkbase, where the app is published as TrackMe for Splunk SOAR

Important

Availability of version 2.0.0 on Splunkbase

Version 2.0.0 is submitted to Splunk for publication on Splunkbase. Updates to the Splunk SOAR connectors are reviewed and published by Splunk, and that process can take a while — so the version offered on Splunkbase may still be 1.x for some time.

In the meantime, download version 2.0.0 directly from our release website:

• https://downloads.trackme-solutions.com/trackme-app-on-soar/trackme_200/

The package (trackme_200.tgz) is the same one submitted to Splunk, and installs exactly the same way. The directory also publishes the release notes and a release-sha256.txt you can use to verify the download:

shasum -a 256 trackme_200.tgz

Install it from the SOAR UI with Apps > Install App, then confirm the app reports the expected version and Python runtime:

The application ships with its own built-in documentation, which is available directly in SOAR once installed and is the authoritative reference for the current action catalogue:

Note

The action catalogue evolves with the app version. The in-SOAR documentation and the README always describe the version you actually have installed.

The service account and its RBAC

The asset authenticates to TrackMe with a Splunk bearer token, which belongs to a Splunk user — the service account. Everything the app can do is bounded by what that account is allowed to do: what the service account can do in TrackMe is what your playbooks can do.

There are two ways to entitle it.

Option 1 — a Splunk admin account

A member of the Splunk admin role holds every capability, including all TrackMe capabilities, and has access to every application namespace and index. Every action works immediately, and there is nothing to configure.

Warning

This is not recommended. It grants the SOAR asset far more than it needs — well beyond TrackMe — and it conflicts with TrackMe’s own least-privilege model. It is acceptable for a quick evaluation on a lab instance; use a scoped service account for anything that matters.

Option 2 — a dedicated service account (recommended)

Create a dedicated Splunk user for the SOAR asset and grant it a custom role carrying exactly what the app needs. Four things must line up — miss any one of them and actions fail with 403, or ingestion silently returns nothing:

1. The TrackMe capability

Grant the capability matching the tier of the actions your playbooks run. The tiers are cumulative, and a higher role inherits the lower ones:

Capability	Built-in role	Needed for
trackmeuseroperations	trackme_user	Read-only actions: entity status and realtime data, get acknowledgements, list maintenance, tenant and scheduler status, get outliers models
trackmepoweroperations	trackme_power	Managing entities: acknowledge, toggle monitoring, priority and SLA, reset, delete, maintenance windows, notes and labels, outliers operations
trackmeadminoperations	trackme_admin	Administration: enable / disable tenants, run trackers, and other tenant-level operations

Most SOAR use cases are remediation-oriented, so trackmepoweroperations is the usual answer. Grant the admin tier only if your playbooks genuinely drive tenant-level operations.

2. The tenant’s RBAC lists

The capability alone is not enough. TrackMe additionally filters by tenant scope: a request only sees the tenants whose configured role lists intersect the caller’s Splunk roles. Your custom role must therefore be listed in the admin / power / user role lists of each tenant the SOAR asset is expected to reach.

Important

This is the step most often missed. If Test Connectivity succeeds but actions return nothing — or a tenant appears not to exist — the capability is present but the custom role is not listed in that tenant’s RBAC configuration.

3. Access to the TrackMe application namespace

The app calls the TrackMe REST endpoints, which are served from the TrackMe application namespace. The service account’s role must be able to reach the trackme app.

4. Access to the indexes (ingestion only)

Ingestion reads TrackMe’s alert events from Splunk, so the service account additionally needs to be allowed to run searches and to read the indexes holding those events:

Event type	Default index	Sourcetype
notable	trackme_notable	trackme:notable
stateful	trackme_summary	trackme:stateful_alerts

Add these to the role’s allowed indexes, and include them in the role’s default indexes searched if you want the searches to work without an explicit index scope.

Note

The app’s ingestion searches the default index names shown above. If a tenant writes its notable events to a custom index, those events are not ingested — align the tenant on the default notable index if you intend to ingest it. This applies to ingestion only; the action catalogue goes through the REST API and is unaffected.

Warning

The inheritance pitfall. If your custom role inherits a built-in TrackMe role rather than holding the capability natively, and that built-in role is still listed in a tenant’s RBAC, the service account gains access to every tenant left at default — the opposite of what a scoped service account is for. Either make the TrackMe capability native to the custom role, or remove the built-in roles from each tenant’s RBAC. See Roles & access control.

See also

• Roles & access control — the roles, capabilities and tenant-scope model.

• Roles & access control — in depth — the full capability matrix and a worked per-team example.

• Service account and permissions — the configuration details.

Configuring a TrackMe asset

Create the asset with Configure New Asset, then complete the Asset Settings:

Setting	Description
Splunk API URL	The Splunkd management URL of your TrackMe deployment, for example https://mysplunk.mydomain.com:8089
Splunk bearer token	The bearer token of the TrackMe service account (stored as a sensitive value)
Verify Splunk API SSL certificate	Whether to verify the Splunkd SSL certificate. Disabled by default; enable it when Splunkd presents a certificate trusted by SOAR
Per-request timeout	Timeout in seconds applied to each TrackMe REST call (default 300)

Validating connectivity

Use Test Connectivity to validate the URL, the token and the network path before running any other action:

Hint

If Test Connectivity fails, the message distinguishes the two common causes: an authentication or capability problem (the token is invalid, or the service account lacks the TrackMe capability — see The service account and its RBAC) versus a transport problem (the URL, the port, or the certificate).

Actions overview

Each action maps to a TrackMe REST API endpoint. The app exposes actions across the following areas:

• Acknowledgements — get and manage acknowledgements.

• Maintenance — global maintenance mode, and per-entity maintenance windows (set, clear, list).

• Entities — realtime data and full status, toggle monitoring, update priority and SLA class, reset, delete, manage data sampling, set false positive, manual score influence, notes and labels.

• Machine Learning Outliers — get, train, monitor and reset models, exclusion periods, false positives, and bulk actions.

• Logical groups — get associations, manage groups, update members.

• Tenants and operations — enable and disable tenants, run trackers, components and scheduler status, alerts, blocklist, disruption tuning.

• AI advisors and routines — asynchronous AI component-health advisors and on-demand AI routines.

Note

Several action names use the original snake_case form (ack_get, component_manage_entity, and so on). These are the names the app has always shipped, and they are preserved deliberately so that existing playbooks keep working across upgrades — Splunk SOAR resolves phantom.act() on the action name.

Ingesting TrackMe alert events into SOAR

The recommended way to bring TrackMe alerts into SOAR is the app’s built-in ingestion. The app polls TrackMe on a schedule and creates a SOAR container per alert event — no forwarding rule, no report, and no field mapping to maintain.

Why ingestion replaces the previous forwarding approach

Earlier versions of this documentation described pushing TrackMe Notable Events into SOAR with the Splunk App for SOAR Export: a globally shared report, an Event Forwarding Rule, a manually maintained field mapping, and a subsearch to avoid duplicates. That approach is superseded. Native ingestion is:

• Built into the app — one asset to configure, nothing to deploy or maintain on the Splunk side, and no dependency on the Splunk App for SOAR Export.

• Complete — every field of the TrackMe event reaches the artifact, so there is no field mapping to curate and no fields silently missing when TrackMe adds them.

• Safe by design — de-duplication is guaranteed on the event’s own event_id, rather than relying on a subsearch against previously forwarded artifacts.

• Broader — both notable and stateful alert events are supported, where the forwarding recipe only covered notables.

If you already run the forwarding rule, see Migrating from the SOAR Export forwarding rule below.

What gets ingested

TrackMe produces two families of alert events, and the app can ingest either or both:

Event type	Description
notable	TrackMe Notable Events — the notable-style alert surface.
stateful	TrackMe Stateful Alerts — the opened / ongoing / closed alerting path.

Every event carries a unique event_id. The app maps it to the container’s source_data_identifier, so SOAR de-duplicates natively: a repeated event never creates a duplicate container, which is what makes overlapping poll windows safe.

Ingest settings

Configure ingestion in the asset’s Ingest Settings:

Setting	Description
ingest_event_type	Which events to ingest: notable, stateful, or both (default)
ingest_tenant	Optional comma-separated list of tenant identifiers, to restrict ingestion to specific TrackMe tenants. Leave empty to ingest all tenants
ingest_lookback	The Splunk earliest-time window searched on every poll (default -30m)
ingest_max_events	Maximum total number of events ingested per poll, across all selected event types (0 for no limit, default 1000)

In the standard SOAR Ingest Settings, set the label that ingested containers receive, and enable Polling with a Polling interval in minutes.

Recommended polling configuration

Important

Poll every 5 minutes and leave ingest_lookback at the default -30m.

Every poll searches the full ingest_lookback window rather than a narrow since-last-poll window. This is a deliberate trade of load for reliability: because event_id de-duplication is guaranteed, a repeated event never creates a duplicate container, so overlapping the window makes it far less likely that a late-arriving or briefly missed event is dropped. A 30-minute window polled every 5 minutes gives each event several opportunities to be picked up.

It is not free — each poll re-runs the whole lookback search and the connector re-processes rows it has already seen, so a wider window or a shorter interval costs more Splunk search and connector work. Size it for your environment:

• if your events arrive late, widen ingest_lookback rather than lengthening the poll interval;

• ingest_max_events caps how many events a single poll ingests, so a poll that reaches the cap will not reach every event in the window — raise it (or set it to 0) in high-volume environments, and size it for the volume a wider window returns.

Results in SOAR

Ingested events appear as containers under the label you configured:

Each container carries one artifact holding the complete TrackMe event, so playbooks can read any field without a mapping step — including tenant_id, object, object_state, priority, anomaly_reason, status_message, drilldown_link and the TrackMe identifiers:

Stateful alerts carry an alert_status. When TrackMe closes the alert, the corresponding container is created with a closed status, so the SOAR view reflects the TrackMe lifecycle:

Container severity is derived from the event: the entity state drives it where present (red maps to high, orange to medium, green and yellow to low), falling back to the event priority otherwise.

Hint

Use Poll Now on the asset to validate ingestion immediately, without waiting for the scheduled poll. If no container appears, check that the asset’s ingest label exists, and that the service account may run searches and read the alert indexes — see The service account and its RBAC.

Migrating from the SOAR Export forwarding rule

If you currently forward TrackMe Notable Events with the Splunk App for SOAR Export:

1. Configure Ingest Settings on the TrackMe asset and enable polling, as described above.

2. Use a different label from the forwarding rule, so the two paths remain distinguishable while you compare them.

3. Once you are satisfied that the ingested containers carry everything your playbooks need, disable the Event Forwarding Rule and repoint your playbooks at the new label.

4. The Splunk report and the field mapping that fed the rule can then be retired.

Note

The two paths de-duplicate independently: the forwarding rule and the app’s ingestion do not share state, so running both at once creates one container per path for the same TrackMe event. Run them in parallel only for as long as you need to compare them.

Usage example

Beyond ingestion, the app’s actions let a playbook act back on TrackMe. A common pattern is to react to an ingested TrackMe alert and update the entity’s acknowledgement status, place it under a maintenance window, or trigger an AI component-health advisor — all from the container the ingestion created.

See also

• TrackMe App on SOAR — the readable overview.

• Splunk SOAR — monitoring the health of a Splunk SOAR deployment with TrackMe.

• Notable events — the TrackMe Notable Events ingested by the app.

• Stateful alerting — the TrackMe Stateful Alerts ingested by the app.

• Operations & Administration — the TrackMe REST API the app calls.

• Roles & access control — the access the SOAR asset authenticates with.