Incoming Emails - Processing Logic

How does Enate match an incoming email?

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.

They system will look at multiple different 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-[e-mail]>

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

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.

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