Case v Custom Entity Part 1 – Lets Fight

“Should I create a custom entity or should I re-use an out-of-the-box entity to deliver a requirement?”

How often do you have to decide when and how to use a custom entity instead of modifying and customising an out-of-the-box entity? In my experience, in every Dynamics 365 implementation you are presented with this dilemma.

There is no direct, fault-proof, straight-forward answer to this, it will obviously depend on the requirement and scenario. Usually what dictates whether or not you should use a specific out of the box entity versus a brand new custom entity are the features it provides, also considering the effort to implement them from scratch, and the time spent removing unnecessary components and features that are available by default.

In Part One of this series, we will look in detail at 10 features that the Case entity provides from a technical and functional standpoint. We will also look at how similar functionality might be implemented with a custom entity.

Part Two of this series will then provide a comparison and matrix of the functionality provided by cases and custom entities to help you make your decision. We will look at the generic features common across all Dynamics 365 entities, with an overview of some of the licensing considerations you need to keep in mind if you are creating your own custom entity.

1. Generic Features

Case Entity Functionality

The following out-of-the-box components are made available:

  • Fields;
  • Forms;
  • Business Process Flows;
  • Views;
  • Charts;
  • Reports;
  • Security Roles;
  • Dashboards.

 

Despite the fact that these components can be modified and (in some cases) deleted or made hidden, sometimes it is more time consuming to perform these actions instead of actually create a new entity from scratch.

Custom Entity Functionality

From a technical standpoint, you will need to create a new entity from scratch with all the forms, fields, business process flows, dashboards and whatever other components you need.

2. Routing Rule Sets

Case Entity Functionality

It can be useful for an organisation to manage incoming case emails in CRM based on the content or level of service offered to their customers. Out-of-the-box it is possible to configure “Routing Rules” against the Case entity to push cases to the correct queues using a combination of workflow processes and routing rules.

By using routing rules, CRM cases are directed to the right teams and individuals to ensure prompt attention that shortens resolution times and improves service delivery. Advanced rules can be configured to precisely control the automated routing of cases using the built-in Record Creation and Update Rules feature without any need for additional coding.

However, sometimes there is the need to create additional workflows as the “Routing Rules” functionality only routes cases automatically when these are created either by Automatic Case Creation Rules or by Workflows. Routing Rules are applied to Manually Created cases by clicking the Apply Routing Rules button.

Equivalent Custom Entity Effort

Create the following components to support both configuration and execution:

  • Workflows;
  • Plugins;
  • Entities;
  • Buttons;
  • Web-Resources (Configuration).

Alternatively, this link below describes a simplistic approach on how to implement a workflow to assign and route case records based on conditions.

3. Automatic Record Creation and Update Rules

Case Entity Functionality

This feature allows users to use multiple activity types (Appointment, Email, Phone call, Task, Service and Custom activities) to create or update records automatically. Rules can create multiple CRM records from one activity type and increase the efficiency of automatic record creation. Automatic record creation or update eliminates the need of manually writing any code.

While creating a rule, you need to define the conditions to create or update records into the system. You can also define post record creation or update actions. To enable the rule to update records, you must add an update step to the rule. You can collect additional information for the activity record by defining some channel properties while creating a rule. This requires a use of JSON parameter attribute from activity.

Once all rule creation/configuration is done, you will need to activate the rule which creates an out of the box workflow. The rule is able to read the incoming source activity data and to create or update records in Dynamics 365.

Similarly, to all other CRM components or Web resources, rules can be added to the CRM solution and can be exported and imported to other Dynamics 365 organizations.

However, in spite of the fact that this functionality is not limited to cases, some of is features actually are (image below).

Custom Entity Effort

Create the following components to support both configuration and execution:

  • Plugins;
  • Workflows;

4. Parent and Child Case Settings

Case Entity Functionality

