Collaboration WorkflowCollaboration Hub

Collaboration Workflow

Use Collabs projects in ModelBoard to propose work, invite collaborators with roles and access scopes, manage assets, and track projects.

What a collaboration is in ModelBoard

A collaboration in ModelBoard is a Collabs project created from a proposal between a sender and one or more receivers.

When you start a new project from the Collabs hub, ModelBoard creates a proposal record that tracks:

  • Who is sending the collaboration request

  • Who is being invited

  • What the project is about

  • The current status in the collaboration lifecycle

That proposal powers the workflow page at /collab/{id}, where you manage collaborators, assets, and communication for that project.

Think of a collaboration as a shared project space backed by a proposal: the sender owns the project, receivers get access based on their Compliance Role and Access Scope, and both sides use the same workflow surfaces to keep work and communication in one place.

Where collaborations live in the app

The Collabs hub at /collabs is your home for collaboration projects.

From the hub you can:

  • See projects you have sent or received

  • Check the current status of each proposal

  • Open any project workflow page at /collab/{id}

To start a new project, use the actions in the hub:

  • New Blank Project – creates a draft proposal/project and takes you straight into the workflow page so you can add details and invites.

  • New Collaboration (where available) – starts a new proposal, typically with some context prefilled (for example, from another surface in the app).

Once you create a project, ModelBoard saves the project proposal and updates its lifecycle as participants act on the invite.

Collaboration lifecycle and statuses

Every collaboration project moves through clear lifecycle labels:

Each label has a specific meaning in the UI and for your workflow.

  • Pending – You have sent a collaboration request that one or more receivers have not accepted yet. The project is open, but key collaborators still need to respond.

  • Accepted – Receivers have accepted the proposal. The collaboration is active, and you use the Production, Post-Production, and Distribution stages to coordinate planning, assets, delivery details, and communication.

  • Completed – You have marked the collaboration as finished. The project is no longer active work, but you can still reference its assets and history.

  • Archived – You have moved the project out of your main view. Archived collaborations stay available for record-keeping but no longer show as current work.

If a project looks stalled, check whether the proposal is still Pending. Until receivers accept, they see it as a collaboration request, not as an active project.

End-to-end collaboration workflow

Use this walkthrough as the concrete, in-app flow from creating a Collabs project through closing it out.

Create a new project from the Collabs hub

Start at the Collabs hub at /collabs.

  • Click New Blank Project (or New Collaboration where available).

  • Confirm that ModelBoard opens a workflow page at a URL like /collab/{id}.

  • Add a clear title and description so invitees immediately understand what the project is about.

Success looks like you see a new project in /collabs marked Pending and you can open its workflow page from the list.

Set up the project overview

Configure the Overview tab so collaborators have context when they accept the invite.

  • Describe the project goal, scope, and any key dates in plain language.

  • Add links or references to relevant work so collaborators know what style or usage you expect.

  • Save your changes so receivers see the same information when they open the project.

Success looks like you can open the Overview tab on /collab/{id} and understand the project without needing extra messages.

Invite collaborators and set role and access

Use the Collaborators tab to add people to the project.

  • Open the invite UI for the project.

  • Search for existing users by name or username and add them as collaborators.

  • If you want to invite someone by email, enter their email in the invite field:

    • If the email matches an existing user, ModelBoard sends an in-app collaboration request.

    • If the email does not match any user, ModelBoard sends an external email invite that links back to the project.

  • Choose the collaborator's Compliance Role:

    • On-Screen for collaborators who appear in the content.

    • Off-Screen for collaborators who support the project without appearing in the content.

  • Choose an Access Scope preset:

    • Viewer for read-focused collaborators.

    • Contributor for collaborators who provide materials or deliverables.

    • Editor for collaborators who help manage more of the project workflow.

  • Review locked capabilities. View Only Mode, Stream Release Assets, and Project Chat Access are enabled automatically and are not user-toggleable.

When you send the invite, ModelBoard saves the project proposal as a pending request and sends an in-app collaboration request notification to receivers.

Success looks like each invited collaborator appears in the project’s Collaborators list with the correct Compliance Role, Access Scope, locked capability state, and pending request status.

Wait for receivers to accept the proposal

