Split versions into files

Have a customer with similar setup. We have handled it by adding a 2 letter "division" prefix on all objects imported from or created for a specific division. The prefix is placed in the external ID as well as in the Name or title property. This way they avoid the problem you are facing.

If your issue only concerns a small number of documents you can manually open a previous version of a document and then save it as a new document. I am not aware of any method that can do this automatically. You would probably need to develop something if you need to handle large numbers of documents.

Thank you for replying. I think we have a plan for new documents. It was the old ones I was thinking of primarly. 
I was afraid that it wasn't easy to solve. I guess that it is hard just to filter out all the affected documents. "Every document where version is more than 1 and where metadata division differ between versions"...

I don't believe that's an easy thing to identify, unfortunately.  You could approach it via code but, even then, you'd still probably end up with a "candidate" dataset that you'd have to iterate over to check the details to see whether it needs to be processed.

Ok, as I suspected. Thank you for your reply. I will focus on solving the problem for new documents and then the users probably have to live with some docuements will be a litte bit hard to find.

One solution could have been if one could choose to have the results to be shown as one row per version, but it doesn't seems to be something that is possible in M-Files

You're right...  As you said: whilst you can search for historical object versions, the actual results will only contain one record per object (the latest version I seem to call)...  So that doesn't help here.

It's a difficult situation and I suspect the correct way forward will depend on the volume of affected older files along with how often they're actually being retrieved.

I think that's probably the best approach, at least for now.  If this causes significant issues then I suspect the only solution would be to write a little application to "fix" those old ones; if you have access to development resources then it shouldn't take a huge amount of work, but it's non-zero...  A partner with more significant M-Files development experience may also be able to assist as well...  They'd be faster, but I'm sure there'd be a cost there.

You're right...  As you said: whilst you can search for historical object versions, the actual results will only contain one record per object (the latest version I seem to call)...  So that doesn't help here.

It's a difficult situation and I suspect the correct way forward will depend on the volume of affected older files along with how often they're actually being retrieved.

I think that's probably the best approach, at least for now.  If this causes significant issues then I suspect the only solution would be to write a little application to "fix" those old ones; if you have access to development resources then it shouldn't take a huge amount of work, but it's non-zero...  A partner with more significant M-Files development experience may also be able to assist as well...  They'd be faster, but I'm sure there'd be a cost there.

Yes exactly. I´m totally new to M-Files so it would be high hill to cross if I´m gonna do it myself. At the same time I want to learn as much as possible to be able to do more on my own.

That's always the catch-22: without the experience things take a long time, but it's difficult to find the time to get the experience!

In deed!