M-Files is a 2025 Gartner Peer Insights Customers' Choice for Document Management
️️➡️Download the report!

Options
  • Locked Locked
  • Replies 18 replies
  • Subscribers 9 subscribers
  • Views 405 views
  • Users 0 members are here
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Comprehensive manuals or other help to set up Metadata Structure

Former Member
Former Member
Though I always thought that I'm not stupid I have really hard time setting up (rather complex) Metadata Structure.
User guide that I got from M-Files is next to nothing. Unfortunately the help is not better - actually I've never seen worse. M-files offer something (that I doubt would be what I truly need) for "modest" fee of EUR 500+?
Does anybody have advice how to set up Metadata Structure this on budget that does not break my bank account?
What I truly need is the 'best practices' how to use Object Types, in conjunction with Value Lists and Property Definitions in order to get proper Contact type/Contact/Contact Person/Project/Document relationships. So when I select specific Contact type (Client, Prospect, Vendor, ...) only appropriate list of companies appears in Contact property dropdown, and only appropriate list of project names appears in Project property dropdown, and so on. Also how to use Value lists and Sublists - when is appropriate to import values from db, and when enter manually via M-Files client.
Parents
  • Former Member
    Former Member
    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
Reply
  • Former Member
    Former Member
    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
Children
No Data
M-Files
M-Files Support


© 2025 M-Files, All Rights Reserved.