> 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-xdr-5.x/detect-investigate-and-respond-to-threats/investigate-and-respond-to-cases/automation/playbooks/build-your-playbook/add-objects-from-the-task-library/add-manual-tasks-and-blank-tasks/create-a-conditional-task.md).

# Create a conditional task

Conditional tasks determine the path through a playbook.

For example, a phishing playbook can check email attachments. It can quarantine malicious emails or route others for manual review.

### Conditional task types

Create one of the following conditional task types:

* **Built-in** — Create a logical statement from an entity in the playbook. For example, set severity to High when an Asset ID belongs to a VIP.
* **Manual** — Require an analyst to resolve the condition manually. For example, an analyst can validate whether a suspicious file is malicious.
* **Ask** — Send a single-question survey. The answer determines the next path.
* **Choose script** — Use script results to determine the next path. For example, use `IsIPInRanges` to check whether an IP is internal.

Script inputs and outputs are generated by the automation script.

### Create a conditional task

{% stepper %}
{% step %}
From the **Task Library** pane, select a task.

For example, select **Blank Task**.
{% endstep %}

{% step %}
In the **Task Details** pane, select the **Conditional** task type.
{% endstep %}

{% step %}
Enter a meaningful value in **Task Name**.

Use a name that describes the data you collect.
{% endstep %}

{% step %}
Select the required conditional task option.

Some field configurations are required. Others are optional.

<details>

<summary>Built-in</summary>

* **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.
* **Advanced**: Includes the following fields:&#x20;
  * **Register as case timeline record**: If enabled, the results of the task execution appear as a record in the case timeline. If enabled, you must enter a **Record name.** You have the option of adding an **Effective time**, **Description**, **Tags**, and marking the record as evidence and adding an evidence comment.\
    NOTE: Only enter an **Effective time** if you want the same exact time recorded every time the playbook task executes.
  * **Quiet Mode:** 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.

</details>

<details>

<summary>Manual</summary>

* 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**:&#x20;
  * **Register as case timeline record**: If enabled, the results of the task execution appear as a record in the case timeline. If enabled, you must enter a **Record name.** You have the option of adding an **Effective time**, **Description**, **Tags**, and marking the record as evidence and adding an evidence comment.\
    NOTE: Only enter an **Effective time** if you want the same exact time recorded every time the playbook task executes.
  * **Quiet Mode:** 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.

</details>

<details>

<summary>Ask</summary>

* 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 the 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.
  * **Register as case timeline record**: If enabled, the results of the task execution appear as a record in the case timeline. If enabled, you must enter a **Record name.** You have the option of adding an **Effective time**, **Description**, **Tags**, and marking the record as evidence and adding an evidence comment.\
    NOTE: Only enter an **Effective time** if you want the same exact time recorded every time the playbook task executes.
  * **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)**: Describe 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.

</details>

<details>

<summary>Choose script</summary>

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 issue field.

  The value for an output key populates the specified field per issue. This is a good alternative to using a task with a `setIssue` 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.
  * Register as case timeline record: If enabled, the results of the task execution appear as a record in the case timeline. If enabled, you must enter a Record name. You have the option of adding an Effective time, Description, Tags, and marking the record as evidence and adding an evidence comment.\
    NOTE: Only enter an Effective time if you want the same exact time recorded every time the playbook task executes.
  * 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.
* 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.

</details>
{% endstep %}

{% step %}
Select **Save**.

The task is added to the playbook editor.\
If you select a system script, the task logo shows **Builtin.**
{% endstep %}

{% step %}
Connect tasks in their logical order by dragging a wire between them.
{% endstep %}

{% step %}
Save the playbook.
{% endstep %}
{% endstepper %}


---

# 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-xdr-5.x/detect-investigate-and-respond-to-threats/investigate-and-respond-to-cases/automation/playbooks/build-your-playbook/add-objects-from-the-task-library/add-manual-tasks-and-blank-tasks/create-a-conditional-task.md?ask=<question>&goal=<endgoal>
```

`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.
