Most teams set one SLA. Every case, regardless of the work inside, inherits the same set of response and resolution targets. When the work is uniform, that is adequate. When the work splits into categories that differ in urgency, complexity, or operating hours, a single policy produces two failure modes. Some cases get measured against targets that are too aggressive, so the team lives in permanent breach. Others get measured against targets that are too loose, so real delays go unreported.
This release extends the SLA model with complete tag-specific policies. A direct case tag can now select the full configuration: overall attainment target, first-response attainment target and minute threshold, resolution attainment targets and minute thresholds for Critical, High, Medium, and Low priorities, plus working-hours definitions. If more than one applicable tag maps to a policy, the system applies a deterministic selection rule and records which tag triggered the match.
What changes
Earlier tag overrides could change limited timing values while the rest of the commitment still came from the general policy. That made it difficult to say: "On-site visit cases use one set of attainment targets and local working hours, while remote recovery cases use another complete commitment." The timing could differ while the policy explanation remained partly blended.
Tag-specific policies remove that constraint. An operations lead can now define distinct SLA policies and anchor each one to a case tag. When a case is created or updated with a matching tag, the corresponding policy is selected and snapshotted onto the case record. From that point forward, the case runs against that policy's targets and working hours. Reporting later shows what the commitment was at the time the case was open - not just what the current configuration says.
Policy definition
Each tag-specific policy is a self-contained commitment block. It specifies:
- An overall attainment target percentage.
- A first-response attainment target percentage and minute threshold.
- Resolution attainment target percentages and minute thresholds per priority tier: Critical, High, Medium, Low.
- A working-hours configuration that determines when the clock runs.
The working-hours setting inside each policy uses the same working-hours-aware SLA deadlines model already available for general policies. The difference is that different tags can now carry different working-hours windows. An on-site tag might track a 9-to-5 window in the customer's timezone. A remote tag might track a 24/7 clock.
How policy selection works
A case can carry multiple tags. When more than one tag maps to a defined SLA policy, Latch selects the strictest applicable resolution target for the case priority, with a stable tie-break when targets are equal. The selected source is recorded on the case. This makes the result predictable without adding a separate policy-order setting.
The chosen policy, along with the triggering tag, is written into the case record as a snapshot. The snapshot preserves the target percentages, response and resolution minutes, and working-hours basis that governed the case, even if the policy is later updated. Without that snapshot, an SLA report generated after a policy change could silently re-measure old cases against new targets.
Reporting by policy
SLA reports now break outcomes down by policy rather than blending them into one rate. A report shows which cases were governed by which policy, what the targets were, and whether each case met them. Default, tag-specific, and manually set policies appear as separate populations so that a single dashboard does not hide the difference between a 2-hour on-site target and a 4-hour remote target.
This separation matters most when commitments differ. A blended rate that flattens everything into "95% met SLA" conceals the real story. One team might be failing on-site visits consistently while remote cases sail through. Breaking outcomes by policy exposes that pattern without requiring a separate queue rebuild.
What this is not
Tag-specific policies do not replace the default SLA policy. The default remains the fallback for any case that carries no matching tag. The model also does not automate tag assignment - tags must be applied during case creation or triage, either manually or through an external automation rule, before the policy selection fires.
This update also does not introduce new queue-health metrics. The metrics already available - breach status, time-to-response, time-to-resolution - remain the same. The change is in how the targets are assigned and how reporting explains the commitment that actually applied. For teams that want to measure more than first response, queue health measures beyond first response still apply across all policies.
Where this fits
Tag-specific SLA policies extend the control model introduced in the April and May product update, where SLA editing and working-hours support were added. That update made the SLA configurable. This update makes it disambiguated. The two together turn the SLA from a single flat rule into a structured set of commitments that match the actual shape of the team's work.
A shared inbox hides variation; a single SLA ignores it. Tag-specific policies let the measurement model match the operational model.