Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
There are two things that developers in AL do not like to do. Reports – I know very few people who like it, and Permissions. Although in my case I should say I do not like only one thing since permissions I just HATE.
In the next two weeks, we plan to release a new extension on AppSource (stay tuned) and we need to do permissions – as always. I sat with one of our developers and we decided “let’s do it in a new way”.
In version 18 (released April 2021) you can do permission in two ways – old and new. For those who try not to do permissions sets in AL so often, here is a small reminder: in the old way you needed to create an XML document where you did not see what the object name is or even type if you do not remember C/SIDE. And this XML document was very, very (and very very) long. In my case, it has (and I have more than one) over 4000 lines.
In a new way, the permissions are defined as objects similar to enums, profiles, and all others. So why it is so good?
First of all, when creating permission you can see what are objects are included and what permission right away.
Moreover, you can extend other permission sets. So, imagine a situation that you have a new extension and you do not want to create a new permission set for your users but only extend an existing one. You do not need to send users information to assign new permission – they will get it automatically.
You can obsolete also permission and see which one will be obsolete from the standard permission set.
When we created permission in a new way my colleague called me and said this is great, I can now group the permissions in one set – but what he did he just group them in one object. After few minutes we both realized that there is a much better way to do it and instead of one permission set now we have… more than twenty.
Don’t worry it does not mean that the user needs to have assigned all twenty permissions. It even does not mean the administrator sees those twenty permissions. He still will see only one. But for us who the same permission can be in two different roles is a great way to do the job only once.
To achieve so you need to know two parameters – the first one says if permission set can be assigned to users – Assignable. And the second that says which permission sets are included in the permission set – IncludedPermissionSets.
The result is that in Business Central there is only one permission set visible which contains all permissions from my multiple objects. This way you do not need to multiple the same permission if they are needed in multiple roles.
We have been a little struggle to get it working at first so here are few tips:
This time it will be short. The developer who was working on it told me: I never want to go back to XML permissions. And I think this is the best conclusion ever.
Business Applications communities