This week I’m Down Under in Melbourne, Australia, teaching an IPA Design and Implementation course. Since I have servers at my disposal and a little time during labs, I decided to experiment a little with initiating a Process from a handler in conjunction with an inbound ACD call, so that a Work Item alerts on the agent’s queue just after he/she picks up the call. The results are not perfect, but do show great promise and usefulness – I know other folks are creating fairly complicated solutions along the same lines.
I chose to place my functionality into the CustomACDPostAlert handler. That way, I know that the call has already been answered by an agent, and I have the agent’s scoped Queue Name passed in as p_sAgentQueueID. Initiating the process after the call has been answered helps avoid the scenario of sending both a call and a work item to the same agent, but he/she only picks up one of the interactions.
In CustomACDPostAlert, I first strip the “User Queue:” from the value in p_sAgentQueueID, because I want to pass just the user name to IPA:
Next I use the Convert CallID to String tool step to create a unique value for sPADataName, the string variable naming the object to which data passed to IPA will be attached:
I have also used the Unique ID tool step to create sPADataName. The main idea is to have a truly unique string.
The next step is to use a Get Process Properties tool step to, well, get the process properties…
The Input parameter Process Name is a drop-down list of all the processes active in IPA, and the Outputs are the Process ID, Description, and Published Version.
I want to send some data from the handler to the IPA process instance, so I need a Create PA Data tool step, followed by one or more Put PA Data Element tool steps:
In this case, I am going to pass IPA the name of the Agent who was assigned the call, so I can then use a Send Work Item to User action in IPA to route a work item to the same agent who just answered the ACD call.
Note that the Put PA Data Element tool step has an Input parameter named “Element Name”. Normally this parameter would be tied to an element name in a Run Handler action, but because I am initiating the process from a handler it will actually populate a process variable of the same name (e.g. Process.ICUser, in this case).
The last bit, from the handler side, is to use an Initiate Process tool step to send the notification to IPA and pass the data. Make sure to put in error-handling functionality for each of the exit paths…
One item of note – as of SU12, the “Initiator Name” parameter is not working correctly. It is supposed to populate the Process.InitiatingUser variable in IPA, but right now it does not pass a value. The fix is in SU13.
Well, that’s it for today…don’t feel too jealous, since it is winter here in Melbourne. Next I’m off to our office in Sydney to set up our 4.0 classroom environment.