Having grown up in Pittsburgh, I set a goal of never living on the other side of a river from where I work. When you have a river between you and your job, you have very few travel options. I managed to achieve this goal for about 2/3 of my career, and then our company moved to a town on the opposite side of the Connecticut River. Now, between me and my office, there are precisely three bridges. Leading up to those bridges are a variety of highways and feeder roads, but choosing a bridge limits my options. How fast I can go, where I can stop, what I can buy along the way, all depend upon the bridge I select. While I prefer having lots of options, so that I can avoid traffic jams or run errands, there is a certain comfort from having limited options. For example, directions are easier to explain. When introducing SharePoint to users as a document repository, I am slowly becoming a big fan of bridges.
I have spent parts of the past few weeks, designing a small series of record keeping and document management sites. The further I move through this process, the more I realize that I want to offer very few options. The options that I have been eliminating this week are all ways of moving documents. From my early days with SharePoint 2003, and continuing into SharePoint 2010, I have been disappointed with the options for moving documents. When I say move, I mean move, not copy, not copy and then delete, not cut and paste, MOVE! I don’t want to lose metadata, I don’t want users creating temporary copies of documents on their desktops, I don’t want broken links, and in SharePoint 2010, I don’t want the Document ID changing. Changing Document IDs? Wait, I thought “document ids remain the same even if the document is moved within folders or to another library in the site collection“. True enough, but the operative word is “Move”.
I’ve been reading blogs, TechNet pages, MSDN pages and while lots of references talk about the powerful nature of Document IDs, few mention the fact that you don’t really have a “move” option right on the library page. If you want to move your document, and preserve its Document ID, you need to work from the Site Content and Structure page. You can also build some custom “Send To” options for your library. Some suggest that opening the library in Explorer and using Cut & Paste works, some argue that certain metadata will change using that technique – I have to admit, I didn’t check that out in enough detail to know the answer. What I do know is that these options require my users to have a pretty good understanding of SharePoint. Most complaints that I get from my users include the phrase “yeah, that’s easy for you, you understand SharePoint“. Before you start down the “…it’s not that hard to understand” road, remember what I try to remind myself – they have a job to do, and that’s what they understand.
So, I have users who have heard that SharePoint 2010 has this great feature called Document IDs, and that they can link to documents and never have those links break. They don’t know, don’t understand and won’t remember the ways you can move documents and preserve the ID, or the ways that will cause a new ID to be generated. Yes, I will explain that to them in training and I will remind them when we design sites but mostly, I will eliminate the options for making mistakes. Where we have documents whose Document IDs need to be preserved, moving those documents from place to place during a process will be controlled by Workflows. I like this solution for several reasons:
- Workflows reduce the opportunity for error.
- Workflows not only get the document into the right place, they can be designed to update a lot of the metadata columns at the same time. This reduces the amount of work involved in the process.
- Workflows can “Move and leave a link” in the existing library. I really like this option because the user often relates to the place he built the document more than the place it needs to be stored.
- Workflows can operate at an elevated permission level. SharePoint 2010 includes the ability to impersonate another user during a workflow step. That means a user can cause a document to be moved to a library he or she doesn’t have permission to create documents in.
As with Document IDs, most of these steps have some flaws in their implementation. I will talk more about those in the future. I will also focus on some of these issues in my presentation at SPTechCon, as reasons why you may not want to tie a business process to SharePoint and or what you should consider if you have to make the connection.