Exception queue

An exception queue holds work that failed a rule, lacks required evidence, crossed an authority limit, or encountered conflicting state. It is broader than an approval queue. An approval item may be complete and simply need an authorized yes or no; an exception may require investigation, correction, tenant contact, vendor clarification, or a system retry before any approval is meaningful.

Each item should identify the property, affected record, triggering event, reason code, current risk or deadline, responsible owner, required evidence, allowed next actions, and age. The queue should preserve the underlying workflow state rather than copying a vague task such as “check payment.” A returned ACH, for example, needs the original receipt, provider return code, ledger effect, communication status, and any retry eligibility.

Suppose a maintenance estimate is below the owner’s normal cap but the vendor’s insurance record expired yesterday. The dollar rule passes while the eligibility rule fails. The system routes an exception to obtain and verify current evidence; it should not ask the owner to approve the price as if that resolves the credential gap.

Queues fail when everything becomes “high priority,” items have no owner, or closing a card does not repair the source record. Use service levels based on actual consequence and deadline, not cosmetic urgency. Closure should record the disposition and resume, revise, or terminate the original workflow. Review recurring reason codes to fix upstream configuration instead of staffing an ever-growing manual inbox.