Queues and SLAs
Last updated September 21, 2026
Use legal-task ownership, priority, due dates, notification state, and workflow context to manage review queues without overstating built-in SLA automation.
What is implemented#
The repository exposes task lists, matter task APIs, human task APIs, task approval/retry routes, notification streams, usage views, and matter-level task panels. It does not define a separate queue service with formal SLA guarantees. Queue and SLA language should therefore describe operating practice for legal work, not a platform guarantee.
Design queues around ownership#
Use legal workflow definitions, assignees, human review tasks, and notifications to route work to accountable attorneys, paralegals, or legal-ops groups. Keep the queue model simple enough that a supervising attorney can explain why a task is visible, who owns it, and what completion means.
Use due posture carefully#
The UI can display task counts and due-related posture where data exists, but these docs should not claim a formal SLA engine unless the workflow explicitly creates escalation tasks or notifications. If you use labels such as Healthy, At Risk, and Breached, define them in workflow or reporting logic.
| Posture | Typical behavior |
|---|---|
| Healthy | No intervention needed |
| At Risk | Visible in supervisor views and escalation watchlists |
| Breached | Escalation task or notification is created by your workflow logic |
Queues should be reviewable
If a supervising attorney cannot explain why a review task is in a queue or why it is prioritized the way it is, routing policy probably belongs back in the legal workflow design review.
Align task posture with notification policy#
Matruno exposes notification surfaces and task counts in the application. Use them together. If a workflow uses At Risk or Breached posture, pair those states with explicit supervisor notifications or escalation tasks so the model produces action, not just reporting.
Was this helpful?