"Let's start from the Sales Manager security role and copy it to build our custom role". The classic way for a Dynamics CRM consultant to configure security settings for #PowerApps. I know I've followed this path countless times. The neat thing about CRM/XRM/CDS/Dataverse security settings is that Microsoft has never provided detailed information to us on what each of those rows in the security role configuration screen relates to. So, we've learned to start from something that works & adjust the rights from there to the customer specific need. Today I was reminded that we shouldn't consider Power Apps to be "a sales CRM that we just customize". A platform feature that you'd expect to be available OoB for all users like Environment Variables was blocked from the Sales Manager, causing my custom logic to fail. Out of curiosity, I launched #XrmToolBox and opened the Role Comparator tool. This allows me to visually compare the Sales Manager OoB role to the Basic User role. There are also other platform level privileges missing, such as Settings Definition / Organization Settings. Microsoft does provide a minimum privileges security role that we can download as a solution from Docs. The guidance has been that you should start from it and create a copy to build a custom security role. Well, it also seems to be missing a lot of useful core things that the Basic User role does include. Should we then copy the Basic User role instead? Well, we're going to run into the same issue sooner or later with any custom security roles: they are not updated while MS extends the platform. Features that are not visible to app end users may have dependencies to new boxes to be ticked in the security role settings. I guess the "right" way would be to always assign both Basic User and your custom security role to any user. One controls the platform level features and is owned by Microsoft. The other role is controlled by you as you build app features on top of the platform. What are your thoughts on #PowerPlatform security role configuration best practices in the year 2022?
Andrew Bibby
1y
Basic User gives way more privileges than required on many Power Platform projects. The creation of security roles for PP apps needs a wholesale rethink. Good post highlighting the issues Jukka
Thomas Unzeitig
5mo
Well I usually start with a copy of the systemadmin role. Remove everything and then I apply the necessary rights. There are so many things in security roles, which cannot be adjusted in the UI. Why I start with the systemadmin role - I dont know - I have the feeling it comes out of the box with everything, where I cannot be sure with the other roles.
Juan Simon
1y
Yes, it needs an update and it still is complex for most users. The problem with first-party apps is when you license a user it automatically assigns a ‘base’ access that is sticky, than it might show stuff you want to hide. You can remove that access but if you refresh the user it brings it back again!
Test & Verify. That part of the project never went away, no matter the renames or branding. I have been in Dynamics CRM since "v4" & "2011"
It’s certainly easier to build a least privileges concept when starting from ground than when being tasked for backwards compatibility with least impact on anything existing.
Simon Hetzel
1y
I've also faced this issue a while back. I don't remember licence to role mapping being available in PPAC at the time and we ended up getting MS Support to turn the automatic role assignment off. We used roles assigned to AAD Group Teams to fulfil a similar function. Personally I'd like to see MS implement a "based on" for custom security roles so that we can easily say "like this OotB role but with these extras privs and (importantly) **without** those". (And then for it to then update automatically when MS change the base role).
Agree with your comments, Jukka, I faced this issue a few weeks back. I went on creating as you did and users can't access the apps and figured out that we need to provide read privileges for Model Driven Apps Table, and a few other issues. As Andrew said, if we don't want to use the Basic User role (grants more than required), this "min priv role" gives a good base for us to start setting up the base role or use it in combination. Link to download from MS learn site https://learn.microsoft.com/en-us/power-platform/admin/database-security#minimum-privileges-to-run-an-app
Excellent way of explaining the lack of detailed microsoft documentation on roles. I agree with you in that using the Basic User role as a start point will eventually miss some important permission, and unfortunately we dont have all the time in the world to “play” and figure it out, most of the time we are time constraint and end up giving more permission than what is really needed. Then when trying to tweak and fix the role with only the permissions needed, the users liked a featured that it will go away after the tweak. I’m so glad we have internet and everything in it so we can figure things out and share it.
Ben Thompson
1y
This has been the case for years - security roles are a fragment in time reflecting the functionality available at the moment they were created / last updated I think the issue comes down to the fact many of us come from the on premise world where best practice was give everyone a customised security role because the system slows down if anyone has more than 1 or 2 security roles. Of course - in those days another advantage was once the system was installed things weren't likely to change for years. Nowadays new functionality and other changes arrives every week. So I suspect best practice now looks like Basic User Role - MS controlled (but as Andrew points out still has too much control)... Sales Manager / custom role(s) - appropriate security role for the App the user has access to (that may be multiple roles if a user accesses multiple Apps) Non standard items - explicit roles say for those allowed to export to excel or do something equally non standard
The Original Power Platform Advisor. 11x Microsoft MVP. Low-code 4 life.
1yIn January 2023 there has now been a new feature added to the release plan related to these standard security roles: "Secure environment maker and basic user security roles by making them non-customizable." https://experience.dynamics.com/releaseplans/?app=Microsoft+Dataverse&status=new&planID=d2365b11-b0a6-ed11-aad0-002248244c88 At least it will clarify the intention behind such roles, meaning that you should never edit the Basic User role that Microsoft owns and maintains.