The permission system in N365 is complex. Privileges can be derived from many sources thus you should carefully design a privileges matrix for your application.
Application #
There are no privileges for an application. You can only indicate the application administrator. Such a person can read all documents in the application, add new documents, and delete the old ones. Furthermore, the administrator can also modify the application by changing forms, lists, processes, etc. To set the administrator you can do it in the general settings of each application at the bottom of the screen. Only the administrator of the application can add additional administrators.
A regular user gains access to the application via permission to a single document or form. It is enough to have privileges to add a new document to see the application but if you do not have permission to read any documents, the application will be empty.
Form permission #
When configuring the form, you can set permissions in the Permissions tab for every document created on this form.
Add permissions – add users or groups of users who can add the documents,
Full control permissions – add users or groups of users who can read, modify, and delete the document,
Edit permissions – users and groups of users who can modify the existing document,
Read permissions – users and groups of users who can access the document in read-only mode.
There is also a possibility to configure privileges for the creator of the document. You can add read permission to all and full access to the creator.
Permission to menu elements in the application #
You can restrict the visibility of the menu element to selected users or groups. To set it, choose the Restrict permissions checkbox and add users or groups to be able to view this element. Checking Inherit permissions will inherit view permissions from a parent menu element. If the parent menu element does not have any defined permissions child menu element remains visible.
Document permission #
Each document inherits permission from the form and process. You can check it on the tab Permissions. But remember, if a user is an application administrator he can see and read the document but he is NOT listed on the permission tab.
Using this tab, you can change permission to the specific document by adding or removing privileges. You can remove privileges derived from the form but cannot remove process privileges.
Process permission #
There is a special kind of permission – permission derived from the process. When you are an actor in the process, you must be able to edit and save the document. Therefore by default, when you do something in the process (you are one of the process actors) system adds you permission. When your step in the process is over, the system does not take away your privileges but changes them to read only so you can read the document but you cannot change it anymore.
Notice, that if you are an actor in the process but the process path omits you you are not gaining permission. A good example would be when the executor of the step is Anyone from the department and 5 different people have a workflow step awaiting. When your colleague did the work and finished the step, he gained permission and 4 others did not.
Changing permission #
Besides changing permission by hand, as described above, the system offers the possibility to change the permission by using a system action. You can configure the process so that the privileges are changed by going through the path. A detailed description of using this action can be found in another article here.
Managing access to data on the form #
When a standard permission system is not sufficient enough, ex. you need to show the document to the user but some of the data should be hidden, you can use the Condition of visibility option to control access to data. This way you can make some tabs, groups, or fields hidden from some users even though they can see and edit the document.
You can find more information on this feature in another article. Notice, that you will have to use the SQL statement option (example: User form in System application) to add advanced configuration to this function.
Permissions between system elements #
Other system applications can access certain system elements like forms and lists. To configure those permissions set the Element accessibility (Access) in the General tab (Lists, Processes) or the Settings tab (Forms). Elements accessibility options are:
Private: form can be used only in this application (by default)
Public: form can be used in all applications, even those created in the future
Shared with applications: most common and advised option for security reasons. You can specify a list of applications in which this form will be available. Notice, that if you later add a new application and want to use this form in this new application you have to share it with this new application.
