Many teams give a field engineer access to the full operations queue and then rely on a filtered view inside the navigation to keep the work manageable. That looks like access control. It is not. It is a display setting that fails the moment an engineer searches, counts records, or opens a direct URL.
The problem is that access scope must live in the permission boundary, not in a UI filter. When the system does not enforce scope at the API level, a curious or distracted engineer can stumble into cases they should not see - or worse, a reporting query can pull counts that include work outside their responsibility.
Assigned Scope as a Workflow Design
Latch takes the opposite approach. A Field Engineer role sees only cases explicitly assigned to that person. The restriction is enforced in the API and reflected in every surface: the mobile queue, search results, record counts, and direct case URL lookups. If a case is not assigned to Priya Nair in Nairobi, her view of the world does not include it. There is no filter to toggle and no URL to guess.
Kwame Mensah in Accra sees a different list. His queue contains only his assigned work. The system does not allow Priya to view Kwame's cases, and vice versa, unless an explicit reassignment occurs through an approved workflow. That boundary is what turns a case queue into a reliable field tool. The engineer opens the app and sees only what they need to act on. No scrolling through a shared inbox. No mental filtering of someone else's escalations.
Why a Navigation Filter Is Not Enough
A common pattern in field service tools is to give engineers broad read access and then show a "My Cases" tab. It appears to solve the problem because the default view looks clean. Failures appear later:
- The search box often searches across the entire workspace. An engineer searching for a site name may see cases from another region.
- Aggregated counts - badge numbers, "open" totals on dashboards - often reflect the full dataset, not the filtered view, and become meaningless.
- A direct link to a case, shared in a chat or SMS, may load a case the engineer should not access. If scope is not enforced at the point of retrieval, the record opens.
These are not edge cases. They are what happens when access control is a presentation concern instead of a data concern.
What an Assigned Case Contains
An assigned case in Latch brings together the customer name, site address, asset details, service history, and the evidence attached to past decisions. The field engineer does not need to open four different systems to understand what the job requires. The case record carries the context that was gathered during triage and review. The engineer arrives on site, opens the assigned case, and knows what has already been decided and what still needs to be resolved.
When the engineer adds notes, photos, or a completion confirmation, those updates flow back into the same record. The operations team can see the update without chasing down a WhatsApp message or an email thread. The case remains the single source of truth for what happened.
The Boundary That Matters
This model does not prevent escalations or reassignments. A case can be moved from one engineer to another through a deliberate step that records who transferred it and why. But the default state is that every field engineer lives inside their own assigned scope. That makes the queue smaller, the permissions simpler, and the audit trail cleaner. It also eliminates a class of error that starts with "I opened the wrong case."
For teams running field operations across multiple regions, this assigned-case model keeps data local to the engineer who needs it without complicating the underlying case record. The record is the same. The access is just properly bounded.
Continue reading: the field-service release overview, asset context for field service cases, why case status workflows need hard edges.