Microsoft Dynamics 365 Extensions Cookbook: Add functionality to existing model elements, source code and finally package and deploy using DevOps

In order to configure the schema, you will need to have access to a Dynamics 365 instance along with a System Customizer or higher security role . As a best practice, it is always recommended that you implement your configuration within a solution. For the purpose of this book, it is expected that you already have a solution created called Packt with a publisher prefix of packt_.

Just like database modeling, entities can be normalized or denormalized. Normalizing a structure is the action of separating it into several related tables to reduce redundant data or empty fields. Denormalizing a structure is the opposite: we merge two or more tables together to simplify the structure and improve query performance, whilst adding redundant or empty fields. In this recipe, the entity was denormalized to allow different types of contacts to be surfaced through the same contact entity.

In step 1 to step 4, we added the existing contact entity to the Packt solution. Notice that in step 3, we had the option to either add the necessary assets or add all assets. For this recipe's simplicity, we added all assets. With the recent granular solution enhancements, we can simply add what is required.

In step 5 to step 7, we created the attributes, and in step 8 and step 9, we added the attributes to a new contact form. In step 10, we published the configuration we implemented.

Looking at the design of the updated entity, we have now configured the contact entity to fulfill more than one purpose: it is a generic contact as well as a student one.

A simplifiedEntity Relationship (ER) diagram is depicted in the following screenshot:

The advantages of a denormalized model are:

The disadvantages of a denormalized model are:

Similar to the previous recipe, System Customizer or higher security role is required to perform the configuration as well as a solution to contain the changes.

Although this recipe is simplified, typical normalized models will contain more than one attribute, as well as more than one entity.

In step 2 to step 11, we created a normalized entity that contains the employee details along with its Quick View. In step 4, we avoided keeping the checkboxes ticked. All the checkboxes with a

symbol depict options that cannot be reverted. We can always enable them later if required. As a best practice, if they are not required, don't enable them, otherwise your choice will be irreversible. In step 12 and step 13, we created a relationship between contacts and the newly created entity to provide a navigation path between the parent contact entity and the additional attributes for the specific types (Supervisor and Post Graduate Start Date). In the last steps, step 14 to step 18, we added the lookup as well as the Quick View on the contact form. A Quick View is a simplified sub-view of another record that can be placed on the parent record's form to display the child's subset of attributes in read-only. The red box in the following screenshot highlights the Quick View related to the Graduation Details lookup record:

With this design we can now see the graduate details on the contact form without creating the attributes on the entity itself.

Our ER diagram now looks like this:

The advantages of normalizing your data with a common parent are:

This model also has some cons, which are as follows:

Similar to the previous recipes, a System Customizer or higher security role is required to perform the configuration, as well as a solution to contain the changes.

The alternative to the previous two modeling patterns is to keep your entities completely separate. This could prove to be an efficient design as it maximizes your instance's diversity. You can create a multitude of entities without overcrowding and without overlapping functionality. Nonetheless, as a best practice, promote reusability where possible. Keep in mind that a Dynamics 365 online instance has a limit on the number of custom entities that can be created. The limit also includes custom entities introduced by deploying third-party solutions. At the time of writing, the limit is 300 custom entities per Dynamics 365 instance. You can check your limit by navigating to Settings | Administration | Resources In Use:

Your new ER diagram is highlighted in the following screenshot:

The advantages of a completely normalized model are:

This model also has some cons, some of which are:

Similar to the previous recipes, a System Customizer or higher security role is required to perform the configuration as well as a solution to contain the changes.

Enter the following details, followed by a click on Apply:

Enter the following details:

Enter the following in the right-hand pane:

We started by marking the field as hidden by default in step 3. As a best practice, it always makes for a better user experience when hidden fields are revealed, as opposed to hiding visible fields on loading a record. In step 7 and step 8, we created the condition and rule to show the field; in step 9 and step 10, we created the converse condition and rule to hide the field. Always think about the reverse scenario when implementing business rules, otherwise, you will be faced with an irreversible action.

