Dynamics365 Field Service Work Order Theory
Come from :https://neilparkhurst.com/2016/08/20/field-service-work-order-theory/
In this post I aim to continue my series covering all aspects of Field Service for Microsoft Dynamics CRM, work orders are the primary entity within Field Service. Think of them as the “essence” of all information needed complete a service request.
Note: If you have previously used FieldOne Sky then you will find most of the theory connected with work orders to be very similar. Except some related entities now have different names!
In this post I specifically cover these questions on work orders;
- What are they?
- What is the work order life cycle?
- How do work orders relate to other Field Service entities?
It is important to appreciate the information in this post before continuing to configure Field Service as you’ll need to understand these base concepts to be able to appreciate the implications of any configuration work.
Work Orders – What are they?
A work order is used to coordinate and schedule resources and activities. The work orders can be for differing types of work including installations, repairs or preventative maintenance. (The types can be configured to reflect whatever services a particular organization performs.)
A work order can contain;
- A description of issue or work to be completed
- Customer details include service and billing accounts
- Equipment affected
- Location
- Parts, products and services needed
- Tasks to follow
- Priority and estimated duration
- Characteristics (skills) required to complete the work order
What is the work order life cycle?
A work order will have a lifecycle in that they are created, scheduled, Dispatched, Serviced, Review / Approval, invoiced (& inventory adjusted)
One very important difference between Field Service and FieldOne is the additional of a business process flow that is used to progress the work order life cycle. Making the process much simpler from a user point of view.

Creation
Work orders can be created in four ways.
- From an agreement, this might be an on-going contract involving regular service visits for preventative maintenance.
- From a case, a case might be created in the contact center. If the case can’t be resolved locally and a field engineer is required, then work order(s) can be created directly from the case.
- From a sales opportunity.
- Manually directly within the Field Service options in CRM or from the Field Service Mobile application.
When a work order is created it can contain many fields, including the service and billing account details, incident type plus details of the services and products required.
When a work order is created its status is initially “Open Unscheduled”.
Scheduled
After a work order has been created it can then be scheduled to a resource. A work order can be scheduled in four ways;
- Manually by a dispatcher from the schedule board.
- Manually by a field agent from the Field Service mobile application.
- By a dispatcher using the scheduling assistant.
- By using the Field Service routing engine to automatically schedule.
Once a booking (work order schedule) is created the status on the work order changes to “Open Scheduled”.
One work order can have many resource bookings (schedules), as a separate schedule will be created for each resource needed on a work order.
Note: If you have previously used FieldOne you need to be aware that work order schedules are now called resource bookings.
Dispatched
After a work order schedule has been created a specific resource will be dispatched.
Once assigned to a resource (field agent), the field agent will be notified and they can accept or reject the work order schedule.
When dispatched the work orders retains the status of “Open Scheduled” but the work order schedule is changed to be scheduled, accepted or declined.
Note: You can also create customer work order schedule status values beyond the defaults of schedules, accepted or declined.
Serviced
This stage reflects the processes that would happen whilst the work order is in progress. Such as on route, in progress etc.
The work order status changes from “Open Scheduled” to “Open Complete” once the service has been completed.
Changing the status to “Open Complete” is the default out of the box behavior. It is however possible to alter the Field Service setting to assign a different status if required. You could, for example, jump straight to Closed – Posted.

Review / Approval
After the service has been completed a manager or the dispatcher will review the work order and confirm the required services have been correctly completed and all the information correctly entered.
Once reviewed the work order status changes to “Closed – Posted”. From this point onwards the work order cannot be changed.
invoiced (& inventory adjusted)
Finally, Field Service will automatically create any invoices required and adjust inventory.
Optionally parts used can be logged against as customer a “customer equipment”. Useful scheduling future maintenance work.

How do work orders relate to other Field Service entities?
Below is a summary of the key relationships between a work order and the other Field Service entities.


- Each work order will have one service account.
- The service account is Geo Coded and is used to decided where the work order should be performed.
- Optionally a work order can have a billing account. (The billing account is the service account if not defined.)
- Each work order will have one or many resource booking records.
- The resource bookings contain details of when & who should complete the work order.
- Each resource booking will have a resource. This could be a person, crew or piece of equipment

Each work order can be assigned an incident type. The incident entity is used to “bundle together all the products, services, service tasks and resource characterictics (skills) needed to complete that incident. Using incidents to bundle these items like this makes the process of creating work orders much easier. Meaning the use of incidents isn’t mandatory with Field Service but they are highly recommended.

The last group if entities, work order type, priority and territory are used mainly for information purposes,


