The Only SharePoint Blog Not About SP2013

imageQuick, guess what the best SharePoint related thing to happen to me this week was… OK, if you guessed that it’s that my Sys Admin is testing SP2013, look at the title and guess again. The continuing evolution of SharePoint is very good news, but our main concern is the version that is running today. One of our lawyers had some serious questions regarding how we might preserve and control some company governance documents. These documents need to be maintained at specific revision points, e.g. “the 1996 edition” but they also change periodically. This discussion occurred in the hallway, as I was leaving for the day, but it wasn’t long before I was sounding like a carnival huckster; I may have even used the expression “but wait, there’s more!

Record Libraries – A place that you can put stuff where it can’t change and can’t get deleted. I use absolutes like that when I talk to end-users because when I start adding the “well, you can delete if you…” and “…of course we can set it up so…” they shake their head and give me the staring-at the-IT-Guy look. I give the bare facts and then I wait until they ask me if there’s a way to delete, and then I slide in the rest. SharePoint is best served in small portions.

His next concern was about getting the right documents into the right places. Coming from a shared folder, he was expecting a similar challenge. I explained that you can explicitly put the documents where they belong, but added that we can wire up a custom Send To Destination option so that you can put them there without having to remember where “there” is. I also offered to show him examples of a workflow driven process where the document is marshaled into its proper location after the final production step is completed. Finally, I mentioned the option to create a PDF (either from within a workflow or by explicit action) in the Record Library. He liked that last option because while the Word documents change at a glacial pace, they do change. His next questions were about managing those changes.

Versions and Management Options – Most of our users understand that SharePoint has versioning features, but I’m not sure everybody thinks of versioning the same way. My coworker became excited when he learned that he could have a working version that is only visible to certain people. He absolutely loved the idea that he can be in charge of declaring the major and minor versions and granting the permissions to see them. I love that too, because it takes my department out of the process. It’s not that we are lazy, but we don’t need to be the gatekeepers at every stop. While speaking of gatekeepers, I pointed out the ability for him to approve content before accepting it in a library.

Management Policies – We finished our discussion with a little information about retention schedules an auditing, and how those policies can be made to apply differently to different Content Types. Of course, that led to a discussion about Content Types and what we can do with them.

It may seem strange that a small company that has had SharePoint for several years is only now having this conversation; well this isn’t the first time we have had this conversation. This is the first time we have had this conversation with this person, and that’s because this is the appropriate time. There may not be a widespread deep understanding of SharePoint’s features in our company, but there is a common understanding that SharePoint can probably be configured to handle any need. Most people can’t do the configuration work themselves, but almost all of them know enough to ask my team for help. I am very excited at having reached that point in our journey to effectively use this amazing product.

Sometimes it is Not User Error

clip_image002The 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.

Window Dressing

I remember when I was a child and my mother would take me to downtown Pittsburgh to see the store windows, decorated for Christmas. Once, when I was older, I got to see the men and women setting up those displays and I was amazed at how quickly they could transform each small space into a delightful holiday scene. Of course, I remained oblivious to the marketing aspect of the process, the room full of the season’s hottest inventory. I’ve recently realized that a SharePoint site’s main page is its “store window” and that like those department stores of old, we shouldn’t be afraid to change them to meet current customer demand.

We have an internet facing site with several portals for various business partners. These people visit the site infrequently, usually in conjunction with a meeting or event that they are attending or to access information from one of our many reference libraries. In some cases, these are also people who are not familiar with SharePoint. Our goal is to make their visit a success, and we have recently changed the way we prepare for these visits. We decorate the site for the occasion.

Just like the showroom window workers, I’ve just finished configuring one of our many external sites for an upcoming event; in this case, a meeting. Meetings are a common thing to support with SharePoint, and we have the requisite contact list of attendees, meeting agenda and a document library of supporting material. But, rather than create a sub-site for this content, we built the Custom Lists and Libraries off the main page and we placed Web-part representation of those resources right on the main page; one-stop shopping as it were.

