Microsoft Gold Partner Logo_edited.png
  • LinkedIn Social Icon
  • Twitter Social Icon
  • Facebook Social Icon
  • YouTube Social  Icon

Austin  |  Dallas  |  Houston  |  New Orleans  |  Nashville

Record Level Security in Dynamics NAV 2015


Dynamics NAV 2015. While there are Add-Ons available to facilitate security setup, some allowing profiling of user permissions via a SQL trace, easy copy and paste, and snapshots or version of security setup, the base product has all you need to get started.


Some things to consider:

  1. Before starting, it is best to compile a list of desired functionality the user should be able to perform as well as ‘must-have’ restrictions the user should be prevented from performing (good documentation always helps)

  2. Create two user accounts, one for testing the roles and one SUPER to add to permissions.

  3. Start with assigning the BASIC role, set the desired role profile on the user to display a fitting Role Center or Home page.

  4. Create a new role, assign to the user and add permissions gradually while performing defined tasks the user should be able to accomplish. While fixing permission errors in an iterative process is time-consuming, it still is the best method to keep security tight.

  5. Test critical functionality to make sure the user does not have access to tables that are not desired

  6. Use Record Level Security to filter data as needed and test the modified or created roles thoroughly.

A practical example could be the setup for QC users in a lab environment where each department maintains a certain type of test. Here the differentiator is the Item Number., e.g. one user group “LAB_A” tests Item No. “1”, the other group “LAB_B” tests Item No. “900” and “901”.

The setup for two custom roles has been refined with the Security Filter added on the Item No. and is applied to the test setup (Quality Specification Header) and the actual tests created (Quality Test Header):

The below Quality Specifications will then be filtered on the Item No. field – the filter value/expression itself will not be visible to the user.

A couple of notes on Security Filters:

  1. The filters or Filter Criteria are not visible to and cannot be removed by the user, unlike the ad-hoc Advanced Filters.

  2. The following characters are supported as part of the filter expression: <, >, |, &, ..

  3. Depending on the table and data, don’t forget to include blank fields, i.e. when creating/inserting new records (in the above example QC Tests).

  4. The following characters are not supported: *, ?

  5. The maximum length of a security filter is 200 characters, including all field names, delimiters, symbols, and operators that used in the filter.

  6. When multiple permission sets that refer to the same table data are assigned to a user, they are combined so that the least restrictive filter is used. Therefore, you should not repeat a table in multiple permission sets if you plan to combine those permissions sets for one user.