Search For Case Records (Episode 14)

Posted on December 24, 2019 by Paresh Sharma

There are three ways to search case records within Dynamics 365:

  1. Quick Search
  2. Global Search
  3. Advanced Find

In Customer Service Hub, open Cases. The following screenshot shows the three ways of searching:

For Quick Search

  • Search for records, say “Product”. Irrespective of the view selected, the system will display a search result with list of all the records that being with the search term. In this example it shows all the case titles that begin with the term “Product”.

  • There may be instances where the case tile may not begin with the term you are looking for. In such cases you can use wild card characters, for example: *product*. In this example the system will populate a search result with all the case titles that has the term “product” in it,

For Global Search

  • Type the search criteria in the global search, for example: “Adventure”. You can use wild card characters as well, such as “*Adv*”.
  • The system will look into all the entities and display categorized search results as shown below. You can also apply filters to show the results for a particular entity.

For Advance Find

  • Click on the funnel icon to open the Advance Find.
  • Here you can create a simple or complex query, edit columns, provide filtering criteria and click on Results to see the result based on your query.
  • You can also save the query as your personal view.
  • So for example:
    • Use an existing view, say Active Cases.
    • Click on Details to change the filters.
    • Select a filter: Case Title Contains *adv*.
    • Select the filter lines and group them as OR.
    • Click Results.

You can also use filter on the columns in a view as well:

  • Open an existing view. Say, “All Cases”
  • Click on the filter icon beside a column header.
  • You can apply filtering criteria for each column. You can also apply filters on multiple columns at a time.
  • Click Apply to see the result.

Posted in D365 Customer Engagement (CRM), D365 Customer Service, Microsoft Dynamics 365 | Tagged , , , , , , | Comments Off on Search For Case Records (Episode 14)

Manage Case List and Views (Episode 13)

Posted on December 23, 2019 by Paresh Sharma

A Case is a single incident of service raised by the customer. It can be an issue, query or a feedback. The customer service representative will work on this incident and try resolving the case.

A Customer (Account or Contact) can raise multiple cases in Dynamics 365. There is no limit on how many cases can be raised. However, there might be restrictions based on Service Level Agreements (SLA) signed with the service provider. These cases can have different statuses as well.

Views allow users to see multiple cases at the same time (active cases, my cases, closed cases, etc.)

Let’s have a look in Dynamics 365:

  • Open Customer Service Hub in Dynamics 365.

  • Click Cases in the Navigation bar.

  • This page shows the cases as per the view selected. For example, the current view show “My Active Cases”, i.e. all the cases assigned to the user currently logged in.

  • Similarly there are many other views which can be useful in you day to day activity. You can also Pin the view to be you default view when you open the Case list.

  • Note that each View has different filtering criteria and can have different number of columns relevant to the view.
Posted in D365 Customer Engagement (CRM), D365 Customer Service, Microsoft Dynamics 365 | Tagged , , , | Comments Off on Manage Case List and Views (Episode 13)

Case Management Process Flow (Episode 12)

Posted on December 22, 2019 by Paresh Sharma

We are going to discuss the default out of the box case process flow that is there is Dynamics 365, however, you can also add new steps and change the process according to the customer needs.

Following is the flow:

  • A case starts when a customer raises an issue or asks a question or sends a feedback. Now this can happen outside Dynamics 365 either manually or they could use Customer Service Portal to log the case.
  • A case is created when customer calls a customer service representative or sends an email, or the case can be created automatically by when the customer logs the case via customer service portal. When the case is created, the status of the case is set to Active.
  • The next step is to assign the case to the relevant person. The cases can be assigned manually to relevant customer service agent or automatically using the Case Routing Rules. So, the objective is to assign the case to a customer service agent who can resolve the case. The status of the case is still Active.
  • The next step is research, where the customer service agent may call the customer or send an email or ask for more information to really understand the issue. Many a times when customer raises an issue it may not be clear and the customer service agent may need more information, or do internal research, to give the real solution to the customer. The status of the case is still Active.
  • Next the case can be resolved once the research is done and the issue is solved, or the question is answered, or the feedback is taken and noted. The case is closed, and the status is set to Resolved.
  • The other possibility (from Research stage) is that the cases was resolved by customer themselves and it is no longer required for the customer service agent to work on it then the case can be cancelled. The status is set to cancelled.
  • If required, you can reactivate the case from the resolved or cancelled status. The status of the case is set to Active.
