/build/static/layout/Breadcrumb_cap_w.png

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
  • Since nobody seems to have an answer, here is the actual rule. I have a similar rule created by Wizard, but both rules work the same in all regards (update as expected, email sent as expected, etc., and no ticket created from email).

    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 8 years ago
  • I had also tried to do this some time ago with generating emails for sending in to make new tickets. I ended up taking to support about the issue and was told that there was a build in system that will not allow the kbox to make tickets from emails that it sends. It is to do with loop detection.
    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 8 years ago
    • Thanks for taking the time to respond.

      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 8 years ago
  • Remember sparks are part of the kool science. :-P.
    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 8 years ago

Answers (0)

Be the first to answer this question

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