> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsoar-8-on-prem/8.14/configure-cortex-xsoar/playbooks/customize-your-playbook/playbook-polling.md). # Playbook polling When working with third-party products (such as detonation, scan, search, and other third-party products) you may need to wait for a process to finish on the remote host before continuing. In these cases, the playbook should stop and wait for the process to complete on the third-party product, and continue when it is done. Integrations or automations may not be able to do this due to hardware limitations. Generally, polling is used in the following scenarios: * File detonation in a sandbox * URL detonation * Queries that take a long time to complete To use polling, Cortex XSOAR comes out-of-the-box with the **GenericPolling** playbook, which periodically polls the status of a process being executed on a remote host, and when the host returns that the process execution is done, the playbook finishes execution. For more information about using this playbook, see [Generic Polling](https://xsoar.pan.dev/docs/playbooks/generic-polling). The **GenericPolling** playbook is used as a sub-playbook to block the execution of the main playbook until the remote action is complete. There are a number of playbooks that use the **GenericPolling** playbook that come out-of-the-box or installed from a content pack, such as: * [Contex Polling - Generic](https://xsoar.pan.dev/docs/reference/playbooks/context-polling---generic): Polls a context key to check if a specific value exists. * [Field Polling - Generic](https://xsoar.pan.dev/docs/reference/playbooks/field-polling---generic): Polls a field to check if a specific value exists. * [Scan Site - Nexpose](https://xsoar.pan.dev/docs/reference/playbooks/scan-site-nexpose): Scans according to asset IP addresses or host names from Rapid7 Nexpose, and waits for the scan to finish by polling the scan status in pre-defined intervals. See [this video](https://live.paloaltonetworks.com/t5/cortex-xsoar-how-to-videos/cortex-xsoar-8-how-to-video-generic-polling/ta-p/565892) for more information on how to use generic polling in Cortex XSOAR. {% hint style="warning" %} ### Prerequisite You need to use the **GenericPolling** playbook as a sub-playbook in a main playbook, such as **Detonate File - JoeSecurity**. The main playbook should follow this structure: 1. **Start Command**: The task contains a command that fetches the initial state of the process and saves it to context. This command starts the process that should be polled. For example: Detonation: Submits a sample for analysis (detonated as part of the analysis), using the **`joe-analysis-submit-sample`** command. Scan: Starts a scan for specified asset IP addresses and host names using the **`nexpose-start-assets-scan`** command. Search: Searches in QRadar using AQL using the **`qradar-searches`** command. 2. **Polling Command**: The task contains the **GenericPolling** sub-playbook that polls for an answer. For example: * Detonation: After the file is submitted to Joe Security, the playbook polls for specific information for analysis, such as ID, status, comments, errors, SHA-256 hash details. * Scan: After the scan runs in Nexpose, using the playbook polls for scan information such as the scan type, the number of assets found, the scan ID, and other information. * Search: The playbook runs the **`qradar-get-search`** to poll for the search ID and status. 3. **Results Task**: Returns the results of the operation. The task contains the results that were polled, which are added to context. For example, after polling JoeSecurity, the results are added to context. For information about the **GenericPolling** playbook inputs such as Ids, Interval, and dt, see [Playbook inputs](https://xsoar.pan.dev/docs/reference/playbooks/generic-polling#playbook-inputs). {% endhint %} This generic polling example uses the **Detonate File - JoeSecurity** playbook from the **Joe Security** content pack. The **Detonate File - JoeSecurity** playbook detonates one or more files using the [Joe Security](https://xsoar.pan.dev/docs/reference/integrations/joe-security) integration and returns relevant reports to the War Room and file reputations to the context data. 1. If you have not done so, go to Marketplace and download the Joe Security content pack. 2. Go to **Playbooks** and search for **Detonate File - JoeSecurity**. 3. Open the **JoeSecurity Upload File** task. This task uses the **`joe-analysis-submit-sample`** command, which starts a new analysis of a file in Joe Security. This is the **Start** command. 4. Open the **GenericPolling** task. This is the **Polling** command. * **Ids**: Returns a list of **`Joe.Analysis.ID`**’s to poll. * **PollingCommandName:** The **`joe-analysis-info`** command returns information for a specified analysis, such as status, MD5, SHA256, vendor. * **PollingCommandArgName:** The **`webid`** argument name of the polling command. * **dt**: The filter for polling. This is defined as **`Joe.Analysis(val.Status!==’finished’).ID`**. **`Joe.Analysis`**: The object to return. **`(val.Status !==‘finished’).ID`** Gets the object that has a status other than ‘finished’, and then gets its ID field. The polling is done only when the result is **`finished`**. When finished, the **`dt`** filter returns an empty result, which triggers the playbook to stop running. You can change the **`Status`** to: **`starting`**, **`running`**, or **`finished`**. ![](/files/zZ0oXugxU1rDoYRrfCbl) 5. Open the **JoeSecurity Get Info** task. The **`joe-analysis-info`** command returns details of the IDs that have finished polling. This is the **Results** task. 6. Open the **Set Context** task. The context path to store the poll results is **`Joe.Analysis`**. #### **GenericPolling playbook limitations** The **GenericPolling** playbook has the following limitations. * **Global context** is not supported. Global context outputs enable receiving information from multiple integrated products when executing playbooks and commands. * It does not run from the **Playground**. * It uses the **ScheduleGenericPolling** script, which must support a list argument. ![](/files/QTmZLoFZ3UhxiXQkWirk) #### **Troubleshoot playbook polling** The following are common generic polling issues and the recommended ways to deal with them. * The playbook is “stuck” on **`Waiting for polling to complete`**. As generic polling schedules tasks are outside the context of the playbook (not visible in the playbook run), errors may appear only in the War Room. Go to the War Room for the incident and check for errors or warnings related to GenericPolling tasks. * The GenericPolling task completes but the status has still not "finished". If the timeout is reached, the playbook successfully finishes even if there are items that did not complete. Try increasing the timeout value for the GenericPolling task. * The integration returns an ID not found error when running from the GenericPolling sub-playbook, but when running manually, it finishes successfully. Some products cannot handle consecutive requests to query an action status right after the request to perform the action. After you initiate the action, try adding a Sleep task before calling the GenericPolling sub-playbook. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xsoar-8-on-prem/8.14/configure-cortex-xsoar/playbooks/customize-your-playbook/playbook-polling.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.