Lets say that you always want to always keep the phone number that is entered by the user for a particular ticket regardless of what is in the contact record.  This may come about if you have a telephone number for a contact that is only applicable to that ticket.  Lets take a look at how to do this.

First we want to save the old values, so in the pre fill expressions we will add:

$save.field=field in $File;

We would repeat this step for all the fields we are going to check if they have changed.

Next we need to add the conditional expressions in the post fill expressions.  Don’t forget to cleanup your variables when you are finished:

if (field in $File ~= $save.field) then (field in $File=$save.field);

cleanup($save.field);

This will leave the fill value in the record unless it is different from the initial value, in which case it will replace the fill value with the saved value from the previous step.

Or you could use this technique to tie a particular type of telephone number to the priority of the ticket.  Lets use the office number for low priority, and the cell for high priority.  First we add variables in place of the “fill to” values (where the field on the form would usually be located) for all the phone numbers we might use.

fill to                 fill from

$work.num               contact.work.phone

$cell.num               contact.cell.phone

Then in the post fill expressions we need to add code to use the correct telephone number based on the value of priority (always cleanup your used variables)

if (priority in $File=”low”) then (contact.phone in $File=$work.num);

if (priority in $File=”high”) then (contact.phone in $File=$cell.num);

cleanup($work.num);cleanup($cell.num);

This same technique could be used in a variety of ways including conditional fill of other fields based on certain fill values or even modifying the values that are being generated by a fill.  Although the code we used is rather simple, it is powerful and indeed a valuable tool in Service Manager.

The following fix come directly from HP – there is a bug where read-only fields will not display correctly web clients.  Using the steps below should fix this problem:

Having problems with ‘read-only’ fields not displaying values and display lists correctly on your Web Client?

There is a hidden fix for the 'read only' issue in the web client that involves modifying the ‘topaz.js’ file, which is located under the ‘\js’ directory in the Web-Tier folder structure (example: C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\webtier-7.11\js).

To fix the issue with ‘read-only’ fields not displaying values and display lists correctly on your Web Client, the following tasks must be done to resolve the issue.

1. Search for the following function

"function setComfillReadonly(field, sValue)"

in the topaz.js file.

You will see the following lines in this function:

if (dvdTrue(sValue))