Posted in D365 Customer Engagement (CRM), D365 Customer Service, Microsoft Dynamics 365 | Tagged , , , | Comments Off on Case Management Process Flow (Episode 12)

Important Terms in Customer Service for Dynamics 365 (Episode 11)

Posted on December 21, 2019 by Paresh Sharma

Overview

Customer Service Hub for Dynamics 365 can be utilized for:

  • Solving Issues
    • When a customer raises an issue, this module can be used to resolve those issues.
    • The customer may or may not have a service contract with you.
  • Answering Questions
    • When a customer has any doubts or questions about the purchased product/service.
    • This module can be used to send information and answering customer’s questions.
  • Feedback Analysis
    • When customer provides any feedback about your product/services.
    • This module can be used to capture feedback and improve your products/services.

Understanding Core Records

The following terms are essential for you to get acquainted with, before you can work with Customer Service Hub for Dynamics 365:

  1. Accounts

    An Account is an Organization. This includes:

  • Customer
  • Vendor
  • Partner
  • Affiliate or Other
  1. Contacts

    A contact is an individual:

  • Associated with maximum one Account (through contact form)
  1. Cases

    A case represents a single incident. A case can be:

  • An Issue
  • A Query
  • A Feedback
  • Activities
    • Activities are the interactions between customers and the business.
    • Activities are based on incidents.
    • Every activity should be resolved in order to close any incident.
  • Queues
    • Queues are the place or location where activities and cases are stored to be processed.
    • Queues are created based on users and teams.
  • KB Articles
    • KB Articles stand for Knowledge Based Articles.
    • These are Information Articles Repository to help resolve cases.
    • Used by the support users / service engineers.
  • SLA
    • SLA stands for Service Level Agreements.
    • SLA explains the level of service offer to customers.
    • Define Metrics and KPI (Key Performance Indicators) to attain service levels.
  • Subject Tree
    • Subject Tree helps you categorize Service Cases, KB Articles, Product Catalog Items, Sales Literature.
    • Makes it easy for users to search and use information to resolve cases.
Posted in D365 Customer Engagement (CRM), D365 Customer Service, Microsoft Dynamics 365 | Tagged , , , , | Comments Off on Important Terms in Customer Service for Dynamics 365 (Episode 11)

Work With Status Reason Transitions (Episode 10)

Posted on October 10, 2019 by Paresh Sharma

<–Previous Episode

The status of a record helps identify where the record is in a specific process. For example, if you’re currently working on a case in the system, the case is considered to have a status of Active. After the case is closed, it can be set to a status of Resolved. These statuses make it easier to sort, filter, and query specific records in the system.

Out of the box, specific statuses are available for each Dynamics 365 record, depending on the type of record. Cases have three statuses that they can be in:

  • Active: The case is currently open and is actively being worked on in the application.
  • Resolved: The issue for the case has been fixed.
  • Cancelled: The case is no longer active in the system, but it wasn’t resolved.

You can’t change the statuses that are available for a specific record type. But it’s often important to have more specific information about the status of a record. For example, a case might be active in the system, but what exactly is being done on the case? Is the agent researching the problem? Is the agent waiting for the customer to provide more information? Knowing these details can be critical to effective service delivery.

Each record type has what’s called a status reason. A status reason is associated with a specific record status and provides more information about why the record is in that status. For cases in Dynamics 365, several status reasons are available out of the box:

Active:

  • In Progress: The case is currently being worked on by a customer service agent.
  • On Hold: The case is active, but it isn’t currently being worked on.
  • Waiting for Details: The case is active, but you’re waiting for more information from the customer.
  • Researching: The case is currently being researched.

Resolved:

  • Problem Solved: A successful resolution was found for the case.
  • Information Provided: The customer was given satisfactory information, and the issue was fixed.

Cancelled:

  • Cancelled: The case was cancelled.
  • Merged: The case was cancelled because it was merged with another record.

You can add, remove, or change case status reasons as needed by going to Customizations > Cases > Fields and selecting the drop-down arrow in the Status Reason field. Multiple status reasons are available for each status, and they can be changed.

Status Reason Transitions

Often, organizations have a specific process that they follow to resolve cases. Case statuses and status reasons might play a role in that process. To help organizations more clearly define and enforce those processes, Dynamics 365 lets them create customer status reason transition paths.

Status reason transitions add an additional level of filtering to define a specific list of status reasons that can be selected for a specific status reason. For example, when a case has a status reason of Waiting for Details, it’s technically already on hold. Therefore, letting a technician change the status reason to On Hold is redundant. Additionally, On Hold just might not be the best status reason to transition to. By using status reason transitions, you can define the specific transitions that an agent can go to from the Waiting for Details status reason.

