Jira Integration Best Practices

Guidance for running the Jira integration day to day, from what the anomaly's Tickets panel tells you to the choices that keep issues and anomalies in step without surprises. For the mechanics behind each behavior, see How the Jira Integration Works.

Read the Tickets Panel

Once an anomaly has a linked issue, the Tickets section of the anomaly shows one card per issue with:

The issue key, which expands the issue's details.
The issue's status and priority as of the last read from Jira.
Synced X ago, the time of that read, or Linked X ago before the first one.
A Two-way / Read only button that sets how this one issue is synced. It is shown while the integration itself is set to two-way sync, and it is visible but not clickable without the Manager role and the Author team permission on the anomaly's datastore.
A View button that opens the issue in Jira.

Register the Webhook Early

Without a webhook, a change made in Jira reaches Qualytics when someone opens the anomaly, or on the background sweep that runs hourly by default. Registering the webhook while you set the integration up means every linked issue refreshes within seconds, and the other two triggers stay as a backstop. See Register the Jira Webhook.

Narrow a Single Issue Instead of the Whole Integration

When one issue should stop receiving comments and status notes, use its own Two-way / Read only button rather than switching the integration to read only. The integration setting is the master, so turning it off silences every linked issue at once and hides each issue's own button because it can no longer change anything.

Link Only the Issues That Represent the Work

An anomaly can carry several linked issues, which is useful when the same problem is tracked by more than one team. Keep in mind how that interacts with Anomaly status sync, because the anomaly moves only when every linked issue sits at a status mapped to the same anomaly status, read only issues included. A duplicate issue closed early therefore cannot resolve an anomaly whose main issue is still open, and an issue linked by mistake keeps the anomaly where it is until it closes too.

Map the Statuses Your Workflow Actually Uses

The status mapping is the only bridge between Jira's free-text statuses and the fixed anomaly statuses, and nothing is ever inferred from a status name that is not in it. Fill the rows with the names your projects really use, leave a row unchanged when an anomaly status should move nothing, and remember that the Jira account needs permission to transition issues in those projects. See Anomaly status sync.

Allow Every Project Your Teams Actually Use

The Allowed Projects list governs more than where new issues are created. Searching for an existing issue to link is scoped to the same list, so an issue in a project you left out cannot be found from the anomaly, even when the integration's account can browse it in Jira. Add the projects your teams work in when you connect, and revisit the list when a new team starts tracking data quality work.

Expect Mirrored Comments to Keep Their Original Time

A comment written on the issue is mirrored onto the anomaly's Timeline with the time it was written in Jira, not the time the sync ran. A comment that took a while to arrive therefore lands at its own point in the conversation rather than at the top, which keeps the thread readable but means a new comment is not always the last thing on the Timeline.