With this feature it is possible to track multiple issues for a customer, or track the same issue that’s affecting multiple customers, using parent and child cases. The primary case or issue is called the “parent case”. Any related cases are called a “child cases”.

For example, it is possible to track a case where work needs to be done by other departments.

To use this feature, it is required to set up a few rules about how information will be inherited.

Custom Entity Effort

Create the following components to support both configuration and execution:

  • Plugins;
  • Workflows;
  • Web-Resource;
  • Entity.
  • Link custom entities using relationship or the custom Connection type
  • Surface related cases through the use of CRM Dashboards.

5. Create Child Case/Associate Child Cases

Case Entity Functionality

Out-of-the-box it is possible to manage multiple cases more efficiently by using parent and child cases in Microsoft Dynamics 365. When there is the need to track a case where work needs to be done by other departments or when there is the need to track the same issue for multiple customers, it is possible to open a primary case called the parent case, and then create secondary cases called child cases.

For example, if there is a new service request to install new electrical and gas connections, this requires work to be done separately by the gas and electric department. In this situation, it is possible to open two child cases, one for the gas and the other for the electric department. The original case is marked as the parent case. Once the child cases are resolved, it is then possible to close the parent case.

Similarly, parent and child cases can also be created when multiple customers call in about the same issue (i.e. a network outage). Instead of creating a new case for each customer, a parent case can be created to track the main network outage with the Network Operations team, and then create child cases when customers call in about the issue.

The Create Child Case and Associate Child Cases buttons are available from the Case entity ribbon.

Custom Entity Effort

Create the following components to support both configuration and execution:

  • Plugins;
  • Workflows;
  • Web-Resource;
  • Ribbon Configuration
  • Link custom entities using relationships or the custom Unity Connection type.
  • Surface related cases using CRM Dashboards.

6. Merge Similar Cases

Case Entity Functionality

Out-of-the-box it is possible to eliminate redundancies between similar cases in Microsoft Dynamics 365 by merging them into one case. When a customer opens multiple cases about the same issue (through different support channels), or when multiple customers from the same account call in about the same issue, it is possible to merge those cases into one case so everything is visible in one place.

For example, when a customer or multiple customers from the same account submit a case on the web and also call in about the same issue, it is possible to merge the cases into one case instead of keeping track of multiple cases.

When a case is merged, the state of the case is changed to Cancelled, and the status is changed to Merged. This is because it is merged into another case and all of the open case activities, emails, and attachments are now associated with the case it was merged into. By default, it is possible to merge up to 10 cases at a time.

A few things to remember merging cases with parent and child relationships:

  • When merging a case that has child cases, those child cases become child cases of the parent case they were merged into.
  • It is only possible to merge a child case into another child case if both of the child cases have the same parent case.

The Merge Case button can be found on the Case ribbon.

Custom Entity Effort

Create the following components to support both configuration and execution:

  • Plugins;
  • Workflows;
  • Web-Resource;
  • Ribbon Configuration.

Note that the out of the box merge functionality cannot be used on custom entities.

7. Entitlements

Case Entity Functionality

Entitlements allow the user to specify and control the amount and type of support a customer is entitled to receive.

It is possible to specify the amount of support in terms of support hours or number of cases. There is also the ability to restrict entitlements based on specific conditions, such as limiting support to a specific product or list of products, or also by limiting support with contact(s) or person(s) of an entitlement customer who is responsible to open a case.

Each Entitlement record includes four key fields:

  • Allocation Type
    • Defining if the entitlement is based on the number of cases or hours consumed by the customer.
  • Decrease Remaining On
    • Case Resolution: The total number of Entitlement terms is decreased when a case is closed
    • Case Creation: Or, the number of Entitlement terms is decreased when a case is created 3.
  • Total Terms
    • This represents total terms which have been purchased by any customer.
    • For example, if 15 is entered in this field it will reflect either 15 cases or 15 hours depending on the allocation type selected.
  • Remaining Terms
    • This is a running total that is automatically calculated by Dynamics CRM which shows the remaining resource available for the customer.

