Should I migrate from CALL to IMS?

[Bradley Ross]

ServiceNow has a "Service Desk Call" application plugin and an "Interaction Management System" application plugin. We have been using the Call application for a while. It works great to document the information about a call before we know whether it will be an incident or a service request. 

We're implementing the Walk-Up Experience and noticed that it wants to create Interaction (IMS) records. Are interaction records intended to replace call records? Or should each call also create an interaction record behind the scenes? Should each Connect Support Chat message also create an interaction record behind the scenes?

The documentation for Interactions is still pretty slim. https://docs.servicenow.com/bundle/newyork-servicenow-platform/page/administer/interaction/concept/i...

[PierreDumoulin]

Agreed, Bradley. We are in the midst of doing exactly that. We consider moving to the interaction as a stepping stone to using agent workspace, which we should get to deploy for our service desk in the coming weeks / couple of months. Our developers have worked out scripts to completely migrate call data to interaction and also update the relevant references from requests or incidents. It will be as if the call table had never been used. Once the data's migrated to the interaction table, we may disable the call table or delete its data entirely as to not cause any confusion, or give the impression to anyone still running reports off of that table that it's still being used.

[pooja V1]

@PierreDumoulin How is data manually migrated from call to iteration record?

[PierreDumoulin]

Hey Pooja, our developers have basically written a script to handle the copy. The two tables are technically quite similar so there wasn't too much equivalency mapping involved. Also, since the interaction table is currently not getting any traffic, we've been looking at copying call data for closed incidents or requests ahead of the implementation to cut down on deployment time, since this could technically constitute a no impact pre-implementation step, leaving little data corrections to be done live off hours when the implementation does occur. We are really trying to "rewrite history" and make it look like the interaction table was always being used by migrating the entire history of calls, otherwise, you'd need to consult calls for records that occurred before the migration and interactions for the rest. The migration to the interaction table is still going to have an impact on reporting, but at least everything will be in the same place and if people's call-centric reports no longer show any data, at least they really only need to skip to the new table and reuse the same logic for filtering and displaying data. May be a good idea to spot reports that touch on the call table and send the owners a notification that you're planning to make the change. Sometimes the reports aren't even used anymore, but, for the ones that do, the users will appreciate the heads up. Hope this helps!

[JeremyHoffman]

This is enlightening! We are just underway with the project to migrate from Service Desk Call to the Interactions Management module. I worked with the stakeholders from the SD to understand the requirements for the interaction record and as mentioned above there are a lot of similarities. There is one glaring difference and that is the Interaction table does not have a Description field, which is a head scratcher for me. @PierreDumoulin did you use the Description field in the CALL record, and if so what field are you mapping it to within the Interactions table? A custom Description field?

Migrating data from the new_call table to the interaction table is something I will need to bring up with the stakeholders to see if they see the value in taking this on. I definitely do.

[PierreDumoulin]

Hey Jeremy,

yes indeed, we've had to accommodate that custom field given the history we had with it in the call table days. I figured we would revisit this when looking forward to migrating to a completely agent workspace based environment in the near future. However, don't just let me encourage you to go there, lobby for the out of the box configuration and take the time to evaluate how SN is supposed to meet this need by design first. Cheers!