I am tempted to start this post with the Frankie Goes to Hollywood cry: “Absolutely nothings, say it again…”, but that might be a bit harsh, and it might deter you from reading on.

In this post I critique the standard OOTB SharePoint Document Library Web Part, as I believe we can do better, which is why we at Kaboodle Software built a couple of alternative solutions to do just that, namely K-Docs View and Far Point web part which is part of our soon to be released K-Links solution.

Like all our solutions, both K-Docs View and K-Links are Freemium product, that you can just download and use – you don’t even need to register! They are fully functional; you only need to become a licensed-paid customer if you want to unlock advanced features.

But I digress. The purpose of this post is to highlight the inadequacies of the standard SharePoint Document Library Web Part. If you are not familiar with this web part, the idea is that you can add a web part instance to any SharePoint Modern Site Page.

And then connect it to a view on one of the libraries in the site.

I guess the first question we might want to ask, is why we might need such a web part.

After all, why not just access the library list view and select an appropriate view? This is of course rhetorical question which I shall proceed to self-answer by exploring potential use case scenarios.

Using the Document Library Web Part for Quick Links

You might want to show some documents on a site page along side other web parts. We could maybe use a web part to provide a sort of quick links to show a subset of documents as might be returned by the selected view.

In this scenario we just want users to access the documents as consumers and so we might create a custom view for our purposes with just the document link column and then configure the web part to hide the toolbar and the See all link. Let’s give that a go.

Well, it sort of works. It is functional, in that when I click the document links the documents open. But…

• If you place the web part in a 1/3 width column (as above), which is the most likely scenario, there simply isn’t enough room to show document names of any length without cutting them off and displaying an ugly horizontal scroll bar at the bottom – not a good UX.
• We might improve things if we switched the view to compact mode and yes, this is a bit better.

• But you can only do that if the toolbar is showing (which we don’t want) and setting compact view mode doesn’t persist in any case – things revert after a page refresh.
• I don’t need the document select column (the check-circle in the above screenshot). I could reclaim some valuable space if we could hide that – but we can’t, it’s displayed whether we want it or not.
• I don’t want to display the column headers either, that’s also simply a waste of space in this scenario, but again, there is no way to hide this.
• And, whilst I’m on a roll, I don’t need line separators either – more space wasted!
• This web part has a fixed white background colour. Which is fine when the background is also white but just looks ugly (IMHO) when the section has a custom background specified.

If this is your intended use for the Library Web Part, my conclusion is that sadly, it is not fit for this purpose.

There are other OOTB solutions which we might consider:

• Quick Links Web Part: Yes, way more options with this one, but the problem is that the links are not dynamic and must be maintained manually, which I would much rather avoid.
• Highlighted Content Web Part: This is a very cool web part and at least it adapts to the background of the section, but it still uses up way too much space and I still can’t hide the line separators or column header, or (in this case) the See all link. And because this web part is driven by search (rather than hooking into a view) it is much tricker to set up if you need to filter by metadata attributes and specify a custom sort order.

You could also try other solutions, such as the free PnP Modern Search Web Parts. This puppy is amazingly versatile, and I am certain that we could build an acceptable solution that is dynamic driven by the data.

However, I am equally certain that this would be a non-trivial exercise, beyond the abilities and patience of all but the most persistent and capable citizen developers.

We decided to build a custom web part called Far-Point, part of the soon to be released K-Links solution. K-Links is currently in active service with several customers, but a commercial release is not yet available from our web site or the Microsoft Marketplace. I will provide an update link, here when this product is publicly available – we hope to release it in January 2026.

Dynamic Filtering

Back in the day of SharePoint on-prem, lots of web parts were connectable. This was occasionally useful as we could use one web part as the filter provider for other web parts on the page. When we moved to the cloud and SharePoint modern, we lost this capability with most standard web parts but the Document Library Web Part (and the equivalent List Web Part for lists) do retain this feature in the form of dynamic filtering.

