In the design and implementation of an authorization framework in Microsoft Dynamics NAV and 365 Business Central (BC), permission sets are a vital part. In a solid authorization framework, permission sets are designed to represent user tasks and contain a set of permissions that allow a user to perform this task.

This way every user task that is identified in the organization and is considered to be separately executable from other tasks, will be represented by its own permission set. Besides these permission sets, permission sets for all users have to be included, for example a basic permission set to log in. This will result in a significant amount of permission sets in the permission sets list. A clear overview of which task is represented by the permission sets is important for the setup of organizational roles (role based access) and authorization framework management.

Our standards for naming and coding permission sets

2-Control has a great amount of experience in the design of the authorization framework for a great variety of organizations. Regardless of the size and nature of these organization, in every project the same standards for naming and coding permission sets are used. We’ve listed the 3 most important standards to improve your permission set coding and naming.

1. Include an organizational code and the relevant business process in the code.

   Include an organizational code to easily identify the permission sets included in your framework. This way it is easy to distinguish standard sets created by Microsoft, software partners or extensions from the sets that you use. Also include a code for the business process, like SLS for sales, FIN for finance or GEN for general. This also favors getting a clear overview by sorting the list. An example for company 2-Control, business process sales, task post sales invoice is 2C-SLS-INVOICE POST.

2. Include a verb. Use noun first, verb second.

   As shown in the example above, the standard for coding the task is noun first, verb second. This is mainly for sorting and overview purposes. If the maximum amount of characters in the code field allows it (max 20) and if relevant, include a verb. This makes it easy to distinguish for example a document posting set from a document creation set.

   What verb to use is sometimes dependent on the permissions in the set. For example, when RIMD permissions are granted, we use “manage”. With RIM permissions, we use “create” and so on. Some examples: 2C-SLS-CUST MANAGE for customer management, 2C-PUR-VNDR BNK CREA for creating vendor bank accounts, 2C-SLS-INVOICE POST for posting sales invoices.

3. Include ALL in permission sets that are granted to ALL users

   Read permissions on table data, most pages and reports and object types like table, query’s and XML ports are often grated to all users, due to their low risk nature when granted on its own. Also, to log on to the system certain permissions are required and are naturally granted to all users. Sets that are granted to all users are easily identified is “ALL” is included in the code. Examples are 2C-GEN-ALL USERS, 2C-GEN-TABLE ALL, 2C-GEN-PAGE ALL and 2C-GEN-REPORT ALL.