SB-DispatchLink 4.5.34 Update 11/22/12

Multiple New Functions for Auto-Integration with ServiceBench:

Yes, this venue is typically used to describe ServiceDesk-specific improvements, as opposed to those made in complimentary apps.  However, since so many of you also use the SB-DispatchLink utility (SBDL), and since we've made rather significant improvements there, this seems like a suitable place to announce. 

Only some three months ago we added two new elements of information that may potentially be auto-uploaded to ServiceBench, via SBDL (that time we announced via email to SBDL users): ServiceDesk JobRecord HistoryNotes and direct/separate close-transactions for completed jobs:

Since then, we've been asked for three more additions to our SB-uploads roster: (1) direct notice when job is re-scheduled; (2) direct/live-informing when a tech arrives and/or departs from each job; and (3) direct notice of each event when a message is left for a customer (or similar significant to job-progress event). 

It appears, evidently, NEW is campaigning hard (and perhaps other entities are as well) to maintain a live and real grasp of how each job is progressing. 

Regardless, we have added each of these new transaction functionalities into SBDL (though not all show as discrete options within the SBDL interface): 

Here is a specific explanation for each of these options, as now setup:

Looking in the first of the checkboxes as now configured, you'll see it reads similarly (though not quite the same) as compared to what was added in that position three months back:

From Three Months AgoNew/Current

Formerly, if you had the above-option checked, JobRecord HistoryNotes would be added with each sub-status upload.  Specifically, they'd be added as a single (and typically large) block of text, within a Comment section that was directly appurtenant to the sub-status update itself.  In other words, it was simply part of the status update (a mere comment appended to the same), and was not a transactional-upload event in and of itself.  

We discovered, with such notes provided in this fashion, they were not reaching the eyes of persons interested in seeing such details (such as NEW personnel).  Upon also learning some users were being pressed to log into their ServiceBench online interfaces to manually enter notes each time they talked to (or left a message with, etc.) a customer, we decided we needed to upload JobRecord history notes (and with each note as a separate item) directly into the same place users were being asked to do it manually. 

So, if you now have the first sub-option checked (as above illustrated); it will invoke a rather different underlying action, as compared to before.  Instead of uploading the entire JobRecord historical narrative as a mere add-on comment with the status upload, it will instead upload each discrete entry, as added to the applicable JobRecord history since the last prior update.  It will upload each such new item individually, and using a dedicated ServiceBench Add-Comments transaction as made for the purpose.  In result, these notes should now be placed precisely where needed for appropriate visibility by underlying ServiceBench clients (e.g., NEW). 

Now we focus on a checkbox option that is indeed totally new, with this morning's release:

As its wording suggests, this one will upload to ServiceBench notice whenever you change an appointment (or make a new one) on an applicable job (i.e., one that was dispatched to you by ServiceBench).  Much like that above-described "Comment" upload, it's being done via a dedicated SB transaction we'd not formerly been employing. 

Though the third status/sub-option checkbox is not new with this release, we'll nevertheless provide some contextual explication (in particular, for any who may have missed the explanatory email from three months ago):

Normally, SB-dispatched jobs are put to bed ("closed") via the claim-filing process, as done from within ServiceDesk.  The problem is this sometimes does not occur in the intended fashion.  In particular, we've learned for some servicers it's quite common to have a job dispatched by Lowes, with a claim being made against Whirlpool.  This fails to close the Lowes job.  This option (as added three months ago) is designed to assure closing occurs, regardless.  Indeed, it should assure closing after a JobRecord is moved to the archive, whether a claim was involved in any manner.  

You may notice there are no checkbox options for turning on or off what we described, early in this post, as another addition to the arsenal of status-upload related functions: direct/live-informing when a tech arrives and/or departs from each job.  There is no sub-checkbox for this, because this function is not sub-optional.  If you have the main/general "Uploading of Job Status" frame checked, general status changes will be uploaded, along with when the sub-status changes because a tech has arrived or departed from a job.  We simply do not contemplate anyone will want to upload status generally, and not want to do the arrive/depart sub-status change as well. 

Of course, it's also true that if you do not have your techs using SD-Mobile (or using it but not doing it live as per design intent) there will not be a basis to do the live reporting of their arrivals and departures.  Uploading of those events depends on the system itself having due notice. 

Please be aware, BTW, these new functions, that are optional, default as unchecked.  If you want the functions to occur, you need to check the applicable boxes.