Data Quality Dashboard

Use the Data Quality Dashboard pre-built canvas asset to monitor ingestion runs, track record counts, and diagnose data quality issues by field and resource.

The Data Quality Dashboard is a pre-built canvas asset that lets you monitor your tenant's ingestion runs end-to-end. Once a solution is rolled out and starts ingesting, the dashboard surfaces:

• How many records have been processed
• How many rows passed or failed validation
• Which tables and which solutions are affected
• Which error codes are most frequent
• The exact failed rows, with the source field values that caused validation to fail
• Table-level object-validation results — the outcome of any freshness, missing_data_validation, and foreign-key rules configured on your tables
• The rows kept in a table with a flagged foreign-key violation, listed by constraint

Data flows in automatically — nothing additional is needed at ingest time. Every validated row contributes to the dashboard, regardless of how it was ingested (see API Guide — Validation behavior).

Prerequisites

Before you start, make sure:

• Your tenant is on the latest ingestion release. The dashboard depends on the validation feature that ships in this release. If your tenant has not been upgraded yet, submit a support ticket.
• At least one solution has been rolled out in the tenant via the ingestion API (see Schema lifecycle). The dashboard renders empty until a rollout has happened.
• You have permission to create canvas assets.

Setting up the dashboard (one-time)

Setup is a one-time task per tenant, performed by a tenant admin. Three steps.

Step 1 — Register the Data Quality Dashboard action

The dashboard reads aggregated validation metrics through a backend action that needs to be registered in your tenant before the dashboard widgets can fetch data.

1. Go to Actions in the tenant settings.
2. Select Add new action and choose the API spec / OpenAPI option.
3. Paste the OpenAPI spec for the dashboard. The current spec is provided by Peak when you request dashboard setup — submit a support ticket if you do not have it.
4. Save the action with the exact name Data Quality Dashboard APIs.

Step 2 — Open canvas and select the namespace

1. Open Canvas in the tenant.
2. When prompted to choose a metrics namespace, pick peak__dq_dashboard.

This namespace is reserved for Peak-managed dashboards — the dashboard's KPI cards and detail tables read their numbers from cubes published into it whenever a solution is rolled out, upgraded, or has a column added.

Warning:

Do not publish your own cubes into peak__dq_dashboard. Pick a different namespace for any custom dashboard work.

Step 3 — Create the asset from the template

1. With the namespace selected, open the Templates library in canvas.
2. Find the template named Data Quality Dashboard and select it — a preview of the layout is shown.
3. Select Create asset, give it a name (for example, Data Quality Dashboard), and confirm.

The asset is now yours: rename it, share it, embed it in spaces, or duplicate it. Edits you make to your asset do not affect other tenants' copies.

What's in the dashboard

The dashboard is a single scrolling overview page, plus a table-level detail view you reach by drilling into any table. Every panel on the overview responds to the filters at the top.

Monitoring filters

A filter bar scopes every panel on the page:

• Start date and End date — set the monitoring window. All KPIs, charts, and tables are calculated for this window.
• Solution — focus on a single solution, or leave it on All solutions to span the whole tenant.

Period-over-period comparisons on the KPI cards are measured against the immediately preceding window of equal length — for example, a 93-day window is compared with the previous 93 days.

Current health snapshot

Five KPI cards summarize the selected window. Each card shows the headline number plus how it has moved versus the previous, equal-length window:

• Total requests — number of ingestion requests received.
• Rows processed — total rows seen across those requests.
• Failures — rows that failed validation.
• Rows ingested — rows that passed validation and were written to the destination.
• Pass rate — share of processed rows that passed validation.

A row kept in a table with a flagged foreign-key violation does not count as ingested. It counts under Failures when the check's severity is error, and as a warning when it is warn — so enabling the check lowers the Pass rate for tables that have unresolved references. Clearing the violation returns the row to the passing count.

Charts

Three time-series charts plot trends across the selected window:

• Error-code trend — daily stacked failed-row counts for the top six error-code series, with all remaining series grouped into Other. Shows which error codes are driving failures, and when.
• Validation results over time — daily failed, warning, and successful row counts side by side.
• Pass rate over time — pass rate on a fixed 0–100% scale, so quality is comparable across windows.

Tables

• Top error codes — error codes ranked by total occurrences in the window, each with a plain-language description (for example, DI_E_22023 — Value is not one of the allowed enum values). Use it to find the most common data-quality issues to fix at the source.
• Breakdown by table — one row per table, with its solution, run count, and failed / success / total row counts. The list is searchable and sortable, and paginated. Select a table name to open its detail view, scoped to the active solution and date range.
• Breakdown by request — a collapsible secondary view, sorted by failed rows highest first, for investigating a specific ingestion request. Select Show requests to expand it.

