ServiceDesk 4.7.87 Update 08/03/14

Though it's a rare situation, a very few clients have wanted to divide their territories into more than 30 zones (30 is the max quantity of divisions that has prior been accommodated for).  With this release, you can now make up to 60 zones.

The change involves more than just restructuring elements within ServiceDesk.  Because they are involved in zone/availability management with third parties, each of the DispatchLink utilities (SBDL, SPDL and LGDL) also had to be updated with ability to manage the increased quantity of zones.  So did the SD-CyberLink utility, for its uploading of availability information for your own customer's online scheduling.  Updates have been posted on all of these, in addition to the update on ServiceDesk itself.  It's important, if you choose now to setup with more than 30 zones, that -- in addition to updating ServiceDesk -- you also update any such utility you may be running.

As an incidental byproduct of updating all these utilities, each has also been updated with internal wherewithal to inform the ServiceDesk's new "Command View" of its running state (a feature announced in the last-preceding-update entry). 

A couple of releases back, we added an option in SB-DispatchLink (SBDL) that changes how holdbacks are calculated.  For clarity, holdbacks refer to the practice of withholding portions of your availability from exposure to the third-parties these utilities link to.  The general idea is that, typically, you do not want third-party-administrators and/or OEM-warranty clients to hog all your available capacity, and thereby leave you with no room left for your own more profitable COD work.  So, the DispatchLink utilities have long had a couple of parameters you can set to "hold-back" a percentage or quantity of slots within each scheduling pocket.  This holdback method was somewhat blunt, so earlier this year we added a far more sophisticated method (see entry below dated 1/7/14) that lets you far more finely specify holdbacks -- in particular, as specific to individual zones and days of week. 

Anyhow, for either situation the holdbacks have been designed to apply to the quantity of slots you had remaining for a given scheduling pocket (i.e., allocation minus present burden), rather than to the raw allocation.  One of our users provided some good arguments for why it would be better (at least for certain situations, such as his) for the holdback specification to apply against raw allocation instead.  So, there's now an option in each of the utilities to apply instead on that basis.  For example, in SBDL it looks like this:

While overhauling our within-SD ZoneScheduler interface (Shift-F5) to accommodate more zones, we made some incidental GUI improvements.  Most notably, if you have ServiceDesk itself expanded when the ZoneScheduler form is opened, the ZoneScheduler interface itself will expand to take advantage of the enlarged available space.  This may be particularly useful if you decide to setup with a very-large quantity of zones such as is now available.