Skip to main content
Issues are the action layer in PRIZM. While an alert tells you something has gone wrong, an issue is the tracked unit of work to actually fix it — carrying an AI-generated summary, a set of recommended actions, and a link back to the alert and asset that triggered it. Use the Issue page to manage your team’s data quality backlog so nothing falls through the cracks.

Issue statuses

Every issue moves through five statuses that reflect where it sits in the resolution workflow.
  • New — The issue has been created but no one has started working on it yet. New issues are your unactioned backlog.
  • In Progress — A team member has picked up the issue and is actively investigating or fixing the underlying problem.
  • Blocked — Work is paused pending an external dependency.
  • Resolved — The problem has been fixed. Resolved issues remain visible for audit and trend purposes.
  • Reopened — A previously resolved issue whose underlying alert has re-fired.
Each of these five statuses has its own live count card at the top of the Issue page.

Issue severity

An issue inherits its severity from the alert that created it (or is set manually if the issue was created by hand). Unlike alerts, which have four levels, issues use four: Critical, High, Medium, and Low — there’s no Info level, since an informational, non-breach event has nothing actionable to track as an issue.

Issue List

The Issue page lists every issue with the following columns:

Filter by category

Issues filter by category tabs above the table — All, Business, Operational, Performance, Structural and Reconciliation, when non-zero — the same categories used throughout PRIZM’s metric contexts, each shown with a live count.

Issue lifecycle

1

Problem detected

A Critical or High priority alert fires on a metric, or a data engineer or analyst manually notices an anomaly during their own investigation.
2

Issue created

An issue is created with status New. If created from an alert, its metric, asset, alert message, and severity are pre-populated automatically. If an open issue already exists for the same asset, PRIZM prompts to link to it instead of creating a duplicate.
3

Issue picked up

A team member takes ownership by setting Assigned To (there’s no suggested owner yet — assignment is manual). The status moves to In Progress.
4

Problem resolved

The underlying problem is fixed and the team member marks the issue Resolved.

Issue detail page

Clicking into an issue opens its detail view across five tabs: Overview, Timeline, Lineage, Audit, and Conversation — plus a side panel with Artifact and More Info.

Overview

  • An Issue Context panel showing Status, Priority, Assigned To, and Expected Resolution — the SLA-derived target date/time for this issue — alongside Root Alert (the alert that triggered it), Reason Code, and Resolution Note.
  • An AI Insights panel generating a plain-language description of what was detected.
  • Recommended Actions — a list of AI-generated next steps (for example, running a root cause analysis, engaging data governance stakeholders, or validating affected reference data), each with its own checkbox so it can be marked complete individually. A refresh control regenerates the list, and a + control lets you add a step manually.
  • Semantic context (Domain, Application, Product, Tag), Owners (Business, Technical, and Steward — each independently assignable), and Audience.
  • An Integrations panel showing linked external tickets — Jira and ServiceNow tickets created from the issue are shown here with their ticket ID.
  • A Recent Alert card linking back to the specific alert occurrence that created the issue.
  • The side panel’s Artifact tab holds file uploads and the underlying query behind the metric (for example, a .sql file), while More Info carries additional context.

Timeline

The same kind of metric timeline chart and occurrence table you’d see on the underlying alert, showing the metric’s value over time alongside expected range, change %, priority, and any linked issue for each occurrence.

Lineage

Counts of affected assets and affected reports, plus an interactive lineage graph. Each node shows the downstream table, its health percentage, row and column counts, and badges for its own alert/issue activity — so you can see exactly how far the problem has spread without leaving the issue.

Audit

An immutable, read-only log of every action taken on the issue (for example, Create — “User vignesh.r@dqlabs.ai created a new ISSUE ISU-46”), including status changes and assignment history.

Conversation

Threaded discussion on the issue, filterable by All, Trending Topics, Bookmarked Topics, Topics with Most Likes, and Topics with Most Dislikes — empty until someone starts the first thread.

Issue metrics at a glance

Summary cards at the top of the Issue page track your current backlog — New, In Progress, Blocked, Resolved, and Reopened — each a live count, with the page header showing the total issue count across all of them.

SLA and external ticketing

Each issue’s Expected Resolution date reflects the SLA policy bound to it, and its status is reflected in the linked alert’s own SLA Status column (e.g. Breached, Stopped) on the Alert and Issue lists. Issues can also link out to external tickets — Jira and ServiceNow references appear directly on the issue’s Overview under Integrations.