Since I blogged the first two posts a while ago regarding “Alerts in SharePoint (Troubleshooting MOSS/WSS)” and “Alerts in SharePoint Part II (Troubleshooting MOSS/WSS)”
I thought, it’s time to continue this series with some updates and news
So first of all, most of the details and troubleshooting steps in the above mentioned posts are still applying almost the same for SharePoint 2010 as well.
The basic processing and technology on handling alerts has only slightly changed or was even more improved, hence you can still use the nearly same steps for evaluating any suspected issues with SharePoint alerts in 2010 too.
Starting with an update from a recent case I used to work on with an Alerts issue in SharePoint 2010, check out the following:
On a SharePoint 2010 Server Publishing page, you have a list- or Document library (in this case: the Site library) and you have enabled Alerts on this list or library.
On the list settings also the “Check-In required” option and “content approval” workflow is set/configured.
Any other alerts or email functionality is working fine and outgoing email settings are properly set.
User configures “Alerts” settings on this list/library with
- Change type: “New items are added”
- When to send Alerts: “Daily/weekly Summary”
– Alerts are not sent for Readers before content approval (pending state)
– Alerts are sent for Readers after content approval and/or Check-in (as this would be a new item from readers perspective)
– Alerts are sent for readers when all above applies AND defined columns with choose values/drop downs are filled (see “Variant” at the bottom)
Created alerts on only “New items are added” will never be sent out for Readers after approval´and/or Check-In and the daily/weekly summary Email alert is not fired.
This is a “by design” behavior and based on the technology, how the item on creation/edit time is computed.
Because it’s only a status change, meaning a modification of the item, it never gets the status “new item” and hence the Alerts logic will only detect this as a “change or modify”.
When an item is created, the first update to the database already happened while you still editing the assumed “new item”.
So as by now, the row entry already exists in the database, the final “check-in” and/or “Approval” is only a modification and not any longer considered a “new item”.
Sure, this is discussable but for now, its as it is
Set Alerts on “All Changes” or “Existing items are modified” for the Readers, which now will be detected and processed as expected, thus, Email alerts summaries will be fired on schedule.
Alternatively, you also can simply disable the “Check-In required” option and “content approval” workflow, so that the new item is truly a new item and will be processed as such.
When you additionally or at the same time have columns defined, that will be filled or updated on creation time (means a new item is created and the column type requires an additional entry to be typed or selected from a Drop down field i.e.) the same issue occurs and is caused by the same technical logic that will consider this item not as new while creating it!
Workaround here is:
Set the column with a default value to ensure, that on creation time, this field is already filled!
The logic behind is, that each described condition (check-in, approval, lookup or choose column field) is computed as a “modify” instead of a “new item” and thus your expected alerts never will happen.