Queues and Workers
A Task Queue is one configured operational queue, not a template that generates other queues. It holds Tasks of admitted Queue-mode Definitions. Configuration access, pool membership and dispatcher authority are separate.
Build the Queue
Section titled “Build the Queue”- Create a Queue in Task Queues with its key, display name and description.
- In Task Definitions, admit the Queue-mode Definitions it may receive.
- In Workers, add specific Workers or sources based on workspace roles or responsibility groups. Effective membership uses current facts and a valid Worker-to-User association; it is not a copied employee list.
- In Dispatchers, map the workspace roles that may perform operational distribution and intervention in this Queue. These mappings do not grant Configuration Management or rights in another Queue.
- Configure Prioritization, Getting work and Limits & warnings. Use an Active Queue for new intake. Verify the flow as an intended Worker.
Initial placement requires the Definition’s Creator authority and an admitted active destination; the Creator need not be a pool member. Later movement uses Change queue authority and additional runtime restrictions. Removing a Worker source or changing a role does not silently release existing assignments.
Ordering and acquisition are different
Section titled “Ordering and acquisition are different”Prioritization has five modes:
| Mode | Shared order |
|---|---|
| Queue entry | Time of entering the current Queue; ascending is the default. |
| Creation date | Immutable Task creation time. |
| Due date | Current due time; missing dates are last in either direction. |
| Numeric priority | Priority followed by Sub-priority, with the same direction for both. |
| Manual | Explicit shared order; arrivals append and an authorized user can move a task. |
Automatic ties use Queue entry ascending, then stable Task ID. Moving to another Queue creates a new residence, including a later return to an earlier Queue. Switching from automatic order to Manual captures the current effective order. Personal grid sorting, filters and visible pages never replace the shared order.
Getting work controls how a Worker receives an eligible task:
| Mode | Effect |
|---|---|
| Any | The Worker selects an eligible task. |
| First / Last | Take the first/last eligible task in the shared order. An ineligible end row is skipped. |
| Auto-assignment | A Queue-bound algorithm runs for enabled automatic causes; both role actions below remain available. |
| Assignment on request | The same algorithm runs on explicit requests; automatic causes are inactive. |
In both algorithm modes, eligible Workers can use Give me work and authorized dispatchers can use Distribute tasks now. One actor may have both actions. Each new Worker request attempts a new assignment; existing assigned work only contributes to capacity. Neither distribution nor acquisition automatically starts execution unless the user explicitly chooses a supported Take and start.
Restricted future-work visibility is incompatible with Any. For a restricted Worker, First/Last exposes only their current candidate; algorithm modes do not expose a future backlog. Broader rights remain scoped to the actual Definition or Queue. See operational Queue work.
Algorithms and working time
Section titled “Algorithms and working time”Select the bundled standard algorithm or a compatible published customer Queue selector. The standard algorithm follows effective Task order and prefers eligible Workers with the smallest global assigned count; equal loads use stable Worker ID. It updates projected load between proposals, then the runtime rechecks each assignment. Custom code proposes assignments; it does not bypass those checks.
Automatic Task-entry/state-change causes and CRON belong to the Queue. The
default CRON is */20 * * * *; a null time zone uses the workspace zone.
Changing to a manual acquisition mode retains algorithm settings without using
them. An unavailable selected algorithm is diagnosed, not silently replaced.
Consider working time applies to Auto-assignment and Assignment on request. When enabled, the runtime obtains the Worker’s effective working-time facts before admission. Missing required facts do not create an assumed all-day shift. The setting is inactive in Any/First/Last and is not an execution-start calendar gate. A custom selector does not need to reimplement the shared schedule filter.
Queue limits and Worker Profiles
Section titled “Queue limits and Worker Profiles”Queue hard maximums cover concurrent In progress and Postponed work. WIP, Paused and Blocked thresholds warn only. WIP includes every unfinished task in the Queue, including unassigned and future-available work; it is not an intake cap.
Worker Profiles supplies global capacity per Worker across all Direct Responsible and Queue Executor assignments. Owner and managing Queue Responsible do not consume performer capacity merely by holding those positions.
- The mandatory Default applies when the Worker has no specialized membership. It cannot be deleted. A new specialized profile copies the current Default once; later Default changes do not change that copy.
- Each Worker has at most one specialized membership. Batch transfer is atomic; one invalid or stale member rejects the whole batch. Removal returns the Worker to Default. A specialized profile must be empty before deletion.
- Maximums are Assigned, In progress, Paused and Postponed. Null means unlimited; zero prevents an increase. Warning zero means off, and positive count warnings trigger strictly above their threshold.
- Assigned counting includes all unfinished assigned tasks by default. The alternative counts only Idle; it does not add another hidden overall ceiling.
- Lowering a limit preserves existing assignments and running work. Lawful return to Idle can retain assignment above an Idle-only limit; new load increases are blocked until capacity permits them.
Dispatcher exceptions are explicit, default-off settings with a requested reason. They apply only to the relevant Queue or profile limit and require a dispatcher of that task’s Queue. They do not apply to Direct work or override Worker validity, Task permissions, availability or arbitrary refusals.
Use Drain to stop new intake while retained work is processed or moved out. Draining is not deactivation. A nonempty Queue cannot be deactivated; investigate stalled progress through signals.