I never, actually, tried the Field Service before – just never had to.
You might say that’s so much for being an MVP
, 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:
https://www.microsoft.com/en-us/download/details.aspx?id=56050
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: