A long, long time ago (I can still remember when), I hit on the idea of building a new way to help users to more easily access documents in SharePoint. Documents stored in SharePoint can be tagged with a multitude of metadata attributes so as to facilitate search and retrieval, but they are essentially stored physically, as a a flat list, unless you use folders.

I’d rather not reopen the can-of-worms-debate as to whether we should still use folders or if they are an anachronistic throwback to a time when we didn’t have anything better. Some insist folders are the spawn of Beelzebub and should never be used, whilst personally I think they are fine so long as we don’t nest them too deeply and fall into the trap of using them as a surrogate for the lack of implementing an appropriate way for users to easily tag documents.

We can of course use the search engine to filter and refine our data and that helps immensely when trying to find what we are after, but search does the very opposite of what I am taking about here. It accesses information that is physically stored hierarchically in multiple sites, libraries/lists and folders, and presents the results as a flat list.

Here’s the thing though. We love hierarchies; being able to put things into boxes is an inalienable human trait. It seems we much prefer that over a big pile with no organisation. But this is where metadata can help us. We might choose to store documents in a flat(ish) library but that doesn’t mean we need to access them that way. So long as we have appropriate metadata, we can build a virtual, hierarchical structure from a flat, physical storage structure.

The key thing here is that because this hierarchical structure is virtual, we are not constrained by having just one of them (as we are with the SharePoint’s nested physical container structure of sites, libraries and folders), we can have as many as we need.

Furthermore, if we build the solution right, we can place the assembly of these navigation hierarchies in the hands of users, at runtime even!

For example, I personally might prefer to organise my view of the data structured first by product type (document type or Content Type) and then by business function, whereas you might want to pivot things and organise your view to be structured first by business function and then by product type. I want to browse Procedures => HR, but you prefer to browse HR => Procedures and who am I to argue that my way is any better than yours. If we are going to do this right, we need to empower users with choice!

Virtual Trees from the Physical Forest

One obvious way to construct this virtual visualisation structure is to build a tree. We love trees right. That’s what the folders in file shares are. File share folders (and SharePoint folders for that matter) are considered to be physical structure because documents physically reside in one place, the folder. A document cannot simultaneously reside in 2 physical folders.

This is a huge challenge, when logically a document might belong to more than one place. Does an IT Purchase Order belong in the IT folder or the Finance folder? Too often the solution has been to copy the same document to multiple locations but that directly contravenes the Prime Directive of good information management; “Thou shalt have a single source of truth”, as it leads to problems of:

• Currency: Are we all looking at the most recent document version.
• Consistency: Are we all looking at the same document version.
• Security: It is obviously a more complex task to implement effective security and access control measures if we have multiple document copies stored in different locations.

But when we have metadata, we are not constrained by the physical. A document can indeed reside in multiple (virtual) folders because in reality they are nothing more than pointers to the same single, physical instance of the document, and the single-source-of-truth directive is not violated.

So, if we consider our forest to be our disordered collection of physical documents, how then do we build our nicely structured virtual trees from this physical forest.

Standard Metadata Attributes

SharePoint gives us some standard metadata attributes in every SharePoint library and these include:

• File Name: The name of the document.
• Title: A single-line text field which Microsoft seem to want to hide in document libraries, for some reason.
• Created By: The user who introduced the document to SharePoint by either uploading it to the library or creating it, in-place.
• Created: The date and time when the document was introduced to SharePoint. Note that if the document was uploaded, rather than created in place, this is not when the source document was created, although technically it is the date and time that the SharePoint document was created because when you upload a document you are actually creating a copy of the original.
• Modified By: The user who last made a saved editorial update to the document (or any of its metadata attributes).
• Modified: The date and time when the last saved update occurred.
• Version Number: When versioning is enabled.
• Content Type: When the library is configured to support custom Content Types.

When building a hierarchy of virtual containers, we don’t to work with properties that would have unique values or else we will end up with a separate container for each document. This means that File Name and Title are of no use to us. Version Number is probably of no use to us either because that is a transient value that is generally not suited to grouping.

The user columns (Modified By and Created By) are potentially useful as we might want to group data this way.

At first sight, the corresponding date columns (Modified and Created) appear to be of little use as SharePoint records these events down to the second, so they are almost certainly unique. However, just because these values are stored at the granularity of a second, doesn’t mean we need to organise them at that same level of granularity. If we zoom out, we might structure things based on a wider timespan when would be far less prone to uniqueness. We could for example construct a grouping container based on a shared day, week, month, quarter, year, financial year etc. If we can do that, these properties surely have potential for our virtual hierarchies.

Above, I mentioned that file names are no help when seeking to construct a virtual hierarchy because of their value uniqueness. However, in the case of documents, that’s only true if we consider the file name in its entirety, but we can sort of zoom out here as well (like we did for date/time values) because each file name comes with a file extension (.docx, .dotx, .pptx, .pdf etc.) and we can zoom out further to a default application mapping such that the .docx, .dotx, .dotm file extensions are logically associated with MS Word, for example. This is of no use to use in SharePoint lists though as all list items are accessed through a SharePoint form with the same .aspx extension.

