"Import complete", zero rows imported

13:17. A user reports that the day's bank import produced nothing. Yet everything is green, and the job says "Import complete".

Everything is green, and there's nothing

The user is right. Not a single row arrived. And the job says it succeeded.

It's the worst-case scenario. A failure that makes noise, you see it. You fix it. A failure that says "complete", the tool doesn't see. It takes someone who knows their figures and is surprised not to find them.

That day, it was a user who noticed. Not the tool.

What happened

The import receives an Excel file. The automated job was reading it as a plain text file. Inevitably, the read failed.

So far, nothing serious. A job that fails, you notice. Except that one step further on, another rule deleted the rows in error.

Every row was in error. They were all deleted.

So nothing was left. And nothing, for a machine, is a success. No rows to process, so no errors to report. The job finished normally. It showed green.

Taken alone, each step made sense. Chained together, they produced a false "complete".

A step that deletes the rows in error can be a good idea. On one condition: that something counts what it deletes, and says so.

At 14:55, 117 rows and 62 positions

Fixing the read is simple: read the Excel file as an Excel file. At 14:55, it's fixed. 117 rows imported, 62 positions created.

We could stop there. The day's problem is solved.

To be honest, the real problem wasn't. The same chain could still, on another day, show green on an empty import. For a different reason, with the same consequence: teams who believe their figures are up to date.

The real fix

The real fix doesn't touch how the file is read. It touches what the tool says.

• Zero rows gets said out loud. When the import brings back zero rows, the message says so in plain words. No more "complete" on an empty import.
• A failure gets shown. When something fails, the alert email carries the link to the run in question. You click, you're on the run that failed. No need to look for it.

With the first point, the screen would have said "zero rows" instead of "complete". That's all it took for the tool to warn people before the user did.

The second helps on the days when something really breaks. An alert without a link forces you to search for where it broke. An alert with the link removes the search.

A rule on every project

On every project, I hold myself to a simple rule: every alert email carries the link to the run in question.

It's not a technical detail. It's the difference between "something failed" and "here's what failed, click here". The first sentence worries you. The second lets you act.

And an import that brings back nothing has no right to show green. Zero rows is information. It has to reach you.

What this means for you

Look at your automated imports. Not the ones that break down: the ones that show green.

• If today's import brought back zero rows, would the screen say so? Or would it say "complete"?
• When a job fails, does the email you receive say where to look? Or do you have to find the run by hand?
• Who, in your company, would notice an empty import? The tool, or a user who knows their figures?

If the answer is "a user", your tool is counting on people's vigilance. It works, until the day nobody is looking.

This import is part of a bigger story, told in the timestamped green dot and in the case study The green dot. Another silent error, this time in a treasury tool: the 500-row limit. Alerts and scheduled imports are described on the page Tasks that run by themselves.

The dangerous error isn't the one that makes noise. It's the one that answers "all good".