> 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-agentix/detect-investigate-and-respond-to-threats/investigation-and-response/investigate-issues/issue-investigation-actions/update-issue-fields.md).

# Update issue fields

You can update issue fields by running the `setIssue` and `setIssueStatus` commands in the CLI, in a script, or a playbook task.

* **`setIssue`:** Sets values for specific issue fields. The supported fields are presented in the list of arguments.

  Examples of the setIssue command in the CLI

  The following examples show how to run the `setIssue` command in the CLI. You can run CLI commands in the **War Room**. When you start typing the CLI provides the available options and if you select an enum field, the CLI provides the available values.

  * To change the issue severity to `high`, run

    ```programlisting
    !setIssue severity=high
    ```
  * To change the issue severity to `high` and star the issue, run

    ```programlisting
    !setIssue severity=high starred=true
    ```
* **`setIssueStatus`:** Sets the status or resolution value for an issue. This command supports the `status` argument, which presents a list of status and resolution type values. The selected status is set in the `custom_status` field.

  If you specify a resolution status, the issue is closed and the `resolution_status` and `closeReason` fields are updated to the same value as the `custom_status` field. If you specify a New, Reopened, or Under Investigation status, the issue remains open and the `resolution_status` and `closeReason` fields are empty.

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Tip</h3><p>You can create custom issue statuses and resolution reasons, and use the <code>setIssueStatus</code> command to set these custom statuses for issues.</p><p>For example, when a user starts investigating an issue, the issue status is automatically changed from <strong>New</strong> to <strong>Under Investigation</strong>. In some cases, it is useful to create an interim status, such as <strong>Triage</strong>. After you create the custom status, the new status will be available for selection. To create a custom status, follow the instructions in <a href="/spaces/ocwvgxtzkvBHMLbPsZuG/pages/Vq3PlNoZkz8JAY7lomGy">Create custom case statuses and resolution reasons</a>.</p></div>

  Examples of using the setIssueStatus command in the CLI

  The following examples show how to run the `setIssueStatus` command in the CLI. You can run CLI commands in the **War Room**. When you start typing, the CLI provides the available options and if you select an enum field, the CLI provides the available values.

  * To change the issue status to `Resolved - Known Issue`, run

    ```programlisting
    !setIssueStatus status="Resolved - Known Issue"
    ```
  * To change the issue status to custom status `Triage`, run

    ```programlisting
    !setIssueStatus status=Triage
    ```

    <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>You must create a custom status before you can select it.</p></div>

  Example of using the setIssueStatus command in a playbook

  The following example shows how the `setIssueStatus` command can be used in a playbook task. In this example, the task sets a custom issue status (Triage). The custom issue status was created before setting up the playbook.

  ![setAlertStatus\_playbook\_example.png](/files/QqoOOwSE35DqP9CW8zCy)

### **Use issue timer field commands manually in the CLI**

You can manage the timers for a specific issue by running commands manually in the CLI. By running CLI command you can to manage timers on a more granular level within specific issues when the need arises. For example, for a high severity issue you might need to decrease the response time.

<details>

<summary>Set timer fields</summary>

Use the `setIssue` command to set a specific issue due date, or to set a specific timer field in an issue. If you add the `sla` parameter to the command, it sets the time for the issue's due date. If you also add the `slaField` you set the timer for the issue field.

Example 58.

To change the **Time to Assignment** field target to 30 minutes in the current issue, run the following command:

```programlisting
!setIssue sla=30 slaField=timetoassignment
```

To change the timer to February 1, 2024, at 11.12 am, run the following command:

```programlisting
!setIssue sla=2024-02-01T11:12
```

{% hint style="info" %}

### Note

When defining the values for the `slaField` use the machine name for the field, which is lowercase and without spaces. You can check the machine name by editing the issue field.
{% endhint %}

</details>

<details>

<summary>Start or stop timer fields</summary>

Run the following commands in the CLI:

| Command      | Description                                                                                                                                                                                                                                                                                                                                                                                            |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `startTimer` | <p>Starts the timer.</p><p>This command can also be used to restart a paused timer.</p><p>\*\*Example 59. \*\*null<br><br></p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong></p><p>Timer fields are not started automatically when an issue is created unless run in a playbook.</p></div>                                                |
| `pauseTimer` | <p>Pauses the timer.</p><p>Use this command when a timer field has already started.</p><p>\*\*Example 60. \*\*null<br><br></p>                                                                                                                                                                                                                                                                         |
| `stopTimer`  | <p>Stops the timer.</p><p>\*\*Example 61. \*\*null<br><br></p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong></p><p>After a timer field is stopped, before you can start the timer again you must reset the timer using the <strong>resetTimer</strong> command.</p><p>Timers are automatically stopped when an issue is closed.</p></div> |
| `resetTimer` | <p>Clears all fields for the timer.</p><p>This command must be used before restarting a timer that was stopped.</p><p>\*\*Example 62. \*\*null<br><br></p>                                                                                                                                                                                                                                             |

{% hint style="info" %}

### Note

When running commands in the CLI, you can specify the `alertID` to change the timer for a different issue.
{% endhint %}

</details>


---

# 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-agentix/detect-investigate-and-respond-to-threats/investigation-and-response/investigate-issues/issue-investigation-actions/update-issue-fields.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.
