As I revise for the MB2-718 exam (Microsoft Dynamics 365 Customer Service) I’m creating blog posts detailing all aspects of my revision. I hope these posts will aid anyone who is also revising for this exam. In this post I will continue with my series on Field Service, by expanding on the concepts I raised in my introduction and looking at how we plan for a Field Service implementation.

In my previous post I gave an introduction to many of the Field Service concepts. In this post I will continue that overview and start to consider how we plan for a Field Service implementation. You can see the skills measured statement below, notice I have highlighted that we need to understand how to plan for a Field Service implementation.

Below I will describe several of the key Field Service entities and what “qualities” they have;

Resources

• Typically a user who will execute Field Service work. (But can also be defined as contact, equipment or group.)
• Can have characteristics and these can have a proficiency rating. Characteristics are typically the resource’s skills and certifications.
• Can have roles, such as a repair engineer etc.
• Will have an associated calendar that can define working hours.
• Resources can be linked to a warehouse.
• May have some scheduling parameters, such as each day what location do they start and end from.
• Will be linked to an organizational unit.

Note: Resources are part of a concept known as “Unified Scheduling”. Meaning the resources can be defined and booked against work orders but the same resources can be booked against project tasks from Project Service Automation. And additionally could be applied to other entities as required. (Such as cases, opportunities or even custom entities.)

Work Orders

• Captures the essence of the service to perform.
• Used to coordinate and schedule resources (By linking to resources using resource bookings)
• Will be linked to a service account, this will define the location for this job.
• May additionally be associated with a billing account.
• Work orders have a status. (“Open – Unscheduled”, “Open – Scheduled”, “Open – In Progress”, “Open – Complete”, “Closed – Posted”, “Closed – Canceled”.)
• Each work order status can optionally have a user definable sub status. You might, for example, want to define a sub-status on “Open – In Progress” to signify what progress is being made.
• Can be based on one or more pre-defined incident types. (See incidents below.)
• When work orders are scheduled they will have one or more bookings. (See bookings below.)
• Can include service tasks.
• Maybe linked to products.
• Will be linked to one or more services to be performed.

Incidents

• Defines repeatable incidents of service, to aid work order creation. (By speeding entry and ensuring a consistent approach is applied.)
• Can include a list of characteristics (skills) the engineer should have to complete this type of incident.
• Includes a list of service tasks to instruct the engineer what steps to follow.
• May include one or more products that will be consumed whilst conducting this incident type.
• Will include one or more services and how long those services are expected to take.

Bookings

• Booking are a definition of which resources are planned to execute which work orders.
• Adding a booking to a work order will change the status of the work order from “Open – Unscheduled” to “Open – Scheduled”.
• Known as “Bookable Resource Booking Records”.
• Each booking will be associated with a resource, They will have a start time, end time and duration.
• Each booking will have a status including, scheduled, in progress, traveling, canceled and completed. (etc.)
• An estimated travel time will be calculated and linked to each booking.

Products

• Products can be inventory items, non-inventory or services.
• When a service can have associated field service pricing information, which defines minimum call out prices etc.
• Start off in draft mode and must be published before being included in incidents / work orders.

Customer Assets

• Used to define equipment held by the customer

Agreements

• Reflect any contractual agreements to perform regular service.
• Agreements are typically used to preventative maintenance or service scenarios.

Warehouses

• Locations that hold inventory.
• Maybe relate to physical buildings but could also be virtual warehouses. (One common example of a virtual warehouse might be an engineers van.)

Organizational Units

• Used to define the locations from which engineers work.
• Can have Latitude / Longitude values which are then used when calculating routes for engineers. (Note: These fields may not show on the organization unit form by default, meaning you have to add them!)
• Each organizational unit will be associated with a list of bookable resources who operate out of that unit.

Planning for a Field Service

Implementing Field Service can be a complex task! Therefore planning how to approach that implementation could be a significant task.

In my introduction I described a concept that we have an overall flow to Field Service. Starting with work order creation, moving into scheduling, then service execution and finally billing. This concept might be useful to keep in mind as you need to plan for these processes are part of your implementation.