Once you send invites, collaborators need to accept the collaboration request.

  • Receivers see a collaboration request notification and/or an email with a link to the project or communications view.

  • When a receiver accepts, the project moves to Accepted so the collaboration becomes active.

  • If someone declines or ignores the request, the project can remain Pending until you update or close it.

Success looks like the project appears as Accepted in /collabs for involved users, and collaborators can open /collab/{id} from their side.

Use the project stages to run the work

With the proposal accepted, use the stage navigation on /collab/{id} to collaborate:

  • Use Production for the project overview, collaborators, compliance, timeline, moodboard, and screenplay.

  • Use Post-Production for Project Files and Pro Services.

  • Use Distribution for File Sharing, Metadata, Credits, Licensing, and Forensics & Distribution.

  • Use Project Chat from the project header when you need a shared conversation that is not tied to one tab. Collaborator Project Chat access is enabled automatically and is not user-toggleable per invite.

Success looks like most project activity happens inside the workflow page instead of scattered across separate tools.

Mark the project completed and archive when ready

When work is done, close out the collaboration.

  • Confirm that working assets in Post-Production → Project Files and delivery materials in Distribution → File Sharing are up to date.

  • Mark the project Completed when the main work is finished. It will be archived as a reference for compliance purposes and available if you need to consult it later while removing it from your active project list.

Success looks like the project shows as Completed and Archived in /collabs, and you can still open /collab/{id} to review history and assets.

What you can do inside a project

The collaboration workflow page at /collab/{id} is organized into three stages. Each stage groups the tools you need at that point in the project.

Use Production for planning, setup, and active coordination.

  • Overview keeps the project goal, scope, and context in one place.

  • Collaborators shows who is involved and what access they have.

  • Compliance tracks verification, agreements, and release-related work.

  • Timeline keeps schedule details and key dates close to the project.

  • Moodboard organizes visual references and creative direction.

  • Screenplay keeps script or scene planning available to the team.

Project Chat is available from the project header rather than as a workflow tab. Collaborator Project Chat access is enabled automatically and is not user-toggleable per invite.

Different stages may matter more depending on your role. Owners typically focus on collaborators, compliance, and distribution readiness, while contributors may spend more time in Project Files and Project Chat.

Roles, ownership, and access scopes

Different people see the same collaboration through different lenses, but the feature centers on project owners/senders and collaborators/receivers, with behavior shaped by Compliance Role and Access Scope.

Focus: Create the proposal, choose collaborators, and control access and status.

  • Start new projects from /collabs and configure the Overview before sending invites.

  • Use the invite UI to search profiles or send email invites, choosing On-Screen or Off-Screen Compliance Role and a Viewer, Contributor, or Editor Access Scope intentionally.

  • Monitor proposal status using the UI labels Pending, Accepted, Completed, and Archived, then update it as the project moves forward.

  • Adjust collaborator roles and access scopes when responsibilities change instead of sharing accounts.

  • Close out projects by marking them Completed and archiving them when they are no longer active.

Access, privacy, and compliance

Collabs projects are shared workspaces, not public content. Only people explicitly added as collaborators on a project should see its internal details.

The invite UI now centers on role and scope rather than separate View, Comment, and Upload toggles:

  • Compliance Role – choose On-Screen for collaborators who appear in the content, or Off-Screen for collaborators who support the project without appearing in it.

  • Access Scope – choose Viewer, Contributor, or Editor based on how much project participation the collaborator needs.

  • Locked capabilities – View Only Mode, Stream Release Assets, and Project Chat Access stay enabled automatically and cannot be toggled per invite.

Use Viewer for visibility, Contributor for people providing materials or deliverables, and Editor for collaborators who help manage the workflow. Grant broader scope only when it is necessary.

Respect privacy when you include personal information, images, or project details in a collaboration.

  • Keep sensitive information (for example, IDs, private contact details, rates) limited to projects and collaborators who actually need it.

  • Use the Compliance tab to keep verification or agreement-related information close to the project, but do not treat it as a substitute for your own record-keeping.

  • Remember that external email invites may expose the project title and basic context in the email; write titles and descriptions accordingly.

This documentation does not provide legal advice. For questions about consent, releases, IP ownership, or regulatory obligations, involve your legal or compliance team before you publish or reuse collaboration assets.

Common issues and how to handle them

Was this page helpful?