If you’ve used other CstmrDbase systems, you may have a bit of un-learning to do before making full sense of the ServiceDesk setup.  Ours is different.

In a typical system, the CstmrDbase consists of a master list.  This list has one entry for each customer.  Each such entry lists things such as a customer’s name, address, telephone numbers, etc.  The list of entries has no function except to be a repository of this information, and a source from which such information may be drawn when needed.  Typically, the list involves a considerable amount of housekeeping work on part of the user—in first creating the entries, keeping them up-to-date, eliminating duplicate entries, correcting for errors, address or telephone number changes, divorces, etc.  These are complications we sought to avoid in the ServiceDesk system.  How have we done it?

Basically, we eliminated the master list.  ServiceDesk has none.  Instead, it simply uses the accumulated history of past jobs (i.e., the one that will develop as you use the system).  Each of these jobs, after all, has—as part of its record—all the information that would likely be in any master list (and much more).  The trick is simple.  ServiceDesk maintains indexes to this mass of past jobs.  By doing logic-based searches within these indexes, it can instantly locate any name, address or telephone number that arose in any of those past jobs, along with the full information set from each job that pertains.

So why do you need a master list?  In fact, there are some potential benefits in more traditional systems (such as that a master list may contain information of a kind that would not normally be put directly into a job record, for example), but for a typical ServiceCall-performing operation, we think their disadvantages (especially as compared against the many benefits of a pure job-record-based system) outweigh any advantage.  Regardless, please do not look for such a dedicated master list in ServiceDesk, for there is none.  In our system all customer information is found, quite simply, in the actual record of past jobs.

At least, that’s the generality by way of background, but in fact there are several specifics it may be helpful to know.

1. In the foregoing paragraphs we’ve used the term “past jobs” somewhat loosely.  In fact, the CstmrDbase indexes reference jobs both from the JobsArchived file and from the JobsCurrent file (at least those that have “in the past” been indexed, see following).  In understanding this, please try to avoid a mistake common among new users who sometimes think it’s Callsheet text that should be indexed to the CstmrDbase.  Though first written to a Callsheet, job information is not that until it’s part of an actual JobRecord, which of course is initially created from a Callsheet, but is certainly different from it.
2. ‍you should know how the CstmrDbase indexes are created and maintained.

Utilities for doing so are found in two different places.  One is in the JobsCurrent form, another in the JobsArchived form.  The difference is that, while the former is designed merely to update the indexes from time to time, the second creates a new set of indexes entirely from scratch.  Why are both functions provided?  In fact, when you’re first using ServiceDesk either method would work fine for all purposes.  However, after you’ve accumulated many thousands of job records, the process of making new indexes from scratch may  take many minutes of intense, no-other-use-possible computer time.  To minimize that inconvenience, you’ll more typically use the mere update method.  Yet sometimes you may still need the MakeNew method because it’s possible, from time to time, that some corruption will creep into these files, and it’s only by building virgin indexes from scratch that it can be eliminated.

To be more specific in regard to the mere-update method, it’s provided in the JobsCurrent form as part of its Archive utility.  That utility, obviously, invokes the process of moving completed JobRecords out of the JobsCurrent file and into the JobsArchived file.  This event necessitates updating of the indexes, because they reference the location of these jobs (i.e., in which file and wherein), after all.  Thus it’s logical to incorporate updating of the indexes into the same process that involves moving the underlying records.  In fact, during this routine the process updates the indexes to reflect all records in the JobsArchived file and all that currently exist within the JobsCurrent file.  We make the distinction as to those records that “currently” exist for this reason:  Any new jobs that are added, after the CstmrDbase indexes are either updated or newly created, will obviously not be in the indexes.  Thus, these particular jobs will not show up in any CstmrDbase search (although, remember they will still be accessible from within the JobsCurrent form itself, based on any of its built-in searches).

This last fact, incidentally (i.e., non-availability of post-index-created jobs via a CstmrDbase search) argues strongly for running the JobsCurrent form’s Archive utility with some frequency—or better yet, letting  the Auto-Archive utility do it for you automatically on a nightly basis (see page 209).

Regardless, there is a related detail that bears explanation.  To absolutely maximize the speed at which CstmrDbase searches are performed, we’ve designed it so that each ServiceDesk station maintains its own local copy of the indexes (this way they are not each simultaneously clamoring to access common files from the Server).  Plus, each station keeps the index files open during normal operation (rather than opening and closing as needed with each use).  This complicates the matter of making new or updated indexes from any particular station, for the others must receive updated copies.  Utilities are built-in to both procedures to assist in this (the Auto-Archive sequence takes care of everything for you), but with this word of explanation it may make more sense.  Also bear in mind that if you’ve failed to use the built-in utilities for updating other stations, it’s easy to copy the relevant files over (from one station to another) using Windows Explorer or other Windows utility (it’s simply all four files that you’ll find in the ‘\sd\cstmrdbs’ folder that are relevant).

3. You should understand the basis ServiceDesk uses in deciding which text from a given job record should be included in the indexes.  Obviously, not every item of text in every job is going to be properly applicable, and ServiceDesk must have some means (without true intelligence) of deciding what’s merely extraneous text within a field and what’s real information of the kind that should be indexed.

