The Investigation Page is the central workspace in Splunk SOAR where analysts interact with a specific incident or case.
Think of it as your mission control panel for each alert. Once an event is triggered and turned into a case or investigation, this is where all the details live and where analysts do their hands-on work.
It brings together all of the information, playbook results, actions, and notes into one place — making the incident easier to understand, respond to, and document.
A chronological list of everything that has happened related to the case.
This includes:
Automated actions (from playbooks).
Manual analyst actions.
Decision outcomes.
Notes and comments.
Event status changes (e.g., from Open → Closed).
Helps you see the full story of the incident.
Makes it easier to audit or review what actions were taken and when.
Provides clear documentation for reporting and compliance.
Artifacts are pieces of evidence or data that were collected during the event or incident. These can include:
IP addresses
File hashes (MD5, SHA1, SHA256)
URLs
Usernames
Email addresses
Hostnames
Displays all artifacts in a structured table.
Lets you sort or filter them by type.
Allows you to select specific artifacts and take action on them directly (e.g., check reputation, enrich data, run a playbook).
You don’t need to scroll through raw logs.
All critical data points are extracted and clearly shown.
You can quickly interact with just the parts you care about.
Lets analysts manually trigger actions or playbooks from within the investigation.
You can:
Run a specific asset action (e.g., “Query IP reputation” using VirusTotal).
Choose a playbook to run just for one artifact.
Customize input parameters before execution.
Sometimes automation can’t decide everything — human judgment is needed.
Gives analysts flexibility and control during investigations.
Helps analysts respond to new developments as the investigation unfolds.
Log hypotheses or findings (e.g., “This IP is part of a known phishing campaign”).
Collaborate with other analysts in shifts or across teams.
Record decisions made manually (e.g., “User was contacted and confirmed unusual activity”).
Keeps everything documented in one place.
Makes it easier for team members to stay aligned.
Provides historical reference for future investigations or audits.
Let’s look at how analysts actually use the Investigation Page during their workflow:
Example:
You see an IP address in the artifact panel.
You run an enrichment playbook to:
Get geolocation
Query threat intelligence sources
Check past behavior in your SIEM
This helps determine if the IP is benign or malicious.
From the same interface, you can:
Block a suspicious IP on a firewall.
Disable a compromised user account.
Quarantine an infected endpoint.
These actions can be triggered manually or via playbooks with just a few clicks.
Playbooks don’t always run perfectly. In the Investigation Page, analysts can:
Watch live as each step of the playbook runs.
Pause, cancel, or adjust the playbook flow.
Step in to provide manual input if the playbook needs a decision or clarification.
This lets analysts blend automation and human expertise for faster, smarter incident response.
| Component | Function |
|---|---|
| Timeline View | Shows a complete history of everything done on the case |
| Artifacts Panel | Displays and allows action on data like IPs, hashes, URLs |
| Manual Actions Panel | Lets analysts run playbooks and actions manually |
| Notes Section | Used to document findings, decisions, and collaborate with teammates |
Analysts often need to highlight key data points (artifacts) within a case to draw attention for triage or collaboration. Splunk SOAR supports artifact annotation features to support this.
Analysts can "pin" artifacts to the top of the page or to a summary panel.
Pinned artifacts become more visible in the Investigation Overview, making it easier for other team members to quickly identify what matters.
Certain artifacts (e.g., IPs, file hashes, or email addresses) can be flagged as critical.
This helps in:
Prioritizing actions
Triggering additional playbooks or alerts
Auditing post-incident reviews
"How can an analyst highlight a suspicious IP address so it stands out in the investigation view?"
Correct answer: By pinning it or marking it as critical
The Investigation Page includes features to observe and control playbook execution live, which is essential for advanced incident handling.
Each block (action, decision, prompt) of a running playbook is shown in real-time.
Analysts can see:
Which blocks are currently executing
Success/failure states
Output values of actions
If an action fails or behaves unexpectedly, analysts can:
Click into the block to see execution logs
View variable values and errors
This is essential for troubleshooting failed automation
Playbook execution can be:
Paused
Aborted
Manually redirected, especially if a user prompt or decision is required
"Where can an analyst check the outcome of each action in a playbook while it’s running?"
Correct answer: Within the Investigation Page's live playbook view
The Investigation Page is also a hub for generating and exporting documentation after an incident is closed — often required in compliance-driven environments.
Analysts can collect:
Timeline history
Analyst notes
Artifact interactions
Playbook execution results
This can be exported as:
Case Summary Report
Audit Trail Document
Supports:
Incident closure reviews
Internal audits
External compliance reports (e.g., for GDPR, HIPAA, or SOC2)
"After closing a case, how can an analyst prepare documentation for audit purposes?"
Correct answer: Export a case report or timeline from the Investigation Page
| Feature | Description |
|---|---|
| Artifact Pinning | Highlights critical data points visually during triage |
| Critical Marking | Flags high-risk artifacts for prioritization and collaboration |
| Live Playbook Monitoring | View each step’s execution status and outputs in real-time |
| Debug Logs | Inspect action logs and values for troubleshooting |
| Playbook Control | Analysts can pause, cancel, or intervene manually |
| Case Report Export | Generate documentation for audits, compliance, or summaries |
What is the primary function of the Investigation page in Splunk SOAR?
The Investigation page provides the workspace where analysts examine containers, analyze artifacts, execute actions, and review automation results.
Once a container is selected from the Analyst Queue, analysts use the Investigation page to perform detailed analysis. The interface displays artifacts such as IP addresses, domains, and file hashes associated with the event. Analysts can manually run actions against these artifacts using integrated apps, trigger playbooks, and view the results generated by automation. The Investigation page centralizes investigation data, automation outcomes, and analyst interaction, making it the main operational interface for responding to incidents within the SOAR platform.
Demand Score: 71
Exam Relevance Score: 82
How can analysts manually execute actions on artifacts during an investigation?
Analysts can select artifacts within the container and run available app actions directly from the Investigation page.
Artifacts represent observable indicators extracted from the container data. When an artifact is selected, the system displays a list of compatible actions provided by installed apps. Analysts can manually execute these actions, such as performing a threat intelligence lookup or retrieving additional information from external systems. Once executed, the results are recorded in the container’s action history and become accessible to both analysts and playbooks. This capability enables analysts to extend investigations beyond automated workflows.
Demand Score: 64
Exam Relevance Score: 76
Where are action results displayed after an action or playbook runs?
Action results are stored within the container and displayed in the action results panel on the Investigation page.
When an action is executed, the system records the response returned by the external system or integration. These results include structured data fields, status indicators, and additional metadata. Analysts can review this information within the Investigation page to determine whether further investigation steps are required. Playbooks also access this stored result data through datapaths, allowing automation logic to use the results of earlier actions as inputs for subsequent steps.
Demand Score: 59
Exam Relevance Score: 79
Why might an analyst manually run a playbook on an existing container?
An analyst may manually run a playbook when automation did not trigger automatically or when additional analysis is required after the initial investigation.
Playbooks are usually triggered automatically when containers are created and labeled. However, analysts may need to execute additional automation later in the investigation. For example, a container initially processed with a phishing playbook may require additional enrichment once new artifacts are discovered. By manually running a playbook, analysts can apply automation workflows to existing investigation data. This flexibility allows automation to complement manual investigation rather than replacing it entirely.
Demand Score: 58
Exam Relevance Score: 74