Comprehensive manuals or other help to set up Metadata Structure

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

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