Reset a VICIdial list: understand the flag and check the result

01 / 05

1. Decide what needs to change

List reset, disposition, attempt count and the hopper answer different questions. A list reset is a list-wide action on the called-since-reset flag. A status records the lead outcome; the hopper stages eligible work. Do not use one as a synonym for another.

If the actual problem is an empty hopper, first use the hopper guide to find the failing gate. Resetting an entire list just to see what happens can affect leads that were intentionally finished.

Understand the hopper and eligibility gates →

Compare call-count limits →

02 / 05

2. Isolate the list and capture the baseline

Use a list made for this exercise, not a production calling list. Keep the test campaign inactive while preparing and confirm the owner has approved the specific list and time. List IDs below are labels: choose unused IDs on your system.

Download the worksheet and replace its fictional rows with internal labels for your synthetic leads. Record the installed build and observation time, including time zone. Do not put actual customer numbers in the worksheet.

1. Open Campaigns and record the test campaign ID, Active setting, Dial Statuses, call time and applicable attempt limits. Record the original settings so the owner can restore them.
2. Open Lists → Show Lists and select the dedicated test list. Record its exact ID, campaign, Active setting and lead count. Stop if the list belongs to a different campaign or contains records outside the test.
3. Inspect at least one uncalled and one previously attempted synthetic lead. For each, record lead ID or a private label, status, called-since-reset flag, attempt counts and any scheduled callback. Preserve any distinct history or report reference.
4. Compare the count and identities with the approved test plan. If either differs, reconcile the population before anyone performs a list-wide action.

You should seeThe baseline identifies the whole intended list and separately records each state that you plan to compare.

Download the list-reset ledger (CSV) →

03 / 05

3. Review the exact action before using it

The official API documentation defines update_list with reset_list=Y as resetting the Called-Since-Last-Reset flag for all leads in that list. This is a description of the API field, not proof that every release presents the same screen or that every other field remains unchanged.

In the captured installed source the list screen labels the control Reset Lead-Called-Status for this list. Its reset branch checks a daily reset limit before changing the flag; inspect the limit and any additional options on your own build. Ask the system owner to verify whether callback records, counters and history are affected in that build. Keep these as separate observations, not assumptions.

1. Read the current list ID and campaign again immediately before the action. Confirm the campaign remains inactive and that the list contains only approved synthetic leads.
2. Have the authorized operator review the control and the baseline. If the label, scope or expected behavior is unclear, stop and obtain a build-specific explanation.
3. Only after the operator approves the scoped change, use the installed list reset control once. Record the time and any confirmation shown; do not treat a button click alone as proof of changed records.

Native list reset, reset-time and daily-reset-limit controls

Open to enlarge

You should seeThe operator has a specific list, action, time and original state to audit. This is a reader-run procedure; no reset was executed for this guide.

04 / 05

4. Compare the saved records

Refresh the list and inspect the same lead identities from the baseline. Add a separate after row for each, retaining the original values. Include callback and attempt fields even when they appear unchanged; your installed build and exact operation determine the result.

1. Record the list ID and count again. For each lead, compare the called-since-reset flag with the before value and the documented reset scope.
2. Compare status, counters, callback record and history independently. Mark an unavailable value UNKNOWN; do not infer an unchanged field from an unchanged list total.
3. If any value differs from the approved expectation or a lead is missing, keep the campaign inactive, preserve the before and after evidence, and ask the owner to investigate before any retry.
4. If a future controlled calling test is separately approved, check status, list and campaign activity, local time, DNC and attempt restrictions first. Log the actual attempt and outcome rather than calling eligibility a completed call.

You should seeThe ledger shows which fields were observed, at what time, and which remain unknown.

05 / 05

5. Close the exercise and restore the test state

A reset is not an undo button. Repeating it does not reconstruct the old per-lead flags. If the outcome is unexpected, retain the comparison and ask the owner for the approved recovery procedure; do not improvise a database update.

Leave the campaign inactive until the owner has reviewed the results and any planned cleanup. Record any changes actually made and who owns the next step. For a production list, repeat the impact review with its own approved scope rather than copying the lab decision.