We have many different parties we try to integrate that have some sort of status system and their own list of statuses for their system to use and understand.  Each of these third parties has other parties they are working with as well with different list of statuses as well.  With all these lists it is very unlikely to find any two list that match exactly.  Often statuses in the lists will be very similar the only difference could be a word or the order of the words.  Even these slight differences are enough to make matching of statuses in the list a issue.  So who gives in and does the work to make it happen.  In most cases it smaller party or the one seeking the integration.  The remainder of this article is about our specific integration with ServicePower.

In SerivceDesk we have a set number of JobStatus as listed below.  An example could be our status is "Waiting for Parts" which for our system covers the time the part is requested by the tech until it arrives.  

As part of our integration with the ServicePower we try our best to pick from statuses they provide to us and then upload them to based on the guidelines provided by them.  We can even note at this point there is a difference in how the statuses are addressed we call them Statuses and ServicePower has Master Statuses(see complete list further below) and Sub-Statuses.

Here is the list of our statuses and the corresponding ServicePower statuses we have chosen to use for our status upload process.

One of the considerations we have had to make with integrating with ServicePower the list of 38 different sub-statuses they have versus the 7 statuses in ServiceDesk.  I addition to the number of sub-statuses to choose from we also run into many sub-statuses having similar or virtually the same many to each other and having multiples that match the meaning of a single status in ServiceDesk. 

I will note here that for ServicePower the status update has a Master Status and a Sub-status as seen above.  As we can see the master status for all of the ServicePower listed sub-statuses is "ACCEPTED". The problem is not with the ServicePower system getting or even accepting the statuses we upload but is on the other side of the coin.  How does the client get the statuses we upload.


To unpack the meaning of this we are going to use the ServiceDesk status "Waiting for Parts" .  In the list above you can see ServicePower sub-status "PARTS ORDERED".  Which if  you recall our list of ServiceDesk statuses to ServicePower sub-statuses "PARTS ORDERED" is uploaded to ServicePower for ServiceDesk status "Waiting for Parts".  I believe you and I logically see connection between the ServiceDesk status "Waiting for Parts" and the ServicePower sub-status "PARTS ORDERED".   The actual status we upload results in the Master Status being set to "ACCEPTED" and the Sub-status being set to "PARTS ORDERED" as per our example above.  However, was that the only option, for us to use?  No, in fact there are 6 options we could choose from as listed here.
Why does it matter which sub-status we choose?  If ServicePower is able to receive it and process it as an acceptable upload for their status system isn't that all ServiceDesk users need to be concerned with.  It could be true except ServiceDesk and ServicePower are not the only parties in this integration.  We also have the manufacturers and warranty companies that are clients of ServicePower.

Each ServicePower client (e.g., LG, Warrantech, Electrolux, GE) creates its own list of call statuses that can be set by changes uploaded from third parties like ServiceDesk or manually changed by the Repair Service Provider through the ServicePower Website.  From the understanding we have been provided the client can choose not only which statuses are displayed in the call status list from the 38 listed ServicePower sub-statuses but they can create their own unique/custom statuses(ex. Electrolux has a status "TRAVELING" which is not on of the 38 ServicePower statuses).   This allows the client to be able to set call status so they can easily be recognized by their systems similar to how we can relate our ServiceDesk system statuses to ServicePower the client can relate ServicePower statuses to theirs.
Going back to the "Waiting for Parts" status example we know SerivceDesk is choosing "PARTS ORDERED" but we can see that GE has chosen "WAITING ON PARTS".  What happens when a sub-status is used that doesn't match one of the selected call statuses by the client.  In fact the sub-status uploaded is simply dropped from the narrative on the clients end and they will only see the master status noted which as we prior discussed is "ACCEPTED" and the call status list will reflect that as well and I believe will actually display with the "select" option being displayed instead of a specific call status.  So what can be done to reduce the number of status uploads resulting in only the master status being uploaded and the call status being reset to the "select" option.

There are two parts to handling the call status relate to the sub-status from the client's side to reduce the undesired results of above.  They can choose to add all of the sub-statuses that could be used to represent the status in their system to their call status list but this could clutter the list and make it unpleasant to navigate.  The client only choosing to put in a single option like "Waiting for Parts" like GE did makes sense. So the second thing the clients can do is referred to as mapping the sub-status. In this process they choose which of the 38 ServicePower sub-statuses they want to be equated to the Call Status options they have chosen to list.  Staying with the example of ServiceDesk using the "PARTS ORDERED" as a sub-status upload GE would need to map their Call Status option "WAITING ON PARTS" to the ServicePower sub-status of "PARTS ORDERED".  Now they could do this to the other 6 related sub-statuses we discussed above and then no matter which option a third party like ServiceDesk choose to upload it would be processed and seen by the client as "WAITING ON PARTS".  This would also be true for custom options like Electrolux's Call Status "TRAVELING".  I am assuming a logical ServicePower sub-status to be mapped to "TRAVELING"  would be "EN ROUTE" but if that was not mapped that way by the client when we uploaded the "EN ROUTE" sub-status when the status in ServiceDesk becomes "Dispatched to Tech" all the client would see is the master status as "ACCEPTED".