A status update in my content queue erased the questions I had left open

What I expected

My content pipeline works from a queue: a plain table with one row per item and a status cell at the end of each row. A drafting step writes the next waiting items and marks their rows. A checking step looks at each draft. A scheduling step gives each draft that passes the next free publishing date, and a separate publish job puts scheduled items out automatically at 00.

One more thing lives in that status cell. When the drafting step needs me to confirm something before an item can go out, it leaves a short question for me in the same cell, after the status. My mental model was simple: each step moves the status along, and nothing removes a question except me answering it.

What actually happened

In September, the questions disappeared from the queue.

The scheduling step was the cause. When it scheduled a draft, it wrote the row’s status cell as a whole new value. The cell had held the old status and the questions; afterwards it held only the new status. The questions were not moved or hidden. They were overwritten.

The illustration below shows the shape of one cell (not the exact text):

Moment	Status cell
After drafting	drafted · Q: question for me
After scheduling	scheduled (date)

Two things were lost at once: the questions themselves, which I had not answered yet, and what they meant. A draft with an open question is a draft I have not confirmed. Those drafts had been given publishing dates like everything else.

How I noticed

By reading the queue. I was about to gather every draft that carried a question so I could answer them. Right before doing that, I re-read the queue, and the questions were not there.

That is worth noting on its own. Losing text does not look like a failure to the step that overwrote it, because from its point of view it did exactly its job. A check that only watches for errors would have had nothing to report.

Why

The scheduling step was written when the status cell held only a status. Then the drafting step started appending questions to the same cell. From that point two steps wrote to one field, and only one of them knew the field had two parts. One appended; the other replaced.

There was also a quieter gap. A question was something for me to read, not a condition any step would stop for. Nothing in the pipeline treated “this draft has an open question” as a reason to wait.

What I changed

1. Recovered the questions. The drafting step keeps a log of what it wrote, including the questions. They were restored from there.
2. Took the affected drafts off the schedule. 13 drafts had carried questions. All 13 were moved back to the unscheduled placeholder date before the 00 publish ran, so none of them went out with a question unanswered. They waited until I had answered.
3. Made an open question stop the line. The scheduler now holds any draft that has open questions instead of giving it a date. The question is no longer just text in a cell; it is a condition.

What this has to do with hiring someone

Most business automations update a record somewhere: a status column in a sheet, a stage in a CRM, a tag on an order. Sooner or later a person adds a note to the same place, or a second automation starts writing to it. The first automation keeps doing what it was built to do and quietly overwrites what it did not know about. That never shows up in a demo. It shows up weeks later, as something missing.

Three questions are worth asking a freelancer before the build:

• Which fields does each step write, and does it replace them or change only its own part? Ask for a list. Any field written by two steps, or by a step and a person, needs a rule.
• What should stop the automation and wait for a person? A flag or an “unsure” note should be a condition the automation checks, not text it happens to carry along.
• What does the log keep? If the log records the full text each step wrote, a lost field can be restored. If it records only “done”, it cannot.

At acceptance, add one test to the usual ones: put a note of your own into a field the automation updates, let it run, and check that the note is still there. It sits well next to the forced-failure and duplicate-run tests in the acceptance checklist for unattended automations. If the automation also publishes on a timer, read how cron schedules work so you know exactly when the point of no return is, and put an alert on anything that should have stopped the line; the error alerts brief covers what that alert should say.