The views and opinions expressed in this blog are those solely of the author(s) and do not necessarily reflect Microsoft’s current policy, position, or branding. For official announcements and guidance on Dynamics 365 apps and services, please visit the Microsoft Dynamics 365 Blog.
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
2020 release wave 1Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 Timeline
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
The System Administrator role reminds me of this quote from Blade Runner
“Replicants are like any other machine. They’re either a benefit or a hazard. If they’re a benefit, it’s not my problem”
I would change it to
“CRM Developers are like any other person. They are either a benefit or a hazard. If they’re a benefit, it’s not my problem”
“The System Administrator security role is not like any other security role. It’s a benefit and a hazard. When it’s a benefit it’s not the CRM Developers problem”
The System Administrator role gives CRM developer super human powers in the CRM world.
Sometimes a CRM developer will need more than the System Administrator role, if they want to deploy plugins not in a sandboxed CRM where they also need the Deployment Administrator role, which is a tricky customer, find out why in this blog Understanding and adding deployment Administrator role
The System Administrator role is different from other CRM security roles because it’s dynamic.
The System Administrator role automatically has access to all records and all system and custom entities.
One frustrating aspect of adding a new entity in CRM is automatically no security roles have access to it, until you set the privileges in the security. One security role has access to it, the System Administrator role who automatically has access to it.
What’s better is CRM does this for you automatically. If you want to read more about System Administrator role check my study notes on Business units and security roles.
The System Administrator role also has privileges on any Field level security profiles setup.
You can copy the System Administrator role by the copy will not automatically have the super powers of the System Administrator role and is a snapshot. So any new field level security profiles or entities added won’t be included in the copy.
So the System Administrator role is great for CRM developers because it means they have the rights to deploy plugins (Assuming they are deployment administrators) they can view all entities and there are not restrictions.
Here is a list
The System Administrator role is dangerous, you can delete data you aren’t meant to delete
The System Admin role is terrible for testing and is the cause of millions of CRM Developers saying
“I can’t recreate that problem in my system”
“It works ok for me?”
The first bad point is CRM Developers will usually do some integration testing using System Admin role, so if there are any security role/permission errors they completely miss them.
CRM developer will often follow up this bad practise by trying to reproduce the bug by testing with a System Administrator role and not be able to reproduce it.
We can see System Administrator role can be a problem but how can you avoid those problems.
In non Developer environments like Test, Pre prod, etc don’t give CRM developer System Administrator role. Make the CRM Developer login as another user
Make sure CRM developers test their code with another user role. If you have a Test environment make sure the default security roles for a users windows login is not a System Admin role.
Make sure testing code using a different role is an expected part of the development process. It will be a good habit for the developers to form.
Business Applications communities