You might say we are continuing the SDM-2 imperative.  Ver. 2.0.0 of Mobile offloaded all the regular/behind-the-scenes data updates to a separate invisible application, so as to prevent the interface in Mobile itself from ever again going into lock mode, pending completion of those particular updates.  However, we left a few on-demand data movements live, meaning that, for those, interface lockups might still potentially occur.

One of those was the request for a call-ahead RoboCall, which we just barely modernized (see two releases back) to make it asynchronous (i.e., the interface will continue interacting with you, even while the request is pending).  At the time, we neglected to consider a companion request, which is the request to check on the status of a prior-issued RoboCall request (this request is initiated by right-clicking on the Call Ahead button).

So, that oversight is what we've now addressed.  The Check-On-RoboCall function is now also asynchronous.  We also dealt with a situation that had been discovered where the system locked, when a user requested the check while the original request was still in-process.

Recently it was brought to our attention, since SDM-2 began, the sequence of these routes was not always correct.  It was an oversight.  Based on new ways we are structuring data in SDM-2, the code that does this exporting needed to be changed.  We'd overlooked it, and that oversight is addressed in this release.

This release, incidentally, also addressed some other miscellaneous bugs, including one that preceded SDM-2 (for some users, the system would sometimes lock upon accepting a disclaimer signature).  It addresses others as well.

In the last-prior entry (see just below) we gleefully announced the new share-Rolodex-with-Techs feature.  While so doing, we acknowledged there might be some managers who don't want to share such info, and, if this proved true, we'd need to provide an option to refrain.  We hoped the added programming investment would not be required.  Well, it was.  

Indeed, not only did a certain user (yes, that was you Michael Basich) want to refrain from sharing standard Rolodex info with his techs, he further had the gall to ask us to create a special Rolodex just for techs.  

Hmmph.  How do you like that?  

Okay, so we did it.  

Actually, I latched upon a method, for the provision, that made the programming reasonably lightweight.  

Here's how it works.  

If you don't want your techs getting the full and standard data set from your within-SD Rolodex, you may simply create a document that contains the text you want them to have.  It should be a simple text document, and must be saved to the x:\sd\netdata folder (where the "x:" in the reference is stand-in for whatever is your actual server drive).  The file must be named Rolodex.txt.  

It's as simple as the above.  When SD-MobileLink sees that file present, it will upload its contents for your techs, as opposed to contents from your standard within-SD Rolodex.  Thus, you may simultaneously avoid sharing your standard Rolodex, plus provide your techs with whatever you may uniquely want for them.  

As it happens, the next release of ServiceDesk will have a shortcut to make this file-creation very easy.  Specifically, there will be a new button within its Rolodex interface:

The purpose of this button is to facilitate creating a simple text file that's a more-or-less complete textual summary of your within-SD Rolodex contents (in fact, it runs the same process as does SD-MobileLink when pulling from your standard Rolodex to upload to the techs).  Anyway, our thinking is perhaps you'd like to share most or your Rolodex data with the techs, while omitting just a few sensitive elements.  If so, we suggest you use this button to create a standard/full export, then edit as wanted to remove what you don't want your techs to see.

BTW, we have also created provision within MobileLink itself by which you may direct-verify whether it's going to pull from the standard/full Rolodex within SD, versus pulling from your specially-created Rolodex.txt file.  It's done via the ToolTip that will appear when you float your mousepointer over the "Other" upload button:

Above is how the ToolTip will look normally, when MobileLink intends to pull Rolodex info direct from your within-SD Rolodex (emphasis here added to guide your eye)

Now above is how it will look when MobileLink sees (and therefore is instead prepped to upload) contents of a specially-created file (again, emphasis added).

‍