#Dynamics365CC – Record identification, data and all the fields!
Disclosure: All information is accurate at the time of writing this article, things change, we change,
vendors change (and we all love them for it)… take everything with a pinch of salt, if you like salt…
When bolting on some of this new Contact Centre functionality, it usually begs the question – how good is the data?
One thing I find, and have seen over the past many years in Modern Work is legacy data, it’s everywhere and comes with a culture, systems change, people change and process takes a bit to adapt, what get’s left behind is a messy dataset (with no fault of anyone), it’s baked into a business no matter where I go or see… so what can we do about it?
Typically, my approach involves trying to assist as we proceed. However, this isn’t always possible due to tight deadlines and rapidly changing requirements. Still, there’s usually time for some in-flight tasks. I highly recommend this, whether it’s a name change, checking field allocations, or simply verifying data duplication. We have plenty of smart tools, such as Copilot and analytical smart things, that can support us in these efforts. Even a few clever formulas in Excel can be quite effective.
Now, moving on from my rambling, let’s discuss how this all connects to our current situation.
Almost all vendors are looking to ease the load on the agent, save customers from repeating information or just presenting something to speed up the actual ‘help’ needed for an inbound interaction but this is where my statement above kicks in hard – you need the data to match and it be clean – to an extent.
With the voice side of things, usually out of the box we have a DDI to work with, most CRM data will contain this to some degree, but we may have the odd set that doesn’t, or just the minimal amount to capture, if any.
Dynamics has many toolsets to help route to someone, assist the agent AFTER everything has been done, but most forget about how / what data we use to at least identify the inbound request, the intent itself.
This is split into 2 ways of thinking (yes, it sounds obvious):
Automatic Identification: Something out the box, like a DDI, authenticated email address etc.
Manual / Part Manual – ‘Pre’ conversational – taking something off the customer before we start doing the smart stuff.
Starting backwards, manually, we can use pre-conversational tools, over most of the modalities that Dynamics offers, we can even fall back to use the bot to do this to get more in depth analysis and the fun of context variables (wont go too far on this) but it’s powerful, and you can then bring in additional flows to go even further with record checking… most importantly we can then throw this back to the workstream(s) / classification rulesets for processing in Unified Routing, bit of light reading below but the idea is taking some more ‘data’ from the customer:
https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/configure-pre-chat-survey
https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/context-variables-for-bot
From this point, it then starts to then identify a record inside of the dataverse / CRM dataset to try to give the agent a form of active Account / Contact or Case that’s matching with the data we collected, this leads onto the Automatic way of working (even though this is kind of the same thing).
Automagiclly, we are trying to find something we can use out the box from the inbound to match, like above to a Account / Contact or Case, in my usual context a voice call will have a DDI pass through (some restrictions on this, witholding, upstream configuration etc) for the matching, then the system will try to find a match on a few fields inside of the records themself BUT we are limited to start:
https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/record-identification-rule
Initially, the flow takes the telephone1 and mobilephone fields for identification, usually most datasets will have these filled in some form, but like we have already worked out, not all data is clean, so what we can do is ask the workstream to look at some additional fields for lookup… I would recommend not overdoing it with these because, as I keep going on about, data cleansing should be the priority:
https://learn.microsoft.com/en-us/dynamics365/contact-center/extend/enable-fields-identify-customers
We can bring in these fields using the fetchXML method (URL above) for updating. I would suggest prettifying it up first, as it can become quite mashed up. You can grab your workstream ID directly from the URL when looking it up in the portal:
WorkstreamVirtualHubWrapperControl&data=%7B%22streamSource%22%3A1XXX%2C%22workstreamId%22%3A%227e024812-2XXXXXXX%22%
The rest is pretty much self-explanatory, just remember it’s per workstream, depending on how you use them (please don’t use one per DDI, maximise that Route to Queue and Context / Classification Functionality… it’s cleaner!), then each one will need to be updated, where needed.
The last thing to touch on is what constitutes a lookup, there is a article from Nishant which I stumbled on, and it seems he’s the only one that explained it in depth and it’s worth a look:
And just to summarise it here, we have certain methods how the system looks these up and some can cancel others out – the primary thing to take away is that IF it can’t make a match (duplicate data, conflicting records) the agent can always fall back to asking again, so trying to keep that 80/20 rule I love (80% ease / 20% fallback) we should have enough to get some matches to our screen.. most of the time!
Hoping that makes sense and gives some food for thought, but we do have a 50/50 chance on matching a record if that data is good!
The next fun thing is the new Copilot intent models (preview), but that’s for another time, when it’s in a good state and it’s not a baking 32 degrees in the UK!
Ben