Permissions in AL allow users to give permission to other users based on their particular needs.
Initially your assigned license determines the permissions you can have in D365 Business Central, later on you may granted the security permission set by your system administrator. We have many standard permission sets by default in business central which we can assign to user whichever suits him also we can create different permission set with some set of permissions included in it and assign to the particular user.
Here is what we need to take into the consideration while assigning permissions from AL objects. Below are the objects which can access the Permissions property to assign permissions.
Objects to use Permissions:
- Codeunit
- Table
- Request Page
- Page
- XML Port
- Report
- Query
- Permission Set
- Permission Set Extension
Along with all objects above we have one other parameter to assign permissions is Tabledata that can have permissions to read, insert, modify and delete. Other objects can only have execute permission to run that object from environment.
One must have the proper permission to access any of these objects. If you have only been assigned read permission, you can open a page, but you cannot insert, edit, or delete any records from it.
Let us see how these permissions can be assigned with different values:
Permissions on table data can be assigned as below:
| Permission values | Represents | Description |
| R or r | Read | R for direct read access, r for indirect read access. |
| I or i | Insert | I for direct insert permission, i for indirect insert permission. |
| M or m | Modify | M for direct modify permission, m for indirect modify permission. |
| D or d | Delete | D for direct delete permission, d for indirect delete permission. |
Permissions on all objects can be assigned as below:
| Permission values | Represents | Description |
| X or x | Execute (Run) | X for direct execute permission, x for indirect execute permission. |
Mostly by default objects don’t have the permission defined. It works based on the user’s permission set, except in cases like ledger entries where direct insertion, modification, or deletion is restricted. However, you can still insert data indirectly through posting functionalities.
If we are passing indirect read permission to any tabledata you cannot run that page even, you can see that in global search. You will be facing an error as shown below:
But you can read the data by running the table or page from URL as below:
Also, if you have the permissions on tabledata read but you don’t have the execute permission of table than you will not be able to run table as above.
Full or Partial Access:
If we are assigning X for objects and RIMD for table data grants full access to that object.
Also, you can assign permissions as partially as RID, rimD or any kind of grouping of permissions
NOTE: Users with super permission can access all objects and fully control them, reading, inserting, modifying, deleting, or executing anything, even without specific assigned permissions.
Wildcard:
With the help of wildcard, we can assign a same permission to all objects of that type as shown below:
This will assign direct execute permissions to all the codeunits available in the current extension. We must use this functionality very cautiously because it may affect the security of objects as it is giving permission to user for all the codeunit objects from that extension.
This is how permissions work, determining whether a user can access data and objects directly or indirectly, based on their assigned roles and permission sets.
If you’re curious about how we can assist you in reaching your goals, don’t hesitate to get in touch. Our dedicated team is ready to provide support every step of the way.
Let’s turn your vision into reality together!
