Blogs

If you have ever had food poisoning, you know that the moment you realize it, your thoughts are highly focused on dealing with the symptoms. Afterwards, you work your way through the recovery process, tea, Saltines, rest, etc. but sooner or later, you start thinking. “Where did I go?” “What did I eat?” “Did anything taste funny?” SharePoint is like this.

Okay, problems in SharePoint are rarely as bad as food poisoning, but the progress is the same. There is a bit of panic when you (pretend you’re the user, not the technician) realize that you have done a lot of work and something has gone wrong in the process of saving that work. This may not be your problem, but at 3:25 pm yesterday, it was the problem for one of my coworkers, and he was very concerned. The first thing I did was to address that major symptom – I made sure he saved a copy of the document on his local drive.

Next we laid out the roadmap for recovery. The inspection report the engineer had just completed is now part of a workflow-driven-metadata-managed process on SharePoint, but old school methods still exist. “We will look at this in the morning, but worst case, you can just email this to …” In other words, the world isn’t going to end because SharePoint tosses an error during a process. This is an important step, because people need to know that everything is going to be taken care of. SharePoint is supposed to be doing things for them, but they are still responsible for getting those things done; it isn’t enough for them to say “SharePoint failed.” It also isn’t enough for you (the technician) to say SharePoint failed, and it isn’t enough to simply fix the problem. If you want the users of a system to trust the system, they need to understand why problems occurred and what steps were taken to ensure that they will not occur again.

This is when the analysis begins. “Did you create this document from the template on SharePoint?” “Did you work with is off-line?” “When did you create it?” …and so on. Much like a quest to find the cause of your discomfort, the answers rarely point to a single source. That’s the trouble with SharePoint; there are often multiple starting points to a process, off-line activity, and in our most recent case, changes to the Library details between the creation of the document and the point at which it couldn’t be saved. We worked our way through the life of the document, decided on a likely cause and a course of action that we thought would solve the problem. We took those steps, uploaded the document and began the process. When everything worked, we took the most important step – we explained the situation to the user.

I have purposely left out most details here, because I don’t want to explain something that I am not yet certain was the root cause of the problem. If we can sleuth this out further, I will explain the problem in detail here, or on my other blog. One detail I do want to share with you is the response I received from my coworker: “Thanks Dan.  I had already checked and saw that the status had changed.  I appreciate the update and explanation.”