This then provides us with a 2nd possible scenario for the Document Library Web Part. We might place a List Web Part on the same page as a Library Web Part and then set things up so that they share a common metadata property that can then be used as a key in the List Web Part to filter documents in the Library Web Part.

To do this, I created a custom list especially for this purpose and added a single managed metadata column (Business Function) which I knew was also a column in my library. For each metadata item, I wanted to filter by, I added an item to this list. I then hid the default Title column from the default view (we don’t need it here) and so end up with a simple list as shown below.

I then added a Document Library and List web part to the same page for dynamic filtering and set things up so that the Business Function column in the list could be used to serve filter values to the library web part.

By using a vertical section to host filter list web part and a single horizontal section for library web part I can make best use of the available screen real estate.

This basically works as expected, but I do have some ideas as to how we could make this better.

First, the filter list isn’t dynamic. I need to set this up in advance and that requires ongoing maintenance.

This approach can result in scenarios like the one above where I selected the Information Systems Technology filter but there are not items tagged with that value returned by the view connected with the library web part. A better solution would be for filter web part not to rely on a list at all, but instead dynamically show the set if filter values which are relevant to the document library view. In this case, the Information Systems Technology filter should not be shown because no documents have been tagged with this value and so it is irrelevant.

My second complaint is that I can only filter on a single property, the property I choose as my dynamic filter. With a larger result set I might want to filter using multiple properties with a logical AND in between them such, show me documents:

Where (Business Function is Quality Control OR Business Function is Procurement) AND (Content Type is Policy)

We can do the OR part just fine but the AND part is simply not supported with this approach.

I can do this when I filters using the column headers

This then begs the question as to whether setting up dynamic filtering is worth all the extra effort:

• Setting up a page
• Creating a filter list
• Setting up custom views
• Adding and configuring web parts to the page
• Ongoing maintenance of the above

Sadly, I can only conclude that it in most cases it is not. Cool as dynamic filtering might be, it is just too painful to set up and manage to be worthwhile.

Whilst column header filtering offers better functionality it is far from perfect. Top of my list of gripes are:

• It is not at all obvious how to set and manage column filters.
• It takes way too many clicks to set things up. First you must navigate a mini menu, then select the filter properties and then click the Apply button.
• If you want multiple filters, you need to do it all over for the next column.
• It takes just any many clicks to remove a filter as it does to set up.
• Filters on date columns are listed as exact values whereas what I might really want is to set a date range.

• I can only filter on complete values, whereas I might want to use a pattern to filter partial values, especially text values such as: Contains “Safety” or Starts With “SLI-POL”
• And why can’t I do that same pattern matching and specify case sensitivity?
• Any why can’t a match and filter with multi-line text columns?
• And if I am using a Managed Metadata column as my filter, I’d want to be able to apply that filter at any level in the structure, such that:
  • When I select a parent term, I want to include items tagged with any child terms
  • When I select one (or more) child terms it excludes items tagged at the more generic parent level

Below is a screenshot of the filter panel we bult into K-Docs View.

Documents on the right are dynamically filtered based on simply checking or unchecking values in the filter panel or setting a date range. A similar slider is shown for number and currency columns, and it works equally well for calculated columns.

Below shows the options for a text field.

In this case we are filtering the Title, so a single line text column, but it works equally well on multi-line text fields.

And notice, there is no Apply button, everything is filtered dynamically as you change the settings.

To be fair to Microsoft, they do provide a dynamic filter panel with some of the features described above which is accessible from every library view page.

But this is only available from the list view pages and not available when using the Document Library Web Part and it doesn’t support free text filtering (more on that in a minute).

A Niche Scenario

The only scenario in which I can envisage where you might want to use dynamic filtering is if your site contains multiple libraries and lists, which have all have items/documents that have been tagged with a common, unique property. You could then use the filter to prune the items/documents in several Library/List web parts at the same time.

Say you set up a customer management site which split data across several lists and libraries such as Complaints, Correspondence, Invoices, Quotes etc., and each document/item in these lists and libraries has been tagged with a column that uniquely defines the customer, then selecting the relevant customer in the filter list will apply that filter to all web parts and so immediately provide a context for the selected customer in focus.

