Skip to content

Generate a Data Quality Report ​

This guide explains how to generate and read a data quality report — an assessment that tells you whether a data source or a delivered file is clean and complete enough to integrate, and what needs attention first.

Overview ​

A data quality report runs a catalogue of checks against one subject and turns the results into a readiness verdict. There are two kinds of subject:

SubjectWhat is checked
A connectorIts latest database profile — relationships, keys, empty tables and columns, and how completely the source could be profiled
A fileA delivered spreadsheet or CSV — its structure, value types, columns and rows

A report lives in Data Quality and is part of at most one project. Data → Data Quality lists every file and connector you assess, each with its latest outcome and the project it is part of. You don't add reports to a project yourself — the project's sources decide:

  • A file is part of the project when you upload a spreadsheet or CSV on the Data sources tab with Assess for data quality turned on — see Add Reference Documents.
  • A connector is part of the project once you profile it from the project's Data profile tab. The report is this project's own: another project profiling the same connector has its own report and triage.

A file can also be assessed on its own, part of no project — see Assess a file on its own.

A report leaves the project only by being removed: select Remove next to it on the Data quality tab or on its page in Data Quality, unlink its connector, delete the project, or tick Also remove its data quality assessment when deleting the reference document it was assessed from. Removing deletes the report and its findings; the reference document stays.

Both read the same way: the same verdict, the same findings queue, the same triage. Only the checks that apply differ.

Reports are generated on demand and always describe the latest state — a source report interprets the most recent profile of that source.

Prerequisites ​

For a connector: a connector that supports database profiling, linked to the project and profiled from its Data profile tab — see Profile a SQL Server Database.

For a file: a spreadsheet (.xlsx) or CSV, up to 50 MB, uploaded on the Data sources tab with Assess for data quality turned on, or on its own in Data Quality.

Generate the report ​

  1. Go to Operate → Projects and open your project
  2. Select the Data quality tab — the project's connectors and files are listed on the left, each with its current state
  3. Pick the one you want assessed — a connector whose profile has not finished yet offers Profile connector
  4. Optionally, set the checks it is held to on the Checks tab (see below)
  5. Select Generate report

You can do the same from Data → Data Quality: select a file or connector in the list to open its page, with the same Report and Checks tabs.

Assess a file on its own ​

A file doesn't need a project to be assessed:

  1. Go to Data → Data Quality and select Upload
  2. Choose a spreadsheet (.xlsx) or CSV and select Upload — the file's page opens
  3. Set its checks on the Checks tab, then select Generate report on the Report tab

The file stays in Data Quality, part of no project.

Find a report ​

Data → Data Quality shows one row per file and connector with its latest outcome. Narrow the list by name or project name, by kind (file or connector), or by outcome (Ready, Needs attention, Failed, Not assessed).

The checks a subject is held to ​

Next to the Report of the selected subject, the Checks tab shows what it is judged against:

  • Check groups — the platform groups a file is held to (structure, value types, columns, rows), and any of your organisation's own check groups. Tick or untick them on the Checks tab and select Save check groups. A connector is always held to the profile checks.
  • Field mapping — when you tick one of your organisation's check groups, say which column of the file holds each field the group checks. Pick the columns yourself, or select Suggest to have the AI propose them and change any you disagree with. Fields the checks need but that have no column are listed, and the report shows them as missing rather than failing.
  • Custom checks — a file's own checks, written for that file in the platform's check format. Add, edit or remove them here; they run on the file's next assessment.

The report runs in the background and can take a few minutes — the card shows that the agent is working while it runs. You can leave the page and come back; the result is saved.

Read the verdict ​

Every report opens with a verdict:

VerdictMeaning
ReadyEvery check came back clean, and none was left unchecked
Ready with issuesIntegration can proceed, but review the findings first

The verdict is computed from the findings alone: a check raises a finding when its count passes the check's threshold, and any raised finding — or any check that could not run — makes the report Ready with issues. Some checks only report: they show what they counted and never ask you to act. The same data always produces the same verdict.

Below the verdict, the report contains:

  • A summary band — how many checks raised a finding, how many need action, and two tiles describing the subject itself (tables classified and domains for a source; sheets and data table for a document)
  • Functional domains (source reports only) — the source's tables grouped into business areas (for example Sales, Master Data, Audit), with each domain's size, what kind of data it holds, and whether it needs attention
  • Findings — one row per check in three groups: what raised a finding, what could not be checked, and what passed. Each finding carries the number it counted and where it looked, and the raised ones are what you work (see Work the findings)
  • Run details — which check groups judged the report, when it ran, and a reference id and token usage for the AI work behind it. A source report adds how many labelling calls its domain grouping took and how many tables they left unlabelled

Where the numbers come from

Every number in a finding is measured — from the profile for a source report, from the file itself for a document report. A finding's wording comes from the check's own definition with the measured numbers filled in, never from a model. On a source report, AI contributes the grouping of tables into business areas and nothing else.

A check that could not run

A check can report that it did not run — a precondition wasn't met, or it failed. Those never read as a pass: the report counts them separately and the verdict drops to Ready with issues, so a coverage gap is never mistaken for a clean result.

Work the findings ​

Each finding is something to action, not just read:

  • Resolve a finding once you've handled it — optionally noting what was decided or the answer the customer gave.
  • Dismiss one that doesn't apply, with an optional reason.
  • Restore a resolved or dismissed finding to reopen it.

Your decisions are recorded against the subject and carried into future reports, so a regenerated report doesn't re-raise something you've already settled. For a source, the decisions belong to this project's assessment of the source rather than to one profile — re-profiling and generating again keeps them.

Triage never moves the verdict. It records that the team has dealt with what the report raised, which the document list shows as Ready once every finding that needed action is resolved or dismissed.

Regenerate the report ​

Select Regenerate report to run the checks again — for example after re-profiling the source, or after changing a file's checks. A corrected file is a new upload: add it on the Data sources tab with Assess for data quality turned on.

After re-profiling a source

A source report interprets one profile. If you profile the source again, generate the report again so it reflects the new profile.

One run at a time

A subject can only have one report generating at a time.