Comprehensive manuals or other help to set up Metadata Structure

To me this is indeed the hardest part of any kind of document management. And the best meta data structure is always dependant on the specific requirements, so there's no way to give the best solution that would fit everyone. But like you asked, there are some "best practices" that usually lead to good things.

I assume that you have studied the sample vault, which gives quite good guidelines on the idea of object types and classes.

So, what I suggest, is that you will provide here your business diagram or other information of your requirements, and we will try to give you ideas how to develop the meta data structure. Let us know if this is OK with you.

Best regards,
Samppa

To start with a good basic structure, I really recommend to refer to the sample vault provided with the installations. But to achieve the same basics usually required in any kind of business, you can start with the following aspects:

* Usually one deals in the business with customers and suppliers (companies)
* Customers and suppliers have contact persons
* In addition to the material or knowledge transfer, one also exchanges documents with suppliers and customers
* This relationship with you and customer might create a project

Now, this should be broken down to a little bit more detailed information. What information do I need to know about the suppliers and customers? Here's a quick list that came to my mind this morning:

* Name of the company
* Where is it located, address?
* Telephone number
* Fax number
* Web site

Then again, the location should be broken down to more simple units, such as:

* Post address
* Visiting address
* City
* Zip code
* Country

So, based on this information, we would need to create these property definitions into the vault:

* Customer name
* Post address
* Visiting address
* City
* Zip code
* Country
* Telephone number
* Fax number
* Web site

To make things easier for the end-user, it is always recommended to use value lists. This helps to avoid spelling errors, since spelling errors would generate problems when we want to list e.g. customers divided into virtual folders by the city property. And in addition to the spelling errors, for example Swiss city Genève is spelled like this in French, but it's Geneva in English and Genf in German. This would generate 3 entries and statistical information would be wrong.

So, it could be good to have a list of cities? It depends. If you can get the information easily, why not, or collect it by allowing the users to add items to the value list. I think most of you have already noticed that zip codes could be listed in a value list too. And why not countries. But the interesting part is, that you could also define relationships between these lists:

* Country could have a sublist of cities
* Cities usually have multiple zip codes

It would be nice, when I choose e.g. the country in a meta data card, the city field would only show a list of cities in that chosen country. Or if I choose the zip code, country and city are automatically filled. Not a problem! Once you have made these relationships in M-Files Server Administrator, the basic behaviour is like that.

And if you already have a list of customers in a database, why not connect M-Files Server to the existing database. This will allow you to use the same information directly in M-Files, and still in e.g. dedicated CRM software which uses the database directly.

For some property definitions the value list is not a good option, for example listing all the world's telephone numbers in a list is usually not a good idea, unless you are a telemarketing company and you really need to divide customers by e.g. area codes. And even though it is telephone number, usually it contains some other characters too. So, text is a safe choice.
By implementing these steps you should have your customer object type more or less ready to be evaluated, if it really contains all the things you need in your system, or not. Now, you should do the same for the remaining objects, such as contact person, project and document.

Within documents, the hardest part is to create the correct classes. Usually, e.g. email is not a good class definition. Why not? Well, using email you can send and receive any kinds of documents (for example proposals and requests for proposals), and email is more like media used to transmit that information. Email can be used as an option in a e.g. Media property definition, to distinguish whether the document was transmitted using a normal letter or email, if that is important in your business.

So, to recap, it really takes some thorough thinking to create a good meta data structure, and there is no general structure that would fit all purposes. But once you let us know more about your requirements, I'm sure we can point you into the right direction. And like you implied, in M-Files one can usually make the same thing in many ways, but usually there's only a couple of good ways to do it. But it all depends on your requirements.

Once you have these set up, then the next big thing is to create suitable views, set up the permissions, templates, ... ;)

Best regards,
Samppa

I have just spent the last couple of months to prototype and build our metadata structure. The key to me was to build something, and then to test it by filing some test documents to establish if I have the appropriate level of properties, value lists, classes etc. It became very complex which then lead me to a phase of optimising it; simplifying it; reducing the number of document types, making more use of templates etc. It is also important to relate each metadata design compotent with the views and how the users will ultimately want to use the metadata to manage their desk and the business.

it was a real journey (and not yet completely done). What I do know is the more time I use in the design phase the less time I will have to spend ultimately to find quick solutions for problems that I did not foresee.

I can sympathise with you on this! I've been on the same journey...

We have also gone through a number of vault iterations whilst we have user workshops, map the type of documents we have, and learn the capabilities of M-Files.

Much of our data now comes from a bespoke SQL application we use - and our CRM system.

We have found there are many "right" ways to create a structure - but ultimately it must be easy for the user to understand and use!

My biggest problem is changing user behaviour - as Explorer makes it so easy for people to "dump" stuff in folders!

Paul

Hi,
answer to this post is an is the primary explanation of the M-Files. I just started this journey but now M-Files is my Mount Everest. I try to get the summit.
I hope this forum will help me achieve this goal.

Thanks in advance for every hint.
;D

I know this thread is quite long dead.. :)
and after reading your posts, it's like hearing others who are going the same problems as well, :)
I would like to ask from the seniors, if it's possible / would you guys be generous enough to share your metadata structures for others to look at and learn.
I Know it's quite a lot of q request (might as well give it a try though) but this will be of great help to the community especially for newbies. :)
Thanks in advance for considering. :D

cheers,
;D

I'd share my metadata structure, but it's probably a good example of what NOT to do. Instead, I'll just say this:

1) Wherever possible, use document templates instead of creating classes. Originally, I used classes to determine what properties to show to users. I thought it would be easier for them - but the multitude of classes just ended up being confusing. Templates would have accomplished the same thing, and would have also provided a consistent format for many document types.

2) Make good use of objects... Every business tends to be revolve around a few core concepts (Accounts, opportunities, projects, assets, etc.). Capture these items as objects and you'll find that almost every document you add to the vault would naturally relate to one or more of your objects. Define good permissions for your objects, then set up automatic permissions on your documents - your vault will practically manage itself.

3) Consider breaking large vaults into a few smaller vaults. I made the mistake of having one huge vault for everything. It now takes a good 12 hours to back up, and has tons of classes of which each individual user only needs a subset. Analyzing the usage patterns, I can see now that I could probably break the vault into 2-4 vaults based around specific sets of business processes that would be easier for users to work with. Your engineers probably don't care about marketing brochures - why put them in the same vault?

Just my 2-3 cents...

Jason

thanks for the share and insights Jason, really helped a lot, specially for a newbie like me.. :)

100% agree with JasonP, it sounds like we made exactly the same mistakes!

Looking at others metadata structures will just cloud your solution - make sure you get a good idea of how your users work (they are your stakeholders, and they can make the project impossible to complete if you don't cater to their needs!). User acceptance is a big factor, and they have to understand that it is document management not file storage.

Don't try to be too clever, keep it simple - a user will typically take the path of least resistance, so will select a class with 5 options over one with 50 if it is quicker for them!

I would argue that the "Sample" vault is a good starting point for most - just tailor that to meet your needs.

Paul

Adding a reply so this shows up under my forum subscriptions.