Create a project

Create the project before the work scatters

Create a project when the team needs one place for canvases, owners, dates, status, tags, views, and shared progress. The best time to create a project is when work is about to split across people or stages. If you wait until every conversation, file, and canvas already exists somewhere else, setup becomes cleanup.

A project does not need to be complicated on day one. A clear name, a few sections, and the first real canvases are enough. You can add tags, filters, calendar dates, members, and Dashboard progress rules as the project becomes more active.

If you are not sure whether you need a project, read Understand projects.

Before you create it

Decide what the project is responsible for. A good project has a boundary. Website redesign is clearer than Marketing things. Customer onboarding - Q3 is clearer than Customer stuff.

Decide who will maintain it. Projects fail when everyone assumes someone else will update dates, owners, and status. Name an owner or small owner group, even if ALLO does not require that field at creation.

Decide the first working structure. You might use phases, teams, status, or deliverable types. Keep the first version small. It is easier to add a section later than to convince the team to use a project that starts with twenty empty sections.

Create a project

Open Projects from the workspace navigation, then choose the create or new project action. Enter a clear project name. Add optional details such as description, members, icon, or initial structure if your workspace shows those fields.

Use the create screen to set the project boundary before you add canvases or invite people. If the project name is still vague, pause there; vague project names become vague links, vague notifications, and vague ownership later.

Create the project, then open it. Confirm that the title is clear, the project is in the right workspace, and the first view is understandable. If the project should be easy to return to, star it from the project menu or header. See Use Starred.

If you do not see a create action, your workspace role may not allow project creation, or the current area may not support it. Ask a workspace admin or project owner to confirm your role, and use Members, guests, and external collaborators if the role boundary is unclear.

Name the project well

Project names should make sense in Search, Starred, Shared with me, Activity, and dashboard widgets. Add context that helps people distinguish similar work.

Strong names include a team, client, quarter, region, or deliverable: Q3 partner launch, Client A onboarding, Brand refresh - web, Hiring plan - design, or 2026 planning workshop.

Weak names create search noise: Planning, New project, Work, Client, Launch, or Test. If the workspace has many similar projects, weak names become a support problem later.

Add the first sections

Sections should match the workflow people already understand. For launch work, use sections like Planning, Production, Review, Ready, and Follow-up. For a simple Kanban workflow, use To do, In progress, and Done. For content, use Ideas, Drafting, Editing, Scheduled, and Published.

Do not create sections for every possible edge case. Start with the path most work follows. Use tags for cross-cutting categories like priority, channel, risk, or team.

If a section becomes empty and no longer helps people act, rename or remove it. Project structure should stay close to the team’s actual workflow.

For section menus, complete-section behavior, and section moves, see Organize canvases and sections.

Add the first canvases

Create the canvases that make the project real. A project canvas should describe an action, deliverable, review surface, or working room: Launch brief, Pricing page review, Product screenshots, Legal approval, or Retrospective.

Add only the structure that will help people act:

• owners when someone is accountable
• dates when timing matters
• canvas tags when they will help filtering
• notes, files, comments, decisions, and deliverables inside the canvas behind the project row

See Create a canvas in a project and Add a canvas to a project.

Avoid filling the project with placeholder canvases that nobody will update. Empty structure looks organized for a day and becomes noise for everyone else.

Choose initial views

Use List when you need to enter or edit many canvas details. Use Kanban when the team needs to scan workflow stages. Use Calendar when dates are the main risk. Use Dashboard when the question is whether the project is moving.

Views do not create separate copies of canvases. They are different lenses on the same project. Start with the view your team will actually open first. Add or use other views once the project has enough canvases to justify them.

See Use project views, Project Dashboard and progress, and Use a project calendar.

Add tags carefully

Tags are useful when they help people find work across sections. Good canvas tag categories include priority, workstream, channel, customer, region, risk, or review type. Bad tags duplicate what sections, owners, or Due dates already say.

Create a small tag set and name it consistently. If half the team uses Design, another uses Creative, and a third uses Assets, filters become unreliable.

See Use tags and filters.

Invite or share with the right people

Give access to the people who need to plan, execute, review, or observe the project.

External collaborators and guests may need narrower access. Make sure you share only the work they should see. For guest and role details, see Members, guests, and external collaborators and Invite guests and external collaborators.

If a teammate cannot open the project after you share it, use Troubleshoot project and canvas access.

Project actions and permissions

Project menus can include actions such as rename, duplicate, archive, delete, copy link, add to Starred, manage members, or leave project. The actions you see depend on your role, project state, workspace settings, and whether the project is archived or otherwise restricted.

If you created the project but later lose an action, check whether your role changed or whether another owner changed the project state. Missing menu actions are usually permission or state issues, not broken menus.

Be careful with archive and delete. Archived work can be hidden from ordinary views, and deleted work moves toward Trash and retention. If a project was removed by mistake, check Trash before recreating work.

After creation

Run a quick project health check:

1. Can a teammate understand the project from the title and sections?
2. Do the first canvases have owners where needed?
3. Are due dates added only where timing matters?
4. Do the canvases contain the notes, files, comments, and decisions people need?
5. Can the right people open the project?
6. Do complete sections match how Dashboard should count progress?
7. Is the project easy to find from Search, Starred, or Home?

If the answer is no, fix those basics before adding more fields.

Examples

For a product launch, create Q3 mobile launch, sections for Planning, Assets, Review, Launch week, and Follow-up, then canvases for the brief, positioning, design, QA, legal, launch checklist, and retrospective. Mark the sections that mean finished work as complete so Dashboard progress is honest.

For a client onboarding project, create sections for Prep, Kickoff, Configuration, Review, and Handoff. Connect canvases for kickoff notes, implementation map, and client feedback.

For a recurring team operations project, use simple sections and tags by team. Star the project for daily access and use filters for each owner’s work.