Monthly Archives: May 2018

Configuration Data Manager – updated for V9.0.2


Looks like something has changed in V9 recently that did affect my Configuration Data Manager solution, too, so there is an updated version you can download now which works with V9.

It also fixes a couple of issues related to big integer numbers and to the missing N:N relationships. Yet keeping in mind that it works in the most recent V9, it’s just a better version overallSmile

However, just to show you how easy it is to use this solution (and you don’t even need to install any tools on your machine), here is a quick recording me bringing over a few accounts and a few related contacts from one environment to another using this tool:

Just keep in mind this tool is not meant for large data transfers. It’s best suited for moving “configuration data” between different environments as part of your other solutions.

Hierarchy security – what if a user did not have access to their own records?


Hierarchy security has a bit unexpected side-effect. In theory, it is supposed to give managers access to the records assigned to their subordinates – I am assuming the idea there was to bypass role security and to quickly give managers access to that data.

But what if we had a record assigned to a user, and what if that user did not have any permissions (not even “read”) for the entity? Would a manager of that user be able to see such record?

As in the example below, my “Test Sales Person” role does not give access to the account entity:


And it’s the only role assigned to the Crm Test1 user:


Now, there is an account record assigned to Crm Test1:


It is a “historical” record stuck with the user from the times that user had access to the account entity.

Right now, though, if the CrmTest1 user tried to open that account, here is what they would see:


And, in the log file, there would be this error message:

<Message>Principal user (Id=165066b2-a658-e811-80be-00155d00c103, type=8) is missing prvReadAccount privilege (Id=886b280c-6396-4d56-a0a3-2c1b0a50ceb0)</Message>

However, CrmTest1 has a manager:


That manager has a slightly customized Sales Person role:



Normally, that particular manager would only see account records assigned to themselves.

However, because of the hierarchy security, our manager user can see the records assigned to his/her subordinates:


In other words, hierarchy security ignores “subordinate user” permissions – it’s just looking at the ownership when deciding if the manager can see those records or not. And the user can loose permissions as a result of role change or, sometimes, as a result of business unit change (since that’s when all user roles will be removed automatically).

At this time Microsoft Dynamics 365 requires version 4.6.2 of the .NET Framework for plugin assemblies


A few days ago somebody raised a question in the community forums:

Currently, Microsoft Dynamics 365 requires the .NET Framework version 4.6.2 for plug-in assemblies. Rebuild the assembly with the .NET Framework version 4.6.2 and try again.”

Well, it’s hard to know what’s happening in various environments, so I made a note for myself but did not pay too much attention. That is until a few days later somebody else (yes, Rob K), mentioned that he could not import my TCS Tools solution into V9.

That sort of rang a bell, but I still did not make the connection right away.

To my surprise, I got exactly the same error when I tried importing TCS Tools into a new V9 trial a day or two later.

If you look at the thread there, you’ll find a response from Vladimir Karukes – basically, we need to specify 4.5.2 target for the plugin assembly to avoid the error. Turned out he was spot on.

In case with TCS Tools, here is what happened:

  • I’ve always been building it using the on-prem version, and it works fine with 4.6
  • So the target FW version of my assemblies used to be 4.6(?)
  • At which point did it stop working in V9, I am not 100% sure, but, looking at that thread in the community forums, it seems there was some recent change


So yes, rebuilding for 4.5.2 did solve the problem.

But, before I got to 4.5.2, I actually tried 4.7.2.. Guess what error message came up then? It was exactly the same error, but it was saying that my assembly was supposed to target 4.7.2 this time around.

In other words, the error message seems to be misleading – Dynamics seems to be looking at the actual target FW version of the assembly and just echoing that version number where it should be asking for 4.5.2(since it seems to be the highest supported version in the online environment).

PS. Still have to rebuild Configuration Data Manager tool, too, but that’s for tomorrow..

Field Service: Trying it out (Part 2)


There are a couple of things about Resource Scheduling / Field Service I learned today which may be worth sharing, so here we go:

1. For those who want to try Field Service on-premise

If you already have access to the customer source, you can download Field Service files from this link:

There is a catch, though. When installing the Field Service into your on-prem Dynamics instance, you will be asked to login to the Office 365, and you will actually need to login using the account that has access to the required Dynamics 365 license (as noted in the previous post, Field Service is licensed through the dual rights).

So, if you are not there yet (and you’ll need to be there if you ever decide to get Field Service on the production instance of your on-prem Dynamics), there is a workaround.

What you can do is:

  • Create a Dynamics 365 trial account
  • Open the link above and provide that account credentials
  • Download Field Service solution
  • Deploy it in your on-premise environment
  • When asked for the credentials, provide the same trial account credentials


