Field Service – Reference Data

As I configure my Field Service application for Microsoft Dynamics CRM I am creating blog posts which collectively will document how Field Service works. This time I am going to look at the many pieces of “reference” data you need to create or amend whilst implementing Field Service.

When you access the Field Service administration page you can see the number of options that need to be configured.(It’s quite a few!) I will cover several of these options in this post.


The above list is missing a few options such as bookable resources, pricelists and products. This is because these options are large and will be covered in separate posts individually.

Please note that many of the resource related options are now shared between Field Service and Project Service. I will be documenting them from a Field Service perspective. When I look at Project Service (in a later series of posts!) I will focus on any additional Project Service specific functionality.

I will not cover booking rules here as this is a complex advanced option that I consider beyond the scope of these simple notes. (And because I need time to look at some examples before commenting in detail!)


The skills option of FieldOne has been replaced by characteristics in Field Service. This provides a very similar concept but with some enhancements.

Field Description
Name The name of characteristic
Description A detailed description, should you need one!
Characteristic Type Can be set to Skill or Certification.
Require Approval Yes / No

Note: When characteristics are added to resources their approval status automatically defaults to Approved. So I couldn’t see any specific functionality associated with this field. Although I guess you could complete a simple customization to make use of it.

Each resource can have multiple characteristics. Then a work order can have a list of required characteristics. These can be just in conjunction with the scheduling assistant to ensure only field agents with the correct characteristics are allocated to specific jobs.


Each account can be assigned to a Field Service Territory, which in turn is transferred to the work order. And each engineer can also be allocated a particular Field Service Territory. The scheduling assistant and schedule board can then filter “jobs” / resources by territory. Meaning this feature will commonly be used to help focus scheduling on specific areas. Maybe one dispatcher looks after the south of the country and another deals with the north. Or maybe you simply don’t want to see engineers who live in Scotland whilst your booking a job in for Brighton!

Notice that the territory can optionally be assigned to a manager.

Also notice the postal codes option which would allow entry of the post codes that make up this territory. If you enter a full post when accounts are added their territory will be set automatically. (Meaning you enter “DY6 0HP” not “DY6”!)

You will find the same ability to assign postcodes to territories repeated in a second administration option of Field Service.

Bookable Resource Category

Each resource can have one or more resource categories. And on the resource category we can set a target utilization, billing type and skills.

It is worth remebering that Field Service and Project Services share the same reource model. So some fields will be specific to projects rather than Field Service.

From a field service point of view this field can simply be used to group resources. Maybe all of your Electricians have one category and all you plumbers have another. (You don’t want to send a plumber to fix a faulty light!)

Notice that you can also optionally add skills (or characteristics) to the resource category. I did a quick check and found that the resource assistant in Field Service does not seem to take these skills into account. The resource assistant only looks at the characteristics directly associated with the resource.


Work orders have a priority. You can edit and add addition priority options using this option.

Keep in mind that the priority is purely for reporting. The work order scheduling assistant does not take this priority into account.


Work Order Sub -Statuses

Out of the box the work order sub status fields look like this. Having these gives you the ability to effectively add detail to the main system status. For example, if an “Open – Unscheduled” order is marked as purchase order required the scheduler would know not to dispatch an agent.

It might be that you need to add additional sub-statuses. For example, say a customer needs to pay in advance before a field agent is dispatches. Then you might want a new sub-status of “Awaiting Payment” for the “Open – Unscheduled” status.

Adding additional sub-statuses can aid your business processes and may also be useful for reporting purposes.

When creating a sub-status, you can also set it as a default. Meaning this sub-status is assigned as soon as the work order reaches the status. Below, for example, whenever my work order reaches the “Open – Unscheduled” status the sub statues would become “Await Payment”.


Booking Statuses

Allows creation of multiple sub-statuses mapped to a booking status option. Essentially provides a feature similar to that of creating work order sub-statuses but for the resource booking. Although notice that the interface for mapping the sub status to the Field Service status differs slightly.



I will return to talking about warehouses when I cover the inventory options for Field Service. This option however simply lets you create a warehouse and give it a name.

A warehouse doesn’t have to be an actual physical warehouse. It can be a virtual warehouse, such as an engineer’s truck or even a goods in transit “location”.


RTV sub-statuses

Return to vendor status. Like booking and work order sub-statuses the RTV option lets you define additional detail status information associated with returns.

Notice that you can define the sub-status as a default meaning it will be set to that value when the required system status is entered.


Postal Codes

As I mentioned when describing creating a territory, each territory can optionally be associated with a list of postcodes. If you do this the field service territory on accounts will automatically default the territory. The only “problem” I have found is that the postal code needed to be the full code not just the sector. So “DY6 0HP” not “DY6”. This does mean maintaining the data could be a problem. The most likely approach to defining your postcodes / territories is to do like I did and import them from a spreadsheet. J


Ship Via

The ship via option is simply used to define your various shipping methods. This is used in places like on a purchase order.


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.

Will describe more detail on how to create these and use them whilst scheduling work orders in a future post. But they can be used to help make scheduling simple, say you only want to book three appointments per day and only offer the scheduler one option whilst doping so. Then a time group like the one below could be used.


Work Order Types

Work order types define the various type of work order available. Importantly they also define if an incident is required or not. Incidents are an important part of Field Service that I will cover in a separate post. But essentially they define a job in detail including all of the products, service tasks, skills etc. Using incident types is highly recommended as it speeds the creation of work orders.


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.


Incident Types

I have already mentioned that creating work orders using incident types. They are an important aspect of Field Service as they are used to make the process of creating work orders quicker and less prone to human error.

This is achieved by creating an incident type that pulls together all of the products, services, skills etc. that are needed on a work order into one definition.

I will explain Incident types in greater detail in a future post.


Resource Pay Types

The resource pay types option lets you define the different pay types. Typically, your “Normal” working pattern will give you 100% of the hourly rate for this employee. Other types such as over time would have a different percentage. Say you pay time and a half for overtime that would be 150% of the hourly rate.

You could in theory also have a mark-up that reduces the hourly rate. Below you can see the employee only gets 50% of their hourly rate whilst on a break.


Tax Codes

If an account is not tax exempt that a sales tax code is assigned to govern the rate of tax they pay. Below you can see that on an account I have said this account receives value added tax at the standard rate.

On the tax code we then define what is taxable and at what rate.

Note: if you select act as tax group multiple tax amounts can be grouped. To allow multiple taxes to be applied by selecting the group instead of individual tax codes.


Agreement Sub-Statuses

Used to specify the sub-status options available on agreements. Agreements start off as an estimate, become active and eventually expire. This option allows the definition of sub-statuses to add detail. Such as, why has the agreement expired and is it being renewed.


RMA Sub-Statuses

Return Merchandise Authorisation (RMA) allows the definition of return status options.

For example, say when some returns a fault product it needs to be checked and the fault confirmed before progressing to the next stage in the return. To achieve this you could create addition sub-statuses on the products received status.


Purchase Order Sub Statuses

The purchase order sub-statuses option works in a very similar manner to the other sub status options I have covered! It allows the definition of detail status options. Say a purchase order needs to be approved before it can be changed from a draft status to become submitted to the customer, you could use sub-statues to control this process.


Payment Terms

Allows you to define the descriptions used to reflect payment terms.


One thought on “Field Service – Reference Data

  1. Pingback: Field Service – User Guide | Microsoft Dynamics CRM and Unified Service Desk

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s