Tag: dynamics365

Thoughts around the Connection entity

I decided to write this post due to currently looking at the Connections entity. This is for a current project with a very specific purpose. When this came up, my thoughts went back to a previous project some years back when we also looked to use the Connections entity. I therefore thought that it would be good to recap & share my experience.

What are Connections?

Now, the Connections entity truly is a wonderful piece of work. It’s one of the core features that doesn’t actually get much time or effort devoted to it! However, it underpins a lot of the way that Dynamics 365 has been built to work over time.

The best way to summarise Connections is:

Connections are a very easy way to connections records without needing to have to create a custom relationship in the system. Connections can be used between records from the same entity, or from different entities.

See, you are able to connect one record to another record within the system. This could be account to account, account to contact, or contact to a custom entity. There are practically no limits, apart from the extent of your mind! All of this is done by leveraging the functionality that Connections brings to the table.

Note that I’m not talking about lookup fields here, which are also great, but work differently, and require creating a relationship between entities (or even within the same entity).

Just a quick reminder here that custom entities need to be enabled for connections – it doesn’t happen as standard when creating them. You can either do this when creating it, or you can edit the settings for it later:

How to use Connections

In order to connect one record to another, you need to open the first record & click the Connect button on the toolbar:

You’ll then be presented with the New Connection screen, where you’ll select the record that you want. Click the ‘All Records’ item at the top & then ‘Change View’ to select the actual entity that you’re wanting to look for:

You then select the record that you’re wanting, and save. Hey presto, the two records are now connected! To see the connected records, look at the associated ‘Connections’ setting from either record:

OK, so this is really all brilliant. For the absolute majority of situations, it works, and works well. There’s nothing better for it. There are a few small issues, such as the fact that you can’t use Business Process Flows or Business Rules for custom logic, but instead need to use Javascript, but for the most part they work well.

Edge case scenarios & issues

However, there are some edge case scenarios that I’ve come up against, which is the whole purpose for writing this blog post.

What happens if you’re trying to use Connections to establish a hierarchy of records. Eg one record is a parent of another record. Well, you could use a lookup field instead, but if you wanted to define specific attributes for the actual relationship, that wouldn’t work.

Here’s the scenario. You’re needing to capture the relationship between different people, along with certain attributes (eg if they’re a legal guardian, or a trustee, or have power of attorney, etc). You’d think that Connections would work brilliantly for this. After all, you can modify the actual Connections entity to add custom fields onto it. So for example, you could have something like the following:

Note: I’m not referencing Connection Roles, as you can only have a single connection role per connection. In the scenarios I’m handling, I’m needing to have multiple attributes per connection.

So you create the connection between the two records, and you set the attributes that you require. All good. What’s also good to remember is that Connections are bi-directional. You can view them from either ‘side’ of the connection. Eg:

Record 1

Record 2

That’s actually really helpful & useful in the normal scheme of things. You can easily see connections from either side.

But there’s a catch, or even (in our case above), an issue. If we open up each of the two Connection records, we’ll see the following data.

Joe Bloggs connecting to Helen Sommers:

Helen Sommers connecting to Joe Bloggs:

Can you spot the issue? Of course you can! On BOTH of the connection records, the custom fields that we set have the same values. We originally connected Joe Bloggs to Helen Sommers as the Legal Guardian, Power of Attorney & Trustee. Well, if we open up the connection record from Helen Sommers, we’re seeing the same values set, just in the opposite direction!

This is actually due to how Connections work. When you create a connection Record A to Record B, the system automatically creates a mirror Connection record from Record B to Record A. When it does this, it copies all of the values that you’ve set over to this mirror record.

So when you look at the data, you can’t actually see how the structure should work. It’s an issue. Especially if you’re passing the data to other system/s that may need to evaluate it. They just can’t understand this properly, and you’ll get some VERY unwanted results out of this.

Now, there is actually a field within Connections that shows which record is the ‘master’ (ie the one you actually created), and which one is the ‘mirror’ that the system created:

However even with this in place, we’ve found issues when using it:

  • If you’re relying on people looking at the record to see the information, they’re going to make mistakes (ie not checking this value). With the fact that the values are also displayed on the mirror record, this is very prone to user error, and isn’t a good way to do things
  • If passing information to another system (ie the record & the values), you need to program it to only allow it to pass records with this flag set correctly. If the other system is writing back data, it also needs to be configured to write back to the same record.

Summary

With all of this in mind (& especially considering that users may create connections from the ‘wrong direction’, which is quite possible to happen), it’s important to think of the best way to architect systems for regulatory purposes. Financial, legal & other judicatory requirements need to have a system that can handle them properly & accordingly, and not leave room for error.