Most of the components / entities that will be included in a Field Service implementation can probably be related back to one or more of the core processes shown in the process flow above. Therefore your planning should probably document the “current processes” and the “to be processes” for each of these business processes.

Tip: I don’t recommend diving straight into a Field Service project without doing this upfront planning. Why? Well, if you do just jump straight in you may find in the later stages that the required data wasn’t correctly captured in the early stages. Often I like to actually work in reverse! By for example, considering what does my final bill need to include? Knowing this will help me understand what information needs to be captured right at the start of the process when the work order is created.

Below I will give some pointers on the kinds of things you might need to consider for each step in the process. However this should not be considered a complete list! I am simply listing some of the core concepts to consider. Your key take-away from this should be that your planning needs to encompass a large number of considerations!

Work order creation

Here you will need to plan what information needs to be entered. This will include defining your service tasks, products, services, price lists (that will later drive billing), incident types etc etc.

As work order creation is the first step in your business process flow, I hope you can see that we need to configure quite a few attributes that will be used later in scheduling, service execution and billing. A key step in a Field Service implementation is configuring correctly all of the attributes that are used to make up a work order.

Additionally you will need to consider who will create work orders and how this will happen. Will they come from converting cases or do you need to additionally define service agreements that will generate work orders etc. It might even be that your are using IoT devices to make use of connected Field Service to proactively create work orders based on detected events.

Assuming each work order could consume one or more parts, you will also need to think about defining a product catalogue. The product catalogue will define all of your inventory and non-inventory products. If you need to hold inventory of products you will also need to consider warehousing. Typically you’ll want to define details for your physical warehouses but often virtual warehouses may be created. (For example, if engineers carry stock in their vans then their vans may need to be defined as virtual warehouses.)

Schedule / Dispatch

For scheduling you’ll need to consider what parameters might apply when scheduling your work orders, including;

• What resources are needed,
• Do you need to schedule “just” users or does the scheduling also need to include other resource types such as equipment,
• What characteristics / skills are important,
• What territories exist,
• What are the working times (and time zones) for each resource,
• How will you manger “downtime”, like staff training, team meetings etc.

Additionally you will probable need to consider how to configure / customize the schedule board. For example, assuming you might have multiple dispatchers or many type of work orders that should be scheduled separately you’ll need to consider what views of work orders will be needed. So that each dispatcher can quickly find the work orders they need to process.

Will scheduling be completely manual? With dispatchers simply dragging items onto the schedule board. Or will you use the scheduling assistant to partially automate this process. Or maybe RSO is needed to automatically recommend the most efficient approach.

Service Execution

Service delivery / execution involves understanding how you engineers will work whilst on site. Will they use the mobile application? What device type(s) will they use? (Phones, tablets laptops etc.) And will they need to use their mobile devices offline. (Meaning you might need to consider what data is synchronized to the device.)

What status reporting is needed, such as do you need to be able to communicate back to the customer the location of the engineer whilst traveling to a job.

What data much they collect from the customer, some of which will be key to support approvals and invoicing. (Such as what products have been consumed.)

What data will the engineers need visibility of? For example, what account record must they be able to see and if the customers have defined assets (customer equipment) will they be able to see and update this data.

Approvals / Billing

Billing will obviously be an important topic! You will need who and how the engineers work should be approved. And then what is the process for creating and sending the bill to the customer.

When work is completed it may be a common process to want to consider what follow-up steps are needed. For example, you might want to send of a Voice of the Customer survey at capture customer satisfaction ratings.

It will be quite common that you need to consider integrations with back office systems. As it maybe common to record the work completed in Dynamics 365 but the actual invoicing and cash collection maybe carried out in another system.

Field Service does include inventory management and purchase order processing but you may need to consider if any inventory related integrations are needed with your ERP system.

Hopefully I have given you lots to consider for you MB2-718 revision! Planning for a Field Service implementation is not easy, I guess that will be why it has been itemized in the skills measured!