> 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.12/configure-cortex-xsoar/playbooks/develop-your-playbook/task-3.-add-tasks/create-a-conditional-task.md). # Create a conditional task Conditional tasks are used for determining different paths for your playbook. For example, in a playbook for handling phishing emails, a conditional task can be used to check if an email contains suspicious attachments. If the attachment is identified as malicious, the playbook can automatically quarantine the email; otherwise, it can proceed to manual review by a security analyst. **Conditional task types** You can create different types of conditional tasks. * **Built-in**: Creates a logical statement using an entity from within the playbook. For example, in an access investigation playbook, you can determine that if the Asset ID of the person whose account was being accessed exists in a VIP list, set the incident severity to High. Otherwise, proceed as normal. * **Manual**: Creates a conditional task that must be manually resolved. For example, a security analyst is prompted to review and validate a suspicious file. The playbook task might involve instructions for the analyst to analyze the file, determine if it is malicious, and provide feedback or take specific actions based on their assessment. * **Ask**: Creates a single-question survey communication task, the answer to which determines how a playbook proceeds. For more details about ask tasks, see [Create a communication task](/cortex-xsoar-8-on-prem/8.12/configure-cortex-xsoar/playbooks/develop-your-playbook/task-3.-add-tasks/create-a-communication-task.md). * **Choose script**: Creates a conditional task based on the result of a script. For example, check if an IP address is internal or external using the `IsIPInRanges` script. When using a script, the inputs and outputs are generated by the automation script. How to create a conditional task 1. In a playbook, click **+ Create Task**. 2. Select the **Conditional** option. 3. In the **Task Name** field, type a meaningful name for the task that corresponds to the data you are collecting. 4. Select the relevant conditional task option. Some field configurations are required, and some are optional.
Built-in * Condition: Define one or more logical conditions for the task. * Details: Includes the following fields. * Tag the result with: Add a tag to the task result. You can use the tag to filter entries in the War Room. * Task description (Markdown supported): Provide a description of what this task does. You can enter objects from the context data in the description. For example, in a communication task, you can use the recipient’s email address. The value for the object is based on what appears in the context every time the task runs. * Timers: Includes the following fields. * Timer.start: The trigger for starting to send a message or survey to recipients. You can change this trigger or add a trigger for Timer.stop or Timer.pause. Select the trigger timer field from the drop down. * Add Trigger: You can add other trigger timer fields from the drop down. * Advanced: Determines whether this task uses the playbook default setting for Quiet Mode. When in Quiet Mode, tasks do not display inputs and outputs or extract indicators. Errors and warnings are still documented. You can turn Quiet Mode on or off at the task or playbook level. * On Error: Includes the following fields. * Number of retries: How many times the task should retry running if there is an error. Default is 0. * Retry interval (seconds): How long to wait between retries. Default is 30 seconds.
Manual * Manual task settings: Includes the following fields. * Default assignee: Assign an owner to this task. * Only the assignee can complete the task: Stop the playbook from proceeding until the task assignee completes the task. By default, in addition to the task assignee, the default administrator can also complete the blocked task. You can also block tasks until a user with an external email address completes the task. * Task SLA: Set the SLA in granularity of weeks, days, hours, and minutes. * Set task Reminder at: Set a reminder for the task in granularity of weeks, days, hours, and minutes. * Advanced: Determines whether this task uses the playbook default setting for Quiet Mode. When in Quiet Mode, tasks do not display inputs and outputs or extract indicators. Errors and warnings are still documented. You can turn Quiet Mode on or off at the task or playbook level. * Details: Includes the following fields. * Tag the result with: Add a tag to the task result. You can use the tag to filter entries in the War Room. * Task description (Markdown supported): Provide a description of what this task does. You can enter objects from the context data in the description. For example, in a communication task, you can use the recipient’s email address. The value for the object is based on what appears in the context every time the task runs. * Timers: Includes the following fields. * Timer.start: The trigger for starting to send a message or survey to recipients. You can change this trigger or add a trigger for Timer.stop or Timer.pause. Select the trigger timer field from the drop down. * Add Trigger: You can add other trigger timer fields from the drop down.
Ask * Message: Includes the following fields. * Ask by: The method for sending the message and survey. Options are: * Task (can always be completed directly in the Workplan) * Generated link (appears in the context data) * Email * To: The message and survey recipients. You can define by: * Selecting from a predefined drop down list. * Manually typing email addresses for users and/or external users. * Clicking the context icon to define recipients from a context data source. * CC of the email: A CC email address. * Subject of the email: The message subject that displays to message recipients. You can write the survey question in the subject field or in the message body field. * Message body: The text that displays in the body of the message. This field is optional, but if you don't write the survey question in the subject field, include it in the message body. This is a long-text field. * Reply options: Reply options are sent via the selected channels as options for an answer. * Require users to authenticate: Enable this option to have your SAML or AD authenticate the recipient before allowing them to answer. You must first set up an authentication integration instance and check Use this instance for external users authentication only in the integration instance settings. * Timing: Includes the following fields. * Retry interval (minutes): Determines the wait time between each execution of a command. For example, the frequency (in minutes) that a message and survey are resent to recipients before the response is received. * Number of retries: Determines how many times a command attempts to run before generating an error. For example, the maximum number of times a message is sent. If a reply is received, no additional retry messages will be sent. * Task SLA: Set the SLA in granularity of weeks, days, and hours. * Set task Reminder at: Set a task reminder in granularity of weeks, days, and hours. * Complete automatically if SLA passed without a reply: Select this checkbox to complete the task if the SLA is breached before a reply is received. You can select yes or no. * Advanced: Includes the following fields. * Using: Choose which integration instance will execute the command, or leave empty to use all integration instances. * Extend context: Append the extracted results of the action to the context. For example, "newContextKey1=path1::newContextKey2=path2" returns "\\\[path1:'aaa',path2: 'bbb', newContexKey1: 'aaa',newContextKey2:'bbb'\\]" * Ignore outputs: If set to true, will not store outputs into the context (besides the extended outputs). * Execution timeout (seconds): Sets the command execution timeout in seconds. * Indicator Extraction mode: Choose when to extract indicators: * None: Do not perform indicator extraction * Inline: Before other playbook tasks * Out of band: While other tasks are running * Mark results as note * Mark results as evidence * Run without a worker * Skip this branch if this script/playbook is unavailable * Quiet Mode: When in quiet mode, tasks do not display inputs and outputs or extract indicators. Errors and warnings are still documented. You can turn quiet mode on or off at the task or playbook level. * Details: Includes the following fields. * Tag the result with: Add a tag to the task result. You can use the tag to filter entries in the War Room. * Task description (Markdown supported): Provide a description of what this task does. You can enter objects from the context data in the description. For example, in a communication task, you can use the recipient’s email address. The value for the object is based on what appears in the context every time the task runs.
Choose script From a drop down list, select a script for the playbook to run. In the following tabs you can set: * Inputs: Each script has its own set of input arguments (or none). You can set each argument to a specific value (by typing directly on the line under the argument name) or you can click the curly brackets to define a source field to populate the argument. * Outputs: Each script has its own set of output arguments (or none). * Mapping: Map the output from a playbook task directly to an incident field. The value for an output key populates the specified field per incident. This is a good alternative to using a task with a set incident command. The output value is dynamic and is derived from the context at the time that the task is processed. As a result, parallel tasks that are based on the same output may return inconsistent results. 1. In the Mapping tab, click Add custom output mapping. 2. Under Outputs, select the output parameter whose output you want to map. Click the curly brackets to see a list of the output parameters available from the automation. 3. Under Field to fill, select the field that you want to populate with the output. 4. Click Save. * Advanced: Includes the following fields. * Using: Choose which integration instance will execute the command, or leave empty to use all integration instances. * Extend context: Append the extracted results of the action to the context. For example, "newContextKey1=path1::newContextKey2=path2" returns "\\\[path1:'aaa',path2: 'bbb', newContexKey1: 'aaa',newContextKey2:'bbb'\\]" * Ignore outputs: If set to true, will not store outputs into the context (besides the extended outputs). * Execution timeout (seconds): Sets the command execution timeout in seconds. * Indicator Extraction mode: Choose when to extract indicators: * None: Do not perform indicator extraction * Inline: Before other playbook tasks * Out of band: While other tasks are running * Mark results as note * Mark results as evidence * Run without a worker * Skip this branch if this script/playbook is unavailable * Quiet Mode: When in quiet mode, tasks do not display inputs and outputs or extract indicators. Errors and warnings are still documented. You can turn quiet mode on or off at the task or playbook level. * Details: Includes the following fields. * Tag the result with: Add a tag to the task result. You can use the tag to filter entries in the War Room. * Task description (Markdown supported): Provide a description of what this task does. You can enter objects from the context data in the description. For example, in a communication task, you can use the recipient’s email address. The value for the object is based on what appears in the context every time the task runs. * Timers: Includes the following fields. * Timer.start: The trigger for starting to send a message or survey to recipients. You can change this trigger or add a trigger for Timer.stop or Timer.pause. Select the trigger timer field from the drop down. * Add Trigger: You can add other trigger timer fields from the drop down. * On Error: Includes the following fields. * Number of retries: How many times the task should retry running if there is an error. Default is 0. * Retry interval (seconds): How long to wait between retries. Default is 30 seconds. * Error handling: How the task should behave if there is an error. Options are: * Stop * Continue * Continue on error path(s) This option configures the task to handle potential errors that may occur when executing the current task's script.
5. Click Save. --- # 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.12/configure-cortex-xsoar/playbooks/develop-your-playbook/task-3.-add-tasks/create-a-conditional-task.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.