I haven’t usually been putting up posts around the exams that I take. A few months back I did decide to write one on the MB-600 exam (MB-600 Solution Architect Exam), which just took off! It was quite amazing (& pleasing) how many people were looking at it, & asking me questions around the exam.
As a result, I’ve decided to continue this, and am therefore now writing this post on the MB-400 exam.
There are several different ‘ranges’ of exams within the Dynamics 365/Power Platform space. These are aimed at different types of roles, or specific specialisation/s within a role. A good example of this is the MB-2xx range. It covers functional technology, and is split across the different ‘main’ areas of Dynamics 365.
The MB-400 (the only one in the range at the moment) is aimed at developers. According to the official description for the exam:
Candidates for this exam are Developers who work with Microsoft Power Apps model-driven apps in Dynamics 365 to design, develop, secure, and extend a Dynamics 365 implementation. Candidates implement components of a solution that include application enhancements, custom user experience, system integrations, data conversions, custom process automation, and custom visualizations.
Candidates must have strong applied knowledge of Power Apps model-driven apps in Dynamics 365, including in-depth understanding of customization, configuration, integration, and extensibility, as well as boundaries and constraints. Candidates should have a basic understanding of DevOps practices for Power Apps model-driven apps in Dynamics 365. Candidates must expose, store, and report on data.
Candidates should have development experience that includes JavaScript, TypeScript, C#, HTML, .NET, Microsoft Azure, Office 365, RESTful Web Services, ASP.NET, and Power BI.
As anyone who knows me will attest, I am NOT a developer. However I decided (for several reasons) to give this one a go, and see what would happen! I knew I’d be pushing myself out of my comfort zone, there would be things I wouldn’t understand/know at ALL, but hey – I was curious to see what would happen! Even more challenging, I decided to book & take it within a 24 hour period!
Now as this has been out for a little while (& isn’t in Beta), there’s thankfully some good resources on Microsoft Learn about it. Take a look at https://docs.microsoft.com/en-us/learn/certifications/exams/mb-400, where there are several learning paths that can be followed.
A big shout out as well to Julian Sharp & Joe Griffin who recently ran a multi-week course around it. The official Microsoft learning paths are great of course, but seem to miss out quite a bit of what’s actually needed to be known for this. The course that they ran covered a lot more. Hopefully there will be more courses like this run in the future!
When passing it (& assuming that you’ve passed the MB-200 as well), you get a lovely shiny badge!
I’m SO proud of this!
Once again, I sat the exam through the proctored option (ie from home). The experience went somewhat better than previous times. Amusingly I got told off by the proctor during the exam for ‘looking down at the keyboard’, rather than looking at the screen! I explained that I was using a different computer, & kept clicking the wrong mouse button on it (leaving aside that I was exhausted when doing it!).
So, as before, it’s not permitted to share any of the exam questions. This is in the rules/acceptance for taking the exam. I’ve therefore put an overview of the sorts of questions that came up during 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!).
Configuring security for system connections (security types)
D365 Web API – how it’s used, types of calls made from/to it
Azure API – making calls to/from it
Code for importing data (debugging, variables)
Advanced Find
Types of calls (synchronous, asynchronous, )
Data modelling
Creating & deploying solutions through different methods
Publisher versioning
Identifying code variables, and saying what would happen in given scenarios
Power Apps Component Framework (PCF) – how to use, how to package components, how to deploy
PCF components & classes
JavaScript – code examples, what happens when a given scenario happens
JavaScript functions
Dynamics 365 Ribbon – what it is, what you can do with it, different types of functionality & ways to do things with it
Security & Permissions, including roles, teams, field level security, business units
Workflows, Power Automate Flows (how they’re set up, different functionality within them, how to do things with them given a specific scenario)
Business Rules (what they can/can’t do, different scopes, etc)
Field types (eg option-sets, calculated fields, roll-up fields, multi-select, etc)
Importing solutions – requirements for this, versioning, deployment between environments
Compatibility with Microsoft Teams
Now many of these (as I said above) are outside of my comfort zone. In fact, I’d say that even with absolutely cramming for a whole day for the exam, I still felt that I was guessing the answer for at least 30% of the questions. Admittedly though, as Julian Sharp says, a ‘gut feeling’ answer is usually right most of the time, coming from what the subconscious has absorbed during revision.
I was REALLY happy that I got a passing mark for this, & admittedly was VERY relieved as well. So now another lovely shiny badge in my collection, and I’m now going to go and update it on LinkedIn as well!
If you have any questions on this, feel free to drop them below, and I’ll try to help out as best as I can!
Many people in the IT scene will know of LogMeIn (https://www.logmein.com/), or LMI for short. For as long as I can remember (which means going back almost 2 decades!) they’ve been one of the main remote access solutions. With their product range, it was possible to leave your computer at home, travel abroad, and easily log into it from practically any computer anywhere.
It’s also a great product for IT professionals. Being able to deliver customer support through remote sessions, manage identity solutions, etc. The number of products over the years has grown, and been quite pleasing to watch:
Pro handles unattended remote access for up to 10 computers, and is aimed at small businesses
Central takes this up to the next level, covering 250 computers, but has all of the admin features that larger businesses want
Of course, LogMeIn Free (a great starter product for personal usage) was removed some years back, which to this I still believe is a great pity. Obviously the company decided to focus on the more enterprise side of things, which I can understand as a business.
So, why am I now writing about them? Quite simple, actually. LogMeIn are one of the providers that are working with Microsoft to provide Co-Browse solutions for Omnichannel! It’s a very new piece of functionality that’s been launched in the Dynamics 365 product, and there aren’t many providers out there that have integration points to it.
What is Co-Browse?
It’s important to understand what co-browsing is, and some useful stats:
“Co-browsing” refers to the ability to have a service provider & customer jointly navigate an application in real time through the web.
Co-browsing: The Gateway to Happy Customers & Better Financial Results, 2015
So co-browsing is useful. But just how useful can it actually be? Well, apparently it can be VITAL:
Co-browse has the potential to bridge the gap between human & AI-driven customer interaction, & to enable organisations to differentiate their customer service.
By 2022, co-browsing will be used in 2% of customer service interactions, up from 0.1% in 2017 (2000% growth).
Gartner 2017: How Co-browsing Can Differentiate Your Customer Service
LogMeIn has had their Rescue offering available on the general market for a while as a standalone product (alongside the rest of their offerings). They’ve now build it out into a new standalone product called Rescue Live Guide, and provided an integration into Omnichannel for Dynamics 365. Customers obviously need to have licenses for the product, but with these, they now have the ability to co-browse during support sessions. Not only can they see what’s going on, but they can also interact with the customer browser itself, providing an even better support experience.
So, let’s go ahead and take a look at how to set it up, the experience itself, and my thoughts on things.
Setup
When I first started testing out the LogMeIn offering, I had to go through a manual install process. This was due to the product just being released (in May 2020), but wasn’t actually that difficult to carry out.
However, they were in the process of switching over to an automatic installation through AppSource, as most of the other apps have. It’s great to be able to see that this has gone live, and is now available for users – it really does make the install that much easier!
Clicking ‘Get It Now’ takes you through the usual route of installing a solution from AppSource: selecting the environment, confirming the installation, etc. After around 5 minutes, I can now see the following:
Once it’s installed, we’ll need to set it as the co-browse provider for the channel that we’re wanting it for. To do this, open the chat record, go to Conversation Options, and select it there:
We’ll also need to put in two records for the LogMeIn co-browse configuration:
Finally, there’s a script block that needs to be added to the webpage where the chat widget is located. This enables the LogMeIn co-browsing ability from the customer side. It can be added right under the chat widget code itself; in the fullness of time, this may be able to be auto-generated as part of the chat widget code, but it’s not at the moment (this is dependent on Microsoft being able to offer it):
Right – setup all done, but before we see it in action, let’s take a quick look at the Rescue Live Guide admin console side of things.
Rescue Live Guide Admin Console
Although the functionality is within Omnichannel for Dynamics 365, administering agent licenses and groups takes places within the Rescue Live Guide admin console at https://console.logmeinrescue.com/admin. As companies will need to have Rescue Live Guide licenses, they would usually be familiar with this.
There’s the ability to create new users or groups, and manage them as well:
It’s also possible to set the names that are used for the agent & customer. These can be either the actual name of the agent, or instead potentially a job role/title:
I’m not going to go further into the admin functionality here – documentation can be found on the Rescue Live Guide site around this. Let’s instead take a look at the experience within Omnichannel, which after all is what we’re here to see!
Agent Experience
So how does this actually work, in practise? Well, from the customer side, they start a chat like they would usually do. When the agent responds, they’re given an option for ‘Live Guide’:
When the agent clicks on this, two things happen:
Firstly, there’s a URL that’s posted in the chat. This contains a link for the customer to click, with an auto-generated ID number
The agent is taken to the LogMeIn Rescue site page in a new tab.
Note: At the moment, the agent will have to sign in manually. LogMeIn have told me that their roadmap includes Single Sign On, so that after the initial setup they’ll be signed in automatically, and not have to perform this step in the future.
Once logged in, the agent will see that the session is ready, & waiting for the customer to connect to it. Once the customer has clicked the URL provided in the chat, it will open the Rescue Live Guide session, and authorise the agent to co-browse with them. They’ll then see the following prompt. This tells them that the session is connected to the agent, and that they can begin:
Once the customer has accepted to start browsing together with the agent, they get some small extra items appearing on their screen:
They can see that there is indeed a shared browsing session happening
They can also see where the agent’s mouse cursor is pointing to (by default, without the agent actually doing anything)
It’s important to note that that the co-browse session is taking place within the specific browser (tab) that is open. Therefore if the user navigates away, the session is paused until they navigate back to it.
On the agent’s side, they can view the customers browser. They can only see what’s happening in the actual tab that’s open for the co-browse session (see below for some more information around this though). It’s quite similar to the customer’s side, though has some LogMeIn features available. Well, obviously it’s similar to the customer – the agent is seeing the customer’s browser window!
They can of course still access the Omnichannel chat itself, and send information through that as well if they wish to.
Just as the customer can see the agent’s mouse position, the agent can see the customer’s mouse position. There are also gesture indicators so that each person can see what the other clicks etc as well, which can be really helpful when walking through a process.
The functionality currently available to the agents covers scrolling (within the page), highlighting, drawing and ‘virtual tabs’. As shown in the image above, the agent is able to highlight text/images, which will then be displayed as being highlighted to the customer. Agents are also able to enter text into text fields, click on buttons, and interact with the native webpage functionality.
Note: The Rescue Live Guide admin centre provides granular controls around these, so that customers can allow agents certain rights, rather than allow them to do everything.
The agent is also able to ‘draw’ on the webpage to be able to point something out, highlight a part of the page, etc.
Note: These annotations will disappear once the customer or agent starts scrolling up/down the page again.
As I’ve mentioned above, the session is taking place within a single browser tab. If the user nagivates away (to a different tab), the session is paused. The agent isn’t able to see any other tabs. So what happens if we do indeed need to open a new tab for something?
Well, there’s a really nice feature that the agent is able to use for this. It’s sort of a ‘virtual tab’ within the browser tab. Sounds interesting!
The customer is able to see this, and can navigate between the tabs. They’re now also able to open a new virtual tab themselves (which is an update to the functionality – originally they weren’t able to, and had to request the agent to do it).
Customer view of the support session
If the customer wants to pause or stop the session, the user simply has to click the ‘Stop’ button in the bottom left. They’ll then be presented with the following screen:
Whilst the session is paused, the customer can continue to use their machine as normal, but the agent won’t be able to see what’s going on. Only if the customer allows the session to resume by clicking ‘Continue Browsing’ will the agent be able to see the customer’s browser once again.
Alternatively, the agent can end the support session themselves, and the customer will be notified about this.
Suffice it to say that LogMeIn have been a market leader for many years in this sector, and I’m happy that sessions through their products are adequately encrypted & protected.
Other functionality
Apart from the above, which is obviously the core of the product, there’s other functionality that’s possible to enable through the LogMeIn Rescue console:
Session recordings. It’s possible to record these for playback, which is then available from the LogMeIn portal. All recordings are carried out from the agent’s viewpoint, not the customers – there is therefore no issue that sensitive information from the customers side could be seen
Data masking. It’s possible to use data masking to hide sensitive information. At the moment the setup for this is a very manual process, so I’m not going to go into how to set it up it here. Having played with it a little, it’s really quite useful. Agents can’t see sensitive information on their screen, and if a customer needs to enter/update information, the session pauses whilst this is being done. However I understand that part of the LogMeIn roadmap for the near future is to make the setup process much more user friendly. When this is released & available, I’m planning to do a post on this
Reporting happens through the LogMeIn portal (see my thoughts below on this). It looks nice, and can be downloaded as a CSV file. Again, the functionality of this is going to be expanded in the near future.
Reporting in the LogMeIn website console
My thoughts
Having gone through testing out the product, I think that LogMeIn has brought a really great product of theirs into the Omnichannel experience. I used to use their products regularly (I ran an IT MSP some years back, in which we used LogMeIn products as well), and always found that they behaved well.
Now having the ability for agents to not only see, but also interact with the customer browsing experience really does take things to the next level. Audio and/or video support is great of course, but sometimes being able to see what the customer is seeing in their browser results in a much quicker resolution. This of course results in happy customers, which is what we’re striving to achieve!
As I’ve said above, I’ve used LogMeIn over the years, and always found their products to be pretty much amazing. With Rescue Live Guide, there are several differentiators that the solution brings to market:
For the standalone solution of Rescue Live Guide dedicated web resources aren’t needed. It’s an easy solution to set up, and for the customer to engage with – all it requires is a URL to be provided to them to get the session going. Obviously, as mentioned above, there is some slight coding needed for the Omnichannel integration, but this is really minor. Any company having Omnichannel installed/configured will already have power users/admin familiar with what’s needed for this, so it’s a very small additional step
It’s possible to co-browse on any website that the customer wants to, not just a single specific website. Once the co-browse session is active, the customer can change to any other website, as long as they do so within the co-browse session tab. Most other co-browse solutions out there can’t do this, so this is a really strong point in favour of this solution.
The data masking is really cool, and for most customers, will be a ‘must have’ rather than ‘nice to have’. I’m looking forward to when the setup for this is updated to be more business-user friendly, and will then do a separate blog post around it, together with a video!
A few things that I think would be nice to have:
The agent is already able to draw on a webpage during the co-browse session, and select different colours for this. It would be great if the agent could also type text in to display on the screen (not in a specific field) in colour. Sometimes being able to see an example written in front of you (without it going into the actual field) can be quite handy.
Being able to transfer the co-browse session to another agent. This could be either another Omnichannel agent, or a separate specialist team. It is of course possible to transfer the chat session to another Omnichannel agent, but then they’d have to start the whole co-browse session again (with a new PIN, etc)
Reporting (for the most part) all occurs in LogMeIn at the moment, as Dynamics 365 only has very limited reporting on this natively. However I understand that this is due to change at some point this year, with the ability to report properly on it within Dynamics 365 itself.
At the point when new items do get released, I’ll be aiming to do a review of them, and add to the knowledge around the product.
So, with all of that, how do you think this could best help you & your customers? Please comment below – I’d love to hear!
Previously I’ve touched on how it’s possible to use Azure Active Directory for Dynamics 365 security. This can be of great benefit to an organisation, especially when needing to invite in external users. The details that I go into around it can be found at Dynamics 365 Security & AAD. As I point out there, it’s a very helpful feature, and can also help with onboarding new users within an organisation.
What I’ve found out about it, however, is that there can be some very interesting little quirks with how security actually works. Originally I thought it was a bug, and raised it with Microsoft Support, but it turns out not to be. Let me take you through the journey that I experienced last week…
The scenario is as follows. We had security set up in place, which was working perfectly (or so we thought). We’d gone through all of the following steps:
Create Dynamics 365 security role/s with appropriate permissions
Create AAD security group
Create Dynamics 365 AAD Security Team, and link it to the AAD security group
Assign users to the AAD security group
This was working exceptionally well (except, of course, when the external users hadn’t followed the setup instructions correctly). Users were logging in, searching for information, creating/updating records, etc. All was good…or so we thought.
Now, the users who are actually using the application don’t have a Dynamics 365 background. It’s the first time that they’re using the specific system, and as such, are going through a learning curve. We’re not expecting them to understand the advanced functionality at this point, though some of them are indeed venturing further/deeper into the capabilities that it brings.
One of these, of course, is the Advanced Find. Now, those experienced with Dynamics 365 will know all about it. There are good points, and there are not so good points. Functionality in it has expanded over time, though to be honest it’s still easier to run a SQL query/extract for more advanced information retrieval.
Users seemed to be fine with the Advanced Find. We showed them how it works, how to filter, set up columns, etc. We even showed them how to export data to Excel, and keep a live data connection back to refresh it!Brilliant – they were most pleased.
Then I got an email in from a user needing support. They reported that they weren’t able to save custom searches. This is of course very helpful, in order to avoid having to set up the same search/layout every time. This seemed puzzling to me, and I started to take a look into it.
Always download the error log file – it can be SO useful!
I was able to replicate the problem immediately with a test user, having assigned it the same security role. Opening the log file (which can be extremely helpful at times with troubleshooting), I looked to see what the issues were. I was thinking it was a problem with security permissions – if I assigned the system administrator role to my user, everything worked just fine.
In my error log, there were repeated references to ‘ObjectTypeCode”:4230’. This is the View settings in the security role. I therefore went to the security role, and ensured that it was set to allow access to Saved View across all permissions:
It’s only possible to set User-level permissions for Saved Views
Right – permissions set, all should be good. Let’s go ahead & try to save an Advanced Find as a view…but no! It’s still not working, and showing the same error message!
What I then tried to do was apply the security role directly to the user, rather than through the AAD security team. To my surprise (well, not really, actually), it worked. I was able to save Advanced Find views. I changed back to the user getting permissions through the security group (ie not directly), and again I had the issue.
OK – so I thought I had discovered a bug. As far as I was aware, I couldn’t see any reason why the user wouldn’t be able to save the Advanced Find view. After all, they’re able to create & save records within the system. There surely shouldn’t be any difference between saving records, and saving an Advanced Find view?
My next step was to raise a support ticket with Microsoft, and then carry out the obligatory ‘show & tell’ to the support agent. Ivan (the agent assigned to my case) was very helpful, understood exactly what I was trying to accomplish, and what the issue seemed to be. I left him with the support case, and focused on trying to find a workaround for the situation.
After a few days, Ivan came back to me with a resolution. It wasn’t a bug in the system (which was a shame – I was looking forward to having it attributed to me!), but rather a specific case of permissions.
See, there’s something called ‘privilege inheritance’. In a nutshell, there are two ways of giving access through a security role:
User privileges. This is when the user is given the permissions directly
Team privileges. This is when the user is given the permissions as a member of the team. If they don’t have User privileges of their own, they can only create records with the team as the owner
Users were able to read, create, update records without issues, as the team was the owner of these records
However as views need to be owned by a user (though they can be shared with a team), the user was unable to save them!
Thankfully it’s quite easy to fix – on the security role itself, you change it here:
With this then in place, everything then worked just fine. The user was still getting the role through the Security Team, but was now able to save these directly.
Quite an interesting little quirk, but one that is likely to come in useful when looking at other functionality within the system.
Have you come across this before? Have you found anything else that seems a little strange? Comment below – I’d love to hear!
Recently I’ve been doing a LOT of work with canvas apps. As I think I’ve mentioned before (at least once or twice!) my background is the traditional ‘model’ style app. As a result, it’s been quite a steep curve to skill up, but I think I’m handling it alright. I’m (slowly) getting used to the way that canvas apps work, the ability to put different controls on the screens, and reference each other.
Heck, I’m even starting to play with more advanced navigation concepts, based on some REALLY great ideas that I’ve seen (Clarissa, I can’t say how grateful I am to you for all of your assistance & guidance!).
Amongst all of this incredible & wonderous journey, I’ve also been learning some code. Yup – you heard me correctly! I’ve always said that I’m not a developer – I respect them greatly, but I don’t develop code.
True, I’ve picked up some SQL here & there, and will freely admit that running SQL queries against the Dynamics 365 database is SO much more powerful than running an Advanced Find. Of course, it’s necessary to know the joins, conditions & such. Redgate’s SQL Helper has been amazing along the way. With moving to cloud systems, things got a little more….complicated. XrmToolBox has the SQL4CDS tool which I’ve used several times, but I was really excited by the recent announcement/release of being able to (properly) run SQL commands against the CDS database from SQL Management Studio….
Anyhow, I’m digressing. So, I’ve been needing to learn canvas app style code. It’s like Excel commands, though (slightly) different at times. Things don’t always make sense (to me, at least) – I STILL haven’t figured out why some expressions need to be in a certain order. After all, according to mathematical principles it doesn’t matter if you write A>B, or B<A. Going to still need to wrap my mind around all of this.
In short, Patch allows you to set record values from places other than a form table to the data that you’re saving. It also allows you to save field values that aren’t available on the canvas form table (due to limitations). I’ve referred to this previously at https://thecrm.ninja/canvas-app-record-set-regarding-field/. The scenario that I talk about there is just one of the things that can be done in this way. Since that post, we’ve come a long way, and are doing most things with Patch statements (due to the scenario requirements).
So that’s all well & good. However, there IS actually a reason for me writing this blog post….crazy, right? And it’s not to waffle on and on about patch statements. It’s about a very specific scenario that we hadn’t come across to date, but that came up last week.
Now, obviously you’re now VERY interested in hearing all about it, and learning for your own situations. I mean, otherwise you wouldn’t have stuck with me through this article for so long. So, let me set out what happened.
As mentioned above, we’re mostly using patch statements throughout this specific app. That’s….quite a lot of patch statements (especially as we also have IF statements governing which one is being used, as it’s not possible to use IF inside a patch statement, but I’m digress…). I’d say we’re pretty familiar with this now.
However, even with being familiar with it, we suddenly had a problem. One of the forms that we’re saving down started to NOT save down. Records weren’t being saved, which obviously is a problem!
Bear in mind here that we hadn’t touched the code for this specific action for a few weeks. Nothing had changed in our code, and nothing had changed from a platform perspective (ie Microsoft hadn’t changed any of the underlying functionality.
Going into the statement, we immediately started testing it out, and saw something interesting. We were getting an error that a required field could not be NULL:
This was quite puzzling – although in a model app we can set fields as required, and users can’t save the record until they populate it, this isn’t true in a canvas app (well, when using Patch, at least). See, it’s technically possible to use a Patch statement to create/update a record, but you don’t have to pass in required field (values). It’s a sort of workaround (& can be used in some scenarios for benefit, actually). So this happening all of a sudden was quite strange to us.
It was even stranger as we hadn’t been using the field on the form at all. The field that was being referred to was being used for a totally different process, in a different team, & not surfaced into the canvas app at all. This really was causing us to scratch our heads, and try to think (more) out of the box. It didn’t seem to be the code (we could set a value in code, but didn’t want to as it wasn’t relevant), yet we weren’t able to ignore it. Really frustrating!
With all of this in mind, I decided to go back to absolute basics after a few hours of troubleshooting. The field that seemed to be causing all of these issues was a relatively new addition, so I checked all of the details around it:
Was the field type correct for what it should be? Yes
Was it set as required on the CDS field definition? No (not that I thought this would help, but still checked)
Was the field on the entity form? Yes
Was the field set as required on the entity form? No (again, I didn’t think I’d get any joy from this)
Hold on….on the form designer it’s not set as Required. But when I open the form, and put some values in, suddenly it IS required.
Aha! OK – I’m now starting to see some light shining on this. I headed over to Business Rules to check out what might be there. Lo & behold, there was a business rule that set the field as required (when certain conditions were filled). An example of this would be:
Now this field hadn’t been in place when the code was developed (as mentioned above) – it had come in since. I was very curious if a Business Rule could require canvas apps to set the value, and so did some testing.
Disabling the business rule removed the error from the patch statement. Re-enabling it caused the issue again. OK – so we’ve found what’s been causing this, and could put in an adequate solution to handle it.
So in short, if you’re setting a field as being required through a Business Rule, you’re going to need to address it in any canvas app as well (that’s saving data down to the same form that it’s appearing on). Why it actually happens, when just setting it as Required on the form doesn’t, I have NO idea.
But it’s a good concept to keep in the back of your mind, I believe. Especially if there are multiple people working on developing a single entity, as otherwise you could find yourself in exactly the same scenario that we did!
Have you come across anything like this, or a different piece of strange behaviour? Comment below – I’d love to hear about i!
I come from an ‘on-premise’ background. I’ve spent years in organisations with on-premise systems such as Dynamics 365. Take me into a server room that’s alive with whirring fans, and I get quite nostalgic. Those were the days…well, in some ways, anyhow. But having recently discovered some quite helpful functionality, I thought I’d share it with others!
See, when it came to Dynamics 365 security, there was no way to automate things. Yes, users had to be created in Active Directory (and also, in a folder that the Dynamics install could refer to within AD!), but they had to be manually added to Dynamics 365. There was no way to automate this (from recollection – then again my memory grows dim with the fog of time).
So what the system administrators needed to do was to manually go to Settings/Security within the system, and there they could either add a single user at a time, or multiple users. They would then assign role/s (for multiple users, all of the users would need to have the same role/s – it wasn’t possible to modify individual users within this process).
One way to slightly speed up time in handling different security roles was to have teams, relating to the business needs. The security role/s would be created, assigned to a team, and then any user added to the team would automatically get all of the permissions that they needed.
Then came the heady world of Dynamics 365 being online! Well, nothing much changed really, at least not for a little while.
But then, things really did change, in May 2019. Functionality for security teams within Dynamics 365 was increased. Notably, there was now something called a ‘AAD Security Group Team’:
So what was this magical new item?
When we create a team, and we set the Team Type to ‘AAD Security Group’, we’re now able to set an AAD Object ID. In fact, it’s required! After we’ve created this object within Dynamics 365, we can then apply security role/s to it directly (as we could to any other team records beforehand):
Let’s take a moment to reflect & think on this. Until now, we’ve had to handle security directly within Dynamics 365. Now, we have the ability to have an Azure Active Directory (for that is what AAD stands for) group, and reference it within Dynamics 365.
Suddenly new possibilities open up. As part of the on-boarding process (for example) we can users to specific AAD security groups, which will then give them access with appropriate permissions within Dynamics 365. We’re also able to have multiple AAD groups, each inheriting a different set of Dynamics 365 roles, and thereby create a multi-layering approach to different business & security needs.
We’re also able to use tools such as PowerShell, LogicApps, Power Apps & Power Automate to carry out automation around this. There’s an Azure AD connector (https://docs.microsoft.com/en-us/connectors/azuread/) which gives the ability to set up & administer these.
We’re actually using this functionality now in some of our COVID-19 response apps. Instead of needing our own support desk to manage the (external) users, we’ve provided an interface where client IT departments can quickly log in, upload a list of users, and assign them to the relevant AAD group/s. It’s very quick, and allows the users to onboard to the Power Apps within minutes!
So with knowing this, how do you feel it might help benefit you? Comment below – I’d love to hear!
Recently we’ve been rapid producing & deploying solutions, due to the current pandemic. One of the apps that I’ve been working on required quite a few fields for data capture. Well, truthfully most apps require quite a few fields, but I thought that I’d talk about this one in particular, due to something that I discovered.
Now, we all know how to create fields in the Power Platform maker experience. It’s really quite simple – you select that you want to add a new field, put in the details/type of field, & save. Hey voila – you have yourself a nice new field! You can then go on to add it to forms, views, etc etc. We all know how it’s done:
What I’ve found myself doing recently though is not to create fields through the Maker interface (make.powerapps.com), especially when there are lots of fields to create. Instead, I’ve been using the XrmToolBox to do this. There’s a very helpful tool within it called Attribute Editor, which allows you to use an Excel spreadsheet. It takes this, and creates the relevant fields through the Dynamics 365 API.
One of the reasons for doing things this way was that it allows me to get on with other things whilst the fields are being created. Although it doesn’t happen in the blink of an eye (especially when there are a lot of fields to create), I can leave it whizzing along, and do something else. This, of course, makes me feel VERY productive!
Right – back to what I was saying. So I had a lot of fields to create, and many of them needed to be datetime fields. Actually, all I needed was the time component, but unfortunately Dynamics 365 DOESN’T allow you to just show the time. It’s either Date, or DateTime, but no option for JUST Time. A flaw, in my opinion, for what it’s worth….
So I created the Excel template, started the process, and went on to do something else. I of course made sure to specify that the field type should be ‘DateTime’.
Coming back to it when it had finished, I started to place fields on forms, and noticed something strange. All of the datetime fields that I had created through this were date ONLY. This was…puzzling! Going to check the fields themselves, they were set as Date ONLY, not DateTime!
I went back to check my upload spreadsheet, and it was set correctly there. I even tried uploading another field, but still the same issue was occurring.
Now, with the way that Dynamics 365/Power Platform works, once you’ve created a field & saved it, you can’t change the field type. When it’s created it’s saved down to the underlying database structure as the specified field type, and that’s it. No way to change it…or at least not through the front end!
With this in mind, I fired up another one of the XrmToolBox tools, namely Attribute Manager. What this handy tool does is, behind the scenes, allow you to change the field type. Well, it doesn’t ACTUALLY change it directly – it clones it, deletes the original, then clones it back. There are some caveats to it working properly (ie that the field isn’t used in a view somewhere, for instance), but it’s really helpful.
Note: It only works for custom created fields, not the default OOB fields!
Depending on the field type that you’re wanting to change it to, you can select different options. However for DateTime, there’s only one option. OK – I was going to see what happened.
Well, I ran the update, but nothing changed. It was still ‘Date’ only within the interface, which was really being incredibly annoying. It wasn’t as if I could just delete & recreate it (well, I could, of course). I had dozens & dozens of these to do, and quite frankly didn’t want to spend all of that time in doing this.
Thankfully (with the help of one of my colleagues, who’s an experienced & devoted developer – thanks Sid!), we found the solution.
See, I had been doing everything within the ‘new’ interface. This is the one that Microsoft keeps pushing everyone to, as they don’t want people to really be using the Classic Interface anymore. That’s all very well & good, but the ‘new’ interface isn’t on parity (for some things).
Reverting back to the Classic interface (note that the option below is only available when working within a solution!), we discovered some hidden behaviour
We located the entity that we needed, and the field itself, and opened it in Classic. With the screen that’s presented (I do miss this in some ways – I remember the days where I almost lived permanently in here!) we AMAZINGLY have the following option:
We can CHANGE THE TYPE!! Now, this is just with the field that we’ve selected. To be frank, I have no idea at this point about any other field types, and would need to explore that separately. But for the moment, my problem has been solved! (well, to the point that I have ‘time’ values available – I’d still like to see JUST time values being an option).
So with this in mind, I merrily waded through the dozens of fields in the Classic UI, changing them all as needed. It wasn’t just a few minutes of work, but it was definitely much less time that deleting & manually creating each one!
So, really quite helpful. The only other thoughts that I had around things were that it would be nice if the various tools within the XrmToolBox could do this as well. However, the fact that they don’t seem able to actually seems to be a limitation of the API. Having gone to check the different field types & how they’re set programmatically (https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/types-of-fields), I’ve noticed the following:
There really doesn’t seem to be any way to specify the different sub-type, which is a shame!
Have you ever had a similar situation with fields? Drop a comment below- I’d love to hear about it.
Here’s a scenario that could be all too familiar to us. We’re on-boarding users (to either Dynamics 365 or a Power Platform app), & they’re new to the environment that it’s deployed to. So they’re set up, and all ready to go. Suddenly they start asking why records created (or modified) by colleagues show up as having the wrong time on them.
Does this sound familiar? I’m sure it does to quite a few people out there!. See, there’s no way to set a default system-wide time zone in Dynamics 365 (or Power Platform). At least not that I’ve come across – if you know of one, please comment below with instructions as to how to do this!
As a result, users are given the default timezone, and need to change it. This is easily done through the Personalization settings area in the app. Users click here, and then select their appropriate time-zone. Brilliant…or so you’d think.
See, when it’s one or two users, it’s generally OK to tell them to do that. However, when it’s 200 or 2000 users, you’re going to get push-back. The last thing you want is for a large number of them to start contacting you to work out how to do it (read the instructions, perhaps?).
I’ve had this scenario over the last week, where the client actually told us that they didn’t want us to tell users to update it manually. They wanted a better solution.
Well, there is a solution out there to update users. It’s the ‘User Settings Utility’ app that’s in the XrmToolBox (https://www.xrmtoolbox.com/plugins/MsCrmTools.UserSettingsUtility/). Really neat & nifty, and does just what it says on the box. Simple enough to select users (or all of them at a time), select the time-zone you’re wanting to apply to them, and click a button. Hey presto – it’s been updated
Hmm. But what if you didn’t want to have to do this manually. Or (and this is what I was dealing with), there were decent enough number of users being added to the app every few days, & I didn’t want to have to do this as a manual task.
So I started digging into how the time-zone setting was actually stored. It turns out that there’s an entity called ‘User Settings’, which is associated with a User record. Oh, and if you’re going to want to take a look at this entity to see what it contains, it’s NOT available through the front end. You can’t go into the entity list and just display it (though if you’ve found a way to do this through the Power Platform NATIVELY, drop me a line, please?).
Anyhow, back to things. There’s a value for ‘TimeZoneCode’, which maps to a specific time-zone. Aha, I thought! Right – now what’s the best way that I could work out to do this automatically. Checking in with some contacts in the tech community (thanks BlackOps etc!), Power Automate was suggested, so I started to see about how I could go about it…
So, I created a Power Automate Flow (haha…I got the name right there!). On creation of a new user record, it would programmatically go away and update the value to the one for the time-zone that I wanted it to be set as. This actually worked really well.
The only drawback is that through the user interface, it’s not actually shown as being updated, though it has been. Or sometimes it changes, but doesn’t reflect it accurately. This is somewhat annoying, and caused me quite some confusion between checking the front end to see if things were working, & confirming through the back end (& opening records up) to see that it was. I still have NO idea why this was happening.
Before changing my settings
After changing my time zone to USA (EST)
For my specific scenario, all of the users are in the UK, so I set it to update every user on creation to the UK time-zone. Obviously if you have users in different time-zones, you’d want to set this differently. This shouldn’t be an issue though, as you can expand the Power Automate Flow and add logic conditions/branches to be able to do this.
Now I think that this is pretty cool, and I couldn’t find anything out there for this. I’ve therefore decided to release this in a small solution, for others to be able to use. Part of this is the entire list of time-zones with their specific codes, so that you can update to whichever one you need to.
This post really goes back to basics, but it’s one of basic fundamentals for any successful project. In order to lay a proper foundation base, and to ensure success for a project, users need to actually know how to use the system! When going into greenfield (new) implementations, or expanding brownfield (existing) implementations, users need to know how the system works. For new implementations, it’s highly likely that many users, if not all, will never have actually used Dynamics 365 before! Going into a completely new system, with no understanding of how it works, can be extremely daunting. If not handled in the right way, and the right skills imparted, it can be a major blocker to the project itself.
Incidentally Microsoft Learn has closed the gap slightly on this. The different learning paths & courses can be really helpful to gain understanding of the system, and the basic components. I’ve done quite a few of these (the gamification angle helps with that!), and am generally quite impressed!
So with all of that in mind, I thought I’d share something. Over the last few years, I’ve noted the D365 Academy Belt Program (https://www.d365ug.com/participate/academy/blackbelt). It’s something that I’ve toyed with doing, but never got round to it.
I’ve recently had the opportunity to look over the actual material that’s used for the different belt courses. Not only have I looked over it, I’ve actually gone through all of the different belt training as well, to see how it actually is. Even with my knowledge & experience of the system, I’ve still learned/improved my knowledge in several things. I think it’s a really good structured learning system, and furthermore, actually shows clients how to become system ‘power users’!
I’ve listed below the different belts, and what’s included in each one
White Belt
Creating a trial – how to sign up & set one up
Overview of users – what they are
Office 365 vs Dynamics 365. The differenced in how they work when it comes to users
User maintenance – setting up users & teams, and handling licenses
System settings – how to set organisation-wide defaults
The basics of workflow – what a workflow is, and what it does
Form configuration – what is a form, modifying fields properties to display accordingly
Creating new fields – different field types & options
View configuration – creating, adding columns & filter criteria to display the data
Blue Belt
Security concepts – overview of how security works in Dynamics 365
Business Units – what they actually are, and how they help with things
Security Role Concepts – how they’re used, and the power that they bring to the security model
Security Role Applications – how to set them up, and showing practical uses with examples
Hierarchy Security Concepts – what exactly is a security hierarchy, and why it can be helpful
Hierarchy Security Application – how to set this up, and use within the system
Ownership Teams – why this can be helpful when using records
Access Teams – how are these different from the other teams, and how they can be used
Auditing – how Dynamics 365 has an in-built audit trail for records, and the benefits of it
Purple Belt
Advanced Form Configuration -sub grids, charts, navigation links & iframes
Creating Custom Entities – building on the knowledge of the system so far to implement these
Calculated & Roll Up Fields – what these are, the differences, & where to use them best.
Field Level Security – ways to restrict specific data fields on entities to a specific team of users
Charts, Dashboards & Reports – how to set these up, and the different ways in which they help
Document Generation – how to automatically create Word & Excel documents from templates
Business Rules – ‘no code’ approach to making fields required, hiding them, setting values
Business Process Flows – guiding users to enter data in a specific way, with making it easier
Branding – making your site reflect your company colours & logo
Site Map Editor – placing just those entities that users access to create a clean interface
Brown Belt
Duplicate Detection Overview – what it is, and how it works
Duplicate Detection Configuration – how to set up rules to enable it to work in the right way
Data Imports – how to configure & set them up to then import data into the system
Data Mapping – the key item in data imports. Getting this right is imperative
Bulk Deletion – carrying it out, and what to be careful of
Cascading Relationships – how these can be so powerful, & where to use them best
Data Integration – best practise thinking in how to approach integration
Black Belt
Workflows – what are they, understanding how they work
Realtime & Background – the differences between these two, and how you should use each one
Power Automate – how it differs from traditional workflow, & how to start configuring one
Document Storage – the different options available, including cost considerations.
Extending with 3rd Party Tools – using tools available in the XrmToolBox, and how this can help
Power Apps Introduction – what these are, and scenarios for them
Model/Canvas Apps – the differences between the two, and considerations for each
I’ve been working with Dynamics 365 for a decade now, yet there were still things that I felt I learned from the course. I feel that it’s possible to learn from everything, even from what we’d consider to be a ‘simple’ source.
So what are the next steps for people looking to learn? Well, Microsoft Learn (https://docs.microsoft.com/en-gb/learn/) of course would be a great place. Carrying on from there, you could look to start taking some of the available exams. There are plenty of these available, ranging from basic fundamentals all the way up to solution architect.
I hope that this has been useful to you – if you’ve come across other great introductory training resources, please let me know!
I’d like to start off here by admitting that in a previous blog post that I put up, I mentioned that it’s not possible to route customers to different queues through the chat itself. That was wrong – thankfully several very nice people at Microsoft reached out to let me know how it’s done (thanks BTW for reading my blog!). I therefore thought it would make a good article, as people do ask me about this from time to time.
So, how exactly does Omnichannel facilitate this? Well, there are two parts:
Pre chat surveys
Routing rule items
Pre chat surveys
These surveys are really quick & easy to set up (or even more complicated, if you so desire). To start getting to grips with them, open a Live Chat record, and go to the ‘Pre-chat survey’ tab
Here, you’ll be able to set up your questions, which is done by clicking the ‘Add Question’ button. When you do this, you’ll get the following prompt.
So, three of the four questions are really quite simple. You need to give it a name (as every system record needs), the actual question text, and whether it’s mandatory or not. The fourth question ask you what sort of question type you’re looking for. The options available are:
Single line of text
Multiple lines of text
Option set
User consent
If you select ‘Option set’, you’ll be prompted to enter the values. These should be separated by a semi-colon character:
With our pre-chat survey questions being set up, let’s see how we go ahead and use them for routing.
Workstreams
If you go ahead and open up any workstream record, you’ll see several tabs available. Two of these tabs are Context Variables, and Routing Rule Items. There’s usually one workstream per chat channel, with setting options within it as required. Opening up the workstream for the Live Chat, we can see them there:
Let’s take a closer look at the Context Variables first. Going to this tab shows us the following:
Woah. Where did those entries come from? I didn’t enter anything here – though I can create context variables if I want to.
Well, remember those pre-chat survey questions that we created? Each time one of these is created, it creates a context variable record for the workstream that the chat is associated to. So each of my questions (and I have four of these) now have a corresponding entry.
OK – so the system does that. But how does that help me when looking at trying to route things?
Simply put, these are the building blocks that we’ll set up in the Routing Rule Items to flow the customer chat through to an appropriate location. Let’s go and create one to see what happens.
We need to set the queue that this rule to apply to. Then we’ll go ahead and set the condition/s that we’re wanting to apply for this queue. There are several different possibilities to start with:
Selecting the entity that we want to use for the rule will then allow us to pick an attribute for that entity. So;
Account, Contact, Case & Live Chat Context will give an option to select one of the attributes from the entity
Context Variables will give the available context variables to choose from
You’ll then be prompted to select an Operator. These will vary depending on the type of field (eg a number field will have additional options such as Greater Than, Smaller Than, etc)
Finally, you’ll enter the value that you’re looking to match with for the condition. This is free text (it’s not auto-populated with values). So in summary, you’ll have something like the following:
And tadaa! it’s active. Brilliant!
We’re able to stack up multiple conditions to cover specific scenarios. An example could the following:
Customer has a Kawasaki motorbike (not a different make)
Customer’s annual spend falls into the ‘high spend’ bracket
There are plenty of other scenarios that can be covered, and the conditions allow this to cover quite complex situations.
So, some things to note around workstreams & routing rule items:
You can have multiple routing rule items per workstream, each one routing to a different queue. These are evaluated in the order that they’re saved in. Eg if there are 4 rules, an incoming chat will be evaluated against rule 1, then rule 2, etc
When a routing rule condition is met, the chat gets routed to the destination. No other evaluation against the remainder of the rules is carried out
I hope that this has come in useful, and put some interesting thoughts into your mind as to how you could implement this at your organisation or clients!
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!
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!
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!
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!
