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.
16 thoughts on “Alerts in SharePoint 2010 (Troubleshooting)”
if i create a new item in document library the alerts are fired and send email,in that email properties are showing previous item values.
Please help me on this.
I’m sorry but this needs to be investigated via a support case. My posts are just for the first basic steps to check and whats not covered here will have most likely another reason or cause that cannot be solved via blog post comments.
Hello Steve,Since the DST time change my scheduld alert for Posts summaries are one hour after the scheduled time. Is there a fix for this?Thanks, Mike
Hi Steve,I am having an issue where a weekly alert set-up for when new posts are added to a blog, is also including items that are pending approval in the email. Unfortunately the alert goes out company-wide, hence when I was testing with drafts pending approval all my test blog posts were included in the weekly email alert 😦 Any advice here please?
We are having a strange issue with the daily summary alerts. It is sending multiple emails instead of one summary email. Let us say there are 10 changes that needs to be sent on a given day and the user subscribed to receive the daily summary email at 12 PM. It is sending 2-3 emails with a gap of 15-30 minutes. The first email contains a subset of the changes ( 1-2) , the second email contains another subset (1-8) and the third email contains all the changes (1-10 ). This is happening for multiple users every day. The number of emails and the content appear to be random.
How do you troubleshoot this issue ? Would appreciate any pointers.
So if it has worked for the first attempt with a view set up based on a >4 value, then the same should also work for the >3 Value in column.
Is this applied onm the very same library/List the >4 value is working?
Is there any other condition set afterwards that may conflict with the previous try?
Try to find out if there is a differnece between >4 value = alerts working and >3 value = alerts NOT working.
Also maybe a refresh of the property Settings may Help, please see my related post here for similar Troubleshooting steps:
HtH, cheers, Steve
the time set for fire alerts are depending on the time that is set on the Server that runs the timerjob. If your Servers are all set to cahnge automatically to the DST, the next timerjob run should respect it correctly.
Please check also the time Settings on difference between your Farm Servers and the Email Server, as the time shown as "sent on… ." will Display the time Settings as configured on the SMTP host.
I think, this is not a General alert feature and might be steered via th approval workflow itself with an additional step for sending the email on "reject" Status.
In your Case, the modified item is not considered as a "Change/modify" same as it would be once the item is changed as usual by modifying the property afterwards. As Long as the approval is in process and the "reject" state is set on it, it will not be seen on closing the Task as a "changed item".
I like your post but my issue is related to Daylight Savings Time ending. Alerts that are scheduled for say, 5:00pm are being sent out an hour early; 4:00pm (Daily Alerts). Would you happen to have any solution or knowledge about my issue? Current Farm Version is 14.0.6117.5002 (SP2010)
Can you please suggest a change or edit I can make for Content Approval on a Calendar that will allow Alerts to be sent to the initiator when their request is "rejected"? Currently only "Approved" request Alerts are sent.
We are having problems getting alerts to work on some views. I have a view set up that is based on a >4 value in one of my columns, we created the alert and it works beautifully. We then created another view (based on that view) >3. the view works fine. When we set up the alert we get the confirmation email but we don't get any subsequent alerts. Do you have any ideas?
Do you know why an alert would display the wrong Document ID for an item? This is what happens on my farm when someone updates a certain item with an alert set on it.
– have you checked if there is set a multiple alerts notification for each of the email alerts separately?
– what if you delete all alerts and recreate the only one you’re interested in?
– for a more detailed Troubleshooting, you should raise a Support Case with MS Support to investigate the behavior in depth
Hi Matt, I'm sorry but I'm not sure what you mean with "document ID". Could you please be a bit more specific? Thanks and greets, Steve
Very well explained. Thanks Steve.
@Chet: I think this is a behavior that follows the logic of how we fire alerts, So in your case, the item IS newly added to the list/Library and hence the alert setting applies and fires.You can maybe try out this: On List settings, go to the “version settings” and change the ” Who should see draft items in this list?” to ” Only users who can edit items” – since the security trimming happens on alerts as well and your “company-wide” alias does not have “Edit” permissions, they wont see the alerts in the weekly summary.if that doesn’t help, call MS Support for a case to see if this is either a code defect and not expected behavior or even if a design change request could get filed to achieve your intended results.HtH, cheers, Steve