Given that the scope of the business rule was set to the default All Forms (top-right corner when editing the business rule), all forms will now respect that rule. If the scope was set to Entity, the rule would also trigger on the server side, which could be useful if implementing calculation rules that need to be respected when manipulating the data outside of a form (for example editable grids, bulk import, or through the Web API or SDK):

Behind the scenes, JavaScript functionality is created to address the rules' requirements. This is also respected in all form factors following the configure once, deploy everywhere design pattern.

Business Rules also have limitations, as follows:

For additional limitations, visit https://technet.microsoft.com/en-us/library/dn531086.

Business Rules provide a wide range of actions that can be performed. Among them are the following:

The TechNet article (https://www.microsoft.com/en-us/Dynamics/crm-customer-center/create-business-rules-and-recommendations-to-apply-logic-in-a-form.aspx) covers more details about Business Rule.

Similar to the previous recipe, a System Customizer or higher security role is required to perform the configuration as well as a solution to contain the changes.

In step 2 to step 4, we created a workflow that triggers on creation (when the contact record is first created, the workflow will start waiting). The workflow can also be called on demand in case we want to trigger it again. In this example, the contact might already be created but not as a Student. Once the contact is set as a Student, the workflow can be triggered manually to send the welcome e-mail.

In step 5 and step 6, we set up the wait condition to wait for a day.

In step 7 and step 8, we checked if the contact is an active student with an e-mail address.

In step 9 to step 12, we created a personalized e-mail for the contact and welcomed them.

In step 13, we activated the workflow.

When asynchronous workflows are triggered, they enter into a pool to be processed when the asynchronous service is free. Asynchronous workflows are typically executed within seconds or minutes. If the execution is taking hours, then you might want to raise a support ticket with Microsoft to investigate. Executing workflows asynchronously is a great way to lighten the load on your Dynamics instances.

When workflows instances are waiting for a condition to be satisfied, they do not consume resources or affect your instance's performance. However, it is generally agreed by the community that it is a bad practice to have too many workflow instances in a waiting status.

In more recent releases, synchronous workflows that turn your workflow into a configurable plugin became available. Microsoft does not recommend synchronous workflows for long processes due to the load that is associated with them. Furthermore, online instances have a limit of 2 minutes per synchronous workflow or plugin. Nevertheless, synchronous workflows are there to be used. Use them wisely.

Similar to the previous recipes, a System Customizer or higher security role is required to perform the configuration as well as a solution to contain the changes.

In step 2 and step 3, we created the blank action. We ensured that the action's entity is set to None (global), meaning that the process is not bound to any entities (the way workflows are).

In step 4, we created three input parameters and one output parameter.

In step 5 to step 7, we created the student contact record using the input parameters.

In step 8 to step 10, we assigned the created record to the output parameter.

In step 11, we activated the process.

As mentioned previously, actions can be called from workflows, JavaScript, Plugins, or using the Dynamics 365 web services. Every time an action is created, Dynamics 365 creates a message that can be called externally. In the Creating your first custom action recipe in Chapter 4, Server-Side Extensions, you will learn how to generate early-bound types for actions to call using managed .NET code.

Microsoft recommends naming your action using a verb describing what the action is about to ensure your application's vocabulary is something that makes sense from a business flow perspective.

For more information about actions, visit https://technet.microsoft.com/en-us/library/dn531060.aspx.

The Creating your first custom action recipe of Chapter 4, Server-Side Extensions

Similar to the previous recipes, a System Customizer or higher security role is required to perform the configuration as well as a solution to contain the changes.

In step 2 to step 7, we created a new rollup field of type whole number that calculates the total count of active activities associated with a contact.

Frequency

When a rollup field is created, behind the scenes, a system asynchronous job is scheduled to execute 12 hours after the field is created. Navigate to Settings | System Jobs; you will see a job of type Mass Calculate Rollup field with the name of your new field in System Job Name. You can force the job to run sooner by clicking on Action | Postpone and entering an earlier date/time. It is not recommended to do so when you have a large number of records in a production environment. The first time the job runs, it will have to update all fields, which might lead to a performance impact.

Subsequently, the System Jobs option will have a Calculated Rollup field per entity that has rollup fields configured. By default, subsequent rollup field calculations will take place every hour, (which is the fastest schedule). If an hourly update is not necessary, you can update the value by double-clicking on the System Job option, and selecting Actions | Modify Recurrence. This will present a dialog box that helps you redefine the recurrence of the execution:

Note

Given that the rollup fields are executed as asynchronous jobs, if the calculation is not occurring, consider checking the status of the asynchronous service. For on-premise installation, log on to your backend server and check its status. For online implementations, log a support call with Microsoft to check the status of the service.

Rollup fields are a powerful feature in Dynamics 365. On top of the counting capability described in this recipe, rollup fields offer other types of aggregations. Furthermore, in some cases (activities), the aggregation can span across multiple relationship levels.

Similar to the previous recipes, a System Customizer or higher security role is required to perform the configuration as well as a solution to contain the changes.

In this recipe, we used a point and click configuration to set up a calculated field to calculate the number of months' difference between a graduate's start date and end date.

In step 5 and step 6, we defined the condition, and in step 7, we defined the calculation formula.

Given that the execution takes place on the server side, the users will only see the changes right after a save event is triggered. Unlike business rules and JavaScript customization, the result is not instantaneous. They do not trigger after the condition is met on the form frontend.

Similar to rollup fields, calculated fields are read-only and do not take into account a user's security roles.

Calculated fields are a powerful addition; they can be used in many scenarios, some of which are:

The TechNet article (https://technet.microsoft.com/library/dn832103.aspx) covers calculated fields in a few examples. The article also covers some limitations of calculated fields. Among them are the following:

At the time of writing, in addition to basic arithmetic operations, the Dynamics 365 supports the following built-in formulas with their respective return types:

Similar to the previous recipes, a System Customizer or higher security role is required to perform the configuration as well as a solution to contain the changes.

In step 2 to step 5, we created an alternate key using First Name, Last Name, and Email on an individual. In step 6, we tested the duplicate detection by creating two records with the same key combination.

Alternate keys have a similar behaviour to conventional duplicate detection, except the check happens at a lower level in the database (a unique nonclustered index). Additionally, if a duplicate is detected, primary keys will strictly stop a duplicate from being created, whereas, conventional duplicate detection functionality gives you the option to create it nonetheless. This is particularly important if you want to stop duplicates when using different channels than the frontend forms.

Behind the scenes, Dynamics CRM is creating a nonclustered unique index using the three fields defined in the key. If you have an on-premise deployment, you can run a SQL profiler to intercept commands that are executed on the database. A query similar to the following one will appear in your list:

CREATE UNIQUE INDEX [ndx_for_entitykey_packt_NameandEmail]
ON [ContactBase]
([EMailAddress1] ASC, [FirstName] ASC, [LastName] ASC) 
INCLUDE ([ContactId])
WHERE [EMailAddress1] is not null
AND [FirstName] is not null
AND [LastName] is not null
WITH (FILLFACTOR = 80, MAXDOP = 4, SORT_IN_TEMPDB = ON)

The preceding query creates a unique nonclustered index on the ContactBase (the contact table) on the three columns: FirstName, LastName, and EmailAddress1. For more information on nonclustered indexes, read the following article at https://docs.microsoft.com/en-us/sql/relational-databases/indexes/create-nonclustered-indexes

During the duplicate detection process, if a field has an empty value (translated to NULL in the database) in one of the fields, the record will not be identified as a duplicate.

Note that alternate key creation can fail sometimes. Always check, after creating your key, whether the creation has been successful. If a duplicate already exists in your dataset, the key creation will fail. To check the status of a newly created key, in your solution, navigate to Entities | <your entity> | Keys and ensure the Status column states Active. If the creation fails, it will state Failed: