Tag: dynamics 365

Omnichannel & Sentiment Analysis (II)

I’ve previously touched upon sentiment analysis within Omnichannel in several articles (https://thecrm.ninja/omnichannel-sentiment-analysis/ and https://thecrm.ninja/omnichannel-supervisor-tools/). It’s really a great feature that allows agents to quickly & easily see how the customer is interacting. It also allows for supervisors to see at a glance how interactions are going overall.

With all of that, I thought it would be helpful to take a further look into how sentiment analysis actually works, so that we can understand it a little better.

Now, the actual nuts & bolts for sentiment analysis are provided by Azure Cognitive Services. There are a wide range of tools available through this, but we have no need to go into Azure to configure this. It’s a simple setting within Omnichannel to get it working, rather than needing to fiddle around with many different things:

However, what’s actually going on during a conversation, and how is the sentiment analysis worked out/calculated? We see the pretty little face icons (with the different colours), but how are these actually being set?

Well, there are two ways in which algorithms are used to calculate the sentiment that’s shown:

  • Natural language processing (NLP)
  • Machine learning (ML) algorithms

With these two ways methods, it’s possible to not only see what the current interactions are showing, but also to enhance the model to understand sentiment better.

Note: In a session that I presented recently, one of the attendees asked if it’s possible to train the model, to result in a custom algorithm. Unfortunately this isn’t possible to do – the machine learning that takes place is the general Azure one, rather than one for a single company or customer

The following diagram shows the sentiments that are used. They’re nicely colour-coded, for ease of reference as well:

When a customer interacts through Omnichannel, the sentiment shown is based on the last 6 messages received from the customer. As a result, the sentiment shown can very well fluctuate & change during the conversation, based on how it’s going.

The Sweetest Languages in the World - | Beyond Exclamation

Obviously, customers aren’t just going to use English to communicate. Companies are based around the world, and will use their native/local language when providing support. Omnichannel allows for this without an issue, utilising the Azure Text Translator API behind the scenes to provide this. If you’re interested to see which languages are supported for this, head to https://docs.microsoft.com/en-us/azure/cognitive-services/translator/language-support which is the latest source of information for this.

There are some interesting things to know around how this actually works:

  • When a language other than English is used, the Text Translator API translates the text to English, and then it’s analysed/scored for sentiment
  • If a language isn’t supported by the Text Translator API, it won’t be scored
  • If profanity (eg a swearword) is detected, the sentiment will automatically be shown as Negative or Very Negative, regardless of the rest of the last 6 lines of conversation

Some people have expressed their concern to me around how accurate the Azure translation actually is, but to date I haven’t seen any major concerns resulting out from it. As with the other Azure services, Microsoft is continually refining & improving it. That being said, there are several languages with very nuanced terms. I’d like to think that these would be supported without issues.

There is, however, somewhat of an interesting behaviour when starting off the analysis at the beginning of the conversation:

  • If the initial language is detected as English, it’s assumed that all of the subsequent conversation will be in English. As a result, if the customer switches away from English, the system won’t recognise this, and a Neutral sentiment score will be shown
  • If the initial conversation is not in English, then the system will check every conversation line & re-detect the language as necessary.

This seems somewhat strange to me, as I’d have thought that the system would automatically check the language for each conversation line. I can think of plenty of scenarios where different languages are used in a single conversation, even if it does start with English being used. I’d like to think that this will be updated at some point, to make the experience better.

Updating User Settings with Power Automate

Here’s a scenario that could be all too familiar to us. We’re on-boarding users (to either Dynamics 365 or a Power Platform app), & they’re new to the environment that it’s deployed to. So they’re set up, and all ready to go. Suddenly they start asking why records created (or modified) by colleagues show up as having the wrong time on them.

Reverse Wall Clock Unusual Numbers Backwards Modern Decorative ...

Does this sound familiar? I’m sure it does to quite a few people out there!. See, there’s no way to set a default system-wide time zone in Dynamics 365 (or Power Platform). At least not that I’ve come across – if you know of one, please comment below with instructions as to how to do this!

As a result, users are given the default timezone, and need to change it. This is easily done through the Personalization settings area in the app. Users click here, and then select their appropriate time-zone. Brilliant…or so you’d think.

See, when it’s one or two users, it’s generally OK to tell them to do that. However, when it’s 200 or 2000 users, you’re going to get push-back. The last thing you want is for a large number of them to start contacting you to work out how to do it (read the instructions, perhaps?).

User queue stock photo © zam ri (OneO2) (#258450) | Stockfresh

I’ve had this scenario over the last week, where the client actually told us that they didn’t want us to tell users to update it manually. They wanted a better solution.

Well, there is a solution out there to update users. It’s the ‘User Settings Utility’ app that’s in the XrmToolBox (https://www.xrmtoolbox.com/plugins/MsCrmTools.UserSettingsUtility/). Really neat & nifty, and does just what it says on the box. Simple enough to select users (or all of them at a time), select the time-zone you’re wanting to apply to them, and click a button. Hey presto – it’s been updated

Hmm. But what if you didn’t want to have to do this manually. Or (and this is what I was dealing with), there were decent enough number of users being added to the app every few days, & I didn’t want to have to do this as a manual task.

So I started digging into how the time-zone setting was actually stored. It turns out that there’s an entity called ‘User Settings’, which is associated with a User record. Oh, and if you’re going to want to take a look at this entity to see what it contains, it’s NOT available through the front end. You can’t go into the entity list and just display it (though if you’ve found a way to do this through the Power Platform NATIVELY, drop me a line, please?).

Anyhow, back to things. There’s a value for ‘TimeZoneCode’, which maps to a specific time-zone. Aha, I thought! Right – now what’s the best way that I could work out to do this automatically. Checking in with some contacts in the tech community (thanks BlackOps etc!), Power Automate was suggested, so I started to see about how I could go about it…

So, I created a Power Automate Flow (haha…I got the name right there!). On creation of a new user record, it would programmatically go away and update the value to the one for the time-zone that I wanted it to be set as. This actually worked really well.

The only drawback is that through the user interface, it’s not actually shown as being updated, though it has been. Or sometimes it changes, but doesn’t reflect it accurately. This is somewhat annoying, and caused me quite some confusion between checking the front end to see if things were working, & confirming through the back end (& opening records up) to see that it was. I still have NO idea why this was happening.

Before changing my settings
After changing my time zone to USA (EST)

For my specific scenario, all of the users are in the UK, so I set it to update every user on creation to the UK time-zone. Obviously if you have users in different time-zones, you’d want to set this differently. This shouldn’t be an issue though, as you can expand the Power Automate Flow and add logic conditions/branches to be able to do this.

Now I think that this is pretty cool, and I couldn’t find anything out there for this. I’ve therefore decided to release this in a small solution, for others to be able to use. Part of this is the entire list of time-zones with their specific codes, so that you can update to whichever one you need to.

Update Timezone for New UsersDownload

I hope that this helps solve a small but annoying problem (at least it did for me). Please do provide feedback if you want to!

Omnichannel – Pre Survey Responses & Routing

I’d like to start off here by admitting that in a previous blog post that I put up, I mentioned that it’s not possible to route customers to different queues through the chat itself. That was wrong – thankfully several very nice people at Microsoft reached out to let me know how it’s done (thanks BTW for reading my blog!). I therefore thought it would make a good article, as people do ask me about this from time to time.

So, how exactly does Omnichannel facilitate this? Well, there are two parts:

  • Pre chat surveys
  • Routing rule items

Pre chat surveys

These surveys are really quick & easy to set up (or even more complicated, if you so desire). To start getting to grips with them, open a Live Chat record, and go to the ‘Pre-chat survey’ tab

Here, you’ll be able to set up your questions, which is done by clicking the ‘Add Question’ button. When you do this, you’ll get the following prompt.

So, three of the four questions are really quite simple. You need to give it a name (as every system record needs), the actual question text, and whether it’s mandatory or not. The fourth question ask you what sort of question type you’re looking for. The options available are:

  • Single line of text
  • Multiple lines of text
  • Option set
  • User consent

If you select ‘Option set’, you’ll be prompted to enter the values. These should be separated by a semi-colon character:

With our pre-chat survey questions being set up, let’s see how we go ahead and use them for routing.

Workstreams

If you go ahead and open up any workstream record, you’ll see several tabs available. Two of these tabs are Context Variables, and Routing Rule Items. There’s usually one workstream per chat channel, with setting options within it as required. Opening up the workstream for the Live Chat, we can see them there:

Let’s take a closer look at the Context Variables first. Going to this tab shows us the following:

Woah. Where did those entries come from? I didn’t enter anything here – though I can create context variables if I want to.

Well, remember those pre-chat survey questions that we created? Each time one of these is created, it creates a context variable record for the workstream that the chat is associated to. So each of my questions (and I have four of these) now have a corresponding entry.

OK – so the system does that. But how does that help me when looking at trying to route things?

Simply put, these are the building blocks that we’ll set up in the Routing Rule Items to flow the customer chat through to an appropriate location. Let’s go and create one to see what happens.

We need to set the queue that this rule to apply to. Then we’ll go ahead and set the condition/s that we’re wanting to apply for this queue. There are several different possibilities to start with:

Selecting the entity that we want to use for the rule will then allow us to pick an attribute for that entity. So;

  • Account, Contact, Case & Live Chat Context will give an option to select one of the attributes from the entity
  • Context Variables will give the available context variables to choose from

You’ll then be prompted to select an Operator. These will vary depending on the type of field (eg a number field will have additional options such as Greater Than, Smaller Than, etc)

Finally, you’ll enter the value that you’re looking to match with for the condition. This is free text (it’s not auto-populated with values). So in summary, you’ll have something like the following:

And tadaa! it’s active. Brilliant!

We’re able to stack up multiple conditions to cover specific scenarios. An example could the following:

  • Customer has a Kawasaki motorbike (not a different make)
  • Customer’s annual spend falls into the ‘high spend’ bracket

There are plenty of other scenarios that can be covered, and the conditions allow this to cover quite complex situations.

So, some things to note around workstreams & routing rule items:

  • You can have multiple routing rule items per workstream, each one routing to a different queue. These are evaluated in the order that they’re saved in. Eg if there are 4 rules, an incoming chat will be evaluated against rule 1, then rule 2, etc
  • When a routing rule condition is met, the chat gets routed to the destination. No other evaluation against the remainder of the rules is carried out

I hope that this has come in useful, and put some interesting thoughts into your mind as to how you could implement this at your organisation or clients!

Omnichannel Install/Update Errors

I’ve had an interesting time over the last week or so. Several people have contacted me about trying to either install Omnichannel, or upgrading to the latest version. These differ based on what the user was trying to do.

When trying to install into a new environment, the error says ‘To add this channel, you must have an active subscription to Dynamics 365 for Customer Service Chat or Digital Marketing’. This is especially strange as a trial environment (for testing purposes) doesn’t actually require these licenses. It only requires a Customer Service Enterprise license.

When trying to upgrade an existing environment, there’s a different error. This one says ‘We are unable to check for upgrade as you don’t have the required permissions. You need to be either a global administrator or a Dynamics 365 service administrator to check for upgrade. Transaction Id: 0cc1f6be-32f1-476c-8071-acc4d8475e63’. However the user has the Global Administrator role (which obviously also includes the Dynamics 365 Administrator role as well!

image.png

Now I love being able to share my knowledge & help others. That’s one of the main reasons why I started this blog and why I share information that I feel is helpful & useful to the wider community. So I was more than happy to try to help the people who had reached out to me, and jumped on a screenshare session with them (using Microsoft Teams, I may add!).

They were indeed getting the errors mentioned. Nothing that I could suggest helped to rectify. To try to diagnose & compare, I jumped into my own environment. To my absolute surprise, I was greeted by the same issues!

Nanny Knows Best: Shock Horror Probe - People Take Responsibility ...

I knew that it hadn’t been occurring several weeks back, as I had carried out some maintenance work in my own tenant & everything was working fine. I double-checked everything on my end, and it all seemed to be set up correctly.

I therefore decided to go ahead and log a ticket with Microsoft Support. I had a sneaky feeling that it was something, somewhere, to do with the Wave 1 2020 release upgrade. This had happened 2 weeks back (since I had last been into the Omnichannel setup), and I was figuring that something could have gone wrong.

This feeling was boosted by hearing that someone else who was having the same issues had also logged a ticket with Microsoft Support, and they had resolved the issue for the affected tenant. In doing so, they had mentioned that the back-end hadn’t been configured correctly, and got it fixed.

My support agent was a lovely guy called Tomasz, based in Portugal. Emails initially exchanged, we then jumped onto a Teams screenshare session so that I could demonstrate the issues from my side. He was very helpful, and immediately got to work. Within 12 hours I had received an update from him on the situation. They had identified the problem, and were working on a fix.

I had mentioned to him that I knew it wasn’t isolated to my tenant, or even region, but that other people across the globe were also experiencing this. I suggested that whatever fix would be found should be rolled out on a global scale (if applicable).

The crux of the problem seemed to be that with the Wave 1 2020 Release, there had been a change in the architecture of the Omnichannel total solution. Everything still appeared the same through the interface, but under the hood there had been some changes (I have no idea of what actually had changed though).

For new instances (whether Trial or Production), the solution was installing with the new architecture. However all existing systems (whether Trial or Production) had the old architecture, and the Wave 1 2020 Release wasn’t upgrading it to the new one. It simply failed, giving the different error messages.

The fix that was needed was actually quite simple, and only took a few minutes. I had to spin up a new trial of Customer Service within my tenant (which would expire within 30 days). Doing this re-installed the Customer Service solution, & included the new Omnichannel architecture. As a result, after waiting around 5 minutes I was able to open the Omnichannel Administrative Settings, and upgrade my existing Omnichannel deployment. I was also able to deploy to another new environment without any issues. The problem had been solved!

Joyful Green Monster Saying Hurrah Vector Sticker Illustration ...

Overall, this support ticket was an example of how support should be/work. I’ve had times before when it’s unfortunately not gone like this, which makes me value this all the more so.

So, lessons to learn from this. Well, if there’s an issue with deploying Omnichannel to a new environment, or upgrading an existing deployment, fire up a trial of Customer Service, and that should fix it. Brill.

I do wonder how this managed to creep in. Obviously one of the main parts of deploying any new major solution is thorough testing. Perhaps it could be that due to the size of the actual Omnichannel solution, something was overlooked somewhere? It would be good if this sort of situation would be avoided for future releases, and functionality build in to automatically upgrade the Omnichannel solution if it has an old architecture.

Update. I’ve actually had feedback from the Omnichannel team around this. Essentially there’s something different about Trial environments, and this issue only affected them. Production environments (ie with paid-for licenses) wouldn’t have experience the issue. I don’t know why they’re different, but somewhere they are!

Omnichannel – Chat Setup

Looking back at the information that I’ve already posted on around Omnichannel for Microsoft Dynamics 365, I seriously can’t believe that I haven’t already done an article on how to set up a chat channel. I know I’ve talked about some of the functionality within chat itself, but it’s now time to sort this out.

This was the FIRST thing that I did when I got my first Omnichannel environment up & running. The feeling of satisfaction when it was all complete and worked was incredible. I think I may have bounded out of my chair, punching the air!

So, with that all being said, let’s see how to go about it. It’s not that difficult, and there are some helpful settings within it. The functionality has also increased with the Wave 1 2020 release, which is quite cool.

Now, you can create multiple chat channels, and position them where you want to. Each chat channel can point to a different workstream, and then feed into a different queue (more on that in another post).

To create a chat channel, go to the Omnichannel Administration Hub, select ‘Chat’ in the left hand menu, and click ‘New’

You’re then presented with a new Chat record window, to set it up. It’s actually quite simple to go through, with tabs providing different options. Don’t forget about these!

A few things to point out from the main page:

Chat Design

Once you’ve filled in the main information, switch to the Design tab. Here you’ll be able to configure the look & feel of things:

Now at this point in time, you’re only able to use the pre-defined theme colours for the Omnichannel chat widget. That’s not to say that you can’t work around this – if you use an Azure bot, or a custom bot (which needs to be using the Azure bot framework, admittedly), you could set a custom colour there.

You can change the logo displayed – this needs to be a publicly accessible online image. This can result in some fun looks!

You can also set Operating Hours for when the chat will be active (see https://thecrm.ninja/handling-company-hours/ for how to set this up).

Pre chat survey

Heading to the pre-chat survey tab, we can set up survey questions for the customer to answer before the chat actually starts with an agent.

There are some nice options here:

  • Being able to set questions as mandatory or not
  • Different answer types available. Eg text (single or multi-line), option-set, or user consent

Now at this point in time, it’s not possible to use the answers given (eg with using an option-set) to route a customer to a specific queue. It would be amazing if this would happen, but it’s not there yet. Instead the information from the pre-survey questions are displayed in the agent interface. This is aimed at being able to gather information upfront, rather than the agent needing to ask for this during the chat session

Location

The next tab allows the ability to tie the chat widget to a specific website. This means from a security point of view that if someone copies the source code from your webpage, it won’t work on a different website. If no domain is specified, the chat widget can be embedded on any website, without restrictions. It’s a useful concept that can be handy in certain scenarios.

We’re also able to capture the customer geo-location. This will prompt the customer to allow their location to be shared with the agent. If the customer doesn’t consent, then it won’t be shared. Note that this does require Bing Maps to work

Conversation Options

Part of the Wave 1 2020 release has been additional functionality for Omnichannel agents to use. This includes abilities to call, co-browse, and screen-share during customer chat sessions.

I’m going to going into detail around these options in a separate post. I’m also going to be looking into the current solution providers for this, and seeing what each one provides above & beyond Omnichannel integration

Custom Messages

The final tab gives the option to use custom messages for some of the system functionality. Essentially things like starting a chat, ending a chat, and chats timing out all have messages around them.

These are things like ‘An agent will be with you in a moment’:

What custom messages allows you to do is to change these. So for example, you could set up the following to be displayed:

I hope that this has been helpful in seeing how you can set up a chat channel. Stay posted for how to set up the other channels as well!

Omnichannel Desktop Notifications

I’m quite regularly asked various things about Omnichannel. One of the most regular questions goes along the following lines:

Are we able to show a desktop notification to our agents, when they’re not on the Omnichannel Customer Hub screen?

Let me explain what this is all about. When an agent is logged into the Omnichannel Agent Hub, and a new chat comes in, they get the following prompt on their screen:

They can then accept it (which will open up a new chat session), or reject it (which will send it back to the queue).

But if they’re not on the browser tab that Omnichannel Agent Hub is open in, they won’t see any notifications. At all! So they miss out on this, and the customer isn’t engaged with. This obviously is undesirable from a business perspective, as it could even result in losing the customer. So the answer, until now, has unfortunately been ‘No’.

Now in the past when this has come up, I’ve suggested that people take a look at either:

However in my experience these haven’t really been suitable for Omnichannel. This can be due to various reasons, including the client, the requirements, or the infrastructure itself. It’s always been a real annoyance to things, and something that I (& many others) wish would be in place. Several of us have given previous feedback to the product team that this would be really useful to have.

Companies want their agents to be as productive as possible, and this therefore results in a gap in their potential productivity.

Well, the amazing news is that the Product Team for Omnichannel have listened to the feedback given. Not only that, they’ve actually acted on it!

As part of Wave 1 2020 functionality, we now have Omnichannel desktop notifications! This can cover the following scenarios:

  • The Omnichannel agent has minimised the Omnichannel Agent Hub app
  • The Omnichannel agent is working on another tab of the browser
  • The Omnichannel agent is working in another browser window

So what does this actually look like? Well, it’s quite nice & neat to see:

Desktop notification

Very helpfully (in my opinion) it even tells you the browser that’s being used. Users can be running multiple browsers, and this helps as a reminder. If a user has multiple different browsers open, this can assist with working out which one has Omnichannel running in.

Now, there are several different actions that will happen, depending on the agent reaction to the notification:

  • If the agent clicks on the text (but not one of the buttons), it’ll open up the Omnichannel app, and show the agent the notification within the app. They can then choose to accept or reject it within the Omnichannel app
  • If the agent clicks the Accept button, the Omnichannel app will open up & be active, and the session with the customer will start
  • If the agent clicks the Reject button, the notification will go away, and the customer will be returned to the queue

Lets take a look again at the notification within the app itself:

There’s a ‘Wait time’ contained with it. If the wait time expires without the agent doing anything, the conversation is returned to the queue.

This value can be configured by the Omnichannel Administrator, to whichever setting fits the organisation. To do this, go to Notifications in the Omnichannel Administration Hub, open up the notification that you’re wanting to modify, and change the value shown below:

However, you’ll note on the desktop notification that there’s no ‘Wait time’ included on it. This is because the way that notification appears on the desktop doesn’t allow for it to be shown. That isn’t to say that it’s not applicable – the agent will still have the same amount of time to respond. If they don’t respond within this time, the desktop notification will disappear.

Now, there’s still something that the agent will need to do in order to have the desktop notifications to appear. They’ll need to give the browser permission to allow it to happen. The first time that it occurs, it’ll prompt the user as follows:

Allow desktop notification

When the user clicks ‘Accept’, it’ll save the setting, and the desktop notifications will be pushed through. Obviously if they don’t, the desktop notifications won’t appear!

There can be occasions when this still doesn’t work. The below items should help you troubleshoot any these, or similar situations:

One thing that’s also really useful to know is that all of this isn’t just for new customer conversations. The functionality for desktop notifications also covers:

  • Incoming chat conversation
  • Incoming SMS conversation
  • Conversation (work item) assignment
  • Conversation transfer
  • Conversation escalation
  • Conversation escalation from a bot

So really the whole gauntlet of agent interactions that they’d be doing on an on-going basis. Which of course is really helpful, and highly useful.

I’m really quite happy that this has come out as part of the Wave 1 2020 feature items. I’ll be continuing to go into depth around the other functionality that’s part of this release. For the moment, I’m also going to quietly wonder what the product team are going to include next – I’m sure it’ll be very helpful!

Thoughts around the Connection entity

I decided to write this post due to currently looking at the Connections entity. This is for a current project with a very specific purpose. When this came up, my thoughts went back to a previous project some years back when we also looked to use the Connections entity. I therefore thought that it would be good to recap & share my experience.

What are Connections?

Now, the Connections entity truly is a wonderful piece of work. It’s one of the core features that doesn’t actually get much time or effort devoted to it! However, it underpins a lot of the way that Dynamics 365 has been built to work over time.

The best way to summarise Connections is:

Connections are a very easy way to connections records without needing to have to create a custom relationship in the system. Connections can be used between records from the same entity, or from different entities.

See, you are able to connect one record to another record within the system. This could be account to account, account to contact, or contact to a custom entity. There are practically no limits, apart from the extent of your mind! All of this is done by leveraging the functionality that Connections brings to the table.

Note that I’m not talking about lookup fields here, which are also great, but work differently, and require creating a relationship between entities (or even within the same entity).

Just a quick reminder here that custom entities need to be enabled for connections – it doesn’t happen as standard when creating them. You can either do this when creating it, or you can edit the settings for it later:

How to use Connections

In order to connect one record to another, you need to open the first record & click the Connect button on the toolbar:

You’ll then be presented with the New Connection screen, where you’ll select the record that you want. Click the ‘All Records’ item at the top & then ‘Change View’ to select the actual entity that you’re wanting to look for:

You then select the record that you’re wanting, and save. Hey presto, the two records are now connected! To see the connected records, look at the associated ‘Connections’ setting from either record:

OK, so this is really all brilliant. For the absolute majority of situations, it works, and works well. There’s nothing better for it. There are a few small issues, such as the fact that you can’t use Business Process Flows or Business Rules for custom logic, but instead need to use Javascript, but for the most part they work well.

Edge case scenarios & issues

However, there are some edge case scenarios that I’ve come up against, which is the whole purpose for writing this blog post.

What happens if you’re trying to use Connections to establish a hierarchy of records. Eg one record is a parent of another record. Well, you could use a lookup field instead, but if you wanted to define specific attributes for the actual relationship, that wouldn’t work.

Here’s the scenario. You’re needing to capture the relationship between different people, along with certain attributes (eg if they’re a legal guardian, or a trustee, or have power of attorney, etc). You’d think that Connections would work brilliantly for this. After all, you can modify the actual Connections entity to add custom fields onto it. So for example, you could have something like the following:

Note: I’m not referencing Connection Roles, as you can only have a single connection role per connection. In the scenarios I’m handling, I’m needing to have multiple attributes per connection.

So you create the connection between the two records, and you set the attributes that you require. All good. What’s also good to remember is that Connections are bi-directional. You can view them from either ‘side’ of the connection. Eg:

Record 1

Record 2

That’s actually really helpful & useful in the normal scheme of things. You can easily see connections from either side.

But there’s a catch, or even (in our case above), an issue. If we open up each of the two Connection records, we’ll see the following data.

Joe Bloggs connecting to Helen Sommers:

Helen Sommers connecting to Joe Bloggs:

Can you spot the issue? Of course you can! On BOTH of the connection records, the custom fields that we set have the same values. We originally connected Joe Bloggs to Helen Sommers as the Legal Guardian, Power of Attorney & Trustee. Well, if we open up the connection record from Helen Sommers, we’re seeing the same values set, just in the opposite direction!

This is actually due to how Connections work. When you create a connection Record A to Record B, the system automatically creates a mirror Connection record from Record B to Record A. When it does this, it copies all of the values that you’ve set over to this mirror record.

So when you look at the data, you can’t actually see how the structure should work. It’s an issue. Especially if you’re passing the data to other system/s that may need to evaluate it. They just can’t understand this properly, and you’ll get some VERY unwanted results out of this.

Now, there is actually a field within Connections that shows which record is the ‘master’ (ie the one you actually created), and which one is the ‘mirror’ that the system created:

However even with this in place, we’ve found issues when using it:

  • If you’re relying on people looking at the record to see the information, they’re going to make mistakes (ie not checking this value). With the fact that the values are also displayed on the mirror record, this is very prone to user error, and isn’t a good way to do things
  • If passing information to another system (ie the record & the values), you need to program it to only allow it to pass records with this flag set correctly. If the other system is writing back data, it also needs to be configured to write back to the same record.

Summary

With all of this in mind (& especially considering that users may create connections from the ‘wrong direction’, which is quite possible to happen), it’s important to think of the best way to architect systems for regulatory purposes. Financial, legal & other judicatory requirements need to have a system that can handle them properly & accordingly, and not leave room for error.

Therefore, if you’re looking to handle these sorts of scenarios, I’d recommend to look at implementing a custom entity for those specific connections.

Another benefit of this is to separate out these connections from the general connections entity. That way, you’ll also be able to handle security appropriately, which is usually applicable in these sorts of situations. It will allow you to easily allow only a subset of users access (read and/or write) to this data, rather than trying to apply it to Connections (which is going to be a major headache!)

Wave 1 2020 – Search Behaviour Changes

Having applied the Wave 1 2020 release to several of my test environments, I was browsing around to see the new functionality within it, which is pretty good. However, there was something that I wasn’t expecting, which was a little startling to see! This is around the way that the search behaviour is now working within the system.

What am I talking about? Well, for years, users have asked me if they could search within a specific view. Ie if we had a view set up for ‘My accounts’, where the user is set as the account manager, it would show only the accounts where that condition applies. However when using the search functionality, the system would search & return ALL results that match the search criteria (eg if searching for ‘Apple’, it would return all accounts with the word ‘apple’ in them, regardless if the user was set up as the account manager or not).

Explaining this to users was probably the most complicated thing, in my experience (well, that, and having to then trawl through hundreds, if not thousands of records, where it’s a common word). But for the most part, they accepted it. OK – we all moved on.

Let’s see an example of this. The screenshot below shows an account that exists within one of my Sandbox environments (which has the Wave 1 2020 update applied to it):

I’m now going to search for it within the entity itself (more about Global Search at the end of this post):

Hold on – it’s not showing up! What is happening here – is the system OK???

Let me explain what’s happening. Previously (before the Wave 1 2020 update was applied) it would indeed show up in the search results.

But this has now changed! The system is now performing searches ONLY within the view that the user is using. The reason why it’s not showing up here? Well, it’s because I’m not set as the owner of the account – a different user is (and I’m using the ‘My Accounts’ view, as seen in the previous screenshot):

If I now change my view to ‘All Accounts’ and repeat the search again, the record now shows up:

I hadn’t come across this in my perusal of the release notes. On going back to it and digging deep, I found the mention here – https://docs.microsoft.com/en-us/power-platform-release-plan/2020wave1/microsoft-powerapps/improvements-quick-find-search-experience-grid.

Amusingly there’s actually even a little hint within the system for this. If you look at the entity search box, this is now the text that’s being displayed within it:

There’s also an additional feature as part of this – if you’ve prefiltered a view using column value, searching within the entity will RESPECT the pre-filtering!. OK – now this is indeed incredible:

My thoughts on this is that it’s going to be a double-edged sword. For years, we’ve been educating customers about how searching works, and now this has the potential to change things up.

Thankfully it’s actually possible to turn this off, and revert back to the way that searching has always worked – this is likely to be needed to be done quite a bit. To do this, go to Settings, Administration, System Settings, and change the value for Categorised Search to ‘Yes’ (it’s about 1/3 of the way down the page):

It would have been nice if Microsoft had made people more aware of this, in my opinion.

Please note that this only applies to searching within an entity itself. Global Search (for the moment) still uses the Quick Find view, and returns all results (regardless of filters).

Handling Company Hours

Companies want to be able to support their customers, and provide a valuable customer experience. That’s a given, of course! On the other hand (especially if the company isn’t a multi-national), they’ll have hours of operation that they’re open for. When the company isn’t open, they’ll want to ensure that customers will know this, and not be routed to customer support when it’s not available.

There are several different ways of handling this, depending on how exactly the system/s have been implemented. Let’s take a look at some of these

Omnichannel Native Web Chat

One of the channels available through Omnichannel is the webchat. I’ve covered some of the ways that this can be done at https://thecrm.ninja/proactive-chat-in-omnichannel-for-dynamics-365/.

When setting up a chat channel directly from within Omnichannel, we can leverage the inbuilt settings for Operating Hours:

By using this, we’re able to set up different day & time combinations, along with the timezone that’s it’s applicable for (I’d suggest to use appropriate names and/or descriptions to easily identify them, of course!):

It’s not even a blanket setting (ie that you set up one record for this, that governs all communication channels). You’re able to set up multiple Operating Hour records, and can then point each chat instance to a specific one. To do this, go to (or create) the Chat record, open the Design tab within the record, and select the Operating Hour record you’re wanting to associate to the chat:

Now, when this has been applied, the chat widget button will only be displayed on the webpage/s where it’s deployed to during the specified Operating Hours. Great!

Power Virtual Agent

There will be scenarios where you’ll be implementing a Power Virtual Agent in the first instance, rather than using the Omnichannel chat itself. Reasons for this include the ability to have automated responses to issues, allow users to self-service their enquires, and other.

Having taken a look, the configuration for escalating a PVA conversation into an Omnichannel queue is actually quite simple and basic. Unfortunately, there doesn’t (at the time of writing) seem to be any way of picking up the Omnichannel Operating Hours that are set up within the system, nor any method to specify these in any other way for the PVA itself. Hopefully this will change at some point!

Azure Chat Bot

I’ve also taken a look at Azure Chatbots, as these are another way in which companies will enable customers. Once again, there’s no way to have an Azure Chatbot respect/pick-up Omnichannel Operating Hours. I would hope that this will be functionality that comes in the future.

However (unlike Power Virtual Agents), it should be possible to write code within the chatbot (using the Microsoft Bot Framework) to indeed take these into account.

Other channels

There are of course other channels such as Facebook, SMS, and the Wave 1 2020 items (Twitter etc). With all of these, there are likely to be different methods in getting the Operating Hours set up, along with things like auto-responses (eg ‘The office is now closed, please contact us again between 09:00 & 17:30 Monday through Friday to speak with an agent’) to give the best experience.

Omnichannel & Sentiment Analysis

In general, it’s usually quite useful to be able to see how customers are engaging with your company, and how they’re feeling about things. If customers are disgruntled, annoyed, or complaining, it’s important to be able to understand the root cause/s of their issue/s, and resolve them as soon as possible.

One of the tools available in Omnichannel is Sentiment Analysis. What is this?

Being able to identify how customers see/interact with your brand, accurately, is vitally important. Using people to manually trawl through your data to attempt to identify this has many drawbacks:

  • Lack of consistent approach
  • Large amounts of time needed
  • Many manual touchpoints

As a natural follow-on from this, being able to identify & categorise the sentiment in customer communications through using machine learning can unlock many business use cases that can then result in immense value for your company.

Microsoft provide the ability for this through Azure Cognitive Services. It’s really quite interesting in how this actually works. You can go to https://azure.microsoft.com/en-gb/services/cognitive-services/text-analytics/, put in a sentence, and see what results come back. It can be quite amusing to see what different colours come out as!

As part of the analytics around chat (and by chat, I’m not referring to just a chat bot – anything within Omnichannel can be referred to as ‘chat’, from an agent perspective), sentiment analysis can be used.

This is quite easy to set up. To do so, open the Omnichannel Administration Hub, go to the Settings area in the left-hand menu, open ‘Sentiment Analysis’, and click to enable it. Remember to save it to apply it!

This will then result in the agent interface showing the following:

Now, this isn’t static. The sentiment will update in real time as the conversation continues, and will change based on what the customer is saying.

Now, obviously we’d expect agents to be able to judge the tone of the conversation based on what’s being said (at least I’d personally expect it). So for this, the sentiment that shows within the chat isn’t that helpful.

However, it does come into its own in a slightly different place. This is the Omnichannel Sentiments Analysis Dashboard, which is served through PowerBI.

Through this, supervisors can understand how their company is measuring up to their KPIs & necessary trends. They can also understand the overall support experience that omnichannel is having, along with tracking the sentiment of customer interactions. As a result of having this to hand, better understanding of customers can take place, resulting in improvement of the overall customer experience.

Once the dashboards have been configured within PowerBI (I’m going to do a separate post on this), it’s then possible to surface these within the Omnichannel Customer Service Hub (which users with the Supervisor role will be able to see). This means that supervisors won’t need to open a separate place to see these; it’s all available through the same interface.

There’s also a more detailed view into what’s actually happening, through the ‘Omnichannel Insights – Sentiment Analysis Report’. This displays a lot more information, drilling down & splitting the data up into agents, queues, channels & trends. Here’s an example of this:

With all of this information as the fingertips, it’s now really possible to drill down into the details. Through this, we’re able to carry out full & proper analysis on what’s actually causing customer interactions. From looking into what’s occurring, it’s then possible to review the current state of things, and see what can be improved. This will then result in more positive sentiments shown by customers, and drive their loyalty to the company!