There are two web-parts on the page that are interesting. The first is a contact list. We use Bamboo Solutions List Rollup part so that contacts can be maintained in a central list and displayed wherever they have a role. This gives us the comfort of knowing that a contact is up-to-date everywhere it appears. The second part on the page is a custom view of the meeting agenda. Rather than use one of SharePoint’s meeting templates, the agenda is a custom list. The full agenda list has the common elements you might find on any agenda but the main page view has the item and a reference to any supporting exhibits. That reference is in the form of a hyperlink so the site visitor can open the exhibits right from the agenda.

One other change we made was to the Document Library used for the exhibits. The library has folders for the various exhibits, as some have several documents. In case the visitor views the library listing instead of the agenda, we wanted the folders to contain descriptions of their contents. We created a custom Content Type to handle that requirement; we simply added an “explanation” column to a Folder type. The result is a kind of visual cross reference. The agenda (list) contains references (links) to the document library and the document library’s folder descriptions contain explanations that mirror the agenda. Regardless of how the visitor wants to explore the site, they understand what goes with what. Of course, the beauty of this approach is that everything is on the one page they know how to get to. . Today, the agenda has the prominent position; after the meeting is over, we’ll move the document library into the spotlight to lead visitors to the minutes.

SharePoint as Catalyst

I’m going to stay within my chemical past for another post. Activation energy, the energy required to overcome the barriers to a reaction or, in our case, a process, always comes at a cost. Instead of looking for ways to coax activation energy out of our coworkers, what if there was a way to lower the barriers? If we were in a lab, we would be looking for a catalyst – something that makes a reaction happen faster by lowering the activation energy. That sounds like technology to me.

In fact, using technology as a catalyst for ECM is a perfect role. The job of a catalyst is to make it easier for a process to proceed, technology does that. The definition of a catalyst also requires that the catalyst doesn’t alter the outcome and is not consumed. OK, here’s where we have to be careful. Let’s dispense with the second condition first – other than drive space, our technology isn’t consumed during document management and we could argue that if we’re moving documents from file shares, inboxes and local drives, it may be a wash. If we’re eliminating duplicates, we may be gaining ground.

The first point is more important and it’s also where SharePoint shines. SharePoint makes ECM easier in many ways but it doesn’t alter the documents. We’re not converting documents to a proprietary format, we’re not adding the burden of different software to view or edit our documents and we’re not leaving traces of SharePoint in the documents themselves. SharePoint adds value through additional features and associated information. Metadata, custom columns, effective organization, permissions and rights management and search are a few of the things SharePoint couples with our documents. But wait, these things don’t make ECM easier, they are ECM, they are the result but we still have to do the work – how is this lowering activation energy?

SharePoint’s role as a catalyst relies on the other features SharePoint offers. For example, an email enabled document library can have a workflow attached to the arrival of new documents. This means contributors don’t even have to know where the library is, they just have to send the document to an email address and the approval or review process begins. In another library, Content Types deliver the right template to an end user so that the development of the document is easier and fewer edits are required. Staying with production, SharePoint’s awesome collaboration features can make it much easier to develop and manage documents. Consider the following example.

We recently moved the maintenance of our public web site into SharePoint. We have several people inside the company involved in authoring and approving content and we have an outside firm, Centroid Communications, helping with design, editing and production. New ideas are described in a SharePoint wiki. Draft articles are written, edited, commented upon in the wiki and ultimately published from the wiki. In the past, these articles would traverse multiple inboxes and were often delayed. Even if they moved quickly, the comments had to be weighed and merged and the “final” article reviewed again. I can point to more than one document in our file share whose title includes “final-final” as a result of the old process.

Some people in the industry complain that SharePoint’s wikis are not “best of breed”. Maybe that’s true but you have to consider everything that’s included. First, we have a browser-based platform to build the content in. SharePoint provides the access control, allows us to review the history (who changed what) and alerts us when changes are made. Combined with the wiki editor and feature set, this is a very powerful tool; it’s making the job of web publishing easier and it doubles as the archive. How much better does it get?