Callbacks Bulk Move

[dspaan]

So i spent all morning delving into and documenting which various things there are to know about callbacks. I got triggered by a supervisor who said that there were callbacks visible under 'campaign>View callback holds for this campaign' which were not getting dialed. Investigation turned out they had made new callback statuses but didn't add them as a dialable status in the campaign so they were not getting called. Despite that some of them had a final status in the vicidial list because they had been called manually.

So this had left a bunch of callbacks in the callbacks table whith live status but where the lead itself had a non-dialable status.

So what i remember from the past is that you could click one of these links at the bottom of the page:

Remove LIVE Callbacks older than one month for this campaign
Remove LIVE Callbacks older than one week for this campaign

And clicking that would delete them from the callbacks table or set them to inactive, i'm not sure.

I'm using SVN3199 and when i click either of the links now it takes me to the callbacks bulk move page and pre-selects the campaign i came from along with the related lists, related usersgroups and related users:



Now when i only want to purge the callbacks that already have a non-callback status in the vicidial list i would uncheck 'Purge uncalled records' and leave 'Purge called records' checked. Since i don't want to move the callbacks to a new list i leave the 'List ID' set to DO NOT ALTER LIST ID.

When i do this and click the TRANSFER TO button nothing happens. The screen flashes and all my selections are undone, no callbacks have been cleaned from the callbacks table and no confirmation screen on the selection i've made (is what i would expect).

I tried with error console but no errors. Nothing in the apache error log. I searched the forum and mantis but nothing. Did i find a new bug?
I also checked the latest version of the manager manual but this is really nothing more then the explanations you can find by using the help icons:

Callbacks Bulk Move
This is complex utility that is used to move callbacks meeting a set of selected criteria to a new list and or a new lead status. It can also purge called records from the callbacks table.

Campaigns with callbacks -The current list of all campaigns having at least one callback - select one
or more to move callbacks from these campaigns in bulk to new lists and or assign new statuses. This
will combine with other selected criteria to make a final list of callbacks to move.

Lists with callbacks -All list IDs having at least one callback - select one or more to move callbacks
from these lists in bulk to new lists and or assign new statuses. This will combine with other selected
criteria to make a final list of callbacks to move.

User groups with callbacks -The current list of all user groups having at least one callback - select one
or more to move callbacks from these user groups to new lists and or assign new statuses. This will
combine with other selected criteria to make a final list of callbacks to move.

Agents with callbacks -The current list of all agents having at least one callback - select one or more
to move callbacks from these agents to new lists and or assign new statuses. This will combine with
other selected criteria to make a final list of callbacks to move.

Purge called records -If this box is checked, before the leads meeting the selected criteria are moved,
the callbacks table will purge itself of all inactive records in the table. This includes records that have a
status of INACTIVE, OR any record still in the callback table that is LIVE but whose status in the
vicidial_list table is NOT listed as a callback, i.e. it has been called, lead has called in, lead dispo has
been modified. The page will notify you how many leads will be purged before you confirm that you
would like to proceed.

Purge uncalled records - If this box is checked, before the leads meeting the selected criteria are
moved, the callbacks table will purge itself of all uncalled records in the table. This includes records
that have a status of ACTIVE, OR any record still in the callback table that is LIVE but whose status in
the vicidial_list table is still listed as a callback, i.e. it has not been called, has not called in, and has not
had the lead dispo modified. The page will notify you how many leads will be purged before you
confirm that you would like to proceed.

Live and uncalled for over XX days -Selecting a date range from this drop down menu will filter out
any callback where the scheduled callback time is past the selected number of days from the current
date and time. This will combine with other selected criteria to make a final list of callbacks to move.

Transfer to List ID -The list ID to which all callbacks will be moved. The move will occur on the
records in vicidial_list table - the matching records in vicidial_callbacks will be removed.
New Status -The new vicidial_list status the selected callbacks will be updated to. This affects the
vicidial_list table ONLY.

Also the option 'Revert to last status' at the right bottom isn't documented anywhere.

Also i already have this active in crontab:

Code: Select all

# cleanup of the scheduled callback records
25 0 * * * /usr/share/astguiclient/AST_DB_dead_cb_purge.pl --purge-non-cb --quiet
# removal of duplicate scheduled callback records
35 0 * * * /usr/share/astguiclient/AST_DB_dead_cb_purge.pl --purge-non-cb --remove-dup-cb --quiet


help info:
[--purge-non-cb] = delete callback records of leads with no CBHOLD/CALLBK status
[--remove-dup-cb] = remove older duplicate callbacks for same user and lead_id

Here is an example of what i have in my callbacks table:



