Auto-Assignment & Operator Capacity

Auto-assignment takes newly created tickets and routes them to the right operator without manual triage. When enabled, Ticket0 picks the eligible operator with the lowest current load and assigns them the ticket.

How auto-assignment works

Turn on auto-assignment in Settings → Routing. Once enabled, every ticket that is not already claimed by a routing rule is distributed via round-robin:

• Only operators who are Available are considered.
• The operator with the fewest open + pending tickets receives the next ticket.
• Ties are broken by join date so the order stays stable.

If every eligible operator is at their workload cap or marked Away, the ticket stays unassigned in the shared inbox.

Availability (Available / Away)

Each operator controls their own availability from the top-bar profile menu:

• Available — the operator can receive auto-assigned tickets.
• Away — the operator is skipped by auto-assignment; existing tickets remain assigned.

The menu also shows the operator's current load as X / Y open, where Y is the effective cap (or ∞ when uncapped).

Workload caps

Caps limit how many open + pending tickets an operator can hold at once.

• Workspace default — set in Settings → Team. Applies to every operator unless overridden.
• Per-operator override — set on each member row in Settings → Team. null falls back to the workspace default.

A blank cap means no limit. A cap of 0 removes the operator from auto-assignment without marking them Away.

Overflow behavior

When all eligible operators are at cap or Away, incoming tickets remain unassigned. Use the Unassigned filter in the inbox to see them.

When an operator frees a slot by resolving, closing, snoozing, or reassigning a ticket, or when they flip from Away to Available, the system assigns one queued ticket to them — the oldest unassigned open or pending ticket. One ticket per event keeps load from spiking unexpectedly.

Interaction with routing rules

A routing rule can target a specific operator. If that operator is unavailable or already at cap, the rule does not force the assignment. Instead it falls through to round-robin, and the audit log records fallbackFromRuleTarget so you can see what happened.

Limitations and good to know

• One ticket is assigned per capacity event. Raising a cap does not retroactively pull tickets until the next resolve/availability event.
• Auto-away after inactivity and separate chat/email caps are not implemented yet; the schema carries an availabilityChangedAt timestamp so a future auto-away job can be added without a migration.
• Auto-pickup from the unassigned backlog writes an in-app notification and an audit log entry but does not emit a ticket.assigned webhook.