> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to run a recurring data quality audit
- URL: https://blog.jestor.com/run-a-recurring-data-quality-audit/
- Published: 2026-09-16T18:56:39.000Z
- Updated: 2026-09-16T18:56:39.000Z
- Author: Bruno Bannach

A **data quality audit** is worth running only on the fields your processes actually depend on. In **Jestor**, those checks can be views and formulas that run continuously, so quality is monitored rather than inspected periodically.

## Why data quality degrades silently

Nobody decides to let data degrade. It happens through small events: a duplicate created in a hurry, a field left blank because it was optional, a category typed differently.

Each is invisible individually. The aggregate surfaces months later, when a report is wrong and nobody can say since when.

What a recurring audit catches:

- Duplicates in key registries
- Required data missing on active records
- Categories used inconsistently
- Records orphaned from their connections
- Values outside plausible ranges
- Records that have not been updated in an implausible time

## Checks worth automating

| Check                      | What it finds                    | How                   |
| -------------------------- | -------------------------------- | --------------------- |
| Duplicate registry entries | Near identical names             | A review view         |
| Missing key fields         | Records that cannot be processed | A filtered view       |
| Orphaned records           | Broken connections               | Empty connected field |
| Implausible values         | Entry errors                     | A range formula       |
| Stale records              | Abandoned or forgotten work      | Last updated date     |
| Inconsistent categories    | Free text where a list belongs   | Distribution review   |

## Step by step to implement it

1. **List the fields your processes depend on**, which is a short list.
2. **Build a view per check**, showing only the failures.
3. **Assign each view an owner**, since a view nobody owns is ignored.
4. **Review weekly**, briefly, rather than annually at length.
5. **Fix the cause**, not only the record.
6. **Add a validation rule** once a cause is identified.
7. **Retire checks** that stop finding anything.

## Why fixing the cause matters more than fixing the records

Cleaning a list of failures restores quality until the same conditions produce the same failures. Each fix should end with a validation rule, a required field or a connected field that makes the failure impossible, which is what converts an audit into an improvement.

## Why choose Jestor

In **Jestor**, quality checks can be filtered views on live data rather than a periodic export, formulas flag implausible values, connected fields and required fields remove causes once identified, and the history view shows whether a problem came from a person, an automation or the **API**.

## Frequently Asked Questions

### Which fields should be audited?

Only those your processes depend on, which is a short list. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### How often should checks run?

Continuously as views, reviewed briefly each week.

### What should each fix end with?

A rule that makes the same failure impossible in future.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.