Playbook Testing and Task Node Re-runs

LAST UPDATED: MARCH 13, 2025

Prerequisites

PREREQUISITES

General knowledge of:

• Preprocessing Playbook

• Investigation Playbook

• Dynamic Data Selection (Playbook Data)

• Jinja Basics (Assigning Variables and Conditional Statements)

• Conditional Task

When testing a playbook, it is important to understand the difference between re-running a task and re-testing the entire playbook:

• Re-running a task will not update Playbook Data or propagate new return data to downstream tasks.

• Only re-testing the playbook applies updated configurations in subsequent executions.

Testing a Playbook

EXAMPLE Consider the following playbook:

1. Configure DF Task 1 to return "alpha."

   

2. Configure the conditional task with two branches: Branch 1 and Branch 2.

   

3. Configure the conditional task to evaluate DF Task 1's return data and route execution to Branch 1 if the value is "alpha", otherwise route to Branch 2.

   CODE

   {% set x = PlaybookData | jsonpath('$.["DF Task 1"].returnData') %}
   
   {% if x == 'alpha' %}
       Branch 1
   {% else %}
       Branch 2
   {% endif %}

   

4. Click on the button.

   

5. Click on the Run Test button.

   

6. Verify that execution followed Branch 1.

   

7. Click on the icon for DF Task 1 to verify the output.

   

8. Click on the icon for Conditional Task to confirm that "alpha" was indeed read.

   

Rerunning a Task Node

Continuing the example from above, re-running a task node executes only that task without resuming the playbook.

1. Re-configure DF Task 1 to return "beta."

   

2. Re-run DF Task 1.

   

   

3. Observe the return data.

   

4. Observe that DF Task 1 executed twice, with no changes occurring downstream, as indicated by the unchanged task icons.

   

OBSERVATION

According to the conditional logic defined here, one might expect DF Task 3 to have executed. However, this did not occur – no other task executed apart from DF Task 1.

5. Re-examine DF Task 1's return data within the conditional task.

   

INSIGHTS

• The new return data did not propagate to downstream tasks.

  • The re-run DF Task 1 task did not update the Playbook Data.

• The user will see that the return data of DF Task 1 remains "alpha" despite being configured to return "beta" here.

6. Re-run the conditional task.

   

   

7. Re-examine DF Task 1's return data from the conditional task's perspective.

   

OBSERVATION

DF Task 1's return data still remains "alpha" unchanged, despite being configured to return "beta" here and re-running the conditional task.

8. Observe that both DF Task 1 and Conditional Task executed twice, with no changes to the downstream execution path.

   

9. Stop the test and re-test the playbook.

   

   

   

10. Verify that execution followed Branch 2.

    

11. Click on the icon for DF Task 1 to verify that it outputs "beta."

    

12. Click on the icon for Conditional Task, to confirm that "beta" was indeed read.

LESSONS

• Playbook Data remains unchanged for all nodes after re-running a task.

• Re-testing the playbook applies updated task configurations in subsequent executions.

Re-running a Task Node with Stop on Error Enabled

For a task with Stop on Error enabled, the button re-executes the failed task and resumes playbook execution from that point.

Rerun Button Availability in the Configuration Module

When testing playbooks in the Configuration module, the button remains available even after a successful () execution.

Understanding this behavior helps users use the button effectively for Stop on Error tasks, avoiding unintended task repetition. This is important for downstream task nodes, such as those creating Jira tickets or sending emails, where re-execution may result in unnecessary duplicates or repeated actions.

Rerun Button Availability in the Incident Workspace

In contrast to the Configuration module, the Incident Workspace displays the button only for errored tasks, and it disappears after being clicked.

READER NOTE

The button’s availability depends on the selected execution record in the Playbook Task Details dropdown.

• ABSENT in a successfully re-executed () task.

  

• PRESENT in the original error () execution.

  

  • CAUTION Re-executing may cause unintended duplicates or repeated actions in downstream tasks.

Example - New Execution Entry Generated After Re-Running an Errored Task

Re-running an errored task creates a new entry in the task execution log (dropdown) for the current task node and all subsequent rerun task nodes.

EXAMPLE

1 - Error: The initially failed task. The button is available.

2 - Done (Rerun 1 - Error): The successfully re-executed () task after clicking on the button in the 1 - Error execution.

3 - Done (Rerun 1 - Error): Returning to the 1 - Error execution and clicking on the button creates a third entry in the execution log.