K1000 Service Desk Emails to End Users... Is there a way to dress them up?
As usual, we're constantly getting feedback about how our helpdesk system is awesome/horrible depending on what end users show up for staff meetings. One of the last things that was brought to our attention was that some end users think all the emails they get from the service desk are automated, and by automated they mean that it doesn't contain any information useful to them. This is a problem because we'll post comments and questions trying to get more information about the problem or help them through it and they're not reading any of it.
My boss just approached me and asked if there's a way we can cut the "fluff" such as field changes out of the emails sent to end users in order to make it less distracting for them. His first request was to have bold red text that would stand out for them. When I told him that probably wasn't going to be possible without pro support, he asked instead that when we comment or post resolution that they only see the text that we've placed in those fields. Any ideas or tips would be greatly appreciated. Thank you!
Answers (3)
You can definately change the verbal in emails that go outbound from the queue section for custom emails. You can then also create and write your own emails based on custom ticket rules. With those ticket rules you can add any information you like from the ticke that you feel would be informative to the end user.
Then there are all the check boxes on Email on Events based on what outbound notification you want.
Making it red might not be doable as we are sendint text based, not html. There is the uservoice forum you can vote on this and then you could put the font a color if you know html.
http://kace.uservoice.com/forums/82699-k1000/suggestions/2739340-outbound-html-emails-from-sd
"he asked instead that when we comment or post resolution that they only see the text that we've placed in those fields. Any ideas or tips would be greatly appreciated. Thank you!"
This could be something you should be able to use the comment check box so when you do make a comment it goes out to everyone with the comment checkbox (submitter, approval, ticket/category cc). If you are familier with ticket rules you could do that instead and would make it more custom.
Are you using the system email rules or custom rules for sending notifications to users? I have found that using system rules gives me much more flexibility with what we send to the user and we don't use any of the system rules anymore.
Comments:
-
You mean using custom rules gives you more flexibility, right? I totally agree. - lmland 11 years ago
-
Right... now I just have to learn how to write them :) I placed a ticket with KACE support parallel to this thread. If I get some good examples from support I'll be sharing them here for everyone else's benefit. - GeekSoldier 11 years ago
After speaking with KACE support, we narrowed down what I'm ultimately looking for. We need a ticket rule that will generate an email to the submitter when a comment is posted. The official answer is that it will take KACE pro services. The unofficial answer is that someone well versed in writing ticket rules could jam this out in no time. Question is, is the ITNinja community up to the challenge!?
Comments:
-
Here's the select statement used for one of our queues:
select HD_TICKET.ID,
HD_TICKET.ID as TICKNUM,
HD_TICKET.TITLE,
U1.USER_NAME as OWNER_NAME,
U3.USER_NAME as LASTINPUTNAME,
DATE_FORMAT(HD_TICKET.CREATED,'%b %d %Y %I:%i:%s %p') as CREATED,
DATE_FORMAT(HD_TICKET.MODIFIED,'%b %d %Y %I:%i:%s %p') as MODIFIED,
HD_STATUS.NAME AS STATUS_NAME,
HD_STATUS.ORDINAL as STATUS_ORDINAL,
STATE,
U1.FULL_NAME as OWNER_FULLNAME,
U1.EMAIL as OWNER_EMAIL,
U2.USER_NAME as SUBMITTER_NAME,
U2.FULL_NAME as SUBMITTER_FULLNAME,
U2.EMAIL as SUBMITTER_EMAIL,
U3.EMAIL as UPDATEREMAIL,
U3.FULL_NAME as UPDATERNAME,
UNIX_TIMESTAMP(TICKETCHANGE.TIMESTAMP),
TICKETCHANGE.COMMENT as COMMENT,
TICKETINITIAL.COMMENT as INITIAL_COMMENT,
TICKETCHANGE.DESCRIPTION as CHANGE_DESCRIPTION,
HD_CATEGORY.CC_LIST AS CATEGORYCC,
HD_CATEGORY.NAME AS CATEGORY_NAME,
U2.LOCATION AS SUBMITTER_LOCATION,
U2.WORK_PHONE AS SUBMITTER_WORK_PHONE,
HD_PRIORITY.NAME AS TICKET_PRIORITY,
HD_QUEUE.NAME AS QUEUE_NAME
from ( HD_TICKET,
HD_PRIORITY,
HD_STATUS,
HD_IMPACT,
HD_CATEGORY)
JOIN HD_TICKET_CHANGE TICKETCHANGE ON TICKETCHANGE.HD_TICKET_ID = HD_TICKET.ID
and TICKETCHANGE.ID=<CHANGE_ID>
JOIN HD_TICKET_CHANGE TICKETINITIAL ON TICKETINITIAL.HD_TICKET_ID = HD_TICKET.ID
and TICKETINITIAL.ID=(select MIN(ID) from HD_TICKET_CHANGE where HD_TICKET_CHANGE.HD_TICKET_ID = HD_TICKET.ID)
left join USER U1 on U1.ID = HD_TICKET.OWNER_ID
left join USER U2 on U2.ID = HD_TICKET.SUBMITTER_ID
left join USER U3 on U3.ID = TICKETCHANGE.USER_ID
left join HD_QUEUE on HD_QUEUE.ID = HD_TICKET.HD_QUEUE_ID
where HD_PRIORITY.ID = HD_PRIORITY_ID and
HD_STATUS.ID = HD_STATUS_ID and
HD_IMPACT.ID = HD_IMPACT_ID and
HD_CATEGORY.ID = HD_CATEGORY_ID and
TICKETCHANGE.COMMENT != '' and
TICKETCHANGE.DESCRIPTION not like "Changed ticket Machine from%" and
TICKETCHANGE.DESCRIPTION not like "%Ticket Created%" and
HD_TICKET.HD_QUEUE_ID = 9 and
HD_STATUS.NAME != 'Closed'
Note that this gives you the initial comment on the ticket at $initial_comment and the most recent comment at $comment. Be sure to change the queue_id towards the end to match your queue_id. - chucksteel 11 years ago-
How would I be able to Add more information to this rule? For instance what if I wanted to add a U4 called previous_submitter or a U5 called Previous_owner?
Thanks in advance for your help. - Kevino2010 10 years ago-
You would need to add two joins to the user table. To get the previous submitter this should work:
left join USER U4 on U4.ID = HD_TICKET_CHANGE_FIELD.BEFORE_VALUE and HD_TICKET_CHANGE_FIELD.FIELD_CHANGED = "SUBMITTER_ID" and HD_TICKET_CHANGE_FIELD.HD_TICKET_CHANGE_ID = <CHANGE_ID>
With that join in place you could select U4.FULL_NAME for the full name, etc.
To access the previous owner you would use this join:
left join USER U5 on U5.ID = HD_TICKET_CHANGE_FIELD.BEFORE_VALUE and HD_TICKET_CHANGE_FIELD.FIELD_CHANGED = "OWNER_ID" and HD_TICKET_CHANGE_FIELD.HD_TICKET_CHANGE_ID = <CHANGE_ID>
I haven't actually tested these joins but in theory they should work. - chucksteel 10 years ago
-
Chuck,
I really appreciate your willingness to spread knowledge, as you have helped me several times now. I'm working to understand what is going on the the rules.
By using a left join, are we just creating a user table with records of U1-U5, with the left join allowing us to tie different actual ID's to different User's in the user table that we made?
I wasn't able to get the rule to work properly, I have tried tweaking different things to no avail. Do you think I need to include two "and's" in parens or something simple like that? I used MySql Workbench and it looks like HD_TICKET_CHANGE_FIELD.BEFORE_VALUE exists.
This is what I get:
07/23/2014 11:24:06> Starting: 07/23/2014 11:24:06
07/23/2014 11:24:06> Executing Select Query...
07/23/2014 11:24:06> mysql error: [1054: Unknown column 'HD_TICKET_CHANGE_FIELD.BEFORE_VALUE' in 'on clause'] in EXECUTE("select HD_TICKET.ID,
I understand how to select different attributes of a user, the joins.....not so much. - Kevino2010 10 years ago-
You're correct about the joins. We're making five different relationships with the user table so that we can reference five different users. Looking back at my joins I realize what the problem is. Before we can reference the HD_TICKET_CHANGE_FIELD we need to make a relationship with it so I think we actually need two joins per user to accomplish what we want. So to determine the previous submitter:
left join HD_TICKET_CHANGE_FIELD U4_CHANGE on U4_CHANGE.HD_TICKET_CHANGE_ID = <CHANGE_ID> and FIELD_CHANGED = "SUBMITTER_ID"
This makes a relationship with the HD_TICKET_CHANGE_FIELD table based on the current ticket change ID (represented as <CHANGE_ID> and only gets the entry for when the submitter was changed. Now that we have this relationship we can make a relationship with the user table:
left join USER U4 on U4.ID = U4_CHANGE.BEFORE_VALUE
I believe that should work better. For the previous owner you also need two joins:
left join HD_TICKET_CHANGE_FIELD U5_CHANGE on U5_CHANGE.HD_TICKET_CHANGE_ID = <CHANGE_ID> and FIELD_CHANGED = "OWNER_ID"
left join USER U5 on U5.ID = U5_CHANGE.BEFORE_VALUE - chucksteel 10 years ago
-
As always thank you for donating your time and hard work for the cause. I know you don't have to do it, but it's always appreciated. - GeekSoldier 11 years ago