A wrong number on a finished report almost never comes from the workflow that built it. When a dashboard shows a number that looks off, the reflex is to open the workflow and start checking the logic. Usually the logic ran exactly as designed; the defect entered earlier, in data nobody looked at first.
The common culprits repeat across teams. A null value should have stopped a calculation but passed through blank. A duplicate row inflated a count. A reading fell outside a valid range without triggering any alert. A schema change arrived silently and shifted what a column even meant.
Rebuilding the workflow after something breaks doesn’t fix anything. Placing a check at the point where data enters the process does, and that check has to hold up for three different people, not just the one who built it.
The analyst inherits every defect the workflow doesn’t catch
For the analyst who owns the workflow, verification is a manual habit competing with a deadline, and manual habits are the first thing skipped when a deadline gets tight. There is no systematic way to confirm the input is right before the workflow runs on it.
Dana owns exactly that problem. She’s an analyst on the plant analytics team at a tier-one automotive parts manufacturer, and her weekly first-pass-yield workflow pulls readings from the final-assembly line’s MES feed into the report the plant reviews every Monday morning. Operations leans on that report to decide whether a line needs attention before the next shift starts, so a wrong number doesn’t just sit quietly in a spreadsheet.
She used to eyeball row counts and spot-check a sample of readings before running the report each week. That worked fine when volume was low, when a handful of readings could stand in for the whole shift. As the line scaled to hundreds of readings a day, the spot check shrank to a rushed glance before a deadline, then to trusting the feed outright.
A firmware update on the final-assembly station’s torque sensor changed what happened when a reading fell below 2.4 Nm. Instead of logging those readings as failures, the sensor simply stopped writing a row for them. The out-of-spec units never appeared in the dataset at all.
Dana’s yield calculation only ever saw passing readings. It reported first-pass yield climbing for three straight weeks while the line’s actual reject rate was quietly rising underneath it.
The gap ran deeper than the sensor. Nobody had entered the true torque spec, 2.4 to 2.6 Nm, into the MES’s own limit table. It existed only in a quality engineer’s personal spreadsheet, so even a complete dataset would have had nothing stored to check itself against.
That’s a profiling problem before it’s anything else: verifying what’s actually in the incoming data before trusting what comes out the other end, checked against a spec limit that lives somewhere other than one person’s file. It has to run as part of the workflow’s normal execution, not as a separate manual task competing with the same deadline pressure that caused the gap in the first place.
What a check would have needed to catch
- A row-count comparison against the shift’s expected production volume, to catch silently missing readings, not only bad ones.
- A range and threshold validation against a stored spec limit, not one living in a single person’s file.
- A null or blank check on the sensor field itself, since this failure showed up as absence, not as an error value.
- A hold on the batch, not just a note, when a shift fails these checks, so a bad shift doesn’t roll into the weekly number unnoticed.
Before the next report goes out, it’s worth tracing the last unexplained number back to its actual origin. More often than not, the workflow did its job. The data reaching it was the problem, and nobody checked it going in.
IT won’t trust a workflow it can’t verify
IT asks a different question than the analyst does. The analyst wants to know whether the data passed the check. IT wants to know who changed the check, when they changed it, and whether that change can be proven after the fact.
That question came up the moment Dana’s team wanted the yield check to run automatically every shift, instead of only when she remembered to look at it. IT’s first question centered on access, not logic: who else could edit the spec-limit thresholds behind it, and whether a change to those thresholds would leave any visible trace.
Teams evaluating any platform for this kind of work look for the same two things: changes to workflow logic that are logged and attributable, and controlled access to who can edit a check running in production. Neither is optional once a check stops being a personal habit and becomes something a plant depends on every shift. A workflow that runs unattended is still code touching production data, and IT treats it that way regardless of who wrote it.
The tension is real and it doesn’t resolve on its own. Analysts want a check that’s fast to adjust the moment a spec limit changes, since a slow change process just invites people to work around the check instead of updating it. IT wants every one of those adjustments traceable, for exactly the same reason: an untracked change is indistinguishable from an error until someone proves otherwise.
A workflow that makes changes easy but invisible satisfies neither person. It just moves the risk from a check that might be wrong to a check that might have been changed by anyone, with no record of it.
What IT needs from a solution is specific: changes have to be attributable and reviewable, without turning every spec-limit tweak into a ticket queue that discourages analysts from keeping the check current in the first place. Get that balance wrong in either direction and the check stops being trustworthy to somebody.
What IT actually reviews before trusting a workflow
- Who can view, edit, or run the workflow that contains the check, not just who can view the resulting report.
- Whether a change to the check’s logic, like a spec limit, is recorded with who made it and when.
- Whether a failed check is visible somewhere an admin can see it, not only in the analyst’s own run log.
- How long that change history is retained, and whether it can be exported for a compliance review.
The plant director doesn’t see the check, only the number it would have stopped
The plant director never sees the check, only the number it would have caught or missed. Presenting a weekly yield figure to corporate means trusting the workflow behind it sight unseen, with no way to know whether anything actually verified the number before it reached the deck.
That’s exactly what happened at Dana’s plant. Three straight weeks of climbing first-pass-yield numbers went into leadership review before a customer complaint about defective units forced a manual audit. The audit found the sensor gap only after the fact; by then, the number reported upward had already been wrong for three review cycles.
The pattern isn’t isolated to one plant. A 2025 Deloitte survey of 600 senior manufacturing executives found that scaling smart-manufacturing and AI initiatives is limited, industry-wide, by poor data quality, weak governance, and fragmented systems.
The stakes show up at the executive level too. A 2025 IBM Institute for Business Value study found that 43% of chief operations officers identify data quality issues as their most significant data priority, ahead of nearly everything else competing for their attention.
A plant director doesn’t care about the mechanics of a check. The only question that matters going into a leadership meeting is whether the number in front of them has already been verified, not whether the team can explain afterward why it wasn’t.
A wrong yield number reported upward for three weeks isn’t a data problem from where a plant director sits. It’s a customer-facing quality miss, and it’s a credibility problem the next time the team reports any number at all. Rebuilding that trust takes far longer than the three weeks it took to lose it.
Where the three interests align, and where they don’t
All three stakeholders are served by the same underlying thing: a check that runs automatically, every time, without depending on whether an analyst remembered to look before a deadline. That much is shared ground.
Where they diverge is in what each one needs to see about it. Making a check fast for an analyst to adjust, say a spec limit changes or a sensor gets replaced, can work directly against IT’s need for that same change to be reviewed and attributable. Speed and traceability pull in opposite directions unless both are designed for at once.
The second friction sits between the analyst and the plant director. A leader wants a clean number, or a clear flag that something failed, not the level of detail an analyst or IT needs when a check actually breaks. Handing a director a run log solves nothing, and handing an analyst only a pass or fail flag solves nothing either; each stakeholder needs a different slice of the same event.
This resolves into a requirement, not a negotiated compromise: the check itself has to be identical for everyone, automated, running on the same schedule regardless of who’s watching. What differs is what each stakeholder sees about it: an edit log for IT, a pass or fail flag for the director, a verified number for the analyst to build on.
Unmanaged data quality problems carry a real, quantified cost. Organizations lose at least $12.9 million a year on average, according to Gartner research. That figure holds across industries precisely because the underlying failure is the same one playing out at Dana’s plant: nobody owns the check itself, so the cost of a defect gets discovered downstream, by whoever happens to be holding the bad number when it finally shows up.
Run the scenario through again and the same embedded check would have served all three. It would have given Dana the row-count and threshold verification she used to do by hand. It would have given IT a change to the spec-limit logic visible somewhere other than her inbox. And it would have given the plant director a yield number that was already vetted instead of one waiting on someone to notice a problem.
What a solution must satisfy for all three
The requirement across all three stakeholders is the same. The check has to live inside the workflow itself, not in a person’s habit of remembering to look, and it has to run on a schedule that doesn’t depend on anyone requesting it.
That means the workflow needs a way to see, column by column, whether incoming data is complete and valid before it gets used, and a way to fix common issues like nulls, stray characters, and inconsistent casing as part of the same process that prepares the data, not a separate manual pass. That second piece is what data cleansing actually means in practice: correcting the data, not just flagging it.
IT’s requirement from earlier was specific: a record of who changed the check and when, that can be proven after the fact. Platforms like Alteryx One answers that need through audit logs, which track changes to workflow logic as logged, attributable, exportable events, kept separate from the check’s own pass or fail result rather than a substitute for it.
Teams still building out that first layer can start with these data preparation resources, which walk through the mechanics in more depth.
That check only becomes routine once it stops waiting on anyone to run it manually. The same workflow can be scheduled to run automatically every shift, so the profiling and cleansing sequence repeats on its own instead of depending on someone remembering to check.
A column-by-column profiling tool can show nulls, blanks, and out-of-range values as data moves through the workflow, which answers the analyst’s original problem directly: seeing what’s actually there before trusting it downstream.
A dedicated cleansing step handles the common fixes, like nulls, stray whitespace, and inconsistent casing, as part of that same process rather than as a separate task squeezed in before a deadline.
Building the shared case
Framing this as “a new tool for data quality” invites budget scrutiny and vague pushback. The sharper case rests on the specific failure the scenario exposed: three weeks of a wrong number reaching leadership review, and the specific fix it demands: checks embedded in the workflow and scheduled to run, not remembered.
The analyst’s talking point should quantify the failure mode itself, not a vague industry aggregate. A missed check doesn’t cost “data quality” in the abstract. It costs a full shift’s worth of units built to the wrong tolerance before anyone notices, with rework or scrap to show for it, plus the hours spent afterward reconstructing what actually happened on the line.
IT’s ask is smaller than it sounds. Rather than asking anyone to trust the analyst’s spreadsheet outright, it asks to see the check’s logic and its change history, a narrower and more answerable request than a full platform review, and the one IT actually needs answered before signing off. Framed that way, the conversation moves from a general security review to a specific, bounded question IT can say yes to.
The leader’s talking point is about risk, not initiative. This isn’t a new project competing for budget attention. It’s risk reduction on a number the plant already reports upward every week, one that already cost a customer complaint once, and one more miss would be harder to explain the second time.
Put together, these three points converge on a single ask: one change to how the yield workflow runs that gives each stakeholder exactly what the previous section described. IT gets an audit trail, the analyst gets a scheduled check, and the director gets a verified number.
Testing that change directly is the fastest way to see whether it holds up under a real production schedule. Alteryx One’s free trial runs for 30 days, long enough to build the check, schedule it, and watch it catch the next bad shift before it reaches a report.