In this blog, we highlight a lesson learned when we used a Dynamics 365 Customer Engagement online data source connector, called Instance Web API, for Power BI reports.
Dynamics 365 Field Service offers a wealth of configuration options for the resources you will be scheduling. Microsoft’s documentation describes these configurations without context making it difficult to understand their overall impact on the system. Never fear, PowerObjects is here! Our goal with this 2-part series is to demystify the configuration settings and help you understand the system-wide impacts. In Part 1, we discussed configuration of the Bookable Resource record. Today, we’ll be looking at all the related items that impact scheduling. Let’s go!
The Work Hours you apply to each Resource are going to determine when they are available to work. If you have a resource that typically works during the week, but is willing to work on weekends once in a while, you need to set their Work Days to be every day of the week. If you only set their Work Days M-F, they will never show up on an availability search on the Schedule Board for weekend work.
Business Closures work similarly. Your Resources who are covering holidays need to be set to Do not observe or else they won’t appear as available on holidays.
One of the biggest considerations for Work Hours is whether to include Breaks. While it seems like a good idea to include Breaks to make sure field technicians get rest, the downside involves Resource Schedule Optimization (RSO). If you have RSO enabled in your system, the optimization engine will assume that all Breaks will occur at the Start/End Location for the Resource.
If your Resource is configured to start work at the office each day and scheduled to have a 15-minute break mid-morning, then RSO will assume the Resource is driving back to the office for that break. You would likely end up with excess travel times unless the work order location happens to be very close to the office.
Determining how to structure territories is a big discussion that we’ll cover in a future blog. For the purposes of this blog, understand that Territories are a geographic region in which the Resource works. Resources can be part of as many Territories as needed.
It’s important to note that a work order requirement (or Requirement Group) can only exist in ONE territory. That means only the technicians who are members of that territory show on the Schedule Board during availability search. One example is Resources that typically work only in one territory but cover a second territory during holidays. For these resources, you’ll either need to include that Resource in both territories permanently or remember to add them to the second territory just before the holiday (and then remove them again after the holiday).
The easiest way to explain the difference between these two:
Categories don’t have any relationship to whether or not someone can do a job. A category simply says you’re responsible for that job.
Characteristics are how we identify in each work order who is qualified to perform the service needed. For example, a small electrical job could possibly be done by an Apprentice. A more complicated job may require a Journeyman. A full house retrofit is likely to require a Master Electrician.
In this case, we’d have a characteristic called Electrical, accompanied by three Rating Values: Apprentice, Journeyman, and Master Electrician.
Let’s say your organization employs a highly skilled electrician who is responsible for safety at the worksite. You would set this person up this way:
Configuring your system for RSO includes determining which of your Resources will be included in the optimization. Some Resources wouldn’t benefit from optimization (such as Resources that only respond to emergencies), and you don’t want to waste system resources looking at their schedules.
Once RSO capability has been enabled in your system, each Bookable Resource record will have a new tab. Simply set Optimize Schedule to Yes, as shown below, and that Resource will be included.
As we mentioned in Part 1 of this series, each Resource must have their Start/End Location fields completed and they must be the same for RSO to function properly. The Start/End Location is also used by the optimization engine as the location where all breaks will occur. (See Work Hours above.) If you’re not careful, this can have a big impact on travel times.
Understanding the various configuration options available is the easy part. Knowing how those configuration changes will impact the system as a whole is the hard part – but also critical to effectively and efficiently using resource configuration. Hopefully, this blog series has helped to clear up some confusion and demystified this aspect of Dynamics 365 for Field Service. If you have input, please comment below.