Current slice summary

A short narrative of the selected window — overall pass rate, the table with the most failures, and the top error code — followed by a Coverage line stating how many tables across how many solutions were monitored in the window.

Table detail

Selecting a table name in Breakdown by table opens a detail view scoped to that table, solution, and date range. It lists the failed rows for the table, including the source field values that caused validation to fail, so you can reproduce and fix them. Hover any error code to see what it means.

The page header's Table detail and Object validation tabs move between the row-level view and the table's object-validation results without losing the selected table and window.

Table detail — foreign-key issue rows

FK validation issue rows lists the rows that were kept in the table with a flagged foreign-key violation. The panel reads the table's live PEAKAUDITERRORS column, so a row leaves the list once its parent arrives and the next async_foreign_key run clears the flag.

Three parts make up the panel:

• Count cards — Flagged rows, Violations, Error severity, and Warn severity. Flagged rows and violations differ when a row breaks more than one constraint, since every violation is counted separately.
• By constraint — one row per foreign-key constraint with its violation, error, warn, and flagged-row counts, so you can tell which reference is causing the backlog.
• Flagged rows — the rows themselves, paginated: Primary key, Constraint, Severity, Error code, Details (for example, region_id has no matching row in stage.fkr_regions (fk_osw_region)), Flagged at, and Ingested at. Severity and constraint filters narrow the list.

Flagged rows also appear in the row-level Error-code trend and Top error codes panels under DI_{E|W}_23F01. The panel is shown for every table that carries the foreign-key audit columns, and reports that no rows are flagged when the table is clean.

Object-level validation monitoring

Alongside the row-level metrics above, the dashboard surfaces table-level object validations — the results of the freshness, missing_data_validation, and async_foreign_key rules you configure through objectValidations. These checks run on demand, not in response to any single ingest request, and are reported under their own error codes: DI_{E|W}_24F01 (freshness), DI_{E|W}_24M01 (missing data), and DI_{E|W}_23F01 (foreign key), where E marks an error and W a non-fatal warning.

The object-validation panels appear in two places: summary panels on the overview page, and a dedicated object-validation view on each table's detail page.

Object validation health (overview)

Five KPI cards summarize the selected window across every monitored table:

• Tables monitored — tables that have at least one object-validation rule.
• Freshness failures — number of freshness-rule failures (DI_*_24F01).
• Missing-data failures — number of missing-data-rule failures (DI_*_24M01).
• Under-filled periods — total individual time windows that came in below their expected row count.
• Last failure seen — timestamp of the most recent object-validation failure.

Two charts plot the trend across the window:

• Object validation failures over time — daily freshness, missing-data, and async foreign-key failure counts.
• Severity mix over time — daily error and warn counts, so you can see how serious the failures are, not just how many.

Object validation by table

One row per monitored table, each with its freshness failures, missing-data failures, async FK failures, under-filled periods, a severity breakdown (error / warn / failure counts), and last checked time. The list is searchable and sortable. Selecting a table name opens its object-validation detail view, scoped to the active solution and date range.

Below it, Top validation error codes ranks the object-level codes (for example, DI_W_24M01, DI_E_24F01, DI_W_23F01) by count, with the number of affected tables — kept distinct from the row-level Top error codes panel higher up the page.

Table detail — object validation

Selecting a table opens its object-validation detail page. A Detail filters bar sets the date window for every panel on the page, and a summary line reports the span of the gaps and the number of under-filled periods across the table.

Object validation health cards summarize the table in the window:

• Freshness failures, Missing-data failures, Under-filled periods — current-slice counts.
• Total shortfall — expected-minus-actual rows summed across all gaps.
• Worst freshness age — the largest observed staleness for the configured column.

Two per-table charts — Failures over time and Severity mix — plot the same trends scoped to this table.

Missing-periods drill-down

A single missing-data run can flag multiple time windows, so a Run selector pins the view to one validation run (de-duplicating overlapping runs). The Missing-data shortfall by period chart then plots every under-filled period from that run, derived as expected minimum rows minus actual row count.

Detail tables

Three tables list the raw check results for the table in the selected window.

The Freshness checks table lists one row per freshness evaluation: Checked at, Configured column, Last seen value time, Observed age, Threshold, Severity, Error code, and a plain-language Message (for example, Data is stale: column 'recorded_at' is 61 days old (threshold: 2 days)). A Failure severity with an em-dash age and "Rule evaluation failed; check service logs." means the check itself could not run.

