Who Can Refuse to Publish? Designing an Editorial Workflow With Real Gates

Ask a team to describe its editorial workflow and you get a list of statuses: draft, in review, ready, scheduled, published. Ask a different question, which is what happened the last time somebody wanted to publish a page and could not, and about half the time the answer is that it has never happened.

That is the tell. A status is a label. A gate is a thing that says no. If nothing in your process can refuse to publish a page, you do not have a workflow — you have a vocabulary, and it will hold right up until the week somebody publishes a price that was never approved.

Editorial workflow gates are the part every team skips, and the reason is not laziness. Designing a gate means deciding who is allowed to block whom, which is a political conversation wearing the costume of a configuration screen. Statuses are easy because they commit nobody to anything.

What follows is how to tell a gate from a notification, which states are worth having, three gate designs we would actually build, and how to stop any of them turning into a queue that everybody learns to route around. It applies whether the publishing practice runs on a hosted CMS, a repository, or a shared drive nobody admits to.

A workflow is whatever can stop a page

Take your workflow diagram and delete every box that cannot block a transition. What remains is the workflow you actually have. On most teams that is one box, sometimes none, and the deleted boxes were places where somebody gets told about a change after it has already happened.

The diagnostic question is concrete: name the last page that was stopped, who stopped it, and what happened next. If nobody can remember one, the gate is decorative. This is the same argument our parent company makes about drafts, in where drafts live and what stops them: storage and process look like separate topics until you notice that the only real part of a workflow is the part that can say no.

A notification is not a gate

A notification informs somebody. A gate prevents something. Most CMS approval features are notifications with an approve button attached, and nothing in the system depends on that button ever being pressed. Which is fine, as long as everybody knows it. Nobody ever does.

Three questions separate the two. Can the publish action be performed while the check is unsatisfied? Is the rule enforced by the system, or remembered by a person? And the one that finds the truth: what happens at six on a Friday when the approver is unreachable and a campaign starts on Saturday? If the honest answer is that somebody uses the other button, you have a notification.

Being honest about this is more useful than fixing it immediately. A team that knows its review step is advisory behaves carefully. A team that believes an advisory step is a gate stops reading the pages, because they assume somebody else already did. The belief in a gate that does not exist is worse than having no gate at all.

States that mean something

The test a state has to pass

A state earns its place only if some transition out of it is restricted. "Ready for review" that anybody can move straight to published is draft wearing a hat. Run the test across your list and it usually collapses to three or four real states, which is a good outcome: fewer states, each of them meaning something. The three most commonly muddled are the subject of preview, draft and publish.

The states most teams need

Draft is private and freely editable. In review freezes the content, or does not, and you must pick one and mean it. Approved says the words are signed off but the timing is not. Scheduled is approved plus a time, and it is worth keeping separate so legal can sign off on Tuesday for a Thursday launch without also owning the launch date. Whether a scheduled state is real at all depends entirely on the mechanism behind it, which is the subject of scheduled publishing on a static site.

Then published, and then retired, which almost nobody models and everybody needs. Retired means removed from navigation while the URL still resolves or redirects somewhere sensible. Without it, the only way to take a page out of circulation is to delete it, and deleting pages is how an archive quietly turns into a list of broken links.

One more confusion worth clearing while you are here. Permissions and states are not the same thing, and most CMS interfaces encourage you to conflate them. A permission says which people may perform an action. A state says which actions are available on this particular page right now. You need both, kept separate, because every rule worth writing is conditional: this author may publish a blog post but not a pricing page, and nobody may publish anything at all while it sits in review. Systems that model only permissions end up with a role called Editor that means four different things depending on who you ask about it.

Roles, and what each one is allowed to refuse

The design constraint that matters more than any other: each role refuses on a named ground. A role that can refuse on any ground is not a reviewer, it is a bottleneck with a job title, and everything downstream of it will eventually be organised around avoiding it.

• The author. Can refuse to publish their own work, at any point, without explaining why. This sounds trivial and it is the only refusal that never needs escalating, which makes it the most reliable one you have.
• The editor. Refuses on accuracy, structure and duplication, including whether the page has anywhere to sit in the internal link graph. A page nothing links to and nothing needs is a page that should not have been commissioned.
• The subject owner. The person accountable for the claims: legal, security, finance, whoever owns the numbers. Refuses on substance only. Explicitly cannot refuse on tone, and saying that in advance saves a great deal of unpleasantness later.
• The release owner. Refuses on timing and collision: two launches in one week, a page going live during an incident, a change landing an hour before a migration cutover. Says nothing about the content, and is often the only person who can see the whole calendar.

Three gate designs

