> ## Documentation Index > Fetch the complete documentation index at: https://docs.voxworks.ai/llms.txt > Use this file to discover all available pages before exploring further. # Batch Queue Management > How to read and manage a batch's queue — statuses, the Table, By day and Kanban views, bulk Pause/Resume/Cancel/Screen actions, locked items, suppression reasons, CSV export and the audit trail. ## What is the batch queue? Every batch has a **Queue** tab — labelled **Queue (`{count}`)** on the batch detail page — listing one row per contact per call attempt. The tab describes itself accurately: "Per-contact planning items. The queue is the source of truth — calls are launched from here near execution." That last part matters. The scheduler doesn't create all of a batch's calls up front. Instead, each queue item is assigned a planned date and time, and the actual call is only created shortly before it's due to dial. Everything you do in the queue — pausing, cancelling, screening, reprioritising — therefore takes effect before money is spent on a call, right up until the moment an item launches. The queue updates in real time: as the planner assigns times, calls launch and results come back, rows change in front of you without a manual refresh. When a retry is due (for example after a voicemail or no-answer), it appears as a *new* queue item for the same contact with a higher attempt number — see [Batch Calling Rules & Retries](/batches/calling-rules) for the retry policies themselves. *** ## Queue statuses Each item carries a status pill. The tabs across the top of the queue — **All**, **Planned**, **Launched**, **Completed**, **Suppressed**, **Pending**, **Failed** — show a live count for each and filter the view with one click. | Status | What it means | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Pending** | In the queue but not yet assigned a dial time. New contacts start here, and items return here when they're paused or when their planned slot is released. | | **Planned** | Assigned a specific date and time within the upcoming schedule window. The Scheduled column shows when. | | **Launched** | Handed to the dialler — a call record now exists for this attempt. From here the call itself takes over; see [Call Statuses & End Reasons](/calls/statuses). | | **Completed** | The attempt finished. Reaching voicemail also completes the item — any voicemail retries are created as separate new items by the retry policy. | | **Failed** | The attempt ended in failure. Retryable failures (busy, no answer, transient errors) spawn a fresh queue item for the next attempt where the retry policy allows. | | **Suppressed** | Reserved for automatic holds the platform can place on an item without cancelling it. You won't typically produce this yourself — pausing, unscheduling and cancelling from the queue currently show under their own statuses below instead. | | **Unscheduled** | Reserved for items removed from the schedule but kept in the queue. Using the platform's unschedule mechanism currently returns an item to **Pending** with a padlock rather than this status. | | **Cancelled** | Permanently withdrawn. Cancelled items are never planned or dialled again. | | **Inbound returned** | The contact called you back before their next attempt, so the pending attempt was withdrawn automatically (when **Cancel on inbound** is enabled in Calling rules). | ### Attempts The **Att** column shows the attempt number for each item. First attempts show `1`; retries are highlighted as `×2`, `×3` and so on. Retry items also carry an earliest-eligible time from the retry policy's delay — the planner won't schedule them before it. *** ## Three ways to view the queue A segmented control at the top right switches between three views. Your current search, filters and status tab apply to all of them. * **Table** — the full working view. Columns: **Scheduled** (time and day, or "Unscheduled"), **Contact** (name and phone number), **List**, **Script** (shows "Batch default" when no per-contact override applies), **Pri** (priority), **Status**, **Screen** (screening verdict) and **Att** (attempt number). A checkbox column on the left drives the bulk actions, and a padlock icon appears beside items that are locked in place. * **By day** — items grouped into one card per scheduled day (plus an "Unscheduled" group), each with an item count. Useful for sanity-checking how the planner has spread the batch across your calling window — see [Batch Scheduling & Pacing](/batches/scheduling) for how those days are chosen. * **Kanban** — five columns (**Pending**, **Planned**, **Launched**, **Completed**, **Suppressed**) with a card per contact, so you can watch work flow left to right while a batch runs. The By day view shows up to 30 items per day and the Kanban up to 50 per column; the header always shows the true totals. *** ## Searching, filtering and sorting The queue uses the same filter header as the other table pages: * **Search** matches contact name or phone number. * **Filters** can be combined across these columns: Contact, Phone, List, Script, DNCR (Clear / Pending / Blocked / Override / Unknown / Error), Scheduled (date range), Lock (Locked / Unlocked) and Attempts (number). * **Sorts** are available on the same columns, and a count line shows "`{n}` of `{total}` contacts" whenever a filter is active. The queue view loads up to 500 items at a time, so on very large batches use the status tabs and filters to focus the slice you're working with. *** ## Bulk actions Tick individual rows, or the header checkbox to select everything currently visible, then use the four buttons above the table. Each button reports how many items it changed and how many it skipped (items that were in a state the action doesn't apply to). | Action | What it does | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Pause** | Holds the selected contacts. Pending and Planned items return to Pending, are marked with a padlock and sit out of planning until you resume them. Items that have already launched but whose call hasn't started dialling are pulled back too — the pending call is cancelled and the contact is held for a later relaunch. | | **Resume** | Releases items you previously paused with the bulk **Pause** action, including ones held by a batch-level **Pause Scheduler**. They return to Pending without a padlock, and the next replan assigns them a fresh time. | | **Cancel** | Permanently withdraws the selected contacts. Like Pause, it also stops launched-but-not-yet-dialling calls. Cancelled items cannot be resumed. Items already completed, cancelled or returned by an inbound call are skipped. | | **Screen** | Runs every screening gate enabled in the batch's **Calling rules** (**DNCR**, **Opt-out**, **Previously called**) against the selected contacts right now, and writes the verdict to the **Screen** column. The result toast reports the outcome: "Screened `{n}` contacts — all clear", "— `{n}` blocked", or "— `{n}` blocked, `{n}` could not be verified" if a gate itself failed. | Two things to know about timing: * **There is a point of no return.** Once the dialler has claimed a call it is committed to dialling; Pause and Cancel deliberately leave it alone rather than drop a call mid-dial, and count it as skipped. Act while items are still Pending or Planned for guaranteed effect. * **Every action triggers a replan.** After a pause, resume, cancel or screen, the scheduler rebuilds the affected part of the plan so remaining items keep sensible times. You can also force this any time with the **Replan** button in the batch header. Pausing the entire batch with **Pause Scheduler** in the batch header stops the scheduler from planning or launching anything further. Any item that had already launched but whose call hadn't started dialling is pulled back to Pending and locked, the same as a bulk Pause; items still Pending or Planned simply sit idle until you resume rather than being individually locked. **Resume Scheduler** releases the locked items and reactivates planning. See [Batches: Overview & Lifecycle](/batches/overview). *** ## Locked items The amber padlock in the Scheduled column (and on Kanban cards) marks a **locked** item. The planner treats locked items as fixed: it never moves their time, releases their slot or re-suppresses them during a replan. Items become locked when you pause them individually with the bulk **Pause** action, and the same lock is applied to any call a whole-batch **Pause Scheduler** pulls back mid-launch — the lock is what guarantees they stay put until you decide otherwise, and resuming removes it. You can filter the queue to locked items with the **Lock** filter. Finer per-item controls — pinning a single contact to an exact date and time, editing an individual item's priority, or unscheduling one row without pausing it — are coming soon to the queue view. *** ## Priority The **Pri** column shows two numbers, `list.contact` — for example `1.3` means list priority 1, contact priority 3. Lower numbers dial first: * **List priority** comes from the **Priority** you set on each source list in the batch's Settings tab. * **Contact priority** is assigned automatically as each contact enters the batch's queue — you don't set it directly. Where items tie on both numbers, the planner interleaves contacts from different lists round-robin so no single list monopolises a day. Priorities are managed through the source lists — see [Source Lists, Allocation & A/B Testing](/batches/source-lists). *** ## Screening and suppression The **Screen** column shows each contact's consolidated screening verdict: | Screen | Meaning | | ----------- | ---------------------------------------------------------------------------------------------------- | | **Clear** | Passed every enabled gate — free to dial. | | **Pending** | Not screened yet; the platform screens contacts automatically ahead of launch. | | **Blocked** | Failed a gate — the item is parked and will not dial. | | **Error** | A gate could not complete its check. Screening fails closed: the contact is held rather than risked. | | **Unknown** | No screening information recorded yet. | Verdicts age out: after the recheck period (30 days by default) a contact is screened again before any further attempt. The separate **DNCR** filter reflects the contact's latest Do Not Call Register wash result specifically — see [DNCR Washing](/contacts/dncr-washing). When an item is held rather than dialled, the platform stores why internally — a pause, an unschedule, a cancellation, an inbound return, or a screening block — but doesn't yet surface that reason as a label in the queue view. Use the **Status** and **Screen** columns instead: a **Blocked** or **Error** verdict holds the item back from dialling for as long as it applies, without cancelling it outright. See [Batch Screening Gates](/batches/screening-gates). *** ## CSV export The download button in the queue's filter header exports the rows currently matching your tab, filters and search — filter first, then export — to a file named `batch-queue.csv` with these columns: | Column | Example | | --------- | ---------------------------------------- | | Scheduled | `2026-07-20T09:30:00+10:00` | | Contact | `Sarah Nguyen` | | Phone | `+61400123456` | | List | `July prospects` | | Script | `Renewal follow-up` (or `Batch default`) | | Priority | `1.3` | | Status | `planned` | | DNCR | `clear` | | Attempts | `2` | *** ## Audit trail Every change to a batch's schedule and queue is recorded as an audit event: plans and replans, scheduler pauses and resumes, bulk pauses, resumes and cancellations (with counts and the affected items), screening runs and their results, priority and schedule changes, and script changes — each with who performed it and when. The dialler adds its own events automatically as items launch, finish, retry and are superseded by inbound calls. The audit trail isn't yet visible in the app. Speak to the Voxworks team for further custom configuration. *** ## Next Steps * [Batch Scheduling & Pacing](/batches/scheduling) — how queue items are assigned days and times: business hours, caps and ramp profiles. * [Batch Calling Rules & Retries](/batches/calling-rules) — the per-outcome retry policies that create repeat queue items, and Cancel on inbound. * [Batch Screening Gates](/batches/screening-gates) — the DNCR, opt-out and previously-called gates behind the Screen column. * [Call Statuses & End Reasons](/calls/statuses) — what happens to an item's call after it launches.