Understanding the Email Message-ID
The Message-ID is generated as unique for each email message in the system, and is shown inside the email header.
If the emails look exactly the same but have different message-IDs, that is an indication the messages are duplicates created by the sending server, where the email was generated.
If the message-IDs are the same, that it is an indication there was no duplicate email sent, but the email server receiving and delivering the message has delivered the exact same message more than once.
One scenario where the same message may be delivered more than once by the receiving email server is when the same recipient is listed with their individual email address and with a distribution list they are a member of. The mail server administrator can control the behaviour on their mail server for this scenario.
- Check the recipient list of the email in the instance.
- Does it show a distribution list and individual recipients? Are the people receiving the duplicate in the distribution list and added as an individual recipient?
- If there is concern the duplicate is created by the sending server, we would want to see an example of a duplicate email where the recipients do not include a distribution list.
When the message-ID is not unique in multiple emails that look exactly the same, turn on the system property glide.pop.debug. After sending the message again, the instance log should provide an output similar to "duplicate of message-id".
Identifying duplicate emails
In order to locate and retrieve email messages suspected to be duplicates to provide them to an email administrator:
- Go to the sys_email table and use appropriate filters on timestamps, subjects, senders, etc.
- Customize the list view to display the message-ID
- Notice if the suspected emails have the same message-ID or different message-ID
- Give this message-IDs to the email administrator to find out if the mail server sent these two email messages
In order to determine which of the emails are for the same Email Notification or if they are different email notifications sent at the same time. Follow the steps below to obtain a list of all duplicate emails in question:
- Navigate to the record showing the e-mail issue and obtain the sys_id.
- Navigate to table [sys_email] and search by target=sys_id.
- Review the time stamp and the recipients to find the same email to help limit the list to the same e-mails.
- Open these emails
- Check the Email Log related list. Note of the Email Notification and the Event used.
- Note the duplicate emails as the ones with same value for the event and email notification.
For example we may find three email records sent, one generated by an event called "incident.assigned", the other two generated by an event called "incident.assigned.to.group", which has fired a duplicate notification.
Navigate to the record for the email notification (System Policy > Email Notifications) in question and take note of the conditions for the email notification.
Troubleshooting Business Rules
Retrieve all the Business Rules that might be triggering the email notifications, where current.update is used in the Script field. If a business rule is running on "After" and it contains "current.update", this may be the cause of the duplicate email. Note the conditions for the business rule and which fields on the current record it updates. For example:
The condition on this "After" business rule runs if "Assignment Group" IS set, and "Assigned To" IS NOT set.
"!current.assignment_group.nil() && current.assigned_to.nil()"
This business rule will modify the current.assigned_to field, and then run current.update().
Look at the Activity History for the record in question and take note of the state of the fields for the record at the time of each update. Match up the state of the fields in the record to the conditions in the email notification.
Note: The first update should match the conditions in the email.
Looking for the event(s) in question that were created for the record, you should see two unique records for the same event created at the same time. The first event inserted refers to the incidents' initial insert or update (which ever was the case), and the second event refers to the *updated* record that occurred during the running of the After business rule which runs "current.update()". This is one of the reasons we recommend *not* running current.update or current.insert in a business rule.
Because there are really two actions here- the initial insert or update, and the second update, there are two events generated. This is a special case, because the first insert or update has not even completed yet when the current.update() in the business rule runs. So the business rule which is responsible for "processing the events" gets evaluated twice, and in both cases the record is considered "updated"- The email notification condition evaluates to true in both cases- and two events are generated.
You will need to modify this series of events so that the update to the current record occurs in a *Before* business rule (making the call to current.update unnecessary). One single event could also be causing two emails to be sent at the same time.