It’s criteria is fairly simple.  In regard to the CustomerInfo block from the job record, the system figures that any leading text in the name field must be a true, properly-index-able name, and any in the address field similarly index-able for that purpose, and similar for the two telephone number fields.  In regard to the LocationInfo block, however, these assumption seem considerably less valid.  On many jobs, after all, the customer and location will be one and the same, and presumably therefore you’ll have true customer information only in the first block.  This leaves the second block free for extraneous notes, and if your office is like ours you’ll occasionally use it for such purpose.  So how can ServiceDesk tell?  Quite simply, it looks for an opening bracket (i.e., “[“) in the LocationAddress line (as would appear in conjunction with a grid reference, for example, and should exist if you’ve used that block for true customer information).

In other words, if the system finds text such as “123 SOMERSET LANE [923E5]” in the LocationAddress line, it will include that and other LocationInfo-block text in the indexes.  If, on other hand, if finds something like “THEN TURN LEFT ON HALIFAX” (or even “123 SOMERSET LANE 923E5]”), it will not index any of that block’s text.

One more caveat in regard to what’s indexed: by design, we intentionally do not index name, address or telephone numbers that belong to those customers that, within the QuickEntry system, are designated as HighVolume-type clients (see page 57).  The reason is because, presumably, you’ll be generating many, many jobs under these clients names.  If each such job created its own index references based on the HighVolume client’s name (or address or telephone numbers), it would expand the indexes needlessly, plus be of no real use.  Instead, these jobs will all be indexed (subject to the proviso explained in the preceding paragraph) based on information in the LocationInfo block of the job record, making any needed lookup very practical indeed.

4. If may help to be reminded that, as a means of displaying the job records it locates, the CstmrDbase system uses an abbreviated instance of the JobsArchived form.  Why, you may ask, did we do it this way and not use a unique form, designed solely for the purpose?  Basically, it’s a matter of economy.  The JobsArchived form was already well-designed for displaying job records, so why not use it?  It seemed sensible to us.

But the JobsCurrent form is likewise designed to display job records, so you may wonder why we did not use it instead?  Well, it’s an already heavily-used form, doing many tasks, while the JobsArchived form was more lightly used.  To impose additional duties on it (and build-in the needed adaptations) was simply more logical.

Of course, each form (JobsCurrent and JobsArchived) in their standard modes are designed to access and display job records only from their own respective contexts (current jobs or archived, as the case may be).  In the CstmrDbase context, we’ve had to adapt the JobsArchived form to allow it to display either archived (which is more normal for that form) or current jobs.  This has an important consequence that may seem more logical if explained here.  Specifically, you cannot edit a job record when viewing it from directly within the CstmrDbase context.  Instead, if it’s a current job record (i.e., it’s still in the JobsCurrent file) you must go to the JobsCurrent form and load exactly the same job record into it, for editing or other operational tasks.  If it’s an archived job record, you must reload it into the JobsArchived form with that form in its standard, rather than CstmrDbase-display mode.

To simplify either task, we’ve built-in a very nice shortcut.  Suppose you’ve looked up any job (current or archived) via the CstmrDbase system.  The job is displayed for you in the abbreviated, CstmrDbase-displayed mode of the JobsArchived form.  You want to do some real, operational work (such as editing, for example) within the record.  What do you do?  Simply press F7 if it’s a current record, or Ctrl-F7 if it’s an archived one.  Ordinarily, of course, such action would load the forms with most recent records loaded into them (then, if wanting a specific different record, you’d have to use some means to locate it).  In this context, however, the system will load the respective form—with the record that you were already viewing in the CstmrDbase context loaded!  (Actually, in the case of an archived record it will convert the already displayed JobsArchived form into its full-use mode, and reload the same record as was already displayed).  This is a very handy tool, so don’t forget about its availability.

5. Be sure to consider all the different modes by which you may conduct CstmrDbase searches (as summarized beginning at page 66), each of which involves a matter of considerable convenience within its own context.
6. If there is an item (name, address or telephone number) that you believe should be coming up in a CstmrDbase search, but is not, consider the following queries by way of troubleshooting.
   (a)                Has either a MakeNewIndex or JobsArchived-form-imbedded Index-Update routine been run since the job was created (created, that is, so that it had an actual JobRecord viewable from either the JobsCurrent or JobsArchived form)?
   (a)                If it’s a last name you’re searching for, was it listed on the job in proper last-name-comma-space-then-first sequence (“BOYLES, JOHN”, in other words, when the name you’re searching on is “BOYLES”)?  
   (a)                If it’s an item from the job’s LocationInfo block, does the address line of that block have an opening bracket (i.e., “[“) anywhere within it?
   
7. Finally, if the above checks fail to provide a solution to any failure-to-show-up problem, or if you have the item showing up but the system otherwise fails, please don’t forget to consider that your indexes may have somehow been corrupted, and you may need to run the JobsArchived form’s MakeNewIndex routine to make new ones from scratch.