Video workflow: routing, named versions and review gates

A video workflow is not the sequence of stages. It is the routing layer underneath them: for every file, which folder it lands in, what its current version is called, who can open it, and which gate has the authority to move it on. Most teams already have the stages. What they lack is the configuration that decides where a file goes when a card moves.

This article is about that configuration layer. If you need the stage order first, the pipeline guide covers pre-production through delivery, and the post-production workflow covers named versions inside the edit phase. Assume both exist, and set up the routing, naming and gate rules in the tool your team actually works in.

Three things you configure, and nothing else

1. Routing. Each stage has exactly one destination folder and one audience. Not "wherever the editor put it".
2. Version identity. Every file that leaves the team carries a name no other version shares, and version numbers are never reused.
3. Gate ownership. One named person moves a card forward from each stage, and they have a checkable exit condition to do it against.

Everything else — task assignment, notifications, chat — is support. If three people on a live edit can answer those three questions without opening a chat thread, the workflow is configured. If they cannot, more stages will not fix it.

The routing table

Write the table before you build anything. Five columns, one row per route. The audience column is the one teams get wrong, because access is rarely a property of the folder alone.

In kloudboard, a guest without the "view all cards" permission sees only the cards they are assigned to. That means your editor's access is a function of assignment first and folder second, so the routing table has to be paired with the assignment rule. The permissions-first setup for freelance editors walks through that pairing; configure it before you invite anyone.

Named-version conventions

Pick one format and do not vary it. A workable one:

project_ep##_v##_YYYY-MM-DD

Version numbers are sequential, never reused, and never restarted because a client asked to "go back to how it was". A version that is superseded keeps its number; you make a new version that happens to resemble the old one.

The predictable failure: clients count their own rounds. They see two client cuts, you see five internal versions, and "the version we approved" means different things on each side. Keep internal version numbers in filenames, show a separate client-facing cut number on the card ("client cut 2 of 3"), and keep the mapping on the card rather than in the editor's memory.

One mechanic worth knowing before you rename anything: uploading a new version to the same file preserves the old ones, and reviewers can switch between versions. Renaming a file, by contrast, breaks whatever linked to it. So get the name right on the first upload, and after that upload the corrected name as a new version of the same file rather than a separate file.

Configuring the gates

An automation is a rule: when X happens, do Y. On a board in kloudboard, open them from the board menu (Automations) or the Automations area; the Templates tab has ready-made rules such as a review task when a card hits Edit or a follow-up on blocked cards. Build your own for the routes above.

Triggers that matter here: a card entering a stage (including by drag and drop), a schedule, a kloudie mention, a Drive upload, a card becoming overdue, and a webhook for external systems. Actions: AI drafting, an AI quality gate that reviews the card's newest video or audio against your quality standards and moves the card on or back, tasks, notifying the card's assignees, comments, moving or completing cards, new cards, Drive documents and emails.

For each gate, write down four things: the owner, what they check, where the card goes on pass, and where it goes on fail. A gate whose exit condition is "someone looked at it" produces false confidence — the card moves forward and the notes arrive later anyway. The AI quality gate is a useful first pass against your written standards, not a substitute for the owner's decision.

A stage with automations shows a bolt and a count on its header; dropping a card on it shows a "Running" notice with a link to the run. The Runs tab lists every run, and a failed run says why in plain words and offers Retry, which re-runs it on the same event.

Before you add more gates, check whether your reviewers can absorb them. This is arithmetic, not intuition.

Review capacity per day

Decide how many review gates and versions your reviewers can actually absorb in a day before adding more.

Available reviewer minutes per day (hours times 60) divided by the reviewer minutes one version consumes (minutes per reviewer times the number of reviewers). Round down for whole versions.

Assumptions: Illustrative planning arithmetic, not a measured benchmark. Assumes reviewers work in parallel, on this edit only, and that minutes per version already includes writing the notes. Excludes waiting on the editor and any other work.

Worked example: Reviewer hours available per day: 3 hours; Minutes one reviewer needs per version: 45 minutes; Reviewers on this edit: 2 reviewers. Versions reviewable per day: 2 versions.

From timestamped notes to a numbered change list

Feedback lives on the version it was written against. In kloudboard, open the board card and use the Review action beside its attached media file or PDF; the review view supports timestamped comments and @mentions on videos and documents. See how Review works for the mechanics.

The step teams skip is the conversion. A comment is not a change request until it has a number, an owner, and a version it applies to. The producer compiles once per round into a single numbered list, assigns each item, and posts that list on the card. Two rules keep it honest:

• No item is added mid-round without a number, or it will be re-raised in round three.
• Every item names the version it applies to. "Fix the intro" on v02 is a different request than "fix the intro" on v04.

The most common failure case is not a missed note. It is the same note arriving twice, because the first time it was a comment in a thread rather than a numbered item on the card.

Lock, deliver, and what sign-off means

Lock is a sentence, not a feeling: a named person approves a specific version number, in writing, and the file is renamed with the lock suffix. After that, a change is a new version plus a change-order conversation — not a favour. If your client-facing cut numbering and your internal version numbering are mapped on the card, this is a two-minute exchange instead of a renegotiation.

Delivery is a routing decision of its own. A temporary download link expires and is fine for a one-off review copy; a shared Drive folder with a stable path is better when the client will come back for the master in six weeks. The comparison of file transfer options covers the tradeoffs; pick one and put it in the routing table so nobody improvises at 6pm.

Run it on one live edit

Do not migrate the whole back catalogue. Pick the edit that is in review this week and run it through the configured routes with three checkpoints:

1. After intake. Is the footage in the right folder, and can the editor see the card without being given anything else?
2. After the internal gate. Did the gate owner accept or return with a numbered list, or did the card sit there?
3. After the client round. Did every note land on a named version, and could you answer "what changed since the last cut?" without opening an email thread?

Measure three numbers on that edit: how many versions you created, how many notes were re-explained in a later round, and how many calendar days the card spent in review. If versions grew but re-explained notes fell, the configuration is working. If re-explained notes did not fall, your conversion step is the problem, not the routing.

One edit is enough to find the broken gate. Run a second before you commit a new client to it, then write the routing table into the onboarding checklist so the next project starts configured. If your team is still deciding where work should live rather than how it routes, start with the automations overview to see what triggers and actions are available on a board.