2. For those who want to try Resource Scheduling Optimization (on-premise or not)

I thought it would be just a matter of installing the solution, but, as it turned out, things are somewhat more complicated.

  • Resource Scheduling Optimization is not available on-premise
  • Resource Scheduling Optimization is not available in the trial online environments


Neither of that is too obvious when you first look at the resource scheduling optimization page:

However, that just seems to be how it is. Have a look at the discussion here:

Either way, there is no resource scheduling optimization application in the trial environment:


And, as for the on-premise, if you look carefully at the article I mentioned above, you’ll see that it only applies to Dynamics 365 online:


Gartner peer insights: Microsoft vs Salesforce vs SAP

Normally, I don’t like participating in any kind of Dynamics vs SalesForce vs Oracle vs .. discussion, since, in my mind, those are all great products, and the success of every particular implementation depends more on the skills and experience of the team working there than on the product itself. So the purpose of this post is not to start such a discussion.

However, I was looking for some reviews of the Field Service and found Gartner Peer Insights site below. There is something interesting about the numbers – you can actually see them for yourself here:


Even though Microsoft has the same overall peer rating as SAP, and it’s not that far behind SalesForce from that standpoint,  there is a huge difference in the percentage of Microsoft customers who would be willing to recommend Dynamics when you compare that to the SalesForce or SAP customers. Well, that difference is not in favor of Dynamics, that’s the interesting part.

Just a little over 50% of the clients would be willing to recommend the product.. I am not a specialist in the client attrition etc, but I have a feeling that’s a bit too low. Not sure why it’s happening.. but I am wondering if some of that is caused by all the changes Dynamics has been going through in the last few years (branding, portals, licensing, solutions lineup, etc)?

Either way, whatever it is, those are some interesting numbers to consider. I’m just hoping they will start getting better for Dynamics soon.

Field Service: Trying it Out

I never, actually, tried the Field Service before – just never had to. 

You might say that’s so much for being an MVPSmile, eh? And you would probably be right, but, to my excuse, Ottawa is still using on-prem version of Dynamics almost exclusively. It’s a bit of an on-premise enclave here – Microsoft is pushing online version everywhere, all the new features are first released there, Dynamics V9 has been around for a while. And, yet, on-prem V8 version is still holding its ground in Ottawa. Mostly because it’s complicated for the government clients to opt for the online deployments, but, also, because on-premise “XRM” usually meets the requirements quite well.

Well, at least that used to be the case until a few days ago when it turned out the client was looking into starting to use the Field Service.

Of course, in the ideal scenario we would be using Field Service on-premise, but it’s not that simple because, according to the licensing guide, Field Service is licensed through dual licensing:

Microsoft Dynamics 365 for Field Service (On-Premises) is not available as a standalone on-premises Client Access License. Rather, access to on-premises functionality is available only through Dual Use Rights leveraging the Dynamics 365 for Field Service, Enterprise edition User Subscription License.

This creates a bit of a problem, since what we have there is Dynamics 2016 on-premises, upgraded to 8.2. Apparently, we will have to figure out the licensing part before we can start using Field Service. But that’s what the online trials are for – they are for us to try them.

Moving on then.

I’ve been playing with the field service for just a little while so far, and here are some of the observations:

1. There is a bit of inconsistency in the names. It does not help when you choose Resource Skills and are presented with the Active Characteristics. Not that it’s a big issue, it just always comes out as a surprise (“wait a second.. this was supposed to be a skill.. ah, right, it’s just named differently”). Or when choosing “Proficiency Models” brings you to the Active Rating Models view.

2. It’s a relatively complex solution, so setting up everything from scratch presents an interesting but somewhat challenging problem. There is sample data which, unfortunately, I was not able to install because of some errors. Maybe it was caused by me experimenting with the environment before trying to deploy the sample data, or, maybe, it’s something with the sample data package.. Anyway, you might give it a try:

3. That said, what’s the best way to start setting it up?

It seems that “Resource Scheduling” is one of those areas which may need to be set up first. You can’t schedule a work order until there are resources, and there is no value in specifying resource requirements unless there are resources which can meet those requirements.

This is why, based on how all those solutions are structured, it probably makes sense to look at the resource scheduling first.

So, for what it’s worth, here is my quick fact-sheet for the universal resource scheduling:

– This is how the dependencies between all those solutions look like in Dynamics:


Down at the bottom, there is a CORE solution (there is no such “solution”, really. It’s just the functionality which comes with the default solution). It’s Dynamics 365 with all the core entities, security features, workflows, customization options, etc