{

field.style.display = "none";

field.style.visibility = "hidden";

fieldReadonly.style.display = "";

fieldReadonly.style.visibility = "";

2. After the line that executes:      fieldReadonly.style.visibility = "";

add the following line: fieldReadonly.value = field.value;

3. Then restart the Application Server (Tomcat, WAS, etc).

If your workflow is like most, you will more than likely have the necessity to ask questions at some point in the process.    Service Manager can make stopping a save process by interjecting user interaction a difficult process.

Since ServiceCenter 6.0 and the introduction of Service Manager, Javascript has been a great tool used to perform more complicated parts of system workflow and validations.  However, Javascript does still have some drawbacks.  Not all Javascript commands are available for use within Javascript.    Even though you may be able to write valid Javascript to call an interactive functions and/or RAD applications in Service Manager,  any interactive calls are likely to crash your Service Manager client application.  Because of this limitation, Javascript cannot be used to solicit user information in the validations on the format control.

There are many solutions to this.  Each solution has a number of pros and cons associated with it.  The key with any of the solutions is to intercept the save process prior to entering the normal processing.

Part I:  Surveying the Solutions

Create a Wizard

If your process requires more than a single piece of information collected from your user, or your process has information that needs to be presented with visual formatting, creating a wizard may be the best alternative.  Wizards may have one or more screens as well as a series of screens and information presented to the user.  Additionally, wizards have the capability to perform branching, requesting dynamic content and even presenting process around cancelling from a wizard.

Create Wizard HP SM (click for full size)

The screen shot above illustrates a set of out of the box wizards that can be used when a user rejects a change.  Wizards may view information from one or more files, run embedded code, Javascript and call formatctrl.  Wizards offer a great amount of flexibility for complex solutions.  However, this may not be the best choice for simpler needs.

Out Of Box RAD Applications

Service Manager features a number of RAD applications that can request information from a user and return that data to the application.

Each application has subtle differences in the functionality and returned data or values.  For our example, we are going to use the RAD application, object.yes.no to pose a question with a Yes or No reply to the user.

The object.yes.no takes several parameters:

• The first is the text parameter.  Text contains the data or prompt to be presented to the user.
• The boolean1 value identifies whether the cancel button will be available as an option.  Acceptable values for this are true or false.
• The prompt parameter contains the name of a Service Manager variable that will hold the response coming from this call.

RAD Object Yes/No (Click for full size)

The example above is being called from a Process record.  Object.yes.no will only be called if there is data to be presented to the user, which is contained in the Service Manager variable $question.  Since boolean1 is false, cancelling from this function is not an option.  Lastly, the users response will be returned from object.yes.no through the Service Manager variable $returncode.

Place a Temporary Field on the Form

In some situations where screen real estate is not an issue and where you do not want to annoy the user with extra screen pops every time they perform an action, a field can be placed on the form that can initiate additional code at save time or can even stop or abort the process.

Several examples are illustrated below.

Notify Owner can initiate notification processing when the ticket is saved.  The value behind the field can be a stored value in the database or can be provided as an interim transient value that disappears every time it is used.

Fields presented on tickets may have DEFAULT values, be required entry or may indicate optional workflow.  This field, when selected, would perform the additional workflow needed to complete and close the ticket.

Which Solution is best?

Each one of these solutions is equally valid and useful.  Which solution is best for your particular situation depends on your specific design and process needs.  Some things to think about when selecting a solution:

• Do you want to prevent the user from taking an action until data is collected?
• Do you want to respond to a users action?
• Do you want to perform additional processing when an action is selected?

Part II:  Where to Implement

Now that our process has directed us to one or more solutions, where does the solution get implemented in Service Manager to cause the least amount of disruption to the existing system?   Because of the interactive nature of  the data being requested, none of the calls below may be made through Javascript.   Some of the solutions below may be combined to implement the best solution.

Format Control

If the solution requires a response before an action is taken (add, update, close) and the solution utilizes values on the form, format control may be the best location.  Format Control can perform calculations on values, perform validation on a value or require additional validations dependent on data in other fields.

Format Control does not work well as a vehicle to conditionally prompt the user and alter workflow in the save process based on the user’s response.

Process

Service Manager Process records offer an excellent place to call conditional workflow.  A Process may execute its own expressions and Javascript and may call one or more RAD applications in a single Process.  These records offer excellent methods of gathering information and acting on the answers.  Processes may call RAD applications (object.yes.no) and/or may call wizards to perform additional processing.

Additionally, Processes may call other Processes and be linked together as required.  Inserting a line into the beginning or the middle of an existing process may prove irritating.  There is no insert command so each set of information below the insertion point would need to be moved by hand.  Or, the new Process may be added as an additional record that calls the existing one.  Be forewarned.  If you choose to place your Process in front of another process, all calls to the original process will also need to be adjusted and changed.

Another option for implementing as a Process is to implement the call to your Process as a callout from your displayoption.  Read on for how to deploy a Process via a Displayoption.

DisplayOption

Display Options are invoked when a user presses a button or other type of event in Service Manager (eg: save).  The display option may be self-contained or in turn execute a display action that invokes a Process.  However, the display option may also call a single RAD application to perform some processing prior to execution of outside instructions.  The result of any expressions or code executed as part of the display option may be used to alter the display action that is executed.

Display options may call any RAD application so it is also perfectly valid to invoke a wizard or interactive message box RAD application from here as well.  The screen below illustrates the calling of a process from within a display option.

Change Display Option (click for full size)

The example above shows a Change Display option that is calling a Process (my.message.functions) to request user interaction.  Once the Process is complete, control will be passed back to this display option.  If all has gone well, the intent it to execute the “save” display action in the upper right corner.

Save Display Option (click for full size)

On the post expressions tab, the variable $returncode that was set in our process is being checked.  If the user answered yes, the save is aborted by modifying our display action.

Putting It All Together

Now you have seen how different solutions and implementations may be used to assist in the deployment of interactivity in Service Manager.  A solution may not offer the desired results in every situation so it is beneficial to know multiple ways to deploy eloquent solutions.

NOTE: This document lays out, in depth, the inner workings of the Knowledge Module setup in Service Manager 7. The document covers how to perform a Full Reindex on your existing Knowledge Bases in the Service Manager system (as the process for this has been modified in the Service Manager 7 system). This document also explains all of the background items that are used to do this.

Pre discussion Notes:

• There is a table named “kmknowledgebaseupdates” in SM 7 that holds a record of all Knowledge Article updates and new Knowledge articles added (and will also temporarily hold new records that get added in when a Full Reindex is done – then these are deleted back out once the “KMUpdate” schedule record wakes up and fires the Javascript responsible for committing the KnowledgeBase indexes and deleting the records out in this table… See the discussions below for more details on this).
• What happens is when the “KMUpdate” schedule record goes in and re-indexes the knowledge articles, it goes into the records held in this table named “kmknowledgebaseupdates” (via the Javascripts that get invoked by his schedule record), indexes the knowledge articles referred to in these records, and removes these records from the “kmknowledgebaseupdates” table once that happens (This is all new in Service Manager 7).

Section I. Performing a Full Reindex of Your Knowledge Bases in Service Manager 7:

***With the above notes in Mind, this is how you would manually perform a one time, Full Re-index of any knowledgebase in the system***:

1.)    Go to the “Menu Navigation”  > “Knowledge Management” section on the Left Hand Side in the System Navigator and double click “Manage Updates”. Then click “Stop” on this form. This stops the “KMUpdate” schedule record from running (this is the record that indexes the knowledgebase articles automatically in the background).

