Content approval system: configuring states, routing, reviewer access and audit trails

A content approval system is the set of states, routing rules, permissions and records that enforce an approval decision after you have made it. Deciding approver roles is a whiteboard exercise. This is the configuration step that follows: which state a deliverable can be in, who may move it, who gets told when it moves, what an outside reviewer can see, and what evidence exists when someone asks who approved what.

If the roles are already settled, the only question here is what you turn on, in what order, and how you verify it on real work before it touches every board. Role design — approver types, sequential versus parallel routing — is covered in content approval workflow: approver roles and routing rules.

Four things a state has to do before it means anything

1. Every state has an entry condition and an exit condition. "In review" is decorative if a card can sit there with no reviewer named.
2. The handoff is automatic. If a person has to remember to tell the reviewer, the state is a label, not a gate.
3. Reviewers see only what they need. A client who can see internal rejected drafts will comment on them.
4. There is a record. When a client says they never approved that cut, you need more than a memory.

Most teams get one or two of these. The third and fourth are the ones that quietly cost money.

The five states, with entry and exit conditions

Five states cover the large majority of creative work. Two more are often needed and should be added deliberately, not by accident: Ready to publish (approved but not yet shipped) and Blocked, so a stalled deliverable does not masquerade as active work.

The third column does the real work. If the maker can move a card out of Approved, your approval state is a label rather than a gate. Check whether your tool supports per-stage transition permissions; not all do. Where a hard lock is not available, the practical substitute is a tripwire — an automation that comments on the card or notifies the approver whenever a card leaves Approved. That does not prevent the move, but it makes it visible within minutes.

Decide early whether internal review and client review are two states or one state with two reviewers. Two states give you a visible funnel and a clear "not ready for the client" boundary; the cost is two more columns on every board, and cards that pile up in a state that looks like progress but is not.

Routing: automate the handoff, not the judgement

The reliable pattern is that a person makes the decision and the system does the moving and the telling. On a kloudboard board, a stage with automations shows a bolt and a count on its column header; dropping a card on that stage shows a "Running: <name>" notice with a View run link, which is how you confirm a rule fired instead of assuming it did.

Three rules are worth building first:

• Card enters In review — create a task for the named reviewer and notify the card's assignees. This is the rule that replaces the Slack message.
• Card enters Revisions needed — comment on the card with your change-list template, so the request has a shape and lives with the version. Feedback in a chat thread is not attached to a version and gets re-litigated.
• Card becomes overdue — notify the assignee. Overdue checks run hourly and fire once per due date, so this does not spam.

Do not automate every transition. Notifications have a budget, and the arithmetic is easy to run before you commit. Take 40 deliverables a month, 2.5 stage changes each, and 3 people notified per change: 40 × 2.5 × 3 = 300 notifications a month, roughly 15 per working day before anyone writes a comment. Those are illustrative counts using your own numbers, not a benchmark — substitute your actual figures before deciding.

Route by exception instead: notify on entry to a review state, on revision requests, and on anything overdue. Let ordinary forward movement stay silent. If the estimate lands above what your team will tolerate, the fix is fewer notified people per change, not fewer rules.

Automations can also be triggered from outside the workspace. A webhook trigger gives you a URL and a secret, and the external system POSTs JSON with the secret in the X-Hook-Secret header. One behaviour worth knowing before you debug: a request with the wrong recipe id, or a missing or wrong secret, deliberately returns 404 rather than a helpful error, and the URL and secret belong to that exact automation. If a webhook starts 404ing, fetch the current URL and secret rather than assuming the sender is broken. The wider set of triggers and actions is in automations.

Reviewer access: three scopes, three exposures

• Assign-only access. A guest without the view-all-cards permission sees only the cards they are assigned to. That is enforced server-side, so an unassigned card is genuinely invisible rather than hidden in the interface. This is the right default for freelance editors and for a client reviewing a single deliverable.
• Board restriction. A board can be restricted to a member list, which is how you show a client one project without exposing the rest of the workspace.
• Client portal. A view-and-review surface that does not require a paid seat, useful when a client should see progress but not live inside your production board.

Set per-member permissions in Settings > Team, and per-board access from the board's settings. The step most teams skip: after inviting the reviewer, look at the board as them. If the card they should see is unassigned, they cannot see it — the mechanism working, but it will look like a bug to them. Assign before you invite.

File access is a separate layer. A reviewer who needs to upload a draft needs Drive access set to Editor plus the specific folder shared with them; sharing a folder changes which files they can reach, not their permission level. The default guest preset leaves the Drive page disabled, so enabling it is a deliberate step. More on the access model in giving clients project access without exposing internal work.

What the audit record actually proves

"Audit trail" gets used loosely. Before you promise one to a client, check which of these your setup genuinely records:

• State history — when a card moved between stages, and by whom.
• Review activity — timestamped comments and @mentions attached to the file, not to a chat thread.
• File versions — uploading a new version to the same file preserves the previous ones and lets reviewers switch between them. This is the strongest evidence that a specific cut was the one approved.
• Automation runs — the Runs tab lists every run, and a failed or rejected run says why in plain words with a Retry. Useful for showing a handoff happened.

The pilot: one deliverable, end to end

Do not configure five boards and announce a new process. Run one live deliverable through the full cycle, including a genuine revision, and watch where it sticks. A worked example, using a three-minute client explainer and a four-person team:

1. Monday. Create the card, assign the editor as maker, name the reviewer. The card sits in Draft. Brief and reference links live on the card, not in chat.
2. Tuesday. The editor uploads v1 to the card and moves it to Submitted. The routing rule creates a review task for the named reviewer and notifies the assignees.
3. Wednesday. The reviewer opens the file in Review, leaves three timestamped comments, and moves the card to Revisions needed. The rule comments the change list onto the card.
4. Thursday. The editor uploads v2 to the same file. v1 is still selectable. The card returns to In review.
5. Friday. The reviewer approves. Check the Runs tab: both rules fired, no failures. Check the version list: v2 is the approved one.

Two things to watch closely: whether the reviewer could find the file without being told where it was, and whether the revision request arrived as comments on the version rather than as a paragraph in a chat. If either failed, the states are fine and the access or routing is not.

If the pilot takes more than a couple of days of elapsed time, that is itself the finding — it usually means the review state has no owner, or the reviewer has no scoped access.

Once it passes, roll out in this order, because each step depends on the one before it: standardise the same five state names on every content board; add the three routing rules; set reviewer access and verify it from the reviewer's side; write down what the audit record covers and what it does not; and only then migrate work in progress onto the new boards. Renamed columns across boards are the fastest way to make routing rules unmaintainable.

If you are still comparing software rather than configuring it, the criteria that matter for mixed deliverables are set out in content approval software for mixed deliverables. If the states are set but the versions are not, start with connecting card status to file version history — an approval that cannot name the version it approved is the one that gets disputed.