Working with email threads
Glossary Item Box
Introduction
The mechanism for creating email threads is available in bpm’online since version 7.10.0. The main purpose of this mechanism is to improve the email interface. Use this mechanism to easily find email connections, e.g. by copying the connections of the previous email.
The thread construction mechanism is based on the In-Reply-To email header data. According to generally accepted agreements, this header should contain the Message-ID email identifier. The bpm'online application retrieves these headers from the synchronized Email service (IMAP / Exchange).
The mechanism can be divided into two logical parts – creating threads and populating activity connection fields.
Creating email threads
The EmailMessageData detail contains 3 fields:
- MessageId – a string of 500 characters in length;
- InReplyTo – a string of 500 characters in length;
- ParentMessageId – a lookup field that references the EmailMessageData detail.
The MessageId and InReplyTo fields are populated with the corresponding message header values during synchronization.
The ParentMessageId field is populated with the following values:
- The EmailMessageData table searches for records where MessageId is identical to InReplyTo. The first found record is set as the current ParentMessageId.
- The ParentMessageId field is populated with the current Id value in all EmailMessageData records if the InReplyTo field of these records is identical to the MessageId field.
Email thread connections are updated for every email.
Copying previous email connections in a thread
Spreading activity connections across the thread upon adding an email. The [Case] field is used in this case.
A parent record with the activity that includes the populated [Contact] field is searched for the current EmailMessageData record. The [Case] field values from this activity will be spread across the thread. Starting with the found EmailMessageData record, all child EmailMessageData records are found and their [Case] field value is updated.
A thread with 3 emails:
| ActivityId | Title | CaseId | EmailMessageId | EmailMessageParentId |
|---|---|---|---|---|
| 28BD6D59-B9D7-4FF9-89F5-FEE1DD003912 | Re: relation | NULL | 66812FBF-411B-4FE0-94C9-1E70FBBEB2D3 | F05B529D-C98C-4E26-BE00-21F8721AEF58 |
| DC0A40D4-700A-40EB-B394-90E0376C3B5D | Re: relation | 1C6E18E3-48B1-495E-8EF9-ACA35DB9DE0B | F05B529D-C98C-4E26-BE00-21F8721AEF58 | E1A0120E-B7C0-4261-9DE0-C63341BF1E0B |
| D7A9B82C-ED46-437C-980A-B2650D4FF3DA | relation | 906909E8-4D64-47FD-AF92-B65B0826AEC3 | E1A0120E-B7C0-4261-9DE0-C63341BF1E0B | NULL |
Another email is received in the thread:
| ActivityId | Title | CaseId | EmailMessageId | EmailMessageParentId |
|---|---|---|---|---|
| 6623B052-73AD-4AE5-AE61-A6F9BCD930A0 | Re: relation | NULL | 60C00B01-D0BF-40F6-923E-1830E433AEA1 | 66812FBF-411B-4FE0-94C9-1E70FBBEB2D3 |
| 28BD6D59-B9D7-4FF9-89F5-FEE1DD003912 | Re: relation | NULL | 66812FBF-411B-4FE0-94C9-1E70FBBEB2D3 | F05B529D-C98C-4E26-BE00-21F8721AEF58 |
| DC0A40D4-700A-40EB-B394-90E0376C3B5D | Re: relation | 1C6E18E3-48B1-495E-8EF9-ACA35DB9DE0B | F05B529D-C98C-4E26-BE00-21F8721AEF58 | E1A0120E-B7C0-4261-9DE0-C63341BF1E0B |
| D7A9B82C-ED46-437C-980A-B2650D4FF3DA | relation | 906909E8-4D64-47FD-AF92-B65B0826AEC3 | E1A0120E-B7C0-4261-9DE0-C63341BF1E0B | NULL |
Starting with the record in which EmailMessageId is "60C00B01-D0BF-40F6-923E-1830E433AEA1", a record with the populated CaseId column is searched (does not contain NULL). This is a record where EmailMessageId = "F05B529D-C98C-4E26-BE00-21F8721AEF58", and CaseId = "1C6E18E3-48B1-495E-8EF9-ACA35DB9DE0B".
Now, starting with the record in which EmailMessageId is "F05B529D-C98C-4E26-BE00-21F8721AEF58", bpm’online updates the value of the CaseId field for the connected records throughout the thread.
| ActivityId | Title | CaseId | EmailMessageId | EmailMessageParentId |
|---|---|---|---|---|
| 6623B052-73AD-4AE5-AE61-A6F9BCD930A0 | Re: relation | 1C6E18E3-48B1-495E-8EF9-ACA35DB9DE0B | 60C00B01-D0BF-40F6-923E-1830E433AEA1 | 66812FBF-411B-4FE0-94C9-1E70FBBEB2D3 |
| 28BD6D59-B9D7-4FF9-89F5-FEE1DD003912 | Re: relation | 1C6E18E3-48B1-495E-8EF9-ACA35DB9DE0B | 66812FBF-411B-4FE0-94C9-1E70FBBEB2D3 | F05B529D-C98C-4E26-BE00-21F8721AEF58 |
| DC0A40D4-700A-40EB-B394-90E0376C3B5D | Re: relation | 1C6E18E3-48B1-495E-8EF9-ACA35DB9DE0B | F05B529D-C98C-4E26-BE00-21F8721AEF58 | E1A0120E-B7C0-4261-9DE0-C63341BF1E0B |
| D7A9B82C-ED46-437C-980A-B2650D4FF3DA | relation | 906909E8-4D64-47FD-AF92-B65B0826AEC3 | E1A0120E-B7C0-4261-9DE0-C63341BF1E0B | NULL |
 |
NOTE Mail servers sometimes send out letters in the wrong sequence, disregarding the way they were written in the thread (e.g. during synchronization, emails are received first from the inbox and then from the outbox). This complicates the mechanism. Building a thread for the emails that were not received consistently is impossible during synchronization. In that case, a thread can be built once the synchronization is complete. If certain mailbox folders are not loaded, or if the conversation was interrupted by other participants, the thread search logic may not work. However, the thread can be built when all emails are downloaded from the inbox in most cases. |
Recommendations for adding a custom search process for all thread connections after downloading an email
Use the following guidelines to start working on a new email after thread formation:
- The Id field of the synchronization session appears in the EmailMessageData table (the values are unique for all synchronization processes). This field is populated only for synchronized emails.
- A record is added to the new FinishedSyncSession table if at least one email was received during synchronization.
- Certain processes that responded to the signal of saving activities now respond to the (Inserted) insertion signal of the FinishedSyncSession object. Emails from EmailMessageData are selected based on the synchronization session Id. The MailboxSyncSettings field of the EmailMessageData object can be used to select Email messages from the service box.
