ServiceDesk 4.5.17 Update 05/05/11

This addition was prompted by a call from JD at Guinco Service in Texas.  That operation has some techs working in remote regions, and as JD in the office pre-screens jobs he'll often order parts before the tech ever goes out.  Pointedly, he has the vendor ship said parts directly to the particular tech -- a factor that, obviously, makes it rather important that when an appointment is created for that tech, its assignment status be set as "Definite," as opposed to "Tentative." 

To accommodate this kind of need, you'll now see a new settings area within any tech's Profile sheet, as displays when you click on his name within the TechRoster section of the Settings form:

At least with benefit of description as above-provided, I believe meanings in these new options are obvious.  The default selection ("never") leaves functions the same as always.  It's only be selecting another option that you'll notice any change in operation.

 In the title of this entry, you'll notice, when referring to this new default-setting option, we're ballyhooing the fact it can be done on a "per-tech" basis.  The reason for this specific "ballyhoo" is because (and we need to explain it here for full context), a couple of years back (see Ver. 4.3.40 entry from 12/10/09, below) we added on option where, from the Create-Job/Sale form, you can change the default as applies in all instances (i.e., across-the-board).  That old (much more of a "blunt knife") option still persists.  And it's true, obviously, that If you did have your default set to "Definite" via that old/broad method, any new-option setting via individual techs would be superfluous. 

Credit for this one goes to Krystle at Folsom Lake Appliance, in California.  Krystle was sometimes getting email replies from customers, triggered by them (and generally containing specific inquiries) on the basis of emailed tickets as generated via SD-Mobile.  The replies did not contain the originally attached ticket, and it's that ticket (in the context of these emails) that would contain information disclosing who the customer is.  Absent knowing who the inquiring customer was, it was difficult for Krystle to respond.  Indeed, her only basis for identification in this context was the customer's email address. 

In regard to such email addresses, ServiceDesk of course has fields to track them very nicely.  However, it's often the case that you do not have the customer's email address prior to sending the tech out.  In such a case (and assuming he's using SD-Mobile, and using e-tickets within SD-Mobile), he will acquire the customer's email address in-the-field, as a pre-requisite to sending the e-ticket.  This email is then automatically inserted back into the JobRecord, via operations of the SD-MobileLink program. 

So, in theory, when Krystle receives the customer's email reply, she should be able to find the JobRecord in ServiceDesk that contains the sender's email address.  That will then be the correct customer.  Problem is, though email addresses have in general been fully searchable in ServiceDesk, the ability has depended solely on the CstmrDbase Index set, which is typically updated once each night.  Thus, if the email had just barely/same-day been obtained (via the tech's getting it for sake of sending the e-ticket), that email address would not yet be discoverable via the long-standing search method.  That's why we added a new option to the record-by-record searches, as offered from within the F7 form:

segment from the Current-JobRecords form showing old search options at left

segment from now-revised form showing search options with new addition

As intimated, this new item is one of the set of searches that does not depend on the once-per-night-updated Index set, and thus it can locate an applicable JobRecord on basis of email address even if that address was only added in the current day.  In regard to all these searches, please always bear in mind that you are permitted to type only a portion of the search target.  Often we see people thinking they have to type the entire thing.  That's too much work. 

Other:

As is the case with most every release, this one too contains improvements you should manage to enjoy without needing to first learn of their existence, via reading here.  In general, we don't announce such matters here, as there is little need.  But some matters are almost the opposite, in that you might think something is wrong, absent an explanation here.  One is as suggested by Adam at Fred's Appliance.  As you open a current JobRecord, the history box will now automatically scroll down (if needed) to show the bottom/most-recent entries.  Please don't think this is a malfunction.  It is intended.