2.)    Then! Go to the “kmknowledgebaseupdates” table in the database manager and remove (delete) any records there.

3.)    Go to the “Menu Navigation” > “Knowledge Management” section on the Left Hand Side in the System Navigator and double click “Manage Knowledgebases”. Do a Search and go to the Knowledge Base you want to full reindex (Make sure you do NOT have the Capability word named “AlwaysAdmin” in the operator record you are logging into the system with in order to have the Full Reindex Button not greyed out for these Knowledge Bases).

4.)    Click the “Full Reindex” button and the “Docs Returned” may say 0 actually, this is normal. ***What happens here then is the number of docs that are in this Knowledgebase will create the SAME NUMBER of records in the “kmknowledgebaseupdates” table à These then will need to be processed by the Javascript that gets fired by the “KMUpdate” schedule record that wakes up in step 5.).

5.)    Go Back to the “Manage Updates” screen (from step 1) and start back up the “KMUpdate” schedule record then (By clicking the “Start” button on this form). See Below now for additional notes on this:

Ok, so when you go to the “Manage Updates” section and click Start (this is if the “KMUpdate” schedule record needs to be restarted and it isn’t already up and running), you will see stats there about what is happening (Note – Clicking “Start” on this screen starts up the “KMUpdate” schedule record and this is how the knowledgebases are automatically reindexed in the background). You can click “Refresh” and see the knowledge docs that it is going through (NOTE!!! It will process ALL “kmknowledgebaseupdates” table records by indexing the knowledge articles referred to in these records and then deleting these records out of this table. It does this in 500 record increments until they are all processed > It looks to hang at 500 record increments > This is because if you go into the “kmknowledgebaseupdates” table and keep refreshing the record count, it is deleting these records slowly until it gets to the 500 it needs to delete and then the next 500 are processed till they are all gone).