The Missing-data checks table lists one row per missing-data evaluation: Checked at, Configured column, Window, Slice interval, Expected min rows, Missing periods count, Severity, Error code, and Message (for example, Missing data: 60 period(s) of 1 days had fewer than 1000 rows). Inline caveats appear when the checked window was truncated.

The Missing periods table paginates the individual under-filled windows for the selected run: Period start, Period end, Watched column, Actual row count, Expected min row count, Shortfall, and Severity.

Async foreign-key checks

Async foreign-key checks reports the whole-table async_foreign_key runs for this table. Four cards summarize the most recent run — Orphan rows (latest run), Violated constraints, Severity, and Last checked.

Below them, one row per run lists its Checked at, Orphan rows, Violated constraints, Severity, Error code, Message, and Run identifier — confirming that a run happened and what it found. The flagged rows themselves are listed in the FK validation issue rows panel on the table's row-level detail view.

What you can monitor

At a glance:

Metric	Where to find it	Use it to…
Rows processed, rows ingested, pass rate	Current health snapshot KPI cards	Track ingestion health over the selected window
Failed, warning, and successful rows over time	Validation results over time / Pass rate over time charts	Spot regressions after a release or schema change
Error codes over time	Error-code trend chart	See which error codes drive failures, and when
Top error codes	Top error codes table	Identify the most common data-quality issues to fix at the source
Per-table breakdown	Breakdown by table	Find which tables are contributing most failures
Per-request breakdown	Breakdown by request	Investigate a specific ingestion request
Per-solution breakdown	Solution filter	Compare quality across multiple solutions in the same tenant
Failed rows with source values	Table detail view	Reproduce and fix the rows that did not pass validation
Freshness & missing-data failures	Object validation health / by table	Catch stale tables and under-filled time windows from freshness / missing_data_validation rules
Under-filled periods & shortfall	Missing-periods drill-down (table detail)	See exactly which windows came in short, and by how many rows
Flagged foreign-key rows	FK validation issue rows (table detail)	See which rows were kept with an unresolved reference, and against which constraint
Async foreign-key runs	Async foreign-key checks (table detail)	Confirm a whole-table re-check ran, and what it found
Object-validation error codes	Top validation error codes	Track DI_*_24F01 (freshness), DI_*_24M01 (missing data), and DI_*_23F01 (foreign key) coverage

Note:

These are the row-level validation metrics. For table-level freshness, missing_data_validation, and async_foreign_key results — error codes DI_{E|W}_24F01, DI_{E|W}_24M01, and DI_{E|W}_23F01 — see Object-level validation monitoring.

When data appears

Ingestion runs on a schedule — once every 30 minutes by default — so data is not instant. Your first request may take roughly 30–50 minutes to appear, depending on how close it lands to the next scheduled run. As soon as that ingestion completes, the Data Quality Dashboard is updated.

The 30-minute interval can be changed for your tenant — submit a support ticket to adjust it.

Once a solution is rolled out and ingestion has run, records start showing up. The underlying metrics cube refreshes every few minutes, so very recent activity may take a moment to appear after each run. Object-validation results are not tied to this schedule — they appear only after a validation run, which you start with Run validations on demand.

Common questions

Why is one of my solutions missing from the solution filter?

The filter lists solutions that have at least one validation record. Freshly-rolled-out solutions with zero ingestions will not appear until their first request runs through validation.

Why is the breakdown-by-table widget empty?

Either no validation records have landed in the selected date range, or your selected solution filter is excluding everything. Try widening the date range or clearing the solution filter.

Why did the pass rate drop after I enabled the foreign-key check?

A row kept with a flagged foreign-key violation no longer counts as ingested — it moves to the failure or warning total according to the check's severity. Once the missing parent rows are loaded and async_foreign_key re-runs, the rows return to the passing count.

Why did a past day's counts change?

Foreign-key counts are read from the table's live PEAKAUDITERRORS column rather than from a point-in-time record. Clearing a violation removes the row from the day it was flagged as well as from the totals.

Why don't I see source columns in the table detail view?

Source columns are only carried for tables that came from the supported standard schemas. Custom tables and custom-added columns appear in the dashboard's audit columns only.

Can I customize the dashboard?

Yes. The asset created from the template is a normal canvas asset — you can edit widgets, add pages, change the styling, and so on. Re-creating the asset from the template will overwrite your edits, so save a copy first if you want to keep them.

Who do I contact for issues?

Submit a support ticket with: your tenant name, the asset ID (visible in the canvas URL), and a screenshot of what you're seeing. Include the time range you were looking at — it speeds up the triage significantly.