Managing Permissions and Security Groups in Dynamics 365 Business Central – Part I
Managing security in Microsoft Dynamics 365 Business Central is one of the most critical—and often overwhelming—tasks for administrators. Giving users too much access to data can lead to errors or fraud, while giving them too little access can prevent employees from performing essential job functions.
Whether you’re preparing for an implementation, cleaning up after go-live, or simply trying to gain control of user access, the complexity of permission sets, security groups, and user roles can feel like navigating a maze.
Start with permission sets, not users
Many organizations begin by assigning permissions at the user level. But that’s not the best place to start. Instead, the foundation of good security in Business Central begins with well-structured permission sets—collections of access rights to table data and objects that align with job roles like purchasing, sales, or accounts payable. Once the permission sets are defined, you can associate users with the appropriate permission sets for their jobs.
Microsoft provides pre-built permission sets. In fact, most, if not all, ERPs come with pre-built permissions. The goal is to make it easy for companies to get started using their software right away. While convenient, these default permissions sometimes give users more access than necessary to certain tables and data.
Instead, administrators can use Business Central’s pre-built permission sets as templates to create custom permission sets tailored to real-world tasks. One reason to create your own permission sets and not edit the ones that Microsoft provides is that Microsoft can overwrite its built-in permission sets at any time when it issues updates.
Another reason is that since there is no “one size fits all” for businesses to set up user access permissions, using these default permission sets without understanding what they do can lead to unintentional data exposure. Verifying that all user permissions match their role requirements is simply good business practice.
To illustrate the point, consider that very few people need the ability to edit a company’s payment terms—most only need to read them. Starting with this kind of access logic reduces risk and increases security.
Suppose a user has created a purchase or sales order, but the customer or vendor has payment terms that come from another table.
In this example, the user only needs to READ from the Payment Terms table because very few people in the company need to be able to edit the payment terms. However, several default permission sets in Business Central allow users to read, insert, modify, and/or delete payment terms, even though most jobs do not require that level of access to the table data.
Over 3000 objects in Business Central can be accessed directly or indirectly, and administrators will need to configure the level of access each job role should have to each data object.
For another example, Microsoft’s pre-configured D365 PURCH DOC EDIT permission set can access 91 different objects, some with Insert, Modify, or Delete privileges.
If you start allowing multiple permissions in multiple groups, you lose visibility on who can modify or delete data. Instead, you should create new permission sets that limit access to specific tables and assign them to individual roles and users as needed.
Defining your own permission sets
For example, we can define three permission sets, each having defined access to customer data: _AP CUSTOMER VIEW, _AP CUSTOMER EDIT, and _AP CUSTOMER ALL. This way, users assigned to _AP CUSTOMER VIEW can only view Customer, Ship-to Address, and Contact information.
Users assigned to _AP CUSTOMER EDIT can view, insert, and modify (but not delete) Customer, Ship-to Address, and Contact information.
Users assigned to _AP CUSTOMER ALL can view, insert, modify, and delete Customer, Ship-to Address, and Contact information.
Setting permission sets in this way makes it easier for the administrator to see who has access to various tables and what they can do with that access. When assigning permission sets, remember that they are used to lock down permission to view or modify table data. Users still need basic table access to read the data or create reports.
NOTE: ISV products require their own permission sets.
Permissions to other objects, such as Codeunits (which gives permissions to access executables) and Reports (which allow users to run reports), are generally provided as needed and included when users require access to the pertinent table data.
In this blog series, we are focusing primarily on Table Data because this is where auditors will focus more of their attention.
Take control of your Business Central security
At ArcherPoint, we help organizations like yours take the guesswork out of security in Microsoft Dynamics 365 Business Central.
In upcoming blogs, we will explore how to set up permission sets, security groups, and user assignments in more detail.
Contact ArcherPoint by Cherry Bekaert if you need help configuring your Business Central security.