Good day, I am currently attempting to setup a system whereby my IVR will allow customers to enter account numbers and then screen pop for agents. I set the data entry from the caller to an attribute and can cause the screen pop to work perfectly on live calls. However, when a customer chooses a callback, the data from my custom attribute is lost. I did some researching and discovered attribute "Eic_AttrCallbackCopyAttributes" which, from what I can read, is supposed to copy attributes from call to callback object. However, it just plain doesn't work. What am I doing wrong? We are on premise CIC 2016R4. Thanks, Cody

Additionally, I have now noted that when I perform my callback function in-queue instead of moving callbacks to a different queue, I can get it to work...

Believe the issue you are running into is that once you remove the call from it's original queue, it is no longer considered an ACD interaction. (Thus the attributes won't copy over) You'll likely need to create a custom handler if you require moving the call out of the original ACD queue. We had to do something very similar here in order to copy the attributes over to the callback request. We wanted to prompt the caller for some additional information before generating the callback request. In order to do that we had to remove the call from the original queue. You can probably debug the IntAttRequestCallback handler to get a better idea of what's going on. Hope this helps. Thanks, Shane

Thanks for your reply Shane. I was beginning to wonder if that may be the case... do you have any tips/suggestions as far as handlers to accomplish this? I don't have much experience in that venue so I might be stuck if I cannot do this in Att. Cody

I ran into the same thing. If you use the call back request from attendant before the call is in an ACD queue, no attributes are copied. There is no customization point to allow us to change this behavior. I updated the IntATTRequestCallback to add the steps to copy the attributes when the call is not in an ACD queue. I used the steps that copied while in ACD as a model. YMMV. Tim

Not only is there no customization point, but ININ/Genesys declined to add one when I asked. :(

Unfortunately you may have no choice but to change your approach to the callbacks to try and accomplish what you need in Attendant. Otherwise you're probably going to have to debug the callback handler and create your own customization point in the base callback handler. Like others have said we had to do the same thing and we also requested\suggested a customization point be added. Our team still believes the product could greatly benefit from additional logic for handling callbacks as well as additional customization points within handlers. The IVR callback feature isn't extremely flexible out of the box unfortunately. Thanks, Shane

I wrote a subroutine to do this which is called by CustomSubroutineInitiatorRouter. I create the callback and then set some attributes on the new Interaction. I set the attribute named Eic_CallBackCreatedId to the Interaction ID of the callback Interaction, I then create a second attribute called Eic_CallbackOrginalCallId which is the call ID of the original interaction. I grab all of the attributes I want to copy form the source call ID then run the logic through Update Data Pair Values and then set the attributes on the callback. It was a long time ago when I built this handler and it never got out of testing as my customer decided to hold off on callbacks. I believe I "borrowed" all of this code from the Interaction Attendant handler IntAttRequestCallback. If you look the reason the attributes don't copy when called from attendant is because there is a check right before the copy to see if it is an ACD interaction and only if there is an ACD interaction will they copy. Furthermore you can't specify anything other than the basic ACD related attributes. At the end of the day if you want to do something like this you might need to do this in handlers.

Hello all, Sorry to resurrect a zombie thread, but my centre has been looking at this again, and I was wondering if anyone would be willing to share some details of how they edited the core callback handler to accomplish this or how they set things up with a subroutine? Cheers, Cody

There are a number of possible approaches to this (since there isn't a nice clean customization point like we'd really like to see). I've taken a couple of different approaches depending on what I wanted to accomplish. As mentioned before, the base handler for Attendant callbacks can be modified to tweak the list of attributes that are copied for in queue callback requests, or to copy specific attributes for non-ACD callback requests (since they aren't copied by default in this case). There is a customization point prior to the creation of the callback object that can also be used to modify the data that is used to populate the notes field in the callback request object. Another possibility is to grab the callback request as it is sent into queue (somewhere like CustomAcdInitiateProcessing), lookup the interaction ID of the originating call by attribute, then copy attributes from the call to the callback request before the inbound call deallocates from the system. Also, here's a blog post I wrote a while ago that doesn't specifically address copying attributes from one interaction to another, but talks about how to link the inbound call with the callback request and also with the outbound call that is placed back to the originating party: http://cpi.solutions/2017/enhanced-callback-reporting-in-genesys-pureconnectcic/