A rollout spreadsheet can count branches while the service queue counts faults at those same branches. The team still has to decide which records belong to the planned change and which are ordinary support.
In a fictional six-branch terminal software update, a bounded Latch Project creates one ticket for each selected site. Each task can have its own owner, status, activity, and evidence.
Synthetic fictional sample data; Classic Projects screenshot captured 2026-09-29.
Give every branch its own task
Select the branches in the bounded project. Latch creates a project task for each site and shows the expected task count before creation. The project owner is assigned to the generated tickets; the team can then assign visits and update each ticket as work moves forward.
Synthetic fictional sample data; Classic Sites view captured 2026-09-29.
The branch task is the coordination record. If five sites are ready and one is waiting on access, that delay stays attached to the affected location. A completed visit can be marked Resolved or Closed without waiting for every other branch. The status and activity remain available on the ticket.
The Sites view also shows other open tickets at each location. That matters during a rollout: a branch may have the planned upgrade and an unrelated printer fault at the same time. The rollout lead can account for that workload without folding the support issue into the programme.
Let the site task cover its equipment
Adding a site brings its assets into the bounded project coverage. The project task for that site remains the coordination point; the asset list shows which machines it covers, their site and operating state, and recent faults.
Synthetic fictional sample data; Classic Assets view captured 2026-09-29.
If only one device is in scope and it has no site, it can be added directly and receive its own task. Otherwise, a site task prevents the rollout plan from multiplying into one duplicate ticket per machine. The equipment record remains available for service history while the project records the temporary change.
This is the distinction between a project plan and a checklist attached to one large ticket. Each site has an accountable record, while the asset view answers what equipment the task covers. The broader Projects model for sites and assets explains how this temporary scope can coexist with ongoing service ownership.
Read progress from ticket state
The bounded project report counts site tasks and their statuses, shows progress by region, and compares created and completed work against the project target date. Its progress comes from the underlying tickets. Resolved and Closed tasks count as complete.
Synthetic fictional sample data; Classic project report captured 2026-09-29.
The report is useful because a reviewer can move from the total back to the site task behind it. It can also show faults on covered assets and unrelated open work at the same branch. The geographic SLA report answers a different question about service outcomes by location; a project report follows planned work to completion.
A ticket marked complete is still a recorded workflow outcome. It does not install software or verify a device independently. The engineer records the test and handover evidence, and the team follows its deployment procedure. For a field visit that needs structured location evidence, see GPS fields on an inspection ticket.
When each location has a task, a project can show where the rollout stands and preserve the detail behind each result. A status update becomes useful when it points to the record that supports it. The quick-edit menu keeps routine status changes close to the task list.