ServiceDesk 4.8.67 Update 08/21/18

We'll just use a picture:

That's all the description you need, right? 

Are you using the integrated Caller-ID feature?

If not, man, you should. It's super powerful.

Anyhow, until now there was a predetermined period of time that incoming Caller-ID info would remain displayed, within the first vacant Callsheet. Specifically, the pre-set display period has been 30 seconds (not more, and not less).

Some folks wanted more time, so we've now made it so you can specify the time-out period, according to your preference.

As logic dictates, this new setting option is located in the "CallerID Setup" interface (accessible by clicking on the option of the same name under "File Functions" in the ServiceDesk MainMenu).

This new feature was triggered by a request from Adam at Fred's Appliance.

Adam has become very active in a venture called Fluid Services, which specializes in (among other things) helping service companies better harness the internet as a source of COD business. He needed the data that's in this export to drive data points that will make Google Maps more effective for marketing in areas it otherwise tends to ignore.

If you wish to use it similarly, we suggest you inform Fluid Services, and they can put you on the right path in regard to how such data is used.

The new export is located in the "Export Customer Data" interface (Alt-F3 is the shortcut) as shown here:

If you have an office person that manually changes the status of one or more JobRecords, and if that person does so in circumstances that it should not be done, it's possible it will foul up some processes, and you'll want to know who was the person that did it, so as to accommodate a little coaching of said person.

Because of this need, we were asked to make it so any such manual status change would be memorialized via an automatic insertion into the applicable JobRecord's historical narrative.

The problem is we get requests for automated insertions in connection with a million different kinds of (often fairly trivial) events. If we acceded to even a majority of such requests, the automated insertions would end up producing narratives that are so lengthy and detailed as to greatly reduce their general effectiveness otherwise. (We think they are most effective when retaining the character of being a relatively brief overview of event high points.) Thus, we must be judicious in what we accept as events that create automatic insertions.

In this case we figured the issue could be solved via another path.

In particular, we made it so any manual change in a JobRecord's status will cause insertion to a new and special log file that will hereinafter exist for the purpose. Contents in the file will look something like this:

The file will be located in \sd\LogFiles\ folder on your ServiceDesk server with the filename "JobRecordStatusChangedManually.csv."