Overview

As a Dynamics 365 developer/consultant, your goal must be to build a robust solution that is easy to maintain, upgrade, and extend. Effective development standards and practices promote code consistency and help avoid errors, bugs, and performance issues.

This is a series of blogs introducing the Development Standards and Best Practices to help configure and customize CRM to do so consistently, clearly, and meaningfully.

1. Configuration in Dynamics CRM

1.1 Publisher

Introduction

In Dynamics 365, a solution Publisher is used to identify its creator and uniquely identify the customizations done by individuals from the OOB(out-of-box) default publisher that comes from the product.

Every app and other solution component such as entities you create or any customization you make is part of a solution.

Best Practices         

1. You should create your own publisher rather than use the default. You specify the publisher when you create a solution.

Even if you don’t use a custom solution, you’ll be working with solutions that are known as the CDS Default Solution.

2. The solution publisher specifies who developed the app. For this reason, you should create a meaningful solution publisher name.
3. Specify the publisher prefix. The publisher prefix is a mechanism to help avoid naming collisions.

Not recommended

1. Avoid using a long prefix name. The prefix will become part of attribute names that will be referenced in Plugin/JS and other customizations.
2. Avoid staring or containing OOB keywords.

For example, mscrm/Microsoft/CDS/Dynamics

See also

1.2 Solutions

Introduction

              Solutions are the mechanism for implementing ALM(Application-Lifecycle-management) in Dynamics CRM. A solution is either managed or unmanaged.

Best Practices

1. Use Pascal Case in the name field, and use a meaningful name when creating a display name for the solution.

For example:  {YourProjectName}.{Configuration}

2. Unmanaged Solutions are used in the development environments while you make changes to your application.
3. Managed solutions are used to deploy to any environment that isn’t a development environment for that solution. This includes test, UAT, SIT, and production environments.
4. It is advisable to avoid dependencies of solution components with other managed solutions.
5. To achieve this, you can categorize the solutions into 4 solutions, based on their component types.

• Configuration
• Customization
• SecurityRoles
• Apps

The following table is the Solution and Component Type mapping rule.

Not Recommended

1. Don’t use the name “Solution” in your solution name. Since you are creating a solution, it’s redundant and provides no added value.
2. Don't place the same component in multiple solutions, in case of interdependence.

1.3 Entity

Introduction

• The entities are used to model and manage business data in Dynamics 365 CRM. For example, entities such as Account, Campaign, and Incident(Case) can be used to track and support sales, marketing, and service activities.
• An entity has a set of attributes and each attribute represents a data item of a particular type. For example, the account entity has Name, Address, and OwnerId attributes.
• Conceptually, an entity is like a database table, and the entity attributes correspond to the table columns.
• Creating an entity record in CRM is like adding a row in a database table.

Best Practices

1. Use lowercase in the Name field. When you enter a Display Name of “Test Entity Name” into CRM, it will automatically generate a Name of prefix_ testentityname.
2. It’s important to select the correct Entity Ownership type when creating, as it can’t be changed after creation.

The following table presents a comparison between the two ownership types.

Not Recommended

1. Do not select the following check box by default during creation. It can be selected later if needed, but once selected it cannot be unchecked.

More topics

Dynamics 365 CRM Development Standards - Configuration 2