NOTE! That this is the ONLY way to Fully Reindex your knowledgebases now in Service Manager 7… Steps 1.) – 5.) above have to be performed and then the KMUpdate sch record comes in and the Javascript it fires processes these “kmknowledgebaseupdates” table records and indexes the knowledge articles.

NOW! After this initial full re index discussed above in steps 1.) – 5.) is performed, only updates to existing knowledge articles and newly added knowledge articles will be stored in the “kmknowledgebaseupdates” table and then ONLY these records get processed by the “KMUpdate” schedule record – This is the case until another Full Re-Index of the Knowledgebase is performed by following steps 1.) – 5.) above.

LASTLY NOTE! The web services tier now (setup in the KM environment record à If this isn’t setup right in this environment record, it all fails), is responsible for using the WSDL (created by the “kmknowledgebaseupdates” “extaccess” table record à This record has the “delete” function here that is used by the system to delete out these “kmknowledgebaseupdates” table records once they have been indexed) to delete out the “kmknowledgebaseupdates” table records once they have been processed…

Section II. Sum It All Up:

So in sum, here’s how the “KMUpdate” schedule record works:

1.)    KMUpdate schedule record wakes up every 5 minutes and fires its Javascript.

2.)    The Javascript fired goes into the “kmknowledgebaseupdates” table and indexes EACH knowledge record that is referred to in each record in this table.

3.)    And at 500 record intervals, each of these “kmknowledgebaseupdates” table records is deleted out (via this web services tier used now – see the section below for a further discussion on this).

4.)    NOTE! If you want to perform a full reindex on any of your knowledgebases in SM 7… Perform steps 1.) – 5.) above in the beginning of this document and then let the “KMUpdate” sch record do the rest… This takes a while and you can monitor the progress of this in the “Manage Updates” link discussed above. You will be able to see the records in the “kmknowledgebaseupdates” table go down slowly as this processes happens (and only you will see this happening when the “Manage Updates” window appears that is has stuck at 500 record increments). After EACH run of this sch record, the “kmknowledgebaseupdates” table should have no records in it or something wrong has happened… FYI

Section III. Further Notes and KM Environment Record Setup:

Further Notes About the Above:

1.)    Now! Web Services in Service Manager 7 is responsible for the deletion of the “kmknowledgebaseupdates” table records in the process explained above (so these records are deleted out of this table once the knowledge articles have been indexed). This is why the user and port number has to be correct for this web services piece on the KM environment record (see screenshot below on the KM environment record in a mock system). The user specified in the environment record below must have web services access by having the “SOAPAPI” capability word. The port number (13081 in the screenshot below) will be pointed at a servlet that should be started up just for the web services connection (If a Load Balancer is setup, extra steps will have to be taken to not have any other traffic directed to that servlet that has been started for this web services connection à There are ini file params for starting up this separate servlet that are not noted here)!

2.)    In the discussion above in Section I, it explains the form that you will see when going to “Manage Updates”. When you click the “Refresh” button on this thing, it will get to increments of 500 records and look to stop temporarily and hang à That’s because at the 500 mark, the process “Commits to the Search Engine and writes the indexes for these knowledge articles” and these 500 are then removed at this point from the “kmknowledgebaseupdates” table and you can see the number of records going down in this table if you go to the records in that table and keep refreshing the Search and count (and again note that the Web Services Connection is for just this deletion of these records once the knowledge articles have been indexed).

3.)    Note! There is a record out there in the “extaccess” table (name: kmknowledgebaseupdates) that should have a delete call in it à This is how the WSDL is constructed that the Knowledge Process uses to delete records out of the “kmknowledgebaseupdates” table when the time comes to do this in the process.

Example of a correctly setup Environment Record For SM 7 Knowledge Management:

SM 7 Knowledge Management Environment Record (click for large size)

