How to fix common permission errors in Business Central
During your everyday work within Business Central, you may encounter the occasional error message. If you’re not a super user, you may encounter permissions-related errors, which tell you when you attempt to perform an action that you cannot do because you don’t have the proper rights or access to do it.
Permissions errors can be triggered doing pretty much anything in Business Central, but where your employees may get error messages will vary based on the permissions assigned to them. Luckily, most permission errors actually show you where the error originated and, therefore, you have the means to resolve that error.
Note that, to properly assign and adjust user permissions, you’ll need to be a Super User without any company restrictions (aka, database-wide access).
Standard Permissions Errors
First, let’s look at what a standard permissions error might look like. The error below was triggered because the user tried to post a purchase invoice (and, apparently, they do not have permissions to do so). A permissions error may prompt a new window to open with the header “Error Message,” as shown in the image below, but depending on what page you’re on, the error may also just open a small error box in front of the current open window. Either way, the error indicates that the action could not be completed, and at the end of the message is a string of details in parentheses.
The error reads: Sorry, the current permissions prevented the action (TableData 38 Purchase Header Modify: Base Application)
This is an example of a different error following the same structure, this time in the form of a popout window. It reads “You do not have the following permissions on TableData Whse. Item Tracking Line: Read. To view details about your permissions, see the Effective Permissions page. To report a problem, refer to the following server session ID: ‘30027’.”
The details within the parentheses actually tell you exactly what is holding the user back from performing that action, so that you can add or adjust their permissions accordingly. The great thing is that most permissions errors follow this structure, so fixing one permission means you can do them in future with relative ease. Here’s what each component means, using the example error we have above:
(TableData 38 Purchase Header Modify: Base Application)
Object Type: TableData is the Object Type. These can be TableData, Table, Report, Codeunit, XMLport, MenuSuite, Page, Query, System. Most of the time, the Object Type will be TableData.
Object ID: 38 is the Object ID. For “TableData,” this will be a number indicating a particular table.
Object Name: Purchase Header is the Object Name, which is another way to identify the Object ID. In this case, Table ID 38 is called “Purchase Header.”
Permission Needed: Modify is the specific permission needed on Table 38 to remove the error. There are 5 permission levels: Read, Insert, Modify, Delete, and Execute. In this example, the user tried to post a purchase invoice, which is one way to modify invoices, and was blocked from doing so.
Extension Name: Base Application is the Extension Name in this example, which indicates what the permissions are for – either the base application of Business Central itself or an ISV extension. In this case, Base Application was the result because Purchase Invoice functionality is a part of the standard Business Central application (not an add-on product).
Solving the Permissions Error
Though the error data will shift depending on the error itself, the process to solve it remains the same. And, actually, you have a few avenues available to you, depending on how granular you want to be with permissions. We’ll tackle one at a time. First, though, you’ll head to that person’s User Card and look under “User Permission Sets.”
Option 1: Assign them default/prebuilt permissions sets.
The first thing we suggest doing is looking at the permissions they already have and ask yourself if there’s a default or prebuilt permission set they don’t have that they should have. Let’s continue with the example error we’ve been using to illustrate. If this user is a standard Accounts Payable employee, we might assume they need to work with (create, edit, post) purchase invoices. If that user doesn’t have any permission sets specific to Accounts Payable, such as the system default “D365 ACC. PAYABLE” permission set or a custom one your organization has configured, that’s probably the first place to start!
A list of permission sets in this example environment.
This is the first step we recommend you take, but it is on the broad side when it comes to assigning permissions. If you’ve determined that the default or custom permission sets in your system are too general, or that this particular employee needs specific, limited access for some reason, then you will want to consider our second or third way of assigning permissions to them to solve this error.
An important note here: All Business Central environments include default system permission sets, which are configured by Microsoft. Microsoft’s default permission sets are built to be on the general side, allowing what may be considered standard permissions for certain tasks or roles. The “D365 ACC. PAYABLE” permission set, for example, is made to provide the permissions required for most Accounts Payable personnel across most organizations. As a result of this generality, Microsoft has to make certain assumptions about what permissions that job role will need, which may not always line up with your needs.
So, it is important to look into each permission set and see what it actually allows access to so that you can ensure it’s not too restrictive or too liberal for that user’s needs. If you find that a default permission set doesn’t work for your organization’s needs, you won’t be able to change it. Instead, you have the ability to create your own permission sets from scratch or copy a permission set that is close to what you need and adjust that copy to meet your needs. We recommend the latter, which will save a lot of time configuring permission sets from the ground up.
Option 2: Record a new Permission Set and assign it to the user.
Did you know you can record job tasks, which will generate all permissions needed for someone to perform those tasks into one permission set? This is our second suggested way to provide access to a user. It’s more specific than assigning a permission set designed around a certain job role, but quicker than assigning permissions one at a time. The system is cataloguing every click you make, every button you press, every table you go to and determining what access is required to do those things. It also includes all the background permissions needed for those actions!
After creating a new permission set, click “Action” and then “Record Permissions.” After you press “Start,” you will use the “Open this page in another window” popout feature or work within the same tab to record. You will click through the processes you want that user to do. You can record separate permission sets for each process, or you can do multiple related processes at once and roll them into one permission set. After you’re done, go back to this original permissions window and select “Stop.” You’ll then review the permission lines and adjust as needed.
From there, it’s as easy as heading over to the User Card and assigning the new permission set to that person!
Option 3: Provide the direct permission.
Finally, you can provide the direct permission that the error identifies. Essentially, this requires you to create a new permission set with a single line, filled in with the same data as the error (Object Type, ID, Name, and the needed permission). From there, you assign that permission set to the user.
The direct permission to eliminate the current error.
This is the most granular way to assign access to the system, and that can be very useful for some cases; however, the granularity comes with a downside. Because you’re only fixing a single permission to a single table at a time, it’s likely that the user will encounter subsequent, related errors when they test their ability to post that invoice. Why?
Well, picture any process as a series of closed doors, all lined up in a hallway. When you start a process, like posting a purchase invoice (which is what caused the original error), the system starts the process—aka tries to open the first door—and it’s locked. That’s when this error was triggered. The user’s permissions couldn’t open the first door, so we can’t see if the next door is also locked. Or the one after that. For instance, after we fixed that first error, the user tried to post the same invoice and received this next error: “Sorry, the current permissions prevented the action (TableData 120 Purch Rcpt. Header Insert: Base Application).”
The error reads: “Sorry, the current permissions prevented the action (TableData 120 Purch Rcpt. Header Insert: Base Application).”
Unless you know what subsequent permissions are needed to unlock all the doors in the process and fix them all at once, the user will keep experiencing the next error down the line, and you’ll have to fix them one-by-one. Eventually you’ll get the last door unlocked, but that can take a lot of time. It’s not particularly difficult, but it can be very time-consuming if this is the case.
So, unless you want ultimate and unmitigated granular control over these permissions and you have a lot of time to set them up, this last way of assigning access is recommended only when absolutely needed. It’s much, much faster to simply copy and edit a default permission set or record a process for a new permission set.
Hierarchy of Permissions
It’s important to keep in mind when assigning permissions that there are 5 hierarchical permission types:
Read – Viewing data
Insert – Create new documents or add to blank fields.
Modify – Adjust tables or in progress documents and lines.
Delete – Delete a document, line, or data field.
Execute – Ability to run something, like a report.
If a user needs permission to modify something, it’s often the case that they also need the previous levels of permission on that item (read and insert). They at least need read permissions, because if they cannot see something, they can’t modify it. Keep this in mind when you are providing permissions.
With knowledge of this standard type of permission error, an administrator is a little more equipped to understand what is happening in Business Central to cause this error and also correct it. Using the error data to directly provide permission to eliminate the single error is one, very granular way of providing and restricting permissions, but it also does take a lot of time. We recommend that these sort of direct permission grants happen only when necessary. It’s much easier to assign permissions via the other two options – recording or assigning pre-built permission sets (customized or system default).
And, if you encounter these or other errors that prove difficult to resolve for your employees, your Syvantis consultants can help!