Like most any advanced software system, your ServiceDesk package includes more than just one program. Indeed, upon installing ServiceDesk you should have noticed that its resulting Windows Program Group includes several program icons: aside from ServiceDesk itself, there’s also SD-Backup, SD-Tools, SD-Manual and Zips. The purpose of this chapter is explain the functions of these other, auxiliary programs. In addition, we’ll describe a few features that, while they are part of the main ServiceDesk program, may nevertheless be bundled in the same category as these other utilities in that their purpose is to manage operation of the program itself (as distinguished from aspects of the program which operate functions of your business, as discussed in preceding sections).
Because it manages so much of your service operation, you'll quickly find yourself becoming dependent on ServiceDesk in a degree that might be considered dangerous—dangerous in the sense that if you happened suddenly to suffer a catastrophic loss of data (i.e., if the fileserver's hard disk were to suddenly crash, with no backup), you'd be lost, severely handicapped in the ability to continue functioning with your normal degree of panache and flair.
As any seasoned computer user knows, there are many systems on the market designed to provide a periodic backup of critical data. Typically, such systems are setup to do a nightly backup of files onto a magnetic tape or writable CD. Certainly, you might consider using such a system to regularly backup your ServiceDesk files. However, besides involving substantial investment in hardware, these systems suffer other limitations which make them potentially less than adequate for the needs of a ServiceDesk environment.
The first problem is that a nightly backup will not save data until after the business day has ended. So, what happens if your fileserver's hard disk crashes around lunch time? Obviously, you will have lost data pertaining to the entire morning's work. This includes all the Callsheets regarding incoming calls that morning, all the JobRecords regarding jobs created and dispatched, all the PostVisitReports from techs regarding jobs done the preceding day, all the entries regarding parts used, replenished, and/or ordered, all the entries regarding sales completed, even the list of jobs scheduled in what was its current state (with additions, deletions and changes since the previous night). Obviously, there's a lot of important data to lose from such a short period of time, and the task of attempting to reconstruct it (and attempting to continue uninterrupted operation in the meantime) might be formidable.
The second potential problem is that, to save media, most backup systems are setup to write new backups over old. Thus, Wednesday night's backup may write over Tuesday's, and so on. To see why this might cause trouble, suppose one of your personnel, working in the Windows File Manager, inadvertently corrupts one of the ServiceDesk files (like the one containing a record of all your past sales, for example). Suppose this isn't noticed right away. You all go home at night, with your ServiceDesk directory containing a corrupted copy of the file, and your backup containing the only remaining good version. Then, precisely when programmed to at midnight, your backup system turns on and copies the corrupted file, writing it over the one good backup. Now, suddenly, you have no remaining good version of the file.
SD-Backup is designed to address both these problems, for any system or network that has any additional hard drive, besides the primary server, available. Installed on the secondary drive (typically from a satellite station in the network, but potentially from a second drive within the primary machine), SD-Backup will make copies of ServiceDesk files once per hour, once per day, once per week, once per month, and once per year. Each of these categories of backup will write into its own sub-directory, over-writing previous backups within its own class, but never over the backup from another. Thus, the most you'll lose from a fileserver hard disk crash (which, by definition, you'll certainly know of immediately) will be one hour's worth of activity (on average, the loss will be only 30 minutes). And, in the event of file corruption that's not detected for at least an hour but less than a day, you'll still have the daily backup to fall back onto (losing up to 24 hours worth of activity in regard to that one file, but no more). If the corruption is not detected until even the previously good daily backup is copied over, you'll still have the uncorrupted weekly backup to use (losing no more than a week's worth of activity on that one file), and so on.
It goes without saying that absolute data security would be even better, but in the real world, complete security for moment-by-moment activity does not yet exist. The SD-Backup system provides the next best thing. Of course, it has to be running to do anything at all. To run it, simply click on the SD-Backup icon from the station where you want your backups located. Then, leave it running in the background, full-time, permanently. Thus, you'll assure continual protection for your files.
We should mention, incidentally, that while there is no strict rule requiring that you use SD-Backup, you'd be most foolish to risk running without it. You'll become so dependent on ServiceDesk, security of its data becomes paramount. As any experienced computer user can tell you, "things happen." SD-Backup is effortless, silent, and very gentle on computer resources. Please see that it's properly running, and that it's kept so.
In the event you actually suffer data corruption or loss, your next task, obviously, will be to secure recovery from your backups. This, essentially, involves locating the uncorrupted backups, and copying them back over, into the appropriate directory, on your primary FileServer drive (or onto a newly appointed FileServer if your former one has catastrophically crashed).
One of the considerations, in this regard, is that before you copy any particular backed-up files over formerly working ones (or into a newly appointed FileServer drive), you may want to first review them for accuracy, lack of corruption, state of currency or not, and so on. ServiceDesk has a terrific built-in feature, for this purpose, called ViewBackups.[1] Access it from the File section of the MainMenu, or by pressing Alt-1. As the name implies, its function is to allow you to view any ServiceDesk data in any of the various (i.e., hourly, daily, weekly, monthly or yearly) backup locations. You are required simply to select the drive and directory for the backups you want to see—after which each ServiceDesk form behaves just as it normally would, except now they are each accessing data from the selected backup directory, to allow you a full review of any file you are interested in. The one difference, you'll notice, is that the Menu bar flashes endlessly in this mode, and in an abnormal color, all to continually remind that you're viewing backups, and not regular ServiceDesk files. To return back to regular file access, either select ViewBackups again (MainMenu or press Alt-1), or assent to changing back when ServiceDesk so suggests (as it does once each minute).
Once you've determined that any particular (or all) normal operating files need to be replaced by one or more backups, the next task is to copy the desired backup (or backups) into the appropriate location. At present, ServiceDesk has no built-in utility for this purpose—meaning you must use Windows Explorer, FileManager, or DOS commands to accomplish the task.
Remember that all the primary operating files, for ServiceDesk, are kept in the \sd\netdata folder of your FileServer drive (see Chapter 11.B: Directory and File Structure). Any other files (in other \sd\ sub-directories) can either be reproduced with some ease, or are relatively unimportant (except the backups themselves). It is, specifically, the contents of the \sd\netdata folder that SD-Backups will be making regular copies of. If a particular operating file becomes corrupted, it is that file, in this location, that must be replaced (i.e., copied back over with a good backup). Use whatever Windows utility you're most comfortable with.
[1]This feature is also handy, occasionally, even when you haven't had a file corruption or loss. For whatever reason, occasion may arise when you want to see what some file (or the data that goes in a file) looked like yesterday, last week, or whatever. It's easy to find out with this utility.
The purpose of this utility is to provide a venue for performing tasks that do not need addressed as part of ServiceDesk's daily operation. Creating a Invoice-Format-Instruction file, for example (see page 278), is something you'll generally need to do but once. Creating your list of Yellow Page ads is a once-yearly task. SD-Tools is designed to assist you in tasks such as these, and need be run only when you are performing them (as specifically addressed in the Appendix). For all other times, SD-Tools is a program you'll leave dormant.
Actually, in providing this utility, we were mostly having fun. We'd secured the data and created machinery, internally, to quickly connect city names with any zip code you might happen to throw out (an ability essential in creating your StreetList). It occurred to us that some users might find it convenient to have this ability at hand, and its reverse: the ability to throw out a city name and instantly see all zip codes applicable to it. So, we made a simple application that does this for you. Just click on its icon; operation is self-explanatory. The one drawback: as mentioned elsewhere, in some cases the city name, that's connected to a zip code, is not very accurate. Blame the Post Office for that.
Your ServiceDesk package includes an electronic version of this manual. It’s provided in Adobe’s .PDF format, so is viewable on-screen via use of Adobe’s Acrobat Reader (more on that later). The file containing the manual (appropriately called ‘sdmanual.pdf’) is installed in the ‘c:\sd’ folder, and could easily be run/accessed via Windows Explorer (or similar means) if wanted. More easily, there’s an icon for it in the RossWare program group. Just click on the icon and (providing your system already has Acrobat Reader installed), the manual will display for you.
One advantage of the on-screen version over the paper manual is that you can click on any page number reference (within the text or table of contents, at least) and instantly be transported to that page. Another plus is that you can always have the most current manual-type information available, even if your original paper manual has long-since fallen out of date (don’t worry, the original paper manual is always up-to-date when first shipped)—as it most certainly will (and probably with some rapidity), for we are constantly improving the ServiceDesk system, adding new features, streamlining others, creating better methods here, shortcuts there, and so on. Naturally, as we make changes in the actual program, we simultaneously make changes in the manual to reflect the fact. Plus, we often make independent changes in the manual simply to improve it, independent of any underlying program changes.
For these reasons, it is important that you make a concrete effort, over time, to assure that the manual you are using is reasonably up-to-date. That’s where the on-screen manual comes most into play, for it’s easier to keep this one up-to-date (electrons being comparatively cheap) than to keep replacing your paper version, over and over again, and with much rapidity. Any time you receive an update via CD, it will include an updated on-screen manual, which will install as part of the process. If you’re updating over the Internet (via email or website), we’ll typically include the current manual as an optional, separate download. Regardless, please make an effort to assure that whatever your source of reading is, it’s not excessively out of date.
In this regard, we realize you may, like us, prefer the immediacy of actually flipping through pages in a physical book, when wanting to review information. Thus, while the idea of a perfectly up-to-date electronic manual may sound well and good, it’s still the paper version you may find yourself wanting to use. So how can you do this, and yet still be reading something (say a year from now) that’s not grown badly out of date? There are a few potential solutions. (1) You can always print-out particularly wanted excerpts from the current on-screen manual. (2) You can even print the entire current manual (from the on-screen version) and have it bound into book form at your local Kinkos or similar operation (or take in the CD, which will always include the current manual [at least current for whatever version is on the CD], and have them do both printing and binding for you). (3) We are happy to provide a new paper manual (updated for all the most recent changes, of course) as often as you want, but for a reasonable fee (typically the fee will be greater, probably, than the cost of doing one yourself at the local Kinkos). Just check with us for current rates.
Regardless, if you’re to use the on-screen manual at all, it is (as mentioned), necessary to have Adobe's Acrobat Reader installed on your machine. In that regard, we'll here provide a small explanation. Acrobat is a utility developed by Adobe to allow for universal document exchange. Basically, any document can be converted to their .PDF format (which we do to our manual before providing it as part of your package), then viewed correctly (at least most of the time) from any other context simply by using Reader. The format is now so common that most computers end up installing it, for one purpose or another, before long. Thus, your computer probably already has it, and there’ll be positively no need for you to concern yourself with these last two paragraphs of description.
If, on the other hand, your computer does not yet have the Acrobat Reader, you'll need to install in order to use the On-screen ServiceDesk manual. For this purpose, we've provided the necessary files on your ServiceDesk installation CD. Just click on Start in your Windows TaskBar, then Run, then Browse, then select your CD drive (usually it's D:). Once you have the contents of the installation CD displayed, click on the folder within that's labeled "Acrobat". Within that folder, you'll see a file named "Acrd4enu.Exe". Simply select that file and run it. It's the utility that will install Acrobat Reader for you.
Though not actually a utility per se, the ServiceDesk MainMenu is discussed in this separate section because, in experienced day-to-day operation, you should almost never need to use it. For novice users, however, it may be most helpful, providing a map to functions that are not otherwise apparent.
Most specifically, you may note that the Menu provides access to almost all non-form-specific functions, without the need to know the Quick-Key combination that would otherwise (and more easily) access the function. Plus, corresponding with each such function's listing in the menu is a reminder of the Quick-Key that might, more conveniently, be used instead. Thus, you can gradually learn which Quick-Keys to use, by reminding yourself what they were each time when, as a beginner, you access something from the menu.
In addition, you'll note there's an entire section in the Menu labeled "Command Summary." This provides an easy, on-line synopsis of the most common commands you're likely to need, under several categories. Some of the items (particularly those under the category labeled "Callsheet Controls") even offer tutorial-type information. Thus, the menu (and particularly this section) can act as a constant, on-line help guide. Also remember that particular sections of this summary are available contextually, from within the particular domains to which they apply.
Aside from the menu per se, there is, of course, its row of 12 command buttons, designed for rapid access without having to reach into actual menu listings. As noted elsewhere, these command buttons may be accessed by a simple left-click of your mouse. But more efficiently, they serve as labels, indicating the function for each of your keyboard's 12 function keys, arrayed in corresponding fashion at the top of your keyboard. Thus, if you want to look at your DispatchMap, and notice that the fifth button on your menu's command button bar is labeled for such purpose, its follows that you can correspondingly hit the fifth function key on your keyboard—for the same purpose. The result will be the same, whether you click on the command button or hit the corresponding function key. It doesn't matter—except that, over time, you'll find it's usually faster when you can keep both hands on the keyboard.
Also, in regard to those menu/command-buttons (and your keyboard's corresponding function keys), you may notice there are only twelve. Yet, we've found the need for more than 12 buttons for bringing up various forms. Accordingly, we've expanded the utility of some button/keys by adding a Ctrl or Alt prefix for differed functions (e.g., you may click/press a plain F7 to load the JobsCurrent form, or Ctrl-F7 to load the JobsArchived form). To see the altered function for each button/key under Ctrl or Alt combinations, simply hold down Ctrl or Alt and watch the labels change. (You'll notice that not all the button/keys have changed assignments; we simply haven't yet found need for all of 36 potential combinations).
Another feature of the menu is its title bar, which displays your company name, with current weekday and time on one side, and date on the other. It flashes alternatively to indicate the status of Callsheets needing serviced at your desk (if any), along with the status of any mail pending for your station (if any), etc.
Note that the MainMenu functions, for the most part, in the same manner as you've grown accustomed to in other Windows applications. The exception is that we've not provided any QuickKeys to access its various headings. The reason: we've used virtually the entire alphabet for QuickKey operations that are more important. This left few keys available as candidates for non-mouse Menu access (and of those that are still available, few would have worked well mnemonically). In consequence, access to our Menu is by mouse only.
As you may have noticed, there are a number of files in ServiceDesk that need to be archived from time to time. Essentially, archiving is analogous to what happens in your file cabinet as one year ends and the next begins. If your office is like most, you probably have one or more drawers where, throughout the course of a year, you assemble all the various bank statements, paid bills, contracts you’ve entered, and so on. When a new year starts, you probably close out that old drawer and open a new one. Eventually, the contents of that older drawer will be moved to a box or boxes and stored in a dusty room somewhere. That, essentially, is archiving. The general idea is that you want to keep your current work area exactly that. Ancient records may occasionally need accessed, but the current area is made much less weighty (and accessible) if the ancient stuff is at least kept in a separate place.
It’s no different with several of the files that ServiceDesk uses, except we do the archiving process more often than once a year. A current area can be kept much lighter (i.e., less to look at, easier to find what you want, more instantaneous access by your computer, etc.) if old stuff is occasionally put elsewhere.
There are five primary contexts in which this process occurs in ServiceDesk.
Most obvious are the Callsheets. The Callsheet pages (how ever many you have going at a given time) are intended to reflect current work in managing calls, service inquiries, and so on. When a Callsheet has completed it’s purpose, it’s marked accordingly (either as having been the basis for creation of a ‘Job/Sale’, as ‘Otherwise Done’, or for ‘Delete’ status). Conceivably, we might have designed the system to instantly remove a Callsheet from the current area (and into the Archive for all but the last category) whenever it’s status is so changed. We did not, however, for removing an item from the Callsheet lineup changes the pagination of everything that comes after. It’s a significant event, and for such reason we thought it best for the process be done on an occasional, batch basis (i.e., letting multiple “done” items accumulate as work progresses, then periodically, and only when ready, removing all such items at once).
Similarly, the JobsCurrent file is intended to contain records pertaining only to jobs that are in-progress. We want completed jobs moved into the JobsArchived file. But that movement is a very serious event, because CstmrDbase indexes must be updated at the same time, copied to each station, and so on. Then there’s the ScheduleList, where again the intent is for the current file to contain only current appointments, and for appointments from the past to be regularly moved to archive. This event is not so significant in terms of what must be internally managed, yet by nature should be done on a batch basis, for it’s by the passing of a day that an entire set of appointments (those from the previous day) suddenly become ready for removal. Additionally, there’s your PartsProcess and AccountsReceivable files, where the same or similar considerations hold true.
As you’ve learned on previous reading, there are methods to manually invoke each of these various archive procedures, on an individual basis. Prior to Version 3.8, that’s exactly what we expected you to do, as often as might be deemed beneficial. In a typical operation (say one having five techs), we expected that Callsheets should probably be archived a few times each day (press Alt-R), the ScheduleList once at the beginning of each day, the JobsCurrent file at least once a week, and the PartsProcess and AccountsReceivable files perhaps once a month. The problem was, most users considered the duty of doing this something of a nuisance, and in fact often failed to invoke the procedures as often as they should have. So, we created a solution: the Auto-Archive utility.
Using the solution is simplicity itself. Simply “turn it on” from within the Settings form. Do this from whichever computer it is that you want to have performing the procedure (not from any others), and leave that computer turned on (with ServiceDesk running) overnight. At precisely 12:30 am Monday through Friday, the system on that computer will self-initiate archive procedures in each of the five files discussed. It will further copy updated CstmrDbase indexes to each of the other stations (for this purpose, obviously, you must leave them running also and connected in the network, but it does not matter if ServiceDesk is running on them at the time).
That’s all you’ve got to do. No fuss, no muss. With so little effort, all these files will be daily cleansed of old stuff, and your CstmrDbase indexes kept up-to-date. The only limitation is that, for Callsheets, a regular nightly archive may be less frequent than you want. If so, continue to manually invoke the procedure (for Callsheets only, the QuickKey is Alt-A) as often as wanted throughout the day (at least you’ll start with a freshly archived Callsheet work area in the morning, based on the automatic procedure having occurred overnight).
If, on the other hand, you’re against leaving your machines running overnight (as is needed for the Auto-Archive procedure to implement automatically), there is a “next-best thing” that allows you to turn your machines off overnight—while still keeping the burden of archiving minimal. Basically, you can manually invoke the same meta-process that would have occurred, overnight, had you had the system setup for it. Under ‘File Functions’ in the MainMenu (there is no QuickKey for this), you’ll see an item labeled “Invoke Auto-Archive.” This features does, obviously, exactly what its name suggests. Specifically, it immediately invokes the same process that would have occurred automatically, overnight, had you had the system setup to do so.
If you do turn your machines off overnight, but will nevertheless make it a practice to religiously click on this item once each morning (before the rest of your work begins), you’ll have the same benefit as if using the full-auto system, and with scarcely more work. The primary downside is that, to fully keep your files fresh, you must force yourself to remember to do this each business day (whereas, with the full-auto system, there’s no such need).
A sixth context involves a kind of quasi-archiving. It’s in the FundsJournal (see page 178). The difference is that there we do not use two separate files (i.e., one for current data and a separate file for old). Instead, we use a moveable marker within a single file (called the “CurrentAreaPartition”). It’s purpose is to allow the system to know how far back, into the file, a search can be limited and still be certain of retrieving all non-checked entries. Like archiving in general, movement of this marker is an “event” –type procedure, because a significant search must be conducted to assure accuracy in the process. However, the system self-invites this process on detecting significant need (a quick check being made each time you load the Funds form). Of course, if you permit the procedure and yet have allowed old, non-checked entries to accumulate in the file, the system will be unable to move the CurrentAreaPartition forward. If so, it will inform you, and suggest that you amend the situation. Given such structure as this, we deemed it best not to include this particular, quasi-archiving procedure among those that are invoked automatically during the Auto-Archive process.
Actually (and in contrast to the other records here discussed), old AccountsReceivable entries are currently not saved in any separate file. Instead, the process simply deletes those entries that have been either paid or written off. We have never encountered a need to review such records in archived form (particularly since the ApplicationsJournal, see page 198, records payments received on any receivable). If you have such a need and would like the old records to be genuinely “archived” (rather than simply thrown out), please let us know.
You might notice that, with this automatic procedure added to a few others, your computers have a busy nighttime lineup of work to perform. At 12:00 am on any business day, the SD-Backup utility should run its procedure for the ‘daily’ category of backup (see page 233). At 12:30 am, there’s this Auto-Archive procedure. At 1:00 am, one of your stations should run the WipAlert procedure (see page 134), and at 1:30 am, perhaps another the WipAlert-Supervisor procedure (see page 170). Be sure to leave the applicable machines turned on, with ServiceDesk or SD-Backup running (as the case may be), so these procedures can indeed be run (unless, in the alternative, you want to manually invoke the auto-archive procedure after turning on the machines upon arriving in the morning, as described in text following).
If there are any stations in the network that do not receive updated copies (the station that does the Auto-Archive will be waiting, when you arrive in the morning, with a report regarding all copied updates), you’ll need to figure out why. For such purpose, well here explain the requirements that must be met in order for the archiving station to recognize and send copies to any other. (1) The other station must be running and connected in the network at the time the Auto-Archive procedure takes place (i.e., 12:30 am on the morning of any business day). (2) The other station must possess the appropriate “c:\sd\cstmrdbs” folder on its hard drive. (3) If ServiceDesk is running on that other station at 12:30 am, it must not be a version prior to 3.8. (4) From within Windows, the archiving station must have “mapped” the other stations hard drive with a local drive-letter designation (see page 338) you may confirm the last requirement by checking, from the archiving station, to see which drives are offered in the ‘FileServer’ designation box of the Settings form. All other stations, that you want to have copied with CstmrDbase updates, should be found there.
While opinions vary, there is a significant plurality of computer gurus who believe it is better for your computer’s health (particularly its hard drive) to be left running, at least most of the time, especially if it is actively used on a near daily basis. If you have its energy-saving options set appropriately (so that various functions “hibernate” after some period of non-use), the electrical draw from doing so is quite minimal. Plus, there are other tasks (automatic hard drive maintenance and so on) that can be facilitated much more conveniently if this is your practice.
Even so, there’s another potential use of this “manual-invoke” feature. It happens sometimes in our office that, though we intend to always let the full Auto-Archive function take care of us (thus we leave our machines running overnight, etc.), occasionally, we’ll inadvertently go home at night, having left without ServiceDesk running on the machine where the Auto-Archive feature is turned on. Thus, we arrive the next morning only to find the process was not done. No worry. Just click on ‘File Functions’ in the MainMenu, then on ‘Invoke Auto-Archive’, then watch as the procedure goes through its tasks—exactly as we’d intended for it to do overnight.
As mentioned in the chapter on installation (see page 13), the Settings Form displays automatically when you first run ServiceDesk after it's initial installation, requiring some minimal settings before ServiceDesk operation can proceed. After that, you can access it from the 'File' section of the main menu, of by pressing Ctrl-F1.
Basically, the form is used to set the primary operating parameters that are specifically customized by you for ServiceDesk operation. It's divided into two sections: one for 'Local Settings' and the other 'System-Wide Settings.' In regard to the latter, we have sometimes used the term "Network Settings," which is something of a misnomer, for settings here are relevant whether you have a network or not. The real distinction is that, while the local section refers to parameters that are particularized for the specific station at which these values are being set, the system-wide (or "network") section refers to parameters that will apply to the entire ServiceDesk operation, regardless of whether it consists of just the one station or of many in a network. If you have multiple stations, changes made in the local section will affect just the one station where it's done. Changes in the system-wide section will alter the values for the entire system—regardless of the station at which they are done.
In the initial setup process, you probably did not take the time to set all the relevant values to where they need ultimately to be when you're actually using ServiceDesk to operate your business. Let's take the time now to explain each parameter, and what you can do with it.
In the upper-right corner of this section of the Settings form, you'll notice two boxes, side-by-side. The first of these is labeled 'Drive Designation for the ServiceDesk Network FileServer'. If you are running ServiceDesk from just one station, the setting here should probably remain at the default that is offered: 'Drive C:'. Of course, if wanted (even on a single station system), you may designate a different drive if available (although you’ll have to add the basic ServiceDesk directories to it). More importantly, if you will be running ServiceDesk simultaneously from multiple computer stations (i.e., you really are networking), please understand, the setting in this box is key to success in the process.
In general (and so far as ServiceDesk is concerned), the networking scheme is very simple. As one component, you must separately install ServiceDesk on each computer where it will be used (you do not have to do this immediately, however, and certainly may add ServiceDesk to any new computer as convenience and need dictate). As the other component, you must decide on which particular computer you want ServiceDesk to maintain its common data files.
Basically, all stations must read, as it were, from a common book. In other words, if you have an operator at one station who adds a job to the schedule, this fact must immediately be evident from all other stations (i.e., as someone at another station looks at the schedule, he or she must immediately see it with the new addition). This task is accomplished by keeping all the basic operating files for ServiceDesk (i.e., the ScheduleList, JobRecords, SalesJournal, and scores of other operating/data files) in one place—or, more specifically, on one particular computer's hard drive. This makes it so that, when changes are made to such files (regardless of from which station), it's the one information set that is modified. And, of course (and by the same token), it's this one information set that is read by any other computer in the system. Thus, and by such means, all stations are enabled, as stated, to "read from a common book."
When referring to this commonly-accessed drive, we think of it conceptually (and refer to it here) as the "FileServer." Understand, however, that aside from the fact that it's where we've decided to keep those common-to-the-entire-system ServiceDesk data files, it's just an ordinary drive (i.e., no more than the basic hard drive on one of your computers).
In ServiceDesk, so far as this scheme is concerned, there is one simple fact each station must know: where it is supposed to find those common data files (i.e., which drive is the FileServer). And that, incidentally, is the precise and only purpose for this little box in the Settings form (i.e., the one labeled 'Drive Designation for the ServiceDesk Network FileServer'). This is where you must inform each station of where to find that "common book."
You may note, in such regard, that this is a local setting, because each station must separately know where to look, for the wanted drive, on the basis of its own Windows-based perspective. And, importantly, you should realize that, depending on how the networking has been setup within Windows, the designation for this drive may vary from one station to another.
If you are wanting to run ServiceDesk within a network, it's very simple—at least so long as the Windows work (of setting up the underlying networked drive access) has already been accomplished. Basically, just click on the down arrow in this box (the one labeled 'Drive Designation for the ServiceDesk Network FileServer'), then identify and select the networked drive you'll be using for the common ServiceDesk data files (i.e., the FileServer). Then, click on the 'Save Local Values' button.
Do this at each station in which you'll be running ServiceDesk, so that all will ultimately look to, read from and write to that one common drive (which, from the FileServer itself, incidentally, will likely be designated as its own Drive C:). Really, it's that simple.
At least, we should say, it's that simple so far as ServiceDesk is concerned. But remember, we are assuming that work within Windows, to setup access to the networked drive, has already been done. Unfortunately, you may find that the underlying work there has not been done. If it has not, you'll find that, as you click on that box's down arrow to display available drives (with the intent of selecting some particular drive from another computer for the FileServer), that other drive does not appear. In fact, unless you've already setup other applications for networking in such manner, you probably will not see the needed listing. This means some Windows work is needed. If so, it will be the one matter—a Windows matter—that may complicate your ServiceDesk networking process.
In regard to further ServiceDesk setup, we'll now move our attention one box to the right. Now, we're in the upper-right corner of the of the Settings form 'local' section. Here, you'll see a box labeled 'Name of person using this station'. Why is this name wanted? One thing you'll find, in ServiceDesk, is that as various tasks are performed, ServiceDesk documents who it was that performed them (and typically the date and time as well). Basically (and with some exception), if work is done at a particular station, ServiceDesk assumes it was done by the person who is designated, here in this box, as the person assigned to the station. Plus, if any mail is sent to a particular person, or a Callsheet's transferred to that person, and so on, ServiceDesk goes by the name designated here to determine whether such matters should be displayed at such person's desk. Thus, it's important to put the actual name here of the primary person who'll be using the station (or desk) in question. By convention, we put just first and last name (in normal order, no commas), in upper and lower case (i.e., do it like "John Smith").
Now, below these two selection boxes in the top-right corner of the form, you'll see an options frame that allows you to select the appropriate CommPort for your computer's modem. In most installations, this will be CommPort 2, but it might, potentially, be any other. If the setting is not correct here, ServiceDesk will be unable to access your modem for autodialing and similar functions.
Finally, arranged in a long column (and somewhat separated groupings) at the left of the local settings section, you'll see a list of features that may, optionally, be turned on or not.
In the top grouping we have first an item labeled 'Enable auto-setting of Capslock'. Set this if you want ServiceDesk to manage placing your keyboard into capslock, or not, as appropriate for each context (recommended). Second, is an item that reads ‘'Include full mailing address with all street name insertions'. Use this feature if you're planning on generating mailing lists for all your customers. The full mailing addresses (i.e., including zip and state) will need to be in each Callsheet, so as to ultimately be included in a mail list. Third, is an item labeled ‘Include full month reference with each appointment insertion. Set this to true if you want all inserted appointment notations to include a number for both month and day-of-month (as in “12/31 THU”) versus simply the day-of-month (as in “31 THU”). Fifth, is an item reading ‘Sound periodic chimes to alert of past-due Callsheets.’ Pretty self-explanatory.
The second grouping involves three options related to the DispatchMap.
The first of these, for example, is labeled 'Show mini-map in dispatch map'. If it takes a lot of panning to view your entire dispatch map, you may want this feature turned on, to help maintain a sense of which portion of the map you are viewing at a given moment (you can turn it on temporarily, to try it, at the very least). Mostly, however, we find the little insert is distracting, and prefer to keep it turned off.
Next is a feature labeled 'Show 5-mile range lines within dispatch map'. Again, you can certainly turn the feature on to try it, and if you like it, keep it turned on (particularly, if you need with some frequency to know distances from your headquarters). We find there is little distraction in the range lines, and like to keep them turned on.
Finally, in regard to the DispatchMap, there is an option labeled 'Show individual mileage estimates in dispatch map'. Our purpose: we found some of our dispatchers were not paying sufficient attention to making the routes for each tech as efficient as possible (i.e., minimum travel between jobs). So, we invented a utility that instantly estimates the number of miles for each route (or instantly recalculates with each routing change). This provides a "score," as it were, by which the dispatcher can grade how well he or she has done—and, we hope, gives some motivation for doing better. We find the extra data is somewhat distracting on the map (roster-wide estimates are given at the top of the map regardless), but may nevertheless be worth the clutter. If wanted, you can choose a middle ground: keep the option turned off, but, when wanting to momentarily view mileage estimates while viewing the DispatchMap, simply press and hold down your keyboard's 'M' key.
Next there’s an option all by itself, labeled 'Switch this station into TechMode immediately upon startup'. The purpose: if you have a station that you've setup pretty much for exclusive use by your technicians (i.e., in reporting on their jobs, etc.), it may be helpful to have ServiceDesk switch into the TechWindow mode immediately upon starting up. By turning 'on' this feature, you can have such a station do so. Of course, you can still switch it out again using the semi-secret key code (see page 116).
Finally, there’s a group of three options. These are somewhat special in that, given what they do, there’d be no purpose in having any one of them turned-on from more than one station in your system (of course, there is labeling there to let you know this).
The first two of these relate to the WipAlert system as described at page 118. First is a feature labeled 'Send WipAlerts (Callsheet notes re stale JobRecords) to this station'. Turn this on at one the particular station where you want such alerts sent (probably your primary secretary's desk). Do not turn it on elsewhere. Second, is an item labeled 'WipAlert-Supervisor (informs if job more than 2 days past alert)'. Turn this on at the one particular station where the owner or supervisor works, assuming this person is separate from the primary operator, and also assuming this person wants to be informed if the ordinary WipAlerts (see above) are not being promptly attended to.
The third item in this last group reads ‘Do nightly Archive/Cleanup of files’. This is where you activate (again, it should be done on one computer only) the Auto-Archive feature, as described beginning at page 209.
After you have all settings as wanted within the local section, click on the 'Save Local Settings' command button. Return to the form to change any feature you want, as often and whenever wanted.
In the first box, labeled 'List of Station Names', you should (as the label implies) create a listing of the names at each station in your network. Use the same simple name format as for the local station name (i.e., first and last, normal order and upper and lower case, as in "John Smith"), and be sure that after typing each name, you hit Enter to make it insert into the list (if you have just one station, list just the one name).
In the next box, labeled 'List of Technicians', you should (again as the label implies) create and maintain a listing of the names for each of your techs. Again, use the same simple name format as described above (i.e., first and last, upper and lower case and in normal order, as in "John Smith"), and make sure you hit Enter to insert the typed name into your list.
One caveat, in respect to these names: ServiceDesk uses initials in several contexts for the names of both techs and station operators. If you have two people with the same initials (i.e., a John Dillon and a Jennifer Dougherty), difficulties could arise. If such happens, you might use a middle name for one of the two persons in lieu of their first, a nick name, or use some similar expedient to avoid identical initials.
To the right, in this purple 'net-wide' section, you'll see another array (similar to those in the 'local' section) of features that may, optionally, be turned either on or off.
First among these is the 'Departmentalize Sales' feature; check it to true if you want to categorize your sales among different departments (see page 172).
Next is a feature labeled 'Enable Source of Jobs Survey.' Basically, you'll want to turn this feature 'on' during the particular period (or periods) when you're conducting a survey (see appendix for directions on setting up), and leave it off at all other times. When it's on, your operators will be prompted to ask the caller a series of questions the time they schedule service.
Next is an item labeled 'Mandatory 10-digit Dialing.' The purpose here: in some areas of the country, even local calls require use of area code when dialing. If this feature is turned 'on', ServiceDesk will add the local area code when auto-dialing any number that does not otherwise indicate an area code. Conversely, if the feature is not turned 'on', yet a number-to-be-dialed shows your own local area code (the latter is itself determined by the voice telephone number listed for your company), ServiceDesk will delete the area code when dialing.
Next is an item labeled 'Allow for divergent sales tax rates depending on locality, type, etc.' This is for those few clients whose territories encompass multiple jurisdictions that each have different sales tax rates (or which require separate sales tax reports, etc.). For such users, it obviously would not work to specify one particular set of rates for all sales company-wide (see next paragraph). If this is your situation, check this option and read the technical section beginning at page 299.
Finally, in terms of net-wide features that may be turned on or off, there's a feature labeled ‘Immediate Call-in Option.’ This is to enable the approach, as described at page 112, where you elect to have your techs call in both on arriving and departing from every job, plus you take a complete PostVisitReport from each with the second call-in.
Following each of these feature settings, in the net-wide section of the Settings form, are several self-explanatory boxes. Some are for inserting your company's current address and telephone numbers (used in some of the documents ServiceDesk creates). One is for your bank account number (ServiceDesk includes this on the deposit slip it prepares for you), and two others for the materials tax and labor tax rate applicable to your sales (ServiceDesk uses these in checking totals on your completed sales, etc., assuming you haven't selected the option described in the last paragraph). Of course, there's also a box for entering the next invoice number in your sequence (defaults to start at invoice number '00001', but should be changed to start at whatever number fits with the sequence you already have in use).
A final box is labeled 'Area codes for which '1' prefix should not be inserted when auto-dialing.' The reason: there are many cities where, in recent years, area codes have multiplied uncontrollably. In some of these, it is both allowed and preferred (some say it's cheaper) to dial the nearby area codes without first using a '1'. If yours is such an area (or if you have mandatory 10-digit dialing yet the '1' prefix is not necessary when dialing your own area code, you may list all such codes in this box. On the other hand, if you do not have mandatory 10-digit dialing, there is no need to list your own area code here. ServiceDesk will assume (without separate listing here) that any number which has the same area code, as the one listed for your voice telephone number, does not need a '1' first.
Much like in the local settings, when you're done with the System-Wide Settings, click on the command button labeled 'Save System-Wide Settings'.
You can enter the Settings form, as often as wanted, to change any parameters as need or preference may arise. Don't be afraid of it. It's simple and easy.
As mentioned elsewhere, one of our purposes in ServiceDesk is to enhance the security of your operations by making it impossible, for example, for funds to disappear without you knowing it, or for paid sales to be credited without corresponding funds being collected, and so on. If an unscrupulous operator were granted unrestricted access to your files, obviously, these purposes could be defeated. Thus, at various places and for particular kinds of operation, we require use of a password—a key to the lock, if you will, that should be possessed only by those you trust for the particular operations involved.
Besides security against intended skullduggery, another reason we occasionally require a password is to keep those who may not know precisely what they are doing (but who nevertheless intend well) out of sensitive operations. You may, for example, want to do something in terms of entering sales, payments, or whatever, that's out of the norm, to correct for a previous improper entry, or similar purpose. You know what you're doing, so it's fine to proceed, but if someone without a real understanding attempts the operation, it may produce an unforeseen result. Thus, we require a password to keep those who are well-intentioned, but perhaps not perfectly knowledgeable, from messing things up—which means that, in considering who to entrust with a password, you must account not only for whether you've got absolute confidence in their integrity, but in their competence in dealing with sensitive operations as well.
For passwords to be effective, obviously, their secrecy must be carefully controlled. It’s also important that you can specify which locks any particular password is allowed to open, and which not. All these needs are addressed in the Security Settings form.
To access this form, you can hit the quick-key combo Shift-F11, or (if you prefer mouse action) click on ‘File Functions’ in the Main Menu, select 'About ServiceDesk', then click on the 'Internal Security' button. If this is the first time you’ve accessed this form, you’ll need to set your Master Password. Think of the Master Password as being like a master key. It can unlock anything. As such, it’s probably a password that should be known only to the owner, and perhaps to a most trusted, top-tier manager.
With Master Password out of the way, you can choose which particular areas of ServiceDesk you’d like to have password protected. To show this display, click on the 'Actions' radio button (Alt-A). The resulting list shows all the areas of ServiceDesk that have password protection available. To enforce password protection on any item, double-click to toggle “Password required?” to TRUE. Double-click again to toggle it back to false.
Just as a large building may have a master key that opens all doors (with lesser keys that open only particular doors), the Security Settings form allows you to create lesser passwords, that can open only the particular doors you indicate. To enter this function, choose the 'Users' radio button (Alt-U). Here you may create (and manage) as many lesser passwords as you wish. Each must be listed on its own line in the first column. The idea is that it’s like creating a key that can open particular doors, and you’ll give that key to the person who you want to have access to those doors. Make as many keys as you need here—and, certainly, keep track of to whom you are giving them. That is, in fact, what the second column in this display is for: to help you keep track. Generally, that second column does not have any other function (i.e., it’s meaningless to ServiceDesk).
After creating any permission key, highlight it and select the 'Permissions' radio button (Alt-P) to select which items in ServiceDesk this key accesses. You can double-click on items here (much as in the ‘Actions’ display) to toggle whether the password will (or will not) provide access to the indicated action. If a password is compromised you can change the password in the first column without resetting the permissions you granted (Alt-P). Also, you may return (as often as wanted) to modify the permissions that are granted to any particular password (i.e., the “doors” which that password can unlock).
There is one exception to the fact that, generally, the second column in the Users page is only to help you keep track of who has which key. If you have techs logging into TechWindow mode and want make it impossible for another tech to log-in under a particular tech’s ID, create a password for the tech and in the second type his entire name (exactly as entered in the settings form). Now, only that password (or the Master one) will work for a tech mode log-in under that tech’s ID.
In the Security Settings form you can also reset your master password (it’s good to do this periodically to enhance security). Select the 'Set Master Password' button at the bottom of the screen. You’ll be prompted for your current password before you can enter a new one. You will then re-enter your password for accuracy. ServiceDesk will keep a log of when your master password was changed.
One note: if you feel absolutely no need for the security of a password, you can set (or leave, if you’ve never otherwise set) the password as nothing (i.e., do not type in anything for your new password, and just hit enter to save the nothing typed). Then, in actual operations, whenever ServiceDesk asks for a password, you can simply hit Enter (easier than actually typing something in), to enter your password of nothing.
