Microsoft Dynamics NAV 2016 comes with some very helpful new functionality for setting up user security. This includes:
- User Security Groups
- Helpful views of assigned permission sets
- Permission recording
- Mass selection of objects when creating a permission set
- Adding read permission for related tables
- Adding or removing permissions based on another permission set
These newly available tools can make security configuration for Microsoft Dynamics NAV users much easier. Let’s take a brief look at each.
User Security Groups
When multiple users perform similar business functions, they will have similar security requirements in the Dynamics NAV system. By defining a User Group (see below for a simple example of Accounts Payable), defining permissions for individual users can be accomplished by making a single reference to the user group. This can be much quicker than redefining all of the permission sets for the user.
As shown below, assigning the user group to the user automatically populates the defined permission sets. This does not remove any other permission sets assigned to the user, so it can be a starting point and individual users can still be fine-tuned.
New Permission Related Views
There are two new matrix views available. One shows the users with each permission set (pictured below). The other shows user groups with each permission set. This provides a quick way to determine which users have each permission set. For example, if you want to make a change to an existing permission set, this provides a quick way to determine which users will be impacted.
Even better… Not only does this allow you to see which users have which permission sets, but by toggling the check-box under a user you can actually edit that user’s permissions. This provides a much quicker way to define security settings (instead of having to open each user and add permission sets one user at a time).
When editing permissions, a record function is now available. You simply need to create a new Permission Set, click the “Start” button and then perform the tasks that you want someone with this permission set to do in the system.
When you have finished performing the tasks, return to the Permissions page and click the “Stop” button. Below is a sample of what was created by creating a new sales order and adding an item line to it.
The recorder only deals with table data, so it does have some limitations. However, based on the typical data control philosophy for enforcing security the limitations may be unimportant in most situations.
Mass Selection of Objects
There are times when it would be nice to be able to load a long list of objects into a permission set without having to do so one at a time. For example, if you want to limit access to certain reports, the permissions must be built to allow access to the ones that you require.
By setting the “Show” to “All” (see below) when defining a permission set, you can see all objects, even those that are not in the set (yet). On this list, you can then set filters and select a number of rows together. The buttons at the top then allow you to quickly set the permission level on all rows selected.
For example, if you filter to Object Type of Reports and then highlight all rows, you can quickly set the execution permission on them all by clicking the “Yes” selection from the “Allow Execution” menu (see below). Once that is done, you can remove the reports that you do not want to include in the permission set.
Adding Read Permission for Related Tables
There are times when you want to add a permission to a certain table. However, often there are other tables with related information. For example, the Customer table will require reference to tables like the Payment Terms and Currency tables (and several others) in order to validate data in certain fields. Simply adding the Customer table to a permission set could still leave a user running into permission errors when trying to add a payment terms code to the customer record. There is now a quick way to insert read permissions to tables related to ones you have already put into a permission set (by clicking the button shown below).
In the example of the Customer table this automatically adds read permissions to Payment Terms, Currency and other tables that are related to the Customer table.
Adding and Removing Permissions based on another Permission Set
The Include/Exclude Permission Set action allows you to build on a permission set based upon the contents of other permission sets. The Operation provides two options: Include and Exclude.
Selecting “Include” will add permissions to the destination set based on the source set specified. This provides you with the ability to combine the impact of several permission sets into a single permission set very quickly.
Selecting “Exclude” will scan through permissions in the source set and for each line look at the destination set. If the destination set already contains that permission, it will be removed. This provides a mechanism to start with a broad set of permissions and selectively remove some. This could be useful in situations where you want to remove certain reports from a permission set that initially was created to include all reports (see Mass Selection of Objects above). For example, you could build a permission set that identifies sensitive reports like financial trial balance reports. You could then make use of this to quickly remove these reports from a new set initially defined to include all reports.
Defining effective security by setting permissions can be a tedious job. Since Dynamics NAV allows for very granular permission definitions, it has often been a very time consuming task. Microsoft Dynamics NAV 2016 has significantly enhanced the tools available for setting up security which will make the task of defining permissions considerably less time consuming.