Revisions get messy for a filing reason, not a creative one. When each new cut arrives as a separate file — v2, v2b, v3_FINAL — the notes scatter, nobody is sure which one the client saw, and the approval you have is against a cut that no longer exists.
The fix is to make the version, not the file, the unit of revision.
Versions, not new files
When a revision is ready, upload it as a new version of the existing file rather than as a second file in the project. Open the file and use Upload new version on the review screen.
What that buys you:
- The file keeps one identity. V1, V2, V3 are states of the same thing.
- Earlier versions stay readable, with the comments that were made on them.
- Approvals stay attached to the version they were given on, so the record never blurs.
- The client's existing link keeps working. There is no new address to send.
You can switch between versions from the version menu, and — in your own workspace view — open two of them side by side to check that a note was actually addressed.
Comments are the revision brief
You do not need a separate document listing the changes. The comment thread already is one, and it is better than a document because each item is attached to the moment it is about.
Work it as a list:
- Sort the panel by timecode and you have the notes in playback order — which is the order you will work through the timeline anyway.
- Filter to Open to see what is still outstanding.
- Resolve each note as you handle it. A resolved note stays readable; it just stops counting as outstanding.
- Reopen anything the next round shows was not really fixed.
Reply once under a note that is ambiguous, and get the answer there rather than in a side-channel. "Warmer" means three different things to three people, and the place to settle it is on the note, before you cut.
Notes your own team leaves are Internal by default, so the working list ("check the handle on that shot, we may not have it") never appears on the client's link.
When to open a new round
A round is one deliberate pass: you share, they respond, you close it. Open a new one when:
- You have uploaded a new version and want it judged.
- The scope of the ask has changed — picture is locked and now you want notes on the mix.
- A new reviewer is joining and needs their own state rather than inheriting someone else's.
Do not open a new round for a note-by-note back and forth. That belongs in the existing thread. Rounds are for "here is the next cut", not for "here is my answer to your third comment".
Each share you create builds a round card on the project's Reviews tab, showing the date, who was asked, the comment count, and the outcome. A round left behind by a newer version shows as Superseded, so an old open round is never mistaken for live work.
Send a change list with every revision
The single highest-value habit in revision management costs one line. When you re-share, say what changed:
"V2: logo trim at 0:12, replacement shot at 0:41, grade one stop warmer. Music still temp."
That turns round two into a check against a list instead of a fresh review of the whole piece, and it gives the client permission to stop looking for changes you did not make.
Keep the record
Resist tidying. Do not delete old versions to "clean up" the project, and do not clear resolved comments. Storage is cheaper than an argument about what was agreed in March.
What you want at the end of a job is a project where anyone can open a file, step back through its versions, read the notes each one attracted, and see a named approval against the cut that shipped. That is the same record that makes the approval process worth running, and it is why the workflow insists on versions rather than new uploads.