Before we dig too deep into Add-Ins for the Interaction Client, it would be useful to cover the functionality that Add-Ins expose. Leave a comment and let me know which of these you’d like me to explore first in a future post. Each topic is followed by a list of relevant classes or interfaces, to help if you want to explore on your own.
- Tracing (ITraceContext)
- Write messages out to the InteractionClient log file for post-mortem debugging.
- Desktop Alerts, or “toast windows” (INotificationService)
- Display a custom message in an alert window
- Making Calls (ICallService)
- Create a new outbound call interaction
- Watch* an interaction (IInteractionService, IWatchedInteraction)
- Example: make a call using ICallService and then watch the resulting interaction for updates, or set attributes, etc.
- Watch* the My Interactions queue (QueueMonitor, IQueueService, IQueue, IInteraction)
- Get notified about all the interactions on the current user’s “My Interactions” queue.
- Implement a custom screen pop (ScreenPop, IScreenPop, IScreenPopService)
- When configured in Interaction Administrator (and/or Interaction Attendant) this custom code will be loaded and executed at just the right moment.
- Add a custom tab (“window”) to the client UI (AddInWindow, IWindow, IWindowManager)
* “Watching” something means that you can query information about the item and be notified about events occurring for that item.
I also wanted to go over a few “Add-In Best Practices.” So since I have to have a heading for everything…
Add-In Best Practices
Use the built-in helper classes if at all possible.
The Add-In API was designed to afford a great deal of flexibility. The base interface, IAddIn, is the entry point to the rest of the supported Add-In functionality. But for many common scenarios, it can be annoying to set everything up just so you can start working on the parts you care about. For that reason, we’ve focused on a few common scenarios and introduced abstract base classes that help take away the “goo” you have to write and let you focus on the tasks you want to accomplish. At the time of this writing, these include AddInWindow, QueueMonitor, and ScreenPop. (With an honorable mention to NotificationServiceUtility which provides handy default values when using the INotificationService interface.)
Be mindful of the “UI” thread
Windows applications that show a user interface follow a simple (yet seemingly difficult) pattern: only access controls from the same thread they were created on. (Get more information about that here.) Typically (though not exclusively) there is only one thread in an application that creates controls. The Interaction Client is a typical application in this regard. Add-Ins are purposefully instantiated on the “UI” thread to provide an opportunity to capture the SynchronizationContext. If you’re doing processor-, network-, or disk-intensive operations you should capture the original SynchronizationContext and then delegate those expensive operations to a background thread using the .NET Framework’s built-in thread pool, using the captured SynchronizationContext to marshal execution back to the UI thread when finished, if necessary.
The danger is that your custom Add-In can have negative side effects on the start-up time of the Interaction Client, or worse, it could hang or crash depending on what your code is doing.
Beware of Modal Dialogs
An application like the Interaction Client has to be careful in it’s design. If a modal dialog is shown above the main interface, it can make it impossible (or annoying, or difficult) to pick up the call or interaction without first closing the dialog. This can involve lost work, etc, and should be avoided. If you display a custom pop-up window with your Add-In, work hard to make it modeless. (Modeless means that you can interact with other windows in the application without closing the primary one.) This takes more effort in development, but it is well worth it to end users.
That’s it for best practices for now, I’ll be sure to point out more as we go along. Remember to leave a comment with what you’d like to see covered next!
Cheers.

Thanks for the post, it’s all good information. I’d like to see more on custom tabs and screen pops.
Thanks for the info. Where can I find documentation on the Add-In? I’m excited to see more regarding it, but this blog seems to be coming slowly.
@Fraser
You can find documentation on the Interaction Client Add-In API under the IC 3.0 documentation library’s Technical Reference section. The specific topic is called “Interaction Client Programmable Add-in”
And I apologize about the speed of blog posts, we are all working hard to release IC 4.0 so it has been difficult to break away and take the time to post more. Hopefully the pace will increase in the future.
Thanks for your help! We have been developing integrations for a while now and are excited to build addins for the Client. This will help make a more powerful product for our customers.
I would love to see a post about “Implement a custom screen pop”. The built in methods of DDE and Web are not enough and I have many customers asking about other ways to do it.
I would like to see how to create a custom tabbed window to the client. Is there any documentation on how to accomplish this?