SPLK-2003 Visual Playbook Editor

Visual Playbook Editor Detailed Explanation

1. Purpose

The Visual Playbook Editor in Splunk SOAR is a drag-and-drop interface that allows you to build playbooks without writing any code.

It’s ideal for:

• Analysts who are not familiar with Python.

• Teams who want to quickly prototype automation flows.

• Environments where clarity, documentation, and team collaboration are important.

It turns automation into a visual workflow, so you can see exactly what will happen, step by step.

2. Key Features

Canvas Interface

The canvas is your workspace — a large visual grid where you place and connect blocks.

• Drag blocks (also called nodes) from the side menu onto the canvas.

• Connect them with arrows to define the order of execution.

• You can zoom in, out, and drag the canvas to move around.

Each block represents a specific function — an action, a condition, a prompt, etc.

Node Types

Here are the main types of nodes you'll use to build playbooks visually:

1. Start Block

• The entry point of the playbook.

• Defines when and why the playbook should start running.

• Can be triggered by:

  • A new event arriving.

  • A manual user action.

  • A scheduled time or case update.

This block always appears at the top of the canvas.

2. Action Block

• Performs a task using a configured asset.

• Examples:

  • Query IP reputation using VirusTotal.

  • Block a user in Active Directory.

  • Get alert details from Splunk.

• You select:

  • The app/asset (e.g., VirusTotal).

  • The specific action (e.g., ip reputation).

  • Input parameters (e.g., IP address from an artifact).

Action blocks are the workhorses of your playbook.

3. Decision Block

• Adds logic to your workflow.

• Evaluates the result of a previous block and branches the flow accordingly.

Example:

• If VirusTotal score > 80 → go down the “Malicious” path.

• Else → go down the “Safe” path.

• You can define multiple conditions using:

  • Text comparisons (==, contains, etc.)

  • Number ranges (>, <)

  • Presence checks (is empty, exists, etc.)

This is how your playbook becomes smart and responsive.

4. Prompt Block

• Sends a question to an analyst during the playbook run.

• Useful when human input is required before taking action.

Examples:

• “Should we isolate this host?”

• “What priority level should this case have?”

• You can define:

  • Prompt message.

  • Input type (dropdown, text, number).

  • Who receives the prompt (specific user or role).

The playbook will pause until someone responds.

5. Format Block

• Prepares information for display or output.

• Can be used to:

  • Format messages to send via email or Slack.

  • Create summaries to log in the timeline.

  • Structure data before writing it to a case note.

• Uses template strings (e.g., IP address: {artifact:*.cef.destinationAddress}).

This is how you make outputs readable and professional.

3. Best Practices

To make the most out of the Visual Playbook Editor, follow these tips:

a. Keep the Flow Linear (Where Possible)

• Try to keep blocks flowing from top to bottom or left to right.

• Avoid tangled, spaghetti-like diagrams.

• Group related logic together and use whitespace for readability.

A clean flow helps others (and future you) understand what’s happening.

b. Use Comments and Labels

• Add text labels to groups of blocks to explain what they do.

• Use the description fields in blocks for details.

• This is especially important for complex workflows with decisions and branches.

Documentation makes your automation maintainable and team-friendly.

c. Test with Simulated Data

Before deploying a playbook in production:

• Use test events or containers to simulate real scenarios.

• Watch how the playbook behaves in the Investigation Page.

• Check logs and outputs to ensure everything runs as expected.

Testing helps you avoid mistakes and surprises during live incidents.

Summary

Component	Purpose
Canvas Interface	Workspace to visually arrange and connect workflow blocks
Start Block	Defines when and why the playbook is triggered
Action Block	Executes tasks using assets and apps
Decision Block	Controls branching based on logic or data values
Prompt Block	Requests analyst input before continuing
Format Block	Creates clean, human-readable output messages
Best Practices	Keep layout clear, label your blocks, and test before going live

Visual Playbook Editor (Additional Content)

1. Saving and Publishing a Visual Playbook

After building or editing a playbook in the Visual Playbook Editor, it is not immediately usable until it is saved and published. This is a critical step, particularly for playbooks intended to run automatically or be reused by other users or playbooks.

• Save: Stores the current edits.

• Publish: Marks the version as active and available for automation or manual execution.

If a playbook is not published, it will not appear in:

• Playbook selectors

• Automation trigger options

• Manual execution menus

Clarifying Sentence:

“Once a playbook is built in the visual editor, you must save and then publish it to make it available for use or automation.”

Common Exam Question Style:

• True or False: An unpublished playbook will automatically run when a matching event is ingested.

• Correct answer: False

2. Where to Define Automatic vs. Manual Execution

Playbooks can be configured to run under specific conditions such as:

• Automatically (e.g., when an event is ingested)

• Manually (triggered by an analyst)

• On a schedule

The configuration for this is located in the Start Block of the Visual Playbook Editor.

Inside the Start Block settings, you can define:

• Trigger type (event ingestion, manual trigger, scheduled run)

• Optional filter conditions (e.g., container type, severity, label)

Clarifying Sentence:

“Trigger settings are configured in the Start Block where you define whether the playbook runs on ingestion, manually, or on schedule.”

Common Exam Question Style:

• Where do you specify whether a playbook should run automatically when a new event is received?

• Correct answer: In the Start Block

3. Decision Block Branching Capabilities

The Decision Block in the Visual Playbook Editor supports logical branching, allowing your automation to handle different scenarios.

• Each branch represents the result of a condition (e.g., True, False, or custom expression)

• While most commonly used for binary logic (Yes/No, match/no match), you can define multiple condition branches

• This is useful for multi-path decisioning, such as:

  • severity == high

  • severity == medium

  • severity == low

Clarifying Sentence:

“Decision blocks can support multiple branches, each representing a condition outcome, such as True/False or multi-condition scenarios.”

Common Exam Question Style:

• How many conditional branches can a decision block support in the Visual Playbook Editor?

• Correct answer: Multiple (based on condition outcomes)

Summary

Concept	Clarification
Save and Publish	Only published playbooks are executable or selectable
Trigger Definition	Configured inside the Start Block of the playbook
Decision Logic	Decision blocks can handle multi-branch conditional flows