top of page
Writer's pictureAlfredo Iorio

Demystifying User Access: Mastering Permissions in Business Central

Updated: Apr 11

Business Central is an intuitive, easy-to-learn ERP system for small and medium enterprises. However, a robust data governance and access policy is essential to making the most of this application, and this is not an easy job.


System admins must manage data governance while ensuring seamless onboarding of new users and safeguarding sensitive information. In this short series of three blog posts, I will guide you through the ins and outs of user management in Business Central, covering user permissions in Business Central, including the new Azure security groups.


In this first post, you will learn how to add users to Business Central and how to create, manage, modify and assign permissions.


How to Add New Users

Adding new users in Microsoft Dynamics 365 Business Central begins with creating users in the Microsoft 365 Admin Centre. As an administrator, you can manage user creation in Microsoft 365 by accessing the Admin Centre, selecting Users, and then Active users, followed by Add a User.


From there, you can set up user basics, such as name, username, domain, and password settings, and assign product licenses. Once users are added to Microsoft 365 and have a valid licence, they can be imported into Business Central using the "Update Users from Microsoft 365" action in the Users window. Users are then automatically assigned permission sets based on the licence type in Microsoft 365. We will see how to modify permissions and the assignment to the licence type later in this post.


After you create users in Microsoft 365 and import them into Business Central, you can further define their access privileges by assigning permission sets and adding them to user groups.


Create and Manage User Groups

User groups used to be a crucial component of managing permission sets for different groups of users within your organization. However, they will be replaced by Security Groups in Q4 2024.


Controlling Access to Business Central Using Security Groups.

In Microsoft Dynamics 365 Business Central, managing user permissions is streamlined through security groups. These groups simplify administrators' tasks by grouping users based on departmental or functional roles. Unlike user groups created in Business Central, security groups are created in the Azure admin or the Microsoft 365 admin portal. This integration allows for seamless use across various Dynamics 365 applications, eliminating the need for administrators to recreate groups across different platforms.


Security groups offer a centralized approach to managing permissions, enabling administrators to assign permissions to groups rather than individual users. By creating security groups in the Microsoft 365 admin centre or Azure Active Directory, you can define permissions and assign them to users within Business Central.


Create a Security Group in the Azure Entra admin centre

Log into your organisation's Azure Entra admin centre to create a security group.

Then select Groups from the left sidebar, then all groups and choose create a new groups.


In the example below, you can see my Tenant Admins group; note that I chose Security as the group type. This is important because you can also create a Microsoft 365 group on this page, which you cannot use in Business Central.



Once on this page, you can assign owners and members to this group. Note that members of an Azure security group can be other groups and individual users. Assigning users with a Business Central licence to an Azure security group will automatically assign the user to the group in Business Central.


The next step is to update Business Central and pull the new security group. Use the search bar, type Security Groups, and open the relevant link. Then click New to add a new security group. You will see all the Azure Security Groups in your tenant from here.


I choose the new Tenant Admins and click OK to finish. As a result, the security group now shows in Business Central. Note that my user shows as a member because I assigned my user to the group in the Azure admin centre.



Assign permission sets to a security group

Once you create the security groups in the Microsoft Entra portal and synchronise them with Business Central, you can assign one or more permissions to the groups. You can add multiple sets to a security group, but you need to pay special attention when adding multiple permission sets to a security group because you might end up with conflicting permissions. We will discuss resolving conflicting permissions in upcoming posts.



Assign permission sets to a user

The last method to assign permission sets in Business Central is to work on individual users. This is not typically recommended in medium-sized organisations because permission sets assigned to individual users are difficult to manage. However, small companies can find this method quicker than using security groups.


To assign a permission set to a user, find the user and go to the User Permission Set tab of the user card. Here, you can add or remove the permission sets.



Implementing Permissions and Permission Sets

Once you have created one or more security groups, you can create and assign permissions to them. Users in these groups will inherit the permissions from the group.


Understanding the granularity of permissions within Business Central

You can configure permissions in Business Central in multiple ways:

  1. By user

  2. By Licence

  3. By Security Group

Permissions by license were introduced in wave 1 2022, and they still apply, even if you use security groups. The key difference between permissions by licence and security groups is granularity. You can create multiple groups with different permissions and assign these to users even if they have the same license. Permission sets inherited from the licence are legacy permissions that take precedence over permissions coming from security groups. If you want to use only security groups for permissions, I recommend removing permissions set on the licence configuration.



Special Permission sets - what they are and how they work

Business Central comes with default permission sets that cover most use cases. Some of these have special definitions and are the foundation of other sets. Typically, permission sets that you create or modify for your organization will include at least one of these special sets. The list below describes the special permission sets


  • SUPER: Users with this permission set can read, modify and delete all data and all application objects in the scope of the licence. This set cannot be modified; you need at least one user with a super permission set in each database (environment). Super users can synchronize users from Microsoft 365.

  • SUPER (Data): Users with this set can also read, modify and delete data in Business Central, but they cannot edit or synchronise users. This permission set is typically assigned to the finance management team, which needs access to all data but does not need to work on users, licences, or permissions. The picture below shows an example of what a user with this set would see when they open the user's page. The option to add or update users is greyed out


  • SECURITY: This permission set allows users to manage permissions, create new users, and remove or modify permission sets. This set is typically assigned to users who need to manage security, such as administrators who don't need access to the system data.

  • D365 BASIC: Users with this set get access to almost all tables; give this set to users who need to log in and show all pages, including the role centre.

  • SYSTEM APP - BASIC: Required to login to Business Central, this permission set give users access to most features of the system but modifying data is not allowed. For example, users can open the sales order list page but cannot create new orders or modify any field on the header or lines, including the ability to release orders.


  • SYSTEM APP - ADMIN: This set grants full permission to run all application features, such as reports, editing users' personalisation, and reading table metadata. It does not allow users to modify, delete, or create new records. This set is for system administrators who don't need access to the front end.

  • LOGIN: This set gives the minimum permissions that allow users to sign in to Business Central. This permission does not include the ability to access a role centre, and it is always used in combination with other permissions sets


