Thoughts & musings from a Microsoft Business Applications Ninja!
Finding out about Mark getting Jon Levesque dressed in a kilt at Scottish Summit, and how that went. Also discussing how Mark’s first foray into consulting occurred, and how he learned all about project time projects for clients.
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
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.
For the last few days, I’ve been working on an app. Not just any app – it’s a canvas app! (It actually happens to be a COVID-19 related app, for local authorities to use to contact vulnerable people & check they’re OK etc).
Now, my background isn’t canvas apps – it’s the model-driven app approach. I’ve been doing this for years – after all, my experience goes back to Microsoft CRM 3.0! So that’s all really nice & easy for me (even with some of the more modern ‘tweaks’ that have been brought in). Canvas apps, on the other hand, are very different from what I’m used to, and are taking quite a bit of getting used to.
See, the following example is easy in a traditional model-driven app:
Create a contact, save various attributes to the contact record. Then create a task, and set the Task Regarding field to the contact that you’ve just created
Looking at that, my mind says ‘easy-peasy’!. I create the fields required for the contact entity (& task entity as well, if needed). I then add them to the entity form/s (creating or modifying the form view/s as well). Finally, I create a Business Process Flow for users on the contact entity, and append the task creation to it. Simple, and done – not much time needed to be spent.
But when needing to do this as a canvas app, things change around QUITE a bit. I can’t create that business process flow, and I have multiple screens to have all of the information on.
Now, if I could add the ‘Regarding’ field to the edit form grid, and apply formatting to it, I could hopefully then just submit & save the grid. However, that unfortunately doesn’t work. I can add the field, but when I do so, I get the following:
So that doesn’t work. Hmmm – how then should I go around doing it?
I did (obviously!!) take a look online. Here I came across this wonderful article all about polymorphic lookups (https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/working-with-references). Having read, & re-read through it, I’m STILL not understanding what exactly I should be doing by this!
So I was stumped. Thankfully we have an amazing community, and on reaching out to someone within it (thanks Eric!), I was helped out. I therefore thought to write this post up, so that it can help others as well.
There are two parts to this, for my specific scenario:
So, how did I go about using the Patch statement? Well, the function is referenced here – https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/functions/function-patch. With Eric’s help, I soon started to see how to do it.
What I did was add the following line in my Patch statement when I was wanting to save the task: ‘Regarding:ContactForm.LastSubmit’ (‘ContactForm was the name of the form for the contact information). What this did was write into the record the GUID for the contact record that I last saved.
An alternative to this would be to use a variable instead, and set it there.
Thankfully this all worked. I’m now able to create Task records and set their Regarding field value to the Contact that I set up before them – which is the exact thing that I was trying to do!
I hope that this has been helpful – leave a note in the comments if you’ve found another way of doing this.
Finding out how Sara decided to get a dog (no, she didn’t dog-nap someone else’s!), starting out as a Dynamics 365 customer, actually getting involved in customising the solution, and why things went so wrong when updates were released.
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
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.
Having applied the Wave 1 2020 release to several of my test environments, I was browsing around to see the new functionality within it, which is pretty good. However, there was something that I wasn’t expecting, which was a little startling to see! This is around the way that the search behaviour is now working within the system.
What am I talking about? Well, for years, users have asked me if they could search within a specific view. Ie if we had a view set up for ‘My accounts’, where the user is set as the account manager, it would show only the accounts where that condition applies. However when using the search functionality, the system would search & return ALL results that match the search criteria (eg if searching for ‘Apple’, it would return all accounts with the word ‘apple’ in them, regardless if the user was set up as the account manager or not).
Explaining this to users was probably the most complicated thing, in my experience (well, that, and having to then trawl through hundreds, if not thousands of records, where it’s a common word). But for the most part, they accepted it. OK – we all moved on.
Let’s see an example of this. The screenshot below shows an account that exists within one of my Sandbox environments (which has the Wave 1 2020 update applied to it):
I’m now going to search for it within the entity itself (more about Global Search at the end of this post):
Hold on – it’s not showing up! What is happening here – is the system OK???
Let me explain what’s happening. Previously (before the Wave 1 2020 update was applied) it would indeed show up in the search results.
But this has now changed! The system is now performing searches ONLY within the view that the user is using. The reason why it’s not showing up here? Well, it’s because I’m not set as the owner of the account – a different user is (and I’m using the ‘My Accounts’ view, as seen in the previous screenshot):
If I now change my view to ‘All Accounts’ and repeat the search again, the record now shows up:
I hadn’t come across this in my perusal of the release notes. On going back to it and digging deep, I found the mention here – https://docs.microsoft.com/en-us/power-platform-release-plan/2020wave1/microsoft-powerapps/improvements-quick-find-search-experience-grid.
Amusingly there’s actually even a little hint within the system for this. If you look at the entity search box, this is now the text that’s being displayed within it:
There’s also an additional feature as part of this – if you’ve prefiltered a view using column value, searching within the entity will RESPECT the pre-filtering!. OK – now this is indeed incredible:
My thoughts on this is that it’s going to be a double-edged sword. For years, we’ve been educating customers about how searching works, and now this has the potential to change things up.
Thankfully it’s actually possible to turn this off, and revert back to the way that searching has always worked – this is likely to be needed to be done quite a bit. To do this, go to Settings, Administration, System Settings, and change the value for Categorised Search to ‘Yes’ (it’s about 1/3 of the way down the page):
It would have been nice if Microsoft had made people more aware of this, in my opinion.
Please note that this only applies to searching within an entity itself. Global Search (for the moment) still uses the Quick Find view, and returns all results (regardless of filters).
Exploring how Malin got into micro-brewing, her fondness for the product formerly known as ‘Talent’, and the family love for beer. Also finding out how she switched into consulting in the first place (spoiler: she didn’t start out in consulting!)
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
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.
Discussing how LEGO is of vital importance in teaching & business applications, and what happens when Scrum isn’t performed properly on a client project. Neil also runs a Scrum for Business Applications course – https://customery.academy/courses/foundations
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
In general, it’s usually quite useful to be able to see how customers are engaging with your company, and how they’re feeling about things. If customers are disgruntled, annoyed, or complaining, it’s important to be able to understand the root cause/s of their issue/s, and resolve them as soon as possible.
One of the tools available in Omnichannel is Sentiment Analysis. What is this?
Being able to identify how customers see/interact with your brand, accurately, is vitally important. Using people to manually trawl through your data to attempt to identify this has many drawbacks:
As a natural follow-on from this, being able to identify & categorise the sentiment in customer communications through using machine learning can unlock many business use cases that can then result in immense value for your company.
Microsoft provide the ability for this through Azure Cognitive Services. It’s really quite interesting in how this actually works. You can go to https://azure.microsoft.com/en-gb/services/cognitive-services/text-analytics/, put in a sentence, and see what results come back. It can be quite amusing to see what different colours come out as!
As part of the analytics around chat (and by chat, I’m not referring to just a chat bot – anything within Omnichannel can be referred to as ‘chat’, from an agent perspective), sentiment analysis can be used.
This is quite easy to set up. To do so, open the Omnichannel Administration Hub, go to the Settings area in the left-hand menu, open ‘Sentiment Analysis’, and click to enable it. Remember to save it to apply it!
This will then result in the agent interface showing the following:
Now, this isn’t static. The sentiment will update in real time as the conversation continues, and will change based on what the customer is saying.
Now, obviously we’d expect agents to be able to judge the tone of the conversation based on what’s being said (at least I’d personally expect it). So for this, the sentiment that shows within the chat isn’t that helpful.
However, it does come into its own in a slightly different place. This is the Omnichannel Sentiments Analysis Dashboard, which is served through PowerBI.
Through this, supervisors can understand how their company is measuring up to their KPIs & necessary trends. They can also understand the overall support experience that omnichannel is having, along with tracking the sentiment of customer interactions. As a result of having this to hand, better understanding of customers can take place, resulting in improvement of the overall customer experience.
Once the dashboards have been configured within PowerBI (I’m going to do a separate post on this), it’s then possible to surface these within the Omnichannel Customer Service Hub (which users with the Supervisor role will be able to see). This means that supervisors won’t need to open a separate place to see these; it’s all available through the same interface.
There’s also a more detailed view into what’s actually happening, through the ‘Omnichannel Insights – Sentiment Analysis Report’. This displays a lot more information, drilling down & splitting the data up into agents, queues, channels & trends. Here’s an example of this:
With all of this information as the fingertips, it’s now really possible to drill down into the details. Through this, we’re able to carry out full & proper analysis on what’s actually causing customer interactions. From looking into what’s occurring, it’s then possible to review the current state of things, and see what can be improved. This will then result in more positive sentiments shown by customers, and drive their loyalty to the company!