ServiceDesk 4.8.46 Update 01/07/18

We thank Tim Koyonen for pointing out the need for this improvement.  He explained how it's pretty common for customers to request simultaneous repairs on more than one machine.  Because the Mobile system is designed to connect to a single machine per JobRecord and appointment, the office will place each of a particular customer's machine requests into its own JobRecord, and make individual appointments as connected to each (all appointments targeted for the same date and time frame, but nevertheless each as its own individual record). 

The issue that arises in this circumstance is, when requesting that the system send out appointment-reminder/confirmation-requests, it sends one request for each unique appointment and machine-to-be-serviced.  Beyond the fact that your customer may be annoyed by these multiple requests, they may also be confused when they see the first request referencing one particular machine to be serviced, when knowing they requested work on that machine, and one or more others, too. 

We've solved that. 

With a combination of this ServiceDesk release and the current release of SD-CyberLink (Ver. 4.5.48), the system will be considerably smarter in handling this kind of situation.  In particular, where you have multiple appointments, each connected to a different JobRecord, but each for the same customer, assigned to the same tech and for the same date and time frame -- where all that is true -- the system will note the fact and create a single reminder/confirmation-request to cover the entire set. 

In fact, in each context where the reminder/confirmation process is poised to remind the customer of what kind of machine is being serviced, the system will intelligently create a combined description.  Suppose, for example, there are appointments to service a Whirlpool Washer, a Maytag Range and a Kitchenaid Dishwasher.  Formerly, there would have been individual descriptions for each (and each in its own particular reminder/request).  Now, the single combined request will reference such objects of service in this manner:

"Washer, Range and Dishwasher"

Obviously, that's much more enlightening (and less confusing) to your customer. 

Another benefit of this new intelligence is, when your customer confirms or cancels on the single combined request, the result flows back into each involved appointment and each involved JobRecord. 

Please don't forget.  You also have to update SD-CyberLink so as to enable this new intelligence.  

The ServiceDesk Security form (Shift/F11) is, of course, where you indicate which actions are going to be password protected, which are not, whose passwords will unlock which door, and so on. 

One challenge in regard to using this system is that, often, because new users don't have a good understanding of what's what, they end up somewhat foolishly putting locks on doors that don't really need them, and removing locks on doors that really should have them.  We've structured the defaults (which doors initially have locks versus not) in a manner we think is optimum for most users.  Where a user has, well, created  something of a "which doors are locked and which are not" mess, it's possible they'll realize they just want to return to defaults, then adjust to particular preference (more carefully this time) from there. 

Until now, we did not have a function for this.  Now we do.  When in the Security form you display Actions (this is the mode in which you see each door that may potentially possess a lock or not, and set each according to preference), a new little button appears, as shown here:

If you click on it, you'll get a dialog that asks if you truly wish to restore defaults.  If you respond "Yes," that is of course exactly what happens. 

At Rossware, we very much want for all our users to enjoy maximum ease, delight and smoothness-of-flow as they use our systems.  Given this, we find ourselves feeling greatly frustrated when, as we're assisting on some issue, we see that a client must endure not just one, but two password challenges before they are permitted to display a particular report. 

Why does that happen?

In a nutshell, we've structured the Security system to give you a lot of flexibility.  In regard to the various reports that are available from within the Reports form, as an example, it's possible you don't want your employees, generally, to be able to access anything from within that area of functionality.  If so, you can put a lock on access to the entire form (a lock that may be opened with authorized passwords, of course, but a lock nonetheless).  Contrariwise, it's possible you don't mind if employees have access in this area generally, but there are one or two particular reports you consider sensitive, and do not want just anyone having access to.  If so, you may forego having a lock on the context overall, while nevertheless putting locks on the particular individual reports that concern you. 

So, we give you that flexibility, and . . . what happens in consequence? 

Yes, many of you choose to put a lock on the entire context, and on individual reports within the context as well.  Thus, there you are, having to endure one password challenge just to get into the context, then another to run a particular report within it. 

Because we don't want you to be endlessly enduring this kind of unneeded and senseless frustration, there are now mechanisms to help keep you away (as you configure your Security settings) from making such a mistake. 

In particular, where you choose to activate password protection in a whole-context area that also has potential password protections within (there are, incidentally, other such contexts, besides the Reports form), the system will look to see if you have activated password protection on one or more of the sub-areas.  If so, it will suggest you should not have both layers, and will offer to delete one or the other.  Conversely, where you are activating password protection on any potentially applicable sub-area, the system will look to see if whole-context password protection is activated in a manner that already covers that item.  If so, it will again present a warning and similar options. 

First, you may now password protect against editing a formerly-saved purchase invoice number in the PartsProcess (F8) form.  Evidently, some users were finding that some of their employees sometimes inadvertently changed that number.  This password protection defaults as turned on. 

Second, you may now differentially distinguish, in password protection, between zone-overbooking that results from changing an existing appointment, as opposed to creating a completely new appointment.  Formerly, a single password protection applied to either situation, but we found some people wanted a password challenge to exist for the new appointment situation, while not for a mere change.  This addition allows you to so distinguish.    It also defaults as turned on.