The Cortex XSOAR Playbook Debugger enables you to troubleshoot playbooks and test multiple scenarios.
The Cortex XSOAR playbook debugger enables you to build and troubleshoot playbooks, by helping you find tasks that might fail and by testing different conditions, branches, and input and output options. Common use cases include:
- Playbook development - test and improve playbooks as you build them.
- Proof of concept - begin to create and test playbooks even before all integrations are in place, by manually providing inputs and outputs as needed.
- Error troubleshooting - use the debugger to find and fix issues if a playbook stops on an error.
- Explore Marketplace playbooks - install content packs and use the debugger to see whether the included playbooks are relevant for your use case.
Building a playbook is an iterative process. The debugger provides a test environment where you can make changes to data and playbook logic and view the results in real time. You have the opportunity to see exactly what is written to context at each step and which indicators are extracted.
The debugger uses test data to execute the playbook, so you can see what your expected results would be. There are two options for test data.
- New Mock Incident- by default, the debugger runs using an empty mock incident. An empty mock incident is useful to test simple functionality, such as a playbook that does simple tasks like parsing inputs.
- Playground- you can load the contents of the playground as test data, enabling you to use uploaded files and custom context data for testing purposes.
- Existing Incident- you can select an existing Cortex XSOAR incident. For example, when debugging a phishing playbook, you might want to use an existing phishing incident that came from the mail listener integration. Using an existing incident in the debugger does not change the original incident.If you need to use event data from third party software that is not yet set up as an integration, you can import a JSON file into Cortex XSOAR through the mapping feature and create an incident that can then be used as test data.You can use a file attachment for your test data by adding the file to an incident and selecting the incident or by uploading the file to the playground and using the playground as test data.
Inputs and outputs
The debugger enables you to temporarily override inputs and outputs for a playbook run and to view the results in real time. When you override an input or output in the debugger, the change is saved only in the debugger view and only for the user who made the change. If, after testing, you decide to keep the temporary changes you made, and apply them permanently to the playbook for all users, you have to cancel the override and edit the task. Tasks can be edited directly in the debugger or outside of the debugger using the standard playbook editing options.
Breakpoints are used to pause playbook execution before a specific task. When the playbook is paused, the Debugger Panel displays the current state of context data, indicators, and task information.
At the breakpoint, you can override inputs and outputs to see how changes affect playbook execution.
In addition, conditional breakpoints set conditions for the playbook to proceed. The playbook only pauses if your condition is met, letting you manipulate data to see how different scenarios impact how the playbook runs. For example, you can set a conditional breakpoint to pause the playbook when a phishing incident targets a member of a VIP asset list. If there are no VIPs in this incident, the execution will not pause. If there is a VIP in the incident, you can check that the member was properly identified by the playbook task.
For testing purposes, you might not want to close a port in a firewall, delete an email, or send a notification to a manager. For this purpose, you can skip a task. In other cases, you might skip a task where the integration has not yet been configured. By skipping a task and overriding the output, you can provide the data necessary to complete the playbook run. When you skip a conditional task, you can choose which branch runs after the skipped task, enabling you to test different outcomes for multiple branches.
Recommended For You
Recommended videos not found.