Task Queue

What It Is

Task Queue is retained as a superseded concept entry. Queue routing now belongs within the broader Task concept, together with assignment, role offers, arrival position and shared responsibility. The permanent identifier remains for historical references, while the active model explains work and its routing in one place. This consolidation follows the authoring contract’s distinction between broad nouns and settings or classifications within them.

For staff, a queue is a named context for shared work. An administrator can use it to organize work associated with a team rather than selecting a holder immediately. Team members can find those tasks through queue views and choose work to claim. The queue does not replace the task: each item still carries its own title, status, dates and assignment information.

What It Is Not

Queue routing is not task classification. Classification describes what kind of work a task is, while a queue supplies where it waits. It is also different from an unqueued offer to a security role. Both are shared-work choices, but the claim paths apply different eligibility checks. A queue view presents tasks matching a routing reference; it is not another copy of those tasks.

How It Is Used

Administrators maintain the named queue list and coordinators route tasks into it. Workers inspect queue views, claim available work and release work they cannot finish. The existing configuration and assignment capabilities remain available after conceptual consolidation. The planning change makes the routing facet easier to reason about alongside the task’s own status and holder.

Queue use also raises retirement questions. Staff can still have work referencing a queue after its active setting changes. Deleting configuration that work still references is different from hiding a selection in a picker. The owning capabilities and findings preserve that distinction rather than treating every inactive queue as empty or inaccessible.

Its Facets

Arrival position describes when each task entered its current queue. Claim and release describe reservation and return of shared work. Responsibility identifies the audience for overdue unclaimed work when the attention integration is enabled. Active setting and list order determine how the queue is presented for selection. These facets are described within Task in the active concept model.

The configuration screen also contains team, distribution, due-time and escalation controls. Their presence does not establish stored behavior. The relevant capability records the mismatch so later design can distinguish working queue routing from proposed extensions.

How It Relates

Task owns the work and its queue reference. Configuration groups administrator maintenance, while the Tasks screen groups worker views and actions. Platform responsibilities and attention supply shared oversight and reminder infrastructure; neither makes a queue a separate permission group of users.

What It Could Become

The product should decide retirement behavior and either remove unsupported controls or specify their effect. Future distribution or service-level features can extend task routing without reviving every queue setting as a broad concept. This superseded entry preserves the earlier model’s history while Task remains the active home for those design questions.