Creating a tenant¶

Tenants are created from a guided wizard in the Virtual Tenants UI (and, for automation, through the REST API). The wizard adapts to the component type you choose, but every path ends with the same access-control step.

Important

The Splunk indexes a tenant uses (summary, audit, metric, notable) must already exist before you create the tenant. The wizard references them; it does not create them.

Identity (all tenant types)¶

Every tenant begins with its identity:

Tenant identifier (tenant_id) — unique and immutable. Lowercase letters, digits, and underscores, up to 40 characters.
Tenant alias — optional human-readable display name (editable later).
Description — optional free text.

Creating a splk-feeds tenant¶

The feeds wizard is the richest, because it configures live discovery of your data. You choose which feeds components to enable — DSM, DHM, MHM — and, per component, set:

Create tracker now — optionally create a tracker during creation (this produces a Hybrid Tracker; you can also add trackers later from inside the tenant).
Splunk deployment — whether the data is local to this Splunk, or on a remote Splunk deployment (see Integrations & Remote Deployments).
Splunk root search constraint — the base constraint that governs which entities are discovered and maintained.
Restrict indexes discovery — narrow the scope further with explicit and wildcard index patterns.
Advanced options — Hybrid-tracker settings plus component-specific options.
Test now — run a preview search against your settings and confirm entities are found before committing.

Component nuances:

Component	What you configure
DSM	Tracks data feeds by `(index, sourcetype)`, with an optional custom break-by field. Produces KPIs, ML outliers, and data-quality signals.
DHM	Tracks sourcetype activity per endpoint. The endpoint defaults to the `host` metadata but can be any custom field.
MHM	Tracks metric-category availability per endpoint. The endpoint defaults to `host` but can be any metric dimension.

Creating a splk-wlk tenant¶

The Workload wizard walks through:

Deployment type — for example Splunk Cloud, which creates a tracker for SVC consumption summary metrics.
Deployment target — local or a remote account (searches switch transparently to the remote deployment).
Root search constraint — optional filters for the introspection, scheduler, and SVC searches (by app, or by host / splunk_server).
ML Outliers — auto-create and train ML models when entities are discovered (trains against the elapsed metric by default).
Inactive entities — auto-purge scheduled entities that have been inactive beyond a configured period; this is handled by the Workload tracker named inactive_entities.

Tip

Multiple search head tiers: restrict the root constraint so it targets only the intended members (for example host=sh1 OR host=sh2). The simplest, most robust pattern is one tenant per search head tier.

Creating splk-flx, splk-fqm, splk-cim tenants¶

These wizards are minimal — you provide the identity, description, and the access-control step. The actual entity configuration happens later, inside the tenant UI, once it exists.

Access control, ownership & indexes (all tenant types)¶

Every creation path finishes with the same step:

Roles (RBAC) — choose which Splunk roles administer the tenant (admin / power) and which have read-only access (user). See Roles & access control for the full model.
Owner — the Splunk user that owns the tenant’s knowledge objects and runs its trackers. Future objects are auto-assigned to this owner.
Indexes — select the (already-existing) Splunk indexes the tenant will use.

Tip

You can preset the default owner and roles that the creation UI proposes, under Configuration → General → RBAC, so every new tenant starts from sensible defaults.

What happens when you target a remote deployment¶

Choosing a remote target triggers an automatic connectivity and authentication test, and the result is shown before you can continue. Creation also checks that your license edition allows another tenant and that you are permitted to use the chosen remote account.

Automating with the REST API¶

Everything the wizard does is also available through the REST API — useful for scripting tenant creation or managing it as code. Browse the full endpoint list and options under API & Tooling → TrackMe REST API Reference in the UI. Tenants are created by posting to /services/trackme/v2/vtenants/admin/add_tenant; for example, a splk-dsm tenant:

| trackme url="/services/trackme/v2/vtenants/admin/add_tenant" mode="post"
    body="{'tenant_name': 'mytenant', 'tenant_desc': 'Demo tenant',
           'tenant_roles_admin': 'trackme_admin', 'tenant_roles_user': 'trackme_user',
           'tenant_owner': 'admin', 'tenant_idx_settings': 'global',
           'tenant_dsm_enabled': 'true'}"

The body carries the same choices as the wizard — identity, RBAC roles, owner, indexes — and a per-component enable flag: tenant_dsm_enabled / tenant_dhm_enabled / tenant_mhm_enabled for feeds, and tenant_flx_enabled / tenant_fqm_enabled / tenant_wlk_enabled for the other tenant types. Set the flag(s) for the component(s) you want; the minimal tenant types (flx, fqm, cim) need only the identity, RBAC, and that flag.