With the release of 2023.5 Enate is introducing improvements to how incoming emails are handled. The intention here is to handle any potential issues as well as possible, attempting to process whatever emails that can be. The most important changes that have been made refer to how Enate treats:
Emails recieved where one or more addresses are invalid (e.g. those involving Distribution Lists),
Emails received which have been BCC'd only to the Enate mailbox address, and
Emails sent into Enate with a 'from' addresse which this Enate instance itself uses to send emails out.
Previously in Enate, incoming emails that contained invalid email addresses did not meet the requirements to be processed, and were rejected by the Enate system. This can often occur if the email addresses contain Distribution lists, where the text name of the distribution list is supplied rather than the associated email addresses.
With version 2023.5 we've adjusted how such emails are handled, attempting to process them where we can, as follows:
If the email contains at least one valid email address which can be used for processing, we will process the mail, but will mark the invalid email address wherever it is displayed.
If ALL of the emails addresses which could potentialy be used for processing are invalid, the system will place the email in the 'Unprocessed emails' list, allowing agents to review and decide on how to proceed.
To help users identify which emails have come in with invalid email addresses, a notification will now be shown in Work Manager wherever that email is displayed, letting users know that it contains invalid address - and will then list all the invalid email addresses it contains.
Previously when Enate was Bcc'd in emails, upon arrival into Enate they would be directed to the Unprocessed emails list (due to not having a 'To' address value, the attribute which Enate uses for routing mails to create new Work Items).
To help reduce the ocurrences of such mails landing in 'Unprocessed emails' in this situation, Enate now supports the ability to configure Email Routes which essentially use the knowledge of which email addresses these mails come from to allow it to be processed. To help with this, you're now able to create Email Routes where the Routing Rules contain:
a '*' wildcard email address setting (i.e. the 'To' address of the incoming mail) along with
a known email address for the 'Sender List includes' (i.e. the 'From' address of the incoming mail).
This lets you set Enate to process emails coming in from a known email address even when Enate is only set as the bcc addresee. See details below for how to create these Email Routes.
Wildcard routes are created in the same way non-wildcard routes are created, via the 'Routes' page in the Email section of Builder. Simply click to create a new email route and fill in the email route pop-up information as required. To set this as a Wildcard Route to handle Bcc scenario, when filling out the Routing Rules information users should put a '*' wildcard asterisk as the 'Email Address', and then in the 'Sender List Includes' field, set the name of the known email address that such mails would be coming from. Multiple such addresses can be added to a single Route, with a ';' semicolon character between.
You should create as many such Wildcard Routes for a single Email Connector as there are different Work Item types you wish to be creating from that connector.
When ordering their email routes into a hierarchy, users should always ensure that non-wildcard routes appear above wildcard routes, with overall fallback routes appearing after the wildcard routes at the very bottom of the list.
Note: There are now a number of important rules to follow when including such Wildcard '*' Email Routes within your list of Email Routes, in order to ensure consistent creation of Work Items. See this section for a list of these rules.
We are making a change in how we analyse incoming emails to determine if they have come from this Enate instance. Until now, the system has used the 'From' address of incoming mails for determining if the mail has come from an address which the Enate system knows that it sends mails out from. The system then ignores such emails as it will have already been dealt with as it was being sent out - this helps reduce creation of duplicate work items. However in some circumstances, third party systems can send emails into Enate which also use those same email addresses as their 'From' - and this results in those emails not being processed by Enate. The new approach avoid this occuring, and such emails from third party systems will now process into Enate. Instead of using the 'From' address, Enate now uses the 'MessageID' of the incoming email to check if it has come from this system. Incoming emails which HAVE actually been sent out by this Enate instance will be identified correctly (and will be ignored), while mails coming from 3rd party systems which would previsouly have been ignored due to their From address will now be processed as desired.
Please note that since all of the above changes for Incoming emails involve processing more emails than previously, users may experience an increase in the volume of emails being seen in their system.
When creating an email route containing a wildcard route, there are some important rules that apply, to keep routing of incoming emails working consistently at runeimt. See the table below for a full list of rules regarding the use of working with Email Routes if wildcard (i.e. '*') email routes are involved.
Note: The system will show error messages when a user attempts an activity which may break these rules.
| Activity | Rule | Related API |
|---|
If a user attempts to move a route into an order that does not correspond with the required hierarchy, the route will return to where it was and a error message will be displayed.
Updating an Email Route | Updating a NON-wildcard email route to a wildcard email route is now restricted. | Email Route - Update |
Updating an Email Route | Updating a wildcard email route to a NON-wildcard email route is now restricted. | Email Route - Update |
Creating or Updating an Email Route | The system does not allow using a wildcard address for the sender list when the route's email address is also a wildcard. | Email Route - Create Email Route - Update |
Creating or Updating an Email Route | A wildcard route requires a sender list to be included. | Email Route - Create Email Route - Update |
Ordering Multiple Routes | When using a wildcard, a strict routing order exists: 1. Non-wildcard Routes 2. Wildcard Routes 3. Fallback Routes | Email Route - Get All For Connector |
Creating an Email Route | When a email route is created, whether it is a wildcard or not, its order is based on the criteria is determined by the order (stated above). Route orders can be adjusted accordingly after creation. | Email Route - Create |
Moving an Email Route | Routes can only be rearranged within their respective type ranges. For example, if it's a wild card route, the system allows moving it within the wild card order range (min-max). The same applies to non-wildcard routes, where the system permits movement within the non-wildcard order range (min-max). If routes are moved beyond their designated range, the system will generate an error. | Email Route - Move Route |
To help users understand how using wildcard routes will impact BCC emails the table below shows the possible scenarios that can occur:
| Scenario | Result |
|---|---|
No wildcard routes in connector - Sent an incoming email with BCC connector. No TO/CC.
Email will land in 'Unprocessed Emails'
No wildcard routes in connector - Sent an incoming email with BCC connector. With TO/CC that don't correspond with any current Routes.
Email will land in 'Unprocessed Emails'
Wildcard routes in connector - Sent an incoming email with BCC connector. Without TO/CC.
Work Item should be created with BCC email address.
Wildcard routes in connector - Sent an incoming email with BCC connector. With TO/CC that don't correspond with any current Routes.
Work Item should be created with BCC email address.
Wildcard routes in connector - Sent an incoming email with multiple connector addresses in BCC connector. No TO/CC that don't correspond with any current Routes.
Work Item will be created only for one (first received email address) connector. Rest of the arriving emails will be marked duplicate and therefore ignored.
Wild card routes in connector - Sent an incoming email with multiple connector addresses in BCC connector. With TO/CC that don't correspond with any current Routes.
Work Item will be created only for one (first received email address) connector. Rest of the arriving emails will be marked duplicate and therefore ignored.
Wild card routes in connector - Sent an incoming email with multiple connector addresses in TO/CC and BCC connector.
Work Item should be processed for TO/CC address. The BCC will not be processed.
Wildcard routes in connector, which contain Multiple 'Sender List Contains' values. Send an incoming email from one of the sender list addresses, BCCing the connector address.
Work Item should be created with BCC email address.
Wildcard routes in connector. Disable the Wildcard route. Send an incoming email from one of the sender list adresses and BCC the connector address.
Email will land in 'Unprocessed Emails'
Wildcard routes in connector. Configure the non Wildcard route with the same set of rules. Send an incoming email from one of the sender list adresses, BCCing the connector address.
Work item will be created for the wildcard route.