This is a great idea in theory, but I have never seen it done well in practice. If you are using List/Library web parts in this way, I’d love to hear how its working out for you. And if it is working for you, that’s great!

However, I would consider this to be a niche scenario and argue that instead of splitting documents across multiple libraries, you might be better using Document Sets, say one for each customer, and then store products of different types in folders if need be.

You could then tag each Customer Document Set with a unique identifier and make that a shared property, so that it is automatically pushed down to all documents within the set. Then create a flat view and filter that, based on the customer identifier.

Quick Search Filtering

A key feature that I think is missing from both the Document Library Web Part and the standard library list view pages, is the ability to quickly type a keyword (or partial) and watch the result set filter dynamically as I type, and to show matches as highlighted text.

Below is a screenshot of how we build such a feature into K-Docs View.

We made this so that it works across all columns in the library, even if the columns not included in the specified view (although you obviously wouldn’t get the highlighting in that case). If we can do this Microsoft, surely you can too!

Stickiness

As mentioned briefly above, the Document Library Web Part has no stickiness when it comes to personalised view settings that user might make.

It will happily let you set the view mode to Tiles, or Compact etc.

However, when you do so the change is only temporary. Refresh the page and the web part reverts to its original setting.

This is because these personalisation settings are saved in browser local storage based on the view. If I want stickiness in my personal preferences, I need to access the view from the list/library and make my changes there. Then my preferences will be preserved between post backs.

Microsoft might try and argue that this is by design, but I don’t buy that! These are personal preferences, and stickiness should apply to these settings wherever they are made. If I choose to switch a view to Tile mode, then it should remain in Tile mode until I change things otherwise, regardless of whether I am accessing the view from a web part or from the list view page.

The Missing Killer Feature

The scenario which might justify the existence and utility of the Document Library Web Part, the killer USP, would be if it provided access to documents that reside in a different site. Imagine I manage a library of Controlled Documents (Policies, Procedures and the like) in one place but want to surface a filtered subset of those documents, as specified by the selected view, on some other site such as your corporate intranet.

You might tag documents in the source library with say a business function (HR, IT, Finance etc.) and then create views to return a filtered set of matching documents based on that attribute. Then on the HR page of your intranet you could add a Document Library Web Part, hook it up to the HR view. This would be wonderfully dynamic, so that when new documents are added and tagged with a business function, they just show up in the right context.

Yes, yes, I know we can do this with the Highlighted Content Web Part but setting this up is fiddly and has several limitations (which I won’t go into here). We might also use the afore mentioned PnP search web parts but that is even more complicated and fickle!

Also note that both of these solutions rely on search, which is generally fine, but it does mean that changes made at the source library location won’t take effect immediately. We must patiently wait until SharePoint Search does its next differential index to check that all is well. The problem is that this can take anywhere between 15 minutes and 24 hours (sometimes even longer). This means that both approaches are suboptimal if we need to push out a change to have an immediate result for consuming users.

As the Document Library Web Part uses the specified view to filter the returned results, and these filters are applied instantly, there is no need to wait for the search engine to catch up and so no flash-to-bang delay which might stretch our patience and cause confusion.

The USP of the Document Library Web Part could (and should) be that it provides easy access to documents which are stored on some other site and the documents displayed respond instantly to changed made in the source library.

But sadly, it doesn’t, and as far as I can see that leaves it with no USP whatsoever.

Doing Better

So, there you have it. I can only conclude that the standard SharePoint Document Library Web Part is essentially a sub-standard option for most use case scenario. It might have utility in certain niche scenarios but you will likely get a better outcome by providing users with an easy way access to standard views, say by using quick links as buttons on a page, or by using the other standard components such as the Highlighted Content Web Part when all you want is to provide quick access to the documents.

We can do better and in a future post I will provide an overview of K-Docs View, our solution to do just that.