Setting Up Permissions – NAV 2016

,

Setting up Permissions within NAV is a process of trial and error. Below are a few steps that should demonstrate how’s best to begin building Permission Sets for users who carry out specific roles within your organisation.

The first step is to have two users logged into NAV. The first should have a Super Permission Set shown below.

permissions 1

The second user should be an end user who will be carrying out the task of their role on a day-to-day basis, in this example we will be using a Sales Order Processor. This user should begin with the most basic Permission Setups, ADCS ALL, ADCS SETUP and BASIC. This gives the user enough permission to log into NAV.

permissions 2

N.B. It is or course possible to have both functions performed by the same person logged in with two separate user accounts (Shift + Right-Click on the NAV Desktop Icon and select Run as Different User to log in as another User).

Once the end user is setup and can open the NAV client, it is then possible to being building their Permissions.

This can be done in a couple of ways. Either you can apply Permissions to the User based on what Permission Sets appear application. i.e. we would expect our Sales Order Processor to require access to Read Customer information and Customer Entries. We should therefore click on the drop-down in the Permission Set field and select the Role ID that is applicable – in this case S&R-CUSTOMER.

permissions 3

It is possible to build the user permissions out of standard NAV Permission Sets, however, many users choose to construct specific Permission Sets for their Company.

You can construct a Permission Set by getting the end user to start trying to carry out their day-to-day functions, in the example below the Sales Order Processor has navigated to the Sales Orders list and received this error.

permissions 4

The error indicates that the User needs to be able to Read the TableData from the Cust. Ledger Entry table.

You can therefore start to build a Permission Set for your Sales Order Processors from this point. This is done by the SUPER user navigating to Permission Sets and selecting New.

permissions 5

You will then be prompted to enter a name for the Permission Set, here is it CRONUS-SOP and enter a Description of the Permission Set. To start building the set, highlight the line you’re going to add permissions to and select Permissions from the ribbon.

permissions 6

This will open the screen below where you can select the object that you would like to give permission to.
There are a number of fields to be aware of on this screen:
Object Type

– Table Data: this gives users access to read and write data in a table, though not access the table specifically.
– Table: this gives access to a specified table and may need to be used in conjunction with the Table Data.
– Report: allows a user access to run a certain report, this can be a document that needs to be printed or a process (i.e. creating a Pick utilises a report).

– CodeUnit: controls certain functionality within NAV and doesn’t relate to data.
– XMLport: users can import and export XML information via NAV through a number of pre-designed XML Ports.
– MenuSuite: gives access to menus in NAV such as the Navigation Pane.
– Page: this is where a user will see table information displayed in NAV.
– Query: query objects allows users to directly query data within the database.
– System: these are standard system functions inherent to NAV.

Each NAV object has a specific ID No. and this should be populated in the Object ID field to which you’d like to provide permission.
Read, Insert, Modify, Delete and Execute Permissions are all actions that a user may be able to carry out on an object. For example a user can Read and Insert data into a table.

These settings can be a way of restricting user access to certain objects. In our example the user needs to be able to Read the Cust. Ledger Entry Table Data, so the Read Permission field would show YES. We may, however, decide that they shouldn’t be able to Delete from this table and so we would leave the Delete Permission field blank.

For certain objects, such as Code Units and Tables, the option to Read and Insert is not relevant and so the only option NAV will give you is Execute Permission – similarly the Table Data Object Type doesn’t require the Option to Execute and so this won’t be available to add.

permissions 7

To Select the Object ID, if you don’t know the specific number, it is possible to select the drop-down shown below and click on Advanced.

permissions 8

This will give you the option to filter the objects based on the permission error message that you received previously.

permissions 9

Once you have added the Object to the Permission Set, you can then add the Permission Set to the user Role.

permissions 10

The user will need to log out of the system and back in to allow this change to take effect.

Our Sales Order Processor should then try to create an order of carry out the next step in their process. You can add permissions as and when errors occur.
If you continue in this way you can build a company specific Permission Set that can be applied to any user carrying out the same role.

Obviously this can be a time consuming process and so many people will choose to start out with a few standard roles and add anything to them that is not already available as a part of the standard Permission Set.

The following two tabs change content below.