In this article by Nicolae Tarla, author of the book Dynamics CRM Application Structure, we looked at the basic structure of Dynamics CRM, the modules comprising the application, and what each of these modules contain. Now, we’ll delve deeper into the application and take a look at how we can customize it.
In this chapter, we will take a look at the following topics:
- Solutions and publishers
- Entity elements
- Entity types
- Extending entities
- Entity forms, quick view, and quick create forms
- Entity views and charts
- Entity relationships
- Messages
- Business rules
We’ll be taking a look at how to work with each of the elements comprising the sales, service, and marketing modules. We will go through the customization options and see how we can extend the system to fit new business requirements.
(For more resources related to this topic, see here.)
Solutions
When we are talking about customizations for Microsoft Dynamics CRM, one of the most important concepts is the solution. The solution is a container of all the configurations and customizations. This packaging method allows customizers to track customizations, export and reimport them into other environments, as well as group specific sets of customizations by functionality or project cycle. Managing solutions is an aspect that should not be taken lightly, as down the road, a properly designed solution packaging model can help a lot, or an incorrect one can create difficulties.
Using solutions is a best practice. While you can implement customizations without using solutions, these customizations will be merged into the base solutions and “you will not be able to export the customizations separately from the core elements of the platform.
For a comprehensive description of solutions, you can refer to the MSDN documentation available at http://msdn.microsoft.com/en-gb/library/gg334576.aspx#BKMK_UnmanagedandManagedSolutions.
Types of solutions
Within the context of Dynamics CRM, there are two types of solutions that you will commonly use while implementing customizations:
- Unmanaged solutions
- Managed solutions
Each one of these solution types has its own strengths and properties and are recommended to be used in various circumstances.
In order to create and manage solutions as well as perform system customizations, the user account must be configured as a system customizer or system administrator.
Unmanaged solutions
An unmanaged solution is the default state of a newly created solution. A solution is unmanaged for the period of time while customization work is being performed in the context of the solution. You cannot customize a managed solution. An unmanaged solution can be converted to a managed solution by exporting it as managed. When the work is completed and the unmanaged solution is ready to be distributed, it is recommended that you package it as a managed solution for distribution. A managed solution, if configured as such, prevents further customizations to the solution elements. For this reason, solution vendors package their solutions as managed.
In an unmanaged solution, the system customizer can perform various tasks, “which include:
- Adding and removing components
- Deleting components that allow deletion
- Exporting and importing the solution as an unmanaged solution
- Exporting the solution as a managed solution
Changes made to the components in an unmanaged solution are also applied to all the unmanaged solutions that include these components. This means that all changes from all unmanaged solutions are also applied to the default solution.
Deleting an unmanaged solution results in the removal of the container alone, “while the unmanaged components of the solution remain in the system.
Deleting a component in an unmanaged solution results in the deletion of this component from the system. In order to remove a component from an unmanaged solution, the component should be removed from the solution, not deleted.
Managed solutions
Once work is completed in an unmanaged solution and the solution is ready to be distributed, it can be exported as a managed solution. Packaging a solution as a managed solution presents the following advantages:
- Solution components cannot be added or removed from a managed solution
- A managed solution cannot be exported from the environment it was deployed in
- Deleting a managed solution results in the uninstallation of all the component customizations included with the solution. It also results “in the loss of data associated with the components being deleted.
A managed solution cannot be installed in the same organization that contains the unmanaged solution which was used to create it.
Within a managed solution, certain components can be configured to allow further customization. Through this mechanism, the managed solution provider can enable future customizations that modify aspects of the solution provided.
The guidance provided by Microsoft when working with various solution types states that a solution should be used in an unmanaged state between development and test environments, and it should be exported as a managed solution when it is ready to be deployed to a production environment.
Solution properties
Besides the solution type, each solution contains a solution publisher. This is a set of properties that allow the solution creators to communicate different information to the solution’s users, including ways to contact the publisher for additional support. The solution publisher record will be created in all the organizations where the solution is being deployed.
The solution publisher record is also important when releasing an update to an existing solution. Based on this common record and the solution properties, an update solution can be released and deployed on top of an existing solution.
Using a published solution also allows us to define a custom prefix for all new custom fields created in the context of the solution. The default format for new custom field names is a new field name. Using a custom publisher, we can change “the “new” prefix to a custom prefix specific to our solution.
Solution layering
When multiple solutions are deployed in an organization, there are two methods by which the system defines the order in which changes take precedence. These methods are merge and top wins. The user interface elements are merged by default. As such, elements such as the default forms, ribbons, command bars, and site map are merged, and all base elements and new custom elements are rendered.
For all other solution components, the top wins approach is taken, where the last solution that makes a customization takes precedence. The top wins approach is also taken into consideration when a subset of customizations is being applied on top of a previously applied customization.
The system checks the integrity of all solution exports, imports, and other operations. As such, when exporting a solution, if dependent entities are not included, a warning is presented. The customizer has the option to ignore this warning.
When importing a solution, if the dependent entities are missing, the import is halted and it fails. Also, deleting a component from a solution is prevented if dependent entities require it to be present.
The default solution
Dynamics CRM allows you to customize the system without taking advantage of solutions. By default, the system comes with a solution. This is an unmanaged solution, and all system customizations are applied to it by default.
The default solution includes all the default components and customizations defined within Microsoft Dynamics CRM. This solution defines the default application behavior. Most of the components in this solution can be further customized. “This solution includes all the out-of-the-box customizations. Also, customizations applied through unmanaged solutions are being merged into the default solution.
Entity elements
Within a solution, we work with various entities. In Dynamics CRM, there are three main entity types:
- System entities
- Business entities
- Custom entities
Each entity is composed of various attributes, while each attribute is defined as a value with a specific data type. We can consider an entity to be a data table. Each “row represents and entity record, while each column represents an entity attribute. As with any table, each attribute has specific properties that define its data type.
The system entities in Dynamics CRM are used internally by the application and “are not customizable. Also, they cannot be deleted.
As a system customizer or developer, we will work mainly with business management entities and custom entities. Business management entities are the default entities that come with the application. Some are customizable and can “be extended as required. Custom entities are all net new entities that are created “as part of our system customizations.
The aspects related to customizing an entity include renaming the entity; modifying, adding, or removing entity attributes; or changing various settings and properties. Let’s take a look at all these in detail.
Renaming an entity
One of the ways to customize an entity is by renaming it. In the general properties “of the entity, the field’s display name allows us to change the name of an entity. “The plural name can also be updated accordingly.
When renaming an entity, make sure that all the references and messages are updated to reflect the new entity name. Views, charts, messages, business rules, hierarchy settings, and even certain fields can reference the original name, and they should be updated to reflect the new name assigned to the entity.
The display name of an entity can be modified for the default value. This is a very common customization. In many instances, we need to modify the default entity name to match the business for which we are customizing the system. For instance, many customers use the term organization instead of account. This is a very easy customization achieved by updating the Display Name and Plural Name fields. While implementing this change, make sure that you also update the entity messages, as a lot of them use the original name of the entity by default.
You can change a message value by double-clicking on the message and entering the new message into the Custom Display String field.
Changing entity settings and properties
When creating and managing entities in Dynamics CRM, there are generic “entity settings that we have to pay attention to. We can easily get to these settings and properties by navigating to Components | Entities within a solution and selecting an entity from the list. We will get an account entity screen similar to “the following screenshot:
The settings are structured in two main tabs, with various categories on each tab. We will take a look at each set of settings and properties individually in the next sections.
Entity definition
This area of the General tab groups together general properties and settings related to entity naming properties, ownership, and descriptions. Once an entity is created, the Name value remains fixed and cannot be modified. If the internal Name field needs to be changed, a new entity with the new Name field must be created.
Areas that display this entity
This section sets the visibility of this entity. An entity can be made available in only one module or more standard modules of the application. The account is a good example as it is present in all the three areas of the application.
Options for entity
The Options for Entity section contains a subset of sections with various settings “and properties to configure the main properties of the entity, such as whether the entity can be customized by adding business process flows, notes and activities, “and auditing as well as other settings.
Pay close attention to the settings marked with a plus, as once these settings are enabled, they cannot be disabled. If you are not sure whether you need these features, disable them.
The Process section allows you to enable the entity for Business Process Flows. When enabling an entity for Business Process Flows, specific fields to support this functionality are created. For this reason, once an entity is enabled for Business Process Flows, it cannot be disabled at a later time.
In the communication and collaboration area, we can enable the use of notes, related activities, and connections as well as enable sending of e-mails and queues on the entity. Enabling these configurations creates the required fields and relationships in the system, and you cannot disable them later. In addition, you can enable the entity for mail merge for use with access teams and also for document management. Enabling an entity for document management allows you to store documents related to the records of this type in SharePoint if the organization is configured to integrate with SharePoint.
The data services section allows you to enable the quick create forms for this entity’s records as well as to enable or disable duplicate detection and auditing.
When you are enabling auditing, auditing must also be enabled at the organization level. Auditing is a two-step process.
The next subsections deal with Outlook and mobile access. Here, we can define whether the entity can be accessed from various mobile devices as well as Outlook and whether the access is read-only or read/write on tablets.
The last section allows us to define a custom help section for a specific entity. “Custom help must be enabled at the organization level first.
Primary field settings
The Primary Field settings tab contains the configuration properties for the entity’s primary field. Each entity in the Dynamics CRM platform is defined by a primary field. This field can only be a text field, and the size can be customized as needed. The display name can be adjusted as needed. Also, the requirement level can be selected from one of the three values: optional, business-recommended, or business-required. When it is marked as business-required, the system will require users to enter a value if they are creating or making changes to an entity record form.
The primary fields are also presented for customization in the entity field’s listing.
Business versus custom entities
As mentioned previously, there are two types of customizable entities in Dynamics CRM. They are business entities and custom entities. Business entities are customizable entities that are created by Microsoft and come as part of the default solution package. They are part of the three modules: sales, service, and marketing. Custom entities are all the new entities that are being created as part of the customization and platform extending process.
Business entities
Business entities are part of the default customization provided with the application by Microsoft. They are either grouped into one of the three modules of functionality or are spread across all three. For example, the account and contact entities are present in all the modules, while the case entity belongs to the service module. “Some other business entities are opportunity, lead, marketing list, and so on.
Most of the properties of business entities are customizable in Dynamics CRM. However, there are certain items that are not customizable across these entities. These are, in general, the same type of customizations that are not changeable “when creating a custom entity. For example, the entity internal name (the schema name) cannot be changed once an entity has been created. In addition, the primary field properties cannot be modified once an entity is created.
Custom entities
All new entities created as part of a customization and implemented in Dynamics CRM are custom entities. When creating a new custom entity, we have the freedom to configure all the settings and properties as needed from the beginning. We can use a naming convention that makes sense to the user and generate all the messages from the beginning, taking advantage of this name.
A custom entity can be assigned by default to be displayed in one or more of the three main modules or in the settings and help section.
If a new module is created and custom entities need to be part of this new module, we can achieve this by customizing the application navigation, commonly referred to as the application sitemap. While customizing the application navigation might not be such a straightforward process, the tools released to the community are available, which makes this job a lot easier and more visual. The default method to customize the navigation is described in detail in the SDK, and it involves exporting a solution with the navigation sitemap configuration, modifying the XML data, and reimporting the updated solution.
Extending entities
Irrespective of whether we want to extend a customizable business entity or a custom entity, the process is similar. We extend entities by creating new entity forms, views, charts, relationships, and business rules.
Starting with Dynamics CRM 2015, entities configured for hierarchical relationships now support the creation and visualization of hierarchies through hierarchy settings.
We will be taking a look at each of these options in detail in the next sections.
Entity forms
Entities in Dynamics CRM can be accessed from various parts of the system, and their information can be presented in various formats. This feature contributes to “the 360-degree view of customer data.
In order to enable this functionality, the entities in Dynamics CRM present a variety of standard views that are available for customization. These include standard entity forms, quick create forms, and quick view forms. In addition, for mobile devices, “we can customize mobile forms.
Form types
With the current version of Dynamics CRM 2015, most of the updated entities now have four different form types, as follows:
- The main form
- The mobile form
- The quick create form
- The quick view form
Various other forms can be created on an entity, either from scratch or by opening an existing form and saving it with a new name. When complex forms need to be created, in many circumstances, it is much easier to start from an existing entity “form rather than recreating everything.
We have role-based forms, which change based on the user’s security role, and we can also have more than one form available for users to select from. We can customize which view is presented to the user based on specific form rules or “other business requirements.
It is a good practice to define a fallback form for each entity and to give all the users view permissions to this form. Once more than one main forms are created for an entity, you can define the order in which the forms are presented based on permissions. If the user does not have access to any of the higher precedence forms, they will be able to access the fallback form.
Working with contingency forms is quite similar; here, a form is defined to be available to users who cannot access any other forms on an entity. The approach for configuring this is a little different though. You create a form with minimal information being displayed on it.
Only assign a system administrator role to this form, and select enable for a fallback. With this, you specify a form that will not be visible to anybody other that the system administrator. In addition, configuring the form in this manner also makes it available to users whose security roles do not have a form specified. With such a configuration, if a user is added to a restrictive group that does not allow them to see most forms, they will have this one form available.
The main form
The main form is the default form associated with an entity. This form will be available by default when you open a record. There can be more than one main form, and these forms can be configured to be available to various security roles. A role must have at least one form available for the role. If more than one form is available for a specific role, then the users will be given the option to select the form they want to use to visualize a record available for it to be selected by the user. Forms that are available for various roles are called role-based forms. As an example, the human resource role can have a specific view in an account, showing more information than a form available for a sales role.
At the time of editing, the main form of an entity will look similar to the “following screenshot:
A mobile form
A mobile form is a stripped-down form that is available for mobile devices with small screens. When customizing mobile forms, you should not only pay attention to the fact that a small screen can only render so much before extensive scrolling becomes exhaustive but also the fact that most mobile devices transfer data wirelessly and, as such, the amount of data should be limited.
At the time of editing, the Mobile Entity form looks similar to the Account Mobile form shown in the following screenshot. This is basically just a listing of the fields that are available and the order in which they are presented to the user.
The quick create form
The quick create form, while serving a different purpose than quick view forms, “are confined to the same minimalistic approach. Of course, a system customizer “is not necessarily limited to a certain amount of data to be added to these forms, “but it should be mindful of where these forms are being used and how much real estate is dedicated to them.
In a quick create form, the minimal amount of data to be added is the required “fields. In order to save a new record, all business-required fields must be filled in. “As such, they should be added to the quick create form.
The quick create form are created in the same way as any other type of form. In the solution package, navigate to entities, select the entity in which you want to customize an existing quick create form or add a new one, and expand the forms section; you will see all the existing forms for the specific entity.
Here, you can select the form you want to modify or click on New to create a new one.
Once the form is open for editing, the process of customizing the form is exactly the same for all forms. You can add or remove fields, customize labels, rearrange fields in the form, and so on.
In order to remind the customizer that this is a quick create form, a minimalistic three-column grid is provided by default for this type of form in edit mode, “as shown in the following screenshot:
Pay close attention to the fact that you can add only a limited type of controls to a quick create form. Items such as iframes and sub-grids are not available.
That’s not to say that the layout cannot be changed. You can be as creative as needed when customizing the quick create view.
Once you have created the form, save and publish it. Since we have created a relationship between the account and the project earlier, we can add a grid view “to the account displaying all the related child projects.
Now, navigating to an account, we can quickly add a new child project by going “to the project’s grid view and clicking on the plus symbol to add a project. This will launch the quick create view of the project we just customized. This is how the project window will look:
As you can see in the previous screenshot, the quick create view is displayed as an overlay over the main form. For this reason, the amount of data should be kept to a minimum. This type of form is not meant to replace a full-fledged form but to allow a user to create a new record type with minimal inputs and with no navigation to other records.
Another way to access the quick create view for an entity is by clicking on the “Create button situated at the top-right corner of most Dynamics CRM pages, “right before the field that displays your username. This presents the user with “the option to create common out-of-the-box record types available in the system, “as seen in the following screenshot:
Selecting any one of the Records options presents the quick create view. If you opt to create activities in this way, you will not be presented with a quick create form; rather, you will be taken to the full activity form.
Once a quick create form record is created in the system, the quick create form closes and a notification is displayed to the user with an option to navigate to the newly created record. This is how the final window should look:
The quick view form
The quick view form is a feature added with Dynamics CRM 2013 that allows system customizers to create a minimalistic view to be presented in a related record form. This form presents a summary of a record in a condensed format that allows you to insert it into a related record’s form.
The process to use a quick view form comprises the following two steps:
- Create the quick view form for an entity
- Add the quick view form to the related record
The process of creating a quick view form is similar to the process of creating “any other form. The only requirement here is to keep the amount of information minimal, in order to avoid taking up too much real estate on the related record “form. The following screenshot describes the standard Account quick create form:
A very good example is the quick view form for the account entity. This view is created by default in the system. It only includes the account name, e-mail and “phone information, as well as a grid of recent cases and recent activities.
We can use this view in a custom project entity. In the project’s main form, add a lookup field to define the account related to the project. In the project’s form customization, add a Quick View Form tab from the ribbon, as shown in the following screenshot:
Once you add a Quick View Form tab, you are presented with a Quick View Control Properties window. Here, define the name and label for the control and whether you want the label to be displayed in the form.
In addition, on this form, you get to define the rules on what is to be displayed “on the form. In the Data Source section, select Account in the Lookup Field and Related Entity dropdown list and in the Quick View Form dropdown list, select “the account card form. This is the name of the account’s quick view form defined “in the system. The following screenshot shows the Data Source configuration and the Selected quick view forms field:
Once complete, save and publish the form.
Now, if we navigate to a project record, we can select the related account and the quick view will automatically be displayed on the project form, as shown in the “next screenshot:
The default quick view form created for the account entity is displayed now on the project form with all the specified account-related details. This way any updates to the account are immediately reflected in the project form.
Taking this approach, it is now much easier to display all the needed information on the same screen so that the user does not have to navigate away and click through a maze to get to all the data needed.
Summary
Throughout this chapter, we looked at the main component of the three system modules: an entity. We defined what an entity is and we looked at what an entity is composed of. Then, we looked at each of the components in detail and we discussed ways in which we can customize the entities and extend the system. We investigated ways to visually represent the data related to entities and how to relate entities for data integrity. We also looked at how to enhance entity behavior with business rules and the limitations that the business rules have versus more advanced customizations, using scripts or other developer-specific methods.
The next chapter will take you into the business aspect of the Dynamics CRM platform, with an in-depth look at all the available business processes. We will revisit business rules, and we will take a look at other ways to enforce business-specific rules and processes using the wizard-driven customizations available with the platform.
Resources for Article:
Further resources on this subject:
- Form customizations [article]
- Introduction to Reporting in Microsoft Dynamics CRM [article]
- Overview of Microsoft Dynamics CRM 2011 [article]
