Links
Comment on page

Incoming Emails - Processing Logic

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 Email Processing Modes - Options 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:

Sending an Incoming Email to an existing running work item

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 section below for more information on how the system detects auto-generated emails.

Sending an Incoming Email to a work item in a state of Waiting

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
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 section below for more information on how the system detects auto-generated emails.

Sending an Incoming Email to a Resolved Work Item (Case & Ticket)

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’.
The same rules apply to auto-generated emails that are matched to an existing work item in a state of RESOLVED. Please see the section below for more information on how the system detects auto-generated emails.

Sending an Incoming Email to a Closed Work Item

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 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, and copy all the information (comms, files, defects, contacts and custom data) from the existing closed work item to the new work item.

If unable to match an incoming email to an existing work item

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’.

Further specifics

  • 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.

Auto-Generated Emails Detection Logic

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 « <<>> »
​

Important Note - Incoming Emails 'From' your Enate instance will be ignored

If an incoming email being received by Enate has a 'From' mail address which has been used in the configuration settings of a Ticket / Case or Acton in that system, including retired versions, Enate will NOT append the email to a Work Item, nor will it create a new Work Item.
You should therefore pay particular attention to the setup of emails are arriving into an Enate instance which have a from address which has been used in that system's Work Item configuration, as the above behaviour will very likely preclude this. The email does NOT need to have originated from the same Enate instance, it only needs to have a From address that is being used in that instance. Additional attention should also be made for e.g. test mail accounts you select to send test emails into Enate.
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.