Key takeaways
- Our Facebook group posting kept the same decision in two places. The approval lived in one file, and the gate that decides which group can be posted to lived in another. Nothing joined them.
- So approving a question did not release its group. The rotation stalled, seven of eight waiting questions sat approved for days, and empty slots kept asking for decisions that had already been made.
- An eighth question had no approval row at all. It held its group out of the rotation for six days, and nobody could see it.
- The fix was a read only report that joins the two records on the one key they reliably share, the question text itself.
- We deliberately did not make approval mark anything as posted, because a yes is not the same as done, and only the person who pasted it knows what the platform did.
In early September our Facebook group posting worked like this. An automation wrote a question for a specific group, the kind of real question that starts a conversation instead of an ad. It went to our approval inbox. When it was approved, a person pasted it into the group by hand, because at the time there was no safe unattended way to post into groups from the account that carries everything else.
A picker decided which group got which slot. It has hard rules: a daily cap, hours between posts, a long cooldown per group, and never a second question into a group whose last one is still open. That last rule is the one that matters here.
Nine empty slots in a row
Between September 4 and September 8, every slot came back empty. The picker's answer each time was the same: this group already has a question staged, waiting on a decision.
When a slot comes back empty, the system writes a card saying so, and those cards asked for a decision. Five in a row told us there were written questions waiting for approval. So we went to look at what was waiting.
Seven of the eight had been approved days earlier. One had been approved on September 2. The decisions had been made. The picker simply did not know, because the picker never reads the approval inbox.
Two records of one question
Here is the shape of it. The approval inbox holds the decision: should this be posted. The posting queue holds the state the picker gates on: staged, live, or skipped. A question stays staged until someone records what actually happened after the paste. Approving it in the inbox changed nothing in the queue.
Nobody designed that gap on purpose. Each record made sense on its own. The inbox is where every decision in our business goes, and the queue is where the picker keeps its rules. The trouble was that the system asked a person for the wrong thing. It asked for approval, which had already been given, when what was actually missing was the outcome.
The eighth question was worse. It had been staged on the morning of September 2 and never got an approval row at all. It was invisible in the inbox, so nobody could approve it, and while it sat there staged its group was locked out of the rotation. Six days, with nothing anywhere to look at.
The join, and the key that almost was not there
The first fix was a report. It reads every staged question in the queue, finds that question's row in the approval inbox, and prints what was decided. Approved, rejected, pending, or no row at all. Our posting board now shows the same thing on each card.
Finding the match was harder than it sounds. The obvious key is the group name, and it does not work, because the empty slot cards list group names too, so a name matches the wrong rows. The group's id would be ideal, and it is not in every approval row.
What every row does carry is the question itself, quoted word for word. So that is the key. It needed one repair first: the staging step wrote the question into the inbox with curly quotes and into the queue with straight ones, so a plain text match fails on any question with an apostrophe in it. The report straightens the quotes and collapses the spacing before it compares.
Why the fix does not close the loop for you
The tempting fix is obvious. When a question is approved, mark it posted and move on. We did not do that, and the reason is the most useful part of this.
Approval means yes, post this. It does not mean this was posted. The person might not have pasted it yet. The group might have held it for moderation, or declined it.
If the system marks it live on approval, it starts a three week cooldown for that group that may not be real. If it marks it skipped, it throws away a cooldown that may be real, and the next slot posts a second question into a group that just had one. That is exactly the behavior that gets an account restricted.
Only the person who pasted it knows what Facebook did with it. So the report is read only. It writes nothing, decides nothing, and never touches the queue. It turns an invisible stall into a visible list of outcomes to record, and the recording stays a human step.
What this means for your business
You have this shape somewhere. A quote approved in email while the job board still shows it pending. A refund signed off in chat while the order system still holds the charge. Wherever a decision is made in one place and enforced in another, a yes can sit for a week while everyone assumes it went through.
Look for the places where your team approves things. For each one, ask what actually changes when someone says yes. If the honest answer is "someone is supposed to go and update the other system", that is a gap. It is worth a simple check that lists what was approved and has not moved.
If you work with a GHL consultant Bay Area businesses use for approvals and automations, ask whether approving something in their setup changes the record that does the work, or only the record that holds the decision.
Want this built for you
We build approval flows and automations where a decision and its outcome are both on the record. Start at optechsol.llc.