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.

Solutions in Microsoft Dynamics CRM

In this post we will briefly discuss about types of solutions available in Microsoft Dynamics CRM and some important points to be remembered while working with Solutions.

There are two types of solutions in Dynamics CRM:

1. Managed Solution: It prevents the solution from being modified in the environment to which it is imported.

2. Unmanaged Solutions: It allows for the solution to be modified after it is imported.

It is recommended that users deploying normal customization changes should do so using unmanaged solutions. Managed solutions are great for ISV’s who are selling their intellectual property and don’t want it to be modified by their customers.

Challenge with using managed solution for normal customizations is that there are some level of customization changes that are required to be made even in a CRM production environment, such as view, chart, and dashboard changes. Also, maintaining a managed solution requires that you preserve an unmanaged copy of that solution somewhere, since that is the only way you can update the solution or delete components.

Removal of a Managed solution does following things:

1. Removes all custom entities and components contained within the solution i.e. entities, web resources, processes.
2. Removes all customizations to system entities contained within the solution i.e. fields, views.
3. Deletes the data that is held within these custom entities and fields.

4. Any personal views/charts/dashboards in any custom entities will be lost.


When you import a solution, custom entity object type codes value changes in the database. If you have any reports or custom development that calls records using the OTC, this may break them. It is recommend to call hyperlinks using the entity name rather than OTC. Also you may find that some processes, such as workflows, cannot be published. This can happen because they reference a record that does not exist.


We usually perform a round of validation after every import of a solution just to be sure that we have deployed everything correctly. Below are some brief components that should also be validated.

1. CRM UI comparison: Verify that all custom forms behave the way they did before by checking create, update, and saving of a record.

2. Security role assignments: Import of unmanaged version of the solution restores the security roles, but it does not links them to the appropriate users as it was in the source environment.

3. Duplicate detection rules and Audit settings: Import of a solution disables auditing and un-publish duplicate detection rules.

4. Processes.

Hope this helps!

Migrating history information while data import in Dynamics CRM

When you import historical data in Dynamics CRM, you may want to override property information like Created By, Created On, Modified By, Modified On associated to the record. It seems possible because CRM has provided security privileges called “Override Created on or Created by for records during data import”. However, simply update the appropriate Security Role to enable this privilege does not completely meet all requirements to override such fields as the name sounds.

The truth is, only “Created On” field can be overridden and only if the ‘allow creating duplicate records’ option is checked during the import process. In other words, we cannot update this field on existing records. Only creating new records does work for overriding “Created On” field.
While the Created By, Modified On, Modified By fields cannot be updated once the data is imported even though the user has full privilege on “Override Created on or Created by for records during data import”.

A workaround for such request can be to have a plugin that fires on pre-create of the entity and set the values for remaining fields problematically.



It is recommended that you do an import process by a administrative user which has a timezone set to GMT/UTC.

The reason is in 2005 (2005 revision to dates of observance) the date when Daylight Savings Time starts and ends in the US was changed. As a result, if you import the data back in for previous years as a user that is not on GMT, some of the records will be off by an hour.



  • When one have a list of related entities for which data import is required, order in which data for these entities are imported is important. In some cases, you have many relationships, and you cannot practically determine the order in which they should be imported. In this case, do a two-pass operation.
  • It is recommended to map the record ID/GUID fields when the records are imported. If you map the GUID fields, all relationships will work when imported.
  • It is recommended to map createdon to overriddencreatedon. You can only populate this when the record is created, and this is what will set the created on date for the record to match the original version.
  • There are some fields that you do not want to map, such as version number, import sequence.
  • There are several fields that you cannot import like modified by, created by, modified on.
  •  Custom data cannot be reimported for closed opportunities.

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