SharePoint alerts: THE UNTOLD STORY

alertI’ve had to have several conversations about SharePoint alerts recently. These conversations have revealed to me that many site owners don’t grasp that alerts are designed to be an “end-user empowerment tool” to facilitate self-service notification about SharePoint site activity. Alerts are not really intended to be an administrative tool for owners to “force” notifications onto site users or control how they work. Why is this so hard to understand?

This misperception can cause problems if that concept is not fully embraced. SharePoint assumes and expects that users are able and capable of managing how they want to be notified, and will appreciate/use the tools allowing them to do so. Savvy site owners will realize there is little value in choosing not to leverage this behavior. Why take on that responsibility? Choose to use alerts as they are intended. Instead of laboring over administration and control of alerts, use that time and effort to educate users about alerts and how they can be one of the most powerful aspects of SharePoint.

OOTB, site owners (or anyone with the Manage Alerts permission) can create and delete alerts on behalf of other users, but beyond that, alerts-for-others become the “responsibility” of the users for whom they were created. Included in that scope is the fact that at any time, any user is free to delete or change any alert put in place on his/her behalf, with zero awareness shared with the alert creator. Set up all the alerts you want, site owners; but just know that your users can delete them as fast as you can set them up.

For example: Joe Owner creates an Announcements List alert that sends an immediate email to 5 users and himself when new items are added. After a couple of days, Joe decides that this is too many emails, and wants to change the alert from an immediate email to a daily digest. He finds that he can only modify HIS own relationship to the alert parameters. It is not possible to change/remove a “mass” alert in one action. When he updates his own instance of the alert, his changes are not “rolled out” to the other 5 users. They will continue to get the alert according to the original set-up. To stop the original alert, Joe would have to remove it manually for each individual (or ask them to it themselves), then recreate the alert with the new daily digest settings for those 5 users. See the potential administrative burden? Who wants that?


A frequent question is: How do I see alerts on my site?

Basically, this depends on your role:

Site Owners: To see the listing of all users who have alerts associated with them on a particular site:

  1. Go to Site Settings > Site Administration > User Alerts (see image).
  2. A drop-down box will say “Display alerts for.” 
  3. Select a user and then click “Update.”
  4. You will see a list of all alerts in place for that user.
  5. Mark the check box to select an alert and click “Delete selected alerts” to remove them.
    • NOTE: It only works in this direction- there is no option to see all alerts and then the associated user name(s).

End Users: Locate your name in the upper right corner of the site and click the drop-down menu, then choose “My Settings” (see image). MySettings

  1. On the next page, locate and click  the “My Alerts” link (top center, sort of small, above your user information).
  2. The next page displays all alerts associated with the user (self-created OR created by others).
  3. The user can then modify or delete any alert.

Companies that want to expand the alert scope into a more admin-focused tool usually end up purchasing a 3rd party add-on, such as the one linked from this article. Also, developers can modify the alert framework by reprogamming default options. See this posting for some of those possibilities.

More on alerts:
Manage Alerts in SharePoint
Alerts “For Dummies” (their title, not mine)
Video: Manage User Alerts in SharePoint 2010

The dreaded “D” word

I’m talking about DELETE. recycle-bin

The prospect of something getting deleted from SharePoint can strike fear into the hearts of many users. So much fear, in fact, that they go to extraordinary lengths to try to make it so that no one CAN delete anything…. EVER. But think about it- SharePoint is not a catch-all or a bottomless archive. SharePoint is generally meant to hold active content that matters- in real time- to you and your colleagues. Sometimes people need to delete things. Sometimes people SHOULD delete things.

Don’t you know that SharePoint has your back? Use the tools at your disposal to ensure that you’ll never be the last to know when someone deletes a document or a list item, and give you ample chance to restore it if necessary.

Continue reading

Frantic User Stories: Relative URLS and the Quick Launch in WSS 3.0

Disclaimer: This article addresses the SharePoint 2007 Standard (WSS 3.0, not MOSS) environment. Some of my comments may not apply to other versions of SharePoint. Also, custom-developed solutions are not an option for any scenarios outlined in this article. I limit my approach to end user/power users who do not have
access to such resources.

A Frantic User emailed: “I deleted a list but the link is still showing on the Quick Launch. What am I doing wrong?”

Short answer: Nothing. The link was manually added to the Quick Launch. Manually-added links are not dynamically connected to the source list/library; therefore they don’t respond to such changes.

Long answer:When creating a content element (list or library), you must choose “Yes” or “No” in response to the question, “Display this list [or library] on the Quick Launch?” If you select “Yes,” the link will automatically be placed under the default content heading for the list/library type, and will point to the default view of the  list/library. In short, what you get in this scenario is a dynamic, relative link to the target list/library.
Continue reading

“Where’s my document?”

Scenario: User reported, “Document X in Folder Y in Library Z should be visible to all users! I can see it but no one else can… What’s going on?”

There are several places to check in a situation like this. Many may assume a permissions issue, especially when folders are involved. Broken permission inheritance, perhaps? I checked the library permissions, folder permissions and document-level permissions. Everything was fine.

Next I wondered if the document was checked out. Nope!

Lastly I looked at versioning settings. Bingo! The library had major/minor versioning enabled, with the most restrictive drafts option selected. The document in question was in draft status, therefore the only people who could see it were its creator and those with Approver permissions. No one else would be able to see it until it’s published to a major version.

To help prevent situations like this, make sure those using the library understand what settings are in place. Versioning applies to the entire library, so only use it when it’s appropriate and logical for all documents in the library. It’s overkill and undue complexity to impose on users when the library doesn’t truly call for it across the board. Make sure all users understand such advanced features.

It’s also a good idea to include something in the library’s description referencing the use of versioning, so it’s not necessary to delve into the settings to discover what’s been put in place. Since permissions can prevent many from accessing the settings, users as well as troubleshooters will benefit from the heads-up.

Also, I would have made sure that the default library view displays both the “Version” column and the “Status” column, so it’s always clear what’s what. If those columns had been in place in this library, it would have been immediately apparent to me that the file was in Draft status and that the version number was indicative of that- it would have been something like 1.3 or 2.2, not the ends-in-zero number indicating a major version (such as 3.0).

Bottom line- if you’ve gone through the trouble of configuring major/minor versioning (including the strictest option for hiding viewing drafts), you should have a good reason. You should also have prepared your users for how that affects their ability to share documents. The command to publish to a major version isn’t glaringly obvious so get that training out there.