Hopefully this post has given you some useful information about work order theory. As I produce more posts about Field Service I will build on this theory.
Dynamics365 Field Service Work Order Theory的更多相关文章
- Dynamics 365 CRM 在 Connected Field Service 中部署 IoT Central (三)- 发送 work order 和 booking 信息给 IoT Central
首先, 我们可以打开IoT alert, 并且点击上的 create a flow. 接下来,我们使用微软准备好的模板:Sample Contoso- When a work order is cre ...
- S/4HANA Service Management和SAP Field Service Management的集成
经常有朋友提出这样的问题:"SAP Business Suite里的CRM的Service模块已经通过Addon的方式迁移到了S/4HANA上,并且SAP之前又收购了一家专门做Service ...
- Dynamics 365 CRM 配置field service mobile
配置field service mobile其实微软是有官方文档的, 但是没有坑的微软产品不是好产品. 一些细节设置文中还是没有考虑到的. 所以这里带大家配置一下field service mobil ...
- Dynamics 365 CRM 在 Connected Field Service 中部署 IoT Central (一)- 配置 IoT Central和IoT alert
今天这个系列给大家带来怎样在connected field service中部署IoT Central 并且做连接. 首先, 这里提供微软官方的tutorial的链接https://docs.micr ...
- MB2-718 Certification: (Microsoft Dynamics 365 Customer Service) – Field Service, Customer Assets
Come from : https://neilparkhurst.com/2018/02/25/mb2-718-certification-microsoft-dynamics-365-custom ...
- Dynamics 365 CRM Connected Field Service 自动发送command
上期降到了怎样部署connected field service(CFS) 我们假设现在IoT 设备是温度监控器, 当温度触发我们之前预设的温度值, IoT会通过IoT Hub 发送IoT Alert ...
- Dynamics 365 CRM 部署 Connected Field Service
微软 Connected Field Service 是一个提供Azure IoT 和 Dynamics 365 连接的这样一个框架 有两种方式部署CFS, 一种是用IoT Hub PaaS, 一种是 ...
- How to solve the error "Field service in com.xx.xxx.xxxx required a bean of type 'com.aa.bb.cc' that could not be found."
When runung a SpringBoot demo, I got a error as following: *************************** APPLICATION ...
- Dynamics 365 CRM 在 Connected Field Service 中部署 IoT Central (二)- 匹配设备
上个blog中介绍了我们怎么去部署IoT central和 connected field service做连接. 我们这次介绍怎么把IoT设备在CRM中怎么去注册. 首先我们打开devices,再选 ...
随机推荐
- hbase2.1.9 centos7 完全分布式 搭建随记
hbase2.1.9 centos7 完全分布式 搭建随记 这里是当初在三个ECS节点上搭建hadoop+zookeeper+hbase+solr的主要步骤,文章内容未经过润色,请参考的同学搭配其他博 ...
- 「疫期集训day7」周期
我们成功入侵了圣康坦,屋子里到处都是面包,食物,水...现在我们的目标就在眼前----亚眠------鲁道登夫攻势中损失惨重的德国精英兵 今天考试考出了历史最低,原因在于T1签到题挂了,ull真的毒瘤 ...
- Uni-app登录态管理(vuex)
应用中,保持登录状态是常见需求,本文讲解使用uni-app框架时如何保持用户登录状态. 即:初次进入应用为未登录状态------->登录---------->关闭应用,再次打开------ ...
- python入门009
目录 四.列表 1.定义:在[]内,用逗号分隔开多个任意数据类型的值 2.类型转换:但凡能被for循环遍历的数据类型都可以传给list()转换成列表类型,list()会跟for循环一样遍历出数据类型中 ...
- Java入门系列之final
前言 在C#经典面试中掺杂过Java的final关键字,主要用于类不能被继承,在C#则是利用关键字seal修饰类为密封类,而在Java中的final关键字的具体用法包含C#中const.readonl ...
- USTC信息安全期末重点
一.ARP协议问题1. ARP协议的作用是什么.地址解析协议,即IP地址和MAC地址之间的转换. 2. 引入ARP缓存的功能是什么.将这一映射关系保存在 ARP 缓存中,使得不必重复运行 ARP 协议 ...
- 一篇文章掌握 Python 内置 zip() 的全部内容
一篇文章掌握 Python 内置 zip() 的全部内容 zip() 是 Python 中最好用的内置类型之一,它可以接收多个可迭代对象参数,再返回一个迭代器,可以把不同可迭代对象的元素组合起来. 我 ...
- python之将一个字符串str的内容倒叙过来,并输出。
inStr = input() flashback = inStr[::-1] print(flashback)
- nginx配置文件服务器——带说明
需求: 搭建一个文件服务器,提供指定软件下载,在访问文件服务器下载软件时,在访问的主页上要有对应的软件使用.安装等说明(本来是可以搞一个readme的,但这个在文件服务器上要下载还要打开,还不如直接显 ...
- Spring Boot中Tomcat是怎么启动的
Spring Boot一个非常突出的优点就是不需要我们额外再部署Servlet容器,它内置了多种容器的支持.我们可以通过配置来指定我们需要的容器. 本文以我们平时最常使用的容器Tomcat为列来介绍以 ...