Handle Errors in a Playbook - Administrator Guide - 6.8 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Administrator Guide

Product
Cortex XSOAR
Version
6.8
Creation date
2022-09-28
Last date published
2024-03-21
End_of_Life
EoL
Category
Administrator Guide
Abstract

When defining a task, you can decide if the playbook continues, stops, or continues on an error path .

You can determine how the playbook behaves if there are automation errors during execution.

When defining a standard task that uses an automation or a conditional task that uses an automation, you can define how a playbook task continues by selecting one of the following options:

  • Stop: The playbook stops, if the task errors during execution. For example, if the task requires a manual review, you may want the playbook to stop until completion.

  • Continue: The playbook continues to execute if the task errors. For example, the playbook task requires EWS but is not needed.

  • Continue on error path: If a task errors, the playbook continues on an error path. You have the option to create a separate, standard path or use a separate error path, which can handle all errors.

    The error path may be useful if you want to take action on an error, like clean-up, retry, etc. You may also want to handle errors in different ways. For example, in case of a quota expired error you may want to retry in 1 minute, but if you receive an internal error 500, you may want to stop the playbook.

    You may want to create a separate path when an analyst manually reviews the incident and research is needed outside Cortex XSOAR. Once an analysis is complete, you can add a task to consider escalating to a customer and, if so, generate a report which can be attached to a ticket system such as Jira or ServiceNow.

    Instead of a playbook waiting on manual input, which displays an error state, such as missing an argument in a script, you can add a separate path for these kinds of issues.

Note

Use the GetErrorsFromEntry automation (part of the Common Scripts Pack) to check whether the given entry returns an error and returns an error message. For example, when using the automation in a playbook, you can fetch the error message from a given task, such as a runtime error. You can then add a step in the playbook flow to send those error messages to the relevant stakeholder through slack, email, opening a Jira ticket, etc.

When errors are created, they are added to context under task id.error.

  1. In a playbook, edit or create a new task by clicking +.

  2. Select one of the task types you want to create or edit.

    Note

    Standard tasks require an automation. For Conditional tasks you need to add an automation. For more information about tasks, see Playbook Tasks.

  3. For new tasks, in the Task Name field, type a meaningful name for the task that corresponds to the data you are collecting.

  4. Click the On Error tab.

  5. In the Number of retries field, type the number of times the tasks attempts to run before generating an error.

  6. In the Retry Interval (seconds) field, type the wait time between retrying the task.

  7. In the Error Handling field, select one of the following:

    • Stop

    • Continue

    • Continue on error path(s)

  8. Click Save.

    When adding the connector to the task, a dialog box appears, which enables you to select one of the following paths:

    • Standard Path: When adding a task to this path, it executes without any exceptions.

    • Error Path: When adding a task to this path, it executes where the source task errors during execution.

  9. If you select the Standard Path, the task continues on this path and executes without exceptions.

  10. If you select Error path, if the task errors, the playbook continues with this path.