Get ready to level up your security automation! We're thrilled to announce two powerful new features in Chronicle SOAR: Playbook Loops and Action Retries. These much-anticipated updates are designed to make your playbooks more dynamic, resilient, and efficient, reducing the need for duplicate playbooks and simplifying complex logic.

Introducing Playbook Loops: Automate Repetitive Tasks with Ease

You asked, and we listened! The ability to loop through actions in a playbook has been a popular feature request, and now it's here to revolutionize your workflows.

What are Playbook Loops?

Playbook Loops allow you to run one or more actions multiple times. Instead of building separate playbook branches for each item, you can now create a single, elegant "For Each" loop that iterates through different types of data. The initial release supports two main loop types:

• Entities: Iterate through all (or a selected subset) of the entities linked to an alert.
• List: Iterate through items within a custom list, with the ability to define your preferred delimiter.

Playbook Loops are a key part of the playbook toolkit, enabling you to run actions multiple times.

Using Loop Placeholders

To give you precise access to the current item within a loop, a new "Loops" placeholder category is now available within the steps of a loop. This allows you to dynamically use data from the current iteration.

• Loop.Entity.[field_name] provides the data of the current entity in an entities loop.
• Loop.Item provides the current item as a string in a list loop.
• Loop.Index indicates the current loop iteration number, starting from 1.

The new "Loops" placeholder category gives you access to the current item's data within a loop.

Iteration Limits and Error Handling

Each loop has a maximum of 100 iterations. If this limit is reached, the loop terminates, and a

skipped_items field in the JSON result will detail which items were not processed. Additionally, if the iteration context exceeds 15MB, the loop will not execute and the "start loop" step will fail.

Short Tutorial: Creating Your First Loop

1. From the playbook editor, click on
   "+ Open Step Selection" and choose the "Loops" tab.
2. Select the
   "For Each Loop" option.
3. Double-click the start loop step to configure the loop type and what it will iterate over.
4. Drag and drop the actions you want to perform inside the loop, using the new placeholders to reference the current item.

Configuring a "For Each Loop" in the playbook editor is straightforward.

Link to documentation 

Never Let a Temporary Glitch Stop You: Action Retries

Playbooks are the heart of your automated response, and now they're more robust than ever with the new Action Retries functionality.

What are Action Retries?

Automated actions in playbooks can sometimes fail due to temporary problems like network outages or API rate limits. To make your playbooks more resilient, you can now configure individual actions to automatically retry if they encounter such failures. This feature helps your playbooks recover from temporary issues without manual intervention.

Retries apply to standard playbook actions like enrichment, containment, or notifications. They are not attempted for actions that time out, and they don't apply to flow control actions like conditions or blocks.

How to Configure Action Retries

In the action's settings, you can now specify:

• Number of retries: Enter how many times the action should attempt to rerun if it fails.
• Delay between retries: Define the delay in seconds, minutes, or hours between each retry attempt.

You can also decide what happens in the "If step fails" section, in the event that the action ultimately fails after all retry attempts:

• Stop playbook: The playbook execution stops.
• Skip step: The playbook continues to the next step.

The action retry settings allow for granular control over playbook resilience.

How Retries Appear During Playbook Execution

When a playbook step with retries is running, you'll see specific statuses and messages indicating the progress:

• If an action fails, its status temporarily changes to Waiting for next retry.
• If the action succeeds after one or more retries, its final status will indicate success and the number of retries (e.g., Completed after 2 retries).
• If the action fails after all attempts, its final status will show the failure and the number of retries (e.g., Failed after 3 retries).

Link to documentation