Plan a launch

A launch needs a plan and a working surface

Launch work usually fails in the gaps between tools: the project tracker is separate from the brief, files live in chat, review comments sit on a canvas nobody can find, and the final date moves without everyone noticing. ALLO projects help by keeping canvases, owners, dates, tags, views, and progress in one workflow.

Use the project to coordinate the launch. Use canvases to create and review the launch material. Use Files to recover attachments. Use Activity to understand recent changes. Use Trash when something is deleted by mistake.

This article gives one practical launch pattern. Adapt the section names, canvas types, and complete sections to your team.

Create the launch project

Create a project with a name that will still make sense in Search and Starred later. Include product, audience, quarter, region, or launch type if needed: Q3 mobile launch, Partner launch - EMEA, or Pricing page launch.

Add a short description with the launch goal, target date, owner, and primary audience. Invite the core team with the right permissions. If external reviewers only need selected materials, share those canvases later instead of giving broad project access.

For setup steps, see Create a project.

Build launch sections

Use sections that match the launch flow. A simple launch can use:

If your team already uses different stage names, use those. The project should reflect how people actually move work.

Add launch canvases

Create project canvases for work that needs ownership, review, or a durable record. Useful launch canvases include:

Do not create one giant Launch canvas. Split work when owners, dates, reviewers, or materials differ. See Create a canvas in a project.

Bring existing canvases into the project

Launch work often starts before the project exists. Move or copy existing canvases for the launch brief, creative review, QA checklist, stakeholder review, enablement plan, launch room, and retrospective.

Use templates when the launch follows a repeatable pattern. A launch brief template, retrospective template, or review canvas template saves setup time and keeps teams consistent. See Create a canvas from a template.

Keep each project row understandable and put rich material on the canvas. The project shows who owns the launch brief and when it is due. The canvas contains the actual brief, files, comments, decisions, and presentation pages.

For move, copy, and sub-canvas placement, see Add a canvas to a project and Organize canvases and sections.

Use tags for launch slices

Canvas tags help each team find its slice without duplicating the project. Common launch tags include Design, Copy, Legal, QA, Product, Enablement, Customer, High risk, External review, and Launch day.

Keep tags consistent. Decide whether the team says Copy or Content, Legal or Compliance, High risk or At risk. One vocabulary makes filters reliable.

Use tag filters in meetings. For example, filter to High risk during launch readiness review, or filter to Legal when checking approval status. See Use tags and filters.

Mark complete sections before the launch review

Dashboard progress is based on top-level project canvases in sections marked complete. For a launch, that might mean Ready, Approved, Published, or Follow-up, depending on how your team defines finished work.

More than one section can count as complete. A team might mark both Ready and Published complete if each section represents work that no longer needs launch-team action. If Done is not marked complete, canvases in Done will not count as complete no matter how finished they look.

You can set complete sections later. If the team already moved canvases into Approved, marking Approved complete makes existing canvases count toward progress when Dashboard refreshes. ALLO can use available movement history for burndown instead of forcing you to rebuild the project.

Use views for different launch meetings

Use Kanban for standups. It shows what is planned, in progress, in review, ready, and done.

Use List for cleanup. It is easier to edit owners, Due dates, tags, and canvas titles in a compact layout.

Use Calendar for launch timing. It shows whether reviews are too close to launch day, whether dependencies are stacked on one person, and whether follow-up has a real date.

Use Dashboard for readiness. Check project progress, total canvases, overdue canvases, canvas subtask counts, burndown, workload, section distribution, top risks, and project activity before status meetings.

Use saved or filtered views for teams when the project gets large: Design review, Legal, This week, At risk, or Launch day.

See Use project views and Use a project calendar.

Run launch reviews

Before each review, filter to the relevant canvases and open the ones that need discussion. Reviewers should comment on the canvas when feedback belongs to the material, and move the canvas to the right section when the work changes stage.

Use mentions when you need a specific response. Use the project row for owner, date, tag, and section. Use the canvas for detailed feedback. This prevents the project from becoming a wall of comments while keeping the work traceable.

For comment workflows, see Comments and mentions.

Manage files during launch

Upload launch assets, decks, screenshots, videos, and PDFs to the connected canvases where they belong. Files added in context are easier to recover later because Files can point back to the containing canvas or project.

If assets have similar names, use clear file and canvas names. hero-image-final.png is not enough if every team has a final hero image. Add project or channel context where possible.

If a file becomes unavailable or was removed, check Preview, open, and download files, Unavailable and retention-locked files, and Trash.

Share launch work safely

Internal launch teams may need project access. External reviewers often need only a canvas. Share narrowly when the reviewer should not see every project canvas or file.

If someone says they can open the canvas but not the project, they likely have canvas-level access. If they can open the project but not a specific canvas, that canvas may need separate sharing. Use Share a canvas and Fix shared access.

For guests, see Invite guests and external collaborators.

Launch-day workflow

On launch day, use a filtered view or Calendar for launch-day canvases. Keep owners visible. Open the launch room canvas for notes, decisions, and live issues. Use comments and mentions for specific blockers.

Move canvases as they complete, but do not delete them just because they are done. Completed launch canvases are useful for post-launch review, Dashboard history, and future planning.

If a launch canvas disappears, check filters, views, All canvases, Search, Activity, and Trash before recreating it. Duplicate emergency work can confuse the team during a launch.

Follow-up and retrospective

Create follow-up canvases before launch day ends. Add metrics review, customer feedback, bug follow-up, sales enablement, documentation cleanup, and retrospective canvases. Give them owners and dates.

Connect a retrospective canvas so the team can capture what worked, what failed, and what should change next time. Star the project or retrospective canvas if the team will return to it during the next launch.

After the launch, archive or clean up only when the team agrees. Preserve useful canvases, files, and decisions. If you delete something by mistake, use Restore deleted work before retention ends.

Common launch problems

The goal is not to create a perfect project. The goal is to make the next decision obvious.