Eat My Cake? SharePoint Search Folders

[tictag]

I want to keep all my business documents in relevant folders (e.g. proposals, invoices etc) but I also want client-based folders (e.g. client A, client B etc). I absolutely refuse to duplicate files and cannot be bothered with file shortcuts.

If I were to add metadata to every business document (e.g. document type, client etc), can SharePoint automatically search for relevant documents when I, for example, open a client-based folder?

Can I have my cake and eat it too?

[#2]

to do this, I recommend using Content Types, this will allow you to assign document specific metadata and provide you the ability to sort, group, filter and view files in a wide variety of ways. see https://support.microsoft.com/en-us/office/introduction-to-content-types-and-content-type-publishing... to get started. I also recommend reading articles from @Susan Hanley who is an expert on this subject, see https://www.susanhanley.com/white-papers

[#3]

I am currently playing with the Document Set content type to create my per-contract document set, but this is actually raising more questions because then I'd want folders of just proposals (or whatever) and folders for just clients. Feel like I might be making a rod for my own back!

Nothing comes to mind with configurable Search Folders like you get in packages like Docuware or even Outlook for that matter?

Thanks for the links, will take a look :)

[#4]

@Dean Gross You don't have to use content types, necessarily. It just depends on whether the content is in the same library or not. I think most users find it hard to remember to select the content type when they are uploading files. Document Sets or Folders or even unique libraries with shared content types might be the right option - it really depends. I don't know if I've written a lot on this because there is really no one consistently right or best way to do this. To get the outcome in the initial post, I might use multiple libraries or document sets and then pull all the content together for each Client on a page, which can easily surface content from multiple locations using doc lib or highlighted content web parts.

[#5]

So if I had one Document Library containing only the Document Set Content Type, with each of those Document Sets made up of proposals, invoices etc., each with associated metadata e.g. 'Document Type' and 'Client' , would I then be able to filter the Document Library based on that metadata e.g. Client = Client A, Document Type = Proposal?

I am, of course, assuming that:
(1) Document Set metadata requirements are distributed down into document properties and
(2) Document properties are surfaced up to the Document Library e.g. via columns.

What does a Document Library made up of only Document Sets look like if sync'd to Windows Explorer? Folders with files?

[#6 · Accepted solution]

For what you are describing, you may just be able to use "regular" folders. You can propagate metadata using Column default value settings so that solves (1) and for (2), the answer is yes. You can use Content Types if each document has different properties or just add a column called Document Type if they all share the same properties (i.e. Client Name). When you create a folder for each Client Name, set a default in Library settings. This seems a lot simpler than using document sets. I would consider document sets if I have a library of JUST proposals so I can keep all the files associated with a proposal together and have a standard "set up" for each proposal set. But, for what you are describing, I would first try using a Folder per client AND a Site Column that you add to the library for Client Name.

[#7]

@Susan Hanley Very cool, and I very much like simple! :)

I guess I was thinking Document Sets only because every contract has the exact same set of documents, and I liked the idea that these documents (templates) would be created for me on demand. Right now I tend to duplicate the last one, delete all the content then start writing the new - unnecessarily time consuming - and I'm forever forgetting to update the document properties (the document properties are used throughout the document itself so this had led to embarrassment ... ooops :flushed_face:)

Note: I intend to programmatically (Zapier/Flow) create the Document Set based on a stage transition within my CRM i.e. Lead > Deal > Document Set

I'll certainly give the 'normal' Folder + Metadata approach a try out. No point unnecessarily complicating things.

Thanks.

[#8]

@tictag 

Also take into account the tools to interact with your content. Do you only plan to use the web interface or also use Teams or use OneDrive for Business client?
Do you plan to drag and drop files from File Explorer or emails from Outlook, ...

Support for metadata is limited and as a result requires discipline from the user(s) to set metadata consistently.

Paul | SLIM Applications

[#9]

I guess ideally I'd like to use Windows Explorer together with a SharePoint document library sync, but I'm [somewhat pessimistically] guessing that document metadata doesn't sync through, so I'll likely need to use a SharePoint page. Not interested in Teams, nor OneDrive (i.e. personal SharePoint), nor drag'n'drop (no enforcement of required metadata).

Basic premise is that the Document Set is programmatically created based on my CRM stage, complete with all required metadata (e.g. Client, Document Type, Proposal ID etc). I then open each document in Word/Excel/Whatever desktop app and add content. Once complete, I intend to programmatically convert to Acrobat PDF format and send to client.

All I actually want to do manually, is write the content.

But outside of that heavily automated sales process, I also want to be able to search/filter my documents based on the metadata contained within the document properties e.g. client wants an update to a proposal, I just want to search/filter based on the Proposal ID or Client, for example.

I know this is all possible in solutions like Docuware, I just don't like Docuware! (and it's bloody expensive!).

[#10]

@tictag While I used to be a big fan of metadata and content types, but it's alot of work and requires a great deal of discipline to maintain. This is particularly problematic if you are not the only person in this library.  I've seen SO MANY metadata systems abandoned....

I've been converted to search. Works awesome out of the box with no extra effort provided your documents contain searchable text and your search term keywords. 

Also, metadata only works WITHIN a folder. Not very helpful if you're trying to find content across folders as you've described.

But search works GREAT across all folders as long as the document contains the term. So organize your contents in whatever structure works for you. Or even no structure at all. Use the SEARCH box at the top of the window to find everything applicable.

[#11]

IMHO, metadata is the future of remote/hybrid working document management and if Microsoft is not embracing this with SharePoint, then they are missing a trick. All other professional remote document management systems rely heavily on structured metadata e.g. automated case management for law firms. By way of related example, every single record on the Microsoft Dynamics platform has some form of record ID and associated metadata.

Full Text Search is an amazing technology, no doubt, but it can be a very blunt instrument when it comes to managing potentially thousands or even millions of documents.

If SharePoint doesn't support metadata well, big companies will always see it as a toy for personal and small business use, which it most definitely is not, imho, nor do I believe do Microsoft see it that way.

When I search for emails in Outlook, I rarely, or at least only as a last result, use full text search. I always use metadata search first e.g. from:client.com attachment:yes date:>10/01/2021. The same, imho, should go for document management within SharePoint.

But ultimately, you may well be right. If SharePoint doesn't meet my business requirements, then I too will have to abandon SharePoint and go elsewhere. For now, I am still optimistic ... and potentially naïve!

[#12]

@tictag Metadata is one of the great features of SharePoint. Configuring search to leverage metadata as refiners was a little complicated but it now getting much easier. And using metadata syntax in search, like you are doing in Outlook, is great too (e.g., ContentType:Policy). But, getting people to consistently apply metadata is not as easy. That's where auto-classification can be helpful for structured documents (e.g. processing Contracts using SharePoint Syntex) or with simple column defaults associated with folders. There is no one best way. It depends on the outcomes you are trying to achieve!

[#13]

@tictag 

You may want to look into SharePoint's property promotion/demotion mechanism. This basically allows you to set metadata in an Office file and upon uploading it is automatically captured into a SharePoint column. This works bi-directional: changing the metadata value in the SharePoint column also results in a change in the value stored within the document. There are several caveats:
- the names of the columns must match exactly
- download an Office file from one site and then uploading the same Office file to another site results in the metadata value from the original site ending up in the new site (promotion takes precedence).
- it only works for Office files (i.e. does not work for other commonly used formats like pdf, msg, zip, ...
- changing the properties in the Office file is tedious given that the document information panel was dropped several years ago.

The classic example is the Title property in Word.

About using email metadata in SharePoint. OOTB this is not possible but there are Outlook add-ins or SharePoint SPFx apps that address this. For example, there are apps that automatically extract email metadata upon uploading (example).

Paul

[#14]

@Susan Hanley 
I agree. The SharePoint platform provides you with different tools in your toolbox (e.g. search, views, metadata, flows, compound documents, ...) and the challenge is to use/combine them to meet your objective and deliver a robust solution.

[#15]

Right then ... best get crackin'!! :)

I too miss that document properties bar!

I definitely do intent to use the bidirectional metadata features, I actually use metadata within the content of my documents e.g. "This contract is between <client> and ..." and also want to search/filter document libraries using that very same metadata i.e. up and down. I'm hoping to 'send across' data from my CRM when the Document Set, and its constituent documents, are created. I hope also to be using automatically incremented variables to represent document IDs e.g. Proposal ID: P102767, Contract ID C44678 etc., using Zapier/Flow. AUTOMATE EVERYTHING!! A mantra I hold dear! :)

Never heard of Syntex - gonna be looking that up. Compound documents ... so much to learn :)

Seriously, guys, thanks so much for all your input. Not been here long but mightily impressed so far 8)

[#16]

This network is an outstanding place to chat with a wide variety of people, many experts share their knowledge and there is not any drama.

[#17]

It's not a question of SharePoint support - SharePoint does FINE with metadata. It's a question of people and discipline. Most people are not that disciplined and any system with metadata is only as good as the people who are maintaining it. If they don't fill in the metadata values, then documents don't check in properly and sort/filter can't work.

But if you go the metadata route, you're better off abandoning folders altogether and use JUST the metadata to organize documents. Metadata columns only work WITHIN folders, not across them.

[#18]

Thanks for the advice, based on bitter experience, I'm guessing! 

This solution is just for me and my own sales process so if I implement a solution for myself based heavily on metadata, then I'd me my own worst enemy if I didn't maintain metadata discipline. That said, I'm also human and make mistakes so I'm hoping a lot of the metadata population can be automated. e.g. from my CRM, flow variables etc.

I'm OK with the documents being in one document library, so long as I can filter/search based on metadata. I'm haven't tried this, but I am also OK with Document Type being a specific Content Type (as opposed to just being a document property metadata). A specific view could then be to 'group by content type' showing 'Proposals', 'Invoices' etc. As @Paul_HK_de_Jong says, the features are likely all there, just need to combine them into a solution that works for me.

I guess ideally I was originally hoping for a 'Search Folder' feature similar to that in Outlook where opening the folder would result in a pre-defined metadata document query e.g. double-clicking 'Clients' would open a folder with either documents grouped by Client or preferably a set of 'virtual' folders where documents would be collated into Client folders. This doesn't appear to be a feature of SharePoint. Maybe something for User Voice, if that is still a thing.