- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
The infamous "send to event creator" option that is sometimes overlooked, can cause a headache later on if not addressed. All hell breaks loose when users start to report missing notifications. In light of iris.geist's post on Troubleshooting email notifications - Send to the Event Creator, let's talk about email notifications and different way to test the "send to the event creator" option.
With email notifications we can send selected users emails about specific activities in the system, such as updates to incidents, change requests, etc. There are several settings that affect how notifications behave and in support we often find that email notifications often are the reasons for people's pre-mature hair loss. The "send to the event creator" option is on the advanced notification view. By selecting this option you can send a notification to the person who performed the action that started the notification process.
When 'send to event creator' is OFF (unchecked), the person who performed the action that started the notification process will be removed from the list generated from the notification Users/groups in fields,Users, or Groups field.
Send to event creator | Reason to use | Problem |
Off - Unchecked | Users avoid receiving a notification of some actions executed by themselves | Some email will not be sent, which may not be explain by final users, and as a result, some of them would complain of not receiving the notifications |
On - Checked (Recommended) | No change on recipient list. Email notifications remain consistent | Some users will receive notifications of the actions done by themselves |
Here are a few examples of how setting the "Send to event creator" option OFF, or unchecked, affects your recipient list.
For the purpose of this example, I have created/updated two users. I gave alejandra.prenatt the "itil" role so she can update the incident.
UserID | Role | |
aileen.mottern | - | |
alejandra.prenatt | itil |
I created a new notification on incident called "test_event_creator."
Name | = | test_event_creator |
Table | = | incident |
Insert | = | CHECKED |
Update | = | CHECKED |
Users | = | aileen.mottern alejandra.prenatt |
Send to event creator | = | UNCHECKED |
Subject | = | test event creator |
Fill the reset of the required fields |
For the purpose of this example, I left the option to Send to the Event Creator unchecked.
As you can see "aileen.mottern" and "alejandra.prenatt" are the target hard-coded recipients. Common sense says both users should get the notification. But, wait.
Example #1: I logged in as "aileen.mottern" and create a new incident e.g. INC0010020
When the notification fired:
- "aileen.mottern" was NOT in the recipient list.
- "alejandra.prenatt" was is in the recipient list.
This is because "aileen.mottern" was the user creating the incident thus the event creator. As the notification 'Send to event creator' is unchecked, it will remove it from the recipient list. From the list of "aileen.mottern" and "alejandra.prenatt", the event creator is removed.
Reviewing on the sysevent table, you can see the User name for the event.
Example #2: I logged in as "alejandra.prenatt," opened the incident created e.g. INC0010020 and add a comment, then Saved.
When the notification fired:
- "aileen.mottern" is in the recipient list.
- "alejandra.prenatt" is NOT in the recipient list.
This is because "alejandra.prenatt" was the user making the change thus the event creator. As the notification 'Send to event creator' is unchecked, it will remove it from the recipient list. From the list of "aileen.mottern" and "alejandra.prenatt." the event creator is removed.
Reviewing on the sysevent table, you can see the User name for the event.
Example #3: I logged in as the Administrator, opened the incident created e.g. INC0010020 and add a comment, then Save.
When the notification fired:
"aileen.mottern" and "alejandra.prenatt" are in the recipient.
This is because "System Administrator" was the user making the change, thus the event creator. From the list of "aileen.mottern" and "alejandra.prenatt," nothing needs to be removed.
Below is the final result after the three tests:
Users that make changes will not receive notifications that have the event creator UNCHECKED. However, you will want to set 'Send to event creator' ON (checked) if you want consistent notifications, as some users will not receive those notification when this is OFF (unchecked).
Target recipients | Notification Event creator | Event creator value | Final recipients |
A,B,C | UNCHECKED | A | B,C |
A,B,C | UNCHECKED | B | A,C |
A,B,C | CHECKED | A | A,B,C |
A,B,C | CHECKED | B | A,B,C |
More information can be found here:
- Email Resources Page (KB0540674)
- Incoming email classified as reply to 'null' via watermark
- Two watermarks in incoming Email messages
- Docs: Notifications
- Docs: Scripting for email notifications
- Troubleshooting email notifications - Send to the Event Creator
- Troubleshooting Outbound Email (KB0521382)
- Speed up your email delivery by validating recipients
- My other blogs
NOTE: Tested in Fuji, using Chrome.
- 14,026 Views
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