So i would say there are plenty leads meeting my criteria for the bulk move tool.

[jjohnson78]

For the callbacks bulk move page, you have to select what is to be done with the statuses, which is the "New Status / Revert to last status" option. It's mandatory, and going by your screenshot you don't seem to have selected anything there. Once you do that you should proceed to the confirmation screen when you click "TRANSFER TO" which will tell you how many leads are going to be affected.

"Revert to last status" means it will default to "NEW" as the status to update the lead to, but will try to find the last non-callback status the lead was dispositioned as from the agent log table, then the outbound log table (in case there is a more recent autodial record there).

Regarding the callbacks cron job, callbacks are purged if the status is INACTIVE or the lead is in the vicidial_list table with a non-callback status (i.e. one where the "SCHEDULED CALLBACK" attribute is "N", not just CALLBK or CBHOLD) OR the lead is no longer in the vicidial_list table at all. Since none of the ones in your screenshot are INACTIVE, it should be that the corresponding record for that lead_id in vicidial_list is still showing a status that is marked as a scheduled callback.

[dspaan]

Hi Joe,

But these links suggest you can remove callbacks from the callbacks table which should not be there:
Remove LIVE Callbacks older than one month for this campaign
Remove LIVE Callbacks older than one week for this campaign

Which status should i fill out in the 'New status' field?

In my case i have some callbacks that are in the callbacks table that are not supposed to be there. For example:







As you can see this lead stays in the callbacks table and the status in vicidial_list is CND but that is not a callback status but is a completed status. Should this not be cleaned up by the cron job?

Another question, when does a callback get status INACTIVE? Which process does this? Everytime i look in the callbacks table i don't see them, they are all in the archive tables (where they should be i suppose).

[jjohnson78]

"LIVE" means the callback reached it's scheduled callback time, so it is entirely possible to have callbacks marked as LIVE that are older than a week or a month. It means that no one ever got around to calling them.

Which status should i fill out in the 'New status' field? - Whatever you want. If you want the reverted callbacks dialable, make it a dialable status. Don't want them dialable? Use a status that you don't plan to dial or even one that isn't defined anywhere in your cluster.

Regarding your CND lead(s), your screenshot shows CND is a campaign status. Check your other campaigns if they have also have CND defined, and if it is a callback status in another campaign. That would prevent it from being handled.

Another question, when does a callback get status INACTIVE? - When an agent dials and dispositions it. Specifically, this occurs in the vdc_db_query.php file.

[dspaan]

Hi Joe,

Regarding your CND lead(s), your screenshot shows CND is a campaign status. Check your other campaigns if they have also have CND defined, and if it is a callback status in another campaign. That would prevent it from being handled.

I checked this but the CND status indeed exists in other campaigns but has the same properties. Why does having a status with the same properties in multiple campaigns block the removal of such a status from the callbacks table? That would mean every campaign would need specific statuses for callbacks? By the way when i check the callbacks overview for that same campaign again now it's gone from the list and has been moved to the callbacks archive table. No idea what caused it to be archived eventually.

Now another question. This is another campaign:



I want to move all 168 callbacks to another list. These are live and active callbacks, so these are also callbacks that still have a date in the future.
I do NOT want to purge them from the callbacks table, they just have to be moved to another list. Is that possible? If i make the selection above i only get 13 leads that can be moved and not 168:

[jjohnson78]

"I checked this but the CND status indeed exists in other campaigns but has the same properties. Why does having a status with the same properties in multiple campaigns block the removal of such a status from the callbacks table?"

It doesn't, necessarily. I wrote "Check your other campaigns if they have also have CND defined, and if it is a callback status in another campaign". Because, if the same status is defined in multiple campaigns but has "scheduled callback" set to "Y" in any of them, it doesn't matter how many other campaigns have it set to "N", it's considered a callback status and will not be archived.

Regarding the second question, what is happening is you're selecting multiple criteria and the bulks callback feature will only move things that meet every criteria you've selected. So it doesn't matter if the campaign says 168 callbacks, if you select one campaign and then also restrict it to certain lists and certain users AND certain user groups, it's only going to count the callbacks that meet all the criteria. Also, you didn't specify an action for purging records (i.e. the two checkboxes), so the callbacks move is only going to look at LIVE records.

You may want to look at the "Advanced Lead Management Tools" in the "Admin Utilities" menu for this particular issue instead. The first section is devoted to moving leads, which is probably what you should be using anyway in this particular case because it sounds as though you're just looking to move CBHOLDs to a different list, not actually purge them from the callbacks queue, which is a big part what the "Callbacks bulk move" page was designed for.