Tag: behaviour

Omnichannel Agent Presence

One of the main parts of any system is to see who’s available to handle customer service queries. This is, of course, vitally important for any company – you wouldn’t want to overload an already busy agent!

In the case of Omnichannel, the system uses something called ‘Presence’ to show this. When users are set up, they have a default presence set against them. These govern system behaviour, along with having a nice friendly icon that helps from a visual perspective. Omnichannel has the following default options available:

These are available for supervisors to see from their dashboards, so that they can see the status of all agents at a single glance.

It’s also used by the system for auto-routing conversations. For example, if the agent status is ‘Busy’, then they won’t have new conversations routed to them. Similarly, if they’re set as ‘Away’ or ‘Offline’, they also won’t get conversations sent through to them (admittedly supervisors can override this, and assign specific conversations to agents who have one of these set).

Agents are able to change their own presence by clicking on the toolbar, and selecting the one that they wish to set:

But what happens if you want to have some custom statuses? Off the top of my head, I can think of at least half a dozen clients that would want more granularity around this.

Well, thankfully we’re in luck. Omnichannel supports the option for a ‘Custom Presence’!. They do need to be set up through the Omnichannel Administration Hub. To do this, go to ‘Custom Presence’ on the left side & select it. We can see that the default system entries are there.

Before going any further, I do want to point out that we should NOT deactivate or delete the standard Presence entries. It’s possible to do, but it’s going to create MAJOR issues in your system. So please, don’t!

Right – back to things. To create a custom presence, we click the ‘New’ button on the menu bar. We get the following window:

The 4 fields shown are as follows:

  • Name. The name of the record
  • Presence Text. The wording that the agent sees when they’re picking their status
  • Base Status. The default system status that this new status will be based on. This is important, as it will drive the icon used
  • Description. A ‘friendly’ description of what the presence/status is about. This is useful to keep track of things

Once we’ve saved the record, it’s then immediately available for agents to select! The only thing that agents need to do is refresh their browser tab. This makes a nice change from the usual ’15 minute wait’ for data to update within Omnichannel :).

So let’s go ahead and see what this then looks like. I’ve chosen a very familiar item (for most people):

When I’ve selected this new custom status, we can then see that the icon in the Ribbon Bar changes as well, to the icon for the base status that we used:

So in short, this is quite a nice little piece of functionality. Nothing too fancy or complicated to setup, but will allow companies to further segment their agents & understand what they’re up to.

Something else that we’re able to use this for is the agent ‘Default Presence’, which is set on the User record. Once we have custom presence records in place, it’s possible to select these there:

So apart from having agents segmented by Teams & Queues, we can now also use these. Some very interesting scenarios pop into mind!

So, how do you think you’d apply this in your own environment? Drop a comment below – I’d love to hear!

Strange behaviour with views

Normally when I write a blog post, it’s about sharing some cool features, new functionality, etc. However this post is going to be a little different, because I don’t actually have an answer (yet!) to what is going on here.

Let me explain the situation.

I’m needing to show some very specific data for reference purposes. For the purposes of this, let’s say that I’m looking at Contacts, and needing to report on Phone Calls. The reason is to identify Contacts who are frequent callers. My criteria are as follows:

  • At least one phone call (that has the Contact as the Regarding value) need to have a specific field set
  • At least one phone call (that has the Contact as the Regarding value) needs to have its Activity Status as Open

These two conditions are separate. So the contact essentially needs to have at least 2 phone calls against them, with each one meeting one of the conditions. There can be more than 1 phone call record with the same condition – that’s not an issue here.

Back in the (good old) day, I’d have written some cool SQL to return this data. Two Left Outer Joins, and we’d be done. However I can’t do that now (I’ve recently started dipping into FetchXML, which is an entirely other story to cover at some point). So I’m having to use the Advanced Find to check that I’m getting the right data.

This isn’t the easiest of things to do. I’m needing to start from Contact, go to Phone Call, go back up to Contact, & go back down to Phone Call. But hey, this is what it looks like:

So with this set up, I run the query, and get some results (in this specific scenario/time, there are 3 results). I go through the data to check that the results are actually satisfying my requirements, which they are:

Wonderful – let’s move forward then!

My next step is to look to set this up as a system view. To do this, I go to the Power Apps Maker (http://make.powerapps.com/), open my solution & find the Contact entity. Opening it, I switch to the Views tab:

I create a new view, add the columns I need, and then open up the Filter Criteria to start setting this up. I’m using the Advanced Find as a reference guide for the conditions I’m needing to use. Going through it, I replicate the values across:

That looks about the same as the Advanced Find, right? It’s laid out slightly differently, but that’s just the designer. OK – let’s go ahead to save/publish it, and see it it in the app:

Hold on. There’s only 1 record showing up there. Admittedly it’s in the list that came from Advanced Find, but what’s happened to the other 2 records?

So I go to check the data. I had already done this before, but I thought that perhaps I overlooked something, so I checked again. Nope – all of the data is fine/correct. There should indeed be 3 records showing up in the system view, but 2 are missing…

Note: As an aside, I do know that this isn’t permissions related. I’m doing all of this as a systems administrator with full privileges to everything. So it’s not that

OK – next steps:

  • Clear browser cache, reload and see if they’re showing up (useful tip – Control+F5 does this!). Nope, they’re not showing
  • Use Incognito mode, log in and see if they’re showing there. No, they’re still hiding away
  • Use a different browser, with a different system administrator login. Unbelievably they’re still being very shy, and refusing to appear!

Even more confusing about all of this is something truly perplexing. I can open up Advanced Find, select the system view (without doing ANYTHING else) & click ‘Results’. When doing this, all of the records appear! So in the entity view they’re not, but when I use that same system view through Advanced Find, they are!

I’m scratching my head at this. It just doesn’t make sense. I have no idea why this is happening. Reaching out to others, they also don’t seem to have any idea either.

My next step (I’m feeling SO proud of this, and so dev!) was to check the FetchXML. Perhaps there was something underlying in it that’s causing this? Using the FetchXML Builder in XrmToolBox, I loaded both views up, and compared them. It’s crazy – they seem to be exactly the same! (well, some cosmetic differences with where aliases appeared on the line, but this wouldn’t affect it):

At this point, I’m thinking that there are some magic elves under the hood, squirrelling away the data. It has to be the only logical reason for this, right?

The only thing I could find in the FetchXML that might make a difference is that there’s a ‘Distinct’ clause at the top of it in the one that’s working:

Why this would cause the issue, I have NO idea. Views return distinct results in them anyhow, so I’m not sure what this is actually doing here.

Regardless, using FetchXML Builder I updated the code, and WOW – it worked! I’m now returning 3 records in my system view! Absolutely strange, but hey – if it’s working now, who am I to question it…

I’m going to try to raise this through official Microsoft Channels, and see what I might be able to find out from them. However if you’ve come across this (or similar), or have some ideas about how to work around it, I’d LOVE to hear from you!