Blogs

I love it when somebody does something that inspires a blog entry. Trying to write two SharePoint blogs each week, and keeping them useful, can be challenging, so it’s nice when someone helps. What’s helping me today is the fact that this Community has moved on up to the AIIM site. That tells me that what might have started as an experiment is ready for prime time. I find that inspiring because I feel the same way about SharePoint.

To be honest, I thought SharePoint was ready for prime time when SP 2007 was released, but in retrospect, there were too many things still missing. You could certainly make SharePoint work for document management and you could make it work for a wide variety of collaboration solutions, but the operative part of those thoughts was “make it work”. What changed my opinion of SharePoint? Well, for starters, Document IDs; a unique immutable identification tag associated with my document. I wrote about one of the reasons this is important last week, but another reason this feature is important is because it tells me Microsoft wants SharePoint to be a document management contender.

The other feature I love about SharePoint 2010, is the ability to run workflows at an elevated permission. This is a trick we have used for decades in our production systems, and it is absolutely critical to maintaining the integrity of an important data/document processing environment. In its simplest form, this feature allows a person to do something, say add a document to a library, where they don’t have permissions to carry out that task. During the workflow, the person briefly impersonates a user who does have permission. What is so very important about this is that it happens “during a workflow”. That means, it happens under controlled conditions. It’s the difference between suggesting patrons wear a jacket to dinner and having the maître d point the guy who shows up in a tee shirt to the parking lot. Procedures tell us what we “should” do; workflows “prevent” us from doing the wrong thing. Below are two examples of when elevated permissions are helpful:

Process – Workflows are often tied to metadata columns. One of those might be a status indicator, where different processes run at different points along the status spectrum. This is more than a control issue; it’s also a collaboration issue. Consider the status “Ready for Review” – if I am responsible for reviewing documents prior to their being submitted to a repository, I would have to be constantly trolling the staging library looking for stuff to review or relying on someone to create a task for me. Using a workflow means that when someone says a document is ready for review, a task is assigned to me. That person can’t assign that task directly; they can’t edit the task list either. All they can do is finish their job and say that it is done.

Logging – As workflows proceed, they typically update a process log. This log is our record and I like the fact that the people doing the activity cannot alter the log. When you are building an auditable process, this kind of control is important. I can point to the log and say with certainty that “these things happened”.

There are other ways of accomplishing these tasks, but they involve people making the right decisions or performing the right steps at the right time. Being able to automate these processes results in an environment that is truly ready for prime time.