These are not alternatives. They catch different classes of error, and a serious publishing operation runs all three, applied to different classes of page.

The second pair of eyes

One other person reads the page before it goes live, and the system makes publishing unavailable until that is recorded. It catches wrong facts, claims nobody can support, tone that has drifted, and the page that duplicates one published eighteen months ago. It misses everything mechanical, and everything the reviewer happens not to know.

Where publishing is a commit, this gate already exists and is called a pull request, which is worth noticing before anybody builds a second approval system beside it. A structured workspace such as Acrosite takes that route deliberately: editors work in forms, the workspace generates the files, commits them to GitHub and triggers the configured deployment, so the review that stops a page is the one your engineers already trust.

The machine gate

Automated checks that run before a deployment is allowed to complete. Required fields present, internal links resolving, images carrying alternative text, heading order sane, structured data valid, no accidental noindex, no canonical still pointing at a staging host. It never gets tired, it runs at three in the morning, and it is the only gate that costs no human attention once it has been written. Running the checks as workflow jobs on every change is ordinary engineering, and the accessibility half of the list maps directly onto the WCAG success criteria you have already committed to.

What it misses is meaning. A page can pass every check ever written and still say the wrong thing. What it catches is precisely the class of defect behind organic traffic falling after a redesign, where nothing looked broken because, taken individually, nothing was. Build this gate first if you only build one.

The named owner gate

Certain classes of page have one named owner and nobody else may change them: pricing, legal terms, security claims, anything asserting a number. It catches the political class of error, which is the change nobody had the authority to make and which no reviewer would have questioned because it looked like an ordinary edit. It needs your content model to know which class a page belongs to, so it arrives nearly free if you have done the work described in content modelling for teams that keep adding page types, and is painful to retrofit if you have not.

What each gate buys you

Read the middle column before the left one. Teams pick gates by what they catch, then act surprised by what still gets through, which was entirely predictable on the day the gate was designed.

Keeping a gate from becoming a queue

Every gate that fails does so the same way. It becomes slow, people route around it, and within a quarter the official process describes something nobody actually does. Six rules keep that from happening.

1. Classify pages by risk before assigning gates. A pricing page and a conference write-up do not deserve the same ceremony. Applying one process to everything is how the process gets abandoned for everything.
2. One approver, never a panel. Two named approvers means each waits to see what the other says. If a page genuinely needs two, make the second one sequential and say so in writing.
3. Put a clock on it. A review not completed within two working days either escalates or auto-approves. Decide which, per risk class, before the first time it matters.
4. Make the state visible where the work happens. A gate whose status nobody can see becomes a person asking in a chat channel, which is a queue with worse reporting.
5. Measure the wait, not the volume. The number worth putting on a wall is time from ready to live. Counting approvals measures how busy the gate is, which nobody needs to know.
6. Delete gates that have never refused anything. A gate with no refusals in a year is a tax collected for a service not rendered. Remove it and watch whether anything breaks.

The rule people resist most is the third, because auto-approval sounds like giving up. It is not. A gate with no time limit does not become a stricter gate, it becomes an unreliable one, and unreliable gates are exactly the ones people learn to work around. Deciding in advance that a low-risk page goes live after two working days is a stronger position than pretending a review will always happen on time.

The bypass, and other honest costs

Now the concession. Gates cost real time, and on a team of two who sit together, a formal system is worse than a habit. Below a certain size the whole apparatus is overhead pretending to be governance, and the gate is simply that the two of you talk before anything goes live. That stops being true the moment a third person joins, a second site appears, or a page starts carrying legal exposure. Those are the three triggers, and they tend to arrive in that order.

There is a further cost worth naming. Gates create a record of who approved what, and that record is occasionally uncomfortable to look at. It is also the only thing that answers "who signed off this wording" a year later, which is a question that tends to arrive with a lawyer attached. The discomfort is the feature.

Where we would start

List the last ten pages you published and ask, for each one, what specifically would have refused it if it had been wrong. Not whether it was reviewed: what mechanism would have said no. Most teams find that eight of the ten had nothing at all, and that the two exceptions were both caught by the same person happening to read something.

Then add exactly one gate, and make it the machine one, because it costs nobody any attention after the week it is written. Wire it into whatever already runs on deployment, keep the checks alongside the maintenance work so they stay current as the site changes, and only then start the harder conversation about which humans may refuse what.

The condition under which we would reverse this advice: if your problem is that nothing gets published, rather than that the wrong things do, adding gates is the exact opposite of what you need. Fix throughput first, because a gate on an empty pipeline is theatre. If you want to work out where your own process would break, our way of working opens with this question, and you can tell us the shape of your team to start it.