Study guide
8.1 Workflow Action Architecture & Field/Event Context
Splunk Core Certified Power User Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
0.1 Exam Facts, Logistics & Test-Taking Strategy 0.2 Splunk Knowledge Objects & Search Pipeline Architecture
2 Chapter 1: Transforming Commands for Visualizations
1.1 The chart Command & Multi-Dimensional Aggregations 1.2 The timechart Command & Time-Series Visualizations 1.3 Transforming Options: limit, useother, usenull, and Split-By Clauses
3 Chapter 2: Filtering and Formatting Results
2.1 The eval Command & Core Evaluation Functions 2.2 Filtering Data: search vs. where Commands 2.3 Handling Missing Data with fillnull
4 Chapter 3: Correlating Events & Transactions
3.1 Understanding Transactions & Event Grouping Concepts 3.2 Configuring transaction Constraints: maxspan, maxpause, startswith, endswith 3.3 Analyzing Transaction Output Fields: duration & eventcount 3.4 transaction vs. stats: Performance & Architectural Trade-offs
5 Chapter 4: Creating and Managing Fields
4.1 Regular Expression Extractions with Field Extractor 4.2 Delimiter-Based Extractions with Field Extractor 4.3 Field Extraction Management, Permissions & Search-Time Precedence
6 Chapter 5: Field Aliases and Calculated Fields
5.1 Creating and Using Field Aliases 5.2 Creating and Configuring Calculated Fields 5.3 Aliases vs. Calculated Fields in the Search Execution Pipeline
7 Chapter 6: Tags and Event Types
6.1 Creating and Using Event Types 6.2 Creating and Managing Tags 6.3 Combining Tags and Event Types for Data Classification
8 Chapter 7: Creating and Using Search Macros
7.1 Creating Basic Search Macros & Backtick Syntax 7.2 Macro Arguments, Validation & Evaluation Functions 7.3 Macro Scoping, Permissions & Troubleshooting
9 Chapter 8: Creating and Using Workflow Actions
8.1 Workflow Action Architecture & Field/Event Context 8.2 Creating GET and POST Workflow Actions 8.3 Creating Search Workflow Actions & Dynamic Secondary Searches
10 Chapter 9: Data Models and Pivot
9.1 Data Model Architecture & The Pivot Tool 9.2 Creating and Structuring Datasets & Hierarchies 9.3 Accelerating Data Models & TSIDX Acceleration
11 Chapter 10: Common Information Model (CIM)
10.1 The Splunk Common Information Model (CIM) & Normalization 10.2 CIM Knowledge Objects, Data Models & Schemas 10.3 Normalizing & Validating Data with the CIM App / datamodel command
8.1 Workflow Action Architecture & Field/Event Context
Key Takeaways Explain This Topic AI
Workflow actions provide interactive, context-sensitive menu items in Splunk Web that enable analysts to launch external web queries, submit HTTP POST requests, or execute secondary SPL searches directly from search results without manual copy-pasting.
Splunk supports three distinct workflow action types: GET (HTTP GET requests constructing dynamic URLs with query parameters), POST (HTTP POST requests submitting form payloads to remote web endpoints), and Search (launching dynamic secondary SPL queries within Splunk).
Workflow actions can target specific UI locations via display_location: Event Actions menu (event_menu attached to whole event rows), Field Actions menu (field_menu attached to specific field dropdowns), or Both (both), requiring explicit field definitions for field menus.
Dynamic variable token interpolation uses dollar-sign syntax ( f i e l d n a m e fieldname f i e l d nam e ), supporting standard extracted fields, internal metadata fields ( t i m e _time t im e , r a w _raw r a w , c d _cd c d ), and special context tokens ( @ f i e l d n a m e @field_name @ f i e l d n am e , @ f i e l d v a l u e @field_value @ f i e l d v a l u e ), with $$ escaping literal dollar signs.
A workflow action is strictly suppressed from the UI if any variable token referenced in its label, URI, search string, or POST arguments is missing or null in the target event, preventing broken links or invalid searches.
Last updated: August 2026
8.1 Workflow Action Architecture & Field/Event Context
Quick Summary: Workflow Actions are interactive context-menu items in Splunk Web that bridge the gap between raw log search results and external systems or secondary internal searches. Configured graphically via Settings > Fields > Workflow actions or through workflow_actions.conf , workflow actions dynamically extract field values from the current event and interpolate them into external HTTP GET URLs, HTTP POST payload requests, or secondary SPL search queries. Precise scoping by sourcetype, host, source, event type, and field presence ensures context menus remain clean, relevant, and actionable.
1. What Are Workflow Actions?
During operational troubleshooting, security incident response, or business analytics investigations, an analyst rarely completes an entire inquiry within a single search view. When analyzing events in the Splunk Events Viewer, an investigator frequently discovers actionable indicators of compromise or operational anomalies—such as an external IP address ( src_ip ), a malicious file hash ( file_hash ), a targeted username ( user ), a database transaction ID ( trans_id ), or an application error code ( error_code ).
Without automation, the analyst must manually copy the indicator value, open a new browser tab or tool, navigate to the target portal (such as a threat intelligence feed, CMDB, or ticketing system), paste the indicator, and initiate the lookup. Alternatively, to cross-correlate that indicator against other internal data sources (such as firewall logs or authentication records), the analyst must open a new Splunk search tab, construct a complex SPL query from scratch, and manually set the time window.
Workflow Actions eliminate this friction by embedding automated, parameter-driven integration links directly into the Splunk Web search interface. +------------------------------------------------------------------------------------------------+
- | WORKFLOW ACTION RESOLUTION ENGINE |
- | |
- | Search Results Stream: |
- | 2026-08-24 14:10:05 | sourcetype=access_combined | clientip=198.51.100.42 | status=500 |
- | |
- | +--------------------------------+ +-----------------------------------------------+ |
- | | [ Event Actions Menu v ] | | [ Field Actions Menu: clientip ] | |
- | |--------------------------------| |-----------------------------------------------| |
- | | > Build Event Type | | > Show only this value | |
- | | > Extract Fields | | > Exclude this value | |
- | | > [Search] Investigate Session | | > [GET] Query VirusTotal for 198.51.100.42 | |
- | | > [POST] Create Jira Incident | | > [GET] Query Cisco Talos for 198.51.100.42 | |
- | +--------------------------------+ +-----------------------------------------------+ |
- +------------------------------------------------------------------------------------------------+
When a user opens an Event Actions or Field Actions menu, Splunk's dynamic resolution engine evaluates the event context against configured scoping rules, replaces all variable placeholders ( $fieldname$ ) with actual extracted field values from the event, and renders the clickable action.
2. The Three Types of Workflow Actions
Splunk supports three distinct workflow action types. Each type serves a specialized integration pattern across enterprise environments:
Workflow Action Type Underlying Protocol / Action Primary Use Cases Configuration Parameters ( workflow_actions.conf )
GET (Link) HTTP/HTTPS GET request Directs the browser to an external or internal URL with parameters appended to the query string (e.g., threat intelligence lookups on VirusTotal/Talos, WHOIS lookups, CMDB asset records, Google searches). type = link ; link.method = get ; link.uri = <target_URL>
POST (Link) HTTP/HTTPS POST request Submits structured key-value form data in the HTTP request body to remote web endpoints or REST APIs (e.g., opening a ServiceNow incident, logging a Jira bug, triggering a SOAR webhook). type = link ; link.method = post ; link.uri = <target_URL> ; link.postargs.<n>.key / link.postargs.<n>.value = <val>
Search Internal Splunk SPL execution Launches a dynamic secondary Splunk search pre-populated with extracted field values from the initiating event, targeting specific apps, views, and custom time windows. type = search ; search.search_string = <SPL> ; search.app = <app_name> ; search.earliest / search.latest
1. GET Workflow Actions
GET workflow actions are the most widely deployed workflow action type. They construct an HTTP GET request by appending parameter values into the URL query string. Because HTTP GET operations are idempotent (read-only and non-destructive), they are ideal for querying public threat repositories, domain registrars, external knowledge bases, and corporate intranets.
2. POST Workflow Actions
POST workflow actions generate an HTTP POST request that transmits form data within the HTTP message body. Unlike GET actions, which expose parameters in the browser address bar, POST actions encapsulate payload arguments within the request body ( link.postargs ). This makes POST actions necessary for state-changing operations, such as creating support tickets, dispatching notifications, or invoking webhook endpoints on remote services.
3. Search Workflow Actions
Search workflow actions keep the analyst inside Splunk by executing a secondary SPL query. Splunk extracts contextual field values from the selected event, injects them into a pre-authored SPL query template, and runs or stages the search in a specified Splunk app and dashboard view. This allows analysts to pivot instantly from a high-level summary alert into raw forensic logs (such as jumping from an authentication failure event to a network connection trace).
3. Display Locations: Event Actions vs. Field Actions Context Menus
Workflow actions appear in Splunk Web across two primary interface locations based on the configured display_location setting: +------------------------------------------------------------------------------------------------+
- | SPLUNK WEB DISPLAY LOCATIONS |
- | |
- | 1. EVENT ACTIONS MENU (display_location = event_menu) |
- | [>] 2026-08-24 14:10:05.120 host=web-01 sourcetype=access_combined |
- | | |
- | +-- [ Event Actions v ] <-- Attached to the whole event row |
- | |-- Show raw event |
- | |-- Build Event Type |
- | |-- [Workflow] Correlate all logs for host web-01 (+/- 15m) |
- | \-- [Workflow] Create ServiceNow Ticket for Error 500 |
- | |
- | 2. FIELD ACTIONS CONTEXT MENU (display_location = field_menu) |
- | +-- Expanded Event Details: |
- | | Field Name | Value | Context Action Dropdown |
- | |------------|----------------|--------------------------------------------------------|
- | | clientip | 198.51.100.42 | [v] --> [Workflow] VirusTotal IP Lookup |
- | | | | --> [Workflow] Cisco Talos Reputation Lookup |
- | | user | admin_service | [v] --> [Workflow] Active Directory User Audit |
- | | status | 500 | [v] --> [Workflow] Search HTTP 500 Knowledge Base |
- +------------------------------------------------------------------------------------------------+
- Comparison of Display Locations
Attribute Event Actions Menu ( event_menu ) Field Actions Menu ( field_menu ) Both Menus ( both )
UI Location Dropdown button on the left of each event row (or top of the event drawer). Dropdown arrow next to a specific field name or value in the event table or Fields sidebar. Appears in both the Event Actions menu and applicable Field Actions menus.
Contextual Scope Evaluated across the entire event . Bound strictly to the specific clicked field . Evaluated for both event-level and field-level contexts.
Required Settings display_location = event_menu display_location = field_menu ; fields = <field_list> display_location = both ; fields = <field_list>
Typical Use Cases Actions requiring multiple event fields (e.g., ticket creation with host, user, and error; cross-index correlation queries). Entity-specific lookups (e.g., IP reputation, domain WHOIS, user directory lookup, hash analysis). Comprehensive investigative actions relevant from both macro and micro views.
4. Dynamic Variable Token Interpolation Syntax
Variable interpolation allows workflow actions to dynamically adapt to the data contained in individual events. Splunk uses dollar-sign delimiters ( $fieldname$ ) to identify variable tokens across labels, URLs, search strings, and POST arguments.
Variable Token Reference Guide
Variable Syntax Scope & Source Description & Evaluation Example
$fieldname$ Extracted / Calculated Fields Resolves to the extracted value of the specified case-sensitive field name. If user="jsmith" , $user$ resolves to jsmith .
$_time$ Internal Timestamp Field Resolves to the raw epoch timestamp integer of the event (e.g., 1755984005 ). Useful for passing exact timestamps to secondary searches or ticketing systems.
$_raw$ Internal Event Text Resolves to the entire unparsed raw text of the event. Useful for injecting raw log messages into ticket description fields.
$_cd$ / $_serial$ Internal Event Metadata Resolves to Splunk internal index block pointers and event serial numbers.
$@field_name$ Field Menu Context Special token in Field Actions menus that resolves dynamically to the name of the clicked field (e.g., src_ip or dest_ip ).
$@field_value$ Field Menu Context Special token in Field Actions menus that resolves dynamically to the value of the clicked field (e.g., 198.51.100.42 ).
$$ Literal Character Escape Escapes a dollar sign to prevent Splunk from interpreting it as a variable token. For example, Cost ($$ USD) renders as Cost ($ USD) . +------------------------------------------------------------------------------------------------+
- | DYNAMIC VARIABLE SUBSTITUTION |
- | |
- | Event Values: clientip="198.51.100.42" status="500" host="web-app01" |
- | |
- | 1. Label Template: "Lookup IP $clientip$ on VirusTotal (Host: $host$)" |
- | Rendered Label: "Lookup IP 198.51.100.42 on VirusTotal (Host: web-app01)" |
- | |
- | 2. URI Template: "https://virustotal.com/gui/ip-address/$clientip$/detection" |
- | Rendered URI: "https://virustotal.com/gui/ip-address/198.51.100.42/detection" |
- | |
- | 3. Context Tokens: fields = clientip, src_ip, dest_ip |
- | URI Template: "https://whois.domaintools.com/$@field_value$" |
- | Clicked clientip: "https://whois.domaintools.com/198.51.100.42" |
- +------------------------------------------------------------------------------------------------+
- The Critical Variable Presence & Suppression Rule
Important
The Strict Suppression Rule: Splunk requires that all variable tokens referenced in a workflow action's label , link.uri , search.search_string , or link.postargs must exist and be non-null within the selected event. If even a single referenced variable is missing from the event, Splunk automatically suppresses the workflow action from the menu.
For example, if an action label is configured as Investigate $user$ on host $dest_host$ , but an event contains user without a dest_host field, the entire action is silently hidden for that event. This design prevents users from clicking broken links or executing malformed searches with unpopulated $token$ placeholders.
5. Granular Scoping Controls & Configuration Methods
To prevent context menus from becoming overcrowded with irrelevant options, Splunk provides multiple scoping directives to restrict when a workflow action is rendered.
Scoping Directives in workflow_actions.conf
Scoping Parameter Matching Logic Configuration Example
fields Comma-delimited list of field names that must be present. Required for field_menu . fields = clientip, src_ip, dest_ip, remote_ip or fields = *
sourcetype Restricts action to events matching the specified sourcetype string or pattern. sourcetype = access_combined or sourcetype = WinEventLog:*
source Restricts action to events originating from the specified source path. source = /var/log/nginx/access.log
host Restricts action to events originating from the specified host name. host = web-prod-*
eventtypes Restricts action to events classified under one or more defined event types. eventtypes = web_error, auth_failure
Multi-Condition Evaluation (Boolean AND)
When multiple scoping conditions are configured within the same workflow action stanza, Splunk evaluates them using boolean AND logic across different criteria and boolean OR logic within comma-separated lists : Action Rendered = ( Sourcetype Match ) ∧ ( Host Match ) ∧ ( Eventtype Match ) ∧ ( At Least One Field Present ) ∧ ( All Tokens Resolved ) \text{Action Rendered} = (\text{Sourcetype Match}) \land (\text{Host Match}) \land (\text{Eventtype Match}) \land (\text{At Least One Field Present}) \land (\text{All Tokens Resolved}) Action Rendered = ( Sourcetype Match ) ∧ ( Host Match ) ∧ ( Eventtype Match ) ∧ ( At Least One Field Present ) ∧ ( All Tokens Resolved ) +------------------------------------------------------------------------------------------------+
- | SCOPING EVALUATION PIPELINE |
- | |
- | Configuration: sourcetype = cisco:asa | fields = src_ip, dest_ip | eventtypes = vpn_drop |
- | |
- | Event A: sourcetype=cisco:asa, eventtype=vpn_drop, src_ip=10.0.0.1 --> MATCH (Action Shown) |
- | Event B: sourcetype=cisco:asa, eventtype=vpn_drop (no src/dest IP) --> FAIL (Field Missing) |
- | Event C: sourcetype=access_combined, src_ip=10.0.0.1 --> FAIL (Sourcetype Mis) |
- +------------------------------------------------------------------------------------------------+
- 6. Configuration Management: Splunk Web vs. Configuration Files
- Method 1: Splunk Web UI Configuration
Power Users and Administrators can create workflow actions graphically:
Navigate to Settings > Fields > Workflow actions .
Click New Workflow Action (or edit an existing action).
Fill in the required fields:
Destination app: The application container for the knowledge object ( search , SplunkEnterpriseSecuritySuite , etc.).
Name: Internal stanza name (letters, numbers, underscores).
Label: Human-readable text displayed in the context menu (supports $tokens$ ).
Apply only to the following: Select sourcetype , source , host , or eventtypes .
Show action in: Choose Event menu , Field menu , or Both .
Fields: Specify field names (required when Field menu or Both is selected).
Action type: Choose link (for GET/POST) or search .
Click Save and manage knowledge object permissions.
Method 2: Configuration Files ( workflow_actions.conf )
In enterprise CI/CD workflows and distributed deployments, workflow actions are maintained in workflow_actions.conf files: # $SPLUNK_HOME/etc/apps/search/local/workflow_actions.conf
- [virustotal_lookup_srcip]
- type = link
- label = Check VirusTotal for IP $src_ip$
- display_location = field_menu
- fields = src_ip, clientip
- link.method = get
- link.uri = https://www.virustotal.com/gui/ip-address/$@field_value$/detection
- link.target = blank
- [escalate_incident_servicenow]
- type = link
- label = Create ServiceNow Incident for $host$
- display_location = event_menu
- sourcetype = access_combined
- link.method = post
- link.uri = https://instance.service-now.com/api/now/table/incident
- link.target = blank
- link.postargs.1.key = caller
- link.postargs.1.value = splunk_alert
- link.postargs.2.key = short_description
- link.postargs.2.value = Web 500 error on $host$ from client $clientip$
- link.postargs.3.key = urgency
- link.postargs.3.value = 2
- Knowledge Object Scoping & Directory Precedence
Workflow actions adhere to standard Splunk knowledge object scoping tiers:
Private: Stored in $SPLUNK_HOME/etc/users/<username>/<app>/local/workflow_actions.conf . Visible exclusively to the author.
App (This app only): Stored in $SPLUNK_HOME/etc/apps/<app>/local/workflow_actions.conf . Accessible to all users within the specific app.
Global (All apps): Shared across all apps with export = system in local.meta . Accessible in every app on the search head.