update_lead no update on mult_alt_phones

[lmoreira]

Hi Guys,

VICIDial Custer, using VERSION: 2.14-664a BUILD: 180310-2321

I'm using update_lead API to import mailing. Logic is: If it exists update the led, else add as new lead.
When updating the lead, no changes on lead's alt extended phones. Only new leads have extended phones included.

Is it possible to update extended phones using update_lead API?

[mflorell]

Updating of existing vicidial_list_alt_phones is not currently an option within the non-agent API

[lmoreira]

But, can it be in future? Too hard?

[mflorell]

Anything is possible given enough time and/or money

It is much more complex than simply adding them, you have to add options for replace-all, only-modify-existing, only-add, only-remove, etc... as well as updating multiple entries for each lead being much more complex to program.

It's not a current feature because hardly anyone uses extended alt number dialing anymore. All of our clients that had been using it moved to MULTI_LEAD auto-alt dialing many years ago.

[lmoreira]

I'm considering change operation to MULTI-LEAD for auto-alt dialing as you suggested. But, I have some concerns and doubt. Hope you could advice me about it.

1. One lead will be create for each phone number, and they'll be linked by vendor_code.
One customer usually load 20k leads (1-5 phones on each) every day. That is 100k new rows on vicidial_list table. This table will grow fast and performance could be degraded soon.

2. I need to keep 3yrs of history of recordings on system (at least info, recording file will be moved after 1yr) on vicidial_list to maintain call history and reports. That should be a problem soon.

Any advice?

Thanks!

[mflorell]

If you archive leads and logs frequently, you can maintain that level of coverage. We have clients that place up to 2 million calls a day on a single cluster, and we still have recordings from them from 3 years ago on the archive server. It's all a matter of the right hardware and configurations.