In Service Manager, have you ever run into a need to make your “User Selections” on your Service Catalog Items actually useable? The article content below will lay out an overview of Service Catalog Item “User Selections” and how you can use Javascript to make good use out these user selections.

“User Selections” on the Service Catalog Item. What are they? Simply put, in Service Manager, if you use the Service Catalog to allow your end users to request certain items, they have the ability to fill out a small set of fields that will contain information concerning the Service Catalog Item they are requesting. These fields that contain this user driven information are known as the Service Catalog’s “User Selections.”

So what? What do these “User Selections” have to do with me and my Service Manager System you might ask? Well, we as Service Manager programmers have the ability to code our Service Catalog Items to easily open Request records (of specific Request Categories) in order to procure these Service Catalog Item Requests made by our end users. So, simply speaking, we can open Request Tickets for our end user Service Catalog Item Requests that will carry the info they provide to us in these “User Selections.”

Now for the fun part! If you have used Service Catalog before, then you already know the ease with which you can setup these Service Catalog Items and make them available to your end users for requesting. However, with this ease comes a few issues. Sure, we can setup our “User Selections” for these Service Catalog items with ease, but with this comes the sheer fact that you cannot report on these “User Selections,” you cannot kick these “Users Selections” back to your infrastructure support teams on emails, and generally, these “User Selections” will exist in a virtual vacuum of sorts in that they are confined to the Request record (or whatever record you are using to procure your service catalog requests) in which they reside.

Well, there is a solution to this problem! With the use of Javascript we can take any of these fields from the “User Selections” and place them into actual fields on the record you are using to procure your Service Catalog Item requests. See the technical section below for information on how to do this inside of Service Manager.

Now for the technical part:

If, for example, you are using Request (ocmq) records to procure your Service Catalog Item Requests, you already know that the “User Selections” are all held in one field on the Request (ocmq) record named “svc.options.” This field holds these “User Selections” in an xml based format so that, when placed inside the context of a dynamic form on the request record, the user selections can be properly displayed to the user viewing the record. That’s nice, however, this does not allow us to have access to those “User Selections” for reporting, email reporting etc. (unless you want to kick back the nasty svc.options field to your users on reports and emails! But nobody wants to do that!).

So, below is an example of a block of Javascript that can be used to go into any part of this “svc.options” field to grab out a field value and place that value into any existing field on the ocmq record. Please note, for this specific example, that the content in the svc.options field on the actual ocmq record is as follows (and also note that this is a real life example of the svc.options field belonging to an ocmq record that was opened from a Service Catalog Item Request that held “User Selections”. Those “User Selections,” in this example, are held in the svc.options field inside of the ocmq record seen below):

>d svc.options in $L.file
<form><text id="vwdateneeded" label="Date and Time of Termination :*">4-4-09 1:30 PM</text><select id="vwpriority" label="Priority :*" style="combo">Emergency<option label="" /><option id="0" label="Standard">Standard</option><option id="1" label="Emergency">Emergency</option></select><select id="vwemployeetype" label="Employee Type :*" style="combo">Permanent<option label="" /><option id="0" label="Permanent">Permanent</option><option id="1" label="Temporary">Temporary</option><option id="2" label="Consultant">Consultant</option></select><text id="vwreportsto" label="Reports To :*">Test Manager</text><select id="vwtypeoftetermination" label="Type of Termination :*" style="combo">VCI Termination<option label="" /><option id="0" label="VCI Termination">VCI Termination</option><option id="1" label="Transfer Out Of VCI Domain">Transfer Out Of VCI Domain</option></select><text id="vwmycomments" label="Comments *:" multiline="true">This is a Test &#xD;
This is a Test&#xD;
This is a Test</text></form>

***Editorial note – the line above needs to stay formatted as displayed for this to work correctly. Unfortunately the line above does not wrap and is displayed under part of the content bars on the right. If you would like to receive the full code for this particular item please email lwalker@stratacominc.com.

