The Email Polling feature automatically manages incoming support requests via email, helping organizations to respond quickly and efficiently to Customer inquiries and minimizes time-consuming data entry tasks for Technicians.
By itself, the Email Polling feature acts as an auto-responder.
To turn on Email Polling:
Log in as Administrator
Enter the Server Details
These are the system accounts for the incoming and outgoing mail servers.
Within the Setup Tab, select Yes for Email Polling
Complete the Interval field
Specify (in minutes) how long the system should wait between automated scans of the system email account. (At minimum this can be set to 5 minutes.) At the specified interval, the system will automatically scan the inbox of the system email address for messages.
Define remaining General, Requests and Notes Settings:
Enable Email Polling to allow the application to check for new email received in the mailbox on the incoming server defined within the Server tab.
For new messages that are received, the system will send a message to the sender acknowledging their message. System generated messages are customized within the Setup>Email>Templates tab.
NOTE:This option will be locked down if the Create via Email option is selected.
Enter the time period the system will use to check the incoming server for any messages sent to the support system.
Select Yes to include a banner within emails sent from the system.
The banner will be derived from: Setup>Customize>Setup>Public Banner.
When enabled, details of any system errors occurring while the application is running will be sent to the development lab.
For emails sent within requests, define if the Technician is to be copied or blind copied the correspondence.
Create/Update via Email
Select this option to enable requests to be created from emails addressed to the support system and Team addresses aliased on the email server.
NOTE:Email Polling will be locked down to Yes when this option is selected and the Accept Anonymous option is displayed.
When enabled, the system will create requests from emails received from email addresses that do not exist in the application's database. (Refer below for more information regarding this setting.)
Notify Alternate Team
When enabled, and if there is more than one Team created for a Process, within the Summary tab of a request the Alternate Team field is displayed. Members of the Alternate Team will be notified relative to the settings defined for the Current Team, and for New Notes, if Technicians is selected in the New Notes screen.
When set to Yes, new Notes created by a Technician or Customer are also sent to them when they save the Note.
Include Request Status
When enabled, the system will include the request Status within the Email Subject line of any correspondence sent from the system, regarding a request.
Include Request Priority
When enabled, the system will include the request Priority within the Email Subject line of any correspondence sent from the system, regarding a request.
Include Request Subject
When enabled, the system will include the content from the Subject line of a request within the Email Subject line of any correspondence sent from the system, regarding a request.
Parse Instance Prefix
The Instance prefix is used to process email correspondence from multiple instances. If this is not required, set the option to No.
Within the new Notes editor of requests, the default email settings can be defined for the recipient groups. Define the groups who are more likely to be sent every New Note created related to a request.
Set the default language file to be used for email correspondence. The option set is applied to the Email Locale field in the Customer and User Information screens and can adjusted on a per account basis, as required.
NOTE:The content for automated emails sent from the system for languages other than English, is defined within the Localization>Content tab.
Customize the content of emails automatically sent by the system within the Templates tab
This includes Handshaking (CloseRequest), No Account and Signature Templates. The message prefix used by the system to recognize correspondence related to requests stored in the system can also be edited within the Prefix template.
If the request creation feature is turned off (i.e., the Create Incidents checkbox is not ticked), a reply is automatically emailed to the sender. The email informs the sender that requests are not received via email, and if they want to log a request they are advised to do so via the Customer Portal. The content of the Responder message can be configured by the Administrator in Setup> Email>Templates.
NOTE:Important: Before using the Email Polling feature, ensure that the main system email accounts inbox is empty. Otherwise, any messages in the inbox will be acted upon either with an auto-response message being bounced back to the sender or the system will attempt to create requests for the messages. The action will depend on the application's settings.
Please take special caution if the main system email account is an IMAP account. Unlike POP accounts, messages generally are not removed from an IMAP server's inbox after they are read. This means that failure to clear out the inbox prior to using the Email Polling feature could result in auto-responses being sent to (or requests being created for) every message in the inbox.
If the Create Incidents feature is turned on, the system will attempt to either create a new request or update an existing one each time a message arrives in the system inbox.
To activate this feature:
Tick the Create/Update via Email checkbox under Setup>Email>Setup
If all Team members are to receive a copy of the notification that a new request has been received, set the Notify Alternate Team option within the Information tab of the Team.
To create a request via email, a Customer with a pre-existing account can simply send an email message describing the issue to the appropriate Team email address (refer to Setting Up Team Aliases, below).
When a new message arrives, the system identifies the Customer by matching the sender's email address against the addresses of Customers registered in the database. If it fails to find a match, an email is bounced back to the sender notifying them that they must create an account before creating requests via email. The content of this message is configured in the No Account field under Setup>Email>Messages.
If a matching Customer account is found, and the address that the email was sent to belongs to an existing Team, a request is created in the system. The body of the email becomes the main text of the request description. Any attachments included with the email will also be attached to the request. The new request is assigned a priority type of Medium, and uses the default Classification - General.
If the Customer only owns a single Item, this Item is automatically assigned to the request and the standard system SLA check of Customer>OrgUnit>Item will be run to verify which SLA should be assigned to the request.
If the Customer owns multiple Items, the system can automatically assign the relevant Item upon request creation if the Customer prefixes the email subject with ‘Item #’ followed by the Item identification number as recorded in the CMDB. If the Customer has an account in the system and is assigned as an owner of the Item, the system will refer to Relationships and Skills configured in the CMDB, resulting in the request being routed to the most relevant Technician for the job.
NOTE:If you want to create a request against a specific item through an email, the email subject must be prefixed with ‘Item #’ followed by the Item identification number as recorded in the CMDB in the following format:
If Item identification include spaces, use: Item # <item_identification>
Example: Item # <ZENworks Agent>
If the item identification does not include spaces, use: Item # <item_identification> or Item # item_identification
Example: Item # 102345 or Item # <102345>
In the case where the “Item #” is not included in the email subject line,and if the matching Customer is assigned zero or multiple Items, the new request uses the Unknown Item and the system default SLA. It is assigned to the Team or Technician who support the Unknown Item. When the Item is changed from Unknown to a specific Item, the Team or Technician assigned may change based on the Team configured to support the Item. The SLA may also be automatically reset by the system as it applies the SLA derivation logic of Customer>OrgUnit>Item to assign the relevant SLA.
Once the request has been created, an entry is added to the request Audit Trail, stating the request was generated via email. The Customer and the assigned Technician then receive emails notifying them of the request number and details.
Incoming email addresses that cannot be processed.
Sender should not have any of the following:
Also Sender should not start with 'no-reply'.
Subject should not contain any of the following:
no such user found
To automatically create requests from emails sent by monitoring tools, the monitoring tool must be created as a Customer within the system. The email address used by the monitoring tool can be the system default support address or a specific Team address. (See: Setting up Team Aliases below for sending to a Team address.) Once the request is created, an entry is added to the request Audit Trail, stating the request was generated via email. The monitoring tool Customer account and the assigned Technician receive emails notifying them of the request number and details.
If the monitoring tool Customer account is assigned to a single Item, this Item is automatically associated with the request and the standard system SLA check of Customer>OrgUnit>Item will be run to verify which SLA should be assigned to the request.
If the monitoring tool Customer account is associated with multiple Items within the CMDB, the system can automatically assign a specific Item upon request creation if the monitoring tool email prefixes the email subject with ‘Item #’ followed by the Item identification number as recorded in the CMDB. In this situation, if multiple Customers own the Item and if the request is to be associated with a different Customer after the request is created, Technicians can update the Customer details to move it from the monitoring tool Customer account within the Customer tab of the request Summary Tab.
In the case where the “Item #” is not included in the email subject line,and if the matching monitoring tool Customer account is assigned zero or multiple Items, the new request uses the Unknown Item and the system default SLA. It is assigned to the Team or Technician who support the Unknown Item. When the Item is changed from Unknown to a specific Item, the Team or Technician assigned may change based on the Team configured to support the Item. The SLA may also be automatically reset by the system as it applies the SLA derivation logic of Customer>OrgUnit>Item to assign the relevant SLA.
Managing requests via email is handled by the application sending its initial email with the subject line prefixed by the ‘Incident #’ or in the case of Change Management, prefixing the RFC subject line with ‘Change Request #’, followed by a series of numbers that make up the individual request identification number. Customers simply reply to this email and their correspondence is assigned to the relevant request, and any attachments are also uploaded to their request. Technicians can also reply to these emails to update the request, if convenient.
When the Note has been created, an entry is added to the request Audit Trail, indicating that a Note was added via email. The Customer and assigned Technician are then sent emails alerting them to the creation of a new Note.
For an incoming message to result in the successful creation of a request, it must be addressed either to the main system email address or to an email account that is an alias for the main system account and assigned to an existing Incident, Change or Service Request Team.
For example, if your main system email address is firstname.lastname@example.org and you want to set up three Teams, Team A, Team B and Team C, those three Teams should use email addresses that are aliases for email@example.com.
teamA@yourcompany.com should forward messages to firstname.lastname@example.org
teamB@yourcompany.com should forward messages to email@example.com
teamC@yourcompany.com should forward messages to firstname.lastname@example.org.
NOTE:Consult the documentation that came with your mail server for information on setting up email aliases.
Using this technique, any message that is sent to teamA@yourcompany.com, teamB@yourcompany.com or teamC@yourcompany.com is automatically forwarded to email@example.com. The Email Polling mechanism then picks up those messages and responds accordingly. The resulting request is assigned to a Technician within the Team the message was addressed to.
An alternate configuration would involve setting a single Team's email address to the main system address, which by-passes the need for aliases but does not allow the system to funnel requests to specific Teams.
If you have trouble setting up or using email polling and creation, keep the following tips in mind:
For the request creation feature to work properly, both the Email Polling and Create/Update via Email options must be selected under the Admin > Setup > Email > Setup tab
Only emails sent to the main system address or to an alias that is currently in use by an existing Team can be accepted
All pertinent information regarding the main system email address and the incoming and outgoing mail servers must be completed correctly
Ensure the Customer sending the email has a valid email address within the system.
NOTE:Only Incidents, Change and Service Requests can be created via email. If a User attempts to send an email to a Problem Team, a reply email will be forwarded to them informing the User that the email must be sent to an Incident, Change or Service Request Team, for a request to be logged with the system.