The following image shows an example.

As you can see, when a case has a status reason of Waiting for Details, the only transition options are:

  • Cancelled
  • Service Escalated
  • Researching
  • In Progress

For each of those status reasons, in turn, multiple transitions can be selected. Therefore, status reason transitions make it easier for organizations to help guarantee that agents use only valid reasons, based on the current status reason.

Status reason transitions are available only on the case entity and custom entities. You can change them by selecting the Edit Status Reason Transitions button on the status reason field customization page. After you turn on the status reason transitions feature, you define the specific status reasons that are available.

Status Reason Transitions

When you define reason options for an active status reason, there must be at least one path to an inactive status. For example, if a case has a status reason of In Progress, it must be possible to transition to at least one of the following status reasons: Cancelled, Merged, Problem Solved, or Information Provided. If at least one path to an inactive status isn’t provided, you won’t be able to save the new transitions.

After the transitions are saved and published, agents will see the changes reflected in the application.
For more about status reason transitions, see Define status reason transitions for the Case or custom entities.

Posted in D365 Customer Engagement (CRM), D365 Customer Service, Microsoft Dynamics 365 | Tagged , , , | 1 Comment

Case Management Work With Cases Scenarios (Episode 09)

Posted on October 9, 2019 by Paresh Sharma

<–Previous Episode

Let’s see how case management features can be used to resolve a case that a customer has submitted.

Nancy Anderson is a customer who works for a company named Adventure Works. She calls a central dispatcher to report an issue that the company is having.

The dispatcher creates a phone call activity for the issue in Dynamics 365.

A customer support agent opens the phone call and converts it to a new case in Dynamics 365.

NOTE: Because the case started as a phone call, the Phone to Case business process flow is triggered. This flow which consists of three stages: Identify, Research, and Resolve.

Identify: The agent identifies the issue and relevant information.

  • The agent calls Nancy, who reported the issue, and identifies information like the customer, contact, and issue.
  • A phone call activity is created that describes what was done and how long the agent was on the phone with Nancy (15 minutes in this example).
  • The case is advanced to the next stage.

Research: The agent researches the issue and tries to find a resolution.

  • The agent spends 30 minutes researching and working on Nancy’s issue.
  • The agent finds a resolution to the issue in a knowledge article in the knowledge base.
  • The agent emails the article to Nancy and links it to the case as the resolution.
  • A task is created that describes what was done and how long it took (30 minutes total in this example).

Resolve: The agent closes the case as resolved.

  • The agent calls Nancy to make sure that the proposed resolution fixed the issue. The agent spends 15 minutes on the phone with her.
  • The case is closed as resolved.
  • The total time for all activities is rolled up to reflect how much time was spent on the issue (one hour total in this example).

For more about the Customer Service Hub application, see User Guide (Customer Service Hub).

For more about case activities, see Add an activity to a case.

Parent/Child Cases

Occasionally, multiple cases might be created that are all related to the same master case. Out of the box, Dynamics 365 lets you create parent/child cases by using its case hierarchy structure. For example, you work for a software company that just released an update to one of its software applications. But the update has a bug. Because many different customers might call in to report the issue, multiple cases might be created. By using case hierarchies, you can associate all the reported cases with a single master case. When the bug is fixed in the master (parent) case, all the child cases can also be resolved and closed at the same time.

The following image shows some examples of how case hierarchies can be used in a customer support organization:

Important Case Hierarchy Information

  • No more than 100 child cases can be associated with a single master (parent) case. If you need more than 100 child cases, you might have to manually create a custom case hierarchy.
  • Only one level of hierarchy is supported.
    • Case field mappings can be created to automatically fill in the fields in child case records.
    • The mapping applies only when a child case record is created in the context of a parent case.
    • Case field mappings don’t keep records synced.
  • The case hierarchy feature supports three cascading closure options when a parent case is closed.

NOTE:

Only one option can be defined per organization.

  • None: Closing the parent case has no effect on child cases. Child cases must be closed individually.
  • Close all child cases when parent is closed: Any open child cases are automatically closed when the parent case is closed.
  • Don’t allow parent case closure until all child cases are closed: All child cases must be closed before the parent case can be closed.

System admins/customizers can specify an organization’s settings for parent/child cases by going to Settings > Service management and selecting the parent and child case settings.

