> For the complete documentation index, see [llms.txt](https://developer.collibra.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.collibra.com/workflows/out-of-the-box-workflows-walk-throughs/dq-incident-triage.md).

# DQ Incident Triage

This workflow reviews an incoming Data Quality event and asks the assigned reviewer to confirm whether it should be logged as a Data Quality Issue. If confirmed, the workflow creates the issue linked to the affected asset.

<figure><img src="https://2208542399-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAeKwSsP1BP6lDDArkTO2%2Fuploads%2Fgit-blob-9c1521bcef44251c0c96146c262e8ca6b138f990%2Fwf_ootb-dq-incident-triage-diagram.png?alt=media" alt="A workflow diagram showing three steps: Parse Trigger reads the Data Quality event and resolves the reviewer via the recipient cascade; DQ Incident Review presents the event summary to the reviewer, who confirms or dismisses; if confirmed, Create Issue creates a Data Quality Issue linked to the affected asset"><figcaption><p>DQ Incident Triage workflow</p></figcaption></figure>

## Roles

| Role     | Task                                                               | Required |
| -------- | ------------------------------------------------------------------ | -------- |
| Reviewer | <ul><li>Confirm whether the event should become an issue</li></ul> | Yes      |

The reviewer is the DQ manager resolved from the event payload. If no DQ manager can be resolved, the workflow falls back to the configured `FALLBACK_ASSIGNEE` user, which is **Admin**.

## Start the workflow

The workflow starts automatically when one of the following Data Quality start events is emitted:

* **Data Quality Job Failed**: A Data Quality job fails to run.
* **Data Quality Job Condition Breached**: A Data Quality job run completes but a configured condition is breached, for example the quality score falls below a configured threshold.
* **Data Quality Monitor Event**: A Data Quality monitor changes state, for example from passing to breaking.

For events to trigger this workflow, the DQ job must be in Event Emission mode with the corresponding event toggle enabled.

{% hint style="info" %}
Configuration-change events, where the `changeType` process variable is set, are silently ignored. The workflow ends without creating a review task or an issue.
{% endhint %}

## Review the incident

The reviewer receives a **DQ Incident Review** task containing a summary of the Data Quality event, including the job name, event type, and event-specific details such as failure information, quality score and breached conditions, or monitor state change details.

The reviewer evaluates the event and decides one of the following:

* **Confirm**: A Data Quality Issue is created.
* **Dismiss**: The workflow ends without creating an issue.

## Outcome

If the reviewer confirms, the workflow creates a Data Quality Issue in the Data Helpdesk linked to the affected asset. The [Issue Management](/workflows/out-of-the-box-workflows-walk-throughs/issue-management.md) workflow then starts automatically and manages the full governance lifecycle of the issue, including review, approval, and resolution.


---

# 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://developer.collibra.com/workflows/out-of-the-box-workflows-walk-throughs/dq-incident-triage.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.
