Auto-Emails

The i-net HelpDesk is able to automatically send emails on important events in the ticket history. These events as well as the possible recipients can be found in this dialog. During configuration, check if a potential mail recipient has an email address.

Note: The behavior when sending auto-emails can be changed via JavaScript.

Auto-Emails to Resources when...

Check the mail address of the resource for correctness! An error in the mail address will result in an undeliverable message, which will be sent back to the i-net HelpDesk and possibly trigger a new auto-email.

Important: The auto-email is always sent to the resource in which the ticket is located at the time of triggering.

Example: When warning of an automatic escalation, the ticket is still in the originally responsible resource. After an auto escalation, the ticket is moved to the escalation resource and they receive the auto mail.

E-mail address/display name of default sender

The values for the e-mail address and the display name of the default sender are used if no e-mail address has been entered for the resource. This ensures that there is always a sender for the automatically sent e-mails.

Auto-Emails to Dispatchers when...

When checking each checkbox, keep in mind that supporters are often members of resources but also have the Dispatcher permission. The Dispatcher permission is typically granted via the supporter's membership in the Dispatcher and/or Administrator groups of the INETAPP. Avoid duplicate auto-emails to Dispatcher and Resources on the same event and enable auto-emails to Resources first, but not to Dispatcher. The only exception for dispatchers is Request from a user. This auto email is triggered when a new request is made by the end user or customer via email or either client.

  • User defined recipients.
    • Define here the group of recipients for auto-emails to dispatchers.
    • Scenario 1: A request is qualified by a dispatcher and assigned to a resource as a ticket.
      • In this case, an acting dispatcher exists for the specific ticket.
      • Only this dispatcher would receive an auto-email if the 3 checkboxes "Manual escalation", "Automatic escalation" and "Deadline exceeded" are activated in each case.
      • If the corresponding dispatcher has an email address, all auto-emails will go exclusively to this user. Only if the dispatcher had no email address in their master data, the auto-email would go to "all dispatchers" or to the addresses in the list.
    • Scenario 2: A call is automatically assigned to a resource as a ticket.
      • In this case, with the 3 checkboxes "Manual escalation", "Automatic escalation" and "Deadline overrun" enabled, every user with dispatcher privileges would receive an auto-email.
      • Your entries usually limit the group of recipients.
      • Adding individual email addresses is also possible.

Auto-emails to Users when...

Please note the following special feature related to the first and third checkbox. (Checkbox 1: Authorization of a request for an order; Checkbox 3: New request via email ...

  • Redundancy occurs when the end user/customer receives two auto-mails for the same ticket promptly or simultaneously.
  • The following is the description for each of the three possible cases when combining checkbox 1 and 3:
    1. The first checkbox is active.
      • Often the recommended variant, since an Auto-Mail is ALWAYS sent when a ticket is created.
      • The channel of the request does not matter (phone, email or web frontend).
      • A request by email should be authorized promptly or automatically to an order, so that the customer receives a confirmation with order number.
    2. Only the third checkbox is active.
      • For each new request via e-mail, the end user/customer receives an auto-mail.
      • Makes sense if requests are made exclusively via email.
      • However, if customers also call, then no auto-mail is sent.
    3. Checkbox 1 and 3 are both active.
      • You should avoid this case.
      • It is better to activate only checkbox 1 and automatically assign all requests by mail to a job of a resource.

Note: No email will be sent to the user if the ticket is a workflow substep.

Additional Settings

The content of the auto-mails is based on template files and can be customized by you. The location of the template files is on the INETAPP server at:

  • Windows: C:\ProgramData\i-net software\helpdesk_System_i-net HelpDesk\Templates
  • Linux: /root/.i-net software/helpdesk_System_i-net HelpDesk/Templates
  • Mac: /var/root/.i-net software/helpdesk_System_i-net HelpDesk/Templates

For editing HTML files, please use a suitable text editor, not MS Word.

The call URL of the HelpDesk server is set automatically during setup. The entry is used in the placeholder <%ServerURL%> in all template files for auto-mails that offer to start the HelpDesk client with direct opening of the respective ticket via a link in the e-mail. The following example of a link comes from the template file autorisierenres.html.

<a href="<%ServerURL%>ticketlist/ticket/<%OnID%>">Edit order</a>.

Some template files, as in Finish.html or Finish.txt, contain the placeholder <%subtemplate%>, which contains the entire history of the ticket in ascending chronological order. This behavior can be changed here.

By default supporters will also receive auto-emails for their own actions. This may be undesired if notification-emails are important only about other user's changes. Deactivate the checkbox Send auto-mails also for own actions to the supporter in that case.

Example: A user with access to resources and the dispatcher role creates an Own new Ticket, assigning it to a resource that contains its own email address in the "Email" field. In this case, neither an auto-email is sent to the user at "Authorization" nor to the email address of the resource ("New request"). Any other email recipients in the resource, on the other hand, will receive an auto-email with the information that there is a new ticket in the resource.

Example: A user with write access to resources manually forwards a ticket, e.g. from a "pool resource" to their "named resource". In the email field of the "named resource" are the addresses of this user and a colleague. If the checkbox "Forward an existing ticket" is active in the auto-email settings, then the user will not receive an auto-email, but their colleague will.

Intelligent handling of "undeliverable email" messages

Incoming emails are checked for bounce messages (https://de.wikipedia.org/wiki/Bounce_Message) and, if necessary, placed as such on an internal "list" that is maintained only in memory.

The sender addresses of these emails are temporarily or permanently not accepted as recipients of auto-emails, depending on the type of error.

The following treatments are applied.

  • More than 100 emails on a ticket: 12 hours block for this ticket.
  • memory problems (account or server full): 3 hours block for the address
  • 550 5.7.1 Unable to relay: 3 hours lock for the address