Skip to content

Assigning Songs

In The Library, projects (sometimes called buckets) are where you organize your work. Assigning songs to projects helps you group tracks by album, client, release campaign, or any workflow that suits your needs. This page walks you through how it all works.


A project is essentially a container that holds your tracks. Think of it like a playlist or a folder — it keeps related songs together so you can find them quickly and track progress across a body of work.

Projects can be simple (like “Q1 Singles”) or structured in hierarchies with parent and child projects. Project assignment and collaborator assignment are separate actions.


Use the bucket-selection controls for the selected track group. They show available buckets, the current assignments, and locked shared-bucket assignments that the current user cannot change.

You can also use the “Unassigned” option to remove assignments that you are allowed to manage. Shared-project assignments that are locked for the current user are retained.

If the save cannot be completed, the assignment is rolled back and the app shows the backend error instead of leaving the track in a partially updated state.


Use the same selection control with multiple track groups to add or remove assignments in bulk. The service validates each target track and preserves existing multi-bucket relationships unless the selected operation replaces them.


One powerful feature is that a track can belong to multiple projects at once. This means a song can live in both your “Client A” project and your “Q2 Releases” project simultaneously.

Track groups can belong to multiple projects. Existing assignments are preserved by multi-select assignment flows, including the non-exclusive Archive relationship.


Use the bucket-selection control to remove an assignment you are authorized to manage. Locked shared-bucket assignments are retained; choosing Unassigned does not remove those locked access paths.


When you assign a track to a shared project, The Library may need to confirm collaborator coverage before it can save the assignment. This prevents a project member from receiving a track without the necessary collaborator record.

If coverage is required, choose one of the options presented:

  • Add missing members as Observers — creates the required collaborator rows with zero splits.
  • Exclude uncovered tracks — keeps tracks that do not have the required coverage out of that shared-project assignment.
  • Cancel — leaves the existing assignment unchanged.

The app retries the same assignment only after you choose a coverage remedy. Successful remediation updates the local collaborator state as well as the project assignment.

Collaborator behavior can depend on project configuration and coverage reconciliation. Use the collaborator workflow to review or change people assigned to a track; do not assume project assignment alone defines collaborator access.


When you select a parent project in the sidebar, you’ll see not just the tracks in that project, but also tracks in all of its child and grandchild projects. This makes it easy to review a whole release campaign or label back catalog at once.

Selecting a child project on its own shows only that project’s tracks, giving you a more focused view.


  • Use clear naming — Give your projects names that make it obvious what’s inside, like “Album 2026” or “Brand X Campaign”
  • Review shared-project coverage — If the app asks for a coverage choice, confirm whether the person should be an Observer before continuing
  • Multi-bucket is flexible — Don’t be afraid to assign tracks to multiple projects when it makes sense for your workflow
  • Check the result — a bulk request can report a mixture of successful and unsuccessful target assignments.