Understand projects

Projects organize canvases into a shared operating view. Use a project when a team needs to know which canvases belong together, who owns each one, when work is due, which section it sits in, and how much work has moved into a completed stage.

A canvas is where the work happens. A project is the layer that keeps those canvases scannable. In a launch project, for example, the canvases might be Launch brief, Homepage review, Press assets, and Retrospective. The project sections show where each canvas sits in the workflow.

For project structure, continue with Project dates, status, and notifications, Use tags and filters, Manage project members, and Project Dashboard and progress.

When to use a project

Use a project when work spans several canvases or stages. Good project candidates include product launches, client delivery, campaign planning, research programs, workshop series, content calendars, class projects, hiring plans, event planning, and recurring team operations.

Use a single canvas without a project when the work is one meeting, one brainstorm, one document-like space, or one workshop that does not need section tracking. Add the canvas to a project later if it becomes part of a larger workflow.

If people keep asking "which canvas is current?", "who owns this?", "what is ready?", "what is overdue?", or "why does Dashboard show no progress?", the work probably needs a project.

Main parts of a project

The same canvas can appear across views. Moving it in List or Kanban changes the canvas in the project, not a copy of it.

Project List behavior

Project List is the densest view for organizing canvases. It shows canvases grouped by sections, with columns for name, owner, collaborators, due date, tags, and sometimes created or modified dates on wider screens.

Use List when you need to add several canvases, rename sections, move canvases between sections, adjust owners or dates, apply tags, create sub-canvas structure, or check which sections count toward progress.

Rows can represent top-level canvases or sub-canvases. A top-level canvas sits directly in the section. A sub-canvas is nested under another canvas and can expand or collapse under its parent. For the broader sub-canvas model, see Use sub-canvases.

Sections and progress

Sections are more than visual groups. A section can be marked complete from the section menu. Every top-level project canvas in a complete section counts as completed for Project progress and Dashboard burndown. More than one section can be marked complete.

For example, a project might mark both Approved and Published as complete sections. A top-level canvas moved into either section counts as completed. A top-level canvas in Draft, Review, or Blocked stays part of the total but does not count as completed.

You can mark a section complete after the project already has history. That immediately makes the section history useful: when Project progress refreshes, existing top-level canvases in that section count as completed. This helps when a team starts with ordinary sections and later decides which sections should represent done work.

Canvas subtasks are separate. Completing subtasks inside one canvas can help that canvas move forward, but Project progress is based on the canvas's section, not on subtask completion.

Move and nest canvases

You can drag canvases inside Project List when your role and current view allow it. Drops have different meanings:

When a manual sort is active, Project List may block same-section row sorting because the visible order belongs to the sort field. Cross-section moves can still work because they change the canvas section rather than promising a manual row order.

Dragging a parent canvas under one of its own descendants is blocked. That prevents cycles in the sub-canvas tree.

Move and copy across projects

Canvas menus can move or copy a canvas to another project. Moving changes where the canvas lives. Copying creates another canvas for the destination project. Copying is useful for templates, recurring meetings, or client-specific versions; it is risky when two copies are treated as the same source of truth.

Some move and copy flows can target either a project or a canvas. Choosing a project makes the moved canvas top-level in that project. Choosing a canvas makes it a sub-canvas under that canvas. See Manage canvases in projects.

Section menus can move or copy a whole section to another project. This moves or copies the section structure and the canvases in it, subject to permission and access checks. Use section copy when another project needs the same workflow slice. Use section move when the section belongs in a different project.

Access and visibility

Project access and canvas access can differ. A person may open the project but not a restricted canvas inside it. Another person may have a direct canvas share without access to the whole project.

Actions can be hidden or disabled based on workspace role, project role, canvas permission, archive state, deleted state, guest state, shared project state, and workspace feature settings. Missing move, copy, section, or progress actions usually means the current role or context does not allow that action.

If a collaborator loses access after a canvas moves projects, check whether their access came from the old project. Add them through Manage project members in the destination project or share the canvas directly.

Common project patterns

For a launch, create sections such as Planning, Creative, Review, Approved, and Published. Mark Approved and Published complete if those sections represent done work for progress and burndown. Use canvases for the brief, asset review, QA notes, launch room, and retrospective.

For a client project, create sections for Prep, Kickoff, Review, Approved, and Handoff. Keep client-facing canvases clearly named and share only the canvases or project areas the client should see.

For recurring operations, keep sections simple. Use tags for categories that cut across sections, such as team, risk, channel, priority, or region.

What to set up first

Start with the project name, a small number of sections, and the first real canvases. Add owners where accountability matters. Add dates where timing changes behavior. Add canvas tags only when people will filter by them. Mark complete sections only when the team agrees those sections mean done work.

Avoid building a perfect system before the work exists. Projects become useful when they reflect real canvas work. Add structure when the team starts asking for it.

If the project becomes noisy, check filters, section names, and canvas names before rebuilding it. Most clutter is a view, naming, or tagging problem.

Recovery paths

If a canvas is missing, clear filters, switch views, search the project, then check All canvases, Search across ALLO, and Trash.

If project progress looks wrong, check which sections are marked complete, whether canvases are in those sections, and whether the Dashboard or project list has refreshed after recent section changes.

If you can see the project but not edit it, the likely issue is permission, not data loss. Use Read-only access, Fix shared access, and Members, guests, and external collaborators.