The subject of today’s tip is highly debatable but Eric Regnier did do justice to it. (Want to start a discussion of your own? Email your tip to jar@crmtipoftheday.com)

In many implementations particularly complex ones, often comes a situation to determine if the same entity should be used for the different “types” (or categories). Say an insurance company implements claim management, there are multiple types of claims, each with their own set of fields and separate business logic/requirements. What do to? One claim entity for all or split into its own entity? Here are some quick pros/cons to provide some guidance.

Some assumptions to support the pros/cons

• Entity in question is complex (>100 custom fields)
• Entity has a high chance of evolving (especially in Agile methodologies)
• Entity is a core/important entity of the system

Pros if split

• Ability to segregate privileges per entity and therefore, have a simpler and more flexible security model. Although might be possible to satisfy requirements if it were one entity, security becomes more complex, e.g. using field level security (which has perf impact amongst other things.)
• Ability to segregate customizations (plugins, workflows, etc) per entity aka separation of concerns. E.g. no extra lines of code to determine which logic to execute based on the type. Some performance gain; can scale and scope plugins/workflows/Flows/etc to execute on the exact type.
• Less risk of regression. Changes occur only on the respective entity, and not touching the other types.
• Leaner forms per entity. Don’t have to create separate forms or one form with JavaScript to auto-switch based on type.
• Performance on searching. If one entity for all types and many fields require searching, might have performance impact. From my experience, I try to limit searchable fields (quick find) to no more than 10.
• In database terms, entity model becomes more “normalized”.  Easier for developers and end-users (e.g. in Advanced Find) since only the corresponding fields are made available. Don’t have to think which fields are for which type.
• If entity contains a lot of data (>1M), in split scenario, data is split and each entity can have its proper indexes.     
• Might be cases where sub-types or even sub-sub-types are needed which make the entity model even more complex if it were one entity.

Neutral

• Reporting can become simpler or more complicated depending of the case. If split, can target specific type without additional filters on every report/view.
• No impact on global/relevance/categorized search. All entities can be configured accordingly. Search at the entity level however will only get results from the entity selected.

Cons if split

• On forms, dashboards and views/charts will have separate sub-grids per entity.  If required to see records in one sub-grid, then custom web resource or canvas app is required.
• If same logic is required on each type, then will have to copy or rely on JavaScript/code not to duplicate the logic. For example, show/hide field on form with business rule. Will require the same business rule on every type unless a common JavaScript function is done (requires a developer).
• There is no concept of inheritance in CRM/D365 CE, so if many fields are the same, will have to recreate the fields in every entity. Developer/customizer will need to be vigilant to ensure the datatype and names matches exactly.

Tîpp Jäår $0.02 + tax

Splitting entity is one of my favorite techniques, especially when it comes to security. But I knew I used it for something else in the past… Lo and behold, “how to update a record without modifying the modifiedon” or Keep your pants on and timestamps intact.