> 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/investigate-issues/issue-investigation-actions/update-issue-fields.md).

# Update issue fields

Update fields associated with an issue.

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

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.

### setIssue

Use the `setIssue` command to update the values of standard and custom issue fields, such as severity, tags, or custom drop downs. The supported fields are presented in the list of arguments.

**CLI example**

You can change the issue severity to `high`:

```
!setIssue severity=high
```

{% hint style="warning" %}

### Important

Do not use the `setIssue` command to assign an owner to an issue. The legacy `owner` field is deprecated and will not update the issue assignee in Cortex XDR. To assign or change the user assigned to an issue, use the `!core-update-issue` command.
{% endhint %}

### core-update-issue

Use the `core-update-issue` command for system-level updates, including assigning users and linking issues to cases.

* **Assign an issue**\
  You can assign an issue to an analyst using the analyst's email address.\
  CLI example\
  &#x20;`!core-update-issue ids=${issue.id} assigned_user_mail="analyst@abc.com"`
* **Link an issue**\
  You can link an unassigned issue to an existing case.\
  CLI example\
  `!core-update-issue ids=${issue.id} case_id="12345"`

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

{% hint style="info" %}
Tip

You can create custom issue statuses and resolution reasons, and use the `setIssueStatus` command to set these custom statuses for issues.

For example, when a user starts investigating an issue, the issue status is automatically changed from **New** to **Under Investigation**. In some cases, it is useful to create an interim status, such as **Triage**. After you create the custom status, the new status will be available for selection. To create a custom status, follow the instructions in Create custom case statuses and resolution reasons.
{% endhint %}

#### 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"><p>Note</p><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](https://2127116976-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FcyIgISZgANJYkmLlnwdK%2Fuploads%2Fgit-blob-d88247f7da993ba4e3ecf486adac970efc1db542%2F0433f525106cdb9443fce93fd8fb967379c402671af56449a120ec129f70fb48.png?alt=media)


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/detect-investigate-and-respond-to-threats/investigate-and-respond-to-cases/investigate-issues/issue-investigation-actions/update-issue-fields.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
