Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Creating a Worker or Role-Based Incident Watch List in Helpdesk

Created: 23 Jun 2011 • Updated: 07 Aug 2012
Language Translations
kevinradler's picture
0 0 Votes
Login to vote

 1.0 Creating a Worker or Role-Based Incident Watch List in Helpdesk

The purpose of this tutorial is to guide you through the creation of a Helpdesk mechanism allowing Altiris workers, arranged according to class or job role, to create incident watch lists. In turn, then, these watched tickets can be queried against and displayed in reports and web parts and on worker portals.

1. 1 The Justification for a Watch List

Why create a way to watch tickets in Altiris? At my company, the Service Desk roles are broken down into three distinct categories: Level-1 technicians, Level-2 field technicians, and Level-3 incident coordinators. Keep in mind these roles do not represent an exhaustive list of service tiers. Instead, they are internal to the Service Desk (Tier-1) component itself.

The Level-3 incident coordinator is charged with managing higher priority incidents from creation to closure. This activity involves coordinating Tier-2 support (i.e., those departments external to the Service Desk, like the networking, server, and telecom teams) and Tier-3 support (i.e., external vendors). To better facilitate this job role, I wanted to provide the Level-3 incident coordinators with the ability to tag higher priority incidents for follow up. Currently, ticket numbers are being maintained on a physical and virtual notepad.

1.2 Assumptions

The author of this tutorial makes the following assumptions:

1.    You have administrative rights to Altiris and can create new and edit existing administrative tasks.

2.    You have a specific worker, job role, or group of individuals in mind to whom you wish to offer this tool to.

1.3 Delimitations

The author of this tutorial states the following delimitations:

1.    The purging of watch list attributes is handled through a separate scheduled task and process, and is out of scope for this tutorial.

2.    This tutorial was written in the context of Altiris Helpdesk 6.9 R11 with console versions 6.0.6074 and 6.5.

3.    The author has roughly 6 months of experience with the current Altiris environment.

4.    This tutorial does not require Helpdesk console or database modifications. Instead, it uses pre-existing functionality built into the product.

5.    This tutorial does not describe how to create a web part from a report, or how to load the web part into a report portal.

2.0 Preliminary Concepts

This section briefly outlines the preliminary concepts one must understand as he progresses through this tutorial. These concepts include auxiliary data assignments and administrative tasks.

2.1 Auxiliary Data Assignment and Administrative Tasks

Every ticket in Altiris has a basic set of attributes, which typically include a unique identification number, title, creation and modification dates, worker and ownership assignments, et cetera. Tickets, however, can be assigned other unique attributes that can be as unique as your business. These attributes can be assigned to a ticket’s auxiliary data field. This data field stores information in an XML string, and by default, at least in our environment, is built with the following values:

Figure 2.1: ‘auxdata’ SQL Properties

You can edit the data in this field in two ways:

1.    Edit the data in the database directly (not recommended)

2.    Enable the pre-built administrative task that enables the ability to edit the auxiliary data from the ticket itself

2.1.1 Edit the Database Directly

The author did not incorporate this method into his solution. As such, database modifications are out of scope for this tutorial.

2.1.2 Enable the Pre-Built Administrative Task

In our environment, most of the pre-built administrative tasks—and I say pre-built because they were built prior to me inheriting the application—were disabled. For the purpose of this tutorial we are concerned with the “Edit incident’s aux data” administrative task, which can be found on the Incidents tab > Admin > Tasks > List Tasks.

Figure 2.2: Administrative Tasks

By activating the Edit incident’s aux data administrative task, you can now add and edit auxiliary information from any ticket directly. This option now shows up under the Tasks section of the ticket.

Figure 2.3: Task Location

The auxiliary data edit menu looks like following, and by default, will include information pertaining to the Helpdesk satisfaction survey. We do not use the survey feature of Helpdesk, so it is out of scope for this tutorial.

Figure 2.4: Auxiliary Data Edit Menu

As stated prior, an incident’s auxiliary data is stored in an XML string. More specifically, it is stored in the following format:

<member>

         <name></name>

         <value></value>

</member>

 And so in the context of the satisfaction survey auxiliary data, the XML string is stored in the database as follows:

Figure 2.5: Database View of Auxiliary Data