Therefore, if you’re looking to handle these sorts of scenarios, I’d recommend to look at implementing a custom entity for those specific connections.

Another benefit of this is to separate out these connections from the general connections entity. That way, you’ll also be able to handle security appropriately, which is usually applicable in these sorts of situations. It will allow you to easily allow only a subset of users access (read and/or write) to this data, rather than trying to apply it to Connections (which is going to be a major headache!)

Wave 1 2020 – Search Behaviour Changes

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).

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.

Omnichannel & Sentiment Analysis

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:

  • Lack of consistent approach
  • Large amounts of time needed
  • Many manual touchpoints

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!

MB-600 Solution Architect Exam

I haven’t really touched very much on any exams that I’ve taken so far during the lifetime of this blog. I’ve mentioned them a few times (ie how important they can be), but haven’t really gone into detail.

However, having seen various comments online recently around the MB-600 exam, I thought I’d do a post on it with my thoughts and comments!

So, what is the MB-600 exam? Well, it’s sort of the ‘Holy Grail’ for Dynamics 365/Power Platform. This is due to the actual full name for it – ‘Exam MB-600: Microsoft Power Apps + Dynamics 365 Solution Architect’. Indeed – assuming you pass it (and you’ve already passed the MB200, and either the MB210. MB220, MB230, MB240), you can officially refer to yourself as being a Microsoft certified ‘Solution Architect Expert’.

Impressive!

The exam was being talked about at the beginning of 2020, and went live (in beta) on Jan 27th 2020. If you’re wanting to book it, do so at https://docs.microsoft.com/en-us/learn/certifications/exams/mb-600.

I sat it several days after it went live, and to be honest found it quite challenging. Why was that? Well, when I sat it, there were no learning paths on Microsoft Learn for it at all. Thankfully that’s now changed – there’s a massive amount of great material at https://docs.microsoft.com/en-us/learn/certifications/power-apps-and-d365-solution-architect-expert. If you’re looking to go ahead and do the exam, I’d highly recommend you go through everything that’s there.

I’ve taken quite a few exams since early 2019, and have now taken the general approach to take exams in Beta. Although there can be some waiting until the results are announced, they’re cheaper, and give you an understanding of what’s going on.

I sat the exam through the Proctored option. I’m not going to say too much about that (you can look up online what this is about), other than to say that I feel that Microsoft really should be doing something about the proctored experience. Pearson Vue is in charge of this, but it can be really bad at times (having taken a dozen or so exams this way in the last year, I feel I’m quite qualified to be able to judge this!). I hope that things do get better for this.

So, to the exam itself. Well, I was lucky – there were no Labs in it (yet!). Several case studies, and lots of questions. Quite hard questions as well – make no mistake, they’re out to seriously test your knowledge.

The first thing that I ‘loved’ when starting the exam was the general briefing, which included something along the lines of this absolute gem (this isn’t word for word, as I’m not allowed to write it down during the exam, but it gives the gist of it):

Some question sets may have more than one solution, while others might not have a correct solution at all

Right. So tell me – if there’s no correct solution, what am I supposed to do? I’m still waiting for someone to enlighten me on this matter, as I haven’t found anyone who’s able to explain it….

Now, part of the exam rules state that it’s not allowed to share any of the exam questions. What I’ve therefore included below is an overview of the sorts of things that were covered for my exam (Note: exams are composed from question banks, so there could be many things that weren’t included in my exam, but could be included for someone else!).

  • Data imports – what they are, how to go about them, troubleshooting them, etc. Also covering different types of sources
  • Security models, permissions, security types (field level, role, user, team etc)
  • Teams integration. How it’s set up, configured & used
  • Solution patch types. What they are, how they’re applied, how they’re used, benefits & drawbacks
  • BCP (Business Continuity Planning and Disaster Recovery) processes. What option/s should you be considering to ensure your business is fully covered in a disaster situation, how are they configured
  • Portals. What they are, how they’re set up, security permissions
  • Business rules, Business Process Flows, Workflows. What each one does/doesn’t do, benefits & drawbacks, how they’re set up & configured
  • Systems – On Premise vs Cloud. The advantages and/or drawbacks of each type, and the different BCP methods (see above) for each one
  • Data integration. OData vs Custom Service for continuous data
  • SLA’s and KPI’s. What they are, when each is used, how to set up & configure them
  • System upgrade paths and compatibility. How you go about upgrading legacy systems, and the necessary path/s that you have to take for a given version number
  • Customer Service through multiple channels. Which option/s would you select for a given scenario, how would you set it up/configure it
  • CDM/CDM/PowerBI/Azure Service Bus/PowerApps. What is each one, what are the benefits/drawbacks of them, how is each one used, & set up/configuration
  • Licensing Types. What license/s would you need for a given scenario
  • D365 Sales Insights. What it is, what benefit/s it brings, how is it used
  • Data security. How is security used for Dynamics 365 & PowerBI data, how is it set up/configured
  • Field properties. For a given scenario, how would you change field properties and/or parameters?
  • Data Migration. Different options available for this, benefits/drawbacks, resolving issues
  • Form security. What is it, what are the different types of security that’s able to be used, how is it set up
  • Solution management. What are the different types of solutions, how is each one used, what are the associated risks, which option would you use for a given scenario

