Study guide
8.2 Creating GET and POST Workflow Actions
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.2 Creating GET and POST Workflow Actions
Key Takeaways Explain This Topic AI
GET workflow actions construct HTTP GET requests by dynamically injecting field tokens into uniform resource identifiers (URIs), opening external resources such as threat intelligence feeds, domain registrars, or search engines.
POST workflow actions submit structured key-value form data in the HTTP request body (link.postargs.<n>.key / link.postargs.<n>.value) to remote web endpoints or REST APIs, enabling state-changing integrations like incident ticket creation in ServiceNow or Jira.
Both GET and POST actions support target window configuration (link.target), allowing administrators to open links in a new browser tab/window (link.target = blank, the default) or reuse the existing active window (link.target = self).
URL encoding in GET workflow actions requires careful handling: Splunk automatically URL-encodes token values injected into URIs, but static query string delimiters (?, &, =) must remain unencoded to ensure valid HTTP requests.
Security governance for external workflow actions requires validating destination URIs, restricting sensitive token leakage in query strings, and employing POST requests over HTTPS when passing confidential event attributes.
Last updated: August 2026
8.2 Creating GET and POST Workflow Actions
Quick Summary: Link-based workflow actions connect Splunk events to external web applications using HTTP protocols. HTTP GET actions append event field values into URL query strings to open threat intelligence lookups, IP WHOIS records, or internal CMDB pages. HTTP POST actions submit structured payload data within the HTTP request body ( link.postargs ) to trigger remote REST APIs, log incident tickets in ServiceNow or Jira, or activate SOAR playbooks. Both support target window controls ( blank vs. self ) and automatic URL encoding of field token variables.
1. Architectural Overview of Link-Based Workflow Actions
In enterprise operations, Splunk is the central nervous system for monitoring and analytics, but remediation, threat analysis, and ticketing occur in specialized external platforms. Link-based workflow actions create friction-free bridges between Splunk and these external ecosystems. +------------------------------------------------------------------------------------------------+
- | HTTP GET VS. HTTP POST WORKFLOW ACTION ARCHITECTURE |
- | |
- | 1. HTTP GET WORKFLOW ACTION (Read-Only / Idempotent Query): |
- | User clicks "Lookup VirusTotal" on clientip=198.51.100.42 |
- | --> Browser constructs: https://www.virustotal.com/gui/ip-address/198.51.100.42/detection |
- | --> Opens in New Tab (link.target = blank); parameters exposed in URL; safe for repeated execution. |
- | |
- | 2. HTTP POST WORKFLOW ACTION (State-Changing / Payload Submission): |
- | User clicks "Create ServiceNow Incident" on host=web01, error=500 |
- | --> Browser/Splunk sends HTTP POST to: https://instance.service-now.com/api/now/incident |
- | --> HTTP Body Payload: { "caller": "splunk", "cmdb_ci": "web01", "urgency": "2" } |
- | --> Ticket is created; parameters hidden from URL bar; modifies remote system state. |
- +------------------------------------------------------------------------------------------------+
- Comparison: GET vs. POST Workflow Actions
- Architectural Parameter HTTP GET Workflow Action HTTP POST Workflow Action
- Underlying Method link.method = get link.method = post
Data Transmission Appended to URL path / query string ( ?key=val&key2=val2 ). Transmitted in HTTP request body as form data / payload.
Primary Use Cases External search engines, threat intelligence feeds (VirusTotal, Cisco Talos, Shodan), IP/Domain WHOIS lookups, CMDB asset views, knowledge base searches. Automated ticketing (ServiceNow, Jira, Zendesk), SOAR alert webhooks, paging systems (PagerDuty), REST API write operations.
Idempotency Strictly idempotent (safe to refresh, execute multiple times without side effects). Non-idempotent (creates records, modifies database state, sends notifications).
Parameter Exposure Fully visible in browser address bar, web server access logs, and proxy logs. Hidden from browser address bar and standard URL access logs.
Splunk Configuration Requires link.uri with embedded $tokens$ . Requires link.uri and one or more link.postargs.<n>.key / link.postargs.<n>.value parameters.
2. Configuring HTTP GET Workflow Actions
GET workflow actions are designed for fast external reference lookups. When an analyst clicks a GET action, Splunk takes the template URL defined in link.uri , substitutes all $token$ placeholders with real event values, URL-encodes special characters in those values, and instructs the browser to navigate to that URL.
Configuration Attributes for GET Actions
Setting ( workflow_actions.conf ) Splunk Web UI Field Description & Valid Options
type = link Action type Must be set to link (or select "Link" in the UI dropdown).
link.method = get Method Must be set to get (or select "GET" in the UI dropdown).
link.uri = <string> URI The full target URL, including protocol ( https:// ), domain, path, and optional query parameters with $tokens$ .
link.target = <string> Open in Controls window behavior: blank (new tab/window) or self (current window). Defaults to blank .
label = <string> Label Context menu text displayed to users. Can include $tokens$ .
display_location Show action in event_menu , field_menu , or both .
fields Fields Comma-delimited list of fields required when targeting field menus.
- Step-by-Step GET Action Walkthrough: External Threat Intelligence
- Scenario: Threat Intel IP Lookup on VirusTotal & Cisco Talos
A Security Operations Center (SOC) wants tier-1 analysts to immediately check any suspicious external IP address ( src_ip , dest_ip , or clientip ) against VirusTotal and Cisco Talos with a single click.
Web UI Setup:
Navigate to Settings > Fields > Workflow actions .
Click New Workflow Action .
Enter the following parameters:
- Destination app: search
- Name: virustotal_ip_lookup
- Label: VirusTotal Reputation: $@field_value$
Apply only to the following: Leave blank (applies across all sourcetypes).
- Show action in: Field menu
- Fields: src_ip, dest_ip, clientip, remote_ip
- Action type: link
- URI: https://www.virustotal.com/gui/ip-address/$@field_value$/detection
- Method: GET
- Open in: New window (writes link.target = blank )
Click Save .
Under Permissions , share the object globally or to the Search app.
Equivalent workflow_actions.conf Definition: # $SPLUNK_HOME/etc/apps/search/local/workflow_actions.conf
- [virustotal_ip_lookup]
- type = link
- link.method = get
- label = VirusTotal Reputation: $@field_value$
- display_location = field_menu
- fields = src_ip, dest_ip, clientip, remote_ip
- link.uri = https://www.virustotal.com/gui/ip-address/$@field_value$/detection
- link.target = blank
- [talos_ip_lookup]
- type = link
- link.method = get
- label = Cisco Talos Lookup for $@field_value$
- display_location = field_menu
- fields = src_ip, dest_ip, clientip, remote_ip
- link.uri = https://talosintelligence.com/reputation_center/lookup?search=$@field_value$
- link.target = blank
- 3. Configuring HTTP POST Workflow Actions
POST workflow actions submit structured data to web endpoints. Unlike GET actions where parameters reside in the URL, POST actions package arguments into the HTTP request body. In workflow_actions.conf , each body parameter is defined using the prefix link.postargs.<n>.key and link.postargs.<n>.value . +------------------------------------------------------------------------------------------------+
- | HTTP POST PAYLOAD CONSTRUCTION |
- | |
- | Event: host="db-srv01.corp" status="500" user="svc_batch" error_msg="DB Connection Timeout" |
- | |
- | Configuration: |
- | link.uri = https://jira.company.com/rest/api/2/issue |
- | link.postargs.1.key = project |
- | link.postargs.1.value = SEC |
- | link.postargs.2.key = summary |
- | link.postargs.2.value = Splunk Alert: Critical error on $host$ |
- | link.postargs.3.key = description |
- | link.postargs.3.value = User $user$ failed with: $error_msg$ in event $_raw$ |
- | link.postargs.4.key = priority |
- | link.postargs.4.value = High |
- | |
- | Constructed HTTP Request: |
- | POST /rest/api/2/issue HTTP/1.1 |
- | Host: jira.company.com |
- | Content-Type: application/x-www-form-urlencoded |
- | |
- | project=SEC&summary=Splunk+Alert%3A+Critical+error+on+db-srv01.corp&... |
- +------------------------------------------------------------------------------------------------+
- Step-by-Step POST Action Walkthrough: ServiceNow Incident Creation
Web UI Setup:
Navigate to Settings > Fields > Workflow actions .
Click New Workflow Action .
Configure fields:
- Name: create_servicenow_incident
- Label: Create ServiceNow Incident ($host$)
- Apply only to the following sourcetype: access_combined
- Show action in: Event menu
- Action type: link
- URI: https://mycorp.service-now.com/nav_to.do?uri=incident.do
- Method: POST
Post arguments:
sysparm_query : caller_id=Splunk^short_description=Web server $host$ error $status$^description=Raw Event: $_raw$
Open in: New window (writes link.target = blank )
Click Save .
Equivalent workflow_actions.conf Definition: # $SPLUNK_HOME/etc/apps/search/local/workflow_actions.conf
- [create_servicenow_incident]
- type = link
- link.method = post
- label = Create ServiceNow Incident ($host$)
- display_location = event_menu
- sourcetype = access_combined
- link.uri = https://mycorp.service-now.com/incident.do
- link.target = blank
- link.postargs.1.key = sysparm_query
link.postargs.1.value = caller_id=Splunk^short_description=Web server $host$ error $status$^description=Raw Event: $_raw$
- link.postargs.2.key = category
- link.postargs.2.value = Infrastructure
- link.postargs.3.key = impact
- link.postargs.3.value = 2
- link.postargs.4.key = urgency
- link.postargs.4.value = 1
- 4. Target Window Controls & Navigation Behavior
The link.target configuration controls how the user's browser renders the target destination when a link-based action is triggered: ┌───────────────────────────────┐
- │ Target Window Options │
- └──────────────┬────────────────┘
- │
- ┌────────────────────────┴────────────────────────┐
- ▼ ▼
- ┌───────────────────────────┐ ┌───────────────────────────┐
- │ link.target = blank │ │ link.target = self │
- │ (New Tab/Window) │ │ (Current Window) │
- ├───────────────────────────┤ ├───────────────────────────┤
- │ • Default setting │ │ • Overwrites active tab │
- │ • Preserves Splunk search │ │ • Loses search state │
- │ • Ideal for external tools│ │ • Used for intranet apps │
- └───────────────────────────┘ └───────────────────────────┘
Setting Value Splunk Web UI Option Behavioral Execution & Best Practice
blank (Default) New window Spawns a new browser tab or window. This is the strongly recommended standard for almost all link workflow actions, as it prevents the analyst from losing their current search results, active filters, or timeline view in Splunk.
self Current window Directs the current browser tab to the target URL, replacing the Splunk Web interface. Use sparingly—typically only for intranet portals that have built-in navigation to return to Splunk.
<frame_name> Custom Named Frame Directs the request to a specific named browser frame or window object if developing embedded dashboard frames.
5. URL Encoding, Special Characters & Token Escaping
When passing dynamic data into external web links, character formatting and encoding require careful consideration:
1. Automatic Dynamic URL Encoding
Splunk automatically applies standard RFC 3986 percent-encoding to all field values substituted into $fieldname$ tokens within link.uri and link.postargs .
Spaces are encoded as %20 or +
Slashes ( / ), ampersands ( & ), and question marks ( ? ) within the field value are encoded so they do not break the URL structure.
2. Static URI Formatting
Static characters explicitly authored in the link.uri string itself are not escaped. You must write proper URL syntax with standard query delimiters: # Correct syntax: static '?' and '&' separate query arguments
- link.uri = https://search.internal.corp/query?host=$host$&app=$app_name$
- 3. Escaping Literal Dollar Signs
If an external service requires a literal dollar sign in a query string or argument (or if a label text contains currency), escape it with a double dollar sign ( $$ ): # Displays label as: "Check Pricing ($ USD) for Server $host$"
- label = Check Pricing ($$ USD) for Server $host$
- 6. Enterprise Security & Governance for External Actions
Power Users and administrators must enforce strict security controls when designing external workflow actions:
Data Leakage in GET Query Strings: GET URLs are logged in plain text by web proxies, browser histories, and edge firewalls. Never configure GET workflow actions that pass sensitive data (passwords, social security numbers, API tokens, or session IDs) in URL query parameters. Always use HTTPS POST for sensitive attributes.
Destination Protocol Validation: Ensure all external workflow action URIs enforce encrypted HTTPS ( https:// ) rather than unencrypted HTTP ( http:// ) to protect data in transit.
Cross-Origin Resource Sharing (CORS) & Authentication: POST actions submitted via standard browser form posts depend on existing active sessions or API tokens accepted by the target endpoint. If an endpoint requires header-based OAuth tokens that cannot be supplied in form posts, consider Splunk alert webhooks or SOAR integrations instead.
Preventing Open Redirect Hazards: Ensure internal workflow action URIs point strictly to trusted, whitelisted enterprise domains to prevent malicious URI redirection attacks.