Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Enate allows you to configure mailbox integrations so that incoming emails can generate new work items / be attached to existing work items and allow the system / agents to send outgoing emails via Enate. You can access this section, along with other email configurations, from the Email link in the Builder toolbar.
Here you can configure:
Email Connectors – click here for more information about email connectors.
Email Routes – where to route incoming emails, i.e. referencing the email addresses in the Connectors you have created, you can specify which Tickets or Cases should route brand new emails into a certain inbox. Click here for more information about email routes.
This approach allows you to set up and maintain how your Tickets and Cases run in conjunction with email servers without having to modify the actual Ticket and Case processes all the time.
Enate can support the following protocols for incoming email:
POP3/SPOP3
IMAP4/IMAPS4
GraphAPI (Office365)
POP3 and IMAP4 can be configured in Enate on any port, so firewall requirements are dependent upon the mail server team and their configuration of these protocols. When using POP3 and IMAP4, Enate requires that these use an external DNS name and have a publicly trusted certificate that matches on the DNS name.
For example, a POP3 server with the external DNS name pop3-mail.enate.net should have a publicly trusted certificate that either matches the full name pop3-mail.enate.net or should have a wildcard certificate for *.enate.net. Enate requires certificates be publicly trusted and cannot accommodate internal DNS names or self-signed certificates. GraphAPI operates over HTTPS directly from Office365 and requires no additional ports to be open.
Note: There is some additional configuration to be done in Office365, which can be found here.
Regardless of the protocol that is used for incoming email, the behaviour is always the same within the mailbox: When Enate polls a mailbox to retrieve messages, these messages will be downloaded and processed by Enate and then be deleted from the mailbox.
Email Integration is possible for Normal User Mailboxes as well as Shared Mailboxes. Since the Shared Mailbox doesn’t have a password but an account with permissions to access the shared mailbox, when configuring your Connector you should first enter the username and password for the primary account via which you can access the shared mailbox, then you set the 'Access Another Mailbox' option to ON, and provide the name of the shared mailbox to be used.
Enate can support multiple aliases on a single mailbox to simplify the configuration and number of accounts required on the mail server side.
Enate mailbox matching logic is always performed on the "To" address received in the message body that was downloaded from the server. Depending on the mail server in use this can present issues when handling email internally for the same domain as the mailbox that Enate connects to. Exchange Server and Office365 will modify the "To" field to be the Primary SMTP address configured for the receiving mailbox if the email has been sent within the same domain. This can cause issues with email routes not correctly matching.
Example:
If enate.sales@example.com were configured as an alias of enate.production@example.com another user sending to enate.sales@example.com from an @example.com email address would result in the "To" field within Enate appearing as enate.production@example.com rather than the enate.sales@example.com address the email was sent to.
Forwarding between different mailboxes is sometimes used to achieve an archive of emails processed within Enate. These can be done successfully in most systems however care should be taken to avoid modification to the "To" field. This behaviour is typically highly specific to individual mail systems depending on how it is being done and so should be tested as to avoid affecting email messages.
Information to help Admins set up relevant email integrations to work with Enate
In order to support inbound and outbound emails in Enate, your email administrators will need to set up the relevant email integrations into Enate.
The following sections give details of the various options available to support both incoming and outgoing emails. You system administrators should familiarise themselves with these options and any technical requirements.
If you have any questions regarding this while you’re looking to set up your email integrations with Enate, please contact us at enate-support@enate.net.
Enate currently only supports SMTP/SMTPS for sending email. GraphAPI is currently only available for incoming email.
Internally, Enate matches on the outgoing "From" to determine what email connector configured as either ‘Outgoing’ or ‘Both’ should be used to send a specific message. If no specific email connectors match the "From" address then Enate will fall back to using the System Default Gateway for sending email.
Note: This System Default Gateway MUST be configured prior to using Enate.
The unmonitored email address which is used as the From address on some automated outgoing emails such as password reset mails (and which you can set in the General Settings section of Builder) functions in the same way as the above configured From addresses. If the System Default Gateway is disabled, you must provide a valid email address for this unmonitored email which has been configured as an outbound email connector.
Outgoing email can be configured in several different ways in Enate depending on the preferences of your mail server teams.
As with incoming email, Enate requires an external DNS name and publicly trusted certificate be configured with SMTP.
The port that Enate connects to SMTP on is configurable within Builder on a per connector basis and so the firewall requirements are dependent on the mail server teams and their configuration of these protocols. Typically, either port 25 for SMTP or ports 465 or 587 for SMTPS are used.
An SMTP gateway can be created with the ability to relay all email sent via it. This can be restricted with a username/password combination to avoid creating an open relay that may be subject to abuse. This can then be configured as the default SMTP/outgoing connector within Enate Builder.
This simplifies ongoing email configurations allowing new incoming email addresses to be added without needing to adjust permissions for sending.
Similar to the above, a gateway can be supplied where a user account with Send As permissions on every account/Email address used within Enate can send email.
For example, an enate.production@example.com account could be created with Send As permissions on enate.sales@example.com, enate.finance@example.com and enate.accounting@example.com. This enate.production@example.com could then be configured instance-wide within Enate Builder.
This increases the configuration complexity and also requires IT or mail servers to add new addresses on an ongoing basis whenever these are required within Enate.
When configuring email connectors in Enate, you can specify either Incoming, Outgoing or Both for the direction.
These settings allow you to configure outgoing email to use connector specific SMTP values. No additional credentials can be specified here and so the POP3/IMAP4 credentials specified on the email connector in Enate must have Send As permissions on the configured SMTP From Address value.
This configuration typically only works where the incoming POP3/IMAP4 address is also the address that will be used to send replies, for example if customers are emailing enate.sales@example.com and the reply will also come from enate.sales@example.com. If this is not the case then this configuration leads to having to manage multiple sets of permissions across different accounts to allow Send As permissions to cover all addresses used in Enate.
You can sync Enate to Microsoft Office 365 email boxes and pull emails into Enate without needing to use POP3 or IMAP protocols via Graph API Integration. Read below to find out how to go about this.
To configure integration between Enate and Office 365, each unique Enate instance must be registered with the Microsoft Identity Platform in the Azure AD of the Office 365 tenant to which you need to establish connectivity.
To create the “App Registration” please follow the guide from Microsoft at .
When configuring the Enate App Registration the supported account types option should be chosen based on the mailboxes you wish to access. No redirect URI is required.
Once the App Registration is complete you must add credentials and setup permissions.
To add the required permissions follow the guide at . The only required API permission is an Application permission of Microsoft Graph\Mail.ReadWrite. It is important to select an “Application permission” and not a “Delegated permission”. Be sure to grant admin consent for the permission within the Azure AD tenant.
To create a credential follow the guide at . Enate supports Client Secrets and Certificates.
Finally to restrict the App Registration to only accessing certain mailboxes (strongly recommended) follow the Microsoft guide at
After Azure AD has been configured to grant access, login to Enate Builder as a user with the “Can Edit Shared Configuration” permission.
Click the settings cog in the bottom left and open the “Office 365 Integration” pane and enter the details from your Azure AD App Registration.
The Tenant ID (aka Directory or Domain) and Application ID is shown on the Overview pane of the Azure AD App Registration; the client secret or certificate (and private key password) are supplied by you to both Azure AD and Enate.
You always use shared mailbox.
Click on the Office 365 Integration” pane and select whether you want to authenticate with a certificate (this is the recommended route as it is more secure), or whether you want to authenticate with client secret.
As part of this set up, an Office365 Certificate would need to be generated - Generating a certificate is an activity for your Office365 Administrator to undertake, and is done completely independent of Enate. For your reference we have provided below a SAMPLE of the kind of PowerShell script that can be used to generate such a certificate. It will save the Certificate with the private key (for Enate) to a PFX file and without the private key (for Azure):
Enter the Tenant ID/Domain and the Application ID, select the 'Authentication with Certificate' option, add the certificate file ( Personal Information File, .pfx) and enter the password for the certificate file.
Then click to check the connection. Once the connection has been successfully tested, click to save.
You have now successfully configured your Office 365 integration.
To authenticate with client secret code, enter the Tenant ID/Domain and the Application ID, select the 'Authentication with Client Secret' option, add the client secret code (this is generated by the network admin of your company).
Then click to check the connection. Once the connection has been successfully tested, click to save.
You have now successfully configured your Office 365 integration.
Enter the name and email address of the shared mailbox to be used.
Then click to test the connection. Once the connection has been successfully tested, click to enable the Graph API connector and click to save. Your Graph API connector is now set up.
If a new email arrives from one of the folders configured in the connector and it matches the folder path specified in the email route and it passes any other routing rules, it will launch the process specified in the route.
If you don't specify the folder path and leave it blank or use a wildcard '*', emails from any of the the folders configured in the connector will create the process specified in the route, as long as all the other routing rules are matched as well.
When new emails arrive into Enate, the system analyses the email to determine whether it’s a brand new request or related to an existing one, and then determines how to proceed.
The system can be set up to analyse incoming emails in three different modes to try to match it with an existing work item (the selection of which mode to use is made in the 'Work Item 'Plus Addressing'' section of Builder's System Settings). Options are as follows:
Plus Addressing OFF - Plus Addressing is completely disabled and emails are matched using the standard email processing rules only.
Mixed Mode - Plus Addressing is enabled and emails are matched using both plus addressing AND the standard processing rules standard email processing rules.
Plus Addressing Only - Plus Addressing is enabled and emails are matched using plus addressing ONLY.
See the section for more detailed information on each of these modes and how the system operates in each case.
Using one of these modes, the system will attempt to match the email with an existing work item. If it finds a match, then depending on the state that work item is in, it will behave as follows:
If the system finds a match to an existing Ticket, Case or Action that is in a state of DRAFT, TO DO or IN PROGRESS, the system will:
append the email to the work item
mark the work item with ‘new information received’
The same applies to auto-generated emails that are matched to an existing work item in a state of DRAFT, TO DO or IN PROGRESS. Please see the for more information on how the system detects auto-generated emails.
If an incoming email is matched to an existing work item that is in a state of WAITING, the system will:
append the email to the work item
mark the work item with ‘new information received’
In addition, if the Wait type is 'Waiting for more information, the system will:
change the state of the work item from WAITING to TO DO
As a result of the change in state to TO DO, a Queue and assignee will be set to the work item and it will move back to the responsible agent’s Enate Inbox, marked with ‘new information received’
If the work item is an Action and both the Action and its parent Case are in a state of WAITING with a wait type of Waiting for more information, the state of the parent Case will change to IN PROGRESS
If an incoming email is matched to an existing work item that is in a state of RESOLVED (note that only Cases and Tickets can be in a state of RESOLVED), the system will:
Append the email to the work item
Reopen the work item and set it back to TO DO
As a result of the change in state to TO DO, a Queue and assignee will be set to the work item and it will move back to the responsible agent’s Enate Inbox, marked with ‘new information received’.
If an incoming email is matched to an existing work item that is in a state of CLOSED, the system may take various courses of action depending upon the type of work item:
The system will firstly ‘go up’ the work item chain to look for a parent work item e.g.
if the email is matched to an Action that is CLOSED, the system will see if the Action’s parent Case is still open.
if the email is matched to a Case that is CLOSED, the system will see if the Case has a parent Case or Ticket that is still open.
if the email is matched to a Ticket that is CLOSED, the system will see if the Ticket has a parent Ticket that is still open.
If the system does find a parent work item that is still open, the system will then apply the rest of the email processing logic to the parent work item (i.e. all of the logic in the above sections on running work items).
If the email is sent to a closed child split ticket, the system creates a new work item for the email.
If no information can be identified to link the email to a currently running work item, the system will generate a brand new work item (Ticket or Case) based on the email’s configured routing rules. A confirmation email will be automatically sent back out to the requesting email address containing the reference number if the email route settings specified in Builder have ‘send response’ set to ‘on’.
Split Ticket – if an incoming email is matched to a split Ticket – either the original Ticket that was split or one of the child Tickets it was split into – the email will be appended to each of the CHILD Tickets. The system will then apply the rest of the email processing logic to each of the child Tickets independently.
Merged Ticket - if an incoming email is matched to a merged Ticket – either one of the original Tickets that were merged or the ‘target’ Ticket that they were merged into – the email will be appended to the ‘target’ Ticket. The system will then apply the rest of the email processing logic to the ‘target’ Ticket.
Ticket converted into a Case – if an incoming email is matched to a Ticket that was Resolved by being converted into a Case, the email will be appended to the Case. The system will then apply the rest of the email processing logic to the Case.
The system detects auto-generated emails by one-or more of the following:
A « x-autoreply » header exists
A « x-autorespond » header exists
A « auto-submitted » header exists and the value is either « auto-generated » or « auto-replied »
A « content-type » header exists and the value is either « multipart/report » or « delivery-status »
The ReturnPath header exists and has a value of « <> » or « <<>> »
Before processing any emails Enate will check to see if it sent it. Every email has a unique identifier which should not change. Enate stores the unique identifiers of emails that it has sent and uses these to perform this check.
This Enate behaviour is to avoid duplicate processing of items which Enate may well have already processed before the outgoing email has been sent, for example (but not limited to) auto-appending of mails to linked work items via Plus Addressing logic.
When deciding which process to start, Enate looks at all the routes for the connector for the email address under consideration (NB* This means that if you spread routes across connectors, you’ll get odd behaviour!).
Enate then looks at each route in the order you have defined, starting at the top (1) checking for the criteria you have added. If all the criteria match then the route is used, if any of the criteria don’t match, Enate will move onto the next route.
The last route is a catch all (fallback) route, however if the email has been sent to an alias, then the catch all route will not match and the email will be made available for processing in ‘Unprocessed View’
If the email has been sent to Enate using Blind Carbon Copy (BCC) then by design Enate is not able to see which email address the email has been sent To (If Enate could see the address list it wouldn’t be ‘blind’). This causes all routes to fail to match.
A specific sceario to handle for incoming email processing is where someone CC'd on a mail sent into enate replies to that email. Enate recognizes the situation and will attach that mail to the original work item, rather than creating a brand new work item.
The technical specifics of this are as follows: Improved 'InReplyTo' logic has been added for processing incoming mails. We now validate if the 'InReplyTo' field of the incoming email aligns with the Message-ID of a prior email. When matched, the email/communication is appended to the relevant work item. In short: if we can tell that a mail has been sent in reply to a mail we already know about, we direct that new mail to the previous mail's work item.
Additional Note:
If your system is using Traditional/Mixed mode, we verify if the 'InReplyTo' field corresponds to the Message-ID of ANY previously received email, irrespective of being incoming or outgoing.
If your system is running in Exclusive (i.e. Plus Addressing ONLY Mode), we verify if the 'InReplyTo' field corresponds to the Message-ID of previous INCOMING received emails only (not outgoing mails).
To help users understand how using wildcard routes will impact BCC emails the table below shows the possible scenarios that can occur:
| Scenario | Result |
|---|
Once you have some email connectors defined, you can reference them in email routing to specify where emails coming into each mailbox should be routed by Enate (i.e. which work items it should start).
The Email Routes page is where you can create new email routes and manage your existing ones.
Email routes are grouped by the email connector to which they are associated. These groups can be expanded and collapsed, making larger bodies of data easier to work with.
At header level, you can search to filter down your view to just one Connector:
You can search for a route at a connector-level, based on its email address, process and/or Ticket category (if relevant).
Note that these searches are all 'start with' searches rather than full wildcard searches, e.g. if you type 'France' it will search for items 'France*' rather than *France*..
For Graph API routes, you have the option to view folders as an additional filter at the top of the screen.
Watch this video to find out how to set up an Email Route:
More information about the attributes to configure when creating a new email route:
Note: The feature to send a Ticket Acknowledgment email to CC users is an enhancement of the existing functionality where an auto-confirmation email or acknowledgment is currently sent only to primary contact/sender but not to the CC users.
When editing an email route, you are also able to see its activity history by clicking on the Show Activity button. You can see when the email route was created and by who, as well as if any edits have been made to the email route, when they were made and by who.
Note: when you delete a Case or Ticket process or a Customer/Service/Contract that has linked Email Routes, you will be notified of this and will need to update the respective Email Routes in order to stop them from creating more work for the process.
Additionally, as a useful shortcut you have to ability to add a new email route directly within a specific email connector itself - clicking on the '+' icon next to a connector will bring up the 'Create an Email Route' pop-up with the email connector name already filled it.
You can add routing rules to an email route to provide a more fine-tuned way of determining where an incoming email gets routed to (and therefore what kind of work item gets created). Watch this video to find out more:
Routing rules can be based on the information of the incoming email including:
Important Flag on Email - if the email has been flagged as 'important'
Has Attachments of Type... - if the email has an attachment of a certain type - list of file extensions separated by a semi-colon e.g. .pdf; .docx
Key Words in the Subject Line - list of key words in the email subject line separated by semi-colons e.g. urgent; support; reset
Sender's company name includes - lets you direct incoming mails based on the company the email sender belongs to. This stops you having to create multiple variations of slightly different email domain-based routings for your larger clients. Select the sender's company name from the dropdown. You are able to add multiple companies. Any emails arriving from email addresses belonging to the companies you have selected will start the process set in the email route.
Please note that information from the incoming email body itself cannot be used when routing emails.
You can add multiple routing rules to an email route:
You can route emails based on a particular email domain by adding a '*' before the domain:
Note that this is only available for 'Sender List Includes' and 'Recipient List Includes'.
You can easily adjust the ordering of the routes for a connector by dragging and dropping to the desired location. When deciding on the order in which to run multiple related routings, you should place the most specific rules first, and set more generic ‘fallback’ routings last.
Additional notes regarding email route reordering:
Email routes cannot be dragged outside of their respective group.
Reordering via the routes grid is only possible with the necessary permissions.
Email route re-ordering will be blocked unless the route grid is sorted by Priority Order: ascending (as this makes the reordering interaction less confusing). When the route grid is not sorted by Priority Order: ascending, a message will show to alert you.
For connectors with extremely large numbers of routings, you may wish to manually set the order number directly (a useful alternative to having to drag routings hundreds of places up and down some of the larger lists). To do this, simply right-click the desired row and click the resulting tooltip:
This will ensure that any mails arriving to that connector which don't get handled by the various email routes configured will at least be handled by this fallback and will kick off the Case or Ticket it routes to.
Fallback email routes show in your email routes section with some specific impacts.
Details of this are as follows:
These routes will always display at the foot of the Email Routes list
The Routing Rule will be set to read-only
The Email Connector will be set to read-only
The 'Enable' setting is set to ON, and is read-only
When configuring email routes, if a sender is an unknown user or a new contact, a route that contains a company filter cannot match. This can lead to emails possibly being sent down the wrong route. To help avoid this, do not combine the following configurations:
Combination One 1. Auto create contacts 2. Contacts locally scoped 3. One or more email routes with a company filter
Combination Two 1. Contacts Locally scoped 2. One or more email routes with a global company filter
Systems set up in this way may result in unpredictable and inconsistent routing of mails and should be avoided. These combinations of setup are not supported.
Once you have successfully configured your Office 365 integration, you can configure your Graph API Mailbox by going to the page and selecting to add a Graph API Connector.
You can now create different for the Graph API connector if you wish.
The same rules apply to auto-generated emails that are matched to an existing work item in a state of Waiting or Waiting for more Information. Please see the for more information on how the system detects auto-generated emails.
The same rules apply to auto-generated emails that are matched to an existing work item in a state of RESOLVED. Please see the for more information on how the system detects auto-generated emails.
If the system cannot find a parent work item that is still open, the incoming email will NOT be appended to the already closed work item. It will instead create a new work item following the for what happens when the system is unable to match an email to an existing work item, and copy all the information (comms, files, defects, contacts and custom data) from the existing closed work item to the new work item.
To support this Enate allows you to define one or more special 'Wildcard' routes that have ‘*’ (meaning any) as the email address. If you do this then you must also specify a sender address. You can also apply any other criteria as appropriate. These Wildcard Routes must be placed at the bottom of the order (but above the fallback route). See this for more information on this.
To help users understand how using wildcard routes will impact BCC emails, see this
Recipient List Includes - email address of the recipient of the email. This can include multiple potential recipient email addresses, both individuals email addresses and . If there are multiple email addresses, each much be separated by a semi-colon e.g. john.smith@example.net; brenda.johnson@acme.com
Sender List Includes - email address of the sender of the email. This can include multiple potential sender email addresses, both individual email addresses and . If there are multiple email addresses, each much be separated by a semi-colon e.g. john.smith@example.net; brenda.johnson@acme.com
A fallback email route needs to be .
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. |
Attribute | Comments |
Email Connector Name | Select from list of pre-existing Connectors |
Route Name | Friendly name fo the Email Route |
Email Address |
Process | The specific process, e.g. Ticket OR Case now. (Select Customer, Contract, Service and Process). |
Ticket Category | The category value to set when launching a new Ticket (Relevant for Tickets only). |
Send Automated Emails | This lets you choose whether or not you want to send automated emails to the work item's contacts. This is defaulted to OFF. |
Create Work For Test Mode | If the email address can be used to create work in Test mode, or only in Live environment. |
Enable | Whether the routing setting is currently active. |
Enate deals with incoming 'Out of Office' emails in two ways:
If the 'Out of Office' email is generated in response to receiving an email written by a user in Enate, Enate will append the 'Out of Office' email to the work item and mark the work item with ‘new information received’. See below for further specifics.
If the ‘Out of Office’ email is sent in response to an auto-generated email from Enate (e.g. acknowledgement of Ticket creation), the 'Out of Office' email will NOT be appended to the work item and the work item will not be marked with ‘new information received’ - it will effectively be ignored.
Expanding on the logic for situation 1 above where an 'Out of Office' email is generated in response to receiving an email written by a user in Enate...
If the incoming 'Out of Office' email is matched to an existing Ticket, Case or Action that is in a state of DRAFT, TO DO or IN PROGRESS, the system will:
append the email to the work item
mark the work item with ‘new information received’
Note: This logic above applies to all auto-generated incoming emails that are matched to an existing work item in a state of DRAFT, TO DO or IN PROGRESS (i.e. incoming Out of Office emails are treated in exactly the same was as other incoming auto-generated emails in these states). Please see this section for more information on how the system detects auto-generated emails.
If the incoming 'Out of Office' email is matched to an existing work item that is in a state of WAITING, the system will:
append the email to the work item
mark the work item with ‘new information received’
In addition, if the Wait type is 'Waiting for more information', the system will:
change the state of the work item from WAITING to TO DO
As a result of the change in state to TO DO, a Queue and assignee will be set to the work item and it will move back to the responsible agent’s Enate Inbox, marked with ‘new information received’
If the work item is an Action and both the Action and its parent Case are in a state of WAITING with a wait type of Waiting for more information, the state of the parent Case will change to IN PROGRESS
The same rules apply to other auto-generated incoming emails that are matched to an existing work item in a state of Waiting or Waiting for more Information (i.e. incoming Out of Office emails are treated in exactly the same was as other incoming auto-generated emails in this state). Please see this section for more information on how the system detects auto-generated emails.
If the incoming 'Out of Office' email is matched to an existing work item that is in a state of RESOLVED (note that only Cases and Tickets can be in a state of RESOLVED), the system will:
Append the email to the work item
Reopen the work item and set it back to TO DO
As a result of the change in state to TO DO, a Queue and assignee will be set to the work item and it will move back to the responsible agent’s Enate Inbox, marked with ‘new information received’.
The same rules apply to other auto-generated incoming emails that are matched to an existing work item in a state of RESOLVED (i.e. incoming Out of Office emails are treated in exactly the same was as other incoming auto-generated emails in this state). Please see this section for more information on how the system detects auto-generated emails.
If the incoming 'Out of Office' email is matched to an existing work item that is in a state of CLOSED, the system may take various courses of action depending upon the type of work item:
The system will firstly ‘go up’ the work item chain to look for a parent work item e.g.
if the email is matched to an Action that is CLOSED, the system will see if the Action’s parent Case is still open.
if the email is matched to a Case that is CLOSED, the system will see if the Case has a parent Case or Ticket that is still open.
if the email is matched to a Ticket that is CLOSED, the system will see if the Ticket has a parent Ticket that is still open.
If the system does find a parent work item that is still open, the system will then apply the rest of the email processing logic to the parent work item (i.e. all of the logic in the above sections on running work items).
If the system cannot find a parent work item that is still open, the incoming email will NOT be appended to the already closed work item. It will instead create a new work item following the rules below for what happens when the system is unable to match an email to an existing work item.
The same rules apply to other auto-generated incoming emails that are matched to an existing work item in a state of CLOSED (i.e. incoming Out of Office emails are treated in exactly the same was as other incoming auto-generated emails in this state). Please see this section for more information on how the system detects auto-generated emails.
If no information can be identified to link the incoming 'Out of Office' email to a currently running work item, the system will generate a brand new work item (Ticket or Case) based on the email’s configured routing rules.
If a Ticket has been created, even if the email route settings specified in Builder have the ‘send response’ option set to ‘on’, a confirmation email will NOT be automatically sent back out to the to the email address that the 'Out of Office' email originated from as the 'Disable Automated Emails' option will be automatically switched on.
Details regarding email deduplication - common Email Server behaviour with how they can create duplicate emails, and subsequent behaviour in Enate
As part of day-to-day processing in Email systems and integration with other systems, it is possible for errors to result in duplicate emails. To combat this Enate provides built-in capabilities to deduplicate received emails. Let’s take a look at the details for this.
As a core principle, Enate will generate or update 1 work item per recipient per received Email after deduplication. A recipient is either an existing work item or an address defined by an email route.
To guard against accidental creation of multiple work items caused by duplicate incoming emails, Enate checks for such duplicates and deduplicates them so that only one work item is created.
Enate looks for duplicates in 3 ways:
The first method considers the entire content of the email, including not just the user-visible content such as Subject, Body, Senders, Recipient, Attachments, etc but also the underlying email information such as the email headers.
(Use case: We have requested IMAP server to delete email, but the server implements delayed delete. Next time we check for emails we receive the email that we asked it to delete again.)
The second method considers a subset of the user visible content, but does not consider most of the underlying email headers.
(Use case: The same email was sent to a mailbox and one of its aliases, OR addressed to multiple work items on the same connector)
The third method only considers a subset of user visible content - excluding the body of the email - and the hidden unique identifier of the message, if available.
(Use case: The same email was sent to a mailbox and one of its aliases, OR addressed to multiple work items on the same connecto.r)
If any of the above methods determines that the email is a duplicate, then the email is considered to be a duplicate.
In a scenario where a sender includes multiple addresses in the recipient list (To and CC) which are picked up by Enate, the system would normally receive 2 (or more) copies of the email, and the Email routing outside of Enate would determine whether it is caught as a duplicate or not. However, the duplication taking place in the Email Server infrastructure cannot be guaranteed.
Whether multiple emails are created or not in this scenario is outside the control of Enate and should be investigated with your Email Server provider or Email administration team. In our experience factors which may affect this include (but are not limited to):
If the email is sent by internal or external senders
If the recipients are real mailboxes or aliases
If transport rules are used (Exchange/Office 365)
If 3rd party antispam/antivirus products are involved in email delivery.
Due to the variability in behavior of external systems with regards to multiple emails and duplicates, we strongly advise business processes and email scenarios are tested thoroughly to ensure the desired behavior in Enate is achieved.
A work item will be created following the applicable configured routing within that mailbox - these may obviously be different, resulting in the created Work Items potentially being in different contexts (and Ticket Categories for Tickets).
Enate has some support for Emails received via BCC through the use of special Wildcard routes. As the enate mailbox is not listed in the recipient list for the email normal routes cannot work, however you are able to create a route where any recipient is allowed and the sender (from) can be used for routing purposes. See this article on Wildcard Routes for incoming BCC Emails for more information on this.
Imagine an email sent to joe@enate.net, tom@enate.net and joe@enate.io and BCCd to kevin@enate.net. Here joe@enate.io is an alias for joe@enate.net.
If the email is sent by a colleague (an internal email) then it is likely, depending on Email Infrastructure, that Joe would receive 1 email, Tom would receive 1 email and Kevin would receive 1 email.
If the email is sent by an external contact (an external email) then it is likely, depending on Email Infrastructure, that Joe would receive 2 emails, Tom would receive 1 email and Kevin would receive 1 email. Joe would see 2 identical emails in his Inbox with no discernible differences; only when viewing the Email headers would differences be identified and even then it is unlikely either email could be attributed to joe@enate.net vs joe@enate.io.
In both examples Kevin would receive the email but wouldn’t really know why – he would not be able to identify himself as a recipient in the To or CC fields and the BCC field is not shown.
The impact of these 2 examples if received by Enate is that for the first example (sent from internal):
1 email would be received in the mailbox joe@enate.net.
1 email would follow the configured routing rules for joe@enate.net and jo@enate.io resulting in 2 work items.
1 email would be received in the mailbox tom@enate.net which would follow the configured routing rules resulting in 1 Work Item.
1 email would be received in the mailbox kevin@enate.net but routing rules on this Email Connector wouldn’t match any of the To or CC addresses, so it will be made available in unprocessed view unless a route had been added to create a work item based on the from address.
In the second example (sent from external):
2 emails would be received in the mailbox joe@enate.net.
1 email would follow the configured routing rules for joe@enate.net and joe@enate.io resulting in 2 work items.
1 email would be received in the mailbox joe@enate.io which would be treated as a duplicate.
1 email would be received in the mailbox tom@enate.net. Same as for Internal, behaviour would be as above would result in 1 work item.
1 email would be received in the mailbox kevin@enate.net, but routing rules on this Email Connector wouldn’t match any of the To or CC addresses, so it will be made available in unprocessed view unless a route had been added to create a work item based on the from address.
Notice how in either case the end result is the same
To add a new email connector click on the ‘+’ icon at the top right of the Email Connectors page, select 'Email Connector' and fill out the details in the resulting popup.
The attributes to configure are:
You must also set a fallback email route for the primary email address of each email mailbox in your system.
This will ensure that any mails arriving to that connector which don't get handled by the various email routes configured will at least be handled by this fallback and will kick off the Case or Ticket it routes to.
When setting a fallback route you must define the work item that should be created for an email coming into that connector (if not picked up by any other email routes), i.e. the specific Ticket or Case.
You can also choose whether you want to send automatic emails (such as request acknowledgement emails) to the work item's contact when a work item has been created via the fallback route by selecting the 'Send Automated Emails' option.
You can also choose whether you want your fallback email route to only create work items in test mode by selecting the 'Only create work in test mode' option.
After your system has been upgraded to v2022.5, Email Connectors which do not yet have a fallback route defined will still work, and as such would still potentially allow some incoming emails to be unprocessed if they are not picked up by any of the existing email routes. However, you should be aware of the following when configuring Email Connectors after upgrade:
Any NEW Connectors which you create MUST have a fallback route specified in order to be saved and set live.
Any EXISTING Connectors which you EDIT MUST also have a fallback route specified in order for you to save your changes. The Save option will be disabled until you have specified a fallback route.
During the upgrade to 2022.5, Enate will assess all the existing Email Routes for each Connector in your system attempt to automatically set one of these for each Connector as its fallback route. In order to qualify as an acceptable fallback route, the email route must meet the following criteria:
Its email must match the primary email address or be set as a catch-all '*' wildcard.
No additional Routing Rules must exist for the Email Route.
It must have a Ticket or Case route already defined for it.
It must already be the last route in the ordered set of Routes for that Connector.
It must already be Enabled.
If an Email Route for a connector meets the above criteria, its route settings will be added to the Connector (displaying in the Connector details popup), and certain aspects of the Route's configuration will become locked down, in order to ensure it remains as the fallback route. See section below for details of this.
Whether it be as a result of auto-selecting during upgrade, or manual definition of the email route afterwards within the Connector, the email routes which have been specified will then show in your Email routes section with some specific impacts.
Details of this are as follows:
These routes will always display at the foot of the Email Routes list
The Routing Rule will be set to read-only
The Email Connector will be set to read-only
The 'Enable' setting is set to ON, and is read-only
Once you have configured the required information you must then test the connection. To do this, click on the 'Test Connection' button.
Once the connection has been tested successfully, you can then enable the connector by switching on the 'Enable' toggle.
The connection will not run with unless 'Enable' is switched on.
You can edit an email connector by clicking on the ellipsis and choosing 'Edit'.
When editing an email connector, you are also able to see its activity history by clicking on the Show Activity button. You can see when the email connector was created and by who, as well as if any edits have been made to the email connector, when they were made and by who.
The system has a default outgoing email Connector called ‘System Default SMTP Gateway’ for standard system activities e.g. User Welcome emails etc.
This section details what happens when subsequent response emails are sent into Enate after an initial work item has been created. These could be sent by the original sender, or by other people included in the original email ('cc' or 'To' recipients) who may have no link to the Enate system.
..an email being sent by JohnJones@Customer.com to multiple people, including into a specific department in your service centre linked to 'FR@SampleCorp.com', resulting in creation of a Ticket T-1234, and an acknowledgement email sent back out to Original Sender, cc'd to those cc'd on the original incoming email.
A number of different scenarios are detailed in the table further below, however there is a fairly standard overall logic of how subsequent incoming emails are treated by Enate when running in 'Traditional' mode, if you need a 'rule of thumb'..
Standard - If you respond to a mail that includes a connector email address, the mail will get appended to the work item that connector created.
Add New Connector - If you add a new connector email address into a response email, a new work item will be created, linked to the initial work item. If the original connector email address is still in the email addresses, the email will also append to that original work item."
BCC - If the connector email address is only a BCC, the email will sit in 'unhandled emails', unless you have a fallback rule set up which routes mails with that 'from' address.
Split - If a ticket is split and you respond to the original ticket, it will get appended to all of the resulting split tickets.
Merge - If a ticket gets merged and you respond to the original ticket, it will get appended to the remaining merged ticket.
Case - If a ticket gets promoted to a Case and you respond to the original ticket, it will get appended to the Case.
| Description | Example details | Behaviour |
|---|---|---|
When incoming emails have the relevant Enate email address as the Bcc'd, they do not have a 'To' address visible to the system and so are plaeced in the Unprocessed emails list.
To help reduce the ocurrences of such mails landing in 'Unprocessed emails' in this situation, you can configure Wilcard Email Routes which essentially use the knowledge of which email addresses these mails come from to allow it to be processed. These Routes are set to match with a wildcard '*' email address (The To address of the incoming mail) and a known email address (or addresses) in the 'Sender List includes' (The From address of the incoming mail). Set in this way, they able to match even a BCC'd email if the from address matches.
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.
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.
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.
This page includes a step-by-step guide on how to prepare your Azure Active Directory setup for successfully setting up the integration between Enate and Office 365. Here is an outline of the topics that will be covered.
.
Within Azure Active Directory, every user account is granted a default collection of authorisations. The accessibility of a user's account is determined by their user category, role allocations, and possession of specific entities. Azure Active Directory has different types of user accounts, each designed with specific levels of access suited for their expected tasks.
In simpler terms, administrators have the highest access, followed by regular member accounts, and guest users have the most limited access.
Azure Active Directory uses permissions to manage the access rights given to a user or group, implemented through established rules.
Access and log in to the Microsoft Azure portal via https://portal.azure.com.
Beneath "Manage Azure Active Directory," select "View Overview Page."
You'll then land on the overview page of your Azure Active Directory tenant. You will need a user account with a global administrator role.
Under "Manage," opt for "Users," and subsequently, navigate to the "All Users" tab.
Here you can see all user accounts in your Azure Active Directory tenant.
Click on the "+" symbol to create a new user account.
Two alternatives will be presented: "Create User" or "Invite User." We'll adhere to the default preference to create a fresh user account.
Input the user details, including the username, first name, last name, and optionally include the user in existing groups.
Scroll downwards to specify the initial password, which the user will employ for their first sign-in.
Additionally, you can include the user into groups or assign Azure AD administrative permissions.
Select "Create".
You can adjust user configurations by accessing the user's name and clicking the "Edit" feature.
Log into your Microsoft 365 Admin Center.
Click on the 'Exchange' to access the Exchange Admin Portal.
Go to 'Mailboxes' and here click on 'Add shared Mailbox'.
Add a 'Display Name' for the shared mailbox and then add an email address and select a domain from the drop down list.
You can use the display name as the 'Alias'.
Click 'Create'.
After creating the shared mailbox you can add members who can receive, read and reply to the emails sent into that mailbox.
This shared mailbox will be now visible in the list of mailboxes with the RecipientType shown as SharedMailbox.
Two types of permissions are needed for successful operation of a shared mailbox.
Full Access Permission: Allows a user to open a mailbox and create and modify items in it. Send as Permission: Allows other members to send emails from this mailbox.
To enable both, click to select the shared mailbox and under 'Mailbox Permissions' select 'Manage Mailbox Delegation'.
Click on the 'Read and Manage' button and select 'Edit'. Click on 'Add Permissions. Select the users that you want to have Full Access Permission to this mailbox. Hit 'Save'. Then click on 'Close' and then 'Cancel'.
After this click 'Edit' for 'Send as' permissions. Click on 'Add Permissions. Select the users that you want to have Send as permissions to this mailbox.
The next thing you'll need to do is the App registration creation and permission restrictions but for these a Mail Enabled security group is a prerequisite. This group can be used to manage permissions, distribute emails, and provide access to various resources within your organization.
1. Creating a Mail-Enabled Security Group
In the Exchange Admin Center, go to "Recipients" and click on "Groups."
Navigate to the "Mail Enabled Security" tab and click "Add a group."
Choose "Mail Enabled Security" as the group type and click "Next."
Group Configuration
Provide a name (e.g., Editors) and optional description for the group.
Set the email address for the group.
Configure communication settings based on your requirements.
Enable owner approval if needed and click "Next."
Confirmation and Group Creation
Verify the details and click "Create group" to complete the process.
Note that it may take some time for the group to appear in your list.
Adding Members to the Security Group
Access the group in Exchange Admin Center, click on the group name, and go to the "Members" tab.
Add members by selecting "View and manage members" and clicking "Add members."
Sending a Test Message
Confirm the group's existence in the "Mail Enable Security" tab.
Send a test email to the group's email address.
Checking Received Message
Access the mailbox of a group member to confirm the receipt of the test message.
Creating an app registration establishes a trust between your application and the Microsoft identity platform. This trust is unidirectional, with your application relying on the Microsoft identity platform. Importantly, once the application object is generated, it remains tied to its original tenant and cannot be transferred to different tenants.
Follow these steps for the app registration process:
1. Sign In - Log in to the Microsoft Entra admin center with Cloud Application Administrator credentials.
2. Tenant Selection - Use the Settings icon to switch to the desired tenant from the Directories + subscriptions menu if you have access to multiple tenants.
3. App Registrations Location - Go to Identity > Applications > App registrations and select New registration.
4. Application Details Provide a display name for the application, visible during user interactions. The Application (client) ID uniquely identifies the app within the identity platform.
5. Define Sign-In Audience - Choose the appropriate account type for the intended audience:
Accounts in this organizational directory only (Single-tenant).
Accounts in any organizational directory (Multi-tenant).
Accounts in any organizational directory and personal Microsoft accounts (Broad audience).
Personal Microsoft accounts (Exclusive personal accounts).
6. Redirect URI Field - Leave the Redirect URI field blank for now; configuration will be done later.
7. Registration Execution - Click Register to complete the initial app registration.
8. Access Application ID - Visit the Overview pane in the Microsoft Entra admin center to find the Application (client) ID.
Note: Newly created app registrations are initially hidden. To make the app visible on users' My Apps page, go to Identity > Applications > Enterprise applications, select the app, and toggle Visible to users? to Yes on the Properties page.
The client ID is utilized in your application's source code or authentication library for validating security tokens from the Microsoft identity platform.
Restricting Permissions
Testing
Select "Azure Active Directory" to navigate to the Azure Active Directory "Overview"
Click the [App registrations] button to open the "App Registrations"
Select your App registration to open its details page
Click the [Certificates & secrets] button to display the "Certificates & secrets"
Select the "Client secrets" tab, if it is not yet selected.
Click the [New client secret] button to display the "Add client secret" dialogue.
Provide a brief description of the secret. This will show up in lists, making it easier to identify later.
Select a time at which the secret will expire and need to be regenerated.
Click the [Add] button to generate the Client Secret and return to the "Certificates & Secrets" value. You should see your newly-generated secret listed here. Copy and save the "Value". You will need it later.
IMPORTANT: After you navigate away from this page, there is no way to retrieve the Secret Value. If you do not copy and save it now, you will need to regenerate a Secret. Keep this secret in a safe place - in Azure Key Vault or in a secure folder. If it is compromised, a hacker can access your API with this service identity.
Establishing Certificate-based Authentication
Establishing authentication through certificates involves a multi-step process. After successfully configuring the entire chain, it's beneficial to disseminate the information for others' convenience.
Reviewing the provided sequence diagram, the initial phase entails the client generating certificates and sharing the public certificate with the server. While utilizing a self-signed certificate suffices for development and testing, it is advisable to employ a CA-signed certificate for production.
Execute the following PowerShell code:
New-SelfSignedCertificate -Subject “CN=CertForMyApp” -CertStoreLocation “Cert:\CurrentUser\My” -KeyExportPolicy Exportable -KeySpec Signature
The initial client step involves generating certificates and sharing the public certificate with the server. For production, prefer a CA-signed certificate over a self-signed one.
Execute the provided PowerShell code to create a self-signed certificate. Note the hex value of the thumbprint for later use.
Export certificates and keys:
Open "mmc" via the Windows search box.
Add "Certificates — Current User" to the selected snap-ins.
Locate the created certificate under Personal > Certificate.
Right-click on the certificate, select All Tasks > Export.
Choose Base-64 encoded X.509 (.CER) format, specify a location and filename, and complete the export.
The exported .CER file is the public certificate to share with the server and upload to Azure AD during app registration.
Private key extraction:
In the mmc application, right-click on the certificate, select All Tasks > Export.
Choose to export the private key, set a password, and complete the export. The private key is in .PFX format.
Utilize SSL Converter to convert the .PFX to .PEM format, containing public (.crt) and private (.key) key files.
Register the app on Azure AD and upload the public certificate:
Follow the steps in the provided link, noting tenant_id and client_id.
Add a certificate, upload the public certificate (.cer) file, and complete the process.
Initial registration and key exchange are complete. Proceed with the API sequence flow:
Retrieve the bearer token from Azure AD.
Base64 encode the hex thumbprint using a tool or Python script.
Use the encoded thumbprint to create a signed JWT token.
Code for JWT token creation:
Here's a breakdown of the script:
Prompt for Password:
This line prompts the user to enter a password securely for the private key and stores it in the variable $pw as a secure string.
Prompt for Certificate Name:
This line prompts the user to enter a name for the certificate and stores it in the variable $name.
Create Self-Signed Certificate:
This section creates a self-signed certificate using the provided name and subject. The certificate is stored in the variable $Cert.
Export Certificate with Private Key to PFX:
This part exports the certificate along with the private key to a PFX file on the user's desktop, using the password entered earlier.
Export Certificate with Public Key Only to CER:
Finally, this section exports the certificate with only the public key to a CER file on the user's desktop.
Make sure to handle the generated files securely, especially the PFX file containing the private key, as it requires the password entered during the script execution.
Finally, execute a GET request to "https://login.microsoftonline.com/<tenant_id>/oauth2/token" with the specified parameters to obtain the bearer token for API calls.
When new emails arrive into Enate, the system analyses the email to determine whether it’s a brand new request or related to an existing one, and then determines how to proceed.
The options for email processing are as follows:
Plus Addressing OFF - Plus Addressing is completely disabled and emails are matched using the only (i.e. those not used in Plus Addressing).
Mixed Mode - Plus Addressing is enabled and emails are matched using both plus addressing AND the standard processing rules .
Plus Addressing Only - Plus Addressing is enabled and emails are matched using .
The setting for this is made in the 'Work Item 'Plus Addressing'' section of Builder's System Settings.
Note that the default value is set to 'Plus Addressing OFF'.
Depending on how your email server is configured / what changes you may have recently made, here is our recommendations for which of these modes to use:
If your email server is configured to support plus addressing, we recommend that you use Plus Addressing Only.
If you are transitioning from Plus Addressing OFF mode to include plus addressing, we recommend that you use Mixed mode for a short amount of time to ease the transition before switching to Plus Addressing Only mode.
If your email server is not configured to support plus addressing, you should use Plus Addressing OFF mode.
Important Note: You should only switch Plus Addressing on in Enate AFTER your Email Administrators have confirmed that your email servers are set up to support Plus Addressing.
Plus Addressing is an industry-defined feature which allows the automatic addition of information into an email address when a mail is being composed. Systems can then subsequently use this additional information if they know to look for it within the email addresses, while still ensuring that the mail gets to its intended recipients. In Enate, we make use of Plus Addressing by automatically adding the reference number of a Case, Action or Ticket (e.g. '101203-T') into the email address of any emails that we know should be being subsequently shared with that work item.
Adding this extra information into the email addresses of mails relating to work items allows us to run an additional layer of processing logic for any response emails which come back in as responses from them. The logic is fairly simple: If a work item reference number is recognized as part of any of an email's target mail addresses, that mail is shared with that work item.
Another way to think of this is that with Plus Addressing addressing each work item gets its own email address.
Doing this massively reduces the chances of creating unnecessary work items when sending emails back and forth - particularly useful when there are multiple separate work items being actioned across multiple separate teams in Enate to deal with larger queries.
If an Agent is emailing out a reply to a query that has arrived into the mailbox 'info@enate.io', upon sending the emailback out, Enate will auto-populate the From email address with a plus sign (+) followed by the reference number of the work item as a tag, so the From email address coming out of Enate will look something like this: 'info+123-T@enate.io'. The underlying structure of this is: [email connector address][+EnateRef]@[email domain].
Similarly, if the person sending the email out from Enate includes other Enate email addresses (e.g. they're copying in other internal departments) where there might also be a linked work item the email could be shared to, the system will allow the sender to share their mail with these other departments - it does this by adding in further work item references to the other departments' email addresses.
Additional advantage: Plus Addressing can match an email with multiple work items. The standard email processing rules can only match an email with one work item.
In Plus Addressing OFF mode Plus Addressing is not used, so incoming emails will be matched using the standard email processing rules. Plus Addressing OFF mode will match with a single work item. Plus Addressing matches with multiple relevant work items, if they exist.
The system will look at the following list of criteria in order and if it finds a match, it will stop searching (i.e. first one wins). The order this runs in is as follows:
1) Header ‘in-reply-to’ value – the ‘in reply to’ value in the header of the email. This value has the following structure:
<‘Unique email GUID’.’work item GUID’@‘Enate server that sent the email’.enate>
e.g. <d23a9d57-6006-4ab7-a412-8ca8ece2f3aa.2b8586bb-ef95-4020-9cf8-ed56a059b47e@SendingServerName.enate>
2) Unique identifier in email message body - If the incoming email has been sent as a response to an email which was sent out from Enate, it will likely contain a unique identifier tag as part of the email body text.
3) Work item reference in email subject
4) Work item reference in email message body
If no information can be identified to link the email to a currently running work item, the system will generate a brand new work item (Ticket or Case) based on the email’s configured routing rules. A confirmation email will be automatically sent back out to the requesting email address containing the reference number if the email route settings specified in Builder have ‘send response’ set to ‘on’.
If your email server is not configured to support plus addressing, you should use Plus Addressing OFF mode.
In mixed mode, Plus Addressing is enabled and emails are matched using BOTH:
Plus Addressing (to potentially multiple work items) AND
If no information can be identified to link the email to a currently running work item, the system will generate a brand new work item (Ticket or Case) based on the email’s configured routing rules. A confirmation email will be automatically sent back out to the requesting email address containing the reference number if the email route settings specified in Builder have ‘send response’ set to ‘on’.
If your email server is configured to support plus addressing and you are transitioning from Plus Addressing OFF mode to plus addressing, we recommend that you use mixed mode for a temporary period to ease the transition before switching to Plus Addressing Only mode.
This is because any emails sent out before plus addressing was introduced will NOT contain plus Addressing information in the email addresses of any response emails coming back into the system. If you were running Plus Addressing Only mode, such emails would not be able to find a match and so would lead to undesirable creation of new work items, rather than matching to an existing work item.
Once you are comfortable that there are no / very few work items in your system which are still open but which started before Plus Addressing was enabled, you can then consider if you wish to move to Plus Addressing Only mode.
In Plus Addressing Only mode, Plus Addressing is enabled and emails are matched ONLY through Plus Addressing. This means that when new emails arrive into Enate, the system analyses the email according to the Plus Addressing rules and then determines how to proceed.
Note: Plus Addressing OFF mode will match with a single work item. Plus Addressing matches with multiple relevant work items, if they exist.
1) Plus Addressing used in the email address section - if a work item reference number is recognized as part of any of an email's target mail addresses, that mail is shared with that work item.
The underlying structure of this is: [email connector address][+EnateRef][@email domain]
e.g. 'info+123-T@enate.io
If no information can be identified to link the email to a currently running work item, the system will generate a brand new work item (Ticket or Case) based on the email’s configured routing rules. A confirmation email will be automatically sent back out to the requesting email address containing the reference number if the email route settings specified in Builder have ‘send response’ set to ‘on’.
You might ask why you would bother moving on from Mixed mode into full Plus Addressing Only mode? Here is a business scenario which explains why running in fully Plus Addressing Only mode can be advantageous:
You can have a scenario where a query is sent in to the IT department. IT team sends a response back out from Enate informing the requester that this needs to be dealt with by HR (they may even even create a new Linked work item to for the HR department. Either way, further correspondence from the requester needs to go to the HR department, not the IT department.
If the original requester sends an email back in, removing the IT department's mailing address and making sure it is only being sent to the HR email address. How will this work in Mixed vs. Plus Addressing Only mode?
If you are running in Mixed mode, there could well be the original 'guid' stamp in the email chain which states 'this came out of Enate from the IT department'. So Enate will use the standard email processing rules to match the incoming mail with the IT department's work item which is NOT what is wanted here.
If pure Plus Addressing is used (i.e. Plus Addressing Only mode), then the mail won't go to the IT department. It will go to the HR department - either as a brand new request (if no plus addressing data was found), or into the existing HR request if plus addressing data for an HR work item was injected into the mail chain in a previous step.
In circumstances such as this where you want to fully switch a work item away from a department/team that was previously involved, you would want to use Plus Addressing Only mode and NOT Mixed mode. So, once you're comfortable that all open work items come from the point where Plus Addressing was switched on or later, we recommend you move to Plus Addressing Only mode.
If an agent writing an outgoing mail includes an email address which Enate knows is linked to an Enate mailbox, when they click to send the mail Enate will display a popup showing them: - All currently linked work items which were created as a result of a mail into that same mailbox - An option to create a NEW (automatically linked) work item.
Once the agent has chosen existing work items / created a new linked work item(s) to share their mail with, the mail will be shared with them, and the email will be sent out to any external / non-Enate using parties. Additionally, the work item references of THIS work item AND the ones it is behind shared with will be added into the respective relevant mail addresses which are part of the outgoing mail. This ensures that on ALL subsequent email exchanges - coming either from internal parties or external / non-Enate parties, those work item 'tags' in the addresses route the mail to share it with the required work items. Further things to note...
If an incoming mail is replying to a closed work item, the system will create new one.
Live and test items cannot be addressed in a single mail.
There is an option to hide work item matching data in email addresses when using Plus Addressing. This is available just in the System Settings section of Builder, just below where you choose your Email Processing mode.
Enabling this will add a 'Reply To' header for outbound emails where work item matching data will NOT display as plus addresses in the 'From' address.
The impact of this is that if the setting is enabled, instead of seeing emails with
'jane.smith+12345-T@acmecorp.org' in the from field, it will instead show simply as
'jane.smith@acmecorp.org'.
Note that this option is set to off by default.
You must enable Plus Addressing in whichever email system you are using.
This article takes you through how to enable Plus Addressing in Microsoft 365:
This article shows you how to enable Plus Addressing in Gmail:
| Activity | Rule | Related API |
|---|---|---|
To configure integration between Enate and Office 365, each unique Enate instance must be registered with the Microsoft Identity Platform in the Azure AD of the Office 365 tenant to which you need to establish connectivity.
Log into the and search for Azure Active Directory
Check out this article showing how is improved by this approach.
The standard email processing rules (which stops after it matches with a single work item). See for an explanation of the standard email processing rules.
If your email server is configured to support plus addressing, we recommend that you use Plus Addressing Only mode. However, if you are transitioning from Plus Addressing OFF mode to include plus addressing, we recommend that you use mixed mode for a short amount of time to ease the transition before switching to Plus Addressing Only mode. See for more information.
See for further details.
Attribute
Comments
Email Connector Name
Your Enate-friendly name – you can enter anything you like here as a name.
Email Service
List of available email Services which can be used for email connectors. Options available are:
Gmail (POP3)
Gmail (IMAP)
Office 365 (POP3)
Office 365 (IMAP)
Office 365 (Graph)
Other - if you select the ‘Other’ option for Email Service, you will need to specify the incoming and/or outgoing email server information, including server address, port and SSL
Username
The email address / username
Password
The email address password. Maximum of 50 characters.
Primary Email Address
The email address of your connector. If you have multiple email addresses linked to the same mailbox, you must note the primary email address.
Can access additional mailbox
If you want to access an additional mailbox which has the same login information as this, tick the box and add the mailbox name here
Use for
Options are:
Incoming: Emails create new Tickets / Cases or link to existing.
Outgoing: Mails can be sent OUT from the system via this mailbox. If you want to reference this email connector in e.g. ‘from email address’ settings etc. within Ticket/Case configuration, you must set it as ‘outgoing/ both’ for this to work.
Both
People start replying on the email chain
a colleague responds to the original email, retaining 'fr@samplecorp.com' as the relevant service centre email address.
The new email is appended to Ticket T-1234, because Enate recognizes this as a mail relating to mail which started T-1234.
People start replying on the email chain, AND adds in a new service centre email address.
a colleague responds with a 'reply all', but also adds in 'ma@samplecorp.com' as one of the addresses.
Enate Creates a new ticket T-1235, based on a mail arriving into 'fr@samplecorp.com'. The email is also appended to Ticket T-1234, which continues as normal. (T-1234 & T-1235 get linked).
Simple Reply Original sender hit 'reply' to the Auto-response email out from Enate.
John.Jones@Customer.com sends reply email back in to fr@samplecorp.com.
The new email is appended to Ticket T-1234.
Original Sender hits 'reply all' to the automated acknowledgement AND adds a new service address AND a new colleague. New colleague then replies to original sender's second email with a 'Reply All'.
John.Jones@Customer.com sends reply all email back in to fr@samplecorp.com, add 'ma@samplecorp.com' and 'James.Smith@Customer.com'. James then sends a Reply ALL
Enate Creates a new ticket T-1235, based on a mail arriving into 'fr@samplecorp.com'. The email is also appended to Ticket T-1234, which continues as normal. (T-1234 & T-1235 get linked). The subsequent email, from James, gets attached to BOTH tickets (as it is addressed to fr@samplecorp.com AND ma@samplecorp.com
A person who was cc'd on the original email hits 'Reply All' to the original email AND adds a new service centre email. Then another colleage hits replay all on that email.
James (cc'd on original) sends a Reply All to original email, and adds in 'Andrew.Jones@Customer.com' AND 'ma@samplecorp.com'. Andrew then sends a 'Reply All' to that email.
Enate Creates a new ticket T-1235, based on a mail arriving into 'fr@samplecorp.com'. The email is also appended to Ticket T-1234, which continues as normal. (T-1234 & T-1235 get linked). The subsequent email, from James, gets attached to BOTH tickets (as it is addressed to fr@samplecorp.com AND ma@samplecorp.com
A person who was cc'd on the original email hits 'Reply All' to the original email but SWAPS IN a new service centre email. Then another colleague hits replay all on that email.
James (cc'd on original) sends a Reply All to original email, removing 'fr@samplecorp.com' and adding in 'ma@samplecorp.com'.
Enate Creates a new ticket T-1235, based on a mail arriving into 'fr@samplecorp.com'.
One of the original email recipients replies to the original email, but moes the service centre address to BCC (NO Wildcard Route is configured for the From address).
James (cc'd on original) sends a Reply All to original email, moving 'fr@samplecorp.com' to be a 'bcc'.
Goes to 'Unprocessed Emails'
One of the original email recipients replies to the original email, but moes the service centre address to BCC (however a Wildcard Route IS configured for the From address).
James (cc'd on original) sends a Reply All to original email, moving 'fr@samplecorp.com' to be a 'bcc'.
Enate Creates a new ticket T-1235, based on finding a wildcard route for the 'from' address.
Convert to Case: An agent converts the Ticket into a Case. An acknowledgement email is sent to the user, which they reply to.
Service Agent converts T-1234 to C-1234, auto-sending out an acknowledgement email. Original sender responds to this mail.
Email gets appended to Case C-1234
Split Ticket: Ticket gets split into 2 tickets. Original Sender sends a 'reply all' mail to the initial mail which created the main 'parent' Ticket.
Servic Agent splits T-1234 into T-1235 & T-1236. John sends a 'Reply All' to T-1234 confirmation mail.
Email gets appended to T-1234, AND to T-1235 & T-1236
Merge Ticket: Ticket gets merged into another (and so is closed). Original Sender hits 'reply all' to their orignal email.
Servic Agent merges T-1234 and another ticket, T-1235, together. T-1245 closes as a result. John sends a 'Reply All' to T-1234 confirmation mail.
Email gets appended to T-1235
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
