Thoughts & musings from a Microsoft Business Applications Ninja!
Discussing mutual interests of motorsport, racing motorbikes, seeing races, & having amazing adrenaline rushes! Also covering thoughts in our heads that we might have said out loud by mistake, and some quite interesting comments around dress codes at 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.
As a starter for 10, this wasn’t actually the blog post that I was going to write today. In fact, the subject of the post wasn’t even going to be about Power Automate! However, there was some really amazing news that dropped today from Microsoft, which I just couldn’t pass up being able to talk about.
You’ve guessed it – it’s about Power Automate! Well, I suppose that the post title was somewhat of a giveaway, wasn’t it…ah well. So let’s go ahead and find out what this is all about then!
To date, we’ve been able to put Power Automate flows into a solution. Well, it wasn’t there exactly at the beginning of things, but it happened somewhere along the way. This was very convenient, as we didn’t then need to deploy each one individually to different environments. Some solutions can contain dozens & dozens of flows, and we really do love to package them all up together for ease of movement.
So that was good. But there was still a (major) ‘bugbear’ (as I like to refer to them as). This is the fact that after we deploy a Power Automate flow, we then need to go into it & (re)authenticate it. This is due to the fact that the connector/s that it uses contains what is referred to as a ‘secret’, and these can’t be moved across environments. As a result, we need to essentially recreate the ‘secret’ in the connector (ie authentication details) every time we move it. This is an annoyance (if you have one or two flows), and an absolute bloody nightmare if you have lots.
For the technical minded – every action in a flow is bound to a specific instance of a connection that it will use to “execute” that action. This is why when moving flows across environments, users are required to rebind every operation to a connection.
For example, I’ve been working with COVID-19 triage solutions. These contain lots of flows within them, connecting to multiple different sources, and doing different things. Every time we’ve performed a release (even if it’s just a simple update), we’ve needed to manually go through each flow, (re)authenticate them, and turn them on. If you forgot one, then everything can come crashing down & not work! But there’s been no other way to do it. To represent this visually, we have the following diagram
For each & every Power Automate, the connection line gets ‘broken’ when it’s deployed, and needs to be re-made.
Until now, that is. For today, Microsoft has announced the Public Preview for ‘Connection References’. Now when something is put into Preview, I usually caveat the usage of it with saying things like ‘it might go away, or not be released for a while’. But I’m going to be quietly confident about this particular piece of functionality, as I really don’t think it’s going to be pulled!
So what exactly are these? Well, in (mostly) simple terms, Connection References provide an ‘in-between’ or ‘abstraction’ layer for the connections that use them. Let’s show this visually as well
We still need to re-authenticate the Connection Reference once we deploy things. But let’s now see how we can save ourselves a massive headache, and LOTS of time:
Oooo…now this is looking better. Instead of having to update three Power Automate flows, we only have to update the SINGLE Connection Reference that’s sitting in the middle. Now multiple that by however many flows you have (eg sending emails out, etc), and start calculating how much time you’ll now be able to spend on coffee breaks, rather than doing this manually one at a time…
We can create Connection References directly from within the solution:
We then give it a name & description, choose which connector we’re going to be using, and either select an existing connection or set a new one up:
Once we’re finished, we click ‘Create’ at the bottom. Voila – we can now see it within our solution!
Note: Interestingly enough I couldn’t actually see this within the solution after I created it, even with the component selector set to show ‘All’. How I actually got them to display was changing the component selector to ‘Connection Reference’, and they then showed up. I’m thinking that this is due to it being new today/in the process of rolling out, and am expecting it to display without any issues in the near future
Let’s take a look at a Power Automate flow itself now to see how it’s referenced. When we open an item with a connector, we can now see the following:
We’re able to select the Connection Reference that we’re wanting to use. Simple, yet so powerful.
When importing a solution containing a Connection Reference, we will be prompted during the import process to set the actual connection that should be used with it:
If you don’t have any connections set up already in the environment, you’ll be able to create a new one from the dropdown.
Some things to note around this:
In summary – this is an awesome step forward with Power Automate functionality. I’m already tasking some of the developers on the team to re-do existing solutions to use it for ease of use. How do you think it’ll best benefit you? Drop a comment below!
I’ve recently been spending time looking at, and talking about, how we can handle company hours within Omnichannel. This has covered both how to use them within chat (Handling Company Hours) as well as being able to change the chat widget functionality (Handling ‘Out of Hours’).
Imaging my surprise therefore when someone asked me ‘how do we go setting them up properly?’. When I originally looked at how to use them within chat, I used the Quick Create functionality. I had meant to come back to looking at it in more detail, but that somehow fell by the wayside. So, I’m now going to make up for it!
As a quick recap – Operating Hours are what we set to show when the company is ‘open’ (or for our purposes, active). This doesn’t need to reflect the actual store hours that might exist – customer support could well start before/end after the normal store times. It’s also the case that we usually can’t just set blanket times – we’ll need to handle holidays, seasonal occasions, etc. This is where Operating Hours really comes into its own.
So to start off, it’s simple to enter operating hours. Really simple. We go to the navigation area, select, it, and click ‘New’:
We’ll create a new record, and click Save:
Once we do that, the magic starts to happen – we get to see the ‘Working Hours’ tab. Clicking on it will give us the following screen (which I can only describe as absolutely amazing!):
I don’t know about you, but I’m loving being able to see the hours for each day in a calendar-style view. It’s so much easier than needing to scroll down a list of records, trying to find a specific date. It’s also much simpler for the eye to follow/see.
At the top, we can navigate between dates, change the view to switch between a specific day, week or month, and enter new information:
There are two options for inputting new settings here:
For working hours, we can input the times, whether it repeats or not, and whether it’s a full day event or not:
We can also edit an existing Working Hours entry simply by clicking on it to change it. When we do this, we get the option as to whether to modify the single item that we’ve selected, or the entire series:
It’s important to note that we’re not limited to entering just a single range per day. We can enter multiple records for a single date, or a date range, to fit what we’re actually trying to do.
For Holidays, we don’t need as many options. We assume that by setting holiday, the company is closed. We’re therefore prompted just for a date (range) to then set this:
So what we then do is build up our calendar. This will result in (hopefully!) a full overview of our company, that we can then use.
What’s important to remember is that we could have different dimensions to our company though. We may allow Sales to be open 20 hours, but Customer Service to be open only for 12 hours.
We’d therefore create multiple Operating Hour entries for each requirement, and point each channel towards to the applicable record. If we only have a single scenario that we need to handle, we can point multiple channels towards the same operating hours record – that’s not a problem at all.
So with this, we can really tweak operating hours as we need to, for each possible usage. It’s really powerful, so easy to set up, and gives us full control over things.
Have you ever struggled with something like this? How did you overcome it? Drop a comment below – I’d love to hear!
Finding out how exactly Beth took up golf, how that then progressed over time into relationships, and what exactly can happen when you’re too honest with people!
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.
Let’s face it – we can be quite spoiled at times. As a customer, we can sometimes expect that companies be available 24/7 to service our requests, needs, issues, etc. That would be wonderful, wouldn’t it! Imagine that you have a mobile phone issue at 2am – you could call up your provider, and have it handled (or a new handset sent out) immediately. That would be quite nice!
Unfortunately the real world doesn’t (always) quite work like that. Of course there are companies that operate on a multi-national or even global scale, and there’s always customer service available (Amazon – I’m thinking of you right now!).
Previously I’ve gone into how we can set operating hours for a company, so that the ability to contact a customer support agent is only shown during these times. Take a look at Handling Company Hours for a refresher on this.
But sometimes not showing the ability to contact support could potentially be counter-productive. Customers may think that our website isn’t working properly, and possibly attempt to try to reach us through other means. This could quite well frustrate them.
Due to this, we have a nice little piece of functionality that’s now come out in Omnichannel. It’s small, simple, but yet quite brilliant in my humble opinion. This is the ability to have a chat widget available, but let customers know that that it’s currently out of company hours.
To activate this, we need to open the Chat record in the Omnichannel Administration Hub, and go to the Design tab:
Quite helpfully, the section is labelled ‘Offline’! How much better could we get.
We do need to understand that (at the time of writing this post) it’s currently in Preview, with all of the usual caveats around how that works.
We have several items available here:
So what does this then look like? Well, let’s take a look:
Personally I think that being able to set a theme colour for offline access gives it that little edge. Customers will become aware of this (subconsciously) when visiting the website, and come to the point of not even trying to start a chat when they see that it’s out of hours.
One MAJOR thing to bear in mind. We’re only going to be given the option to set this when we have a value set for Operating Hours. Without this being set, we won’t be shown this option. Go try it for yourself and see!
There’s not really much else to this, to be honest. But I’m liking it. I know that from a personal perspective I’ve been on various websites, and have no idea if the support chat is actually working or not. With this in place, I’m able to see that it is available for use at the correct time, and not have to wonder about it.
Have you ever thought about implementing something like this? Have you actually done so? I’d be really interested to hear from you about how you went about it – please drop a comment below!
We’ve all been there. We’re in the middle of a chat session with a support agent, or talking to a salesperson, etc. Suddenly things go wrong – our browser hangs, the internet loses connection, or something else…
Alternatively, I do know of situations where kids have pulled out the internet cables during ‘playtime’ – it really does happen!
Immediately we’re frustrated. Not only have we not finished what we were trying to achieve, but we’re going to need to start all over again. Perhaps the agent took notes & logged them against our contact record, but the likelihood is that it hasn’t happened. It’s going to take time to get through to an agent again, then we have to explain the whole situation from the absolute beginning. It’s heartrending, and can cause our day to absolutely go down the tubes!
Well, what if we could just re-connect to the chat session with all our data saved? Better still, what if we could go back and continue chatting with the specific agent that we had been communicating with? Sounds amazing, but wishful, right?
Well, we now have this ability within Omnichannel, to be able to enable our customers even further. There are even two ways in which we can offer this:
Let’s take a look at it, and how it works.
In the Omnichannel Administration Centre, we need to go to the specific Chat record that we’re wanting to set this up for. We open the record, and are now presented with the following (we do need to scroll down the screen a bit):
Note that this is in Preview currently, so just be a bit careful with it!
There are several options available. We don’t need to use each one, but let’s understand what each one does:
Note: The ‘Reconnect Time Limit’ value is auto-set by the system to the value specified in the work-stream that’s associated with the chat widget. It’s not possible to manually change this in the chat widget itself. Instead, the work-stream ‘Auto-close after inactivity’ value would need to be changed. This is shown below:
Note: It’s also important that the customer hasn’t closed THEIR chat window! All of this relies on the customer chat still being there. If the customer has closed their window/browser, they won’t be offered this option.
Have you ever needed to offer customer capability along these lines? How did you go about it? Drop a comment below – I’d love to hear!
Discussing the joys of camping in different countries, FinOps Consulting, and what exactly compromises standard functionality or not when pitching to 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.
I’ll freely admit that the title for this post is a bit of a mouthful! I’ll also admit that I used the British spelling of ‘centre’, rather than what it actually is. You’ll have to excuse my grammar 😉
This post is about something that we all knew was coming. The old Admin Centre is no longer – and we shall miss it! It was inevitable that it would be moved over to the new Power Platform interface, as so many other things have already. Therefore I thought it would be good to do a quick article about where it is now, how to access it, etc.
After all, it is vitally important when needing to carry out the initial configuration for Omnichannel, or to check for upgrades to the Omnichannel installed solution!
Let us, however, cast our mind back to the very familiar layout shown below. We’ve spent so many years here that it seems quite sudden. But though you may be gone, you will not be forgotten!
Right – now onto the new version of it! So this actually took me a few minutes of digging around as to how to find it & get to it.
The first thing I tried was looking in the environment settings, but alas, I didn’t find it there. So I continued digging around.
Wishing you spare you the exact itinerary of everywhere that I looked into, I’ve decided just to show you it! I can hear the sighs of relief at this point…
What we need to do is navigate to the Power Platform Admin Centre, at https://admin.powerplatform.microsoft.com/. Once there, we expand Resources on the left hand side, and select ‘Dynamics 365 apps’. Note that you do NOT have to select a specific environment first to be able to do this./
Now we can see a list of all apps installed. Nicely we’re able to scroll, which we couldn’t do in the old interface! That’s actually really helpful, and avoids needing to navigate to a different page. If we scroll down, we can see the entry for Omnichannel:
Click on ‘Manage’, and we get the following lovely popup:
Click OK to this, and we get taken to the (familiar) interface for configuring the initial items for Omnichannel:
Here we can go about the usual items, such as checking each environment to see if there are any updates available, or configure the main channels.
Nicely, Microsoft has actually updated (some of) their documentation, which is obviously very good. I’m now going to have to go and check through previous articles of mine, and update as necessary!
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:
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!
Finding out just how Sheryl is connected with the annual Glastonbury festival, the wonders of Direct Debit/financial payment runs, and what happens exactly when you might just be performing a backdoor system update into a database…
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.