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

Management of Configurations

Hi M-Files Forum, 

As you are aware, M-Files is a highly configurable system and, I was wondering how other users have organized their configurations once they begin to become substantial in number.

Over time, I can see the configurations area becoming very large and tough to manage. Is there anything you can recommend to pre-empt the problem? And be more proactive about how these are managed? My concern is making sure configurations are organized in a way that ensures future administrators inherit a logical and organized system that allows them to do their job effectively and efficiently.

For example: Have you or your organizations used any specific groupings or categories to organize the various types of configurations?

e.g. "workflow" configs, "appearance" configs etc.

Many thanks in advance.

  • Hi Jo,

    In this context are we talking about "Metadata Card Configuration" rules?

    Regards,

    Craig.

  • Yes - I am definitely talking about the Metadata card Configuration here. thanks!

  • This is something that will really vary based on your implementations as some rulesets and configurations work better with organization attempts than others. The biggest issue you will likely see with grouping them is if you have rules that take advantage of the way rules are executed which is top to bottom. If your configuration uses the order it somewhat limits how you can group them.

    One option is to use the sub-rules to group rules into broader parent groupings or rulesets. For instance if you have a lot of rules on how Contracts are handled in certain situations you can create a parent rule of 'Contract Rules' that uses broad filters and minimal to no actual behavior. Then you can use sub-rules under that parent rule to narrow down the specific ruleset. Such as having sub-rules like 'Signed Contracts', 'NDAs', etc.
    That could let you have just a few generic rules at the top level of your configuration that you can start to drill down to look for what you need to adjust.

    Also, don't forget that you can use the Advanced tab to view and read the 'JSON' of your configuration which allows you to use 'CTRL-F' to search for specific elements to help find which rules affect that element. For instance searching for a class 'NDA' to see how many rules run on that class.

  • One way to categorize is by following the vault structure for object types and classes: create top level rules for each object type ("Document", "Project", "Customer" etc.) where the object type is used as the rule filter and then sub-rules under that as needed. For the Document object type (and perhaps others, too, if they have multiple classes) you could have further sub-rules per document class, if the classes have their own specific metadata card configuration rules.

    This structure should make it relatively easy for other admins to find out rules which affect a specific object. You could also add descriptions of these configurations to your other vault documentation.

  • Some of the bigger challenges in my world are:

    • If two or more Admins change rules at the same time the last one to save will overwrite changes made by the other. Have done that a couple of times when training someone via a shared screen where I went ahead and did some of the difficult parts on my computer, and the trainee took the simple parts on his computer...!
    • When was something changed and why? What was it before the change?
      It would be great to have History on configuration changes and the ability to roll back.
      Have in some cases added an "IT changes" object type to a vault and recorded every change in there for documentation purposes. It may seem a bit too cumbersome at the time when you change things, but a month or a year later it can be quite helpful.
  • Thank you and yes we too have been severely burned with the over-write changes problem. The rework to redo such configurations has wasted a lot of valuable time that we didn't have. The good news is we know about the problem now. Agree that a history about config changes would be great to have. Thanks for the input.

  • Thanks Objects and Classes was also a logical structure for us to use, so its great to have that confirmation from you. When you talk about vault documentation, are you referring to a specific area in the M-Files Admin Client or are you saying (in  general) to keep a document with this kind of info for future reference? 

  • thanks for the excellent tips, I will definitely use the sub rule groupings.

  • I meant vault documentation in general, often during an implementation project there would be some documentation produced about the server and vault setups, integrations etc.

  • Here's how I categorize Managed Properties for easier finding:

    This helps me a lot but has the downside that you have do a lot of work sorting the rules cause there is only "Move to Top, "Move Up", "Move Down" and "Move to Bottom" buttons.. Would be cool to have the option to cut and paste a rule or move drag it to another position or if "Make Copy" would make the copy at the source position and not at the end of the list..