Document libraries are one of the most popular and commonly used features of SharePoint. However, to get the most out of them you need to get your users out of the file server mentality. File servers, or local file folders for that matter, force us to organize our data into a hierarchical “tree” pattern. Most of us are in the habit of creating folders within folders to organize our data, and in most companies’ servers you’ll find layer upon layer of nested sub-folders. After a few years of this with hundreds or thousands of users it’s very difficult to find things unless you know exactly where to look.

SharePoint allows us to break out of this approach and think about organizing our content differently. By adding meta-data to our files, either through the addition of custom columns to lists or libraries, or by creating custom content types, we are able to leverage the sorting, filtering, and grouping capabilities of views. You may have noticed that it’s possible to turn off sub-folders in document libraries; I would highly recommend you do this and start creating customized views instead.

Example: let’s say your project management office wants to organize their files. In the file server world, you might find a shared folder called “PMO”. This folder would probably have sub-folders for each of the individual projects; each of these project folders might have another level of sub-folders for the phases of the project. Within each phase, you might find a folder for status reports, another for budgets, and so on. This assumes, of course, that you are lucky enough that all of the project managers follow exactly the same organizational structure. Given this approach, if you wanted to see all of the current status reports you would have to navigate through each of the projects’ folder hierarchies looking for the most recent status reports. If you wanted to see everything that had been created by a particular user, or all the files for the planning phases of each active project, you would have to collect everything by hand.

By placing your files into a document library, applying some simple meta-data, and creating custom views you can do all of those things and more. By adding a column for “project ID”, another for “phase”, another for “document category”, and another for “notes”, you can create a wide range of views that allow you to look at files for a single project, look at files across all of the projects, show only those files created in the last week that are in the final phase of a project, and so on. This gives users the ability to quickly navigate to the files they are interested in without having to memorize a folder hierarchy. It also makes it much easier for the library owner to keep things organized, as users can’t inadvertently drop files into the wrong folder.

However, if you’re not careful your document libraries can quickly become simple copies of the existing file server hierarchy already exists. By removing the option to add sub-folders and training users how to apply basic meta-data and customized views, you’ll help your organization get the most out of your new SharePoint library.

One of our clients is doing a lot of development work with SharePoint, InfoPath, and SharePoint Designer workflows. We were running into an issue where publishing the form to SharePoint often failed, resulting in an error: “Updating content type failed”. After extensive google’ing it appears that a lot of other developers have run into this, but we couldn’t find a fix for it. A good friend came through last night with a great idea that seems to have solved the problem.

Symptoms:

• InfoPath form with ~150 data elements
• About 60 of the elements need to be attached to the SharePoint library
• We were promoting the columns to the library, and on publishing ran into failures about 90% of the time

Our best hypothesis is that the web service on the SharePoint server was timing out before the publish operation could complete. However, once we changed the way we’re publishing the problem seems to have gone away completely. The fix is to ensure all of the “linked” columns already exist in the form library, then tell InfoPath to attach to those columns, not create new ones. You can do this during the publish wizard process:

1. Click the File -> Publish… menu option
2. Select the first option “To a SharePoint server…”
3. On the next screen include the proper URL to the library
4. On the third screen select “Document Library”
5. On the fourth screen select “Update the form template in an existing library” and choose the library from the list
6. On the fifth screen you’ll have the option to add your columns. When you click the “Add” button, instead of opting to have InfoPath create the column for you (i.e. the “None: Creat the new column…” option), select the “This document library” option from the first drop-down, then select the appropriate column name from the second drop-down box

This seems to have completely corrected the “Updating content type failed” error we were having and appears to have cleared up several other issues. When our publish failed, we were losing all of the views, etc. which makes sense, as InfoPath was re-creating the columns. We were also seeing fields become un-linked in the SP Designer workflow. Presumably this will fix all of the issues and save us an incredible amount of time moving forward. Hopefully this tip helps you, and please leave comments for others if you can add any insight.