Learn about incident context data, how it is stored in Cortex XSOAR, and how to access it.
The context of an incident is a map (dictionary) that stores structured results from integration commands and automation scripts. The context keys are strings and the values can be strings, numbers, maps, and arrays.
You can use context data to:
Pass data between playbook tasks.
Capture important structured data from automations and display the data in the incident summary.
The Set automation, part of the Common Scripts content pack, enables you to set a value in context under a specific key.
Note
All incident data stored in incident fields is also stored in the context data. In most cases, however, not all context data is stored in incident fields. Incident fields represent a subset of the total incident data.
Search Context Data
To view context data from within an incident, click on the menu and select Context Data from the drop-down. In the Context Data pane, you can use jQuery to search within the JSON for specific items and expand nested keys.
Search examples:
${c}
finds the value of the object c.${HelloWorld.Domain(val.domain == 'example.com')}
shows the full object for the example.com domain, as stored in the context data by the domain command that is part of the HelloWorld integration.${HelloWorld.Domain(val.domain == 'example.com').registrar}
shows the registrar for the example.com domain, as stored in the context data by the domain command that is part of the HelloWorld integration.${HelloWorld.Alert(val.alert_status === "ACTIVE").alert_id}
fetches the HelloWorld.Alert.alert_id of all ACTIVE alerts.
You can also write jQuery scripts using complex logic to access, aggregate, and change context data. For more information, see Cortex XSOAR Transform Language (commonly referred to as DT).
Playbooks
When configuring playbook tasks, you can use information stored in the incident context as task inputs and/or outputs. You can, optionally, apply filters and transformers to context data before using the data in playbook tasks.
You can also view context data while running a playbook using the debugger. Since context data may be updated during a playbook run, you can set a breakpoint to view the context data after a specific task, which can be useful for designing and troubleshooting playbooks.
By default, context data for sub-playbooks is stored in a separate context key. When a task in a main playbook accesses context data, it does not have direct access to sub-playbook data. When a task in a sub-playbook accesses context data, it does not have direct access to the main playbook data. If, however, the sub-playbook has been configured to share globally, the sub-playbook context data is available to the main playbook and vice versa.
Note
Generic polling does not work if a playbookâs context data is shared globally.
Integrations
When an incident is created, the incident data is stored in the context data, under the incident
key. When an investigation is opened and integration commands are run, the data returned from those commands is also stored as context data, outside of the main incident
key. In the example below, you can see the original incident data stored under the incident
key and the data from the integrations, such as Wildfire, stored separately within the context data under their own keys.
For more information on how to use context data, including examples and use cases, see Context and Outputs.