vicidial.org

Hello all

I hope this is the right forum. I searched for similar posts and they were kind of all over the place. Anyway, new cluster is up and running (specs in my footer I hope) and now being tasked with starting customizations.

This first one the higher-ups want done yesterday
Goal: When an inbound call comes in (which is 95%+ of our calls) have the agent screen populate with information about the customer loaded via API.
To start, I just want to get Name, Address, and maybe a custom field or two filled in so I'm pretty sure I can just stick with the agent screen and not necessarily use a script. Proof of concept.

I have seen methods regarding adding lists and using CIDLOOKUP, but unfortunately that won't work in this scenario. There are data we need pulled from third-party sources that can change by the minute regarding our existing customers.

Here are the ways I can currently think to do this, but as I am somewhat new to Vicidial customization (but not PHP nor customizing other systems) I would appreciate any feedback about existing best practices for this, working implementations, or anything to especially avoid doing.

1) Start Call URL to send Phone to a handler script, have that script do the API calls by searching via Phone, and then use the agent api update_fields to fill in the fields on the agent screen. Will this work for custom fields? I may have missed it here https://vicidial.org/docs/AGENT_API.txt but I'm not sure. Also, is a reload necessary after sending data? Like formreload? I assume a form is something different than the main agent screen page.
Most importantly, will this (meaning the Vicidial part of it) work like I'm thinking it will to be able to load that information to the screen?

2) Modify the page directly to pull in the information. This worries me because that page seems to be integrated into a lot of things, but also seems to be the most direct way and avoids a few extra requests.

3) Build it into a script/iframe using the same general process as option 1 but then returning the data to the frame using my own method. I assume I still need a handler to capture the Start Call URL and that it can't be sent directly, and I also assume that the script can't be set to load by default, so if those are true I'm not sure what advantage this would have initially. Eventually it may be useful if a lot more fields need to be loaded that I can't shoehorn into the fields on the main screen.

A few other things I'm unclear about after reading the manuals and forum posts:

• For an inbound call from a caller that has never called this new system before, is a lead automatically created?
• Is a lead actually necessary to update these fields? For example, if I'm not using CIDLOOKUP and therefore no lead is pulled. (Unless it is automatically created as asked above)
• Sometimes it seems like a lead will be tied to multiple customer phone numbers, and I'm unclear why, so would this present problems?

Any guidance, feedback, etc., is very appreciated. Happy to provide more information if needed. Thanks!

Hit me up on Skype and I'll see if I can help you figure this out then we can post back here with some solutions

carpenox wrote:Hit me up on Skype and I'll see if I can help you figure this out then we can post back here with some solutions

Sorry for the delay! Holidays, etc. I appreciate the offer very much and may take a raincheck on it if that's alright.

I actually went ahead with an implementation of option #1 that seems to be working pretty well.

Some notes for anyone that may need this info in the future:

• I was debating Start Call URL vs Enter In-Group URL, thinking that the latter would start the lookup a (tiny) bit sooner. However, Enter In-Group URL does not guarantee that a lead is loaded, and a lead is required to be on the agent screen for update_fields to work.
• If it takes a while for the API call to run, note that update_fields will overwrite anything that an agent may have started to write. I don't mean to say that this is a bug, it makes perfect sense, just something to be aware of. I'm actually dropping the bulk of my response into Comments which I made readonly (could also be disabled, just the color changes) but since the script is updating the field contents, it doesn't prevent update_fields from working it just prevents an agent from entering/modifying the info.
• On the topic of comments, I found out the hard way that there is a 255 character limit (as defined in the DB). I noticed in the vicidial.php code that the normal comment field will enforce this limit, but if multiline comments are enabled it is very possible to input more than this without warning and what is saved will be truncated. I can't find any issue that would be caused by changing to a VARCHAR (1000) etc. Not sure about complications if changed to text or something else. For my purposes, 255 will end up working fine.
• I ended up putting the API proxy on another server to (hopefully) keep open connections lower on the web server. I haven't seen any issue so far, running this process about 20k times per day.
• Not sure why I had trouble finding this explicitly, but --A--user--B-- is the agent ID as needed by update_field. It is listed as a field in the manual, I was just unclear for whatever reason if it was the correct one. Hopefully that saves someone some time in the future.

And to answer some of my own questions:

For an inbound call from a caller that has never called this new system before, is a lead automatically created?

Yes

Is a lead actually necessary to update these fields? For example, if I'm not using CIDLOOKUP and therefore no lead is pulled. (Unless it is automatically created as asked above)

It is indeed necessary for update_fields to work. But, will be created once the agent gets it. Note: the lead does not have to be passed to update_fields, but calling the function for an agent who does not have a lead on screen will cause it to error.

Anyway, with all of that being said, I will eventually be switching to either a Form or a Script once my needs become more complex than what they wanted to see currently. However, adding a new field to the vicidial.php page doesn't actually seem too bad now that I've had time to look through it. I do think it would make it trickier for maintenance though.

So overall, for filling fields that are already on the main page, Option 1 works great.
I would say Option 3 is the next-most-reasonable, especially for a lot of data.
Option 2 could in theory work but is likely not worth the effort, YMMV.

Great post back