An editorial workflow that survives a Tuesday
Most workflows are described in a document nobody reads and enforced by a person who is on holiday. The one that survives is the one the tool refuses to let you skip.
Most editorial workflows are described in a document nobody reads and enforced by a person who is on holiday. The workflow that survives a Tuesday is the one the tool refuses to let you skip — not because anybody is untrustworthy, but because a rule nobody can forget is a rule that does not need a meeting to reinforce.
States, not intentions
A draft is not ready for review because somebody typed "ready for review" in a chat window. It is ready because it validates, because an editor moved it, and because there is a published version to compare it against. Anything else is a status meeting with a database attached, and the database loses the second somebody is busy.
The publish step is the one worth being strict about. If publishing is a button an author can press, then it is a button an author will press on a Friday — so schema validation and the review requirement belong at that boundary rather than at the door to the studio, where they only slow down work that was never going to ship badly.
A workflow is a set of things the tool will not do, not a set of things people have agreed to do.
What to enforce, in order
- Required fields at publish — an incomplete draft is fine, an incomplete publish is not.
- Validation with reasons attached, so the author can fix it without asking anybody.
- A preview drawn by the real renderer, so "looks fine here" means something.
- A publish that can be taken back, because the schedule will be wrong once.
Start with the first two. They are mechanical, unglamorous, and they remove most of the coordination a content team is currently paying for with meetings and reminders.
The last one is a query away at any time: the posts that have been written and never dated are the ones a workflow is failing to move.
count(*[_type == "post" && !defined(publishedAt)])
Maya Chen
Head of content operations
Maya ran content operations for a publisher with eleven mastheads before joining Achar. She spends most of her time on the unglamorous half of content: naming things consistently, retiring things on purpose, and making sure the person who wrote a headline can still find it a year later.
Related posts
Your content model is the product decision
Every content system fails the same way: a field that grew a second meaning, and a template that reads it both ways. The model is the one thing you will still be living with in three years.
A content lake is not a CMS
A CMS owns your pages. A lake owns your content and has no opinion about your pages, which sounds like a small distinction until the second frontend arrives.
Draft, publish, and the two-row trick
Achar stores a draft as a second document whose id begins `drafts.` rather than a flag on one row. It looks like duplication, and it is the reason a headline can be rewritten for a week without touching what the site serves.