As you can see, this is an ugly field value to say the least! So, the below javascript is an example of how we can pull out a value in one of these “User Selections” and place it into an actual field on the ocmq record (and then we will have access to report on this field and kick it back to our users in emails as well!). Please note that you would place this block of Javascript below into the next available Javascript box in the actual Javascript section of the “ocmq” format control (Add and Update Conditions for this specific example are: category in $file=”sarterm”). This means that when an ocmq record is opened or updated and has a value of “sarterm” in the actual “category” field, this Javascript will fire on add and update. Again, this is just for our example here, but this Javascript can be applied (with modification of course to point to the right area in the svc.options field) to any instance where a User Selection must be dragged out and placed into a field on the record. Now for the script:

//Begin Script

//Grab the current ocmq File
var file = system.vars.$file;

//Grab the svc.options field out of the ocmq record
var holdSvcOptions = file.svc_options;

//Use Basic String Functions in Javascript to Grab out the String for
//the vwreportsto field user selection.
var positionofManager = holdSvcOptions.indexOf('vwreportsto');

var grabManagerCutUp = holdSvcOptions.substring(positionofManager);

var grabManGreaterThanSymbolPos = grabManagerCutUp.indexOf('>');

var grabManCutUpFurther = grabManagerCutUp.substring(grabManGreaterThanSymbolPos);

var grabManLessThanSymbolPos = grabManCutUpFurther.indexOf('<');

var myManager = grabManCutUpFurther.substring(1,grabManLessThanSymbolPos);

//Place that String into our actual manager field on the ocmq record
file.manager = myManager;

//End Script

In Summary, you can see above that we are keying off of the value that is in the “vwreportsto” “User Selection” (inside of the svc.options field on the ocmq record) and we are dragging that value out (via basic string manipulation functions in Javascript) and placing that value into the actual “manager” field on the ocmq record (the last line in the javascript does this). So this means, for our example, that when our end user goes and requests a Service Catalog Item that opens a Request (ocmq) record of category “sarterm”, this block of code will fire on Add and Update to pull the correct “User Selection” out and place it into an actual field on the ocmq record.

***Now, what if we want to drag out the contents of a multi text field from our User Selections and place that into an array field on our ocmq record? Below is a Block of Code that will extract the contents of a multi text User Selection from the same “svc.options” field shown above and place that into an array field on the ocmq record. Please again note that you would place this block of Javascript below into the next available Javascript box in the actual Javascript section of the ocmq format control (Add and Update Conditions for this example are: category in $file=”sarterm”). Please also note that the section of that svc.options field (from above) we will be referring to in this block of Javascript code is:

…></select><text id="vwmycomments" label="Comments *:" multiline="true">This is a Test &#xD;
This is a Test&#xD;
This is a Test</text></form>

And now the Javascript is below. Again, the Javascript will pull out the multi text user selection field value (for the field named “vwmycomments”) and place that value into an array field named “description” on the actual ocmq record. Note the use of the Javascript based “split()” function as this takes the contents of the multi text user selection and packages it into a useable array that can then be placed into the “description” field on the ocmq record:

//Begin Script

//Grab the current ocmq File
var file = system.vars.$file;

//Grab the svc.options field out of the ocmq record
var holdSvcOptions = file.svc_options;

//Use Basic String Functions in Javascript to Grab out the Value for
//the multitext vwmycomments field user selection.
var positionofDesc = holdSvcOptions.indexOf('vwmycomments');

var grabDescCutUp = holdSvcOptions.substring(positionofDesc);

var grabDescGreaterThanSymbolPos = grabDescCutUp.indexOf('>');

var grabDescCutUpFurther = grabDescCutUp.substring(grabDescGreaterThanSymbolPos);

var grabDescLessThanSymbolPos = grabDescCutUpFurther.indexOf('<');

var myDesc = grabDescCutUpFurther.substring(1,grabDescLessThanSymbolPos);

