Operational case systems usually fail at the control points.
A queue can contain the work but fail to show risk. A report can count tickets but fail to explain whether the team is meeting its service commitments. An integration can create cases but rely on an access path that was designed for a person, not a system. An escalation rule can exist in configuration but still fail to govern the queue when it matters.
The last few weeks of Latch work focused on those higher-impact control points: SLA governance, queue risk visibility, programmatic access, status filtering, and escalation behavior.
The SLA report keeps targets, breach visibility, service-level objectives, and priority performance in one operational view.
SLA Governance Is More Configurable
SLA reporting only matters if the targets reflect how the team actually works.
Latch now supports admin-configurable SLA targets. Teams can set expectations that match the work in front of them instead of forcing every queue into a single global target. A payment exception, a field service issue, and a low-risk support request do not always need the same response or resolution standard.
The practical value is governance. Managers can review SLA performance against targets they actually own. Operators can see where the queue is at risk. Auditors and team leads can distinguish normal operational load from missed commitments.
SLA Breaches Are More Visible in the Queue
SLA reporting is retrospective. Queue visibility is immediate.
Recent work made breached SLA work more visible where operators spend their time: the ticket list. Tickets that are already outside target receive a clear list-level treatment and an explicit breached label.
That changes the operating behavior. A manager does not need to open every case or run a report to find the work that has already crossed the line. The queue itself shows which items need attention.
API Keys Separate System Access from Human Credentials
Customer environments need a clean way for systems to create or update work programmatically.
Programmatic access has moved toward customer-specific API keys. Integrations that create tickets or update operational records should not depend on a brittle browser-auth workaround. They need an auth path that belongs to the customer environment, records usage, and can be governed separately from a human login.
A payment processor, monitoring system, field service tool, or source system can create operational work through an access path designed for machine-to-machine use. The record still lands inside the same case-handling system, but the credential is scoped for the integration doing the work.
Status Filtering Makes the Queue Legible for Triage
Queues need filtering that matches how teams actually triage work.
Recent work improved ticket status filtering so operators can narrow a list to the work that matters: new, assigned, in-progress, resolved, or exception states. That keeps the everyday triage path simple: find the work in the right state, act on it, and move on.
The impact is that teams can separate these categories without turning every queue review into manual scanning.
Escalation Rules Preserve the Control Path
Queues need escalation behavior that admins can trust.
When a rule says certain work should escalate, the system needs to preserve that control path. That matters for SLA-bound queues, high-priority cases, and work that needs manager attention before it slips.
The point is straightforward: if an admin defines the rule, the queue should be able to use it.
The Case Record Now Tells a Clearer Control Story
These changes sit under the same operating principle: the case record should explain how work moved, why it moved, and what control applied.
SLA targets define the commitment. Breach visibility shows the current risk. API keys identify system-originated work without borrowing a human identity. Status filtering makes the queue legible. Escalation rules preserve the path for work that needs attention.
That is higher impact than surface polish. It changes how teams supervise work in flight and how they explain the record afterward.
The Direction
The common thread is not a single feature.
It is the move from generic ticketing toward controlled operational case handling. Queues need to show risk and ownership clearly. SLA configuration needs to match real operating commitments. API access needs to fit customer boundaries instead of borrowing a human login path. Escalation behavior needs to be part of the queue, not an assumption outside it.
That is the shape of the recent work: fewer hidden states, clearer controls, and better evidence at the points where teams actually make decisions.
Where Latch Fits
Latch is for operations teams that need more than a shared inbox and more control than a generic ticket queue.
If your team handles SLA-bound work, system-created cases, approvals, escalations, or high-risk operational exceptions, the system needs to preserve context from intake through resolution. Recent Latch work has been moving those pieces into the everyday surfaces operators use: the ticket list, SLA settings, ticket filters, governed API access, and the audit trail.
The goal is simple: make the work easier to run, and make the record easier to trust.