For more about parent and child cases, see Create and manage parent and child cases.

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 following image shows some potential use cases for this feature.

Additional Considerations for Case Merging

  • 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.
  • One case can be marked as the primary case.
    • The primary case will be active.
    • All other cases will be cancelled.
    • All activities, notes, and attachments that are associated with all cases in the merge will be re-parented to the primary case.
  • After cases are merged, the merge can’t be undone.

The ability to merge up to 10 cases is available only through the user interface (UI). Developers who need to merge cases programmatically must use the same merge software development kit (SDK) message that’s available for account and contact merges.

For more about case merging, see Merge similar cases.

Posted in D365 Customer Engagement (CRM), D365 Customer Service, Microsoft Dynamics 365 | Tagged , , | Comments Off on Case Management Work With Cases Scenarios (Episode 09)

Case Management Dashboard Scenario (Episode 08)

Posted on October 8, 2019 by Paresh Sharma

<–Previous Episode

Dashboards make it easier for users to consume and work with data. For example, a support agent may need to access cases in multiple queues such as gold and silver support queues. That same agent also needs to see the cases assigned to them, and the activities they need to complete. That is four potentially different areas of the application that they may need to go to. However, with a single dashboard the agent can easily see and interact with the data from all four of those locations without ever needing to leave the screen.

There are two types of interactive dashboards available:

  • Multi-Stream Dashboards
  • Single-Stream Dashboards

Multi-Stream Dashboard: A multi-stream dashboard displays real-time data over multiple data streams. A data stream is based on an entity view or a queue, such as My Activities, My Cases, or Cases in the Banking Queue. A stream always contains information about only one entity, however stream on the dashboard may contain information about a different entity.

For example, you may want to track both cases and accounts in a central location. Since a stream can only contain data from one entity, you cannot track both in a single stream. You can however, track cases in one stream and accounts in another stream. Both streams could be displayed on the dashboard.

A multi-stream dashboard could also be configured to display streams based on the same entity as well. For example, you could have a dashboard that contains one stream displaying an agent’s active cases, and another the contains cases opened this week. Out of the box, Customer Service Hub contains a multi-stream dashboard called the

Tier 1 dashboard.

Single-Stream Dashboard: Single-stream dashboards display real-time data over one stream based on a view or queue for example Active Cases. All the charts on the dashboard are associated with the data stream. Additionally, a single-stream dashboard contains tiles. The tiles are positioned on the right side of the dashboard and are always shown. Single-stream dashboards are useful to users who need to monitor fewer, but more complex or escalated cases in a single view or queue. Out of the box Customer Service hub contains a single-stream dashboard called the Tier 2 dashboard.

Tier 1 dashboard

The Tier 1 dashboard provides several “streams” that let you work with cases and related items, like activities or email. By using visual filters, you can show interactive charts that let you filter a case based on specific criteria. In this way, you can find the most appropriate cases for agents to work on.

Date filters let you change the date range of information that agents view. There are several predefined ranges to choose from, and you can also define custom ranges.

Tier 2 dashboard

When agents want to dive deeper into cases, they can use the Tier 2 dashboard. Instead of showing multiple streams that might be for multiple entities, it shows a single stream that’s based on active cases. It also includes multiple tiles and interactive charts for working with case data.

As on the Tier 1 dashboard, the charts can be used as interactive filters to dive into specific types of cases. Additionally, interactive tiles group together relevant data that’s associated with cases. You can use the tiles to view the specific records that are included in the tiles.

Entity-specific dashboards

Another feature of the Customer Service Hub is the ability to work with entity specific dashboards. Entity specific dashboards are just what the name describes. They are multi-stream dashboards display data streams related to a single entity such as cases.

When agents navigate to the case entity they will see a list of their active cases. On the command bar there is an option to open dashboards. This will open the case dashboard. From within the case dashboard, agents can select the Show Visual Filter button to display the case visual filter to filter the case data. This lets them perform more specific items that will assist in identifying appropriate cases to work with. Agents can toggle back to the entity list view at any time, by selecting the Open Views button on the dashboard.

Posted in D365 Customer Engagement (CRM), D365 Customer Service, Microsoft Dynamics 365 | Tagged , , , , , | Comments Off on Case Management Dashboard Scenario (Episode 08)

Case Management Scenarios (Episode 07)

Posted on October 7, 2019 by Paresh Sharma

<–Previous Episode

