Dynamics NAV provides a robust and comprehensive security model, through which users can be defined and granted multiple authentication types along with structured security aspects to fulfill the organization needs regardless of its simplicity or complexity. In this post, we are going to shed a light upon basic security topics, by illustrating the key terms used in this module.
Dynamics NAV User
Initially, there are several key terms that must be understood before proceeding any further. The diagram below illustrates the interrelated setup steps to be considered when defining a new user in Dynamics NAV.
A user is defined from the User Card, in which you define the general details of the user such as: name, license type (full, limited, device only, windows group or external), status (enabled or disabled), expiry date and contact email. Furthermore, the user authentication type is selected (windows, access control, NAV password or O365). Most importantly, you can assign a permission set which defines the security rights of this user.
The user setup window defines the posting permissions from the user perspective, and the responsibility centers (sales, purchasing and service). It is important to remember that the posting permissions on the user level overrides the allow posting from-to option on the general ledger setup.
This window primarily defines the role center/ profile of the user which overrides the system default profile.
User Security Insight
The diagram below illustrates how a user is granted access. A user can either be assigned to permission sets directly or can be assigned to a user group in order to inherit the associated permission set accordingly.
Most importantly, understanding the permission set represents the key to understanding the whole security module. A permission set is a group of permissions, each permission grants the user a very “specific” access to either read, insert, modify, delete or execute a specific object in the system. Below is a simple example in order to help you map the theoretical concepts above into real-life scenarios.
An accountant needs to be granted an access in order to create/ modify GL accounts in the COA. The system provides an out of the box permission set called (GL Account Edit). This in turns includes multiple permissions to directly read and modify existing GL accounts, adding new ones. Additionally, it has permissions to read associated data such as currency, accounting period ..etc.
As shown above in the permission set, there is an essential option called the “Security Filter“, through which you can limit the permission line to specific data level. For instance, lets suppose that you are granting a user an access to see only items from a specific category (such as finished goods) . The security filter limits the read access to only items where their category is “Finished Goods”. Therefore, the security filter represents an important method of creating data level security.
Mahmoud M. AlSaadi