Splunk Dashboard Studio

Splunk Dashboard Studio

Build production-quality dashboards using Dashboard Studio's JSON-based dashboard definitions. This skill covers the full definition schema, all visualization types, interactivity patterns, dynamic formatting, and design best practices.

Prerequisites

• Splunk MCP server connected for running queries and deploying dashboards
• For the existing Simple XML dashboard builder skill, see the splunk-dashboard-builder subagent type

Dashboard Definition Structure

Every Dashboard Studio dashboard is a single JSON object with these sections:

{
  "title": "Dashboard Title",
  "description": "Dashboard description",
  "inputs": {},
  "defaults": {},
  "visualizations": {},
  "dataSources": {},
  "layout": {},
  "expressions": {},
  "applicationProperties": {}
}

Workflow

When a user requests a Dashboard Studio dashboard:

Task Progress:
- [ ] Step 1: Understand the requirements (data, audience, purpose)
- [ ] Step 2: Design data architecture (searches, chains, tokens)
- [ ] Step 3: Select visualization types for each data element
- [ ] Step 4: Build the dashboard definition JSON
- [ ] Step 5: Add interactivity (inputs, tokens, drilldowns)
- [ ] Step 6: Apply dynamic formatting (DOS, conditional colors)
- [ ] Step 7: Deploy and validate

Step 1: Requirements Gathering

Ask or infer:

• What data/indexes are involved?
• Who is the audience? (SOC analyst, executive, engineer)
• What decisions should the dashboard support?
• Interactive or static? Grid or pixel-perfect absolute layout?

Step 2: Data Architecture

Design efficient SPL with base + chain searches:

"dataSources": {
  "ds_base": {
    "type": "ds.search",
    "options": {
      "query": "index=main sourcetype=access_combined | stats count by status, method, uri_path",
      "queryParameters": {
        "earliest": "$global_time.earliest$",
        "latest": "$global_time.latest$"
      }
    },
    "name": "Base Search"
  },
  "ds_by_status": {
    "type": "ds.chain",
    "options": {
      "query": "| stats sum(count) as total by status",
      "extend": "ds_base"
    },
    "name": "By Status"
  },
  "ds_by_method": {
    "type": "ds.chain",
    "options": {
      "query": "| stats sum(count) as total by method",
      "extend": "ds_base"
    },
    "name": "By Method"
  }
}

Data source types:

Step 3: Visualization Selection

Choose the right visualization for each data element. See viz-reference.md for the complete catalog with options.

Decision guide:

Step 4: Build the Definition

Visualization stanza pattern:

"viz_uniqueId": {
  "type": "splunk.column",
  "title": "Requests by Method",
  "description": "HTTP method distribution",
  "dataSources": {
    "primary": "ds_by_method"
  },
  "options": {
    "seriesColors": ["#7B56DB", "#009CEB", "#00CDAF"],
    "legendDisplay": "right",
    "stackMode": "stacked"
  },
  "containerOptions": {
    "title": { "color": "#FFFFFF" },
    "description": { "color": "#999A9C" }
  }
}

Layout: Grid vs Absolute

Grid layout:

"layout": {
  "globalInputs": ["input_time"],
  "tabs": {
    "items": [{ "layoutId": "layout_1", "label": "Overview" }]
  },
  "layoutDefinitions": {
    "layout_1": {
      "type": "grid",
      "options": { "width": 1440 },
      "structure": [
        { "item": "viz_sv1", "type": "block", "position": { "x": 0, "y": 0, "w": 300, "h": 150 } },
        { "item": "viz_sv2", "type": "block", "position": { "x": 300, "y": 0, "w": 300, "h": 150 } },
        { "item": "viz_chart", "type": "block", "position": { "x": 0, "y": 150, "w": 600, "h": 400 } }
      ]
    }
  }
}

Absolute layout adds: "display": "auto-scale", "backgroundColor", "backgroundImage", and "height" options.

Step 5: Interactivity

Inputs create tokens. Available types:

Input definition pattern:

"inputs": {
  "input_time": {
    "type": "input.timerange",
    "title": "Time Range",
    "options": {
      "token": "global_time",
      "defaultValue": "-24h@h,now"
    }
  },
  "input_host": {
    "type": "input.dropdown",
    "title": "Host",
    "options": {
      "token": "selected_host",
      "defaultValue": "*",
      "items": [
        { "label": "All Hosts", "value": "*" }
      ]
    },
    "dataSources": { "primary": "ds_hosts" }
  }
}

Token filters for safe interpolation in SPL:

Event handlers for drilldown:

"eventHandlers": [
  {
    "type": "drilldown.setToken",
    "options": {
      "tokens": [
        { "token": "selected_method", "key": "row.method.value" }
      ]
    }
  }
]

Other handler types: drilldown.linkToDashboard, drilldown.linkToUrl, drilldown.linkToSearch.

Default token values prevent empty panels on load:

"defaults": {
  "tokens": {
    "default": {
      "selected_method": { "value": "GET" }
    }
  }
}

Step 6: Dynamic Options Syntax (DOS)

