Tag: microsoft

Omnichannel Macros

I’ve previously touched on macros in https://thecrm.ninja/omnichannel-productivity-tools/, but with some new functionality that’s now come out, I thought it would be quite interesting to dive deeper in them. By doing do, we can see how they work, the functionality that they offer, and some really cool & interesting scenarios!

Let’s have a quick reminder of what macros are all about (for those who don’t know, yet):

Macros allow customer service agents to carry out repetitive tasks that can span multiple entities. Eg opening forms (model-driven apps), pre-populating data into the form, etc. Through this, not only are there less manual tasks/steps to carry out, there’s now the ability to carry out the same tasks, without worrying about a step being missed, or the wrong data copied in, etc.

With that in mind, let’s see what there is for macros in Omnichannel. As a default, there were always the following 3 pre-defined automation actions:

With these, we’re able to do things like:

  • Opening a form to create a new record. This could be used to create a new contact automatically
  • Opening an existing record. This could be used to open an existing contact (based on pre-survey questions, such as email address etc
  • Searching the Knowledge Base using specified keywords/phrases
  • Opening an email form with a pre-defined templated
  • Linking records together

There’s now a new option available:

Hmm. This looks interesting. What happens when we select it?

We get a condition block! Clicking ‘Add an action’ will allow us to then add either one of the pre-defined automation actions, or another Control/Condition block.

OK – so you’re now thinking that I’m getting over excited about this. But hold on – let me explain further why I’m really liking this.

So when using Power Automate, frequently I’ll use condition blocks to check/satisfy things (it’s obviously available in Logic Apps as well, but I have minimal experience of those to date). Some of them can get quite advanced, but it comes in useful. However for Omnichannel macros to date, it’s not been possible to do this. We’ve been limited to just a few options, without being able to specify branching criteria based on variables.

Now we’re (finally) able to do this. The Condition field works in the same way as Power Automate does, with being able to string multiple statements together, and have actions that result from them. We’re also able to use slugs in them, to populate variables & use customer-entered data.

Let’s see an example of this. We have a customer who’s opening an Omnichannel chat session. They’ve filled in the pre-survey questions, in which we’ve asked for the following pieces of information:

  • First Name (required)
  • Last Name (required)
  • Email Address (required)
  • Company Name

With the condition check in place, we can either create just a contact record (if the customer didn’t fill in the company name field), or we can create both account & contact records, and link the two together. We could also check if the customer already exists as a contact, and then not need to create any records for them.

This means that there will be much less manual work for the agent to carry out, as they won’t have to manually create all of these records.

We’re able to string these together in ‘multi’ step scenarios, to allow things to flow on from each other:

There are also other options available to use, such as the ability to clone, and the ability to open a new application tab. I’ve covered application tabs at https://thecrm.ninja/omnichannel-application-tabs/, so we can see how helpful this could actually be. We wouldn’t need to automatically open a specific system for all customers contacting us; instead we’re able to selectively open things based on the actual customer. This makes for a much cleaner & better agent experience, in my opinion.

In summary, this is a really helpful & useful feature that’s been added, bringing even better functionality to macros. We’ve been able to do these sorts of things elsewhere to date, and being able to do it here now as well is great. All I can say is that I’m wondering what else we could do…perhaps kick off a Power Automate Flow as well? We’ll have to wait and see 🙂

Omnichannel & Application Tabs

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!

Note: For a full listing of the parameters available for each application type, please refer to https://docs.microsoft.com/en-us/dynamics365/omnichannel/administrator/application-tab-templates#application-types

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 🙂

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.

Workflows & Managed Solutions

This is about some interesting behaviour around workflows & managed solutions, which I’ve recently discovered. Let me give a bit of background first.

Currently I’m working on several COVID-19 apps for local authorities, to be able to help them assist people in need. As part of this, each local authority has a portal within the solution. The portal itself is a Power App Portal, and I haven’t really had exposure to them before.

blog.atwork.at | Hello, PowerApps Portals (and external users)!
Default portal view, not the one we implemented!

Installing a Power Apps Portal comes with quite a large number of solutions in order to get it to work. More on this below.

Due to the way in which we’re engaging with our clients, the solutions are built in a single tenancy (different environments, of course!). We’re then inviting the users in as guests through Azure Active Directory, to be able to access functionality etc. This works well – we don’t need to worry about managing user accounts, AAD permissions, etc. However it also means that we don’t have any Office 365 licenses within the environment itself.

Now we have workflows that are sending emails out around the portal – registrations, password resets, etc. These are being generated automatically by the system, but as there’s no Office 365 mailbox for the user, they’re queuing up.

It’s not possible to authenticate a mailbox belonging to an external user (we tried!), as the system needs a native (full) user with an active mailbox to be able to send out emails. This is of course unlike Power Automate, where you can create a Send Email action and use specified credentials for logging in to send an email.

So, we did what any normal system administrator/configurator would do. We opened up the relevant (managed) solution, and from there opened up the workflow that we needed to modify. Things looked normal at first – we deactivated the workflow, and started poking around it to see what made it tick.

We came across the part that actually took user credentials to send the email that was being generated, and modified this accordingly. Then we saved the workflow, which was successful. However, upon trying to then reactivate the workflow, we got the following error message (helpful, isn’t it!):

Nicely it gives the option to download the log file around the error. This can usually be quite helpful (at times), so we thought we’d take a look at it. Behold the following (I’ve had to shrink the screenshot to allow it to fit on the screen!):

Isn’t that ‘beautiful’. Don’t worry if you can’t actually make out the error information – none of it makes any sense, at least not in a practical sort of way.

Being stuck at this, I thought to reach out to one of the community Power App Portal champions, Mario Trueba. I’ve known him for a while, and he’s just simply amazing. Having asked if I could jump on a call with him for 15 minutes to diagnose (& hopefully find an answer!), we spent almost an hour!

He suggested trying to use the classic interface, as I had been doing all of this through the new UI. So off I went to open up Classic (I’ve missed this, I will freely admit). Through there, we opened up the solution, opened up the workflow, and re-activated it. Or not, as it happens – even through the Classic UI, we weren’t able to do so. We tried a variety of things, but to no avail. It just simply wasn’t happening!

I was slightly concerned that there was an underlying issues with Portals, perhaps from some legacy CafeX code. I had tried searching with Mario for error details contained within the log file, but we couldn’t find anything that would fix it.

The next morning on waking up & checking Twitter, I noticed someone tweeting around Portals, and engaged with them. They turned out to be on the Portals development team, and told me to shoot them over an email with the details, which I did. They then replied to me, saying that it wasn’t anything specific to Portals, and that I should raise a support ticket. That crossed one item off my list (a Portals issue), but I was still needing to get things resolved.

So I went off & raised a support ticket. A few hours later, a very nice tech support person called Siva gave me a call to discuss the issue. We hopped into Teams, and in what I can only describe as the SHORTEST period of time that I’ve ever experienced, the issue was resolved (it took 7 minutes in total. Yes, I know…). Don’t worry – I’m not going to leave you hanging here!

See, what the ‘issue’ (and I’m deliberately putting it in quotes) was turned out to be something quite simple, yet quite strange.

Essentially opening the workflow from the managed solution somehow (& I don’t know HOW) inherits the ‘managed’ property. This is whether we open it from the new UI, or the classic UI. As a result we’re able to deactivate it, but we CAN’T reactivate it due to the system thinking that we’re modifying a managed component (as an aside, it is interesting how I did manage to save it though?). This was what was causing things to fall over, and the error message was really not helpful at all.

It’s also not a matter of being a Microsoft (or ISV) managed solution. I’ve replicated this happening with a solution that I’ve built, exported as managed, & then imported.

So how did we do it? Well, there are two ways in which this can be dealt with:

Either we can go to System/Processes, find the workflow there, open it up, and then reactivate it:

Or we can open up the Default solution, navigate to processes, select the workflow, and then reactivate it:

Both methods work just fine, and as mentioned earlier on, I’ve since replicated this on workflows in other managed solutions.

To me, this is somewhat strange, and should work regardless. According to Siva, it’s the desired system behaviour, though I have no idea why someone should want it to work in one way, and not in another.

So if you’re reading this, and you might just happen to know someone in the necessary Microsoft engineering/development team who’d be able to answer this, could you point them my way? I’d love to engage them to find out why, how, and if they could pretty please change this?

Omnichannel Supervisor Tools

While I’ve covered a lot of different pieces of functionality from both the end customer & agent experience, I haven’t really touched on the Supervisor experience to date. With the release of a nice little piece of functionality for it around Sentiment Analysis, I’ve therefore decided that it would be a good time to take a look at it.

Now obviously supervisors exist, in the sense that any contact centre would have managers in place to manage the agents. Indeed, they may actually handle customer queries directly as well – miracles have been known to happen! 😉

Really the aim of the supervisor role within Omnichannel is intended to help customer service managers or supervisors enhance their team’s performance and improve customer satisfaction. They need to ensure that customer queries:

  • Are being responded to quickly within an accepted period of time
  • have agents that are providing the right information necessary to handle the query
  • Are handled in a satisfactory way
  • Leave the customer feeling positive & satisfied around the interaction

To this end, the supervisor role includes access to various dashboards & views on the sessions that are taking place. From this, they’re able to ensure that KPI’s are being met, that queues aren’t overflowing, and that agents are carrying out the right work.

Please note that PowerBI Pro or PowerBI Premium licenses are required for users with the Supervisor role in order to access & view these dashboards

On-going Conversation Dashboard

The on-going conversation dashboard is one of the first tools available to supervisors. In this, they can see the entire ‘landscape’ at one glance, covering:.

  • Which conversations are currently active
  • The queue that the conversation has come through
  • The channel that the conversation has come through
  • Which agent is currently handing the interaction
  • The sentiment of the customer experience (more on this below)

Through this, there’s a wealth of knowledge that the supervisor can use. If a conversation doesn’t appear to be going well, they can reach out to the agent who’s handling it, and ask if they need assistance. They can be ready to offer escalation resolution should it be needed.

Supervisors are also able to allocate any conversation that’s an in ‘Open’ state (ie it hasn’t yet started) to a specific agent, or to a specific queue.. They would do this by selecting the conversation in the window, clicking the Assign button (which appears when the conversation is selected), & selecting either Agent or Queue. Depending on which option is selected, they can then select the agent or queue that they wish to.

Furthermore, supervisors are also able to monitor any conversation that is happening (as long as it’s in the Active or Wrap Up stage). When doing this, the customer & the agent don’t know that the supervisor is monitoring the conversation (unless the agent requests it, of course). Through this, they can keep an eye on how things are going, and if they feel it’s necessary, they can join it (without needing to be invited to it). Of course when they join the conversation as an active party, the customer is then notified about it.

To do this, a supervisor would select the conversation (providing it is in the ‘Active’ or Wrap Up’ state) and then can click ‘Monitor’. This action triggers a new session for the supervisor to be pulled into the conversation.

Sentiment Analysis for Supervisors

So one of the really cool features (in my opinion) that’s recently appeared is the ability to use sentiment analysis to automatically alert supervisors.

You’re able to choose the level of sentiment that you want supervisors to be alerted on. When a conversation reaches the predefined level, the supervisor will get a prompt like this:

Sentiment analysis notification

They can then click through to either monitor the conversation (& help out if necessary), or to ignore it. This can be really helpful as it’s allowing the supervisor to be proactive, rather then needing to keep a close eye all the time on the supervisor dashboards. Indeed for a large contact centre, there could be dozens or even hundreds of conversations happening at the same time, so this will immediately flag these conversations to them.

Intraday Insights Dashboard

The Intraday Insights dashboard gives information around KPI’s that are in place for the company. This does need to be configured before supervisors are able to access it – I’d recommend looking at the extensive guide on how to do this at https://docs.microsoft.com/en-us/dynamics365/omnichannel/administrator/configure-intraday-dashboard-supervisor.

There are two sections that are included:

  • Conversations insights
  • Agent insights

Conversation Insights

This section gives supervisors insights into conversations that have occurred over the last 24 hours, against a range of KPI’s. This is therefore a ‘rolling state’ dashboard, without the ability to go back further over time, or pick a specific date-range. If this ability is needed, then the Agent Insights dashboard will be used.

Conversations insights dashboard

As you can see from the image above, we’re looking at metrics across different sorts of KPI’s:

  • Average wait times
  • Average handling times
  • Conversations exceeding specified criteria

This can be very helpful on an on-going basis to see how the contact centre is performing overall, over the time period. Drilling down into these items can help identify bottlenecks & choke points, which can then be worked on to provide better service & efficiencies.

Agent Insights

This part of the dashboard gives information across various health & status items on any given day. Using this, supervisors can drill down into issues that may not be visible through the conversation insights dashboard.

From the screen above, we can see that things like conversation states, agent status & participation modes are available to view.

Because these are PowerBI dashboards, it’s possible to drill down further into them, filter by item (eg queue, agent, etc), and see very specific stats about items.

I hope that this proves to be helpful in understanding some of the tools that are available within Omnichannel for supervisors, and the help that they can give in running an efficient and productive contact centre!

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 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!

Canvas Apps & renaming field labels

Today I want to share with you something that I’ve realised. Changing field labels can have unintended consequences!

Let’s cast our minds back to the days of ‘traditional’ Microsoft CRM, or as it’s so lovingly referred to nowadays, ‘model-driven’ apps. What you had were a number of entities (eg Accounts, Contacts, etc), all of which contained fields. Fields could be different types (text, integer, boolean etc), and have varying properties on them. You could set them to be required (or not), searchable (or not), and have so much fun.

At the heart of a field is the name that it has. Well, technically there are two names. One is the actual database name. Once a field was created & saved, this was effectively written in stone. The only way to handle a situation where you spelled this incorrectly was to delete it, and then recreate it. Even then, it could still be floating around in the back-end database in its original form.

The second name is the Display name (or Display label). This was the text used on the entity form itself, & could be changed as desired. This was actually really useful – many a time a business unit would say something like ‘we don’t want the field to show as Zip/Postal Code’; we want it to say ‘Postcode’. Well, that was easy enough to address – simply go ahead, load up customisations, & change the display name property for the field. Everyone was impressed & happy, and could get on with their work.

There were of course times that Business Unit A would say ‘I want ‘ABC’ as the display name’, and then Business Unit B would say ‘Ah, but I want ‘XYZ’ as the display name!’. To handle this, it was very possible to customise the label on the form itself, which would then override the display name value. This, of course, would only be valid for that specific form, so it was then imperative to have different forms for the different business units.

Now, in the good old days we use to create SQL queries against the database, SSRS reports, etc. In order to do this, we needed to know the actual underlying (database) field name. We could of course open up customisations, & start trawling through, but there are better methods for doing this. One of these is Level Up by Natraj Yegnaraman. This can be found at https://github.com/rajyraman/Levelup-for-Dynamics-CRM, and is an extension which can be run on Chrome, Edge on Chromium, & FireFox).

Using this amazing tool, it was possible to merely load an entity form up in an existing system, and then TADA! At the click of a button (well, two clicks actually), the underlying database name was revealed. This was an absolute lifesaver, so many times.

So there we’ve been, toddling along for many years like this. It worked, and worked well. All was good.

Then came along canvas apps. Now I’m not a canvas app guru by any means – I’m quite new to them, and still trying to wrap my head around the ‘special’ way in which they operate. Thankfully there are quite a few gurus in the community who have given me help in one way or another to learn how to carry out various functions, and I think that I may JUST be starting to get the hang of it.

With the current COVID-19 situation, I’ve been working on a series of apps for work, to help local authorities. One of these is a canvas app for call centres, to record information easily & quickly. We chose to go down the canvas route due to being able to have a clean layout, as well as being able to display information for the operators to read. This would have been much more difficult in a traditional model-driven app, especially as such things as dialogues have been deprecated.

One of the functions that I’ve had to learn to do this has been to use the ‘Patch’ function (see https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/functions/function-patch for more information on this. The following is an example of one of the Patch statements that I was using:

This was working remarkably well – it was creating the task record, and setting all of the different values that I needed. For those who are curious as to why I was using a Patch statement, rather than submitting the form, it was due to needing to set the ‘Regarding’ field, which has some very special behaviour!

Then someone on the team said ‘Hold on – we’re only storing one address. Let’s change the field display names to remove the ‘Address 1′ part, so that we don’t confuse users’. OK – I didn’t INITIALLY see any issue with this. I bet that you can see what’s coming through…

Yes – you’re right. The patch statement isn’t referring to the field database name. It’s referring to the field display name! The reason for this is that this is the syntax that Canvas Apps use – there doesn’t seem to be a way to refer to the actual underlying field database name

Of course, I only actually discovered this when I ran through the canvas app again. And indeed, it was whilst demonstrating it to other people! Oh joys – what a wonderful time for it to happen.

So, I then had to figure out what had happened – thankfully that didn’t take too much time. What DID take time was going through every single place in the canvas app that had code referring to the specific fields, and update them to the new (correct) values. This therefore ended up looking like:

So, the vitally important lesson to learn here is be VERY careful when changing field display names, especially if you have one (or more) canvas apps that are referencing them. The last thing that you want is a major headache in having to go back through every place that refers to them, and changing/updating the values.

The only workaround that I’d suggest, is that if you’re wanting to change how fields display in the canvas app itself, change the ‘Text’ value for the field:

That way, HOPEFULLY, nothing will break moving forward.

I hope that you’ve found this useful. If you have a different way in which you’ve handled this situation, feel free to leave a comment below!

Farewell to the Outlook Add-In

From the first time that I used Microsoft Dynamics CRM (all the way back in the day), I remember the Outlook add-in. Or rather, I should say that I remember the PAIN that the Outlook add-in was!

You remember what I’m talking about, I hope. Here’s a screenshot of the ‘fabled’ toolbar:

The installation of this was a nightmare, to be honest. From the pre-requisites that it needed to install (and download – even if the machine already had them installed), to just hanging there, it wasn’t ever something that I looked forward to putting on machines.

It was a memory hog, slowed performance, and occasionally crashed Outlook, seemingly just because it felt like it! In addition, trying to carry out a mass roll-out of it (through SCCM, or Group Policy, or even other methods) never seemed to work properly at all.

In one of my roles we had to install this for dozens of users. Randomly, even on brand new machines (with nothing else installed), it would fail to install or initialise. Long hours were spent poring through logs, trying to work out error messages, and frantically get it working. Users were VERY used to seeing the following error happen:

In short, it’s been around for a VERY long time, as the following diagram shows (I’m loving how they compress 12 years into just a short space):

In late 2017, Microsoft announced that they were going to deprecate the Outlook add-in. There were several other options around, such as proper server-side sync, and the Dynamics 365 app for users. These were supposed to be being used instead.

The response from clients was crazy – so crazy in fact, that Microsoft did something that it very rarely does. They reversed the decision to deprecate it, and instead confirmed that it would still be sticking around. They realised that the other options weren’t at parity with the Outlook add-in for desktop, and didn’t want to deprive users of the essential functionality that they were needing.

In 2018, I was at Summit EMEA in Dublin. One of the more interesting conversations that I had with one of the senior Microsoft people was around the Outlook add-in. They told me that from the moment that Microsoft had announced that it was deprecated, every client had asked them about it. Even to non-technical people (eg sales, etc). It was due to this, in part, that they decided to un-deprecate it!

Moving on several years, the landscape has now matured. A lot of users are using Outlook through browsers, rather than the desktop version. They natively plug-into Dynamics 365 through the web as well. The Dynamics 365 App for Outlook has gotten better, along with the way that it works:

Users, on the whole, seem to have generally adopted the latest technology, and have therefore moved on from relying on the Outlook add-in for desktop. There’s also the new Unified Interface, which the Outlook add-in doesn’t support (and which will be being rolled out to all users on Dynamics 365 during 2020!).

Microsoft has therefore announced that as of March 2020 (which has just passed), the Outlook add-in has now been deprecated (once again). Support, security & other critical updates will be continue to be provided until October 1st 202, but customers will need to transition to the Dynamics 365 App for Outlook by then.

Very nicely, they’ve provided a playbook (which can be found at https://aka.ms/OutlookCOMPlaybook). This details the upgrade path, and has some good information in it for customers who will need to upgrade from it.

So if you’re still on the old version, take a look now, and work out the best way for you & your organisation to upgrade. It’ll give you newer & better functionality, work easier, and above all, shouldn’t crash your machine!

Let me know in the comments if you have any questions around this, and I’ll do my best to help you out.

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.