In Part 1, we looked in detail at some of the functionality natively by the case entity that isn’t provided by a custom entity.
In this part, we look at some of the things you need to consider when designing a solution using either method.
Defining Case Management
Until the advent of the new licensing model in Dynamics 365 it wasn’t strictly necessary to define what Case Management is at a low level when beginning a new Dynamics 365 implementation. For the most part, using the out of the box Case entity was a convenient way to go with some out of the box functionality, regardless of whether the customer needed it at that time. This gave comfort that the customer was using ‘best practice’ functionality. In theory, maintenance costs could be kept to a minimum, ensuring the customer can avail of planned new features for the Case entity.
However, when designing a solution, whether in conjunction with a customer when providing consultancy, or as part of a formal response to a tender or list of customer requirements, it is best practice to look at each customer requirement, confirm what is required and then decide how to model an appropriate solution using the most suitable entities.
Once such analysis is complete, a decision may be made to either
- Use the out of the box Case entity with all the out of the box features it provides.
- Model a custom entity or entities. From a technical perspective, this could be because of a need to create multiple types of records, nested relationships for custom entities within a primary record, more niche requirements than are covered by a generic case, or because much of the native case functionality does not match detailed requirements.
The Dynamics 365 licensing model may now influence what was a previously purely a technical or business decision. With new record based licensing introduced in December 2016, the total cost of ownership of a Dynamics solution which uses the Case record has increased dramatically for some customers. When designing a solution for Case Management, we need to consider this increase. There is a need to understand at a low level whether it is appropriate to recommend a native Case Management solution or whether it is more appropriate to recommend a custom entity based XRM style solution.
Dynamics 365 Licensing Guide Ambiguity
Consider this sentence from the Dynamics 365 Enterprise Licensing Guide
“Microsoft Dynamics 365 for Team Members and higher provide the right to use custom entities. Custom entities may only be created or replicated by a partner or user licensed for full Application or Enterprise Plan use. Custom entities may be based on entities included in Dynamics 365, or created by a customer or partner. If the custom entity is based on or replicates the functionality of entities included in Microsoft Dynamics 365, or if the entity links to entities included in Microsoft Dynamics 365, then users accessing the custom entity must also be licensed to access the included or replicated entity. For example, users creating an entity that replicates the cases entity for a ticketing system would still require the user to be licensed for cases. In other words, customizations may only be performed against entities users are licensed to access.”
There is currently no official clarity from Microsoft on what replicates means. The purpose of this article is to assist your decision based on a detailed review of Case Management v Custom Entity features.
As always, please contact Microsoft, your partner or a dedicated licensing and solution specialist to ensure that you are appropriately licensed for your implementation type.
What is a Case in Dynamics 365?
At a database or SDK level the Case entity is called an incident entity which gives you some idea of its origins. In CRM 4.0 and CRM 2011 it was still a relatively basic record with not much added value over custom entities. CRM 2013 Service Pack 1 in Spring 2014 added a slew of new features such as SLAs, Case Status Transitions, Entitlements and Parent and Child cases and it has stayed much the same since, with a few minor tweaks in the interim. Some of these features such as SLAs have since been added to custom entities.
Feature and Functionality Comparison Matrix
|Feature||Native Case Entity||Custom Entity||Design Decisions and Considerations|
|Business Process Flows||Yes||Yes||There is a single default business process flow on the Case entity called ‘Phone to Case Process’. This is relatively basic and is often the first thing that needs to be updated or turned off. Similar more tailored business process flows can be applied to custom entities if required. Standard|
|Social Engagement Integration||Yes||Yes||You can create a Case from Social Engagement, however you can create any type of record, so this works as well with custom entities as it does with the case entity.|
|Case Status Transitions||Yes||Yes||Available with both custom and case entities. Case comes with pre-defined statuses, but these often need to be changed and are trivial to configure on custom entities.|
|Queues||Yes||Yes||Available on both custom and Case entities. A generic and longstanding feature that provides the foundation for managing cases and CRM records.|
|SLAs||Yes||Yes||SLAs are available on all custom entities as of CRM 2016 SP1. Prior to that, they were only available on the Case entity.|
|Categories||Yes||Yes||We can create a standard relationship to a category from any entity – there is no specific restriction on the category for the Team Member license in the CRM licensing guide. Alternatively, a custom entity could be used to model subjects or categories. Team member licensing should allow read access to Categories as a lookup on the custom entity form.|
|Countdown Timer||Yes||Yes||This was added in Spring Wave 14 and applied to custom entities as well as cases, so equally applies to both.|
|Support Hours and Schedules with SLAs||Yes||Yes||Since 2016 SP1, Custom Entities support SLAs and SLAs read Customer Service Schedule. So, this is available with both Cases and Custom Entities.|
|Record Security||Yes||Yes||Custom Entities have the same security model as Cases – can be restricted by business units and other native security features such as access teams, sharing etc.|
|Record Ownership||Yes||Yes||Custom entities can be user owner, assigned to teams and users as required in the same way cases can be assigned.|
|Automatic Case Creation Rules||Yes||No (though can create workflows)||While Automatic Case Creation rules cannot be used with custom entities, these rules are just a vehicle for creating workflows under the hood.
Consider how much extra effort is it to create a workflow as opposed to creating a Case Creation Rule?
|Routing Rule Sets||Yes||No (though can create workflows)||When you create and activate a routing rule set, internally a corresponding workflow is also created. While Routing Rule sets are not available with custom entities, the same functionality can be achieved with workflows. Consider how much extra effort this will be.|
|Subjects||Yes||No||Subject is most likely next on the list to be deprecated to be replaced by categories. Subjects are legacy from CRM 4.0. Consider using categories instead.|
|Merge Case Functionality||Yes||No||Can merge up to 10 active cases. User picks a primary case and the default functionality re-associates all activities, notes and attachments with the primary case. It makes the merged cases cancelled and creates a merged case relationship between the cancelled cases and the master case.
Consider if this is required and if the native Merge Case functionality is a good fit.
|Parent / Child Cases||Yes||No||Introduced Dynamics CRM 2013 SP1. Child cases can inherit fields from the parent case. Can close child cases as part of parent case closure or alternative not allow parent case to be closed until all child cases are.
Similar functionality could be modelled with workflows and self-referential relationships with custom entities. Consider if this is required and if the native Parent / Child case functionality is a good fit.
|Entitlements||Yes||No||This is typically more of a private sector service industry function. Consider whether there is a real current or future requirement for this and whether it fits your use case.|
|Rollup of Activities to Accounts and Contacts||Yes||No||If a user logs an activity against a case, this will be displayed in the related account/contact activity history.
While this is not really case specific functionality, it is a big benefit for organisation who need to have a single view of the customer’s activities.
Prior to Dynamics 365, if a user logged an activity against a custom case entity, we would need to have appropriate logic on the activity to also associate it with the contact or account in a workflow or plugin or use a solution such as this.
Post Dynamics 365 (v8.2), this is configurable out of the box with Rollup views on relationships to the account and contact entity.
|Out of the Box Reports and Dashboards||Yes||No||There are 5 dashboards provided out of the box which reference the Case Entity. These are :
– Customer Service Manager Dashboard
– Customer Service Operations Dashboard
– Customer Service Performance Dashboard
– Customer Service Representative Dashboard
– Customer Service Representative Social Dashboard
Natively there is a single Case Summary Table report that reports directly off the Case Entity.
Consider the amount of effort required to build required reports and dashboards.
|Pre-Configured Forms and views||Yes||No||Native cases give you some pre-defined forms and fields on those forms. Custom entities mean you must define the form from scratch.
Understand if it is easier to start with a blank canvas or to start with a Case form where you must remove grids and fields – some of these are harder to remove than others.
|Convert Activity to Case Button||Yes||No||This Case function is hard coded to show only a few choice fields (such as subject), is likely to be, (and hopefully) needs to be revamped.
Understand if using native cases or custom entities if you want to replace with a pop-up web resource to do something similar and more flexible. You may want to do this with both case and custom entity.
|Knowledge Base Integration||Yes||No||The knowledgebase integration is in a half-way house at the minute. There are 3 different types of Knowledge Base record.
kbarticle is legacy and is officially deprecated – this is displayed in the tab at the bottom of the case form.
knowledgebaserecord is used specifically for Parature, so don’t use this.
knowledgearticle – the current flavour of the month. This is integrated with the case entity standard activity control front and centre of CRM 2016 and later. This can’t be customised until CRM v9.0 (365 2017 July). This control can’t be added to custom entities. This is being replaced in CRM V9.0 in the new unified interface and may be able to be used with custom entities then.
Understand whether the customer plans to use this or not, now or in the future.
|Case Resolution Record||Yes||No||When you close a native case, CRM automatically sums all the duration from the activity records and puts in the case resolution activity record.
This functionality is not provided with custom entities. Consider whether you have a current or future requirement for this.
|Microsoft Portals Default Customer Portal||Yes||No||The Portal Customer Service Portal default configuration uses the Case entity by default leading to a straightforward default portal installation. However, you can also configure custom entities in the same way. How granular are portal requirements meant to be?
Is there a current or future need for a portal at all?
Dynamics 365 v9 has a wizard for adding custom entities to the portal instead of creating all the ADX records manually.
|Other pre-existing Fields||Yes||No||Case Origin Code
Case Type Code
Do customers always want these fields / needs these fields?
Default icons can be configured based on the Case Origin code for display in read-only grids. The equivalent functionality can be applied to a custom entity on an editable grid.
|Contracts||Yes||No||Contracts can be added to a case because they may include a specific level of support or service. A customer may have a certain amount of support hours or may be limited to a specific number of cases.
Like entitlements, have you any need for contracts -does it fit with your organisations business? Not all types of business are likely to need these?
|Future Enhancements||Yes||No||Potentially Cases will get future customer service related enhancements, custom entities may not get such case specific functionality (but may get other generic enhancements in the same way that SLAs were added to custom entities).
Understand you are at a crossroads and are going down a particular path. You may exclude your system from future enhancements in newer versions.
|Record Auto-Numbering||Yes||No||Case Numbers are generated automatically. There are many auto-number solutions available commercially and via open source solutions.|
Native Case v Custom Entity Advantages and Disadvantages
|Native Case||– Parent / Child Cases – up to 100 child cases can be created.
– Merge Cases – can merge up to 10 at a time.
– Routing Rule Sets (creates workflow under the hood).
– 5 Out of the box dashboards.
– 1 Default Case Report.
– Rollup of Activities to Accounts and Contacts.
– Convert Activity to Case functionality on activities.
– Knowledge Base Integration.
– Contracts / Entitlements.
– Mature functionality likely to be supported and extended by Microsoft.
|– More expensive licensing than Team Member licensing.
– There may be much unused functionality when the requirement is for a very basic case management or niche case management solution.
– Noisy – there may be lots of unused or unrelated fields.
– Entitlements and Contracts quite niche for some domains so may not be required.
– Need to hide and turn off things.
– No standard definition of Case across multiple business units within an organisation confuses things.
– Custom Relationships for niche users pollutes the generic case record.
– Convert Activity to Case functionality is there, but is legacy and not extendable (uses Subjects)
|Custom Entity||– Inexpensive with Team Member licence though make sure you are appropriately licensed.
– A blank canvas. If there are very bespoke requirements and many relationships, a custom entity may seem.
– SLAs included for Custom Entities since CRM 2016 SP1.
– Case Status Transitions available like native cases.
– Queues provide for basic Case Management functionality and management of records.
– Security and record ownership.
– Categorisation entity replaces Subjects which is available as a lookup on custom entities – i.e. user has read only access to category entity which is allowed on team member.
– Customer may not require much of Case Functionality.
– May give user enough basic case management depending on requirements.
– Users still have Write Access to Custom Cases, Accounts, Contacts, Activities, Notes with Team Member licence. This, in conjunction with a Case / Ticket / File / Incident custom entity may be ideal.
– Convert Activity to Case style flow can be achieved relatively easily through workflow, business process flows or web resources.
|– Starting from scratch, depending on requirements may need a lot of development.
– Diverging product set. What if a new future requirement means the native Case is more appropriate now or in the future? Will you have to refactor in the future?
– Customer may not understand the features that Case Management provides. Total cost with custom development may be more than using Case Management out of the box.
– Need to build custom reports and dashboards.
– No Knowledgebase / Contract / Entitlement Integration.
– No default Microsoft Portal configuration available.
– Need to consider effort required to build any automation to the custom Case entity.
If you have any further advantages or disadvantages, please let us know below or contact me on Twitter here : Brian Illand.