Securing a menu item is not enough – form controls

In my previous blog post, I talked about missing parts on forms when you only focus on granting permissions on menu items. This is mainly the case if you start privileges and duties from scratch to ensure a least permissions principle. Form parts are a type of form control where security can be managed with other menu items. There is more to take into account next to the previously discussed form parts. There are also other form controls where you need to take care of permissions in another way. This blog post is an addition to my previous post where you will now read about additional form control permissions on privileges.

Form controls

A form design consists of many different objects. There are multiple type of controls and even you can build your own extensible controls. Some examples of form control types are tab page, field group, grid, action pane, string edit, menu item button, button. You can read about form design, patterns and different controls in the documentation: User interface development home page – Finance & Operations | Dynamics 365 | Microsoft Learn

Each individual control can be secured with permissions. The most familiar one is the menu item which can be linked to privileges and you can set your own access level. Most forms do have tables linked to data sources. All conrols on the form which are linked to a physical table field are called Bound controls. Objects like a tab page, button, group are not bound to database information and are called Unboud controls. A last grouping of controls is the Calculated controls where a method is used to display or edit data.

In this blog, I will elaborate on security permissions for unbound and calculated controls. Bound controls can be secured with table and field permissions. In a previous blog, I provided an example for table and field permissions. Security how-to: Only finance users are allowed to see cost prices in Dynamics 365 Finance and Operations.

Before jumping into the details, let’s have a look at the purchase orders details. Below, you will see two screenshots. The first one is with all permissions. The second screenshot is the result of only adding permissions to the menu item All purchase orders. Which can be found in the Accounts payable and Procurement and sourcing menus.

If you compare the screenshots, you will find multiple differences. When diving into all details, you will find even more differences as I only granted access to one menu item. Some menu options in the action bar and the related information were discussed in my previous blog: Securing a menu item is not enough – form parts.

The highlighted sections in the first screenshot are the controls which I will focus on to get them visible to the business user.

Securing unbound and calculated controls

Like mentioned above, you can secure all controls individually on a form, but it needs to be done when it really makes sense. Menu item buttons and bound controls are already part of the security. It would make sense to be able to secure button controls and other controls to segregate betweeen duties. In Visual Studio, there is a form control property (Needed Permission) which manages if a control will be visible to the end user with particular access level. The majority of controls do have the standard value which is None. This means that there is no security check to be able to view and use the form control. Other values will manage automatic visibility to the user: Read, Update, Create, Correct, and Delete. Depending on the access level granted on the menu item on the privilege, you would be able to interact with the control. E.g. when a control has the Needed Permission set to Delete and a user has only read access, then the control will not be visible.

A last option for the Needed Permission property is Manual. When this value is used, no business user will be able to see the control unless the control has been explicity added via the permissions. Note that users with the system administrator role bypasses all security. This is also valid for the Needed Permission property. Regardless of this setting they will see the control on the form.

Manage control permissions (Security configuration form)

In the example above, I highlighted some controls which are missing when I granted permission on one menu item. You can use the standard privileges or duties to bypass the issue. If you need to have a privilege from scratch, you need to add form controls to your privilege. Comparing what exactly to add with the standard would be hard if there are multiple menu items referring to the same form in a privilege. You can view all standard controls which are secured via the Needed Permission property when you dive deeper in the details of the permissions on the privilege. You can follow the flow on the next screenshot.

1. Click on the display menu item which contains the form where permissions needs to be granted on form controls.
2. Select the referenced form name.
3. Click on Controls.
4. Click Add references to open a side dialog with available form controls.
5. Select the controls which you want to add. In this case, I selected the financial dimension controls for both the purchase header and the lines.
   The width of the column is not large enough to display all data. Hovering above a line will show the complete value. In the example above, the needed permission is Manual.
6. Grant permissions for the actions which would be allowed for the user. As this example is related to field values, granting access for Read and Update is sufficient.
7. Click OK to add the controls with selected permissions.

When you made these changes, you can publish the security objects. Now in the same way, it is also possible to add the buttons related to the Intercompany section on the action bar.

Now you might have a question. How to know which controls are to be selected? Partly, you can regognize the controls by name. In case you are not sure, you can follow the next step to get the control name from the user interface. Go to the form and right-click on the control from which you need the name. It will show a pop menu with the name of the form and the selected control. This will be hard for the financial dimensions. At least these are always having a name which are clear to know which one to include.

If a control has the Needed Permission set to e.g. Update, you can override it with Deny permissions to exclude the control for the users assigned to a particular security role.

When we included the financial dimension controls and intercompany buttons, ensure you publish the security changes. The business user will now have access to these controls. Note that I didn’t include the Original sales order button. This is a menu item button. For ths reason, the next screenshot has 3 out of the original 4 buttons.

Manage control permissions (Visual Studio development)

Next to managing the permissions via the user interface, a developer would be able to include the form control permissions via development. Before showing an example how Microsoft did add the form controls on a standard privilege, I will first show an example of the Needed Permission property. If you open the form object PurchTable and navigate to the financial dimension section, one of the elements have a Manual setting for this property.

As metioned above, with this value, noone has access unless you specify it on a privilege. When opening the standard privilege Maintain purchase order details (PurchTableDetailsMaintain) in Visual Studio, there is a section on the privilge for Form Control Permissions. This section contains the form with the controls and their permissions. As a developer you can also add form controls to privileges. Note that there is no option to extend privileges. For changes, you always need to add new privileges if you are using the development approach for security.

The experience to add permissions to form controls via the user interface and development is different. On the Security configuration form, you go to the menu item and then navigate into the details. In Visual Studio, you add the permissions on the Form Control Permissions node. Note that also in Visual Studio, you can navigate into the details of the menu item and you will probably find controls with permissions added to entry points. This option is currently not working from the

There is more…

You can extend existing forms, add new controls with a setting a value for the Needed Permission property or change the Needed Permission for existing controls. If you change the property on existing elements, you can use both the configuration and development options to grant permissions. Newly added controls can only be granted access via the development approach. The new control might be visible for selection when you add references using the Security configuration form, but it is not recognized correctly and not visible to end users.

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!