HaloITSM

HaloITSM Guides

Documentation to assist with the setup and configuration of the HaloITSM platform

Guides > Additional Email Settings

Additional Email Settings

In this guide we will cover:

- Various additional email settings



Associated Admin Guide

The following settings are found under configuration > Email. 


Make Forwarding Agent a Follower

When enabled, this setting will ensure that any agent who forwards an email into a ticket will become a follower of that ticket. Being a follower of the ticket means they will receive email notifications each time the ticket is updated, regardless if they are included in the To fields. 


This can be useful for account managers, when end users emails an account manager in regards to their ticket. The account manager may need to forward this email into the ticket to inform the agents working on the ticket but want to stay updated on the ticket activity. Rather than having to go into the ticket and add themselves into the email recipients list, the account manager will become a follower automatically and receive updates. The customer will then also not see the account manager in the email chain. 


Agent updates via Email are hidden from End-Users

When enabled, any email updates agents send into a ticket will not be visible to the end user in the portal. Useful when agents update the ticket with information they would not like the user to see. 


You may notice the setting 'Forward Agent updates via Email to End-Users' under each ticket type (settings tab). If 'Agent updates via Email are hidden from End-Users' is enabled the user will not receive a forwarded version of the agent update (the global setting will override the ticket type setting).  


Don't allow new Tickets via email

When enabled any emails sent to your mailboxes will not create new tickets automatically. Only emails that match an email rule (where the rule is configured to log a ticket), or emails from suppliers will log new tickets. Users will still be able to update existing tickets via email. 


When enabled an additional option will appear 'Respond with email template'. Here you can choose which email template to automatically reply to the email with, allowing you to communicate to the user that a ticket has not been logged and instead they must go to the portal. 


This is intended for when you would only like users to log tickets through the portal, or agents to log them for users. If you need certain emails to log new tickets you can create an email rule to do this. Head to configuration > email > email rules > new, name the rule and set the 'Email Rule type' to 'Help Request'. Then set the criteria for the rule, when this criteria is met the rule will be matched and a ticket logged. 

Fig 1. Email rule to log a ticket


Only route Emails if received into the same mailbox as the existing Ticket

When enabled, this setting ensures that emails will only update the existing ticket if they are sent to the same mailbox that the ticket communication is taking place in. For example, if an agent raises a ticket manually and sends email communication out to the user on this ticket from mailbox 1. If the user then sends an email update about the ticket into mailbox 2 this will log a new ticket rather than updating the existing one. They would need to send the update into mailbox 1. 


Mark emails from different domains other than the end User's domain as private

When enabled, if emails come into the system that are not from the End-User's email address(es) domain, then the note on the ticket will be hidden from the End-User. For example if the end user bencastle@acornconstruction.com logs a ticket and then gavinshipman@Halo.com sends an email update into the ticket, the end user (Ben Castle) will not be able to see the update from gavinshipman@Halo.com on the user portal). However, if gwynwest@acornconstruction.com sends an email update into the ticket, this will be visible on the portal. 


This prevents the end user seeing updates/information from external sources, aiding security. 


Only send acknowledgements to email addresses that match a Site's domain name

When enabled, this will prevent email acknowledgements (ticket logged conformation) being sent to email addresses that do not match the domain name set against the site. If enabled you must set a domain name against each site. To do this head to customers > sites > select a site > settings tab, here under 'Domain Name(s)', you can set the domain names. 


Fig 2. Set site domain names


This is used when you would only like users at that site to receive the ticket acknowledgement. Useful when a user CCs multiple external addresses into the email chain, as then the external addresses will not receive an email acknowledgement. 


Auto replies do not update the status of Tickets

When enabled, emails that come in to the mailbox that are auto-replies will not update the Ticket's status. These would usually be acknowledgements or out of office replies.


This prevents automatic emails from taking a ticket off SLA hold, and impacting SLA targets. 


This setting can be overridden with an email rule, that is if an automatic reply matches the criteria of an email rule it will not be treated as an auto-reply and still update the status of the ticket. Used for service monitoring, when a service provider sends automated emails about a service status you would want the ticket status to be updated and taken off SLA hold. 


Show the "Send an Email" option on the Tickets screen to send standalone emails

When enabled, an option to 'Send an email' will appear when hovering over the button to create a new ticket. 

Fig 3. Send an email option


Using the 'Send an email' button allows you to send an ad-hoc email unrelated to an existing ticket. This is used for one off user communication ie. you would like to send user(s) an update on something that does not require a ticket.  


Use Dynamic Email Lists

When enabled, the To/CC fields on emails sent from Tickets in Halo will be inherited from the previous correspondence on a Ticket. Allowing email recipients to be updated dynamically based on addresses users/agents add into the email chain. When disabled, the end-user email will always be the default for outgoing emails.


This can be overridden on each action, under the action configuration.


Fig 4. Exclude From Dynamic Email Lists


If an action is excluded from dynamic email lists when it is used it will only send an email to the end user of the ticket, ignoring any recipients in the email chain. 


Fig 5. Update Dynamic Email List


If an action is set to update the dynamic email list and additional addresses that this email action is sent to will not be added to the dynamic email list. 


Add 'X-Auto-Response-Suppress' header to all outgoing emails

When enabled, emails that go out to users and the user auto replies, the auto reply will be ignored. Useful for preventing out of office replies updating the status of a ticket and taking it off SLA hold. 


Outgoing Email Defaults Button

This lets you set the default outgoing email settings. It is important to set this after adding your mailboxes to the system as this is what the system will use to send emails by default.

Fig 6. Outgoing Email Defaults

Popular Guides

Pin It on Pinterest