The Omnichannel Queue Events Table: Every Queue Stay, Column by Column

Every time a ticket or a phone call enters a Zendesk omnichannel queue, Qvasa records a stay: when it entered, when it left, why, and how deep the queue was at each end. The Omnichannel Queue Changed Events table shows those stays one row at a time. This guide is the reference for that table: what a row is, every column, every inbound and outbound reason you can see, which setting turns the data on, where the history starts, and how the two ways Qvasa learns about queue movement show up in the rows.

The queue metrics built on the same history (entering, exiting, queue height, wait time) have their own guides; this one is about the rows themselves.

Why This Exists

Queue metrics answer "how many" and "how long". When a number looks off, or an automation or an AI agent needs the facts behind it, you need the stays themselves: this ticket entered the Billing queue at 09:12 as NEW, was transferred out at 09:40, and was accepted from the Overflow queue at 09:51. The table is that audit log. It is also the widget an AI agent reads through the User Access API when it checks a queue number ticket by ticket, so its column descriptions are written to be read by people and by agents alike.

Before You Start

Omnichannel queues must be on for your account. Qvasa enables the feature internally first; an account admin then turns on Zendesk omnichannel queues in Settings. Without both, the widget is not offered and the table answers that work item records are not enabled.
Live updates are optional. A second setting, omnichannel queue live updates, adds the live polling writer described below (about one Zendesk call a minute). Without it the table still fills from the ticket audit pipeline, with fewer details per row.
Phone calls appear only with Zendesk Talk. Call stays (channel TALK) come from the Talk integration; without it the table holds ticket stays only.
In the widget picker the table is a Configurable table named Omnichannel Queue Changed Events. Through the User Access API and the MCP tools it is the widget omnichannel_queue_changed_events_table, and every column identifier starts with oqce_.

Step 1: Add the Table to a Dashboard

Edit a dashboard, click Add Widget, choose Configurable table and search for Omnichannel Queue Changed Events. The table opens with its two default columns, ID and Queue Started At; open Configure Columns from the widget's menu to add the rest. Rows are sorted newest stay first, and the dashboard's date range selects stays by when they entered the queue.

Open stays (a ticket still waiting) sit at the top with no end time and a Time In Queue that keeps counting; closed stays carry their exit time and an outbound reason. Every column header has an ⓘ that shows the column's full description, the same text your AI agent sees in the widget catalog.

Step 2: Read the Columns

The columns fall into six groups. The identifier in brackets is what the User Access API uses.

Group	Column	What it holds
The stay	ID (`oqce_id`)	The stay's own identifier in Qvasa. Always present.
	Queue Started At (`oqce_queue_started_at`)	When the work item entered this queue. Always present; the date range and the default sort use it.
	Queue Ended At (`oqce_queue_ended_at`)	When it left. Blank while it is still in the queue.
	Time In Queue (`oqce_duration_in_queue`)	Entry to exit, or, for an open stay, entry to now.
	Status (`oqce_status`)	Open (still in the queue) or Closed (has left it).
	Event Type (`oqce_zendesk_event_type`)	The Zendesk routing event that opened the row: INBOUND today; ROUTING_STATE_CHANGE and TYPE_UNKNOWN are reserved.
Where	Queue (`oqce_queue_name`)	The queue the work item entered.
	Previous Queue (`oqce_previous_queue_name`)	The queue it came from on a transfer. Blank on a first queue.
	Channel (`oqce_channel`)	SUPPORT (email and web tickets), MESSAGING, or TALK (phone calls).
Why	Inbound Reason (`oqce_inbound_reason`)	Why it entered. The values are listed in the next section.
	Outbound Reason (`oqce_outbound_reason`)	Why it left. Blank while it is still in the queue. The values are listed below.
How busy	Inbound Queue Size, Inbound Previous Queue Size (`oqce_inbound_channel_queue_size`, `oqce_inbound_previous_channel_queue_size`)	How many work items the channel's queue held at the moment of entry, and just before it.
	Outbound Queue Size, Outbound Previous Queue Size (`oqce_outbound_channel_queue_size`, `oqce_outbound_previous_channel_queue_size`)	The same two counts at the moment of exit. All four are recorded by live polling only; audit-sourced rows leave them blank.
The work item	View in Qvasa (`oqce_show_ticket_in_qvasa`), View in Zendesk (`oqce_show_ticket_in_zendesk`)	Buttons to the ticket. View in Zendesk uses the Zendesk id stored on the stay itself, so it works before Qvasa has synced the ticket; View in Qvasa needs the stay linked to a Qvasa ticket and otherwise reads "No ticket yet".
	Zendesk Ticket ID (`oqce_zendesk_ticket_identifier`), Zendesk Phone Call ID (`oqce_zendesk_phone_call_identifier`), Qvasa Ticket ID (`oqce_ticket_id`)	The identifiers behind the buttons. Ticket stays carry the Zendesk ticket id; call stays the Zendesk call id. The Qvasa ticket id is blank for calls and for stays not yet linked.
Who recorded it	Source (`oqce_source`), Outbound Source (`oqce_outbound_source`)	Which writer opened the row and which closed it: polling or audit (see Step 4).
	Inbound Event ID (`oqce_zendesk_inbound_event_identifier`), Outbound Event ID (`oqce_zendesk_outbound_event_identifier`)	Zendesk's own event ids for the entry and the exit, when polling recorded them.

