The Tenets of Designing a FileHold Library

FileHold is unlike Windows or paper-based filing systems – learn how to create your perfect Library of content!

FileHold’s Library structure necessitates a change in thinking about how to organize content. In training customers, we’ve developed three tenets for helping to guide organizations who are challenged by making the move to a structured environment like FileHold:

1. Library structure is about permissions and less about organization.

2. Never use structure in place of metadata.

3. Make sure the benefits of the structure are greater than the effort needed to build or maintain it.

What is a structured environment? “Structure” means that the information is quantified, controlled, and organized, so a structured environment for files means it’s highly organized with information related to content easily understood by machine language, often through a relational database. We can contrast that with an unstructured environment, like Windows. A file in a Windows system has no “structure” – the only way it can be organized is with the filename or with folders and sub-folders. These tools are fragile – if the document is put in the wrong folder, or the naming convention is not followed, the relationship is broken and cannot be restored by the system. Structured environments are robust – the information is tied to the content, not the filing system.

Tenet One - Library structure is about permissions, and less about organization.

FileHold uses schema and metadata for organizing documents. When a PDF is classified as an Invoice, Contract, or any other document type of benefit to the organization, that information is now attached to the document and no longer needs to be sorted with other similar documents to represent the use case. Schema is a part of the structure to help define how the document will be used. The metadata information connected to the schema further helps to relate the file to other content – the vendor name, for instance, relates to that invoice to POs, Contracts, Packing Slips – any other document or record where relationships need to be shown. This is the robust binding of structure, and far more resilient than the fragile bonds in the unstructured environment.

In this context, the filing location is less useful as an organizing tool but instead becomes a way to exert permissions for access. FileHold controls document access with the schema, cabinet, and folder. The schema controls visibility and is binary: either you can or cannot see the document. The Cabinet and Folder allow the organization to control the level of access the user has to contents, as determined by the user’s role in the system (which can change with each location). By utilizing groups, users’ roles can change depending on where the document is located. This eliminates the guesswork of access since a user must be able to see all three areas (schema, cabinet, folder) to see content: by adding a document or record to FileHold, these rights are exerted automatically. An invoice in the Invoice folder will be accessible by those with permission to see Invoices, and no granular management is required at the file level.

Tenet Two - Never use structure in place of metadata.

When examining a traditional Windows library structure, we might see something like this:

A screenshot of a computer

Description automatically generated

In an unstructured environment, this is well organized and logically laid out: if I was looking for an invoice for the Acme Co, I should be able to find it. However, if I don’t find the document in the folder, what is my next step? I might have to browse the other quarters, and then other years, and even then, there is no guarantee that I will find the document. Was it misfiled? Was it never received? Does it remain on paper moving through the organization for review or approval? When we call unstructured environments fragile, this is what we mean: moving the document to another folder means its bonds are broken and it cannot be easily located.

FileHold’s method of assigning schema to a document creates a bond of usage that cements the file to the organization’s use case – if the document is an invoice, then an “AP Invoice” schema fixes that concept to the file, ensuring it is always associated with that concept. Metadata extends this further by attaching essential information to the file: instead of it being an invoice, it becomes this invoice – related to the vendor, the date, a unique reference number, and a total. It gives it relationships to other documents not only in the schema but to other non-invoice documents that give meaning and value to the organization.

In this context, look at that Windows file structure again – that’s all structure that FileHold incorporates into the document. The schema (invoice), the metadata (vendor, date), and the operational needs for access (finance, accounting) are here. Moving documents from Windows into FileHold is less “flattening”, and more “utilizing”: taking the unstructured content and creating true structure from it. This is robust: move the document to a different folder, and the relationships this document has - the defining information about that document and how it needs to be used – are maintained.

Tenet Three - Make sure the benefits of the structure are greater than the effort needed to build or maintain it.

Structure is comforting. A well-organized office in a paper-based system likely involves lots of filing cabinets and properly labeled and even color-coded folders, with everything logically laid out. We associate this level of organization with order. With paper, it is also essential. Paper becomes challenging to find and utilize efficiently once order is lost. A low-level background buzz of chaos comes when filing is not maintained.

So, when moving to a DMS like FileHold that lacks a sub-folder structure, the instinct is to recreate the elaborate subfolder structure of Windows, to create little places to hold documents. This is understandable – if you have a folder for all of the invoices from the Acme Co for Q1 of 2023, it must be organized and therefore better.

It isn’t. First, as we’ve talked about in Tenets One and Two, this sort of folder structure is not required to organize documents. When elaborate structures are created, they have to be maintained. A folder will need to be created for each vendor, for each quarter, for each year – and for what value? Do you need to have a folder this detailed? A DMS like FileHold offers Search to locate documents based on their schema, metadata value, or multiple metadata fields, depending on what the user needs. Instead of creating a bucket to isolate these documents, a search can gather them just as easily. If you need to locate all the invoices from Acme Co from Jan 1 to March 30 of 2023, that can be searched quickly and accurately. Even better, the search can be saved for ease of recall. So – why create the folder? And more importantly, why go through all the effort to create and maintain that structure? What value does it bring to the organization?

If comfort is of value, then FileHold supports that: creating very specific folders or Virtual Folders to contain this content can certainly be done. But we urge you to ask if this is necessary. Do you need to create this level of detail? If you have folders with only one or two documents, is it worth your team’s energy to create them? With paper, that structure may be of benefit – but with FileHold, you might never browse for a document again. The Byzantine structure you’ve created will be ignored once your team starts using search to instantly locate what they need. Structure may be nice to consider, but only if a) it offers your organization value, and b) that value is greater than the time and effort it requires to maintain the structure.

Putting the tenets together

These three tenets are offered as best practice advice, and we offer them ranked from most to least important. For instance: you may have granular security needs for permissions for Library access which results in a great many folders to exert that control on documents and records – no problem, tenet one (permissions) is more important than effort (tenet three). Or, you might want to add metadata to documents by using their filing location through auto-tagging: no problem, you are not using structure instead of metadata (tenet two) you are using structure paired with metadata, and this is not in conflict with tenet one. Are permissions not essential because you have a small team and access control is not required? FileHold works just as well in that environment, and you can use auto-filing to help get the documents into the right place, which means you can bypass tenet one to focus on two and three.

Moving to a structured environment can be a sea-change for those used to paper and Windows-based unstructured environments, but we are here to offer some best practice advice for making that transition as smooth as possible. Contact us at [email protected] to learn how we can help.