Different Entity Flavours: New entity, new form or same same?

Often times we have different “flavours” of the same entity. For example, we might have cases related to customer service enquiries and other type of cases related to product failures. So the question often arises: How to best model in CRM these different types of entities, should we use the same entity? the same form? This posts aim to provide some guidance for that scenario.

In the example above, you might be hesitating whether or not these 2 different type of cases should use the same entity and have a simple “qualifying” attribute (dropdown) to identify the case type or whether it makes more sense to have a different custom entity for each case type. If you select the same entity, you might also wonder whether the same form should be used for all case types or(maybe with some dynamic show/hide sections) or whether different forms should be used and route to the correct form depending on the value of the “case type” field.

For the sake of this example, I will stick to the “case type” example, although I have seen the same scenario come up with other entities such as contacts and opportunities. When you find yourself in the situation in which you are not sure whether or not to re-use the same entity or even whether or not to reuse the same forms, here are few questions that can help you get started with your assessment:

1. Do you have different security requirements for each case type? If you have a requirement such that a given role/team can only have access to a specific case type then you' should consider using different entities since it will be much easier to manage the security granularity for each of the case types without having to write and maintain tons of code for it.

2. Do you execute reports and BI on all cases aggregated? In this case if you split your case into multiple entities then your reporting can be more challenging and simple charts such as “case per type” would become a pain to do.

3. How much of the business logic is shared? If most of the business logic applies across the board (e.g. same escalation rules, same custom ribbon commands, etc) then it would be easier to re-use the same entity than having to duplicate all that business logic you implemented using JS or plugins on your entity. Also consider whether you will need some of the out-of-the-box business logic (e.g. escalations or allotments for cases) that you don’t want to re-invent if you use a new entity.

4. How much overlap do you have in the fields of each case type? If the only field that the different case types have in common is the “title” then this is a clear indication that your case types are in essence different entities. It would be annoying for end users when they use advanced find or they are creating views/dashboards that they see a long list of fields but they don’t know which field applies to what case type. If most of your fields are applicable across all case types then it would make more sense to share the same entity.

5. Are the optionset values the same for all your case types? Consider for example the “Source” field. Depending on your case types the applicable values might be different, for example “Twitter” might be a valid source for a customer service case but does not apply to an operational case of equipment failure. Think about the effort required to filter or validate option sets if they are too different for each of your case flavours.

 

By now you might have a better idea of whether or not to re-use the same entity or define a new one; there is no one-size-fits-all or blank/white answer, sometimes you need to consider multiple factors and make a difficult decision based on the information you know (e.g. the questions above). Now, if you decide to re-use the same entity you are left with the question: Should I use the same form or define a new form for each case type? Again, there are pros and cons of each approach and I’ll just attempt to provide you food for thought so you can make a better decision to the question above.

1. You can create a “base” form which has a dropdown for the case type. This would be the form that users would see when creating a new case. Depending on the case that they select then you have JavaScript onload that automatically navigates to the appropriate form. This works very well but there is a bad side effect from user experience: Each time you open a case, the last used form is opened by default even if it is not the correct form for the case type you opened. The user will see a delay in which the old form is loaded and after a few seconds it will forward to the correct form and reload it. If the same user has to deal with multiple forms all the time then this effect can be quite annoying and unfortunately there is no functionality in CRM such that the record opens on a specific form without the “jumping”. However, if typically users will only open a specific case type then it would work fine because the same form will always be used by default and rarely will the user see the form switching automatically.

2. Using additional forms allows you to configure role-base security. However, you should probably not leverage this because if you restrict who can see which forms then users might open a case record in the wrong form and the system is unable to navigate to the appropriate form if the user does not have the required role. If you leverage multiple forms per entity depending on case type then it is recommended you allow all users who have access to case to see all forms for case. You can leverage FLS if you want to hide specific fields.

3. Consider creating a common section/tab on the form which contains all the fields that apply to all cases. Then you can add one tab per each case type and then hide the tab dynamically on-load depending on the value of the case type. This works great from user experience because they don’t see the form “redirecting” and it is much faster than having multiple forms. The down-side is that it could get complex if you have many fields and subsections that overlap with some case types but not others. I usually prefer this approach when things are simple (only a few fields are different).

4. Remember that restricting access on a given form to  given role does not restrict the access on the record itself. If you don’t want your customer service team to see system failure case types then restricting the form will not be enough, they would still be able to open system failure cases but see them from the customer service form (which is odd and can cause confusion). If you really have strong security restrictions consider using separate entities or field level security (FLS).