We are trying to make it as easy as possible for participants in our professional development programs to use their team sites, especially their team blogs, to document their activities. SharePoint out-of-the-box allows us to create an incoming email address for the blog (or any other list or library). So team members can contribute by sending an email to that address. So far so good. And the users will automatically receive an alert anytime a new item is added to the blog. We set this up for them using Site Settings but we could also leave it to them to set up their own alerts using these instructions. So the combination of posting by email and automatic alerts lets them use the blog as an email distribution list with a centralized archive.

But now we have a problem. Upon receiving an alert, the conditioned response is to click Reply. But all email alerts for the entire SharePoint installation come from one address and have the same reply-to address. So, out-of-the box, there’s no way to allow users to click Reply when they get an alert and send their response to the blog, list or library it came from. Without customization, to respond to an alert users need to either send an email to their blog address or click the link in the alert to go to the site.For the basic requirement to produce alert messages that contain the full post, look good on mobile email, and can be replied to using the incoming email address for the blog, Tom Clarkson proposed a custom alert system based on event handlers.* This would allow us to customize the alert email individually for each site.

The code involved is reasonably simple. Most of what is needed can be seen in this msdn example. An event receiver would be set up for ItemAdded, and would contain code to create and send the email, using SharePoint outgoing email settings. The solution would be provided as a single WSP (solution package) file.

I’d like to see them using RSS feeds to monitor their team site. This would keep their work in the program separate from their day-to-day work an would get them to use a newsreader with all its aggregation, filtering and persistent searching benefits. But we are taking incremental steps toward Enterprise 2.0 here and these people are comfortable with email (especially email on their BlackBerrys) so that needs to be the first option.

*Two other options we considered were–

1. Modifying the alert template
This requires some centralized configuration changes as well as custom code to associate the templates with a particular list. It doesn’t allow control over the reply address.

2. More extensively customised alerts using INotificationHandler
This provides more flexibility, but still requires centralised changes.