Step 3: Know the Reasons

Zendesk reports a reason with every queue entry and exit it tells us about. Qvasa adds a few values of its own for stays it had to infer rather than observe, so that every row says how it was closed. The raw values are shown as-is, in the table and through the API.

Inbound Reason: why the work item entered the queue

Value	Recorded by	Meaning
`NEW`	Zendesk, through live polling	The first queue after the ticket or call was created.
`TRANSFERRED_IN`	Zendesk, through live polling	Moved here from another queue. Previous Queue names it.
`ASSIGNED`	Zendesk, through live polling	Routed into this queue by an assignment.
`BACKFILLED_FROM_OUTBOUND`	Qvasa	Qvasa first learned of this stay when it ended: the exit arrived with no entry on record, so the entry was reconstructed from the exit.
blank	the audit pipeline	Audit-sourced rows carry no reason: a ticket audit says which queue the ticket is in, not why.

Outbound Reason: why the work item left the queue

Value	Recorded by	Meaning
`ACCEPTED`	Zendesk, through live polling	An agent accepted the work item.
`TRANSFERRED_OUT`	Zendesk, through live polling	Moved to another queue; the next stay for the same work item shows TRANSFERRED_IN.
`ASSIGNED`	Zendesk, through live polling	Routed out of the queue by an assignment.
`OUTBOUND_UNKNOWN`	Zendesk, through live polling	Zendesk reported the exit without a reason. The value is Zendesk's own and is passed through unchanged.
`UNOBSERVED_TRANSFER`	Qvasa	Qvasa saw the ticket in a new queue without seeing it leave this one, so it closed this stay at the moment the new one began.
`LEFT_QUEUEING`	Qvasa	The audit pipeline saw the ticket leave omnichannel queueing altogether, usually because it was assigned or solved.
`STALE_OPEN_ROW_SWEPT`	Qvasa	A newer event for the same ticket or call arrived while this stay was still open, so this stay was closed as stale at that event's time.
`SUPERSEDED_LATE_ARRIVAL`	Qvasa	Qvasa learned about this stay after later history for the same work item was already recorded. The stay is kept and closed at the next known boundary; it never counts as the current queue.
blank		The work item is still in the queue.

Two values you may know from elsewhere are not in this table. MANUAL_ASSIGNED and REOPENED are reasons on messaging work items, the per-agent record of a chat being offered and worked; they belong to the messaging concurrency and capacity data, not to queue stays.

Step 4: Know the Two Writers

Qvasa learns about queue movement in two ways, and a row can be written by either. The Source and Outbound Source columns tell you which.

The ticket audit pipeline (audit) comes with the feature at no extra Zendesk cost. Every ticket audit Qvasa already syncs can say the ticket's queue changed, and the pipeline opens and closes stays from those changes. Audit rows have no reasons and no queue sizes, and their channel is taken from the ticket.
Live polling (polling) is the optional live updates setting. About once a minute Qvasa reads Zendesk's queue events and writes the full row: Zendesk's reasons, the queue sizes at entry and exit, and Zendesk's event ids. Polling also sees phone calls, which audits do not.
They converge. A work item has at most one open stay at a time. When both writers report the same stay, the polling row is kept because it is richer, and the audit pass only confirms it. Whichever writer records a newer moment for a work item closes any stay left open from before, which is where STALE_OPEN_ROW_SWEPT and UNOBSERVED_TRANSFER come from.

Data Start and Backfill

History starts the day omnichannel queues were enabled for your account. Nothing before that day is backfilled: Zendesk's queue events are not available in arrears, and the audit pipeline only reads forward. Ask Qvasa support for your account's enablement date if you need it.
Queue sizes and Zendesk's reasons exist from the day live updates were turned on. Stays from before that, and audit-sourced stays after it, leave those columns blank.
The ticket status a stay began with, which the by-status queue charts use, is recorded from the day that breakdown was enabled; earlier stays show as Unknown status in those charts.
Stays heal forward, not backward: a gap in the history is closed by the next event Qvasa sees for the same work item, as described above, and is never rewritten from scratch.

FAQ

The table shows LEFT_QUEUEING and OUTBOUND_UNKNOWN. Are these real? Yes. OUTBOUND_UNKNOWN is Zendesk's own value when it gives no exit reason; LEFT_QUEUEING is Qvasa's value for an exit the audit pipeline observed. Both are listed in Step 3 and in the column's ⓘ description.
Why is Inbound Reason blank on some rows? The row was opened by the audit pipeline, which sees the queue but not the reason. Source reads audit on those rows.
Why does View in Qvasa read "No ticket yet"? The stay is not linked to a Qvasa ticket: a call still ringing, a ticket Qvasa has not synced yet, or a stay reconstructed from its exit. View in Zendesk still works, because it uses the id on the stay.
Why do I see MANUAL_ASSIGNED in my data? You are reading messaging work item data, not this table. It is a reason a chat was handed straight to an agent; see the messaging concurrency and capacity guide.
Can I filter the rows? The dashboard's date range selects stays by Queue Started At. Ticket filters (tags, fields, status) apply to the stays of the tickets that match them, so stays not yet linked to a ticket drop out of a ticket-filtered table.
Does a transfer count as two stays? Yes. The stay in the first queue closes with TRANSFERRED_OUT and a new stay opens in the second queue with TRANSFERRED_IN and the first queue named in Previous Queue. Queue metrics count stays, not tickets.