How to add a data quality rule in OpenMetadata (step by step)

Almost every data crisis starts the same way: someone opens a report, sees a weird number, and nobody knows whether the data is wrong or the business just changed. By the time they figure it out, the decision is already made.

A data quality rule exists to cut that story off at the root. It's an automated test that runs against your data and answers a concrete question — are there empty phone numbers in the customers table?, are there duplicate IDs?, are there top-ups with impossible amounts? — and warns you before the problem reaches a dashboard.

The good news: in OpenMetadata (open source, no licenses) creating your first rule takes under two minutes. We'll show you with real screenshots on a telecom database.

What a "quality rule" actually is

Think of it as a blood test for your data. You define an expected value ("the phone_number column must never be empty") and the platform checks it every time it runs. The result is binary and honest:

• 🟢 Pass — the data complies. You can trust it.
• 🔴 Fail — something broke. OpenMetadata opens an incident and notifies.

The key part: the rule stays attached to the table, documented and versioned. It's not a loose script on an analyst's laptop — it's governance.

Step 1 — Open your table's quality tab

Open any table in your catalog and go to Data Observability → Data Quality. That's where all of the table's rules live: how many there are, how many pass, how many fail, and when they last ran.

In the example, the customers table already has two rules in green — customer_id unique and phone_number not null. That dashboard is what your team will see every morning.

Step 2 — Click "Add → Test case"

Top right, the Add button opens the menu. Choose Test case to create a new rule.

Step 3 — Pick the scope and the rule type

OpenMetadata opens a guided form. Just three decisions:

1. What does the rule run on? At the table level (e.g. "row count must be between X and Y") or the column level (e.g. "this column allows no nulls").
2. Which rule type? No SQL required: OpenMetadata ships a catalog of ready-made rules — values not null, values unique, values within a range, values matching a pattern (regex), row count, freshness, and more.
3. Name it and hit "Create". Done.

The rule is created and runs — manually or scheduled — alongside the rest. Green or red, no ambiguity.

Where to start: 3 rules worth gold from day 1

Don't try to cover everything. These three catch the most expensive (and most embarrassing) errors:

• Unique IDs (columnValuesToBeUnique) — on your master customer or product table. A duplicate ID poisons everything that joins to it downstream.
• PII not null (columnValuesToBeNotNull) — phone, email, document. A customer with no contact is a customer the business can't reach.
• Amounts in range (columnValuesToBeBetween) — top-ups, invoices, usage. Catches the classic $99,999 amount that pollutes your whole revenue.

With those three you already have a seatbelt on your most critical data.

This is data governance, not a patch

A single rule is useful. Dozens of rules, tied to tables with an owner, a glossary and lineage, running on their own and opening incidents — that's a mature data governance program. It's the difference between firefighting and trusting your numbers.

At GalacticaIA we implement exactly this on OpenMetadata — catalog, lineage, quality and policies — until your governance is operational, with 15+ years of real Telecom and Fintech experience across LATAM.

Want to know where your organization stands? Start with a data maturity assessment or see how we approach OpenMetadata implementation.