The Content Type property (when Content Types are enabled) is potentially a very useful attribute to categorise information. We might have a library that contains Policies, Procedures, Form Templates, Guidelines etc.

My point is that even with the bare minimum standard set of metadata attributes we have plenty to work with when seeking to build a virtual hierarchy. But this story gets better because we can add whatever additional metadata attributes we like and potentially use our tagging to slice and dice, prune and graft the data.

For example, we might typically assign a business function attribute and other metadata that help us associate information products with a business unit, vendors, suppliers, customers, equipment, geographical location and more.

Consider a SharePoint library used to store marketing material. This library has been configured to use custom content types for Photographs, Videos, Presentations, Brochures etc. and market sectors such as Health Care, Defence, Manufacturing, Academia etc. Given the standard set of metadata attributes, plus a few custom ones, there are multitude of ways to construct a virtual hierarchy.

• Sector > Content Type > Application/File Type: Academia > Brochure > PDF
• Content Type > Modified (the past year): Video > 2025
• Application > Sector: PowerPoint > Defence

This is just a few ways in which we might construct a hierarchy to create a virtual path to find documents, but when you think about it there might be thousands of ways to build things and no one way is best. It depends on the context of what the user is trying to do and their cognitive processes based on their personal understanding of the data space and how best to negotiate it.

The SharePoint Way

SharePoint does provides us with some basic built-in features which go some way to realising the above vision.

The first, and simplest approach is to use the Group By functionality available from the list view column headers

In the above screenshot you can see that I can group documents by their Content Type quite easily.

But this method has its limitations. For starters, it only lets us group documents by one property at a time. This means that we don’t really have a tree as such, but rather just a first order grouping mechanism.

We can do a bit better with SharePoint views, which allow us to structure information up to a maximum of two levels.

But my criticisms of this are:

• This is still not a proper tree – we are constrained to two levels only.
• I can’t dynamically restructure things – I am constrained by however the view was set up.
• There are some odd constraints with this approach. For example, I can’t group a view by Content Type which is something I really ought to be able to do.
• When you group by date values it groups items based on the day only – I’d really like to group by a date interval such as by week, month, quarter and year as well as by date.
• The UX is not the best – there is way too much clicking required to expand and collapse sections.

The Kaboodle Way

The idea that we could build something better was bouncing around my head for a few years and I explored several possible technologies which might help. My challenge was that whatever I used it needed to be open source with an unconstrained use and distribution license to make it affordable and it needed to be mainstream rather leverage some technology that might not be supported a couple of years from now.

My research took me to D3 and more specifically D3-Hierarchy Trees. Way back in the day I even posted a 5-part blog series about how we might integrate leverage the D3 way of doing things within the SharePoint Framework:

• Part 1: Getting started with SPFx and D3 – perfect bedfellows?
• Part 2: SPFx and D3 Trees
• Part 3: Making D3 Trees SharePointy in SPFx Web Parts
• Part 4: Controlling D3 Trees via SPFx Web Part Properties
• Part 5: Feeding a D3 Tree in an SPFx Client Web Part with SharePoint Data

The first post dates back to December 2018 and so this concept is at least 7 years in the making!

A couple of years ago, I discovered that a clever and enterprise chap named Ben Kremer had developed a React Wrapper around D3 Trees which can be accessed from https://www.npmjs.com/package/react-d3-tree. This awesome piece of software engineering made the development of a SharePoint solution so much easier – thank you Ben!

We have now developed a solution that brings dynamic tree building to SharePoint lists and libraries and is an integral part of our K-Docs View offering. This is a Freemium product which you just download and use for free – you don’t even need to register.

The screenshot below shows the All Documents view of a library where the documents are grouped by a single attribute, Business Function.

In the above screenshot the Quality Assurance node was selected (just by clicking it) so all documents tagged with that function, glide into view.

Clicking on a different business function node, say Safety Compliance, results in the Quality Assurance documents being tucked away (or you can in fact disable auto-collapse if you prefer) and Safety Compliance documents will glide into view.

Click on a document node to open a document in a preview panel or a separate tab.

The beauty and elegance about this solution is that the simply clicking the relevant grouping checkbox will add additional layers to the tree. But note, that the order in which you select the group by attributes is important.

In the screenshot below, I unchecked the Business Function option then checked the Content Type before re-checking the Business Function. This change of order means that documents are now first grouped by Content Type and then Business Function.

In this final screenshot I have first selected the Release Authority as the primary grouping and then the Modified column and set the date grouping level to be week.

So, there you have it. A new and unique way to access documents by dynamic grouping.

K-Docs View has been in services with preview customers for several months now and is receiving excellent reviews.

Why not download the solution and give it a try. Remember, this is a Freemium solution – no credit card, no registration. You only need to buy a license if you decided to unlock advanced features.