Content approval workflow: how to design approver roles and routing rules

A content approval workflow is the rule set that decides who signs off on each deliverable, in what order, and what state the work sits in while they decide. It is the layer above file review. A single-asset approval workflow answers "what happens to this file's versions on its way to sign-off." This article answers the harder question: you publish 20+ pieces a month across several clients and formats, and every one of them needs a pre-agreed path through your team and theirs.

If you cannot say, for a given content type, who approves it first, who approves it last, and which of those two can stop production, you do not have a workflow. You have a habit that happens to work when everyone is paying attention.

This guide gives you a roles table, a routing decision table, and a worked month with numbers. Adapt the numbers to your own team; they are illustrative, not benchmarks.

What a workflow covers that a single review does not

Three things belong in the workflow layer and nowhere else:

• Assignment of authority. Named people, per content type, with one final approver. "The client" is not an approver.
• Routing order. Which approvals can run at the same time and which must wait for the one before.
• State. Where the work is right now — internal review, client review, changes requested, approved — stored on the work item, not in a chat thread.

Everything else (timecoded comments, version history, watermarking) is tooling that supports those three decisions. Get the three wrong and the tooling just lets you fail faster.

Define who approves each content type

Most broken approvals come from treating all content as one category. A four-person studio shipping longform video, short clips, and social copy has three different risk profiles and therefore three different approval chains.

Write the table once, keep it visible, and review it quarterly. An example you can copy and edit:

Two rules make this table work in practice. First, the client side names a person, not a department. Second, if two client-side people disagree, you route their disagreement back through their single named approver rather than collecting both sets of notes. In kloudboard you can scope that external reviewer's access so they only see the cards and folders they need; the permission mechanics are covered in giving clients project access without exposing internal work.

Sequential or parallel routing

This is the decision that most changes your calendar. Route sequentially when the later approver's judgment depends on the earlier changes having been made. Route in parallel when the approvers are judging independent dimensions.

Default to hybrid for mixed deliverables. Internal reviewers work in parallel because they share context and can argue cheaply. The client review is sequential and single-threaded because each additional client reviewer multiplies the number of competing opinions you have to reconcile.

A note on timing assumptions: if you tell a client "three to five business days per round," that number has to include your consolidation time, not just their reading time. Build the round from the day you send the consolidated list to the day you get one approval back.

Worked example: 22 deliverables, three clients, one month

Assume a studio with four people: an owner who also produces, one senior editor, and two freelance editors. Three retainer clients. October output is 4 longform videos, 12 short clips (3 per longform), and 6 social posts — 22 deliverables.

Run a weekly cycle, not a per-deliverable cycle:

1. Monday, intake. The week's longform and its three clips get a brief, an owner, and a due date on one board. Nothing enters review without a brief.
2. Tuesday to Wednesday, internal draft review. Editor posts the cut; producer and community manager review in parallel. Producer consolidates into a numbered change list and updates the card state.
3. Thursday morning, client review opens. The client's single named approver sees one list on one card, with the media attached to it.
4. Friday, client decision. Approve, or return one consolidated list. Partial notes get routed back through the named approver rather than acted on piecemeal.
5. Friday afternoon, lock and schedule. The clips that were part of the batch move to approved as a group; the clips that missed the window roll to the next batch instead of stalling the longform.

Where this breaks first: the client sends a clip note two days after publish. That is a workflow gap, not a client problem. Either the batch window was not stated as a hard deadline, or the client never saw the clips as a batch at all. Fixing it means stating the window in the brief itself and having one place where approval is recorded, which is the subject of managing client approvals for social posts.

The other predictable break: freelancers upload a new cut to the same file, the client reviews the old link in an email sent before the upload, and you spend Friday reconciling. Keep versions attached to the same file so reviewers can switch between them, and keep the review inside the card's media rather than a downloaded copy.

Revision loops without losing approval state

Revision loops are normal. Losing track of which approvals already happened is what turns a two-round project into five.

Use four states, and only four, as the legal positions of a deliverable:

• Internal review — your team only. Client access, if any, is view-only or off.
• Client review — one named approver, one consolidated list expected, deadline stated.
• Changes requested — the returned list has been parsed into numbered changes with an owner and a version target.
• Approved — a decision recorded against a specific version, not against "the video."

Two guardrails prevent state loss:

Freeze before you reopen. When changes come back, the previously reviewed version stays viewable. Approvals attach to versions, so "we already approved the outro" has an answer you can point at.

Count the loop, don't hide it. If a deliverable returns for a third round, that round needs an explicit reason recorded on the card — new brief information, a scope change, or a missed instruction. Without that, revision rounds quietly become the default and your estimates stop meaning anything.

Where the workflow lives: columns, permissions, and triggers

Design the process on paper first, then map it. Board columns should mirror the states above and nothing more. A board with 11 columns usually signals that someone is tracking approval detail in the column name instead of on the card.

Permissions do the enforcement work. If clients and freelancers are restricted tiers, keep their broad visibility off so they see only cards they are assigned to, and restrict boards to a member list where needed. Per-person permission toggles live in the team settings area. Review for attached media opens from the card and supports timestamped comments and @mentions on video and documents — that is where the client's numbered list should originate, not in an email thread. For the full review mechanics, see the video review and approval process.

Automations should cover three jobs only: move a card when its state changes, notify the next approver, and remind when a review window is about to close. In kloudboard, automations are described in chat and you approve them before they run. Be aware that assignment notifications are in-app and depend on each person's notification preference — self-assignment notifies nobody, and nobody should be assumed to have received an email.

Do not try to automate judgment. Automating "approved" transitions is fine. Automating "this is good enough" is how bad work ships.

Start with one content type this week

Pick the content type that causes the most friction, not all of them. Write these four lines down and put them in the brief template:

1. Internal approver: one name.
2. Client approver: one name.
3. Routing: parallel internally, sequential to the client.
4. Round window: the day you send the consolidated list to the day the decision is due.

Run it for four weeks. Measure two things: how long consolidation takes you, and how many deliverables needed more than two client rounds. If both numbers are acceptable, add the next content type. If not, the problem is almost always the missing single approver, not the tool.

The failure mode to watch for is the one where the workflow exists on a slide but approvals still happen in DMs. A workflow only counts when the state is stored on the work item and anyone can answer "where is this?" without asking a person.