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
    This is a fascinating discussion. Some things I'm asking myself as I'm experimenting with and hoping to roll our M-Files, would like to hear input if anyone has the time:

    1. How much is too much (required) metadata values? In other words, what's the point at which you're driving users crazy and/or they just start making bogus selections so they can file a document? 2 values? 4?

    2. No matter how well you think it through I'm sure there are going to be scenarios you didn't think about. For those instances do you create a generic category for users to drop files into named "needs metadata" or something like that, so that you can improve your metadata structure and add metadata to those files as needed?

    3. Do you ever require a field as a way to streamline metadata, but allow a value of "none" for instances in which is does not apply? Or should metadata ONLY be required when it's certain there will be a value that applies?

    4. How easy is it to change en masse certain elements of meta data after you've started? I don't mean change a single value, I mean if you realize something you did is substantially wrong and you wish you'd done it another way.
Reply
  • Former Member
    Former Member
    This is a fascinating discussion. Some things I'm asking myself as I'm experimenting with and hoping to roll our M-Files, would like to hear input if anyone has the time:

    1. How much is too much (required) metadata values? In other words, what's the point at which you're driving users crazy and/or they just start making bogus selections so they can file a document? 2 values? 4?

    2. No matter how well you think it through I'm sure there are going to be scenarios you didn't think about. For those instances do you create a generic category for users to drop files into named "needs metadata" or something like that, so that you can improve your metadata structure and add metadata to those files as needed?

    3. Do you ever require a field as a way to streamline metadata, but allow a value of "none" for instances in which is does not apply? Or should metadata ONLY be required when it's certain there will be a value that applies?

    4. How easy is it to change en masse certain elements of meta data after you've started? I don't mean change a single value, I mean if you realize something you did is substantially wrong and you wish you'd done it another way.
Children
No Data