The OOTB cascading rules for Case are not optimal for the setup that I like to use. I will try to explain why, and at the same time show what I feel needs to be done for it to work better. Keyword is Parental Relationships that we have to STOP. If you wonder what I am talking about, below is the timeline from Case displaying activities.
What happens when you have parental relationship on, and you assign the case to another user, all of the related entities like Task, Emai, Phone Call etc will also be reassigned. Normally you you could ask why that would matter, but for CASE that is a real issue.
You also happen to change the “Modified On” data for the records leaving them potentially unsorted in a manner that will confuse the service agents. This applies to all activities, even the ones that have been closed as complete.
There are MANY other ways to sort activities, but Emails are almost always historical activities and happen at a given time. Tasks and Phone calls can be in the future. This is why I like modified on date, to keep a sort of chronological order. If possible the best sorting would be chronological order for completed activities, and due date sorted on top of that for open activities. Don’t think that is possible unfortunately.
As you can see, the default behavior is Parental for Email, Phonecall and Task. I could have chosen more, but these are the entities I use the most in Case.
Do the following for all 3 relationships. Select Configurable Cascading and then Cascade None for the Assign. Microsoft DOCS cascading – If you wan to see more about Cascading Rules.
Why not NEW UI Config?
At the time of writing this blog, the configuration still isn’t possible for relationships. If you are familiar with configuring, the main point is just showing what I need to do for Dynamics.
The new name for this function is now called “Automatic Record Creation and Update Rules”. You find it under Service Management in the settings area.
I will try to explain why I believe this is the proper way to set it up, even though many of you probably will have a different preference.
Queue: Choose the queue that we created in the previous post
Create Cases for activities associated with a resolved case: The purpose of this field is to create a new Case when you receive an email on an old existing case.
I believe this setting together with 1 minute is the correct setting. Many will argue that I m wrong, but there is a reason why. Dynamics doesn’t have an automatic case reopen when an email is received on a closed case (A mystery why they haven’t done anything about it yet). Without this feature the email would just land on the closed case and never bee seen. With this setup a new case will be created once you receive an email for a case that is closed.
Certain support metrics work against their purpose. Just think about the good old “Number of cases closed in a day” “Time Case was open before closed” In the end, the customer wants to be treated well, and feel confident that the organizations can help with the issue. I try to educate that the case close confirmation should be done for every case.
With the current setting, emails will create Cases that Customer Service will be able to follow up. Sure you might get more cases, but you won’t loose any. A case not answered might be a customer lost!
Email Template: The template provided here is a nice start. Do what you need for changes. Notice that the case number here is included in the subject, and this is something we want to use later on also! Stay tuned for later post:)
Creating the record
Once you choose CASE as entity to create, the system will provide with default values that are fine.
I am sure there are equally many opinions about the best practice here as there are for the Managed vs UnManaged discussion for solutions in Dynamics. I have my preference, and I hope it all makes sense when I am done with my blog series about Customer Service:)
Why I hate Tracking Token
Why someone at Microsoft thought this was a smart number to add to an email is beyond anything i can understand. Every support system I have tried uses this type of functionality in emails, but the number is always the same as the case number. Microsoft managed to choose this logic🤢
While this gives the system a fairly unique number to work with, the number itself is completely useless for reference. If a customer calls inn regarding this case number you will not get many hits in the Case search. This number is not even unique pr case. It will change based on who is answering the Case, just to confuse the users even more.
This number should be the case number, and that is what I will fix in a later post.
Why I hate Smart Matching
So Smart Matching is supposed enables us to not use Tracking Token…. Or does it? Smart Matching tries to understand the subject, to/from etc etc to figure out where to track this email. Does this process fail? You bet your sweet ass it does:) If you have a customer sending a new email with the same subject but for 2 completely different matters, it might connect it to the wrong record.
Is there a better solution?
Some prefer to combine the two options. I still don’t want the tracking token, so I have a slightly different approach. I will show you in a later post in the series, where I discuss how I handle the email subject.
Back to the actual post.
Lets open the System Settings to see what I choose. You can also go via https://admin.powerplatform.microsoft.com to navigate via new setup, but for some reason Microsoft doesn’t auto fill out the numbers below. I still do this old school.
Filter: ^[\s]([\w]+\s?:[\s])+ Max number of subject: 20 Min diff: 0 Min Number: 2
Locate the queue setup from Dynamics Customer Service Hub. This is where we create a new queue for Support@. For the owner we choose Customer Service Team.
Click Save, and the system will automatically give you a new mailbox.
To configure the mailbox, we need to navigate to Advanced Settings.
Open Mailboxes and find Support@ that we created.
Your picture should look something like below. Following order 1. Approve Email – You must be global admin to do so. 2. Test & Enable Mailbox 3. Follow progress in Alerts
If you have done it right, you should see the following. This process can be tricky, and there are lots of great guides out there that might cover this better. Connecting Exchange with Dynamics it typically really easy, or really hard.
Lets se if it works
So after waiting for a few minutes, I now see the email in the queue 🙂
Why on earth did anyone think that this was a reasonable number to include in Customer Service cases?
This number is way to hard to relate to, and too hard to explain why came to be. It has absolutely nothing to do with the Email Tracking Token, leaving the customer utterly confused when talking about numbers.
Might be a little hard to see here, but I open my solution from https://make.powerapps.com and select the case entity. In the Case entity I have the default Case Number field. When choosing to edit this field I simplify the autonumber. This will make even more sense later on.
All of this will be included in my Customer Service Solution later on in the guide.
I prefer to define a team with a security role when i create Customer Service solutions. The idea is that the incoming case is assigned to the Customer Service team. This way it is clear to see what cases are new and not yet assigned.
NB! Reassigning Cases to a new user Out Of The Box is not great. The cascading rules changes the sorting of emails because of modified on dates. I will therefore include a post on how to modify the cascading rules.
Open Dynamics in any app and find the Advanced Settings
This will open up the good old Dynamics Setup. This is where we can access the security model.
We need to create a security role for the team.
These are the entities that I needed to make my scenario work. It is a very minimal role, but I won’t be needing more than this for Customer Service Team.
Open teams and create a new team. I will call mine Customer Service. Make sure you assign the security role to the newly created team.