So it’s been a busy few weeks here, which is why I haven’t really been putting up any articles. March/April is always a busy time for our family with stuff going on, and this year I decided not to push myself to get articles out, as otherwise I’d be running very low on sleep!
That being said, I’ve still had some great ideas about things that I’d like to share, and have been keeping a series of short notes for me to pick up. Today’s topic is one of them, which I think has been a major pain to anyone involved in canvas app development!
So, the back story to this is that we’re able to use Power Automate flows together with canvas apps. What I mean by this is that we’re able to directly trigger them from within the canvas app, rather than needing to do something like edit or create a record, and then have the Power Automate flow trigger from the record creation or modification.
There’s a specific Power Apps trigger that’s available within Power Automate exactly for this purpose:
When clicked, it gives us the trigger line in the steps as follows:
So what we’d do is within the canvas app, we would bind a button (or another control) that when selected, it would then go away & trigger the Power Automate flow. Great – so many different things that we can get to happen! One of the benefits of doing things like this is that we can then pass information from the Power Automate flow back to the canvas app directly:
This can then mean that the user can know, within the canvas app itself, that the Power Automate flow has run, and use data (or other things) that have come out of it.
OK – all good so far.
The main issue to date has been with deploying canvas apps together with Power Automate flows. See, as per best practise, we would create a solution, place the canvas app, flows, and anything else that’s necessary for it to work within it, and then deploy the solution to our target environment/s. And that’s where things just…didn’t go quite right.
Obviously within the development environment, the canvas app would be hooked up to the flows, and everything would work. Clicking the button would cause the flow to run, etc. User authentication would be in place (along with licenses of course!), and it was just fine.
But when deploying a solution containing canvas apps and associated flows between environments (regardless of whether it’s been manually deploying, or automated using a tool such as Azure DevOps), the connections to the flows would be broken. Ie, the canvas app would run, but the flows wouldn’t trigger. Looking at the connections in the canvas app within Studio would show something like the following:
All of the connections to Power Automate flows would show as ‘Not connected’. It’s not even possible to click the ellipse next to them and re-connect them – the only option available is to remove it from the canvas app!
So in order to get things working again, we’d need to do the following steps:
Open up the canvas app
Remove all connections to Power Automate flows
Add a temporary button, set it to be a Power Automate trigger
Click through all of the Power Automates needing to be connected (waiting for each one to connect, then go to the next one)
Remove the temporary button
Save and publish the solution
This, in a nutshell, has been a (major) headache. For example, I’ve been working with a solution that has over 30 Power Automate flows that can be triggered from the canvas app (lots of different functionality!). Each deployment has needed the above process to be carried out, which has usually added on at least an hour to the deployment process!
Now, this hasn’t been something that’s been unknown. In fact, the official Microsoft documentation noted the following:
So this is something that Microsoft has been well aware of, but it’s been a pain point that we’ve had to work with.
However, this has now ALL changed, which I (and MANY others) are really pleased about!
Microsoft has rolled out an update last month that means that canvas app connections to Power Automate flows will NOT break when they’re deployed across environments! This is such a massive time-saver, that I’m now trying to work out what to do with all of my free time! Only kidding…more project work will commence!
So what we can now do is take our solution, deploy it across the different environment/s that we need to get it out to (whether manually, or automated using tools such as Azure DevOps), publish the solution, and then everything works! Amazing!!
One small caveat though – to ensure that this work, you will need to go into the app, and re-publish it on the latest Power Apps version. This should of course be done in a development environment, and then can be exported and deployed as required.
Well to start with, I’m sure that I’m going to get pulled up by some people for my use of the word ‘field’ in the title. After all, officially it’s now a ‘column’! But I (still) can’t let go of calling them as I’ve done so for over a decade, so field it is.
Now to the actual topic of this blog post, which is centred around Managed Solutions. Leaving aside the whole debate about whether we should be using managed or unmanaged solutions (& when/where to do each), there is one definitive benefit of using a managed solution.
See, unmanaged solutions are additive in nature. Work is done in the development environment, then deployed. Further work is done (additional items added, etc), and deployed, and they then appear in the downstream environments. However, if you delete an item in the development environment, it’s not removed when the solution is deployed downstream.
Managed solutions, on the other hand, are both additive & detractive. As with unmanaged solutions, items added in the development environment are also added downstream when deployed. However, if an item is removed from the solution in the development environment, it will also be removed when the solution is deployed downstream. It’s one of the useful ways to ensure that you don’t end up with random unused items just lying around in Production (which have a habit then of popping up in the Advanced Find window, for example). So it’s really quite handy for a lot of reasons to go down this route.
Well, I found myself going down this route recently, but with slightly unexpected results, I’ll freely admit…
The scenario was that we had deployed a managed solution to the UAT (test) environment on a client project. Then the client changed their mind (shock & horror!!) as to a specific item, and we needed to change it from a text item to a lookup item. Obviously (as per best practise, of course) this would need to be done in the development environment, and then released downstream. Given that this is a managed solution, I’d expect this to work, without any issues. Well, it didn’t…
The change in the development environment (deleted the old item, ‘re-created’ it as a lookup with the same system name) was done, we exported it as managed, and then went to import it in the UAT environment. It took the solution file, thought about it for a while (it’s somewhat of a large solution), & then errored:
Exception type: System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault] Message: Attribute mdm_field is a String, but a Lookup type was specified.
Now I was somewhat confused by this message occurring. It’s not been the first time I’ve seen it over the years, but in my previous experience I’ve seen it when handling unmanaged solutions. It’s when you delete an item in the development environment, re-create it as a different item type (with the same underlying system name), and then deploy it as unmanaged. The solution import in the second environment fails due to the different in the type (as it sees the same name). This, of course, is to be expected.
But here we’ve been using managed solutions for deployment, and as mentioned above, they’re detractive as well. The expected behaviour (at least from my side of things) would be that the system would note that the item type has changed, remove the old item, & import the new item. In my mind, that’s logical, but apparently not?
See, even managed solutions have their limitations, of which this is one of them. Having checked with several other people who I reached out to around this, I’ve discovered that it can’t work in the way that I was expecting it to. Instead, a specific process has to be followed
In the development environment, remove the item, & export the solution as managed
In the downstream environment(s), deploy this (interim) managed solution. This will remove the item from the environments
In the development environment, re-create the item with the different system type. Then export it as managed
In the downstream environments, deploy this solution. This will then add the item (with the new system type) into the environment.
This means that development & deployment teams (if separate ones) need to co-ordinate around this, to ensure it’s done in the right way. It could also be developed/exported in succession, and then imported in succession as well (either manually, or through an Azure DevOps Pipeline, for example).
This worked wonderfully for us, and to be honest, I was quite relieved after several hours of frustration with things. Even better, it was a Friday, so meant that the week could end well!
Have you ever come across this, and been frustrated as well? Have you got a similar story with something else that happened to you around solutions? Drop a comment below – I’d love to hear!
This is an interesting post, for several reasons. Firstly, it’s the first one in 3 weeks – I was off on holiday, and decided to take an (almost) absolute break from all things digital, which included this blog. It was actually quite refreshing, though now coming back & starting to write again does seem a bit daunting, I’ll admit!
Thankfully, whilst wondering what exactly to start with, a scenario came up that I was working on. It seemed quite simple at first, but then actually got someone complicated. I therefore thought it would be helpful to others if I wrote about it, so here it is.
The scenario was as follows. We had records being auto-created in the system, and needed to create child records for them. This, as I’m sure you’ll agree, is really quite simple to do with Power Automate. We also needed to set lookup values on the child record, that were already populated on the parent record (for reference purposes).
So for example, the parent record has a lookup to Country (being a separate entity), and the child record also has a lookup to Country. These need to be the same.
Being both lookup fields, I figured that I’d be able to take the value from the parent record, and simply plop it into the corresponding field on the child record in Power Automate:
So I did that – and immediately hit an error. Not just any error, but the fabled ‘Resource not found for the segment’ error!
Obviously, I did what anyone would do at first – I put it into Google & Twitter, and took a look at what came up.
The ‘problem’ was coming from using the ‘CDS Current Environment’ connector, which is the latest version available (the old one is no longer available to use). It’s really great for a lot of things, but unfortunately not so great in a few areas. See, in the old CDS Connector, you could just drop the lookup field value into the field you were wanting to populate. Power Automate had no issues with that, & it would run just fine.
However in the ‘new’ CDS Connector, you can’t just do that. Instead, you need to use an OData reference (which I haven’t done much of before, to tell the truth). So based on the blogs I had come across, I went to work to try to get this working.
Part of the challenge was that there didn’t seem to be a unified consensus in how to do it. I came across the following variations:
/entityname(Lookup Field Value)
/entityname/(Lookup Field Value)
/pluralentityname(Lookup Field Value)
/pluralentityname/(Lookup Field Value)
Somewhat confusing, as I’m sure you’d agree. Nevertheless, I ploughed through all of the different possibilities. But nothing was working – every single time, I still got the ‘segment not found’ error message. This, as you can image, was extremely frustrating!
Thankfully, one of my good friends was around & able to help out. Namely, Tricia Sinclair came to the rescue!
We took a look at the code I was using, and she took a look at some of her own use cases (where it had worked for her). I was starting to think down the path of needing a capital letter in the entity name (some systems can be REALLY finicky around things like that), but thankfully it wasn’t.
Instead, it was the following. See, this was a custom entity. It turns out that for a custom entity (& heck, for all I know system entities as well) the syntax needed is ‘publisherprefix_pluralentityname(lookupfieldvalue)’. Now that’s not something that I had come across ANYWHERE at all!
Looking at it, I guess it makes sense. After all it would technically be possible to have multiple entities with the same name, though with different publishers. As a result, the system needs to know WHICH exact entity is being needed for the Power Automate, so uses this. Somewhat complicated (and hey – it worked without all of this in the OLD CDS Connector), but we got it to work!
Testing it out, everything worked smoothly. The Power Automates fired off without any issues, the data got created & populated, and everyone was happy.
So there you go. Another interesting little twist in syntax needed, which hopefully will NOT change in the (near) future!
Have you come across anything like this? I’d love to hear – drop a comment below around it!
One of the main parts of any system is to see who’s available to handle customer service queries. This is, of course, vitally important for any company – you wouldn’t want to overload an already busy agent!
In the case of Omnichannel, the system uses something called ‘Presence’ to show this. When users are set up, they have a default presence set against them. These govern system behaviour, along with having a nice friendly icon that helps from a visual perspective. Omnichannel has the following default options available:
These are available for supervisors to see from their dashboards, so that they can see the status of all agents at a single glance.
It’s also used by the system for auto-routing conversations. For example, if the agent status is ‘Busy’, then they won’t have new conversations routed to them. Similarly, if they’re set as ‘Away’ or ‘Offline’, they also won’t get conversations sent through to them (admittedly supervisors can override this, and assign specific conversations to agents who have one of these set).
Agents are able to change their own presence by clicking on the toolbar, and selecting the one that they wish to set:
But what happens if you want to have some custom statuses? Off the top of my head, I can think of at least half a dozen clients that would want more granularity around this.
Well, thankfully we’re in luck. Omnichannel supports the option for a ‘Custom Presence’!. They do need to be set up through the Omnichannel Administration Hub. To do this, go to ‘Custom Presence’ on the left side & select it. We can see that the default system entries are there.
Before going any further, I do want to point out that we should NOT deactivate or delete the standard Presence entries. It’s possible to do, but it’s going to create MAJOR issues in your system. So please, don’t!
Right – back to things. To create a custom presence, we click the ‘New’ button on the menu bar. We get the following window:
The 4 fields shown are as follows:
Name. The name of the record
Presence Text. The wording that the agent sees when they’re picking their status
Base Status. The default system status that this new status will be based on. This is important, as it will drive the icon used
Description. A ‘friendly’ description of what the presence/status is about. This is useful to keep track of things
Once we’ve saved the record, it’s then immediately available for agents to select! The only thing that agents need to do is refresh their browser tab. This makes a nice change from the usual ’15 minute wait’ for data to update within Omnichannel :).
So let’s go ahead and see what this then looks like. I’ve chosen a very familiar item (for most people):
When I’ve selected this new custom status, we can then see that the icon in the Ribbon Bar changes as well, to the icon for the base status that we used:
So in short, this is quite a nice little piece of functionality. Nothing too fancy or complicated to setup, but will allow companies to further segment their agents & understand what they’re up to.
Something else that we’re able to use this for is the agent ‘Default Presence’, which is set on the User record. Once we have custom presence records in place, it’s possible to select these there:
So apart from having agents segmented by Teams & Queues, we can now also use these. Some very interesting scenarios pop into mind!
So, how do you think you’d apply this in your own environment? Drop a comment below – I’d love to hear!
Many people in the IT scene will know of LogMeIn (https://www.logmein.com/), or LMI for short. For as long as I can remember (which means going back almost 2 decades!) they’ve been one of the main remote access solutions. With their product range, it was possible to leave your computer at home, travel abroad, and easily log into it from practically any computer anywhere.
It’s also a great product for IT professionals. Being able to deliver customer support through remote sessions, manage identity solutions, etc. The number of products over the years has grown, and been quite pleasing to watch:
Pro handles unattended remote access for up to 10 computers, and is aimed at small businesses
Central takes this up to the next level, covering 250 computers, but has all of the admin features that larger businesses want
Of course, LogMeIn Free (a great starter product for personal usage) was removed some years back, which to this I still believe is a great pity. Obviously the company decided to focus on the more enterprise side of things, which I can understand as a business.
So, why am I now writing about them? Quite simple, actually. LogMeIn are one of the providers that are working with Microsoft to provide Co-Browse solutions for Omnichannel! It’s a very new piece of functionality that’s been launched in the Dynamics 365 product, and there aren’t many providers out there that have integration points to it.
What is Co-Browse?
It’s important to understand what co-browsing is, and some useful stats:
“Co-browsing” refers to the ability to have a service provider & customer jointly navigate an application in real time through the web.
Co-browsing: The Gateway to Happy Customers & Better Financial Results, 2015
So co-browsing is useful. But just how useful can it actually be? Well, apparently it can be VITAL:
Co-browse has the potential to bridge the gap between human & AI-driven customer interaction, & to enable organisations to differentiate their customer service.
By 2022, co-browsing will be used in 2% of customer service interactions, up from 0.1% in 2017 (2000% growth).
Gartner 2017: How Co-browsing Can Differentiate Your Customer Service
LogMeIn has had their Rescue offering available on the general market for a while as a standalone product (alongside the rest of their offerings). They’ve now build it out into a new standalone product called Rescue Live Guide, and provided an integration into Omnichannel for Dynamics 365. Customers obviously need to have licenses for the product, but with these, they now have the ability to co-browse during support sessions. Not only can they see what’s going on, but they can also interact with the customer browser itself, providing an even better support experience.
So, let’s go ahead and take a look at how to set it up, the experience itself, and my thoughts on things.
Setup
When I first started testing out the LogMeIn offering, I had to go through a manual install process. This was due to the product just being released (in May 2020), but wasn’t actually that difficult to carry out.
However, they were in the process of switching over to an automatic installation through AppSource, as most of the other apps have. It’s great to be able to see that this has gone live, and is now available for users – it really does make the install that much easier!
Clicking ‘Get It Now’ takes you through the usual route of installing a solution from AppSource: selecting the environment, confirming the installation, etc. After around 5 minutes, I can now see the following:
Once it’s installed, we’ll need to set it as the co-browse provider for the channel that we’re wanting it for. To do this, open the chat record, go to Conversation Options, and select it there:
We’ll also need to put in two records for the LogMeIn co-browse configuration:
Finally, there’s a script block that needs to be added to the webpage where the chat widget is located. This enables the LogMeIn co-browsing ability from the customer side. It can be added right under the chat widget code itself; in the fullness of time, this may be able to be auto-generated as part of the chat widget code, but it’s not at the moment (this is dependent on Microsoft being able to offer it):
Right – setup all done, but before we see it in action, let’s take a quick look at the Rescue Live Guide admin console side of things.
Rescue Live Guide Admin Console
Although the functionality is within Omnichannel for Dynamics 365, administering agent licenses and groups takes places within the Rescue Live Guide admin console at https://console.logmeinrescue.com/admin. As companies will need to have Rescue Live Guide licenses, they would usually be familiar with this.
There’s the ability to create new users or groups, and manage them as well:
It’s also possible to set the names that are used for the agent & customer. These can be either the actual name of the agent, or instead potentially a job role/title:
I’m not going to go further into the admin functionality here – documentation can be found on the Rescue Live Guide site around this. Let’s instead take a look at the experience within Omnichannel, which after all is what we’re here to see!
Agent Experience
So how does this actually work, in practise? Well, from the customer side, they start a chat like they would usually do. When the agent responds, they’re given an option for ‘Live Guide’:
When the agent clicks on this, two things happen:
Firstly, there’s a URL that’s posted in the chat. This contains a link for the customer to click, with an auto-generated ID number
The agent is taken to the LogMeIn Rescue site page in a new tab.
Note: At the moment, the agent will have to sign in manually. LogMeIn have told me that their roadmap includes Single Sign On, so that after the initial setup they’ll be signed in automatically, and not have to perform this step in the future.
Once logged in, the agent will see that the session is ready, & waiting for the customer to connect to it. Once the customer has clicked the URL provided in the chat, it will open the Rescue Live Guide session, and authorise the agent to co-browse with them. They’ll then see the following prompt. This tells them that the session is connected to the agent, and that they can begin:
Once the customer has accepted to start browsing together with the agent, they get some small extra items appearing on their screen:
They can see that there is indeed a shared browsing session happening
They can also see where the agent’s mouse cursor is pointing to (by default, without the agent actually doing anything)
It’s important to note that that the co-browse session is taking place within the specific browser (tab) that is open. Therefore if the user navigates away, the session is paused until they navigate back to it.
On the agent’s side, they can view the customers browser. They can only see what’s happening in the actual tab that’s open for the co-browse session (see below for some more information around this though). It’s quite similar to the customer’s side, though has some LogMeIn features available. Well, obviously it’s similar to the customer – the agent is seeing the customer’s browser window!
They can of course still access the Omnichannel chat itself, and send information through that as well if they wish to.
Just as the customer can see the agent’s mouse position, the agent can see the customer’s mouse position. There are also gesture indicators so that each person can see what the other clicks etc as well, which can be really helpful when walking through a process.
The functionality currently available to the agents covers scrolling (within the page), highlighting, drawing and ‘virtual tabs’. As shown in the image above, the agent is able to highlight text/images, which will then be displayed as being highlighted to the customer. Agents are also able to enter text into text fields, click on buttons, and interact with the native webpage functionality.
Note: The Rescue Live Guide admin centre provides granular controls around these, so that customers can allow agents certain rights, rather than allow them to do everything.
The agent is also able to ‘draw’ on the webpage to be able to point something out, highlight a part of the page, etc.
Note: These annotations will disappear once the customer or agent starts scrolling up/down the page again.
As I’ve mentioned above, the session is taking place within a single browser tab. If the user nagivates away (to a different tab), the session is paused. The agent isn’t able to see any other tabs. So what happens if we do indeed need to open a new tab for something?
Well, there’s a really nice feature that the agent is able to use for this. It’s sort of a ‘virtual tab’ within the browser tab. Sounds interesting!
The customer is able to see this, and can navigate between the tabs. They’re now also able to open a new virtual tab themselves (which is an update to the functionality – originally they weren’t able to, and had to request the agent to do it).
Customer view of the support session
If the customer wants to pause or stop the session, the user simply has to click the ‘Stop’ button in the bottom left. They’ll then be presented with the following screen:
Whilst the session is paused, the customer can continue to use their machine as normal, but the agent won’t be able to see what’s going on. Only if the customer allows the session to resume by clicking ‘Continue Browsing’ will the agent be able to see the customer’s browser once again.
Alternatively, the agent can end the support session themselves, and the customer will be notified about this.
Suffice it to say that LogMeIn have been a market leader for many years in this sector, and I’m happy that sessions through their products are adequately encrypted & protected.
Other functionality
Apart from the above, which is obviously the core of the product, there’s other functionality that’s possible to enable through the LogMeIn Rescue console:
Session recordings. It’s possible to record these for playback, which is then available from the LogMeIn portal. All recordings are carried out from the agent’s viewpoint, not the customers – there is therefore no issue that sensitive information from the customers side could be seen
Data masking. It’s possible to use data masking to hide sensitive information. At the moment the setup for this is a very manual process, so I’m not going to go into how to set it up it here. Having played with it a little, it’s really quite useful. Agents can’t see sensitive information on their screen, and if a customer needs to enter/update information, the session pauses whilst this is being done. However I understand that part of the LogMeIn roadmap for the near future is to make the setup process much more user friendly. When this is released & available, I’m planning to do a post on this
Reporting happens through the LogMeIn portal (see my thoughts below on this). It looks nice, and can be downloaded as a CSV file. Again, the functionality of this is going to be expanded in the near future.
Reporting in the LogMeIn website console
My thoughts
Having gone through testing out the product, I think that LogMeIn has brought a really great product of theirs into the Omnichannel experience. I used to use their products regularly (I ran an IT MSP some years back, in which we used LogMeIn products as well), and always found that they behaved well.
Now having the ability for agents to not only see, but also interact with the customer browsing experience really does take things to the next level. Audio and/or video support is great of course, but sometimes being able to see what the customer is seeing in their browser results in a much quicker resolution. This of course results in happy customers, which is what we’re striving to achieve!
As I’ve said above, I’ve used LogMeIn over the years, and always found their products to be pretty much amazing. With Rescue Live Guide, there are several differentiators that the solution brings to market:
For the standalone solution of Rescue Live Guide dedicated web resources aren’t needed. It’s an easy solution to set up, and for the customer to engage with – all it requires is a URL to be provided to them to get the session going. Obviously, as mentioned above, there is some slight coding needed for the Omnichannel integration, but this is really minor. Any company having Omnichannel installed/configured will already have power users/admin familiar with what’s needed for this, so it’s a very small additional step
It’s possible to co-browse on any website that the customer wants to, not just a single specific website. Once the co-browse session is active, the customer can change to any other website, as long as they do so within the co-browse session tab. Most other co-browse solutions out there can’t do this, so this is a really strong point in favour of this solution.
The data masking is really cool, and for most customers, will be a ‘must have’ rather than ‘nice to have’. I’m looking forward to when the setup for this is updated to be more business-user friendly, and will then do a separate blog post around it, together with a video!
A few things that I think would be nice to have:
The agent is already able to draw on a webpage during the co-browse session, and select different colours for this. It would be great if the agent could also type text in to display on the screen (not in a specific field) in colour. Sometimes being able to see an example written in front of you (without it going into the actual field) can be quite handy.
Being able to transfer the co-browse session to another agent. This could be either another Omnichannel agent, or a separate specialist team. It is of course possible to transfer the chat session to another Omnichannel agent, but then they’d have to start the whole co-browse session again (with a new PIN, etc)
Reporting (for the most part) all occurs in LogMeIn at the moment, as Dynamics 365 only has very limited reporting on this natively. However I understand that this is due to change at some point this year, with the ability to report properly on it within Dynamics 365 itself.
At the point when new items do get released, I’ll be aiming to do a review of them, and add to the knowledge around the product.
So, with all of that, how do you think this could best help you & your customers? Please comment below – I’d love to hear!
I come from an ‘on-premise’ background. I’ve spent years in organisations with on-premise systems such as Dynamics 365. Take me into a server room that’s alive with whirring fans, and I get quite nostalgic. Those were the days…well, in some ways, anyhow. But having recently discovered some quite helpful functionality, I thought I’d share it with others!
See, when it came to Dynamics 365 security, there was no way to automate things. Yes, users had to be created in Active Directory (and also, in a folder that the Dynamics install could refer to within AD!), but they had to be manually added to Dynamics 365. There was no way to automate this (from recollection – then again my memory grows dim with the fog of time).
So what the system administrators needed to do was to manually go to Settings/Security within the system, and there they could either add a single user at a time, or multiple users. They would then assign role/s (for multiple users, all of the users would need to have the same role/s – it wasn’t possible to modify individual users within this process).
One way to slightly speed up time in handling different security roles was to have teams, relating to the business needs. The security role/s would be created, assigned to a team, and then any user added to the team would automatically get all of the permissions that they needed.
Then came the heady world of Dynamics 365 being online! Well, nothing much changed really, at least not for a little while.
But then, things really did change, in May 2019. Functionality for security teams within Dynamics 365 was increased. Notably, there was now something called a ‘AAD Security Group Team’:
So what was this magical new item?
When we create a team, and we set the Team Type to ‘AAD Security Group’, we’re now able to set an AAD Object ID. In fact, it’s required! After we’ve created this object within Dynamics 365, we can then apply security role/s to it directly (as we could to any other team records beforehand):
Let’s take a moment to reflect & think on this. Until now, we’ve had to handle security directly within Dynamics 365. Now, we have the ability to have an Azure Active Directory (for that is what AAD stands for) group, and reference it within Dynamics 365.
Suddenly new possibilities open up. As part of the on-boarding process (for example) we can users to specific AAD security groups, which will then give them access with appropriate permissions within Dynamics 365. We’re also able to have multiple AAD groups, each inheriting a different set of Dynamics 365 roles, and thereby create a multi-layering approach to different business & security needs.
We’re also able to use tools such as PowerShell, LogicApps, Power Apps & Power Automate to carry out automation around this. There’s an Azure AD connector (https://docs.microsoft.com/en-us/connectors/azuread/) which gives the ability to set up & administer these.
We’re actually using this functionality now in some of our COVID-19 response apps. Instead of needing our own support desk to manage the (external) users, we’ve provided an interface where client IT departments can quickly log in, upload a list of users, and assign them to the relevant AAD group/s. It’s very quick, and allows the users to onboard to the Power Apps within minutes!
So with knowing this, how do you feel it might help benefit you? Comment below – I’d love to hear!
One of the really nice things about the Omnichannel Agent experience is that it uses tabs. The conversation itself is in the left side of the screen, with the Customer Summary open in the right side of the screen. However this isn’t fixed into place – it’s possible to open additional tabs next tot he Customer Summary tab, and navigate to various places in the system.
This allows agents to easily look up additional information on records such as contacts & cases, as well as other places.
Agents are therefore able to quickly flip between different system records, getting the information that they may need to satisfy the customer interaction.
So that’s great. Clicking the + icon on the tab allows new tabs to be opened, and the agent can select which record type they’d like to see:
The system allows movement between these if they disappear off the screen with arrow buttons being available:
So all of this is really good, and is provided as system default behaviour, without any customisation or configuration being needed to be done.
So let’s now think about several other types of scenarios, and see what could be done to enable them:
You want the agent to see a dashboard showing how long the production line is currently taking with different order types
You want to be able to look up an item in another stock system
You want to carry out a custom search in your distributor network
All of the above items (and many more) are things that aren’t native within Dynamics 365. It’s therefore not possible to display this with native system functionality…or is it?
Well, it is! Omnichannel has something called ‘Application Tab Templates’. These allow you to specify custom tabs to open when a chat start. With these, you’re able to point to any web-based resource, even if it’s not within Dynamics 365!
Note: It’s not possible to point to a bespoke desktop application using Application Tab Templates. The resource that you’re wanting to point to needs to be web-based. This is one of the main differentiators between Omnichannel & Unified Service Desk – USD allows you to point to a desktop/server application within the window.
Setting up a new Application Tab Template is not too difficult, thankfully:
We’re able to select what the Application Type should be. There are various options here, including web resources, ‘third party’ websites, entity lists, etc:
When we save the record, we can then input the necessary parameters for that type. These parameters are system-defined, so we have to work within these, and can’t add any additional ones (at this point in time). We can also use values from pre-chat surveys based on information that the customer has provided before the chat starts. Imagine being an agent with a new conversation, and you already have the entire purchase history for them open, or their billing records!
Once this has been created, the next step is to associate it with a session template. Session templates govern the following items:
The behaviour of the chat by default (Docked, Minimized or Hidden
The name of the session
The application tab/s that open (you can add as many as you want to)
The agent scripts that are available to be used.
To do this, open the relevant session template, and then add the application tab/s to it that you want to appear:
Save & close the session template record, and refresh the agent interface. When a new chat session comes in, Hey Presto!
Using the ability to have different chat widgets, it’s possible to customise each one in a different way. So for example:
The Sales team could have the distributor system open, to know how long it’ll take to fulfil an order
The Billing team could have their invoice/finance system open, to have the customer billing history
The Motorbike Servicing team could have their system which tracks all work done on your motorbike open, to see the entire service history
It’s really up to you how you choose to best make use of this. I feel it’s really quite helpful, and will cut down on the time that agents need to spend to pull up different pieces of information to help the customer.
How do you think you would use it in your company? Comment below to share 🙂
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.
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.
I originally had a different article planned for today, but with the current situation that’s happening over the world, I decided to change what I was going to talk about.
The world has gone crazy, in so many ways. There’s plenty of information out there around what’s happening, and with best advice to people as to how to deal with things, cope, etc. I’m not going to cover that (besides, it’s likely that things will change over time, which means that anything I write could be out of date soon).
Instead, I’m going to address one of the specific issues that I’m seeing again and again. This is the bottleneck that people are facing when trying to contact companies, whether the company is their bank, their utility provider, their health provider, or even travel companies.
Regardless of whether people are trying to cancel an existing holiday & get a refund, speak to their bank to get a mortgage holiday, or get medical advice, they’re facing the same major issue – they’re not the only ones trying to get through. Phone lines are jammed (assuming that they’ve not been stopped due to agents being sick), static forms where you fill in information aren’t liked (as you don’t know what the actual status of things are), and online chat takes an absolute age. I had an online chat session with Amazon two days ago, and it took over an hour for one of their associates to join my session to help me.
Go to any major company website, and you’ll probably see something like the following (this is from British Airways):
I’d like to be clear – companies couldn’t really have forecast all of this happening, if you’d go back several months.
But what companies can, and should have in place, are clear communication protocols that actually enable them to handle a massive scale-up of customers contacting them. It’s not going to be perfect, but can help mitigate the bottleneck to certain degrees.
Having an efficient system can allow a single agent to handle multiple communication streams at the same time. Indeed, it’s not just about handling multiple web-chat sessions concurrently – it’s also about handling communication across different mediums. So agents can handle webchat, Facebook messages, Twitter DM’s, etc.
This is, I believe, where products such as Omnichannel for Dynamics 365 can really come into their own, and shine through. Using it, companies can ensure that their workforce (which is likely to be impacted as well by the situation) can be as best empowered as possible, and assist customers as speedily as they are able to.
Hopefully the current situation will resolve itself as soon as possible, and coming out from it, we should look to carry out any efficiencies that we are able to. This will allow companies to better serve their customers moving forward, and streamline communication channels.
I hope & pray that everyone stays safe & healthy through this crisis, and that we help each other out (to the best of our abilities) to get through it.
