File Permissions


If M-Files does not support folder hierarchy. Could someone suggest a workaround to assign file permissions for a new added user. For eg. If I have 10000 files in M-Files all spread across the application in different locations. How can I select all those files and give access to the newly added user. Please this issue is a show stopper. Any suggestions would be highly appreciated.

Thank you

  • Hi.

    This sounds like a job for metadata-driven permissions and user groups. Using this approach would mean that the new user simply gets added to one or more user groups and they automatically get access to everything they need. 

    I recall from previous posts that you are not engaged with your reseller. That is unfortunate, as your reseller should be best placed to consult with you about what you want to achieve and the best way to structure M-Files to achieve it. You would probably save yourself a lot of stress by being guided by a good consultant. 

    That said, there is documentation on our user guide about how tk configure metadata driven permissions. What you effectively do is configure that certain elements of metadata (e.g. the object class) force a set of permissions onto the object; simply by selecting that this is an "HR Document", the document is automatically hidden from most users. 

    You use this approach to build a set of permissions for each type of object in the vault. 



  • Dear Craig

    Thanks for the response. The problem is that these are not department specific documents. These documents are random minutes of the meeting, presentations, some user guides and manuals, contracts and bunch of other stuff. Currently they are in a folder structure in windows. They want to migrate to M-Files with same folder permissions. For eg each minute of the meeting has a different user and it does not come from a user group. Hence making the minutes of the meeting object would make no sense as each meeting has different members. 

    Thank you 

  • Hi YST,

    The permissions can be driven directly from the metadata.

    So, for example, you add your "Meeting Minutes" to the vault, supply metadata for the type of meeting it was and the people who were there, and then use that to drive the effective permissions on the object.



  • Hi YST,

    The permissions can be driven directly from the metadata.

    So, for example, you add your "Meeting Minutes" to the vault, supply metadata for the type of meeting it was and the people who were there, and then use that to drive the effective permissions on the object.



  • Dear Craig

    Let say for eg, the class is meeting minutes and I add a property definition called "Type". This Type will be a text field, in which the user will type the meeting type. and then based on this type you want me to set the permission. Have I just confused you Slight smile

    Because I really confused right now

  • Hi YST,

    I don't believe that a forum is the best place for this sort of discussion.  It's very difficult to get across what's possible and what's not via this sort of medium.

    In general terms: metadata-driven permissions are driven from lookup-style properties, not text.  So you would choose "Meeting type" from a dropdown box and, depending on that, you add one layer of permissions (e.g. "Board meetings can only be seen by user group X).  You may also have an "attendee" dropdown where the user can select who was at the meeting, and use this to add another layer of permissions (e.g. "All employees who were at the meeting can see it, as can their managers").  Using this metadata-driven approach you can design a set of permissions that are applied automatically simply by describing the document, not by the user having to remember to save data in a specific location.

    Note: you can still have a view that mimics that old location and, when items are created/dropped in it, will automatically apply the metadata you need.

    We do have some pages on our user guide (M-Files User Guide ( and also via our Vimeo videos (M-Files Intelligent Information (, but these are fairly simple in context and likely won't model exactly what you need.

    If you need to go through this in significant detail then I strongly suggest that you reach out to your M-Files Reseller to discuss how best you can be supported.  If your Reseller cannot support you then please do let me know and I can speak to the Channel Account Manager for your region and ask them what other options are available.



  • Much appreciated Craig for the time taken to reply. I will try out what you have mentioned. But I do believe that M-Files should also include inheriting permissions like windows as an option. You might be able to drag in more customers that way. That being said this is just my feedback.  

  • Hi YST,

    The core issue is that M-Files is not based on locations in the same way as other systems; there is nothing to "inherit" from in the same context.  One object may be surfaced in multiple views depending upon metadata and view configuration.

    If you can switch your mental model across to the M-Files one then there is huge value to it, but it does operate fundamentally differently to a folder structure.  This is, honestly, one of the ways in which your reseller should be helping you.



  • Hi Craig

    I am trying out the method that you have mentioned where I need to user metadata driven permissions but I am having difficulty in understanding this.  When you said I can use choose Meeting Type from a dropdown list which would be an added layer of security.

    Ill explain my problem, currently our document are on SharePoint in a windows folder structure. The user is hesitant to move his data from windows based to classes but the management wants this done.

    To start off, I am trying out Automatic Permissions.

    The Steps I have followed are

    1) Create NACL

    2) Create a Class called Presentations

    3) Assigned Automatic Permission to class presentation and have selected the NACL

    Issue: I have 10 presentation of class presentation. The problem is that 5 users have access only 5 presentations out of the 10. How do I limit those 5 users to see only 5 presentations in the class and not all 10. 

    If you can shed some light on the dropdown permissions then may be I can classify the permissions based on the type of presentation and then give automatic permissions based on the type.

    Thank you and awaiting your response

  • Hi YST,

    I reiterate again that this is somewhere where engagement with one of our partners - to help consult with you to get this correct - would probably save you a very large amount of pain.  Permissions are complex, and it's often quite difficult to express both what you want and what you need via a forum.

    I think what you probably need is to create an additional dropdown ("presentation type") with values that allow you to distinguish between the 5 that users should see and the 5 that they should not.  You would then use these values to push a permissions layer to the documents that refer to them (i.e. "presentation type = 'internal presentation' allows access to user group 'A'").

    That said: I am not best placed to respond (my focus is on the APIs and Frameworks, around customising and integrating M-Files).  I'll ask someone else to respond back on your questions.



  • Thanks Craig for the prompt response. I guess going to the partner is not an option for me at this stage. If you can just share or ask someone in that field to share how to put those permission based on the group A. That would indeed be very helpful. 

  • To get the permissions to work you need a property that points back to the users list. An ACL won't work for metadata driven properties.

    Let's use 'Attendees' as the property.

    Then in the class(es) set automatic permissions that pulls from that property.

    You should now have a class(es) that will automatically set the permissions based on who is listed in the Attendees properties.

    Now you just need to determine how/who to add to the attendees. You can leave it manual so that someone can just go add and remove users as needed from each object.

    Or you can setup a configuration rule that can predefine which users should be in the list based on other criteria along with defining if the property should be hidden or read only.

    That last part would be outside the scope of this thread. Hopefully that answers how to set this up.

    When done it should give a lot of flexibility.

  • Thanks a lot Wesley. Appreciate the time taken to respond.

    I tried this but it does not solve my issue. Basically the end user has a presentation class and in the presentation class there are 100 presentations. 20 presentations group A should access, 20 should be accessed by group b and the rest have access to all presentations. So I have only one class called presentation. Basically I am trying to understand if its possible to set permission based on a property  called "Presentation Type".

    1) So I create a class called "Presentation"

    2) I set a property inside the class called "Presentation Type" - This "Presentation Type" comes from a value list. Lets say I have values. Presentation 1, Presentation 2 and Presentation 3.

    3) Presentation 1 is accessed by Group A

    4) Presentation 2 is accessed by Group B

    5) Presentation 3 is Accessed By Everyone

    Now when I select Presentation 1 from the value list drop down. Automatically only Group A and Group C should see and access the presentations

    I hope I have not confused you.

    Thank you

  • You need a 2nd property. You can't set permissions based on a non-user object.

    So you have to set your configuration such that there is a property that defines users, and then set that property to have their values automatically defined based on the presentation type.

    So keep Presentation Type.

    Create a new property 'Attendees' or whatever you want to name it.

    Setup a rule that if Presentation Type = Type 1, then Attendees = A, B, C.

    If Presentation Type = Type 2, then Attendees B, D E


    Then set your automatic permissions to feed off Attendees.