//Take the multi text value you just grabbed and package it into an //array
var x = myDesc.split("&#xD;");
//Place that array into the description field on the ocmq record.
file.description = x;

//End Script

Please again note that, for this example, if an End User Selects a Service Catalog Item that fires a Request (ocmq) record of category “sarterm” then this block of code will fire and the contents of the User Selection we choose in this code (in this case it’s the contents of the user selection named “vwmycomments”) will be placed in the actual ocmq field we choose as well (in this case we place this info into the “description” field on the ocmq record).

How are these two blocks of Javascript code from above helpful? The answer is simple in that we are able to extract the “User Selections” we choose form the “svc.options” field and place these values into actual fields on the ocmq record (or whatever record you are using to procure you Service Catalog Item Requests). This allows us to then report on these fields, kick these fields back to users on emails, and generally have full availability to these fields at all times.

The Notification Engine is primarily responsible for sending messages that are generated by HP ServiceCenter and Service Manager events, such as opening or closing a change or task. Administrators can edit these messages, add new messages, change the conditions that trigger the messages, and select who will receive the messages.

The foundation for the Notification Engine is strong and robust, allowing many different types of notifications to be generated.   The Notification file stores the definitions of the who, what, where, when and how of the notifications.  This file works in conjunction with the message file to define headers for common system events. Arguments are passed to the pre-defined messages and substituted allowing for unique subject lines for each message. 

Out of the box, ServiceCenter/Service Manager is configured to send notifications at all of the touch points of the record lifecycle.  There are notifications for Open, Update and Close.  Additionally Change notifications include many notifications for Approval workflow.  These base notifications are called from the Object record for the file you are working on.

In addition to the base ServiceCenter notifications, notifications may be automatically generated from other triggers, such as the addition of an activity record or by custom methods or scripts and calling the notification engine directly.  This allows for an endless number of notifications to be generated.

ServiceCenter has provided very robust and in-depth tools to produce Alerts and Notifications to users based on system events.  Alerts allow an organization to define known conditions, which could automatically produce some action on the ticket, such as escalating the ticket, changing the severity, notifications, etc.

The ServiceCenter Alert Definitions, Schedule and Notification files all work together to produce output for the Alerts.  Frequent usage of the Alerts includes:

• Notifications for SLA breaches
• Notification of pending Approvals
• Notifications of Past Due tickets
• Notifications of Stale Tickets

While many of the frequent uses for Alerts include notifications, those are far from the only uses for Alerts.  Alerts can be used to update information on a ticket or execute processes.

Each ticket type provides for an alert status field, which can be updated when the alert is triggered.  This status identifies the next time that a specific alert may need to be evaluated or acted upon.  Alerts run at the time when a ticket is saved and evaluates the schedule.condition against the current record.  If a match is made, the Calculation fields on the scheduling tab are used to set the expiration (Alert Time) on the schedule record that will be created.  The name used for the Alert will be the name on the scheduled event. 

Recommendation:  Use very clear names for your Alerts so that Administrators will know what they are looking at when troubleshooting Alerts in the schedule file.

The Calculations for Alert times allow you to schedule an alert to happen based on a specific time in the ticket or a calculated time (such as one business day prior to the implementation time).  Each alert can use a different calendar based on different needs.  Some alerts may use a 24 X 7 calendar while others may use an 8 X 5 calendar. 

The update Information tab allows you to specify notifications that will run and/or special processes to change the existing data in the ticket.  Triggers can be turned off for these updates in order to prevent potential circular processes.  From here, one or more notifications can be kicked off.

Recommendation:  In order to be able to trace system Alerts and Notifications end to end, it is a good idea to use clear and systematic names for your notifications.

There is an Alert tab on the Object record.  This allows for specification of a top level Alert that will run for that specific notification type.  Additionally, the Change module provides Alert panels in each Change and each Task phase to set off Alerts based on specific conditions.

