Daily Reset Limit explained

Scheduled resets are powerful, and that is exactly why they can go wrong. Set too many reset times, or let a few people each add their own, and a list can recall itself far more often than anyone intended, dialing the same Lead over and over. The Daily Reset Limit is the guardrail against that.

It sits on the list modification screen alongside the other reset controls. For the full picture of how lists feed a Campaign, start with the lists and leads guide.

What the limit counts

The Daily Reset Limit caps the number of times a list may be reset in a single day. The count includes scheduled Reset Times and resets done by hand together, so if you set the limit to 3, the list will refuse a fourth reset that day no matter where it comes from. The default is -1, which means disabled, so by default there is no cap at all.

On the same screen you will see a Resets Today figure that shows the running total for the current day. That number is what the limit checks against. When Resets Today reaches the limit you set, further resets simply stop happening until the counter rolls over. It is a quiet ceiling rather than a hard error, which is exactly what you want for a background safety control.

The day boundary matters. The Resets Today tally is measured from the end-of-day time set on your timeclock, not from midnight. So if your end-of-day is 6 PM, the counter rolls over at 6 PM, and resets after that count toward the next day's allowance.

Who can change it

This field is locked to level 9 administrators. That is on purpose: the limit is meant to protect against well-meaning campaign staff who keep adding reset times, so the people it constrains should not be able to raise it themselves. If a floor manager wants more resets, an admin has to sign off. It is a small governance feature, but on a busy floor with several people editing lists, it is the difference between a controlled dial cadence and a list that quietly recalls itself a dozen times a day.

How the cap blocks a reset

stateDiagram-v2
  [*] --> Idle
  Idle --> ResetRequested: scheduled or manual
  ResetRequested --> Allowed: count below limit
  ResetRequested --> Blocked: count at limit
  Allowed --> Idle: count plus one
  Blocked --> Idle: no reset
  Idle --> [*]: end of day resets count

Every reset request checks the running count first. Below the limit, the reset goes through and the count ticks up. At the limit, the request is quietly refused and the list stays as it was, which keeps stale records out of the Hopper until the next day.

A sensible limit protects your lead quality and your compliance posture. Over-resetting drives up contact frequency, which is exactly the behavior that gets call centers in trouble, so a cap of two or three on busy lists is a reasonable default. To understand what a list holds before you cap its resets, read what is a VICIdial list.

Want admin-level controls like reset caps configured on a hardened dialer from the start? See our pricing and launch a managed VICIdial server in under 40 seconds.