A field service operation that spans Nairobi, São Paulo, Dubai, Copenhagen, Manila, and Accra often tracks its sites in a spreadsheet. The dispatcher in Manila knows the local contact for the Dubai data centre because she entered it three months ago and keeps a note. The field tech arriving for a preventive maintenance visit asks the dispatch desk for the gate code. When that dispatcher is on leave, the replacement has no way to find the gate code or the local contact who knows about the cooling system shutdown schedule. The case system holds the address as a text field and nothing more.
Site records change that. A site in Latch is a structured object: name, address, region, time offset, contacts, latitude/longitude, and tags. When a case links to a site, the operator and the technician both see the same operational context - the same contacts, the same time zone, the same notes about the loading dock entrance. For a generator maintenance case in Dubai, the operator links the site "Dubai Data Centre B." The technician opens the case and sees the site's contact details, the UTC+4 offset, and the tag "generator-backup-only." The tech knows not to touch the main power feed because the site record carries that expectation in its tag.
Tags carry local context that the address alone cannot. A site tagged "generator-backup-only" in Manila and "cold-chain-server-room" in Copenhagen travels with different operational expectations. The tag "generator-backup-only" signals to the technician that this site's generator is for backup only, not life safety - the SLA and the work procedure differ from a site tagged "life-safety-generator." Tags let a regional queue filter group all sites with similar characteristics without relying on naming conventions that break after the third acquisition.
Tags are most useful when a queue covers enough sites that scanning a list by address is unreliable. If a region contains two sites and the dispatcher knows both, tagging adds overhead without improving routing. When a queue manages eighty sites across three countries, tags become the primary filter to assign work to the correct subcontractor or field team. The discipline is in the naming consistency. Two people might tag one site "generator-backup" and another "generator-backup-only." The import will treat them as distinct. The system provides the field; the team provides the taxonomy. That coordination failure is not solved by the import tool - it is solved by a naming standard that the operations lead owns.
Coordinates keep location data with the site without implying a map UI. Latch stores latitude and longitude with the site and exposes the fields in the site editor and import workflow. The site record carries the data; Latch does not render a map. The point is to keep precise coordinates in the same operational surface as the address, contacts, time offset, and tags.
The coordinate is a field, not a continuously validated feature. If a site moves or the entered point is wrong, the team must correct the record. Coordinates are optional in the import, so teams should decide when they are required and include that rule in their own data checklist.
Bulk import validates data before it enters the system. A CSV or TSV file runs through a preview before any row is created. The preview checks required fields, coordinate format and range when coordinates are supplied, and whether referenced customers and tags are known. Any invalid row blocks the batch. This avoids a partial import that leaves the operator cleaning up half-created records.
Consider a regional manager who needs to create service sites before a new operating period begins. The manager prepares a CSV with names, streets, cities, regions, customer names, optional coordinates, contacts, and tags. The preview shows which rows are ready and explains any row-level validation error. No records are created until the batch is valid. The atomic import prevents a situation where one part of the file succeeds and the rest must be reconciled by hand.
Bulk import is the right path when the source list already lives in a spreadsheet and manual entry would invite inconsistency. For a handful of sites, the editor may be faster. The preview does not decide whether tag names fit the team's operating taxonomy. It catches structural and reference errors, not semantic drift. That remains a human coordination problem that the import alone cannot close.
Site records are operational context for Latch cases. They are not a master data management system. If the authoritative source for address or contact data sits in an ERP, the team should sync that into Latch rather than maintain two islands. The site record holds the fields the case needs for triage, routing, and dispatch, not a complete asset register.
The operating principle is simple: sites are shared operational context, not just a field on the case form. When the dispatcher, the compliance officer, and the field technician all see the same site record, the handoff loses the phone call. The coordinate lives next to the tag; the tag lives next to the contact; and the whole object updates through the same bulk import that created it.
This release extends the field-service work introduced in the field-service release overview and asset context for field service cases. Read the full set of changes in the July product update.