Licensing Advent Calendar – Day 16 – Correct and Invoke permissions

In the past days, I wrote several times about the difference between Read and Write license access levels for the entitled and not entitled securable objects. In this post, I will elaborate on deprecated access types still responsible for Write access: Correct and Invoke.

Permissions

On day 11 of the Licensing Advent Calendar, I wrote about the Security architecture where I mentioned the available access levels and type of permissions.

Most commonly, we know about Create, Read, Update, and Delete, which is also shortened as CRUD. Obviously, there are access levels that can be granted via permissions on menu items referenced on privileges.

There are two other permission types that were deprecated in Dynamics 365, but used in Dynamics AX 2012: Correct and Invoke. While the security logic has been deprecated, the permissions types are still there and taken into account when determining the difference between Read and Write. When only read access is granted, then the outcome is read. In case Create, Update, or Delete is used, the outcome of the license access level is Write. But also Correct and Invoke are raising the access level, despite not being relevant in the current version anymore.

Before talking about recent updates, let’s first have an understanding of what the deprecated access types were meant to control.

Correct

In Dynamics AX 2012, the concept of date-effective tables was introduced. It was an option to have start and end-date/time fields where no gaps were allowed between sequential records. In particular cases, when you have incorrect data, there is a need to remove a record that may be between dates or correct a start or end date. For this type of change, the Correct access type was introduced. In Dynamics 365, users can make changes to supported forms. In case programming logic is executed to change date effective dates on records, it will be executed without this access type. For that reason, it is considered to be an obsolete access type in Dynamics 365.

Invoke

In Microsoft Dynamics AX 2012, the invoke access type was a security permission that allowed users to execute code within an object. It was validating if methods from classes called by menu items, or service operations, were allowed to be executed. The validation for being able to execute business logic was simplified in Dynamics 365, assuming that if someone has access to, e.g., an action menu item to post an invoice, or has access to service operations, that programming logic is always executed unchecked. This is because the entry point is secured with specific access permissions. Like the correct access type, the invoke permission is not relevant anymore in Dynamics 365.

July 2025

Earlier this year, there were reports that when security was changed from write to read by changing permissions, the objects were still reported with a write access level. This was caused by either the correct or invoke access types still having grant access in the background. These access levels were visible via the View permissions form, but using the Security configuration form, there was no option to manage the access level. At that time, I had a flashback to a blog I wrote at the beginning of 2024: Help! My configured read-only role requires an operations or activity license. Usually, blogs get outdated, but in this case, it was an actual topic, and the blog was relevant to solve the license access levels.

In July 2025, I mentioned the issue and workaround in my blog Dynamics 365 F&O license enforcement status – July 2025

Current version

As I mentioned above, usually blogs get outdated, so also the blog with the workaround to solve the access levels. When you copy a standard privilege and try to lower a license level to change the access level from write to read, you still may encounter grant permissions set for Correct, Invoke, or both. According to the blog shared above, there was no option to manage the Correct and Update permissions directly via the user interface; this is now supported in the latest quality updates for all the supported Dynamics 365 F&O versions.

Instead of removing and re-adding the menu items, you can now simply do a multi-select on the references and then set not only the CRUD actions, but also manage the permissions for the Correct and Invoke access types.

This speeds up the work to be done at clients, bringing back the license access levels from write to read. In my opinion, this could be solved in a different way. As these access types aren’t used anymore, why not change the logic that determines the read or write access level and fully remove the obsolete access types from the application and also from the development environment? I think it is confusing to provide details to security administrators that are obsolete in the application.

There is more…

During the Advent period, each day in December, I will share some thoughts and tips related to the Dynamics 365 user license enforcement. If you have questions about this topic, feel free to contact me via LinkedIn, the comments section below, or the contact form on this blog. I will then either update one of the planned blogs for the coming 24 days or answer questions in a new post.

Dynamics 365 Licensing Enforcement Advent Calendar

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!