The third modeling technique is similar to the second, except that the entities are completely independent. This scenario is typically used when there is a logical separation between the entities and there are few commonalities between them, to the point where reusability is not justified.
In this recipe, we will create a new entity called contractor that mirrors the contact entity with some additional attributes.
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.
- Navigate to
Settings|Solutions|Packt. - Click on
New|Entity. - Enter
Contractorin theDisplay Namefield, andContractorsunder thePlural Namefield, and click onSave:
- Navigate to
Fieldson the left-hand side and click onNew. - Create an attribute called
Hourly Rateof typeCurrencyand click onSave and Close:
- Navigate to
Contractor|Formsand open theMain Informationform. - Add the newly created field to your form by dragging and dropping the attributes from the right-hand window on to the form.
- Click on the
Publish All Customizationsbutton for your solution.
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:
- No coupling between entities, resulting in cleaner and easier to manage solutions
- Full independent control using security roles for each of the entities
- Positive user experience with clean independent forms
- No need for complex configuration or customization to show and hide irrelevant sections
This model also has some cons, some of which are:
- Search results will appear in different lists
- Cannot combine views with both entities
- Some out-of-the-box entities (contact, account, and activities, among others) have well-defined core structures that could be difficult to recreate (for example, the regarding field on activities).
- Modeling denormalized entities
- Modeling normalized entities with a common parent
- Using a Business Rule to show and hide attributes
- The Building cumulative security roles recipe of Chapter 7, Security