Two Approval Rows Landed On One Line, And The One Already Acted On Could Never Be Marked Done

Key takeaways

• Every automation we run that wants to publish something writes one row into a single approval file. A dashboard turns each row into a card, and approving the card publishes the drafts and stamps the row.
• On October 9 our blog lane wrote its row for three drafts. Later that day another automation wrote its own row onto the same line, with no line break between them.
• The three posts went live that evening, about 50 minutes after they were created. Five days later the row still read pending.
• The dashboard publishes first and writes the decision second. A line holding two rows has too many separators for that second step to land.
• The fix was one line break. A second approval was safe, because posts that are already live get skipped. Nothing on disk records the first yes, so the row stayed pending until it was approved again.

Think of the job in your CRM that still says open. The crew finished it on Tuesday, the customer paid on Wednesday, and the card is still sitting in the "in progress" column because nobody dragged it. The work happened. The record did not. We run marketing automation in San Jose for our own business, and on October 9 our own records did exactly that to us.

How a row becomes a decision

Nothing we build publishes on its own. Blog drafts, social posts, ad copy, client messages: the automation stages the thing, then writes one row into one approval file. Each row is a single line with six cells, separated by a column character. An id, a date, which automation wrote it, what it is, where the draft lives, and the status.

Our dashboard reads that file and draws a card for every pending row. For a blog batch, the row carries a marker for each draft it covers. When I click approve, the dashboard publishes every draft the row names, and then writes the decision back onto the row. Two steps, in that order.

October 9

That morning our blog lane created three drafts and appended its row, one line, six cells, seven separators. Later that day a different automation finished its own work and appended its row too. It should have started a new line. It did not. Its whole row, seven separators and all, landed on the end of ours, glued to the last cell.

Scrolling the file, it looked like one very long row. To the dashboard, it was a row whose status cell contained an entire second row.

That evening the three posts went live. The timestamps on the posts say they were published about 50 minutes after they were created. Nothing on disk says who did it or how, and I would rather say that than guess.

Why the stamp never landed

When our next blog batch ran on October 14, the first thing it does is check prior rows. It found our row still pending, and the post list showing all three posts published. That is a contradiction, and the checker we run on the approval file explained it in one line: the row contained seven extra separators inside a cell. Its own words were that a stray separator shifts every cell, and a stamp would overwrite the wrong one.

The most likely story, and the only one the file supports, is that the dashboard did the first half of approve and the drafts went out. Then it went to write the decision onto the status cell, and the cells were no longer where it expected them. Wherever that stamp was aimed, it did not land, and a stamp landing on the wrong cell would have damaged the other automation's row as well.

So the posts were live while the record said they were waiting, and nothing anywhere was wrong enough to raise an alarm.

The fix, and what we did not fix

The repair was one line break. The batch split the two rows back onto their own lines, ran the checker again, and it came back clean. Then it stopped, on purpose.

It would have been easy to stamp the row approved by hand, because the posts were obviously live. We did not, because no file records that yes. Our rule is that a row's stamp means someone decided. A stamp I write because the outcome looks right is a guess that happens to match, and the next person reading the file cannot tell the two apart. So the row stayed pending, and so did the promos that wait on it.

When the row was approved again on October 14, the dashboard did the safe thing: it saw all three posts were already live, skipped them, and wrote a stamp saying so. That is why publishing before stamping is survivable. A second approve cannot publish something twice.

The honest lesson

A record can be wrong in two directions. It can claim work that never happened, which is the one everybody watches for. Or the work can happen and the record can fail to catch up, which looks like nothing at all. The second one hid from us for five days because every signal we check was quiet.

Our own lane runs the checker right after every append. The row that broke ours came from a lane that had not, so the habit we are pushing to every automation that touches the file is append, then check, in the same run. And when a status has not moved in longer than it should, look at the thing it describes before you trust the status.

What this means for San Jose businesses running marketing automation

Your CRM has the same two steps hiding in it. An automation sends the quote and then moves the card. A rep finishes the call and then logs it. Any time the doing and the recording are separate steps, one of them can succeed alone.

• Pick the stage that matters most, closed or paid or scheduled, and once a week compare it to the real list. Invoices sent, jobs on the calendar, posts live.
• When a card has sat in one stage longer than your average, open the actual record before you follow up. You may be about to chase a customer who already paid.
• If a tool writes to a shared file or sheet, check that each entry starts on its own line.
• Decide in advance what counts as proof of a decision. If nobody wrote it down, treat it as not decided, even when the outcome looks obvious.

If your marketing automation in San Jose shows cards that never move, the automation may be fine. The bookkeeping behind it is where to look first.

Want to build this yourself?

Join the On Point Tech Academy at optechsol.llc/academy. It's free, and we build live every Tuesday and Thursday.