> 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-saas/configure-cortex-xsoar/incident-configuration/set-up-incident-mirroring.md).

# Set up incident mirroring

When mirroring incidents, you can make changes in a third-party application, such as ServiceNow and Jira that will be reflected in Cortex XSOAR, or vice versa. You can also attach files from either of the systems, which will then be available in the other system.

Setting up your integration to mirror incidents from the third-party application in Cortex XSOAR includes the following:

* Configure mirroring for triggering incidents originating from your third-party application or from another fetching integration. For example, see the [ServiceNow v2](https://xsoar.pan.dev/docs/reference/integrations/service-now-v2) integration.
* Configure incoming and outgoing mappers. For more information, see [Classification and mapping](/cortex-xsoar-8-saas/configure-cortex-xsoar/incident-configuration/classification-and-mapping.md).
* Configure account roles for API calls. For example, see the [ServiceNow v2](https://xsoar.pan.dev/docs/reference/integrations/service-now-v2) integration.
* Run mirroring commands. For more information about mirroring commands, see the [Mirroring Integration](https://xsoar.pan.dev/docs/integrations/mirroring_integration) or your third-party integration, for example [ServiceNow v2](https://xsoar.pan.dev/docs/reference/integrations/service-now-v2).

#### Enable mirroring for manually modified incident fields (dirty fields)

When incident mirroring is active, Cortex XSOAR automatically tracks which incident fields you manually edited. These are known as dirty fields. To prevent your manual changes from being overwritten, the platform protects dirty fields from being updated by the remote system (such as ServiceNow or Jira) during subsequent mirror synchronizations.

However, if you want to update previously edited incident fields during mirroring synchronization, you can run the **`resetDirtyFields`** command in the War Room or in an automation script. This command removes incident fields from the tracking list (stored in the **`dbotDirtyFields`** property), allowing the next incoming mirror synchronization to update them with data from the remote system. Running the **`resetDirtyFields`** command is relevant in situations where:

* You accidentally edited an incident field.
* A playbook or automation resolved a conflict and needs to re-enable mirroring for specific fields.
* You want to force a full resync of all incident fields from the remote system.

{% hint style="info" %}

### Note

You must have the Incident Advanced Edit permission to execute the **`resetDirtyFields`** command.
{% endhint %}

The following are examples of how to use the **`resetDirtyFields`** command.

**Update specific dirty fields of the current incident in context.**

For example, an analyst manually edited the severity and owner fields but now wants those two fields to resynchronize from the remote system while keeping other manually edited incident fields protected.

* In the CLI: **`!resetDirtyFields dirtyFields="severity,owner"`**
* In an automation script: **`demisto.executeCommand("resetDirtyFields", {"dirtyFields": "severity,owner"})`**

Result: Only severity and owner are removed from the dirty fields list. Other manually edited fields remain protected. The command returns **`Done`**.

**Update all incident fields of the current incident in context.**

This enables a full synchronization of the incident and takes precedence over any specific fields listed in the **`dirtyFields`** parameter.

For example, an analyst wants to allow all incident fields to be updated from the remote mirrored system on the next synchronization cycle.

* In the CLI: **`!resetDirtyFields dirtyFieldsAll=true`**
* In an automation script: **`demisto.executeCommand("resetDirtyFields", {"dirtyFieldsAll": "true"})`**

Result: All fields are removed from the dirty fields list. The command returns **`Done`**. On the next incoming mirror synchronization, all fields are updated with values from the remote system.

**Update specific dirty fields of an incident that is currently not in context.**

For example, a playbook or automation needs to synchronize mirroring for the status and closeNotes dirty fields on a specific incident (12345) that is different from the one currently in context.

* In the CLI: **`!resetDirtyFields id="12345" dirtyFields="status,closeNotes"`**
* In an automation script:

  ```programlisting
  demisto.executeCommand("resetDirtyFields", {
      "id": "12345",
      "dirtyFields": "status,closeNotes"
  })
  ```

Result: The status and closeNotes fields are removed from the dirty fields list for incident 12345. Other manually edited fields on that incident remain protected. The command returns **`Done`**.

#### Troubleshoot incident mirroring

In case of delays in incident mirroring, follow these troubleshooting steps:

1. Use !getMirrorStatistics in the War Room to check the status o the mirroring cycle.
2. Close unnecessary mirrored incidents to narrow down the scope of mirroring.
3. Remove redundant or disabled integration instances as deactivation alone may not free up resources.
4. If delays do not improve, contact support to discuss changing the time frame for mirrored incidents.


---

# 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-saas/configure-cortex-xsoar/incident-configuration/set-up-incident-mirroring.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.