A queue built on case status alone forces a choice: make the status expressive and destroy your reporting, or keep it clean and hide everything the operator needs to know. Most teams push the detail sideways - into tags, form notes, or a separate spreadsheet - because the case system penalizes granularity. The moment you add "Awaiting third-party inspection" as a status, your metrics on open cases become unreadable.
Subcategories are a simple correction. They add operational detail inside a governed status without creating a new status slot. Canonical states such as Assigned, In Progress, On Hold, Resolved, and Closed remain the anchors for reporting and transition rules. A subcategory like "Field visit scheduled," "Parts in transit," or "Monitoring after repair" sits next to the status label and changes as the work progresses.
This matters most where status conveys phase, not activity. Consider a field-service operation where a technician must visit a remote site to repair equipment. The case moves to In Progress the moment dispatch confirms the visit. But that single status hides at least four distinct operational moments: the visit is scheduled, the technician is en route, the repair is underway, and the equipment is under observation after the fix. A reporting dashboard groups all four under In Progress. The operator triaging the queue, however, needs to distinguish a case that can advance today from one that cannot.
Without subcategories, the operator must open each case to read the notes. With subcategories, the queue shows the exact moment and the status remains In Progress. "Visit booked," then "Site arrival," then "Repair in progress," then "Post-repair monitoring" appear inline next to the status. The reporting layer ignores them entirely, so the open-case count stays clean. The operator sees exactly where each case stands without breaking the transition guardrails that case status workflows need hard edges. The status still governs what transitions are allowed, and the enforcement does not change when someone adds a subcategory.
Decision guidance: when to use a subcategory and when to use a tag. A subcategory is useful when the information describes where the operator is in the resolution sequence, it changes as the work moves forward, and it would be valuable to see in the queue at a glance. If the detail is static - a classification label like "Hardware" or "Software," or an issue type like "Payment discrepancy" - tags are the correct tool. Subcategories answer "what is happening right now?" Tags answer "what is this case about?" Conflating them creates noise. A case tagged "Hardware" with a subcategory "Parts ordered" is clear; a case with a dozen subcategories that try to capture classification, priority, and phase all at once becomes unreadable.
One common failure mode is treating subcategories as soft statuses. Teams add a subcategory "Awaiting customer approval" inside In Progress, then expect status reporting to count it as a separate state. It does not, because the canonical status remains In Progress. That is a feature, not a bug. If the work needs a different transition gate, use the status workflow. If it needs a different service commitment, use the applicable SLA policy. Subcategories describe activity within a phase; they do not create new phases or policies.
Another failure mode is subcategory sprawl. If the configured list tries to encode every person, vendor, and part number, the queue turns into a second notes field. Subcategories work best when they are few, standardized, and mutually understood across the team.
Honest limits. Latch validates that an active subcategory belongs to the case's current status, but the label does not prove the underlying event happened. If an operator marks a case "Parts in transit" but the order was never placed, the subcategory will not catch the gap. Subcategories also cannot replace workflow branching logic or change the allowed status transitions.
Subcategories do not create reopen paths or introduce ambiguity about what "Resolved" means. They describe the work currently happening inside a known phase. If a case needs to reopen after resolution, the status machinery handles it as described in designing safe reopen paths. The subcategory resets to match the new phase.
For operations that treat duplicate, rejected, and cancelled as real outcomes, stage-specific subcategories can add a standardized operational label without replacing the notes and references that explain the individual decision.
Start with the signal you need, not the signal the tool can store. A subcategory is valuable when it reduces the number of case-open clicks an operator performs during triage. If the subcategory does not save a click or change a decision, it is not worth maintaining. Test it against a real queue: pick three subcategories for the In Progress phase, run them for a week, and ask the team if the queue became faster to scan. If the answer is yes, keep them. If not, remove them. The standard is measured in operator seconds, not in feature completeness.
Read more in the July product update.