DOS enables conditional formatting using the pattern:

"> [data source] | [selector] | [formatting function]"

Key formatting functions:

rangeValue example (single value delta coloring):

"options": {
  "deltaColor": "> deltaValue | rangeValue(deltaColorConfig)"
},
"context": {
  "deltaColorConfig": [
    { "from": 0, "value": "#1a9035" },
    { "to": 0, "value": "#dc4e41" }
  ]
}

Table column formatting with matchValue:

"options": {
  "columnFormat": {
    "severity": {
      "rowBackgroundColors": "> table | seriesByName(\"severity\") | matchValue(sevConfig)"
    }
  }
},
"context": {
  "sevConfig": [
    { "match": "critical", "value": "#DC4E41" },
    { "match": "high", "value": "#F8BE34" },
    { "match": "medium", "value": "#F1813F" },
    { "match": "low", "value": "#53A051" },
    { "match": "info", "value": "#0076D3" }
  ]
}

See viz-reference.md for the full DOS function catalog.

Step 7: Build the Dashboard

Once you have gathered requirements (steps 1-3) and made design decisions, construct the dashboard.

If a dashboard-studio-builder subagent is configured in .claude/agents/ or ~/.claude/agents/, delegate the build to it with the Agent tool. Otherwise build the JSON inline using the schema and patterns in this skill — the subagent is an optional accelerator, not a requirement. Either way, pass or work from this build spec:

Build Spec:
- Title: <dashboard title>
- Description: <dashboard description>
- Audience: <SOC analyst | executive | engineer | etc.>
- Layout: <grid | absolute>
- Data sources:
  - Index: <index name(s)>
  - Sourcetype: <sourcetype(s)>
  - Key fields: <field1, field2, ...>
  - Time range default: <-24h, -7d, etc.>
- Visualizations needed:
  - <description of viz 1 + type if known>
  - <description of viz 2 + type if known>
  - ...
- Interactivity:
  - Inputs: <time range, dropdown filters, text search, etc.>
  - Drilldowns: <click-to-filter, link-to-dashboard, link-to-URL, etc.>
  - Conditional panels: <show/hide behavior>
- Formatting:
  - Severity coloring: <yes/no + field names>
  - Number formatting: <currency, percentage, units>
  - Table column formatting: <gradient, range colors, etc.>
- Deployment: <deploy via MCP | output JSON only>
- Special requirements: <any additional context>

The subagent handles data discovery via Splunk MCP, JSON assembly, deployment, and validation. It returns the complete dashboard definition and a summary.

If the subagent is not available, or you prefer to build the JSON directly, follow the schema and patterns documented in this skill and the reference files. This path is fully supported.

Expressions for Conditional Visibility

Show or hide panels based on conditions:

"visualizations": {
  "viz_detail": {
    "containerOptions": {
      "visibility": {
        "showConditions": ["cond_has_selection"]
      }
    },
    "type": "splunk.table",
    "dataSources": { "primary": "ds_detail" }
  }
},
"expressions": {
  "conditions": {
    "cond_has_selection": {
      "name": "Has selection",
      "value": "$selected_host$ != \"*\""
    }
  }
}

Application Properties

"applicationProperties": {
  "hideExport": false,
  "hideViewModeActionMenu": false,
  "hideEdit": false,
  "hideOpenInSearch": false,
  "collapseNavigation": false
}

Design Best Practices

1. Information hierarchy: Single values at top for KPIs, charts in middle for trends, tables at bottom for detail
2. Color discipline: Use Splunk's default palette. Reserve red for critical, green for healthy. Limit to 5-7 colors per chart.
3. Grid layout first: Use grid unless you need pixel-perfect placement or background images
4. Chain searches aggressively: One base search with multiple chains beats N independent searches
5. Default token values: Always set defaults so dashboards render meaningfully on first load
6. Title every panel: Every visualization should have a clear, descriptive title
7. Progressive disclosure: Use tabs for multi-topic dashboards, conditional visibility for detail panels
8. Standard canvas width: 1440px for absolute, 1200px for grid
9. Consistent spacing: Use multiples of 8px for gutters and margins

Builder Subagent (Optional)

If you maintain a dashboard-studio-builder subagent (~/.claude/agents/dashboard-studio-builder.md, or .claude/agents/ for project scope), invoke it with the Agent tool to handle the full build lifecycle:

1. Data discovery via Splunk MCP (indexes, sourcetypes, fields)
2. JSON definition assembly with all sections
3. Deployment to Splunk via MCP (if available)
4. Structural validation (viz-to-layout, datasource refs, token consistency)

Invoke it with the build spec template from Step 7 above. The subagent has the complete Splunk UI Design System standards baked in -- color palette, accessibility rules, and information hierarchy patterns.

This subagent is not distributed with this skill. Without it, follow the Design Best Practices above and build inline.

Additional Resources

• Complete visualization type catalog and options: viz-reference.md
• Full dashboard definition examples: examples.md
• Splunk docs: https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/dashboard-studio/
• Splunk UI Design System: https://splunkui.splunk.com/DesignSystem/Overview