How revisions work,
for your team and your client.
You want to know what happens to a deliverable, its versions and your client’s portal between a change request and the final approval.
By the end, you’ll know which version a deliverable shows, when a revision round opens and closes, what your client sees between rounds, and what returning approved work to work does.
Before you start
- A project with deliverables and a client review.
- The project portal set up for your client.
Watch the walkthrough
How revisions work, for your team and your client.
Here's one revision cycle, seen from both sides. Harbor and Pine's first client review is back: one asset approved, one change requested.
On the Deliverables tab, the key visual is delivered, approved at v1. The front label is still in production, with changes requested.
While a deliverable is in production, it follows the newest version you upload. Once it's delivered, it stays on the version your client accepted.
On the Reviews tab, Maya's change request opened revision round 1, counted as included. It stays open until she accepts the revised work.
Now, your client's side.
Between rounds, Maya's portal shows her review as completed, and says the studio is revising one asset, with an expected date.
The approved key visual is already in her delivered files. The front label isn't, until she accepts a new version.
If she changes her mind, she can ask the studio to reopen. That only notifies your team.
Back in the studio.
Your team has added the revised front label as v2 of the same asset. Maya's decision stays with v1, now marked as an earlier version.
Close it, and click Prepare client review. The approved key visual is left out: accepted work only comes back after it's returned to work.
The front label goes in with v2. Add a short note, and click Start review and email clients.
Review 2 is open, and Maya gets an email with the link.
Maya's turn again.
In the portal, Review 2 is waiting. The front label is marked v2, revised.
She opens it and compares it with the version she last reviewed, side by side.
She approves v2, finishes the review, and submits it.
Now both assets are in her delivered files.
And back in the studio.
The front label is delivered, approved at v2.
On the Reviews tab, revision round 1 is now closed.
If approved work still needs a change, someone with the project review permission can return it to work.
The file stays visible in the client portal, marked as being revised. Your client isn't emailed about it.
In Maya's portal, the front label stays in her delivered files, marked Being revised by the studio.
Good to know: a new upload never changes what your client has already received. Returning work sends no email. And the number of included rounds is set on the Reviews tab.
In short: in production, a deliverable follows your newest upload. Once delivered, it stays put. A change request opens a revision round, and your client compares and decides again in the next review.
Search across all videos and guides.
One revision cycle, from both sides.
A revision cycle starts when your client requests changes in a review and ends when they accept the revised work. This guide follows one cycle on the Harbor & Pine launch: Alex Morgan’s studio in YetOnePro, and Maya Chen, the client, in the project portal.
For each step in detail, see Send work to your client for approval, Send a revised version back for approval, Track revision rounds against your agreed allowance and Mark a deliverable as done, and know who can undo it. Your client’s side is in Review work your creative team sent you, Show your team exactly what needs to change and Approve work, or send it back with changes.
- 01
After the first review
When your client submits a review, each deliverable gets their decision. Approved deliverables become Delivered at the version they approved, for example “Delivered · Approved v1”. Deliverables with changes requested stay In production, for example “In production · Changes requested”.
You’ll see this on the project’s Deliverables tab. The Overview tab summarizes the last review, here “1 approved · 1 change requested”.
- 02
Which version a deliverable shows
A deliverable’s file is an asset in your library, and each new upload adds a version to that asset. Which version the deliverable shows depends on its status:
- In production: the deliverable follows the newest version.
- Delivered: nothing changes. The deliverable stays on the version your client accepted, in the studio and in the portal.
A new upload never changes what your client has already received. Work moves forward only through a review. - 03
The revision round
A change request opens a revision round. You’ll find it on the Reviews tab under Revision cycles, here “Round 1 · Included · Open”. The round stays open until your client accepts the revised work. Whether a round counts as included or extra is covered in Track revision rounds against your agreed allowance.
- 04
Your client’s portal between rounds
In the portal, your client sees their review as Review completed, and how many assets the studio is revising, with the expected date: “Studio is revising 1 asset, expected by …”.
Delivered files lists only the work they approved. A deliverable they asked to change appears there only after they accept a new version.
If your client changes their mind after submitting, they can click Ask the studio to reopen. This only notifies your team. It doesn’t change the review or return anything to work.
- 05
Send the revised version
Upload the revised file as a new version of the same asset. The deliverable is in production, so it now shows the new version. Your client’s earlier decision stays with the version they reviewed, marked as an earlier version.
On the project, click Prepare client review. Approved work is left out: “Already accepted — return it to work to review a new version.” Check that the revised deliverable shows the new version, here v2, and add a note for your client if you like.
Click Start review & email clients. The new review opens, here “Review 2 · Awaiting client”, and your client gets an email with the link. The full walkthrough is in Send a revised version back for approval.
- 06
Your client compares and approves
In the portal, the new review lists the revised asset with its version, here “v2 · revised”. Your client opens it and clicks Compare with previous version to see the version they last reviewed next to the new one.
Then they approve or request changes, click Finish review, and submit it. After approval, the asset appears in their Delivered files, here “Review completed · 2 delivered assets”.
- 07
Delivered, round closed
Back in the studio, on Deliverables, the deliverable is Delivered at the new version, “Delivered · Approved v2”. On Reviews, the revision round shows Closed.
If your client requests changes again, the cycle repeats from step 5 with the next round.
- 08
Return approved work to work
Sometimes delivered work still needs a change. A teammate with the project review permission opens the deliverable, clicks Return to work, and confirms. The dialog says what happens: the file stays visible in the client portal, marked as being revised.
- The deliverable goes back to In production, and new uploads move it again.
- The file stays in your client’s Delivered files, marked Being revised by the studio.
- Your client isn’t emailed. If they should know, tell them yourself, or send the next version in a review.
Your client can’t return accepted work themselves. They can only ask the studio to reopen it. For the full walkthrough, see Upload a fix to delivered work, without changing what your client sees.
- 09
Good to know
- New uploads never change what your client has already received.
- Return to work sends no email. The portal marks the file as being revised.
- Included rounds for the project are set on the Reviews tab. Revision rounds are a record for your team, not an invoice.
In short: in production, a deliverable follows your newest upload. Once delivered, it stays on the version your client accepted. A change request opens a revision round, and your client compares and decides again in the next review.
Check the result
- You know a deliverable in production follows the newest upload, and a delivered one stays on the approved version.
- You know a change request opens a revision round, which closes when your client accepts the revised work.
- You know what your client sees in the portal between rounds.
- You know Return to work keeps the file in the portal, marked as being revised, without emailing your client.
If it didn’t work
I uploaded a new version, but the delivered work didn’t change.
That’s by design. A delivered deliverable stays on the version your client accepted. To change it, return it to work, then send the new version in a review.
Is my client told when I return work to work?
No email is sent. The file stays in their Delivered files, marked Being revised by the studio. If they should know, tell them yourself, or send the next version in a review.
Can my client undo their approval?
No. They can ask the studio to reopen the review, which only notifies your team. A teammate with the project review permission can return accepted work to work.
Why isn’t an approved deliverable in the next review?
Accepted work is left out. It comes back into a review only after it’s returned to work.