Build a Dashboard with Dynamic and Editable Inputs

Let's explore how to make a dashboard form with an input that is both autopopulated from a correlation search, but also editable on the fly when needed.

Scenario

Imagine you have a nifty new security dashboard in Splunk that provides a holistic view of the activity around an asset (no, I'm not talking about just recreating the Asset Investigator from Enterprise Security). On top of the dashboard are input fields for IP and Hostname. When suspicious activity occurs with an asset, a ticketing system directs Security Analysts to use this dashboard by providing a dynamic link with either the IP or Host inputs prepopulated.

Ideally, the dashboard would also correlate the asset's owner or user to show security-related usage data points. Unfortunately, sometimes your user correlation finds no match and your left with some ineffective panels. As a result, you'd like the user field to be editable so you can add in the user when you know it but the data doesn't.

The challenge is that the free-text input field is one of the few form fields that doesn't support Dynamic Options. Therefore, you assume you have to choose between using a dynamic input or a free text input, but not both. But you know what they say about assuming...

Approach A: Two Inputs, One Token

This approach is a little easier to implement but a little more awkward for users of the dashboard. Essentially, this approach takes advantage of the fact that there is no restriction on multiple inputs using the same token name. As a result, one input could dynamically load selection options and the other acts as a free text input. Worry not, because as long as you select "Search on Change" (searchWhenChanged="true" in the SimpleXml) then each input field with the same token value will stay synchronized as you make changes to its selected value.

That's pretty abstract so here's what that might look like should you want to give it a try:

Notice that the result is two input fields. One has dynamic options and the other is free text. Any change to one inflicts a change to the other.

Approach B: One Input, One Hidden Search

A more graceful approach for the end users (but more complicated to implement) is to have a free text input field that dynamically loads a value on page load but can also be edited for override.

To do this, you'll need to get familiar with what it means to "set" a token value. That's because there will need to be a hidden search that sets its result to a token that is used to define the free text input field's default value. The result is a free text field that is dynamically populated but also editable.

Notice that the free text input is the only input, but is prepopulated dynamically.

Putting It Together

Incorporating Approach B in our security dashboard means that our hidden search can try to correlate the ip or hostname back to the user. Any values found will populate the user free text field where we're free to edit the value. Alternatively, if no such match is found, we can manually enter a value since it's still a free-text field.

Now that's a Dynamic Dashboard!