The most aggressive content management solution we have put in place within SharePoint is the process that we now use for managing and storing engineering inspection reports. This solution evolved from a simple document library to a workflow-driven process that keys off of both document status and content type. The status portion of the process seems to work well. By that I mean, the engineers understand it and the workflows work as designed. The content type portion seemed to have issues; some people were prone to call everything an Inspection Report rather than agendas, confirmation letters and supporting documents. The person who manages these documents for the engineers assumed that these guys simply weren’t following instructions, and she was manually correcting the content type. A decision that “the problem seems to be user error” sits very well with me and, I must say, is supported by historic events.
Unfortunately, it wasn’t user error, or at least, it may not have been user error in every case. Earlier this week, we needed to add a new content type for Response Letters. We inherited this type from one that uses the same template, set up all the metadata we needed and modified the workflows. In testing, we noticed some very curious behavior – when we clicked New and selected Response Letter, Word opened with the correct template, but when we saved the document, the content type changed to Inspection Report. My coworker fought this issue for a while before asking me to look at it. What I witnessed made no sense at all; the content type was changing before our eyes. Both of us ran out of time while dealing with this problem during the day, but later that night, I decided to dig deeper. Note: the description below is brief by design; the steps I am describing played out over a 3-hour period.
- A check of the advanced properties of the newly created document revealed a ContentTypeID that was consistent with the Response Letter content type.
- Log entries, added as the first step in each workflow involved, indicated that the ContentTypeID of the newly saved document was “Inspection Report.”
- Documents saved to the local file system and then uploaded into SharePoint, retained the correct content type.
- Changing the content type in the document properties on SharePoint, or the ContentTypeID in the advanced properties after the document was saved, fixed the problem and the content type remained unchanged throughout the rest of the process.
- The problem occurred on documents saved to the library or into a Document Set (as is normal procedure).
- This same behavior was evident in other content types; it wasn’t limited to the new one.
The workflows were not causing the problem. The users were not causing the problem. Word was not causing the problem. SharePoint was causing the problem; we didn’t know how, or where, but we knew it was happening as soon as the document was saved (not uploaded) to the library for the first time. In addition, the content type these documents were changing to IS NOT the default content type for this library. I started searching for every imaginable search term, but I was having no luck finding anyone that even had experienced this problem, let alone someone who had a solution. Everything I found seemed to indicate that content types should work exactly as we expected them to, not in the mysterios zombie way they were working for us. Finally, I stumbled onto a blog post by John White talking about using templates. The post is excellent, but it seemed to reinforce that what we had done should have worked. It wasn’t until I read through the lengthy post and into the second comment that I noticed that someone else had experienced the same problem we were having. If you read John’s post, we were working according to what he describes as Option C. As Najro points out in his comment, the problem (of content types changing) can be eliminated if you create the content types and templates according to Option B. I will add that the instructions in Option B need to be followed painfully to the letter – I tried taking a few shortcuts and the problem remained. My coworker plied along step-by-step and was successful.
In the absence of a real debugger for SharePoint and SharePoint Designer workflows, we are left with trial and error and logging. Beyond that, all we have are the helping hands of the good people in the community who just happen to be struggling with the same issue. Thanks to John and Najro on this one. Hopefully my contribution will be to point people to the solution in less time than it took me to find it.