Dynamics 365 Customer Service Module Entities (Case, Queue and Queueitem Overview)

Cases:

Cases are the fundamental record type in service management and represent a single incident of any requested service. Different organizations might use different terms to refer to cases: incidents, tickets, service requests, and so on. In other words, cases are anything in the context of a customer interaction that requires some type of resolution or answer. Many cases can be associated with a single customer record at the same time. In Customer Service, customer representatives can view open and resolved cases from the customer record.

Ways of case record creation overview:

● Case can be manually created
● Case can be created from activity records like emails or phone calls might be converted to case records.
● Case can be created using automatic record creation and update rules in Dynamics 365 to automatically create cases from records like emails or social activities.
● Dynamics 365 case hierarchies and merging functionality can make it easier for organizations to manage duplicate and related cases.

Converting activity records to cases

Sometimes, a case might be the result of an activity like an email, phone call, or task. For example, a support agent might receive an email request for service directly from a customer. In these situations, you can convert activities directly to Dynamics 365 case records. The record creation and update rules in Dynamics 365 are used to automatically convert specific activities to Dynamics 365 records. This conversion can also be done manually on an individual record.

•Appointments
•Campaign Responses
•E-mails
•Faxes
•Letters
•Phone Calls
•Service Activities
•Tasks

Automatic Case Creation

Organizations often prefer that cases be created automatically in specific instances. For example, your organization might have an email alias like support@companyname.com that it uses for support requests. For any email requests that are sent to that alias, cases should be automatically created in Microsoft Dynamics 365 and associated with the customer who sent the email.

Automatic record creation and update rules in Dynamics 365 provide a foundation for consuming information from different channels, ingesting them as Dynamics 365 activities like emails or social activities, and automatically creating the appropriate Dynamics 365 records. The following image shows the basic concept.

Cases hierarchy

There may be times when multiple cases are created that are all related to the same master case. Dynamics 365 supports the ability to create parent/child cases out of the box using its case hierarchy structure. The case hierarchy feature supports three cascading closure preferences when the parent case is closed. Only one can be defined per organization.

● None: Closing the parent case does not affect child cases. Any child cases must be closed individually.
● Close all child cases when parent is closed: Will automatically close any open child cases when the parent case is closed.
● Don’t allow parent case closure until all child cases are closed: Requires that all child cases are closed before the parent case can be closed.

System administrators and customizers can configure and organizations parent/child settings in the service management area of settings and selecting parent and child case settings.

Case Merging

In some common scenarios, one or more customers might report a single case several times. For example, a customer opens a case via a web portal and reports that he can’t sign in because he has forgotten his password. Later, the same customer calls your help desk to report that he’s having sign-in issues. Because multiple cases might be opened for the same item, agent caseloads can be affected. The key performance indicators (KPIs) that the organization tracks for SLAs can also be affected.

In these scenarios, the case merging feature in Dynamics 365 can be used to combine the separate cases into one master case record.

The case merging feature in Dynamics 365 supports merges of two or more active cases. A maximum of 10 cases can be merged in a single action.

Queues: 

A queue is a place to organize and store cases that are waiting to be processed. Customers expect that their requests or issues will be handled in an organized and timely manner.

Microsoft Dynamics 365 uses queues to manage work items like cases, activities, or other record types. Several types of queues are available in Dynamics 365:
● Public: These queues are visible to the whole organization.
● Private: The queues are visible only to users who have been designated as queue members.
● Personal: These queues are associated with a specific user or team, and are visible only to that user or team.

Public and private queues are created to support an organization’s needs. By default, personal queues are automatically created when a new user or team is defined. They route important activities and records that are assigned to a specific user or team. Additional queues can also be used to support service management in a team-based collaborative environment.

● Personal: These queues are associated with a specific user or team. They’re created by the system.
● Personal queues are automatically created by the system when a user or team is added to Dynamics 365. They can’t be created manually.
● Membership in the queue can’t be edited manually. By adding and removing team members, you adjust membership for queues that are associated with a team.
● Public: All users can see and access these queues, depending on their security role.
● Users pick items from the queue. The items that a user picks are then moved to that user’s personal queue.
● Private: Access to these queues is assigned to specific users. (Members are defined on the queue record.)
● Users pick items from the queue. The items that a user picks are then moved to that user’s personal queue

Queue items
When a record like a case or an activity is routed to a queue, a separate record called a queue item is created. A queue item is a representation of the case, activity, lead, and so on, in the queue. Basically, there’s a one-to-one relationship between the queue item and the record that it’s associated with (for example, the previously mentioned case, activity, or lead). Queue items are what agents see in the queue, and they’re what agents use to select and work on specific records.

A record (for example, a case) can have a queue item in only one queue at a time. Queue items for case records can be created and put into a specific queue in multiple ways:
● Manually: The agent selects the Add to Queue or Save & Route button on the command bar.
● Add to Queue: The agent manually selects the queue to route the record to.
● Save & Route: Dynamics 365 uses predefined routing rules to evaluate details in the case and route it to an appropriate queue.
● Automatic: When a case is automatically created, Dynamics 365 automatically applies predefined routing rules to evaluate details in the case and route it to an appropriate queue.

Pick
● Assign Responsibility
● Changes ownership and can move to personal queue
● Sets Worked By
Remove
● Removes item from the queue
● Deleted the queue item record
Release
● Puts item back on queue for another agent to pick
● Changes ownership of record to owner of queue
● Clears worked by

Case Management Business Process Flow

Overall customer journey:

1. Self-assistance: When people need help, the first thing they do is go on the internet and see if they can fix the issue themselves. They’ll visit a few forums and newsgroups, and ask a few questions, hoping for a quick fix. They might visit the company’s website and do some research while looking around in the documentation.
2. Initial case creation and routing: Cases will be generated from multiple channels. They can then be routed to specific queues, based on factors like whether there’s a contract, whether the customer is a preferred customer, or whether a technician who’s qualified to handle the issue is available on a specific queue.
3. Case management and resolution: A service agent will now track all communication with the customer and follow a dedicated case resolution process while using an internal knowledge base. At this point, customer communication can be through email, text messages, or a phone call. Cases are typically tracked to create a historical log of what happened with the customer. The Knowledge Base will also be built out, so that other service representatives can take advantage of knowledge from past
   cases.
4. Post-case activities: Customer service organizations are paying more and more attention to what they do after a case is resolved. These post-case activities are now seen as critical. Companies now want to get feedback from customers about the quality of the interaction, as a way to keep channels open and encourage the customer to stay with the company. To gain more insights from the case and further build out their knowledge base, companies might send customers a survey with specifics of the case.

Hope this blog post given some idea about Dynamics 365 Service Module (Case, Queue and Queueitem Overview). I have shared from my point of view & as per my product knowledge. Happy to hear from others if I have missed anything.