The best first step is to define and map out on paper exactly what you think your organization needs.  Remember that any tool should always support your process.  When should a ticket be escalated?  Who needs to be notified?  When do they need to be notified?  What information is necessary for that step?   While you may feel the need to notify everyone for all items, be conservative about notifying users in your organization.  Excessive notifications will result in users ignoring or deleting them. 

The Alerts in ServiceCenter are extremely powerful when defined and executed well.    When they are not set up correctly, they can have disastrous consequences.  The challenge can be in defining the notifications in a clear and concise manner.    Start small with one Alert and test it end to end.  Once you have nailed exactly what you want, continue to create the additional alerts that are required.

Your success with the web client may vary based on the design of your application.  The design suggestions below are excellent suggestions, no matter what platform you are on.  Some though, are more critical to the web.

Make SURE to use field aliases

Any time you plan to have more than one field on your form with the same input, make sure to use field aliases.  Putting the same field on the form twice may result in unpredictable results. 

Avoid the usage of complex dynamic fields on your form

• Some advanced methods of swapping contents of global variables during form display may not function as desired in the web.
  • SOLUTION – Use conditional display to display one of two fields (with different global lists) based on the needed field
• Dynamic drop-down dynamic fields based on other fields on the form may function unpredictably on the web.
  • SOLUTION – Utilize links for overly complex dynamic field lookups.  The link expressions can be calculated successfully.  That will provide much better results

 Use a form width of 176

Specify the “magic” width size on your form of 176.  This will ensure that the ServiceCenter forms will expand to their full window size.  Although this may be confusing, you are not limited to fields to 176 using this method.  You can design elements beyond that position and the fields will display perfectly.   If, however, you specify a different form width, the form may not display properly based on the width of your window. 

Keep your QBE forms to a minimum number of fields.

Specifying large fields or many fields on your QBE forms will not display nicely to the client.  On the desktop client, a QBE with a description field will take up one vertical line.  On the web, it will expand to show the full contents of the field.  Also, while on the desktop client, you can scroll left to right, that functionality is limited on the web. 

Use Javascript for overly complex expressions

When you need to perform many actions (or have overly complex expressions) used to determine the display of a field or whether the user is an approver, choose to use Javascript over Service Manager expressions.  You have far more flexibility and can simplify expressions using this method. 

Make sure your home menu for the web clients contains visible and usable options

If you have no visible fields on your main (home) menu form, Service Manager will hang when entering tickets. 

Use folders to organize your favorites

Adding all your favorites into the main folder is ok when you have a few items.  If your system has dozens or hundreds of favorites, your users must scroll through many items before finding those few favorites that pertain to them. 

Take time to organize your favorites into folders.  Use separate folders for Incidents or Interactions.  Also, take variations on the same favorite and combine them into their own folder.  

Use top level folders so that the user always has access to his or her favorites on the first displayed screen. 

Keep forms to a maximum height

Using excessive heights will cause your users to have to scroll to see all the fields on your form. 

Whenever designing a Service Manager solution that will be used on the web as well as on the Desktop client, make sure to test equally on both clients.  Just because your functionality works on the desktop client does not guarantee that it will work on the web.

ESS (Employee Self Service) in ServiceCenter provides a functionally slimmed down version of the full web client.  The ESS web client is designed to give the ESS users a way of opening tickets to the Service Desk and checking the status on those tickets.     Several situations were noted where the ESS client was not behaving correctly.  These resulted in a client crash or other internal failure in ESS. 

Examples of the bad behavior include:

• The ESS mail URL (for an ESS client) does not work as expected
• Record lists with one record in the open or closed records causes the ESS client to crash.

 In our affected system, the “New Thread: -> List” option in the Service Desk profile record was enabled for the ESS profile.  Since the ESS client does not support threading, this option causes the ESS client to behave with unpredictable results.  By turning this option off, we were able to resolve both of the issues above.  It should be noted that these are just a few examples of the behavior exhibited in one example.    Other errors in ESS could also potentially be connected to this same issue.