A post in review waits for one approval: somebody on your team from the workspace, or the client from their portal, whichever arrives first. There is no order between the two and it is never both. Review is switched on client by client, and with it off the piece is scheduled the moment it is saved.
Why one yes is enough
Most tools that sell an approval workflow are really selling a chain: the team reviews, then the client reviews, and nothing goes out until both boxes are ticked. It sounds rigorous and in practice it produces two things, a calendar that jams on the busiest person in the chain and a pile of posts that go out late because somebody was on holiday.
Here a piece waits for one signature, not two. Either side can give it: a colleague from the app, looking at the piece as it is assembled, or the client from their portal, looking at it the way it will be published. The first one counts. The client does not wait for your team and your team does not wait for the client.
The fair objection is whether that loosens control. It does not loosen it, it moves it. What an approval contributes is not the number of times somebody says yes, it is that who said it and when is written down against that specific piece. The difference gets very concrete the day a client insists they never saw something that went out, and the answer is on the post itself with a date and a name, not in an email folder.
There is a third reading, less noble and more useful: a compulsory second reviewer gets skipped. Once a two step chain starts costing people their dates, they switch the whole thing off and go back to no control at all. One step that gets followed is worth more than two that get dodged.
The switch lives on the client, not on the workspace
Review is not switched on for the whole agency at once. It is a per client switch, because what you agreed with each one is different: some clients want to see every piece before it goes out and some hired you precisely so they would never have to look. With it off, a piece moves from draft to scheduled when it is saved and nobody approves anything.
| Agency | Company | Creator | |
|---|---|---|---|
| Approvals module | Yes | Yes | Does not exist |
| Decided per | Client by client | The whole workspace | Nothing to decide |
| Who can say yes | Your team or the client | A teammate | Nobody |
| A portal the client signs into | Yes | No clients | No clients |
| Approvals per piece | One | One | None |
| With review off | Scheduled on save | It does not switch off | Scheduled on save |
A company workspace, with an in house team and no third parties, has neither that switch nor a use for it: there are no clients and no portal, and every post waits for one teammate's yes, which is exactly the review that model asks for. A creator workspace has no review layer at all, and it is right that it does not. Approving your own work is filling in a form, not a control.
Which people on your team can approve and which can only write is a question about roles and is settled separately, in the workspace's roles and permissions. And the client's yes needs them to have an account and sign in, which is what the client portal is for.
The board, and its fourth column
The review queue is not a mailbox, it is a board with four states, and the fourth one is the one nobody expects and the one that gets used most.
- Pending. Waiting for that yes, with its planned date up front, which is what lets you sort by urgency instead of by age.
- Approved. Somebody signed. The piece becomes scheduled and enters the brand's calendar with its hour set.
- Rejected. Somebody asked for changes and wrote why. Rejected is a status, not a deletion: the piece stays with the reason in plain sight and comes back by editing it and sending it round again. Nothing leaves the queue in silence.
- Needs rescheduling. The piece got its yes, but its hour had already passed while it waited. It is not published late and it is not thrown away: it is set aside for somebody to give it a new date.
The board is per brand and sorts by planned date, so what sits at the top is what publishes soonest rather than what was written first. How the queue looks from the inside, with its four columns, is on the approvals page.
That fourth column exists because the case is real and invisible to everything else. A piece planned for Thursday at 10:00 and approved on Thursday at 18:00 has no good automatic answer. Publishing it instantly pushes it out at an hour nobody chose; publishing it quietly the following Thursday is worse. Setting it aside and saying so is the only option that does not lie.
The clock, so it never reaches that column
What prevents most of those stranded pieces is warning in advance. With review switched on for a client, a warning goes out three days before the piece's date and another one the day before. They go to the client, signed with your workspace's name, and the piece is inside them exactly as it will be published.
Two warnings and no more, and the reason is one that anybody who has built reminders knows: the third one stops being read and drags the first two down with it. At three days there is room to produce a change; the day before is the last moment the change still fits.
The clock is what makes an approval compatible with a cadence at all. With no warning, a review queue forces your team to chase by hand, which is exactly the work the tool was meant to remove. With it, the product does the chasing and your team only looks at what is still pending on the eve.
Everything in this article happens in one place in GoFeed.
Try it freeWhat ends up written on the piece
Every decision is stored on the post rather than beside it. The approval, with its date and who gave it. The rejection, with the text whoever asked for the change actually wrote. The rounds after that, in order. If a piece was rejected twice and approved on the third pass, that reads in three lines without leaving it.
That settles three conversations that normally cost an afternoon. The first is "I never approved this", which stops being an argument. The second is "why did this go out a week late?", which now has an answer with hours in it. The third, and the most common, is the new person on the team who inherits an account and needs to understand what that client likes: reading ten rejections with their reasons teaches more than any brand document.
The text of the change travels with the piece, which is the detail that looks minor and is not. A comment in an email makes somebody copy it by hand to the place where the piece is edited; a comment stuck to the post is in front of whoever is correcting it, at the moment they correct it. How this chains into the calendar is covered in calendar and publishing.
Where an approval does not fit
It is worth saying what this is not, because the word approval carries expectations from a different kind of product.
It is not an electronic signature and carries none of the weight of one. It is an internal record of who cleared a post, with the hour attached, and it is there to work with and to clear up a misunderstanding. A contract needs something else, and that something is not here.
It is not a wall. With the switch off for a client, their pieces are scheduled without anybody looking at them, and that is the default on purpose. "Nothing goes out without a yes" is only true of the clients who have review switched on, and saying it about all of them would be false.
And it does not replace the conversation you have first. An approval queue full of rejections is not a process that works, it is a sign the brief was never properly agreed: the work of aligning expectations happens at the start with that client, and how that first week is put together is in the client onboarding checklist. Review is a net, not a plan.