Data Quality — find the records your old rules let through

Re-check every stored record against today's rules: missing required fields, broken references, duplicates and retired options, found before they cost you.

Part of AxisIQ's single business model — The understanding layer (Understand the business). How the layers fit.

Validation only ever enforces the rules that existed the moment a row was written. Data Quality in AxisIQ re-runs the rules you have today against the records you stored before — and gives you the list of rows that no longer hold up.

Think about a year of running a business. You make a field mandatory in March, and every customer created in February is still missing it. You retire a courier from a dropdown, and the old shipments still name it. You tighten a phone-number pattern, and the numbers typed in by hand before that afternoon stay as they were. Someone deletes a supplier that forty purchase orders point at.

None of those rows were wrong when they were saved. They are wrong now, and most software never goes back to look. That is the gap this closes.

What a scan checks

Nothing is configured. The checks are read off your field definitions, so the rule in the report and the rule on the form are one rule:

• Required — the field is empty in records written before you made it mandatory.
• Options — the stored value is no longer one of the choices, because the choice was retired.
• Range — the number sits outside a minimum or maximum you set later.
• Currency — the amount carries a code the field is not meant to hold.
• Uniqueness — duplicates that predate the day you decided the field had to be unique.
• Dangling links — the record points at another record that has since been deleted.
• Format — pattern, length, email address, web address, or the contents of a list field.

The scan runs the same validators the form runs, so a rule cannot mean one thing when a person types a value in and something looser when a report counts it. Change a field definition and the next scan uses the new definition — there is no second copy of your rules to keep in step.

One rule is deliberately absent: a field marked unchangeable cannot be violated by data sitting still, so there is nothing for a scan to find.

How a scan runs

You start it from the Data quality tab in an app's settings, and it covers exactly the object types that app owns. The scope is stored with the result, so an inventory app never shows you a number that came from your accounting data.

Scans run in the background, and the result is stored — reopening the tab later is a read, not a fresh scan.

Speed comes from the shape of the data rather than from sampling. Every object type is a real table with real columns, so all the value checks for a type fold into a single pass over it. A type with thirty constrained fields costs the same as a type with one, and hundreds of thousands of rows come back in under a second. Uniqueness adds one grouped pass; each link check adds one join.

Format rules are the exception, because a pattern cannot be folded into that single pass — those values are read back and checked one by one, up to 100,000 rows per type. Past that the report states how many rows it read against how many exist. A check that quietly sampled and then reported all clear would be worse than no check at all.

From a number to the actual rows

A count on its own is a nag, not a fix. Every issue opens into the records behind it, each one in the ordinary record editor, so you correct it exactly where you would have anyway.

That drill-through runs under your permissions, not the scan's. A field masked from you stays masked here; a type you cannot read produces no issues for you to see. The report can never show more than the record list already would, which is what makes it safe to hand to a part-time bookkeeper or an agency.

Each issue keeps a sample of the offending records rather than an unbounded list, and says so when there are more. Records that somebody has already fixed since the scan simply drop out as you work through them.

Why not just write the query yourself?

You could. Analytics gives you real SQL over the same live records, and for a rule that is specific to how your business works — orders shipped with no invoice, customers with a credit limit but no billing address on file — a saved report is genuinely the better instrument, and we would point you there.

The difference is where the rule lives. A hand-written query is a second definition of correctness sitting alongside the field it describes: change the field, remember the query, or the report drifts into fiction. Data Quality has nothing to remember — it derives its checks from the fields every time it runs. Use both: one asks whether the data matches what the system says it must be, the other whether it matches how you actually work.

What it will not do for you

There is no bulk auto-fix, and that is on purpose. A button that rewrites four thousand rows to satisfy a rule is how a small mess becomes an unrecoverable one — the wrong default is applied at scale and the original values are gone. Remediation stays a human act. For a large cleanup, use Fix in Sheets: the offending records open in Axis Sheets as an editable, record-linked sheet, and pushing it writes your corrections back to the records under your own permissions.

Nor is there a schedule. A scan happens when a person starts one, so a regular integrity audit is a habit — after an import, after a round of field changes — rather than something the system does on a timer.

Dangling links are found by scanning and only by scanning. AxisIQ has no hard database-level link constraints by design, which is why deleting a record never fails because something else mentions it. The cost of that choice is that references can go stale, and this report is how you find out.

And the report is only a report, because the rules are still enforced on every write — including required fields on an edit: an update that would leave a mandatory field empty is refused rather than saved quietly. An issue you fix cannot come back in through the front door.

Where it fits

Data Quality sits underneath the rest of the platform rather than beside it. It reads the field definitions you set up in Operations, respects the field masking from Permissions, and is most worth running right after a bulk CSV migration or a round of field changes — the two moments when data reliably goes sideways.

If you are moving off spreadsheets, run one after your first import: it is the quickest way to see what the spreadsheet was letting through. See AxisIQ vs spreadsheets for the wider picture, or get set up first.

FAQ

How do I find invalid records that are already in the system? Open the Data quality tab in the app's settings and start a scan. It checks every stored record of that app's types against your current field rules and returns the failures grouped by rule, with the offending records one click away.

What happens to old records when I make a field required? Nothing — they keep their empty value, and no screen will tell you. A scan is what surfaces them, and from then on any edit to one of those records must fill the field in before it will save.

Can AxisIQ fix the bad records automatically? No. There is no automatic fix: corrections are ordinary record edits, or Fix in Sheets for a large batch — the offenders open in a linked spreadsheet and your edits push back — so a person sees what is being changed before it is changed.

Will a scan slow down my workspace? It runs in the background, and the value checks for a type are one pass over that type's table, so hundreds of thousands of rows finish in under a second.

Does the report expose data that a user is not allowed to see? No. Issues and drill-throughs are filtered by the permissions of the person looking, and fields masked for them stay masked, so the report can never reveal more than the record list already does.