At 9:10 a.m., a product specialist comments on an approved script: “Scene 3 says three compartments. The product has two.” Five minutes later, the marketing lead asks, “Can we keep the delivery date and leave the visuals alone?” Someone reacts with a thumbs-up.
What, exactly, has been approved now?
The mistake should be corrected. But the correction does not automatically reopen the concept, the shot plan, every export, or the launch decision. The thumbs-up does not identify who approved what. And the requested deadline is not a production plan.
A useful creative approval workflow does not try to prevent feedback. It protects the approved baseline while making justified changes traceable. Every approval should bind six things: the reviewed version, the decision scope, the disposition, any conditions, the accountable decision owner, and the work that may begin next. When a late request arrives, assess it against that record and reopen only the decisions and downstream assets it actually affects.
That is the purpose of the template and filled examples below. This is an operational workflow, not a contract, a promise that revisions disappear, or a substitute for legal, regulatory, technical, accessibility, or other specialist review.
Set a Decision Gate for Each Production Stage
Most creative workflows already have statuses such as “In review” and “Approved.” The missing question is often: approved for what?
Asana’s public creative-approval guidance lists useful fields including the project, asset type, file version, owner, brief, review criteria, status, and deadlines. Those fields help organize a review, but a small team still needs to define the decision made at each stage.
Use the following six scopes as a starting point, not as six mandatory meetings or an industry standard.
| Gate | Decisions that belong here | Decisions that normally remain open | Reopen this gate when… |
|---|---|---|---|
| Brief | Objective, audience, required deliverables, channels, constraints, evidence needs, decision authority | Creative direction, exact wording, shot order, final files | The purpose, audience, deliverable set, channel, or non-negotiable requirement changes |
| Concept | Central idea, product use case, narrative frame, visual world, format approach | Exact script, timing, takes, finishing, delivery manifest | The story, use case, promise, or creative direction changes |
| Script or storyboard | Spoken and on-screen wording, claims, CTA, shot sequence, required demonstrations | Final performance, edit rhythm, color, mix, captions, technical packaging | Wording, claim support, required scene, CTA, or planned sequence changes |
| Rough cut | Selected takes, structure, pacing, sequence, cutdown logic, missing pickups | Final grade, mix, graphics polish, caption files, route-specific exports | A requested edit changes story structure, needs new footage, or invalidates approved timing |
| Final asset | The exact finished media, copy, specialist conditions, technical checks | Delivery receipt, trafficking, publication, release authorization | The file changes after review, a condition fails, or a final-context problem appears |
| Delivery or release | Manifest, destination, receiving acceptance, scheduled release, release authority | Future markets, variants, adaptations, unrelated campaigns | The destination, package, release plan, or listed output changes |
Published workflows differ, which is precisely why the gate should name its scope. In Clearcast’s published standard The Library route for UK broadcast advertising, script, rough cut, and final TVC are separate stages; the rough-cut review is strongly recommended rather than mandatory, while the final stage still has technical and compliance checks. That route is not a US digital-ad requirement. It is a useful example of a broader point: approval of an early component is not approval of the complete asset.
A gate is therefore not “everyone looked at it.” It is a recorded boundary: these decisions are accepted, these decisions remain open, and this specific work may proceed.
Separate Feedback Coordination From Approval Authority
Small teams do not need an approval committee. They do need distinct responsibilities, even when one person holds more than one role.
| Responsibility | What the person does | What the role does not imply |
|---|---|---|
| Requester | States the business need, target outcome, required deliverables, and requested change | Automatic authority over every specialist or release decision |
| Feedback consolidator | Collects comments, removes duplicates, identifies conflicts, and returns one traceable response | Power to discard an inconvenient factual, legal, or technical blocker |
| Decision owner | Approves, rejects, defers, or conditionally approves a defined scope | Expertise outside the authority assigned to that decision |
| Producer | Maintains versions, dependencies, impact assessment, schedule, and handoffs | Permission to spend, shoot, publish, or change direction without authorization |
| Specialist reviewer | Verifies a bounded issue such as factual accuracy, legal clearance, brand, accessibility, or technical delivery | Final approval of the complete asset unless explicitly assigned |
GitLab’s public Brand Creative handbook gives one practical model: final approvals and feedback are communicated through one DRI, who is encouraged to consolidate input. Its separate marketing-site workflow also routes approval according to the impact and type of change. The lesson for a four-person team is not to copy GitLab’s hierarchy. It is to keep one feedback entry point while routing decisions to the owner of the affected scope.
When comments conflict, the consolidator should produce a decision packet rather than a compromise sentence:
- Group comments by decision scope: factual, creative, brand, technical, delivery, or release.
- Mark agreements, contradictions, and required specialist blockers.
- Show the affected version and the options available.
- Send the unresolved choice to the person authorized to decide it.
- Record the decision and what happens next.
An assigned approver is not necessarily an available approver. In one GOV.UK publishing route, submitting content for review does not automatically notify the reviewer. Google’s Drive API documentation likewise warns that an approval request can succeed even when a reviewer lacks file access; that person then cannot receive the notification or view the file. Before starting the review clock, confirm four separate facts: the owner is named, has access, has been notified, and has accepted the review window.
If the owner is absent, use Awaiting decision, a pre-authorized delegate, or an explicit escalation. Silence and emoji reactions are acknowledgments unless your recorded workflow says otherwise; they are not a reliable substitute for a scoped decision.
Make Approval Specific to a Version and a Next Action
A link is a location, not an immutable approval object. The content behind it can change.
Frame.io’s current versioning documentation says a version stack opens the newest version by default, while previous versions remain accessible. Its Mounted Storage save history also records a save counter, date, time, and author. That is why an approval record should identify the exact version, save, snapshot, export, or checksum that was reviewed—not merely the live URL.
Google Drive provides an even sharper counterexample. During an approval, edits reset prior approvals only when the relevant setting requires everyone to review the same content. With the alternative behavior, edits do not reset approvals; after final approval, editors can change the file without losing that approved state. An “Approved” flag can therefore survive a content change. The tool is behaving as configured, but the team still needs to know which content received the decision.
Use an approval record like this:
| Field | Required value |
|---|---|
approval_id |
Stable decision ID, such as APR-003 |
reviewed_object |
Asset and version, plus snapshot/save/export identity |
reviewed_scope |
Exact questions decided in this review |
disposition |
Approved, rejected, deferred, or conditionally approved |
permitted_next_work |
Work that may begin because of this decision |
blocked_work |
Work still prohibited or awaiting another decision |
conditions |
Unresolved condition, owner, due point, and closure evidence |
decision_owner |
Named person and authority scope |
timestamp |
Date, time, and time zone |
A useful script approval might read:
APR-003 — SCR-v03 / SNAP-SCR03 — Approved
Scope: wording, claims, CTA, and shot order.
Permitted next work: storyboard lock and production planning.
Not approved: final pacing, captions, technical delivery, publication, or release.
Decision owner: Maya Chen, business owner.
Timestamp: September 18, 2026, 4:20 p.m. ET.
The transition matters as much as the label. Adobe’s documentation for standalone Workfront Proof notes that both “Approved” and “Approved with changes” can trigger the next automatic stage. If your status can advance work, define which work it authorizes and who closes any condition. Renaming a button does not change the underlying workflow logic.
Assess the Work Behind “One Last Change”
A late request is not classified by how politely or briefly it is written. A one-line message can correct a typo or replace the entire concept.
The Association for Project Management defines change control as capturing requests against an approved baseline, evaluating them, and then approving, rejecting, or deferring them. Its guidance calls for assessing effects on scope, quality, time, resources, cost, risk, and other relevant criteria before updating the plan. A small creative team can use that logic without creating a governance board.
For each late request, complete one change card:
| Question | Record |
|---|---|
| Why is the change needed? | Genuine correction, newly discovered requirement, or new direction |
| What is the baseline? | Last approved decision and exact affected version |
| What reopens? | Decisions, source assets, derivatives, exports, reviews, and dependencies |
| What stays approved? | Unaffected decisions and reusable work, with reasons |
| What is the impact? | Additional work, assumptions, external costs, capacity, sequence, and unknowns |
| Who can authorize it? | Decision owner for the revised scope, budget, and date |
| What happens now? | Approve, reject, defer, or authorize assessment only |
Keep effort separate from elapsed time. Six person-hours of work do not necessarily add six hours to a delivery date. The calendar effect depends on when the right people, locations, evidence, or review slots are available. Likewise, an unknown external cost is not zero. Keep it as an unresolved variable until someone supplies evidence.
A concise producer response can prevent accidental production authorization:
“Recorded as
CR-B01against approved scriptSCR-v03. This request changes the product-use story, so it reopens the concept and production plan rather than only the edit. I am authorized to assess the impact, not to book the shoot. I will return the affected outputs, dependencies, estimate, and revised-date conditions for a decision.”
Example 1: Correct the Approved Script Without Reopening the Concept
The following Northline Desk case is a fictional teaching example. Names, dates, rates, asset IDs, and effort estimates are illustrative; they are not market prices, a real campaign, or measured time savings.
The approved work is a product video for a two-compartment desk organizer:
- one 30-second and one 15-second video;
- each video exported in 9:16 and 1:1, creating four video files;
- one English caption file per duration, creating two caption files;
- six listed outputs in total.
The small team is Maya Chen, requester and business decision owner; Jordan Lee, producer and feedback consolidator; Alex Rivera, editor and internal voice talent; and Sam Patel, product specialist.
Their approved trunk is BRF-v01 → CON-v01 → SCR-v03 → STB-v02. The concept is a calm desk reset. The approved script says, “Keep everyday items in three compartments,” but the product fact sheet and filmed model both show two.
The incoming comments
Sam, product review thread, 9:10 a.m.: “Scene 3 says three;
FACT-v01has two. Correct the count.”Maya, email, 9:15 a.m.: “Please keep the delivery date. Can we leave the visuals alone?”
Alex, review thread, 9:18 a.m.: “The footage is the two-compartment model. The current voiceover and overlay still say three.”
Maya, chat, 9:19 a.m.: 👍
Jordan records the thumbs-up as acknowledgment, not approval, and consolidates the evidence into CR-A01.
The filled change decision
| Field | Recorded value |
|---|---|
| Baseline | SCR-v03 / SNAP-SCR03; concept CON-v01; storyboard STB-v02 |
| Reason | Genuine factual correction: “three” conflicts with FACT-v01 and visible product |
| Reopened | Script line, storyboard overlay, voiceover pickup, two edit masters, two caption files, affected exports, factual recheck |
| Retained | Desk-reset concept, existing footage, shot sequence, CTA, end card, four-video/two-caption deliverable count |
| Key assumption | Footage already shows the correct two-compartment model; no reshoot is required |
| Decision | “Replace the incorrect count; retain the desk concept and the 4+2 outputs. No release approval yet.” |
| Decision owner | Maya, for scope and internal planning impact; Sam, for factual closure |
The extra planning effort is calculated rather than guessed:
| Role | Illustrative added effort | Assumed internal rate | Planning cost |
|---|---|---|---|
| Jordan — triage, closure, manifest | 0.75 h | $60/h | $45 |
| Sam — source comparison and factual closure | 0.50 h | $80/h | $40 |
| Alex — script, pickup, edit, captions, change-specific QA | 4.50 h | $70/h | $315 |
| Maya — scope and impact decision | 0.25 h | $100/h | $25 |
| Total | 6.00 h | — | $425 |
That is six person-hours of additional work. It is not automatically six hours on the deadline, a client charge, or an amount “saved” by the workflow.
The version chain
| Affected object | Approved baseline | Corrected object | Exact change |
|---|---|---|---|
| Script | SCR-v03 |
SCR-v04A |
“three compartments” → “two compartments” |
| Storyboard | STB-v02 |
STB-v03A |
Scene 3 overlay becomes “Two compartments” |
| Voiceover | VO-v01 |
VO-v02A |
Pickup replaces the incorrect count |
| 30-second captions | CAP30-v01A |
CAP30-v02A |
Count corrected; cue map retained unless text fit changes |
| 15-second captions | CAP15-v02A |
CAP15-v03A |
Count corrected; cue begins at 00:03.200 in the example timing map |
| Final exports | Previous drafts | New A revisions |
Four video exports regenerated from corrected masters |
Maya then approves SCR-v04A and STB-v03A for finishing, not for release. Sam closes the factual condition by checking the exact replacement against FACT-v01. Jordan closes the caption condition using the text and timing map. Because this is a teaching dataset rather than a real media file, the record does not claim audiovisual playback occurred.
Finally, the delivery manifest lists four video files and two caption files. Receipt of those files is recorded separately from permission to publish them. The workflow absorbs the legitimate correction without pretending that the already approved concept never existed.
Example 2: Assess a New Direction Before Authorizing Production
Now start again from the same approved script, SCR-v03. Maya asks:
“Could we replace the desk demonstration with a travel-ready story? Put the organizer in a bag, take it outside, and shoot the last scene in a coffee shop. Keep the same deliverables and the September 29 date.”
The message is still one paragraph, but it is not a copy correction. It changes the product-use case, narrative, location, footage, and evidence needed to support “travel-ready.” Jordan opens CR-B01 and requests authority for assessment only.
What the request changes
| Scope | Result |
|---|---|
| Brief | Reopens the use case and possibly the evidence requirement; audience and deliverable count can remain unchanged |
| Concept | Reopens the desk-reset direction in favor of bag/outdoor/coffee-shop use |
| Script/storyboard | Requires new scenes, wording, overlays, and shot order |
| Production | Requires location conditions, product-use evidence, capture planning, and new footage |
| Existing work | Some end-card and product-detail work may be reusable; old direction remains the approved baseline until replaced |
| Delivery | Still proposes four videos and two English caption files, but no revised manifest is authorized yet |
The assessment itself is authorized at 3.25 person-hours and $235 in illustrative internal planning cost. It returns a net incremental production estimate of 22 person-hours and $1,545, plus an unresolved external location or permit cost recorded as L. The two numbers must not be blended into a silent go-ahead:
- authorized assessment: 3.25 h / $235;
- proposed additional production: 22 h / $1,545;
- external location cost:
L, unknown; - total if later authorized: 25.25 h / $1,780 +
L.
The proposed schedule reaches October 5 instead of September 29 only if the product-use evidence, location conditions, cost, and capture slot close in time. That is a six-calendar-day difference and four weekdays in this fictional calendar. It is a conditional forecast, not a promise derived by dividing 22 hours by a workday.
The decision record
| Field | Recorded value |
|---|---|
| Disposition | Defer new-direction production; assessment completed |
| Authorized now | The $235 assessment; dependency gathering; preparation of a separate correction request for the known compartment error |
| Not authorized | New shoot, $1,545 production estimate, unknown L, location booking, replacement of the approved baseline, exports, or release |
| Open dependency 1 | Evidence for the “travel-ready” product-use claim; owner: Sam |
| Open dependency 2 | Location conditions, cost, and feasible capture slot; owner: Jordan |
| Decision owner | Maya for revised direction, scope, planning cost, and date |
| Reopen condition | Update the dependencies, then obtain a new timestamped decision on revised scope, cost, and date |
This is a complete decision even though the requested production is not approved. “We assessed it” no longer means “start making it.” Just as important, deferring the new direction does not authorize shipping the known “three compartments” error. That genuine correction remains a separate open route.
A newly discovered delivery requirement can be narrower still. Suppose a partner later asks for Spanish caption files. If accepted, the manifest changes from four videos plus two English captions to four videos plus four caption files—eight outputs. Translation, format, and qualified language review need assessment, but the desk-reset concept does not automatically reopen. Route the change to the decisions it actually affects.
Close the Change Before You Deliver
A change is not closed merely because someone accepted the proposal. Separate these states:
- feedback received;
- impact assessment authorized;
- change approved, rejected, or deferred;
- implementation completed;
- specialist conditions closed;
- exact final asset approved;
- delivery received;
- release or publication authorized.
The names can differ in your software. The transitions cannot remain ambiguous.
Before delivery, ask the producer to perform one closure pass:
- Does every approved object identify the reviewed version or snapshot?
- Does every change name its approved baseline?
- Can a reader see what reopened and what stayed approved?
- Are all derivative assets and exports linked to the source change?
- Does each condition have an owner and closure evidence?
- Are effort, external cost, and calendar assumptions separated?
- Does the manifest contain only approved final objects?
- Are receipt and release recorded as separate decisions?
Final-context review matters because implementation can introduce a new error after upstream wording was approved. The UK Department for Education’s content guidance, for example, calls for a final check in the production or preview context and says accuracy should be checked again if content changes during CMS preparation. The exact review route is organization-specific; the operational principle travels well.
For creative systems that branch one approved core into many exports, the same logic can continue into an immutable delivery ledger. Hookin’s guide to traceable creative variants shows how build identity, parentage, destination, and evidence can remain attached after production.
“One last change” is not a measurable category of work. It may be a necessary correction, a new requirement, or a different creative direction. The workflow succeeds when the team can tell which one it is, preserve the decisions that still stand, authorize the right next action, and refuse to let a vague approval status rewrite the project’s history.
Use the reusable workflow template, filled example ledger, and interactive planning demo to work through the scenarios.
Sources
- Creative Asset Feedback and Approval Template for Reviews — Asana. Accessed September 8, 2026.
- Brand Creative Handbook — GitLab. Page last modified August 31, 2026; accessed September 8, 2026.
- Marketing Site Approval Process — GitLab. Page last modified October 1, 2025; accessed September 8, 2026.
- Send standard content types for review — GOV.UK / Government Digital Service. Accessed September 8, 2026.
- Get approvals on files in Google Drive — Google Drive Help. Accessed September 8, 2026.
- Manage approvals — Google for Developers. Last updated August 19, 2026; accessed September 8, 2026.
- Versioning in Frame.io — Frame.io / Adobe. Page displayed “Updated this week”; accessed September 8, 2026.
- Configure approval decision options in Workfront Proof — Adobe. Last updated June 12, 2026; accessed September 8, 2026.
- What is change control? — Association for Project Management. Accessed September 8, 2026.
- The Ad Clearance Process — Clearcast. Accessed September 8, 2026.
- Quality and assurance — UK Department for Education. Accessed September 8, 2026.