Knowing now that we can manipulate this field to include any optional characteristics we want, this is the root solution for creating our watch list. Keeping this administrative task activated is not necessary, nor recommended, to build out the watch list featureset. Instead, I am merely showing you the option exists, and stating that it is a good tool for validating if your auxiliary data assignments are functioning as expected. I do not recommend you leaving it activated unless you choose to lock it down for use by specific individuals.

3.0 Building the Watch List

This section covers the necessary steps for the building the watch list functionality into Helpdesk. The process involves the addition of two new administrative tasks, one to add the ticket to the watch list and another to remove it.

3.1 ‘Add Incident to Watch List’ Task

The first task we are going to build will be invoked by the Altiris worker to add the ticket to the watch list. Add the new administrative task by going to the Incidents tab > Admin > Tasks > New Task.The table below highlights the values to enter into the new task form.

Table 3.1: Add Incident to Watch List Task Values

Field

Value

Name

Add Incident to Watch List

(You can add anything here you want)

Consumer ID

Helpdesk

Comment

(Write a brief description about what the task is meant to do)

Rank

5

Log to incident

(unselected)

Save the raw text of the response in the incident

(unselected)

Active – task is available on applicable incidents

(selected)

Task is available

When ALL of these are TRUE:

     “CURRENT_WORKER(worker_id)” is one of “123, 456, 789”

     “Auxiliary data (icWatchList, isWatched)” is not one of “1”

     “Status” is not equal to “Closed”

<end>

When criteria are true

Create or edit an incident

Helpdesk

http://<your_server_name_here>

Edit current incident

(selected)

Set these properties

Set “Comment” to “Incident added to IC Watch List by CURRENT_WORKER(worker_name)”

Set “Auxiliary data (icWatchList, isWatched)” to “1”

Credentials

Impersonate the worker

When this task runs

Commit the incident and display the View Incident page

Once you have finished updating the form, click “OK” to save the task.

3.1.1 Explanation of Values

Most the values are self-explanatory; however, this section will briefly describe what some of the more advanced settings are accomplishing.

Task is available:

1.    “CURRENT_WORKER(worker_id)” is one of “123, 456, 789”

2.    This is allowing us to lock this administrative task down by worker id. That way only the appropriate people—in this case based on id number—will be able to initiate the task process. In the example above, workers with id numbers 123, 456, and 789 will all have access to this task, and for everyone else, they will not even see the option in their incident task list.

3.    “Auxiliary data (icWatchList, isWatched)” is not one of “1”

4.    This is performing a check against our watch list auxiliary data variables to see if it has already been set. When it has not been set, the option to add the incident to the watch list will be displayed. Conversely, when the value has been set (e.g., a value of 1 implies active, enabled, yes, et cetera) the option to remove the incident from the watch list will be displayed.

5.    “Status” is not equal to “Closed”

6.    For business purposes, we did not find a need to add closed tickets to a watch list, so the task will not be enabled if the ticket is already closed.

Set these properties:

1.    Set “Comment” to “Incident added to IC Watch List by CURRENT_WORKER(worker_name)”

2.    For business purposes, we wanted to update the incident comment to represent the fact that the Level-3 incident coordinator was watching the ticket. You can add in any comment you so choose or remove the comment altogether.

3.    Set “Auxiliary data (icWatchList, isWatched)” to “1”

4.    This statement is responsible for actually setting the attribute to 1, representing active, enabled, on, et cetera, within the incident’s auxiliary data field.

3.2 “Remove Incident From Watch List” Task

Conversely, we want the worker to be able to remove the incident from the watch list. To do this, we will build a second administrative task that will set the attribute to 0, representing an off or inactive state. The table below highlights the values to enter into the new task form.

Table 3.2: Remove Incident from Watch List Task Values

Field

Value

Name

Remove Incident from Watch List

(You can add anything here you want)

Consumer ID

Helpdesk

Comment

(Write a brief description about what the task is meant to do)

Rank

6

Log to incident

(unselected)

Save the raw text of the response in the incident

(unselected)

Active – task is available on applicable incidents

(selected)

Task is available

When ALL of these are TRUE:

     “CURRENT_WORKER(worker_id)” is one of “123, 456, 789”

     “Auxiliary data (icWatchList, isWatched)” is equal to “1”