Then, there is a Universal Resource Scheduling solution. Which, again, is not so much a solution, since, even though it does not seem to require (in terms of the functionality) Field Service or Project Service solutions, having one of the other two (Field Service/Project Service) is a pre-requisite for the Universal Resource Scheduling. In fact, universal resource scheduling components are included into both Field Service and Project Service solutions. That’s the reason those three solutions are somewhat blended on the diagram

And there are two other solutions which can be installed on top of all that: Resource Scheduling Optimization and Connected Field Service. Those are extensions to everything else.

– As I mentioned, Resource Scheduling Solution comes with either Field Service or Project Service solutions



– Resource scheduling is only enabled for a few entities out of the box, but we cab enable it for “any” entity (using quotes here since there might be exceptions)


– Booking process is based on the resource requirements. A resource requirement is where you can specify the duration, skills, resource preferences, resource roles, and some other parameters


– Once we have a resource requirement, we can go to the scheduling board to book resources based off their availability


– We can link the same resource requirement to different records, although, I ‘m not sure what would it mean, conceptually. It seems resource requirements are supposed to be unique for each new booking since there are fields such as duration, fulfilled duration, and remaining duration. One way to think of the resource requirement is as if it were a template: you need a resource with this kind of skills/roles for that long. If you want a specific resource(s), you can specify resource preferences. And, then, based on those resource requirements, you can keep booking the same or different resources until the resource requirement (in terms of skills, roles, duration, etc) has been fulfilled. Actually, resource requirement is almost like a task prototype. You can even create a resource requirement that’s not linked to any particular record


– When starting to work with the resource scheduling, you might find these two links helpful (I’m sure there are other links – it’s just a matter of starting somewhere):

– When setting up the booking metadata, you may run into this error:


It just means that you’ve selected a booking status which does not fit:


It’s called “Core Booking Status” in the error message, and it may sound a bit confusing at first. But, I guess, there was no better name because of how those fields are named in the solution.

– When defining the skills for our resource requirements, we can choose the characteristic (which is, really, the skill), and the rating value. However, that rating value is coming from all the rating models, it seems, and it should probably be limited to only those rating values which make sense for that characteristic:


If we had “Rating Model” lookup on the form above, we would be able to configure dependent lookups (so that only those rating values which are applicable to the selected rating model would show up). It should not be that difficult to add the lookup, though – only took me a few minutes here:


And now I only see rating values for that rating model in the list:


It looks like the same may have to be done to the Bookable Resource Characteristic entity. Otherwise, it’ll be mixing up all available rating values from the different rating models:


Not sure there is an “out of the box” approach, and, also, whether it makes sense to make those changes. You are more than welcome to tell me why it’s not, I just need to know why then.

And there are a few things I’d still like to confirm/clarify since that functionality does not seem to be available out of the box:

– What if I need to send more than one resource? I’m guessing I’ll need to specify multiple resource requirements and book them for the same time? Is there any way to instruct the system that all those resource requirements should be booked for the same time?

– There is a “crew” bookable resource type and there are other bookable resource types. However, it seems bookable resource entity doesn’t have provide a relationship to specify that one resource can act as part of another. Which likely means that if a resource can act on their own in some cases and as part of a crew in others, there will be no easy way to avoid booking conflicts

What’s next? It seems resource scheduling optimization is what I need to look into next, and, then, I can go back to the field service:

Model-Driven Power Apps: Something went wrong

I love the idea of model-driven PowerApps. XRM is what I’ve been doing most of the time, so that kind of XRM-only plan would be just the right plan for me.

But what I do need is the ability to export/import solutions – so, seeing how model-driven PowerApps are, basically, re-using Dynamics 365 admin interfaces, I went for the regular solution building route:

  • Create a solution
  • Add an entity
  • Publish
  • Export the solution
  • Delete the entity
  • Delete the solution since I changed my mind along the way
  • Publish

It was all going exceptionally well, but, apparently, something went wrong at the very end of that process:


Something went wrong – An unknown error occurred

That’s not a very useful message, so, after hitting “Reload this page” a few times and reloading the browser, I tried creating another application and ended up looking at this message:


Organization ID not determined

So I’ve logged out.. closed the browser.. logged in at, and tried to create a new app. This time the error was starting to make sense:


The Solution ID is incorrect or missing

Ok, so maybe removing that new solution confused powerapps somehow? Turned out I was able to open All Solutions screen using Advanced Customizations option:


At which point I tried to import the solution exported before, and got another error:


This solution package cannot be imported because it contains invalid XML 

Long story short, the only way out of this error cycle was to create a new environment and to start creating a new application in that environment:


But I still need to find a way to do those solution manipulations.. any thoughts on what went wrong?