When agents are working on customer issues, it is important that they have all the necessary tools they need to resolve the issue from a single location. Not only does not having this information greatly impact the overall efficiency of an agent, but it can also be frustrating to a customer who needs to wait as the agent bounces around to different areas to get what they need. Providing agents what they need directly from the case they are working on is the most effective way to ensure that agents have the tools they need.

This might include providing the agent access to the following: – A list of tasks they need to be accomplished before the case can be resolved. – Access to the organizations knowledge base to assist in resolving the issue. – A complete contextual history of what has been done on the case.

Access to other similar issues that could be used to assist in the resolution process.

From within the case form they can see general case information such as the case title, customer, related SLA details, related case activities and other related data. Some of the key pieces of information agents can work with include:

  • Timeline: Displays related case activities. Depending on an organizations service model, many organizations track the total time that agents spend on activities associated with a case to determine how much time to bill back to the customer.
    • For example, if an agent placed 3 phone calls to a customer with each of the phone calls lasting 15 minutes, they might bill back a total of 45 minutes to the customer.
  • Related: The related section displays related information that might be either related to the case (such as a knowledge article) or related to the customer that the case is associated with (such as related support contracts, or related cases).
    • Each related item type has a corresponding icon displayed in the related panel that makes it easier to switch between the related items.
  • Business Process Flows: These represent guided processes that are used to guide service agents to a complete case resolution.
    • The case entity might have multiple business process available that can be switched to depending on specific details in the case such as the case type, origin, or other business factors.

Posted in D365 Customer Engagement (CRM), D365 Customer Service, Microsoft Dynamics 365 | Tagged , , | Comments Off on Case Management Scenarios (Episode 07)

Considerations for Case Creation Automation (Episode-06)

Posted on October 6, 2019 by Paresh Sharma

<–Previous Episode

Organizations often prefer that cases be created automatically in specific instances. For example, your organization might have an email alias like [email protected] 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.

You can access automatic record creation and update rules from Settings > Service Management in Dynamics 365. When you create a rule, you must define an activity source type for it. Out of the box, the following types of Dynamics 365 activities can be converted to cases:

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

Any custom activities that are created for an organization can also be converted by using the creation rules.

In addition to defining the source type, you can define a specific queue that the rule will monitor for items of that type. Therefore, you can define multiple rules for a single source type like email, but each rule can monitor a different queue.

Although you can create multiple rules for a single source type, it’s important to remember that you can have only one active rule for the same source type and queue at any time.

For example, for a queue named Support, you’ve defined an active rule named Email to Case that has a source type of E-mails. If you create another rule named Email to Case 2 that also has a source type of E-mails, the Email to Case rule will be inactivated when you try to activate the Email to Case 2 rule.

The same thing occurs if you have two rules that aren’t associated with any specific queue but that have the same source type. Be aware of this behaviour as you design rules.

Depending on the source type, additional conditions can be changed to determine when a record will be created. Here are the options when the source type is set to E-mails:

  • Create records for email from unknown senders: Cases that come from email addresses that aren’t attached to a Dynamics 365 account or contact can be created automatically.
  • Create case if a valid entitlement exists for the customer: A valid entitlement record must exist for the customer who sent the email. This condition doesn’t check the specifics of the entitlement. It only checks that an entitlement exists. If a customer has multiple entitlements, a record will be created.
  • Create cases for activities associated with a resolved case: This condition checks whether the email is related to a recently resolved case, and whether it should be treated as a new case.

This list represents just the options that are available for emails. We recommend that you check out the options that are available for other activity types, like Social Activities. There’s also an option to define additional channel properties. This option can be helpful when you want to extract additional details from something like a social media post and use those details to fill in fields in the newly created record.

After you’ve defined the specifics of the rule, you must save it before you can define the creation and update details. The details are the actual rules that are evaluated and applied, based on information in the activity that’s received. Multiple rule items can be defined for a single rule.

For example, an Email to Case rule might have the following three rule items:

  • Rule item 1: Check whether the sender’s account in Dynamics 365 is a gold customer. If it is, create a gold-level service case for the customer that has an origin of Email.
  • Rule item 2: Check whether the sender’s account in Dynamics 365 is a silver customer. If it is, create a silver-level service case for the customer that has an origin of Email.
  • Rule item 3: Create a case that no service level is defined for and that has an origin of Email.

Each rule item consists of conditions and actions. You must supply a name for the rule item and save it before the conditions and actions will be available.

Conditions

