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.
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.
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.
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.
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 ...
Note: No email will be sent to the user if the ticket is a workflow substep.
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:
C:\ProgramData\i-net software\helpdesk_System_i-net HelpDesk\Templates
/root/.i-net software/helpdesk_System_i-net HelpDesk/Templates
/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.
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.
550 5.7.1 Unable to relay
: 3 hours lock for the address