Out-of-the-box Entitlements are also used to leverage the SLA functionalities. This means that Entitlements can also be associated with SLA’s to support multiple SLA patterns.

By default, it is only possible to have one default SLA, so if there is the requirement to operate different SLAs for different customers then entitlements are probably needed.

Entitlements are also needed if there is the requirement to restrict the amount of service offered to someone. For example, if the creation of cases for telephone support is only allowed for up to a maximum of 20 hours in the first three months.

Custom Entity Effort

Create the following components to support both configuration and execution:

  • Plugins;
  • Workflows;
  • Web-Resource;
  • Ribbon Configuration;

8. Resolve Case and Cancel Case

Case Entity Functionality

Both Resolve Case and Cancel Case buttons can be found on the Case ribbon.

When resolving a case, the system performs the following:

  • When the information in the resolve case dialog box is complete an activity is created for the case, but the status is resolved. This is used to track the resolution;
  • Microsoft Dynamics CRM sets the case as resolved, and the record becomes read-only;
  • The case status changes to Resolved;
  • The case is moved from the user’s “In Progress” queue and is no longer available in the Active Cases view.

The information recorded in the resolved case dialog box is saved with the resolution activity for the case.

Cancelling a case does not create a resolution activity, but it does perform the following:

  • Marks the case record as read-only;
  • Changes the status to Cancelled;
  • Removes the case from the user’s My Work queue.

A cancelled and resolved case can be reactivated at any time.

Custom Entity Effort

Create the following components to support both configuration and execution:

  • Plugins;
  • Workflows;
  • Web-Resource;
  • Ribbon Configuration;

9. Reactivate Case

Case Entity Functionality

The Reactivate Case button can be found on the Case ribbon. Any resolved or cancelled case can be reactivated.

When a resolved case is reactivated, the status of the most recent closed resolution activity is changed to cancelled. Also, when a case is reactivated and then resolved again, the total time for the case calculates differently depending on whether the case has a contract/entitlement related to it or not.

Custom Entity Functionality

Create the following components to support both configuration and execution:

  • Plugins;
  • Workflows;
  • Web-Resource;
  • Ribbon Configuration;
  • Entities.

10. Case Resolution Entity

Case Entity Functionality

An incident resolution (case resolution) is a special type of activity that is created when an incident is closed.

It includes the description of the resolution, billing status, and the duration of the case.

Custom Entity Functionality

Create the following components to support both configuration and execution:

  • Workflows;
  • Plugins;
  • Entities;
  • Web-Resources.

Summary

Hopefully you have a better understanding of some of the native features provided by cases. In addition to the above, Microsoft have promised us some new features for Case in Version 9.0.

  • Business Process Flows
    • Floating and docked mode for stages
    • Work with BPF steps, with full view of case details
    • Automate contextual process stage actions. E.g. sending an email
  • Timeline
    • Unified view of Posts, Activities and Notes
    • See new activities, unread emails under What’s New Section
    • Intuitive filtering for activities

In Part 2 we will have a look at some of the other Dynamics 365 features you need to consider when deciding on a case versus a custom entity and give you some more technical guidance as well as identifying licensing considerations.

If you have any further advantages or disadvantages, please let us know below or contact me on LinkedIn here : Hugo Goncalves

About Functional Hero: Howard 'Maximiser' Harper

The Functional Hero of the Dynamics 365 Heroes team. The true guru of the team, I have been involved with the product since its inception back in 2003. I maximise the product’s functionality without the need to write a line of code and am proud of my ingenious solutions to meet even the most challenging customer requirements. With contacts in the Dynamics 365 product vision team at Microsoft, you can be sure I can configure the platform to its utmost potential. I take great delight at reigning in Dimitri from “re-inventing the wheel”.

1 Response

Leave a Reply