Pre-built permissions sets

In addition to the special permission set, there are other pre-built permission sets in Business Central. Pre-built sets are of type System and cannot be edited. These sets typically apply to business areas and provide a quick way to set up security for users or security groups. Pre-built sets include permissions that typically apply to roles in the organization. For example, the permission set Dynamics 365 Accounts Payables includes permissions that users in that role will likely require.


Microsoft creates and maintains permissions sets of type System. This includes upgrading the sets on new releases to ensure users don't experience permission issues when new features are introduced.

In the picture below, you can see the page permission set in my sandbox, where I have User-Defined and System sets.



Understanding permissions within permissions in Business Central

A crucial design element of permission sets in Business Central is that more granular permission sets are nested into other sets with a wider scope. Permission sets nested into wider never include the same object; for example, the permission to edit table 27—the item table in the D365 Sales comes from a sub set D365 Item Edit. This design helps eliminate the risk of having conflicts in one permission set.


The picture below shows that set D365 Sales includes permission to read table data Item (Table ID 27)

Permission to view Item table exists in set D365 Sales

However, if we look into the set itself, we can also find other permissions. One of these permissions is for the D365 Item, Edit.



The more granular set contains the permission to read table data 27.



The best way to find permissions at the object level is to open the permission set card and click View all permissions.



Creating New Sets or Modifying Existing ones. Which method should you use?

We learned that permission sets of type systems could not be edited; therefore, if none of the pre-built permissions works for your organization, you first need to create user-defined permissions and then modify them to suit your security requirements. However, you have two options when creating new sets in Business Central; one is to create a new set from scratch and add permissions, and the second is to copy one of the pre-built permission sets.

Remember to check the organization and potential regulatory requirements when creating or modifying permissions. Security and data access policies are business critical decisions that should be taken by senior management. If in doubt, work with an auditor to find the best way to meet your organization or your client requirements.

The quickest way to create a new permission set is to create one and include more granular permissions. Open the page permission set and click New, then click Permission to open the set page. You should see a page that looks like the picture below.



Once you have the new set, you can add more granular sets to the one you created. In my case, I decided to add sets that include tables for the WMS module.



As I add more sets to it, I want to check that I don't include permissions that shouldn't be part of this set, so I click View all permissions to spot-check anything that requires attention. In my example, I can see that the set includes permissions to edit purchase lines and headers, which is fine for a typical warehouse role. However, what if I want to exclude permissions on purchase lines and headers for my warehouse team while still allowing them to receive goods? I need to edit the permission set and change the modified permission to Indirect.



Managing Indirect Permissions

Indirect permissions in Business Central are designed to allow users to perform actions that affect data without accessing the data itself. For example, indirect permissions to edit a purchase line allow users to post a warehouse receipt without giving them access to the purchase order.


Editing permissions on specific objects is possible on user-defined permission sets. You need to use the Permission tab on the permission set page to do that. In my case, I need to exclude objects 38 and 39 and reduce the modified permission to indirect. The picture below shows the result.



The reduced permissions now affect the set or sets that include those objects. In my case, the Warehouse Doc Post shows the reduced inclusion status.



If I check the full permissions for my set, I can see that objects 38 and 39 now show Indirect under Modify.



How to Copy and Modify Permission Sets

Another way to create permission sets in Business Central is to copy and modify an existing set.

First, select the set you want to copy, then click Copy Permission Set.



In my example, I need to create a new set of users who can create and set up new companies and dataverse connection because the organization also has an interface with Dynamics 365 Sales.



The new set is an exact copy of the pre-built one. Now I can add the set required to create and manage the dataverse connector.



As always, I check the permissions in my set to spot-check any missing objects. In my example, I noticed that permissions to create production BOMs are not included.



I have two options if I want to add permissions to that object. The first is to find a set that includes permissions for the manufacturing module, including the production BOM header and other related objects; I can also use the permission tab to include the specified object.



The result is a permission set that includes specific objects and other sets.



Recording Actions to Create Permission Sets

Another way to create user-defined permissions in Business Central is to record actions. This method has been around since the NAV days, and it is still a very effective way to create permission sets based on actual actions that a user must perform in Business Central.


Recording permissions allow you to start a session and let the user perform tasks like opening a page, applying a filter, and opening a related record. During that session, Business Central will record all the permissions required to perform the recorded actions and save them in the new set once the record is stopped. This is how it works.


Create a new permission set and give it a name. Then, open the permission set and find action Start under Record Permission.



Then, use the search bar to find the page or report representing the first step of the typical process you need permissions for and keep performing the actions you need. At the end, go back to the permission set page and click Stop to close the session. You will see all the permissions recorded on your screen



The downsides of recording permissions

Recording actions to create permissions allows you to create very detailed permissions and be extremely granular. The downside of this method is that it requires constant maintenance. For example, you might need to update recorded permissions every time Microsoft releases a new update, which does not happen when you copy and modify a pre-built set. This happens because when you copy a set, Business Central will keep the reference to the original set, which will allow your set to be updated automatically when the original set is updated with the newest version.


In summary

Permission sets in Business Central can be difficult to grasp at first. Still, once you understand core concepts, it becomes very easy to set up and manage your organisation's security and data access policies. The essential elements to understand are pre-built and user-defined sets, the nested model that allows the inclusion of sets within sets, and how to create and modify sets, including the ability to include or exclude permissions.


Regards

Alfredo

1,483 views0 comments

Comentários


bottom of page