/build/static/layout/Breadcrumb_cap_w.png

How to implement a simple father/child relationship between K1000 Service Desk tickets without using processes: an idea...

Some weeks ago a customer asked me how to manage 'major incidents' with KACE Service Desk.

For major incident they intend an incident that is the root cause of other incidents. For example the SMTP server goes down and this is related to a lot of tickets that the users are logging about email problems.

The problem is how to put them in relation (sort of father child relation) after the tickets are created. The other requirement was to avoid the usage of processes

I then had this simple idea on how to implement it. Maybe this is not the best way to do it and some aspect of this implementation need to be tested and enhanced but I think this can represent a good starting point.

The idea is to add a check box that the queue owner will use to mark an ticket as 'major incident' and a single select field that the queue owner can set to refer a ticket to a major incident.

The last part step is to close all the tickets that are referring to a major incident after it is closed.

These are the steps I followed.

1-Modify the queue layout to add the two fields. In this example I used the fields CUSTOM_1 and CUSTOM_2 

Ticket Layout section:

Custom Fields section:

For the selected values I used this simple query:

query:SELECT ID FROM ORG1.HD_TICKET WHERE CUSTOM_FIELD_VALUE0 = 1

So I populate the dropdown single select only with tickets that are marked as major incident

2-Now we need a way to close the tickets associated to the major incident if the major incident is closed

To achieve this result I create a simple custom ticket rule that is executed ever hour. For sure there were much better and complex ways to do achieve the same result but I had in mind the simplicity when I created it. 

The select query of the ticket is the following:

SELECT A.ID
FROM
    ORG1.HD_TICKET AS A,
    ORG1.HD_TICKET AS B
WHERE
    A.CUSTOM_FIELD_VALUE0 != 1 /* The ticket is not marked as major incident */
    AND A.CUSTOM_FIELD_VALUE1 != '' /* The ticket is related with a major incident */
    AND A.CUSTOM_FIELD_VALUE1 = B.ID /*The ticket is related with a specific major incident */
    AND B.HD_STATUS_ID = 2 /* The major incident is closed */

The update query is the following:

UPDATE ORG1.HD_TICKET
SET HD_STATUS_ID = 2 /*Set the status to closed */
WHERE HD_TICKET.ID in (<TICKET_IDS>)

I checked the "Results are tickets, add a comment to each one" and I added a comment to warn the submitter why the ticket was closed.

Things to improve:

  • The single select drop down should be able to select from currently open major incidents (but sometimes may even be useful to associate tickets to major incidents already resolved)
  • If you have multiple queues you may want to add some logic to act only on a specific queue

Caveats:

  • I do not guarantee that this implementation is fully working...it is only an idea that can be developed and improved
  • Custom ticket rules are very powerful & potentially dangerous if they are wrong so they need to be tested well and adapted to your environment...test them well before to activate them!!

 


Comments

  • This is an interesting idea and I think it would work well. My first question is whether your queue is configured to email the submitter the comment that would be added to the ticket. In our environment not all queues email the submitter comments so we would need to add a resolution to the ticket.

    Good post. - chucksteel 10 years ago
    • I need to make more tests but when a ticket is going to be closed the submitter should receive an email automatically.
      I used the "Results are tickets, add a comment to each one" option in the rule to add a comment so this should trigger another email as well..
      Thanks for the comments! - StockTrader 10 years ago
  • I always tell people kace is what you make it. Nicely done! - Jbr32 10 years ago
  • I may be missing something but this seems very similar to the parent/child relationship already built into the ticket system.

    Our Help Desk Queue is configured to allow Parent tickets, owners can check a box that allows a ticket to be a Parent and then we can assign other tickets as children to the Parent ticket. When the Parent Ticket is closed you have the option to close all child tickets and provide a generic comment for all the child tickets.

    More information in the Administrator Guide > Service Desk Administrator Guide > Customizing Service Desk Ticket Systems > Setting up Parent/child ticket relationships - jfields 10 years ago
    • Hello,
      you're right. This is really similar but this was a proof of concept.
      You can extend it do be able to implement a father/child relationship on tickets of different queues if you like.
      Kind regards,
      Marco - StockTrader - StockTrader 10 years ago
This post is locked

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