System Administrator VS System Customizer

Title sounds very basic right? But after working for 3 years on CRM platform this was it that I had missed. But as it is never too late to learn anything here is what I searched and added in a consolidate list. It may not be that helpful for someone who is working from long on CRM but may be for someone who is new to it. J

Traditional definition of these two roles say:

System Administrator

System Administrator is the highest level role which encompasses all the privileges and has over-riding rights. The System Administrator has the authority to allow and remove access of other users and define the extent of their rights. For example, the System Administrator and the System Customizer are given access to custom entities by default while all other users need to be given access. This is the only role that cannot be edited.

System Customizer

The System Customizer role is similar to the System Administrator role which enables non-system administrators to customize Microsoft Dynamics CRM. A Customizer is a user who customizes entities, attributes and relationships.

Ok, so do that mean that the only difference between System Administrator and System Customizer is that System Customizer enables User non-system administrator to customize CRM? No there is more.

System Administrator has Organization level access to all system (Out Of Box) entities while System Customizer has only User level access to all system entities. While both System Administrator and System Customizer have Organization level access to all custom entities.

 

The next important difference is that User with System Administrator role can customize System Customizer security role but no user can customize System Administrator security role.

To conclude in tabular format:

System Administrator

System Customizer

Organization level access to all system (Out Of Box) entities User level access to all system entities
Cannot Customize Can be customize
No restriction on any entity Restricted access (Create/Delete) to Plugin assembly, SDK Message Processing Steps, Service endpoints, Web resource, System Job, Calendar, Business Closer, Business Unit, Currency, Security Role, Team, User Impersonation, Override Created On, Enable/Disable User, Audit Partition, Bulk Delete

 

Do you have your version of the difference? Please share in comments below.

Advertisements

CRM 2013: Access Teams

In Microsoft Dynamics CRM 2011, the Team concept that was used is now known as Owner Teams in Microsoft Dynamics CRM 2013. The new version of CRM also introduces a new team type called Access Teams. Two fundamental differences between an Owner Team and an Access Team involve ownership and sharing. As the name implies, a member of an Owner Team inherits permissions to the records because the team owns the record. Access Teams are different in that permissions are granted to the records via sharing.

Now that there are two team types, when should you use one over the other? Since owner teams are a known concept with the two previous releases of CRM, only the best practice of when to use them will be defined in comparison to access teams.

Owner Teams

  • Best where teams access high volumes of data, via ownership or business unit access
  • When a security role is required to access records scoped by a business need
  • Teams used as service scheduling resource must be owner teams

Access Teams

  • Rapidly changing team memberships
  • Allows for >1,000 team memberships per user
  • Individual record based access
  • Owner of the record allowed to define access to other users
  • Can accommodate varying levels of group access types to records

http://www.microsoft.com/en-in/download/details.aspx?id=41190

http://blogs.msdn.com/b/crm/archive/2013/10/15/collaborate-with-new-access-teams.aspx

https://community.dynamics.com/crm/b/crmcustomereffective/archive/2014/02/08/microsoft-dynamics-crm-owner-teams-vs-access-teams.aspx