Loading a File That Updates Existing Leads in VICIdial

New operators often assume the VICIdial lead loader only inserts brand-new records. Load a file, get new rows, done. But a common real-world job is different: you have a file that overlaps with data already in the system, and you want those existing people handled sensibly instead of duplicated. The loader has settings for exactly this, and getting them right saves you from a list full of triple-loaded numbers.

The key thing to understand up front: the loader does not do a true row-by-row "update this field on this lead" merge. What it does is detect overlap and then move or skip matching leads based on the rules you pick. Let's walk through the two settings that drive that.

Step one: duplicate checking

Before the loader can act on an existing record, it has to recognize it as a duplicate. That is the job of Duplicate check. You choose the scope: check for duplicates within the same list, across all of a campaign's lists, or system-wide. There are also options that only look at leads loaded within the last 90 days. Without a duplicate check turned on, every row in your file becomes a new Lead, overlap or not.

You can also narrow the check to specific statuses, so a number only counts as a duplicate if its existing record is in one of the statuses you care about. This is how you say "treat it as a duplicate only if we already sold it," for example.

Step two: the status mismatch action

This is the setting that actually updates where an existing lead lives. If a lead in your file duplicates out by phone number but does NOT match the statuses you selected for the duplicate check, the Status Mismatch Action lets you move that already-in-the-database lead into the list you are loading into. So a number you have but never worked can be pulled into your new campaign list automatically.

You get two important choices: move only the most recent occurrence of a duplicated-by-phone lead, or move ALL occurrences. And you can set the scope of the move separately from the duplicate-check scope, so the search for matches and the migration do not have to cover the same range. A moved lead keeps its existing Called status and call history; it lands in the new list as-is rather than starting fresh.

How the loader decides

flowchart TD
  A[Row from file] --> B{Duplicate check on?}
  B -->|No| C[Insert as new lead]
  B -->|Yes| D{Matches existing by phone?}
  D -->|No| C
  D -->|Yes, matches dup statuses| E[Skip, treat as duplicate]
  D -->|Yes, status mismatch| F[Move existing lead to this list]

That bottom branch is the "update" most people are really after: the existing lead is not re-inserted, it is relocated into the list you are loading, carrying its history with it. If you instead want fresh inserts and just want to avoid duplicates, see duplicate checking on load.

A note on what does not get touched

This action ignores the mismatch logic entirely if you are deduping against all statuses, because then there is no mismatch to act on. And remember the loader does no data validation beyond stripping non-digits from phone fields, so the file you load should already be clean. Custom field columns can be mapped in, but they cannot be used as a filter.

For the basics of getting a file in at all, see loading leads into VICIdial, and for the bigger picture start with the VICIdial lists and leads guide.

Want a managed VICIdial box where the fifth-generation loader is ready to go and your server is live in under 40 seconds? See VICIfast pricing.