Conditions can evaluate specific contents in the activity that’s being converted to a Dynamics 365 record, or in records that are related to it. For example, a condition might specify that the account or contact record that’s associated with the sender of the email should be looked at. The condition can then check whether the account’s service level field (Custom Field) is set to Gold. This functionality provides more flexibility, because relevant data from Dynamics 365 can also be used as criteria, in addition to the contents of the emails.

Multiple items can be specified in a single condition, and condition items can be specified as either AND or OR conditions.

Actions

Actions have two sections. The first section just lets you create new records. This section is used in most instances where a case should be created. The second section lets you create a record, update a record, send an email, or start a child workflow. This section can be helpful when you want to facilitate additional actions after the initial case is created. These actions include updating information on the account record that the case is related to or starting a workflow that routes the case to a queue.

When records are created, you can dynamically fill in the information in the record, based on content from other records.

How Rule Items Are Applied

Rule items are checked in the order that’s defined in the rule. After the rule finds a matching rule item, it applies that rule item and stops checking for additional matches. You can control the order that rule items are checked in. Therefore, it’s best to put the most specific rules first and work your way down from there.

After a rule is activated, it starts defining cases for email activities that are sent to a specific queue.

For more about automatic record creation and update rules, see Set up rules to automatically create or update records.

Posted in D365 Customer Engagement (CRM), D365 Customer Service, Microsoft Dynamics 365 | Tagged , , , , , | Comments Off on Considerations for Case Creation Automation (Episode-06)

Case Creation & Lifecycle (Episode – 05)

Posted on October 5, 2019 by Paresh Sharma

<–Previous Episode

Cases can be created in multiple ways in Microsoft Dynamics 365, to accommodate the different scenarios that your organization might receive cases from. For example, cases can be created automatically, based on a social media interaction, or agents can create them manually as they take a call from someone. They can even be created through a self-service portal. When you implement a case management strategy, it’s important to consider all the scenarios that your organization might support.

In Dynamics 365, cases can be captured and entered into the system in several ways, depending on the organization’s specific needs (for example, through a self-service portal). Most often, though, cases are created manually or by converting an activity.

Manual Case Creation

In many instances, cases must be manually entered by a service agent. As the agent enters the case, he or she captures relevant information, like the customer, point of contact, issue, and so on. There are two primary ways to manually create cases.

Case Page

The Case page is the most commonly used method for entering cases into Dynamics 365. As a case is entered, the agent who’s entering it specifies details about the case, like the case title, customer, case origin, and so on.

The Case page has all the fields that are available for the case and provides quick access to related records, like knowledge articles. The Case page also provides access to the active business process flow that the case uses. Many items (for example, the timeline) and access to related records aren’t available until the case has been saved for the first time.

The case title and customer fields are required, and must be filled in before a case record can be saved.

Quick Create : Case Dialog

The Quick Create: Case dialog box is a trimmed-down version of the Case page. It has only the most important fields for the case entity. This dialog box is used to quickly enter case information, to save time. You also use this dialog box when you’re creating a case in the context of another record. For example, if you add a case directly from an account in Dynamics 365, you’ll use the Quick Create: Case dialog box.

Quick Create dialog boxes can be accessed from the top navigation bar in the application, or from the related panel or an attached sub-grid on a parent record. Although a Quick Create dialog box isn’t available by default for every entity, it’s available for the case entity. Therefore, when you add a case from a related record, you use the Quick Create: Case dialog box.

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.

Out of the box, the following types of Dynamics 365 activities can be converted to cases:

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

Any custom activities that are created for an organization can also be converted to cases. For example, an organization might create a custom activity named SMS messages that’s used to work with text messages. These activities can also be converted to cases.

From within a specific activity, select the Convert To button on the command bar. You can then select whether to convert the activity to an opportunity or a case.

After you select To Case, the Convert to Case page appears. This page provides more information and lets you do things like close the activity as finished.

Channel Considerations

Because so many avenues are available for customer interaction, organizations are providing more and more channels that customers can submit support cases from. The channel that a case is submitted from can influence how the case is routed or which customer support contract the case is applied to. Because this information can be critical, Dynamics 365 lets you select, directly on the case record, the specific channel that a case was received from.

Out of the box, Dynamics 365 includes the Phone, Email, Web, Facebook, and Twitter channels, as shown in the image. But because most organizations have different channel needs, more channels can be added.

Posted in D365 Customer Engagement (CRM), D365 Customer Service, Microsoft Dynamics 365 | Tagged , , | Comments Off on Case Creation & Lifecycle (Episode – 05)