Dynamics 365 Business Central comes with many predefined permission sets, and they are classified as SYSTEM permission sets. You may have created modified copies of these System permission sets. When your Business Central environment receives an upgrade (either major or minor), there is a possibility that the SYSTEM permission sets will be modified in some way. For example, new permissions are added or removed from these system permission sets.
An issue arises when you have custom copied permission sets, as Microsoft will not automatically modify these when an update occurs. So, if your users are assigned these ‘copied’ versions of system permission sets, they may encounter errors when doing certain functionality in the system. This blog will go over best practices to help mitigate permission errors you may receive after an upgrade occurs for your Business Central environment.
To clarify, these best practices below only apply to permission sets created by copying a SYSTEM permission set – specifically those created via the ‘Copy Permission Set’ button below. Below is an example where we make a copy of the D365 BUS PREMIUM permission set.
On the window that appears, make sure to have this setting below turned on – Notify on Changed Permission Set:
When your Business Central environment receives an upgrade, we recommend that right after that (i.e., the next day), you go to the ‘Permission Sets’ page below. If you have any copied permission sets where its original SYSTEM permission set has changed in any way, you will get the notification below:
And as a side note, to see this notification, you will need to have the following notification enabled in your list of My Notifications. By default, it is Enabled:
Back to the notification you receive – when you press ‘Show more’ on the notification, you will get the page below where it will show the SYSTEM permission sets that have changed after the upgrade.
That is where this functionality ends. It will not say exactly what changed. The recommended next steps would be to export all the tables/code units that are part of the System Permission Set and the Copied Permission Set (i.e., D365 BUS PREMIUM and TEST in my example). Then compare the two to see what needs to be changed on the Copied Permission Set. Most likely, there is a new table that Microsoft has added to the System permission, which signals that you need to add that new table to the Copied Permission Set.
A good best practice to be even more proactive with these permission changes is to schedule your sandbox update sooner than your production environment. When your sandbox receives the upgrade, you can go through the exercise above to identify what changes need to be made to your Copied Permission Sets. Then have your end users ensure the sandbox works as intended with no permission errors. This will help better prepare you for what needs to be done to the Production environment once it eventually upgrades later.
For reference, you would modify scheduled update dates within the Admin Center below: