Overdue Task Notifications being Sent Even Though Workflow was stopped.

A user had started a regular out-of-the-box approval workflow and then decided she did not need the document that the workflow was running on, so she deleted it. A week later, she received an overdue task notification for that document. She figured it just needed time to clear out of the system, so she didn’t say anything to IT. A week went by and she got another notice. She then deleted the entire library – and still the emails kept coming. It was puzzling – the workflow was stopped, yet overdue email notifications were still being sent to workflow participants.


She called me after moving her documents and deleting the site, and still the workflow task notifications kept coming. I was puzzled. After numerous hours spent Googling and frantically trying to eke out an answer on the internet, I remembered something I should have thought of.

We had performed a restore for that site collection a month before (probably why I did not remember it – I can barely remember what I had for breakfast by noon). The restore was placed in a live environment that we use for troubleshooting user issues.

I browsed to the site and sure enough, there was the document, document library and a workflow labeled “In Progress.” Because it was not in a dev environment, it was running SMTP in our production environment and was hosting the workflow as if it existed in the original location.

After I discovered this, I found a couple more instances from other users that had this issue. So apparently, I am not alone. Good thing too – in SharePointLand, alone can be scary!

To wiki or not to wiki? How to deploy a wiki.

If you are thinking about starting a wiki and don't know where to begin, the website that I recommend above all others is wikipatterns.com and was a huge help in deployment and management when I deployed a wiki at my last company. We took a lot of ideas from there. They also have a book by the same name with some case studies that all of our deployment team purchased and read as part of the planning.

We were concerned about several things, mainly the two biggest barriers to wikis: 1) How do we get started, and 2) if everyone is responsible, then no one is responsible. We used the "barn-raising" technique to get the ball rolling. We started with a "Panel of Experts." After they planned and created the basic premise and taxonomy of the site, The Panel of Experts along with all of our business heads and content managers got together for a three-day session to deploy the content. There were about 20 people in all and We made it really fun - had lunch brought in and contests for the people who were entering content, like who could find the most spelling errors during proofreading, and who could wear the goofiest hat. Sounds corny, I know - but it really worked to create enthusiasm around the concept.

The maintenance plan was a was a little harder to decide on. We didn't want to restrict changes to the content too much, because then people would not take ownership or it, but we didn't want to make it a free-for-all either. We settled on a panel of content managers that would set alerts on certain areas of content and when changes were made, they would review them for accuracy on a daily basis. We originally thought that it would be better to have administrators be the only users who could publish changes, but thought that there was probably a good chance of them forgetting to publish the content and then the changes would never happen. We decided that the few people who made incorrect changes were an acceptable risk in order to have all people with buy-in be able to contribute and see their changes in real time. We also made it public knowledge that there was no such thing as "anonymous" in SharePoint, which probably prevented a number of incorrect or inappropriate postings. However, the idea of having all users be able to make edits or create new pages and then have someone else be able to review and publish those changes to a live site is a very viable way to handle this issue and fully supported with out-of-the box Sharepoint.

Weird SharePoint Datasheet View Error with Person Column

Issue: One of my users had a list that had about several hundred items and about 25 columns. She created some views for these items and one was a datasheet view with only about 5 columns. She had created it as a way to modify these columns quickly. However, when she would use this view she noticed something odd: the datasheet view would show duplicates of some of her list items.

When viewing the list in standard view, there was only one of each list item. When we changed to the datasheet view she had created, it would show some items multiple times.

Cause: When we investigated, we found that some of her columns were columns with the data type set to Person or Group. The number of people chosen for the list item directly correlated to the number of items that displayed in the datasheet view! However, when we added the person column to the datasheet view, the problem went away! She really didn’t want that column showing, so we had to figure out what was causing it. We examined her settings on the columns:

• It was a column with a type of Person or Group

• It was required

• It allowed multiple selections

We removed the required field for that column, and the duplicates disappeared! We removed the ability for multiple selections and the duplicates disappeared this way as well.

It was only that combination of having a required person column allowing multiple entries that was not showing in the datasheet view that was causing the problem.

Fix: Unfortunately for our user, her options were to either display the column in datasheet view, disallow multiple entries for the person column or make it a non-required field.