Is a privilege the only check for granting access to forms?

Usually, when you add a menu item to a privilege and set the correct permissions, the user will be able to open the form linked to the menu item. However, it is not a guarantee that you would be able to open the form as there is another prerequisite in the security framework in Dynamics 365 Finance and Operations. In this post, I will elaborate on the additional requirement and provide some thoughts using an example.

I will begin my story with the navigation in the application; the main menu. That contains all the options available for users to open pages, start reports or periodic tasks. Most business users of the Dynamics 365 Finance an Operations application will use the regular main menu, favorites, or open a page from the recent list. In the Search bar, you can also search for a page and choose what to open from a list with results. Depending on the granted security permissions, the users will see only a subset of menu items which are relevant for their duties to be able to perform their work.

Some users and system administrators are aware of how to use the URL parameters to open pages directly. If you have access to e.g. the All customers list page, you can change the URL yourself to open the form by specifying the technical menu item name as one of the parameters. Example: https://[your environment] This will open the All customers list page in the company USMF. You can find more information about URL Parameters And Values in a blog written by Volker Deuss.

A form quite often used to open via the URL manipulation is the Table browser which is accessible as System administrator. This needs an additional parameter to let the application know which table should be presented with their fields. The URL https://[your environment], will open the table browser and shows all records from the UserInfo table. Now with this Table browser as example, I will guide you what additional check is performed by Microsoft Dynamics when opening forms.

Access validations

The first check done by the application is a validation if the user has access to a particular form via the security role assignments. When you try to open the table browser as a normal business user without system administrator rights, you will get the next error.

Does this mean that the form is only available for system administrators? The answer is: “No!”. The system administrator role is bypassing all security. For that reason, you should be careful and prevent assigning this role to any user. The Table browser is a form like any other which has a menu item in the application and you can grant permissions via privileges. When a system administrator will go to Options > Security diagnostics, he will see that a role, duty and privilege already exists in the standard application.

So, in theory, a user with the role Information technology manager or another role where the duty or privilege is attached should give permissions to this form. The first attempt will result in again an error, but now the error is different.

The error now is not that you don’t have the required permissionns, but you are not able to navigate directly to this Table browser form. The root cause is due to the second validation when starting objects linked to menu-items. To be able to use a menu item in URL parameters, the form should be part of the main menu. As a business user, you are able to open the All customers page by editing the URL, but if you try to open the form Customer transactions (menu item CustTrans) via the URL, you will also get this error in the standard appliction. The customer transactions is accessible via the All customers or customer details form and not directly via the main menu. A user with the System administrator role assigned is bypassing all security, so also this check is not executed and the person can open any form via URL manipulation regardless of it is direct accessible via the main menu or if it is a menu item button on forms. Some forms opened from a main form do require to have some arguments which should be sent by the caller form. If e.g. an active record is missing, you will get a runtime error. When a system administrator will search for a page in the top search bar, like all other users, he will only get results of menu items linked to the main menu.


With the knowledge shared above, there is one solution if forms should be opened which are not directly linked to the main menu. The solution would be go to the development environment in Visual Studio and extend a menu by adding the menu item. In most cases, this would be anyway the preferred solution as users will then also be able to use the main menu or search option to open the page. Remembering the technical name of the menu item for URL manipulation is not appreciated by most business users. In the next screenshot you will see my demonstration to add the table browser to the main menu via the Inquiries section on the System administration menu.

When this customization is deployed, the users having access to the table browser (via security settings) can, like the system administrator, look at the table contents of any table. Note that this is not restricted to tables used on the forms and reports which is part of the assigned security roles. I used the table browser as an example to demonstrate the additional check, part of the security framework. If a user should not have the option to see data from all tables, e.g. when tables contain sensitive data or due to GDPR procedures, you should not follow the steps in this blog to give access to the table browser form.

There is more…

By implementing a customization, like above, the user will be able to click on the menu item to open a form.

In this scenario, the form requires an additional parameter for the table name which is only used by this form and should be provided manually by the user. If the user starts the Table browser from the menu directly, there is no table parameter provided and the person will get an error. The URL should contain a parameter for the table name to be able to open the Table browser form. Having the menu item for this particular form doen’t really make sense.

In this specific scenario, but also one scenario we recently had at my work, having the menu item included on the main menu was not the ideal solution. In this case, we would really insist to not have the menu item part of the menu choices for the user. Also for this exception there is a solution available. You can include the menu item on a specific menu, but set the property Visible to No.

In that case, it meets the requirement to be part of the main menu but is not visible for the user. The user will be able to open the form via managing the URL parameters like mentioned above.

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.

That’s all for now. Till next time!

1 reply
  1. Fade
    Fade says:

    This write up is really good as it has opened up another level of knowledge for me as AX/D365FO support analyst. It is something I would like to try in my current D365FO implementation.
    Thank you Andre.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

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