Email to service desk from rule does not create a ticket
I'm trying to implement something similar to the method for creating a child ticket by email from parent ticket as shown in this question and answer: http://www.itninja.com/question/kace-service-desk-variables-parentticket.
However, I can't get emails sent to the queue by my rule to create new tickets.
The rule checks for a specific set of criteria (values set in custom fields) which then updates other custom fields in the ticket. This works as intended.
I have selected "Email each recipient in query results". This works correctly as well, and has been tested with different recipient addresses to verify the email is sent. I can also verify when the email is delivered to the queue's mailbox, and I can see that KACE is retrieving the message. (Message deleted from inbox by POP).
However, no new ticket is created.
I can open tickets by email in this queue otherwise, including sending an email from the queue address to the queue address. So why won't the email sent by this rule open a new ticket?
3 Comments
[ + ] Show comments
Answers (0)
Please log in to answer
Be the first to answer this question
Select SQL:
select HD_TICKET.*,
HD_TICKET.ID AS TICKNUM,
'kacetestq@mydomain.com' as NEWTICKETMAIL
from HD_TICKET where ((HD_QUEUE_ID = 2) and (CUSTOM_FIELD_VALUE3 like '%Email%') and (CUSTOM_FIELD_VALUE4 not like '%Email%'))
Update SQL:
update HD_TICKET
set HD_TICKET.CUSTOM_FIELD_VALUE4 = CONCAT(HD_TICKET.CUSTOM_FIELD_VALUE4, ', Email')
where
(HD_TICKET.ID in (<TICKET_IDS>))
Email each recipient in query results:
Subject: Email Account Creation from $ticknum
Column containing email addresses: NEWTICKETMAIL
kacetestq@mydomain.com is the address for the queue. I can create tickets by sending email to that address, even when sending from that address by logging in to that email account. Why doesn't the rule generated email create a new ticket? - MichaelMc 9 years ago
For example. You have an auto responder that is not setup properly it would cause the kbox to enter an infinite loop of emails.
I suspect that this is your issue as you way you can watch the emails come into the mailbox for processing and get poped down. - smalls 9 years ago
That makes some sense, especially considering that the queue could be set to send a notification email that the ticket had been created. However, I consider this kind of a kludge solution. (I feel the same way about how MS handles Out of Office replies. Of course, if MS can't come up with a better solution, it means they haven't found anyone to buy or steal it from yet.)
I am pretty sure that with some effort I can design a rube goldbergesque email forwarding scheme that could work around this.(Or how about this: Send email to a different queue. That queue has a rule that moves all tickets to the first queue. Kludge solutions create a demand for more kludge solutions.)
In the end, why it doesn't work really doesn't matter. What matters is how to achieve this goal. Did you ever find a method that would create a new ticket from the queue? I'd really prefer something that works cleanly, so it can be adapted or copied to other queues as needed.
My next idea is to use an insert statement in the sql update commands... (Stand back, I'm going to try science!) - MichaelMc 9 years ago
I seem to remember trying the other queue trick but the kbox looks at all the email address it has to prevent the loops from happing.
I ended up using our PargerDuty system to receive the email and send it back to the kbox to generate a new ticket. Like you said "goldbergesque email forwarding scheme". One thing to note about using PagerDuty is that I had to make the kbox send another email to close the open case in PagerDuty. Lots of emails fly when this set of rules trigger. :-P
I have found that this works quite well and then you can get creative with the rules to pull and set data from other tickets or you can simply generate the email using the proper @FIELDNAME= to fill in all the information you want to bring across. - smalls 9 years ago