In a way to circumvent the (sometimes) monthly problems of updated permission(sets) by Microsoft, and the impact of it to custom permissionsets, where many of them were copied and changed (mostly removed some of the permissions), I can't stop thinking about one (simple?) feature that might be a complete solution to it all.

If we could define "deny permissions", we can basically set up anything, and circumvent any upgrade situation. Just imagine I was able to create a permissionset, with a deny on the insert, modify,delete of an entity. That way, I can simply use the default permissions, and change it to a read-only for customers in any case, and still facilitate any upgrade, as an update to a default permission sets, will facilitate the new tables, and still deny one ones that I set up in my custom permission set.

Some other scenarios:
- we could simply set up permissionsets with a table0 and then some deny-permissions of the few ones I don't want users to access. This would be much simpler (and more readable) than adding +700 tables to a permissionset.
- If we could apply this "deny" specifically to a read/insert/modify/delete, we could even CHANGE permissionsets, by simply deny a Read and/or Modify and/or Delete and/or Insert .. and of course still facilitate the upgrade.

Just to put in perspective why I think this is necessary: users haven't been able to log into Business Central after an upgrade ...