Trying to build a help desk service using Dyanmics CRM 2013
January 8, 2014
Posted by on
The past week I’ve been consumed by my work around Microsoft Dynamics CRM 2013. Everybody was still on vacation and I stepped up to do develop the POC. My hope is to learn something and get my developer’s mojo back.
I did get a lot better at writing code, especially Linq, since that’s how I access the entities from CRM SDK.
The routing scenario in the POC is like this:
- A customer calls the help desk. He/she dials the support hotline and punches in the selection to answer the questions asked by the IVR system path. The selections eventually lead the call to a queue.
- The system creates a phonecall record in the CRM and a case record. The phonecall’s regading object is set to the case. Based on the info collected through IVR, the system knows this much about the case:
- support language
- type of service request (questions, complaints, or other types)
- country of support
- product family
- other attributes…
- These selections create a “property bag” around the case. We can use it to match the preset “property bag” for the queues in CRM. If there is a match, the case gets assigned to the queue.
- An agent belongs to a team. The team has its own property bag. When the team’s property bag matches that of a queue, the agents in the team gets to see the queue and all the open items in the queue are up for grab by the agents.
I am not sure how a case gets routed in the out-of-box implementation of Dynamics CRM but so far I know:
- A queue contains queuedItems.
- a queuedItems has a n:1 relationship to any entity that’s queue-enabled: Appointment, Campaignactivity, CampaignResponse, Email, Fax, Incident, Letter, PhoneCall, RecurringAppointmentMaster, ServiceAppointment and Task.
- The assigning of Incident (case) to Queue needs to be based on some kind of logic but I am not finding OOB support from the CRM front-end. I’ve built my own phonecall simulator to do the property bag matching logic like above but would like to learn if there’s way to do this without coding.
Other than the above, I’ve also explored using the Subject entity in CRM to representing the hierarchical reason for user’s call. So, I have the top-level subject called “Reason for Contact” that has children of major reasons for calling. Each of the child reason can have more detailed classification in its own branch. It looks good in the CRM UI. However, if I am using the same Subject entity for something else, like representing my product taxonomy, I want to have a way to configure the branch for the Incident form so that “Reason for Contact” will only show the branch under “Reason for Contact” record and not the product tree. I wish I know how to do this.