Wow. That’s a LOT of stuff. Like…an incredible amount. Some of it touches on parts of the system that I’ve never used before (like PowerBI). Other parts are extremely familiar.

I can’t tell you if I’ve passed it or not…YET!. Results aren’t yet out, as it’s still in beta (and from what I’m hearing, it’s likely to be remaining in beta for several months still.

So, if you’re aiming to take it – I wish you the very best of luck, and let me know your experience!

Omnichannel & Agent Scripts

Earlier this week I started to share information around the Productivity Tools that Microsoft provides (as a separate solution, admittedly) for Omnichannel – https://thecrm.ninja/omnichannel-productivity-tools/. With it, I also covered Macros, and some of the benefits that using macros can bring to a company

Now, we all know that the absolute key point in ensuring a consistent & holistic approach is to have a method for getting something done. A ‘script’, in other words. With this, we can set out the steps that we want to be carried out, in the order that they should be performed, with appropriate information against each item. This results in agents (hopefully!) following this, giving the customer the same (and great) experience each and every time they need to interact.

Scripts isn’t just about instructions to be carried out though. It also allows macros to be included, that agents can run as they go through the script.

Here’s an example of something that I’ve been playing around with in my test environments (ninja’s are just SO cool, that I’ve had to rein in my imagination!):

So that’s an example of what you can do. Let’s now see how we set these up. There are several steps to it

In the Omnichannel Administration Hub, you should see the Scripts entry in the left hand bar:

Open it, and click on ‘New’ in the main menu bar. You’ll get the following form appearing:

Type in a name for the script, and a description (personally I find it annoying that I can’t see all of the text in the Description field – perhaps Microsoft may change this at some point). Save the form, and the grid to the right becomes active!

Clicking the ellipse (3 dots) in the Agent Script Steps grid gives several options:

One of the very helpful options here is to add an existing script step. What’s a script step, I hear you ask. Well, each specific item in a script is referred to as a ‘script step’. You set these up as you go through your scrip, as shown below. You don’t need to create a new script step for each script if they’re the same thing – you can just create one, & add it as needed to multiple scripts (just be careful, because if you need to change it at some point, the changed/updated version will display in all scripts that it’s associated with!.

As with any record, you’ll put in a name, and a description. What you’ll also do is give it an order number (this is manual, not auto-generated). The order number is how the system orders the different steps. There’s also the option (which is a required selection) as to whether this is text, macro, or a script:

  • Text. This will be free text that you enter into the script step, which will then be displayed on the screen for the omnichannel agent to see
  • Macro. This will give you the option to point to a macro that you’ve already set up. When the agent will click on it during the session, the macro will run
  • Script. This allows you to reference existing scripts – you can have smaller scripts that you can then use as ‘building blocks’ to create more complex scripts

Once you’ve gotten the script set up, we then need to configure the chat sessions to actually use it. This allows us to set up multiple scripts in our system, and use them as appropriate (eg by using pre-survey questions, it’s possible to direct a customer to a specific queue, and then have the agents use a specific script for this).

To do this, we go to Sessions, and open the session entry that we’re wanting to set the script up for:

Once it’s open, switch to the Agent Script tab. This has a grid that shows all of the script/s that are set up for it. To add script/s, use the drop-down menu on the top of the grid:

The last thing that needs to be done is to enable the Productivity Pane, as otherwise agents won’t be able to see all of this in the first place! Thankfully this is a single setting, and is done as follows:

  • Go to the Productivity Pane option in the left-hand menu. Click on it
  • Set the Productivity pane option to ‘Enabled’
  • Set the Mode option based on your requirements (this is how it appears in the agent interface). By default it’s set to ‘Collapsed’
Enable the productivity pane

And VOILA! It’s now all set up and ready to go: