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 review the setup & configuration of Field Service.
For reference I have shown the skills measured statement for the Field Service section of the MB2-718 exam below. Many of the items mentioned will be impacted by setup & configuration! Making understanding how to configure the Field Service application an important topic.
In my introductory posts I described many entities which must be configured to support your implementation of Field Service, including resources, products and services. (Plus many more.) So far we have actually only scratched the surface of what needs to be configured! Ther are many items yet to cover including territories, price lists etc etc.
In addition to items like this you will also need to understand how security roles are applied in Field Service and what administrative settings we have available.
Collectively all of these thing cover a large amount of concepts! Because of this I will break this post down into several parts;
- Part One (This post) – Security roles and admin settings
- Part Two – Products and Services
- Part Three – Resources
Security Roles
Field Service gives us five security roles which should make the process of assigning the correct access privileges to users easier.
Note: I am going to make an assumption that you have a basic understanding of how the security model within Dynamics 365 operates. If this is a new concept then I suggest you research the security model as part of your revision for the MB2-718 exam.
As with other security roles you can use these roles straight out of the box or you can take copies and amend as required.
Administrator
These are people who will need access to the Field Service administration options found in the settings area of Dynamics 365.
If you look at this role you can see that it grants full access rights on all entities connected with Field Service. This will include entities that are specific to Field Service such as work order but it will also include other system entities. (Such as account and activity.) It is important you are aware of this as you could be granting more access than expected! Administrators will have organizational level access to things like accounts and resources, meaning they can see and amend all accounts and resources.(Plus many of the configuration options connected with Field Service.)
Dispatcher
Dispatchers are people responsible for scheduling and management of work orders.
- Has access to the scheduling entities
- Can create and add incidents, products, services, tasks and skills to work orders
- Has permissions to time off requests and time off reasons.
- Can view work order schedule rules
See below how the dispatcher often has full access on their business unit and all child business units. (But not full organization access.)
Inventory Purchase
The inventory purchase role is given to people who are responsible for inventory, purchase orders and equipment returns.
- Has access to inventory, inventory journals, purchase orders and returns.
- Typically, this role is combined with dispatcher role when required.
This role actually grants access on a limited number of entities. Mainly included are the purchase and inventory entities. But when access is granted it is for the entire organization.
Resource
Anyone with the resource role are people who will access Field Service. (Aka : The field agents.)
- Only has basic access to work orders and work order related entities.
With this role you will see that access to system entities is very limited. And even custom entities tend to be limited to only records owned by this user.
App Access
The app access role is a very simple one! It just grants access to the App. Typically field agents will therefore have the resource role and the app access role.
NOTE: It is typical that most users will also have one or more other “standard” CRM roles giving them access to other CRM entities. Such as contacts, opportunities, cases etc. You should also keep in mind the way Dynamics 365 security roles work and ensure that users with Field Service roles aren’t inheriting more access than you intended!
Administrative Settings
Below you can see a screen shot for the administrative settings of Field Service, there are a lot!
This first administrative setting is “Field Service Settings”. As you can see below this option gives us access to quite a variety of settings. Including;
- Prefix and numbering logic for work orders, returns and purchase orders.
- Default’s such as work order status and default warehouse.
- When should invoices be created. (Never or automatically on a work order being posted.)
- Plus what pay types to use for regular pay, overtime etc.
- Details of when and how work orders and bookings are created for agreements.
I hope you can appreciate that defining the options in this “Field Service Settings” area will be one of the first tasks you’ll need to complete when implementing Field Service.
As you have seen there are quite a number of administrative options, ideally these need to be defined before you start creating work orders. Some key items include;
| Item | Description |
| Characteristics | Hold the skills and certifications. Resource can have skills, along with a proficiency grading. Work orders can required skills possibly populated by adding an incident type to a work order. These two data sets can come together to ensure the right engineers are scheduled for particular jobs. |
| Territories | The territories that you service. (Typically aligned to your sales regions.) Accounts and resources can be associated with territories. We can therefore ensure appropriate resources are allocated to work orders.
Note: |
| Priorities | You can define custom priorities that can be assigned to work orders. |
| Warehouses | Are the physical or virtual locations that can hold inventory. |
| Postal Codes | These are lists of post codes that can be associated to territories. |
| Products | Details of products that can be consumed (or sold) whilst completing a work order. |
| Resources | These are the bookable resources that can be scheduled. A bookable resource could be a user, contact, equipment, account or group. |
| Price Lists | The various price lists required to define the prices for the products and services you will deliver. |
| Time Groups | Field Service contains the ability to configure time groups, these are very useful if you schedule appointments in terms of defined time slots. For example: You book may only book two appointments per day, one in the morning and one in the afternoon. |
| Payment Terms | Allows you to define the descriptions used to reflect payment terms. |
| Incident Types | Incident types are an important concept that can help speed the entry of a work order. For commonly occurring service requirements you can define an Incident Type. This can contain information about the services to be completed, products required and skills needed to address that type of incident. |
| Tax Code | If an account is not tax exempt then a sales tax code is assigned to highlight the rate of tax they should pay. |
| Booking Statuses | Allows creation of multiple sub-statuses mapped to a booking status option. |
| Service Task Types | Each work order can have a number of tasks the engineer needs to complete. Each of these tasks has a type. This option lets you define the possible types. For example, an engineer might always need to complete a risk assessment. If this is the case, you could create a new service task type of risk assessment. |
| Booking Rules | Specify the code (web resource) that can be added to validate a booking. |
Geocoding Data
Geocoding is the process of assigning longitude and latitude coordinates to any address based data, this is an essential step because this information will be used when calculating travel time and routes. We can only show accounts, resources and organizational units on the schedule board maps if we know where they are.
Below you can see that once Field Service is installed we have a Geo Code option available on entities like accounts.
This option can be used to see and adjust the GEO Code for an address. One tip is that the point on the map can be manually moved. It might be that the post code does identify the correct address but you might decide to slightly adjust the position of the pointer. Maybe to ensure it is places on the correct entrance to the property etc.
Once you are happy with the location you can click the “CHANGE” button to update the latitude and longitude values held against the account.
One additional tip I have on geo codes is that the location of your resources (users) and organizational units may be significant. Say you want the resource to start from your depot each day but end their day at their homes address, ensuring efficient routes may depend on these entities having known locations. AI have a couple of tips for this might help you …
- The address for the resource will code from the address defined in Office 365 admin on the users account.
- Organizational units have a latitude and longitude fields but these are not shown on the form by default. So you may need to add these.
- The organizational unit entity does not have a geocode option, meaning you will have to entre the latitude and longitude values manually.
I hope this post has given you some initial insight into the multiple configuration options you’ll need to understand for the MB2-718 exam.
Microsoft Dynamics 365 
Pingback: MB2-718 Certification: (Microsoft Dynamics 365 for Customer Service) – Revision Guide | Microsoft Dynamics 365 and Unified Service Desk