Permissions in M-Files

M-Files is a tool for sharing and collaborating, but more often than not, there is information that cannot be shared with all users.

Every object in the M-Files vault has its permission settings. These settings determine who can read, edit, or delete the object in M-Files. Object permissions can be set manually or automatically.

Manual Permissions

The permissions of an object can be set either manually, or they can be set automatically when the object has a property value or class that triggers automatic permissions to be set.

This first example shows how permissions can be set manually.

Accessing the Permissions Dialog

To edit object permissions, you need to navigate to the Permissions dialog.

The dialog can be accessed via the metadata card.

Here you can see if the effective permissions of the object.

Editing Permissions

In the Permissions Dialog, you can specify what the users are allowed to do with the object by clicking Edit.

To set permissions manually, you can select a predefined named access control list from the drop-down menu. They are lists of permissions that are defined by your M-Files admin for your organization’s need. Or, you can disable the Use named access control list option to add users or user groups to the permission settings and then grant them access rights

A named access control list is a list of permissions that can be attached to an object. It is a list consisting of one or more subjects (users, user groups) and operations (delete, edit, read, or change permissions) that are either allowed or denied to those particular subjects. 

Named access control lists make managing permissions in M-Files very quick and effortless.

The available options are Read, Edit, Delete, and Change permissions. You can activate an access right by selecting Allow and deny it by selecting Deny.

Below you can find an explanation of the permissions you can change:

Read

A user with Read permissions is allowed to open the files in the object, as well as to view its properties. The user cannot check out the document and therefore is not able to make any changes to it. If the user does not have Read permissions to the document, it will not be visible to the user in views or search results.

Edit

Edit permissions enable users to edit the document. These permissions automatically include Read permission and Edit permissions. Edit permissions do not include deletion rights.

Delete

This allows users to delete the document but not destroy it altogether. Deletion rights do not include any other rights.

Change permissions

The right to Change permissions determines whether the user is allowed to change the permissions of the document. These permissions do not include any other permissions and they can be used independently of the other permissions.

Allow vs Deny

Denied permissions always take precedence over allowed permissions.

Automatic Permissions

You can use automatic permission settings to apply permissions to an object when the object has a property value or class that has been set to trigger automatic permissions. The object receives automatic permissions when such a value is added to the object metadata.

In the example below, automatic permissions have been activated. Read-only access has been granted to all users and a separate access to project managers.

The permissions have a Source, which indicates the source from which the object has received a given permission, a Description, which provides descriptive text for the permission, and an Active checkbox. If you can bypass the automatic permissions when you specify automatic permissions for the relevant value, value list, or object type, by clicking the Active check box, you can deactivate the automatic permissions given through the value.

This causes the permission setting to no longer be active and influences the final permissions of the object.

An object may have various permissions of its own, as well as automatic permission . All these permissions restrict the use of the object when the extended automatic permissions have been activated.

In order for specific access rights, such as read or edit permissions, to be granted to a certain user, all settings must allow it simultaneously.

Example:

A user has defined permissions for the project House project Haven that allow access for the project manager and project group only. When this project is added to the metadata of a project plan, the same permissions are granted to the plan.

Access that is specified for the project plan itself can apply, for instance, full control for all users, while the automatic permissions through the project object can restrict the use of the document in such a way that full control is granted to project managers only and all other users have read-only access.

Metadata Structure Permissions

Permissions can also define, for instance, what objects users can create in M-Files.

Often, it’s only the project team members or project managers who can create new projects. If that is the case, then Project would be visible to them only in the Create menu.

Your M-Files admin can limit who can create what types of objects. For instance, permissions can be set up so that only the HR team is able to create job application documents or employee objects.

View Permissions

Furthermore, the visibility of common views can be restricted with permissions, by your M-Files admin.

Limiting the visibility of the view does not affect object-specific permissions of the objects in the view.

Permissions in Workflows

Sometimes permissions are based on the lifecycle of an object, meaning that different workflow states can apply different permissions to an object.

For instance, in the “Draft” state, the document might be visible only to the document owner, and in the “Waiting for approval” state, the approver gets read access.

Once the document has been approved, the permissions can be set so that M-Files grants access to the correct users.