See what a project is waiting on

Open a project and select Review & Delivery to see the status of every track, who is expected to act, and the recommended next action. Status describes the current version and its review or delivery record. Listening activity does not change it.

Open the project status view

1. Open Projects and select the project.
2. Select Review & Delivery.
3. Read the summary below the project title. It can include counts such as 1 waiting on client, 1 needs changes, 1 approved, 1 delivered, or 2 drafts.
4. Select a track to see its current version, status steps, latest request or decision, review history, and one recommended next action.

Each track row shows the current version, who it is waiting on, and a status badge. If a track has no current version, it shows No current version and remains a draft until you add one.

Read a track status

Track status	What it means	Who acts next
Draft	The current version has no review request, effective decision, or published final delivery. It is still private.	Studio sends the version for review.
In review	The current version has a review request and no effective decision after that request.	The client or designated approver reviews it.
Changes requested	The current version has an effective Request changes decision. Its feedback and decision stay attached to that version.	Studio starts the next version.
Approved	The current version has an Approve decision, but it is not in a published final delivery.	Studio prepares the delivery.
Delivered	The current version is included in an active published final delivery.	Nobody is waiting. Use Update Final Delivery if the package needs changes.

The status comes from the current version's review request, decision, and active delivery. A client opening or playing a file does not make a draft In review, and a client listening to an approved version does not make it Delivered.

Understand who is waiting

For a track, In review means the client is responsible. The waiting label names the designated approver when one exists, then the client name, or Client when no more specific name is available. Draft, Changes requested, and Approved are waiting on Studio because the next step is to send, revise, or package the work. Delivered is waiting on Nobody.

For the project, Mixhaus combines all track states:

Track states in the project	Project status	Project is waiting on
Every track is Delivered	Delivered	Nobody
Every track is Approved or Delivered	Approved	Studio
Otherwise, at least one track is In review or Changes requested	In review	Client, Studio, or both depending on the remaining tracks
All remaining tracks are Draft	Draft	Studio

An approved track still counts as Studio work because it needs a final delivery. For example, a project with one approved track and one draft track is Draft and waiting on Studio. A project with one track in review and another draft has work waiting on both the client and Studio.

The project summary counts the exact track states. A project with no tracks shows No tracks yet; there is no review action to take until you add one.

Follow the recommended next action

The selected track card offers the action that matches its current state:

• Draft: Send [version] for review. Choose the client and recipients, add an optional message, and send the exact current version.
• In review: Copy review link. Resend is available when the same review needs to be shared again.
• Changes requested: Start next version. Add the new bounce to the same track so the earlier feedback remains in its version history.
• Approved: Prepare delivery. Package the approved version and the other final files.
• Delivered: Update Final Delivery. Open the published package to add or update final files.

When several tracks need work, the project-level recommendation prioritizes Changes requested, then Approved, then Draft, then In review, and finally Delivered. Select the track named by that recommendation before acting.

Use Change status only when you have permission to record a manual lifecycle correction and can add the required audit note. Normal review transitions come from Send for review, the client's decision, and Prepare delivery.

Keep version history straight

The current track status applies to the current version. Earlier versions with a review request, decision, feedback, or delivery remain in Review history with their own status and activity.

For example, after a client requests changes on Version 2, upload Version 3 to the same track. Version 2 keeps Changes requested in the history, while the track's current status becomes Draft until Version 3 is sent. Once Version 3 is sent, the current track becomes In review. The client sees only the versions deliberately shared in the active review room, not every private upload.

Check access and activity

When a review room exists, Access settings lets an authorized studio user manage the stable unlisted link, expiry, password, download permissions, and stem access. The link stays the same when those settings change.

Use Client activity in Access settings to see who opened the room, listened, commented, or made an approval decision. Use Insights on a selected track to see listener totals, plays, the latest play, version labels, and whether playback came from Review or Public share. These records help you follow engagement but never determine the lifecycle state.

If the project says client access is expired or revoked, sending the next version restores the durable project review access. The earlier comments, decisions, and activity remain in the project record even when future playback or downloads are revoked.

Expected result

You can tell which version is current, whether it is private, in review, approved, or delivered, and who owns the next action. The project summary gives the rollup across tracks, while the selected track card gives the version-specific evidence behind that rollup.

What happens next

• Send a Draft version with Send a version for review.
• For In review, copy the existing link and wait for the client or approver, or use Resend when a recipient needs the link again.
• For Changes requested, start a new version on the same track, then send it when it is ready.
• For Approved, prepare and publish the final delivery.
• For Delivered, use Update Final Delivery when the package needs another file or revision.

Common problems

• The project is In review, but I expected Approved. At least one track is still In review or Changes requested. The project rollup keeps that unfinished review work visible.
• One track is Approved, but the project is Draft. The project is not fully approved while another track remains Draft. Approval still belongs to Studio until every remaining track reaches an approved or delivered state.
• The client sees an older version. Uploading a newer version does not share it. Send that current version from the review flow, then check the client review's Latest shared label.
• An earlier request for changes still appears. That decision belongs to the earlier version and should remain in Review history. Check the selected track's current version before deciding what to do next.
• There is no listener activity. Activity appears after someone opens or plays a shared track. It does not affect the status or project rollup.
• The review room is unavailable. Check Access settings for expiry or revocation, then send the next version to restore the project review access.

For the exact recipient and message flow, see Send a version for review. For the client view, see Review a mix as a client.