A printer fault at a branch and a terminal upgrade at the same branch share a location. They do not share an owner, deadline, or definition of done. A queue alone leaves the team to reconstruct that difference.
Latch Projects give tickets three destinations: the Default Project for unmatched work, open-ended projects for ongoing responsibility, and bounded projects for work with a finish line.
Synthetic fictional sample data; Classic Projects screenshot captured 2026-09-29.
Give each ticket a reason to belong
Consider a fictional team supporting ATMs across Nairobi while it upgrades terminal software at six branches. A cash-deposit fault belongs to routine service. The planned software check belongs to the rollout. Each ticket stays tied to its site and equipment, while its project tells the team why that work is grouped.
Every ticket belongs to a project. The Default Project catches work that has no stronger match, so a new message or manually created ticket does not need a made-up site or asset. For other tickets, a chosen project is explicit. When no project is selected, Latch checks whether the primary asset belongs to an active open-ended project, then whether the site does. If neither matches, the ticket falls back to Default.
That order gives the more specific equipment relationship priority over the building. A terminal can be assigned to one ongoing support project while the site is part of a bounded rollout. The same asset can appear in both contexts because lasting ownership and temporary programme scope answer different questions.
Synthetic fictional sample data; Classic project overview captured 2026-09-29.
An open-ended project does not create a second task for every member. It groups ongoing work routed by site, primary asset, or an assigned inbox. A manager can see how a ticket joined the project and open the original record for its activity and evidence.
Keep site work and equipment connected
A bounded project represents a rollout, campaign, or other finite programme. Adding a site creates one project task for that location. Assets at the site are covered by its task, so a rollout across several branches has a clear coordination point at each branch without duplicating the plan for every machine.
The project view keeps the site task beside covered assets and unrelated open service work. A printer fault can still interrupt the branch while its upgrade task remains in progress. The service ticket explains the fault; the rollout ticket records the planned change.
This model is useful when the team needs to answer both “Which locations remain in scope?” and “Which equipment at this location is part of the work?” The multi-site rollout walkthrough follows that distinction from site selection through completion.
Route a long-lived inbox to long-lived work
Email is another source of work that may not begin with a site or asset. Project settings can route an existing mailbox to an open-ended project, or let an operator request a new address. The request remains visible while it awaits fulfilment or rejection.
Synthetic fictional sample data; Classic inbox settings screenshot captured 2026-09-29.
Inbox routing is limited to open-ended projects. A bounded rollout eventually ends; a mailbox may keep receiving requests after that. The project boundary should match the life of the work it receives.
Projects add context around tickets, sites, assets, and intake. They do not require every team to model a physical estate. A team with one queue can stay with Default. A team with durable ownership or a defined programme can add the project that reflects that responsibility. To explore related workflows, read about regional service-level reporting and giving collaborators access to their own tickets. See how Latch works to follow the wider workflow.