<end>

When criteria are true

Create or edit an incident

Helpdesk

http://<your_server_name_here>

Edit current incident

(selected)

Set these properties

Set “Comment” to “Incident removed from IC Watch List by CURRENT_WORKER(worker_name)”

Set “Auxiliary data (icWatchList, isWatched)” to “0”

Credentials

Impersonate the worker

When this task runs

Commit the incident and display the View Incident page

 Once you have finished updating the form, click “OK” to save the task.

3.2.1 Explanation of Values

Most the values are self-explanatory and are similar to the previous administrative task we created; however, this section will briefly describe what some of the more advanced settings are accomplishing.

Task is available:

1.    “CURRENT_WORKER(worker_id)” is one of “123, 456, 789”

2.    Again, this is restricting access to this administrative task to a small set of workers based on their worker id number.

3.    “Auxiliary data (icWatchList, is Watched)” is equal to “1”

4.    Validation to see if the isWatched variable is set to an ON state.

Note: In the remove task I am not concerned with the status of the incident. If the incident was previously added to the watch list, I want to give the worker the ability to remove it from the watch list regardless of the state of the incident.

Set these properties:

1.    Set “Comment” to “Incident removed from IC Watch List by CURRENT_WORKER(worker_name)”

2.    Like before, update the incident comment to reflect the change of being removed from the watch list.

3.    Set “Auxiliary data (icWatchList, isWatched)” to “0”

4.    Set the status of the isWatched value to 0, representing an off or inactive state.

3.3 Summary

In this section we created two new administrative tasks, one to add the incident to the watch list and the other to remove the incident from the watch list. Both tasks are set up to modify the auxiliary data of the incident to reflect a 0 or 1 status—representing active and inactive—which we will use later on to determine what gets included on the watch list report.

When active, these new tasks will be displayed under the Tasks section of a ticket (see Figure 2.3 above).

4.0 Reporting on Auxiliary Data

This section addresses how to report on values that are assigned to an incident’s auxiliary data field. More specifically, we will look at using SQL to extract the XML data string for our variable where we will then interpret the value for inclusion or exclusion in our report.

4.1 Creating the Watch List Report

In our case we only want to include those incidents with an isWatched value of 1 in our report. The SQL statement below is what I used to interpret the auxiliary data field. I just copied and pasted this statement directly into the report builder.

Table 4.1: Auxiliary Data Validation

SELECT    

                wcv.workitem_number AS 'Id',    

                wcv.workitem_title AS 'Title',    

                wcv.workitem_priority_lookup_value AS 'Priority',    

                wcv.workitem_status_lookup_value AS 'Status',    

                wcv.workitem_assigned_to_worker_id AS 'Assigned To Id',    

                wcv.assigned_to_worker_full_name AS 'Assigned To Name',    

                wcv.modified_by_worker_full_name AS 'Last Modified By'

FROM    

                Incidents.workitem_current_view wcv    

WHERE    

             wcv.workitem_status_lookup_value NOT IN ('Closed') AND 

             CAST(wcv.workitem_auxdata as xml).value ('(/AuxDataDataSet/icWatchList/value) [1]',

             'tinyint') = 1   

 The line we are most interested in here is the one that reads:

CAST(wcv.workitem_auxdata as xml).value ('(/AuxDataDataSet/icWatchList/value) [1]', 'tinyint') = 1

This line extracts the value from our XML member class and interprets the value. Any record with an active isWatched value (e.g., 1) will be included in the report. I also want to filter out any incident that is closed, and I use a standard status filter to accomplish this.

5.0 Closing Thoughts

There are some things to keep in mind when using this method. First, you probably do not want to go wild by adding tons of extra information into the auxiliary data field. The field is, by default, limited to 256 characters. Second, this option really adds great functionality to Helpdesk without having to perform modifications to the database and console; however, if you find that you would like to add more customized data to your incidents, I would recommend adding customized data fields to Altiris directly (i.e., customized incident statuses or location fields). That way the options can be used by potentially everyone in your organization.

This solution was really designed for a specific role, and as such it has a very narrow scope. I could imagine things could get pretty ugly with having everyone using the auxiliary data field for their own purposes.