Case Management in D365 for Finance and Operations: Part 1
Posted on: September 13, 2018 | By: Jarrod Kraemer | Microsoft Dynamics AX/365
Authored by: Kevin Gallagher
Overview
Case Management within D365 is a seldom used module which could provide value for your business if used correctly. Ongoing events that cover multiple days or weeks work best to be handled by cases, especially events that have multiple steps handled by various departments of an organization. Events like customer returns, customer claims, quality control, collections, and internal investigations are just a few examples of scattered business events that can be dealt with on a systematic level using cases.
Case Categories
(Organization Administration>Setup>Cases>Case Categories)
When designing a case hierarchy for your business, the first step is determining how each business process will fall into Case Categories. Think of Case Categories as a tiered structure in which your ad hoc business processes can be centralized. As shown, my case categories are broken down at the highest level into 3 categories: General, Service, and Collections. This is a simple example, but cases can be used across a variety of functional business departments.
Within my General cases, I have two subcategories, RMA and Claims, which each have a few child categories. This hierarchy structure does not drive functionality, but rather to organize, delegate, and report on the cases a company handles. As a default, these categories can be assigned a default department, worker, email ID, questionnaire, service level agreement, and most importantly, a case process.
Department – If a single department is responsible for a specific case category, this may be a useful field to default. It can be changed when beginning a new case.
Worker – If a single employee is responsible for a case category. Again, can always be altered upon creation of case.
Email ID – This is an email template that can be set up to provide consistency across cases. This is useful if your case frequently sends similar emails to clients, vendors, or other related parties. My template is setup with standard language for a customer quality report.
Questionnaire – A template of common questions you might ask a customer or supplier upon creation of a case. May not be applicable to all types of cases.
Service Level Agreement – A standardized time frame in which a specific case should be completed. My quality return case has a service level agreement of 2 weeks.
Case Process – Defines the steps necessary to complete a case, will be described in detail below.
Once you are complete defining your Case Category structure, you may move on to the most important part of your case, the Case Process.
Case Processes
(Organization Administration>Setup>Cases>Case Processes)
A Case Process represents the meat and bones of your case. This is where we can define a recurring template of sequential tasks that are commonly completed for a given Case Category. As a rule of thumb, there should be a one to one relationship between a Case Category and a Case Process. There is nothing stopping you from using the same Case Process across multiple categories, and it may make sense to do so if you would like to segregate similar cases by department for reporting purposes.
When defining a new process, you must start by giving the case a name, description, and case type. I will be creating a quality related RMA case for my example. There is also an ‘Active’ flag to toggle between active and inactive case processes, if they are no longer relevant to the company. Beyond those initial required fields, we also must define responsibilities. These responsibilities determine which departments will have a role in the Case Process. Choose all departments or sub-departments that have a role in the case. Shown below is my initial setup for a Quality RMA process, which includes AP, Customer Service, Logistics, and Quality Departments.
Case Levels
To define the steps of a case, click on the process ribbon and select details. The various stages in a case process are defined as levels. Within these levels, one or many default activities can be assigned that are commonly used within that level. Depending on the importance and flow of the case, we can set these activities as required, which forces the user to complete that activity before moving on in the case. Within each level, we can set a default start and end date in days. This will drive the default timing of the case and will allow for performance tracking if that is of interest to your company. Additionally, we can set responsibilities at the department and employee level. A department must be listed at the header level of the case to be available to assign a level to. Notes can also be added to give users context about what must be done within a given case level.
Case Activities
Within a case level, default activities can be assigned that are commonly completed during a case. The choices for activities include appointments, tasks, action items, and events. Once again, these activities can be assigned to specific members of an organization, which can then be placed into a work queue, which will be described in part 2 of this series. As a reminder, activities do not need to be added to a case process during setup. Once the case is opened, activities can always be added on the fly to any case level. An example of a simple default activity is shown below. It is initially assigned to the quality department, but once the actual case is created, this action will be assigned to a specific member of that team.
I hope this has helped you better understand the value and setup of Case Management in D365! In part two of this series, I will run through the quality RMA case setup from start to finish. For additional information or questions you may have, feel free to reach out to us at info@loganconsulting.com or (312) 345-8817.
All the best!
Logan Consulting
www.loganconsulting.com