Data Profiling Isn't Optional: What We Check Before You Build a Workflow

The report that looked right

The most dangerous data quality problems aren't the ones that crash a query — they're the ones that quietly produce a plausible-looking wrong number. A "unique customer ID" column with duplicates. A "signup date" column that's 30% null. A report can run cleanly and still be wrong.

What we check, and when

DataQloo profiles a dataset automatically at two points. First, in the Import Wizard, before you commit to saving a new dataset — you see each column's fill rate, unique value count, null percentage, and an average or top value, so problems are visible before anything is built on top of them. Second, in every workflow's Profile tab — a richer version of the same idea, including min/max/average/median and a distribution for numeric columns, or top-value bars for categorical ones.

What profiling doesn't do

This is descriptive profiling, computed from the data you're actually looking at — it's not a rules engine. DataQloo doesn't (yet) let you define an assertion like "this column must never be null" and get alerted when it's violated on a schedule; there's no scheduled monitoring at all today, since scheduled runs aren't built yet either. What exists is a fast, automatic sanity check at the two points where you're most likely to make a decision based on the data: importing it, and building on it.