Study guide
8.3 Creating Search Workflow Actions & Dynamic Secondary Searches
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.3 Creating Search Workflow Actions & Dynamic Secondary Searches
Key Takeaways Explain This Topic AI
Search workflow actions execute secondary, targeted SPL queries directly within Splunk Web, passing dynamic field tokens ( f i e l d n a m e fieldname f i e l d nam e ) from the triggering event into the new search pipeline.
Time range inheritance allows secondary searches to either inherit the exact time boundaries of the triggering event or apply custom relative time offsets (search.earliest and search.latest) such as -15m to +15m around t i m e _time t im e .
Search workflow actions can be explicitly routed to specific Splunk applications (search.app) and designated target views (search.view), defaulting to the search view if unspecified.
The search.preserve_timerange setting governs whether the initiating search's global time picker range is maintained or overridden by the action's specific earliest/latest time configuration.
Search actions empower SOC triage and IT root-cause analysis by automating repetitive pivot searches, such as tracking all authentication activity for a compromised user or mapping firewall connections around a security incident.
Last updated: August 2026
8.3 Creating Search Workflow Actions & Dynamic Secondary Searches
Quick Summary: Search workflow actions execute secondary, parameterized Splunk searches directly from the Event Actions or Field Actions menus. By interpolating event tokens (e.g., $src_ip$ , $user$ , $_time$ ) into pre-authored SPL templates, search actions enable instant cross-index correlation, deep-dive forensic pivots, and automated root-cause analysis. Key configuration parameters include search string templates ( search.search_string ), time range inheritance and offsets ( search.earliest , search.latest , search.preserve_timerange ), application context ( search.app ), and target view routing ( search.view ).
1. The Power of Search Workflow Actions
In enterprise operations, discovering an anomaly in one log source is almost always the beginning of an investigation, not the end. For example:
An alert in index=web shows an HTTP 500 error associated with clientip=198.51.100.42 at 14:15:00. The analyst needs to immediately inspect index=firewall for all connections from that IP, and index=os for database CPU spikes at that exact time.
A security alert flags a failed login for user=svc_finance in index=wineventlog . The SOC analyst needs to inspect all authentication events for that user across the entire network in the surrounding 30-minute window.
Without search workflow actions, analysts must manually open a new search window, retype the target index names, reconstruct complex SPL boolean logic, copy-paste IP addresses or usernames, and manually set the time picker.
Search workflow actions automate this entire pivoting lifecycle into a single click. +------------------------------------------------------------------------------------------------+
- | SEARCH WORKFLOW ACTION PIVOT FLOW |
- | |
- | 1. Initiating Search Result (Web Access Logs): |
- | 2026-08-24 14:15:00 | host=web-srv01 | clientip=198.51.100.42 | status=500 |
- | |
- | 2. User clicks Event Action: "Investigate Firewall Traffic for 198.51.100.42 (+/- 15m)" |
- | |
- | 3. Splunk Interpolates Configured SPL Template: |
- | Template: index=firewall (src_ip=$clientip$ OR dest_ip=$clientip$) | stats count by action |
- | Resolved: index=firewall (src_ip=198.51.100.42 OR dest_ip=198.51.100.42) | stats count... |
- | |
- | 4. Splunk Resolves Time Range: |
- | Event Time: 14:15:00 --> Earliest: 14:00:00 (-15m) --> Latest: 14:30:00 (+15m) |
- | |
- | 5. Splunk Opens Search App in New Tab and Executes the Resolved Search Immediately! |
- +------------------------------------------------------------------------------------------------+
- 2. Configuration Parameters for Search Workflow Actions
Search workflow actions are governed by dedicated attributes in workflow_actions.conf or the corresponding form fields in Splunk Web under Settings > Fields > Workflow actions :
Setting ( workflow_actions.conf ) Splunk Web UI Field Description & Syntax
type = search Action type Must be set to search (select "Search" in UI dropdown).
search.search_string = <SPL> Search string The complete SPL query template containing field tokens (e.g., index=security user="$user$" ).
search.app = <app_name> Destination app Specifies the target Splunk application context (e.g., search , SplunkEnterpriseSecuritySuite ). If omitted, defaults to the current active app.
search.view = <view_name> Target view Specifies the destination dashboard or view within the app (e.g., search , flashtimeline , analytics_workspace ). Defaults to the standard search view.
search.earliest = <time> Earliest time Defines the earliest boundary for the secondary search (supports relative offsets like -15m , epoch $time_offset$ , or absolute dates).
search.latest = <time> Latest time Defines the latest boundary for the secondary search (supports relative offsets like +15m , now , or epoch $time_offset$ ).
search.preserve_timerange Preserve search time range Boolean ( true / false ). When true , uses the time picker range of the initiating search. When false , uses search.earliest and search.latest .
search.target = <target> Open in blank (new tab/window) or self (current window). Defaults to blank .
search.run_on_open Run on open Boolean ( true / false ). When true (default), runs the search immediately upon opening. When false , populates the search bar without running.
3. Time Range Inheritance & Relative Offset Mechanics
One of the most critical aspects of Search Workflow Actions is controlling the time range of the secondary search. Splunk provides two primary models: Time Range Preservation and Relative Time Offsets . +------------------------------------------------------------------------------------------------+
- | TIME RANGE SELECTION STRATEGIES |
- | |
- | OPTION A: PRESERVE TIME RANGE (search.preserve_timerange = true) |
- | • Secondary search inherits the broad time window of the initiating search (e.g., "Last 7d").|
- | • Use case: Broad summary reports and aggregate pattern analysis. |
- | |
- | OPTION B: RELATIVE TIME OFFSET (search.preserve_timerange = false) |
- | • Secondary search anchors around the exact event timestamp ($_time$) with specified bounds. |
- | • search.earliest = -15m@m (15 minutes before event) |
- | • search.latest = +15m@m (15 minutes after event) |
- | • Use case: High-precision forensic triage and local event correlation. |
- +------------------------------------------------------------------------------------------------+
- 1. Preserving Global Time Range ( search.preserve_timerange = true )
If an analyst ran a search over "Previous 24 Hours" or "Last 7 Days", setting search.preserve_timerange = true causes the secondary search to execute across that identical 24-hour or 7-day window. This is ideal when the analyst wants to know if a specific error code or user appeared anywhere else during the overall time period under investigation.
2. Forensic Window Offsets ( search.preserve_timerange = false )
When triaging a specific incident (e.g., a malware beacon or server crash), searching a broad 7-day window generates overwhelming noise. By setting search.preserve_timerange = false and specifying relative offsets in search.earliest and search.latest :
- search.earliest = -30m
- search.latest = +30m
Splunk calculates the time bounds relative to the exact _time of the clicked event . If the event occurred at 14:15:00 , the secondary search is strictly bound between 13:45:00 and 14:45:00 , providing instant, targeted forensic context.
4. Application & View Targeting
Search workflow actions allow Power Users to direct the secondary search into specialized Splunk apps and custom views: ┌────────────────────────────────────────┐
- │ Search Workflow Action Routing │
- └───────────────────┬────────────────────┘
- │
- ┌────────────────────────┴────────────────────────┐
- ▼ ▼
- ┌─────────────────────────┐ ┌─────────────────────────┐
- │ search.app = <app> │ │ search.view = <view> │
- │ (Application Container) │ │ (Target View / UI) │
- ├─────────────────────────┤ ├─────────────────────────┤
- │ • search (Default) │ │ • search (Default view) │
- │ • SplunkEnterpriseSec │ │ • flashtimeline (Classic)│
- │ • ITSI / AppAnalytics │ │ • custom_dashboard │
- └─────────────────────────┘ └─────────────────────────┘
Why App & View Targeting Matters:
Knowledge Object Isolation: If the secondary search utilizes search macros, calculated fields, or event types defined only within a specific application (e.g., SplunkEnterpriseSecuritySuite ), setting search.app = SplunkEnterpriseSecuritySuite ensures the SPL query has access to those private/app-scoped knowledge objects.
Custom Investigation Dashboards: By routing to a custom dashboard view ( search.view = investigator_dashboard ), the search query can populate a specialized multi-panel visualization layout rather than the generic Search & Reporting interface.
- 5. SOC & NOC Real-World Implementation Scenarios
- Scenario 1: Cross-Index User Audit across Windows & VPN Logs
An enterprise SOC wants an Event Action on Windows Security logs that immediately searches across both VPN and Domain Controller logs for all activity involving that user within 1 hour before and after the event.
Configuration in workflow_actions.conf : # $SPLUNK_HOME/etc/apps/search/local/workflow_actions.conf
- [correlate_user_activity]
- type = search
- label = Audit all activity for user $user$ (+/- 60m)
- display_location = event_menu
- sourcetype = WinEventLog:Security
- search.app = search
- search.view = search
search.search_string = (index=wineventlog OR index=vpn) user="$user$" | stats count, values(action), values(src_ip) by index, sourcetype
- search.preserve_timerange = false
- search.earliest = -60m
- search.latest = +60m
- search.target = blank
- search.run_on_open = true
- Scenario 2: Network Connection Triage from Web Access Logs
When inspecting web access logs ( access_combined ), an analyst wants a Field Action on clientip to correlate firewall permit/drop actions.
- Configuration in workflow_actions.conf : [firewall_triage_by_ip]
- type = search
- label = Trace Firewall Traffic for IP $@field_value$
- display_location = field_menu
- fields = clientip, src_ip, dest_ip
search.search_string = index=firewall (src_ip="$@field_value$" OR dest_ip="$@field_value$") | stats count by action, dest_port, proto
- search.preserve_timerange = false
- search.earliest = -15m
- search.latest = +15m
- search.target = blank
- 6. Comprehensive Workflow Actions Configuration Reference
Here is a complete comparison of all configuration parameters across the three workflow action types in workflow_actions.conf :
- Stanza Parameter GET Link Action POST Link Action Search Action
- type link link search
- link.method get post N/A
- link.uri Target URL with $tokens$ Target API / form endpoint N/A
- link.postargs.<n>.key / link.postargs.<n>.value N/A Key-value body arguments N/A
- search.search_string N/A N/A Full SPL template with $tokens$
- search.app N/A N/A Destination application
- search.view N/A N/A Destination view/dashboard
- search.earliest / latest N/A N/A Time boundaries / offsets
- search.preserve_timerange N/A N/A true or false
- display_location event_menu / field_menu / both event_menu / field_menu / both event_menu / field_menu / both
- fields Field list (for field_menu ) Field list (for field_menu ) Field list (for field_menu )
- label Menu display string Menu display string Menu display string
- 7. Power User Troubleshooting & Best Practices
Always Quote Substituted String Tokens in SPL: When authoring search.search_string , always wrap field tokens in double quotes if they might contain spaces or special characters: index=web user="$user$" . If user contains john doe , unquoted user=$user$ resolves to user=john doe , which is parsed as user=john AND doe .
Verify Field Token Existence: Remember that missing tokens cause automatic suppression. If your search query references $src_ip$ and $dest_ip$ , but an event only has $src_ip$ , the action will not appear. Use separate workflow actions or generalized tokens ( $@field_value$ ) when appropriate.
Test with search.run_on_open = false during Development: When authoring complex secondary searches, set search.run_on_open = false . This populates the search bar in the new tab without executing immediately, allowing you to inspect the resolved SPL query and time range before running.