Dynamics 365 Business Central: access modifiers

If someone of you know C# or other object oriented languages in general, you know also that those languages have access modifiers. Access modifiers are keywords used to specify the declared accessibility of a member or a type.

As showed by Microsoft on their Twitter account, with Dynamics 365 Business Central Wave 2 release, this feature will appear also on the AL language.

A table object can have an Access level with the following values:

  • Public (default): The object can be accessed by any other code in the same module and in other modules that references it.
  • Internal: The object can be accessed only by code in the same module, but not from another module.

The access modifier can be specified by setting the Access property to one of the above values.


Regarding fields, you can now declare that a field in a table or a tableextension object has an Access level with the following values:

  • Public (default value): The field can be accessed by any other code in the same extension or another extension that references it.
  • Internal: The field can be accessed only by code in the same extension , but not from another extension .
  • Local: The field can only be accessed by code in the same table/tableextension where the field is defined.
  • Protected: The field can be accessed only by code in the same table or tableextensions to that table.

As an example, here I’ve defined a table with a field with Access = Internal (visible only from the code inside my extension):


If you try to access this field from another extension, Visual Studio Code gives you an error immediately.

The same occours if you change the field access for example to Local (visible only inside the object that defines this field):


Now, if inside your extension you have a code that references this field, you’ll receive an error:


As said before, Access property can be set also in a tableextension’s field:


Nice thing, useful for example to avoid third parties that uses your extension to use reserved fields or tables (that you can now set as Access = Internal).

What about codeunits?

You can specify the Access property to a codeunit too (same values as for the table object):


UPDATE: also for procedures there is the Access modifier property as follows (this is a function declared as Internal):


  1. Hi Stefano,
    Thank you for the information to give us about NAV and BC.
    I have a question about the topic:
    How can we protect our table to being modified by another extension by using recordref or fieldref? Is it possible to prevent it? We have a NavApp.GetCallerModuleInfo() method for on-prem to detecting the caller app but there is nothing for SaaS.


    1. What do you mean with “being modified”? If you mean data, you should use permissions. If you mean structure, a table cannot be altered but can only be extended by another extensions. Another app can extend a table if it’s dependent from the app where the table is declared. Maybe can you better explain your needs?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.