Starting an IPA Process from a Handler

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.




George Ganahl

George Ganahl

I joined Interactive Intelligence in March 1999 with a background in technology and data networking. My first stop was in education, where I taught our partners and customers how to install, configure and administer our IP business communications software system. Several years on the development side of the house followed, where I managed the install, build and documentation teams; built hotfixes; managed our software platform; and maintained the big picture for development. After a return to education, I managed and maintained the worldwide set of classroom equipment and continued to train partners and customers. These days I’m concentrating on internal training for the services teams, including training for our new multitenant cloud platform, PureCloud℠, which delivers customer engagement, and unified communications and collaboration services.