Understanding SharePoint Metadata – Flattening The Hierarchy – Part 2

Last week I tried to explain the concept of metadata in terms of things you already know and use in Windows directories. So when it comes to storing documents in libraries in SharePoint did you expect SharePoint to be any different? The simple answer is that metadata works pretty much the same way in SharePoint as it does in a Windows directory. However, there are some additional reasons why you might want to consider minimizing or even eliminating your folders when creating SharePoint libraries.

First there is the concern that when multiple people are sharing a common library, the complexity of the tree structure creating by having folders within folders within folders can often result in the user getting lost when trying to find or save a file. The danger here is not just that a user may get lost in the forest of folders when trying to find a file and waste valuable time navigating up and down various branches to find the file they need, as bad as that may be, but the very real danger that they may save files to the wrong branch. When a user is saving a file in a library with a very complex folder structure, they may not immediately find the folder they want and assume that it does not exist. Then then create a new folder with the same name as a folder on a different branch of the library to save the file. Potentially, this can result in different versions of the same file (or files that should be related within a single folder) to be found in different branches of the library structure. If the file is actually saved in more than one location because of this error, subsequent updates to either file could occur independently from each other resulting in divergent copies of the document. When someone realizes the problem and attempts to bring the two copies of the file back together again, the process of manually merging the differences between the files can be a challenge.

The second reason however has a greater chance of causing problems. SharePoint only supports URLs with a length of about 260 characters (some say 255 or even 256, but let’s not quibble over a couple of characters.) This length typically does not include the name of the domain/server. However, there are also limits on the length of any folder name or filename of 128 characters. But hidden behind this limitation is the fact that some characters do not get passed as you and I may view them on the screen as single characters. These are the special characters, the non-alphabetic and non-numeric characters that must be passed as encoded strings so that the web engine does not incorrectly interpret them. Each of these special characters must be converted to three characters that represent the ASCII value of the character as a hexadecimal number. The following table shows some of the more common characters that must be converted to their three character hex equivalents before being passed as a URL string of which the total length cannot exceed 260 characters.


Hex Equivalent

Ampersand (&) %26
Equal (=) %3D
Period (.) %2E
Question Mark (?) %3F
Slash (/) %2F
Space ( ) %20


Thus, it is possible to have a path which may look like it has less than 260 characters when you count the characters in the path as you read it, but the length could exceed 260 characters after it has been encoded so it can be passed as a URL.

Note that this limitation does not apply to any query string appended to the end of the path to the actual file.

Perhaps even of more concern is when the site gets translated into some languages which can convert a single character consuming 1 byte as we see it into a string of up to 9 bytes.

Where do we most often see this? If a library has a complex folder structure and its users always navigate down through the structure one level at a time to the specific file they want, they many never know that they have a problem just because of the incremental way in which they are approaching the file. However if they attempt to capture the URL of a file buried deep within the structure, the resulting URL may look correct when they past it into a hyperlink or into an email message for someone else to directly view the file without navigating the folder hierarchy. However, when the person who receives the link attempts to click on it, which pastes the encoded link into the search box of their browser, the resulting encoded string may be truncated because of the extra characters added by encoding the link. This truncated string no longer points to a valid file in the library and the user will receive an error indicating that the file does not exist or that the URL is not valid.

So how do you trim your folder hierarchy and use metadata instead?

The simplest method is to first map out your hierarchy as shown in the following diagram showing only the names of the folders (symbolic folder names have been used here to keep the example as small as possible.)

Referring to the above figure that represents our folder structure within a library, notice that I color coded each level under the library’s root level. The folders immediate under the root are colored Yellow. The folders that are found in the Yellow folder level. These are colored Blue. The Blue level also has folder which are colored Green. Now converting this diagram to metadata, I can create a new library with no folders, just three new metadata columns. Each metadata column would represent one of the color bands. Within that metadata column, possible values will be the names of the folders from that level. For example, within the Yellow column, the possible values are: Folder A, Folder B, and Folder C. Next I create a Blue column with possible values of: Folder A1, Folder A2, Folder A3, Folder A4, Folder A5, and Folder A6. Finally I create a Green Column with values: Folder A1a, Folder A1b, Folder A1c.

Now when I add a file to this new library with no folders, I choose from the possible values in each of these three metadata columns to ‘place’ the file in the correct hierarchy level. If a file was in the original library’s root level, all three of these metadata columns would be blank (empty). For any file that was in the folder: Folder A, I would select the value ‘Folder A’ in the Yellow column and leave the Blue and Green columns empty. Similarly a file that was deep in the folder Folder A1b would be placed in the root of the new library with and I would select the value ‘Folder A’ for the Yellow column, ‘Folder A1’ for the Blue column and ‘Folder A1b’ for the Green column.

The net result is that I now have a flat structure for my library that makes it easy to find files because there are no folders and all files are visible in the default view. I can then use the library’s column headers to sort the files or even to filter files. For example, If I filter the Yellow column on the value, ‘Folder A’, the Blue column on the value ‘Folder A1’, and the Green column on, ‘Folder A1c’ I can quickly see only those files that would have appeared in that folder three levels down in the original structure

But more importantly, with the use of other metadata such as the Created By column which appears by default in document libraries, I can filter on all the files created by a specific person no matter which folder they were in previously to quickly find all of that person’s documents without having to navigate up and down through the previous folder hierarchy. I can also apply multiple filters such as files created by a specific person that were in Folder B or any of its subfolders.

While not shown in this diagram, it is possible to even have files that may have existed in Folder C2c without there ever having been a folder at level Folder C2. This would be very easy to represent in the metadata by providing a value for the Yellow column and the Green column while leaving the Blue column empty.

The challenge is mapping out the folder structure as shown in the earlier diagram making sure that you capture each of the current folders in the library and assign them to an appropriate level.

While this technique may appear at first to be very different from the folder within a folder approach used previously, it really is not so different at all and you should be able to get used to it very quickly. Now that the hierarchy has been flattened, you should never run into a problem right clicking on the name of a file in the library to get its shortcut.

You can then past that shortcut into a hyperlink or simply add it in the body of an email when you want someone else to open the file rather than attaching the entire file to the email. This will save space in your Outlook mailbox as well as reduce some of the strain on your Exchange server.

Hope this helps you understand how metadata can help you slay the nested folder dragon.

C’ya next time.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s