Someone in the firm has said it needs a data quality tool, and the decision has landed on your desk. Before anyone draws up a shortlist, it helps to know that checks on records can run in four places. Data quality tools are one of them, and the other three are the step that moves records between systems, the reporting tool, and a person who reviews a sample by hand. Three jobs come up whichever place you choose: data profiling, which shows what the records hold; data cleansing, which corrects values that break an agreed rule; and watching records as new ones arrive. The right place can depend on where your records live, who writes the rules and who fixes a failure. The wider goal sits in the Signisys use case on making reports and AI answers trustworthy.
Last reviewed 2026-11-02 by Manish Sharma.
Data Quality Tools: Profiling, Cleansing and Watching Records
Three jobs sit behind the label, and each of them can take place in several places. A few terms first:
- Data profiling is looking at what a set of records holds, such as blanks, value ranges, formats and repeats, before anyone writes a rule.
- Data cleansing is correcting or removing values that break a rule the firm has agreed.
- Watching records means running the same checks again as new records arrive.
- A rule is one sentence saying what an acceptable value looks like, worded in a way that lets anyone in the team test a record against it.
- Artificial intelligence, in this guide, means software that answers a question or makes a suggestion from the firm’s records.
Researchers have tried to connect product features to what a firm wants from its records. Papastergios and Gounaris’s 2024 survey on arXiv looked at six open-source data quality tools. The authors link what each tool offers to the dimensions in the ISO/IEC 25012 standard, whose model lists fifteen, and they find that functions and dimensions relate many to many. One function can bear on several dimensions, and one dimension can draw on several functions.
For a buyer, the practical reading is simple. Ask which of your own rules each feature would check, rather than counting features on a list. Once the rules are named, they can be tried on real records with ten pass tests marked against a dated sample.
Where a Quality Check Can Sit in the Firm
A check on records can run in four places, and one firm can use several of them side by side. The four places below are a Signisys working description for this guide, not a standard.
| Approach | Where the check sits | Who writes the rule and who sees a failure |
|---|---|---|
| Checks in the data flow | At the step that copies records from one system into the store behind your reports | The person who builds that step writes it with the field’s owner, and the firm names who hears when the step holds a record back |
| A separate data quality product | In a product the firm adds beside its systems and points at the records | An analyst or a data owner writes the rules; ask the supplier how a failure then reaches whoever will fix it |
| Rules in the reporting tool | Inside a report or dashboard, as a flag, a filter or a count of rows that break a rule | The report builder writes it, and the report reader then sees the flag |
| A person reviewing a sample | With a named reviewer who reads some records and compares them with a written rule | The reviewer and the field’s owner agree the rule, and the reviewer then notes each failure |
Key Takeaway Name the person who writes the rules before you name the product.
The table shows where a check sits. It does not say which place is better, and the next sections leave that choice to your own answers.
Data Quality Tools Added Beside Your Systems
This section sets out one option from the table, the separate product, and ranks nothing against the other three. If your firm is considering a product of this kind, the gains below depend on what the chosen product connects to and supports. The trade-offs, on the other hand, are work that stays with people in the firm.
Advantages
Limitations
The other three places carry gains and trade-offs of their own. The questions in the next section, rather than this list, point to where you start.
Data Quality Tools: Where Records Live and Who Fixes Them
Before you compare data quality tools, work through six questions about your firm’s records and staff. The questions, and the reading table in the next section, reflect Signisys’ working method, offered as reasoning and not as a standard.
- Where do the records behind the report you care about live: one system, several systems or spreadsheets? The answer can set how many places a check would have to reach.
- Who will write the rules: a technical colleague, a business user, or the two together? A rule written without the person who knows the field can invite argument later.
- Who needs to see a failed check, and where do they already look each day: a report, an inbox or a task list? A failure shown where nobody looks may help no one.
The last three questions turn from people to fixing, scope and timing.
- Who fixes a failure, and may that person correct the value where someone first entered it? Otherwise the same error can come back with the next entry.
- How many fields does the first round cover, and which of them would you struggle to explain to your board? A short list keeps the first checks within reach of the people who will run them. Data profiling on just those fields then shows where to begin.
- Should a bad record be stopped before it reaches any report, or is a flag after the fact enough? Stopping it means choosing who releases a held record.
Data Quality Tools: Picking a Starting Place for the First Checks
Read your answers against the rows below to see where data quality tools, or one of the other three places, could start. Each row offers a first try, not a verdict.
| When you find | Place to try first | Agree this before relying on it |
|---|---|---|
| Records sit in one system, and one team enters them | Checks in the data flow, or else rules in the reporting tool | The person who builds the load or the report agrees each rule with the field’s owner |
| Records arrive from several systems, and a business user will write the rules | A separate data quality product | Ask the supplier how a business user writes a rule, and who then receives a failure |
| One or two reports matter, and their builder knows the fields | Rules in the reporting tool | Name who opens the flagged rows and corrects them where staff entered them |
| A handful of fields, with one careful reviewer | A person reviewing a sample | Write each rule down; a colleague can then run the same check later |
| A bad record must not reach any report | Checks in the data flow | Decide who hears when the step holds a record back, and who does the data cleansing before releasing it |
Where several systems feed the same report, the work touches joining up records held in separate systems.
One firm may use two places for different fields. In any of them, data profiling makes a sensible first look before anyone writes rules. It shows what the records hold. A longer account of what that first look reveals is in the kinds of fault that records can carry.
Repair Requests at a Property-Management Firm
For example, picture a residential property-management firm that looks after several apartment buildings. We made it up for this guide to show the four places side by side, and it draws on no client’s records.
Its head of maintenance distrusts the report of open repair requests by building. Requests arrive two ways: front-desk staff type them into a shared sheet, while residents fill in a web form. Someone merges the two before anyone builds the report. A first data profiling pass on the merged sheet would show which fields come through blank or in mixed spellings.
With a person reviewing a sample, the maintenance coordinator reads a sample against two written rules: a closed request carries a closing date, and the building name comes from the firm’s list. Rules in the reporting tool would let the report builder flag requests marked closed with no closing date. Checks in the data flow would put the person who merges the two sources in charge of holding back rows whose building name is missing from the list. A separate product becomes worth a look if a third source joins, for instance contractors’ job sheets.
Whichever place the firm tries, the head of maintenance still decides who corrects a flagged request, and in which of the two sources. Data cleansing in the merged copy alone would leave the shared sheet and the web form as they were.
The example shows reasoning only, and it gives no judgement on your own firm.
Agreeing Fields, Rule Writers and Fixers Inside the Firm
Key Takeaway Write the rule and name its owner before the trial starts.
Three things are worth agreeing before any product trial: which fields matter, who writes the rules, and who fixes a failure and where. A trial on your own records, with your own rules, then tells you two things. Can the person meant to write rules actually write them? And does a failure reach the person meant to fix it? Starting the trial with data profiling on one table lets both people see what the records hold before they write a rule. Agree as well who does any data cleansing, and in which system, and corrections then land where the values began. An order of work for starting that job is set out in how a small team can begin fixing its figures.
Bring in someone from outside when the person who would write the rules and the person who would fix failures sit in different teams, and neither has agreed to take on the other’s part.
Signisys works on data and AI for clients, including setting up checks on their records. Its reporting and BI solution page and Signisys data and AI page set out that work. The box below is a Signisys offer. Read it as one rather than as neutral guidance.
Rules, Checks and Data Quality Tools: An FAQ
Do data quality tools decide what a correct value is?
Where does data profiling end and data cleansing begin?
Can checks inside our reports stand in for data quality tools?
Should the person who spots a failed check also fix it?
What can a short trial on our own records show?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.