Why scheduling and mobile decide a Field Service project
Most Dynamics 365 Field Service projects are not won or lost on the work order form. They are decided by two things: whether dispatchers trust the schedule, and whether technicians trust the mobile app. If the schedule board shows the wrong people for a job, dispatchers fall back to spreadsheets and phone calls. If the app is slow, or shows yesterday's data in a basement with no signal, technicians fill in paper forms and the back office retypes them.
This article walks through the parts of Field Service that drive both of those outcomes: the work order lifecycle, incident types, requirements and the schedule board, Resource Scheduling Optimization, the mobile app with its offline profile, and inventory. It ends with the pitfalls I see most often when reviewing implementations. For the full product scope, start with the Field Service overview on Microsoft Learn.
The work order lifecycle: System status, substatus and booking status
A work order moves through a fixed set of system statuses: Unscheduled, Scheduled, In Progress, Completed, Posted and Canceled. These values drive platform logic. Creating a booking moves the work order to Scheduled, setting a booking to Traveling moves it to In Progress, and the work order only becomes Completed when all of its bookings are completed or canceled. Moving it to Posted is what triggers invoice and actuals creation, depending on your Field Service settings.
Bookings have their own status, and that is where technicians actually work. The out-of-the-box booking statuses are records you can extend, but each one maps to an underlying Field Service status, and that mapping is what the automation listens to:
- Traveling: When set from the mobile app, it stamps the booking start time and puts the work order In Progress.
- In progress: Records the actual arrival time and fills First Arrived On on the work order.
- On break: Keeps break time out of the working duration, so billing and time entries stay accurate.
- Completed: Sets the end time, creates booking journals and, depending on your settings, time entries.
Substatuses are where your own process belongs. Waiting for parts, awaiting customer approval or second visit needed are substatus records linked to a system status, not new system statuses. Keeping that separation lets you report on your own process without breaking the platform's. For follow-up visits, the Status completes work order setting on each booking status is the supported way to let a work order return to Unscheduled instead of completing.
Never edit the system status option values
Adding, removing or renumbering values in the Work Order System Status choice breaks the built-in processes that depend on them. If the labels do not suit your users, change the labels or add substatuses instead. Microsoft documents the full mapping in Work order lifecycle and system statuses.
Incident types: The template behind every work order
An incident type describes a kind of job, such as an annual boiler inspection or a compressor replacement. When you apply it to a work order, Field Service copies its details onto the work order. The more you define on the incident type, the less a dispatcher has to type and the more consistent your data becomes.
- Service tasks: An ordered checklist the technician follows on site. Task durations add up to the incident duration.
- Products: Parts and materials the job normally needs, added to the work order as estimated products.
- Services: Billable labor lines with a duration and unit, priced through the price list.
- Characteristics: Skills or certifications the technician needs, copied to the resource requirement so the schedule assistant can filter on them.
- Estimated duration: Only set manually when there are no service tasks with a duration. The work order duration is the sum of all its incidents.
My advice is to keep the catalog small and well maintained. Fifteen accurate incident types are worth far more than a hundred that nobody updates, because every duration you get wrong is copied into every requirement and every schedule. Review durations against actual booking data a few months after go-live and adjust them. If you plan to use requirement groups for multi-resource jobs, put the characteristics on the requirement group template rather than on the incident type. See Create work order templates with incident types.
Requirements and the Schedule Board
Scheduling in Field Service is built on Universal Resource Scheduling (URS), the scheduling engine shared with other Dynamics 365 apps. When you create a work order, a resource requirement is created with it. The requirement is what actually gets scheduled: it carries the duration, the time window, the territory, the service location and the required characteristics. Bookings are created against the requirement and point to a bookable resource.
Dispatchers work from the schedule board, and in practice from the schedule assistant, which searches for resources that match the requirement, filtering on skills, territory and location, and ranks them on travel time and availability. A few configuration choices make the difference between a board that helps and one that gets ignored:
- Territories: Assign resources to territories and set the territory on work orders, so the board and the assistant only show relevant people.
- Working hours: Maintain resource calendars, including part-time patterns and holidays. The assistant cannot respect availability it does not know about.
- Characteristics with ratings: Model skills as characteristics with a proficiency rating, and require a minimum rating where it matters.
- Board tabs per team: Create tabs with their own filters and views per dispatch team instead of one board for everyone.
For the underlying concepts, see Universal Resource Scheduling for Field Service.
Resource Scheduling Optimization: When is it worth it?
Resource Scheduling Optimization (RSO) is a paid add-in for Field Service, built on top of the URS tables and priced on the number of resources whose schedules are optimized. Where the schedule board and the schedule assistant help you book one job at a time, RSO schedules many jobs at once against goals you rank, such as minimizing travel time, maximizing utilization or handling high-priority work first. Typical patterns are an overnight run that plans the next day, intraday runs that absorb cancellations, and single-resource optimization when one technician's day falls apart.
RSO only produces good schedules from good data. Before you consider it, make sure these are in order:
- Geocoded service locations: every account and work order address needs a latitude and longitude, otherwise travel time cannot be calculated.
- Realistic durations on incident types, validated against actual booking durations.
- Complete working hours, territories and characteristics for every resource in scope.
- Clear rules about which bookings are locked and which ones RSO may move, agreed with dispatchers before the first run.
Start manual, then automate
If dispatchers are not yet using the schedule assistant consistently, RSO will not fix that. Start with manual scheduling, fix the data, and introduce optimization once the requirements are trustworthy. The details are in the Resource Scheduling Optimization overview.
A quick health check: Aging unscheduled work orders
One query I run on almost every project lists work orders that have been Unscheduled for more than a few days. It surfaces requirements the assistant cannot match, usually because of a missing characteristic, a wrong territory or a duration longer than any resource's available time. The value 690970000 is the documented option value for Unscheduled in msdyn_systemstatus.
<fetch>
<entity name="msdyn_workorder">
<attribute name="msdyn_name" />
<attribute name="msdyn_serviceaccount" />
<attribute name="msdyn_primaryincidenttype" />
<attribute name="msdyn_serviceterritory" />
<attribute name="createdon" />
<filter type="and">
<!-- 690970000 = Unscheduled -->
<condition attribute="msdyn_systemstatus" operator="eq" value="690970000" />
<condition attribute="createdon" operator="olderthan-x-days" value="3" />
<condition attribute="statecode" operator="eq" value="0" />
</filter>
<order attribute="createdon" />
</entity>
</fetch>The Field Service Mobile app
The Field Service mobile app is a model-driven Power Apps app that runs on iOS, Android and Windows, and it is included in the Field Service license. Because it is model-driven, you customize it with the same forms, views and business rules you use elsewhere. Technicians work from their agenda, update booking statuses, complete service tasks, record products and services, and create follow-up work orders.
Microsoft has also introduced a refreshed mobile experience built around the agenda and booking quick actions. At the time of writing, the documentation states that the refreshed experience does not yet support working offline, so if your technicians depend on offline mode, check the current documentation before you switch them over. Read the Field Service mobile app overview.
Designing the mobile offline profile
Offline is where most mobile complaints come from, and the cause is nearly always the offline profile rather than the app. The default Field Service Mobile - Offline Profile includes bookings, work orders and their incidents, products, services, service tasks, resolutions and Work Order Not-To-Exceed values, and it syncs every five minutes by default. Its booking filter downloads active bookings assigned to the current user that start or end today or within the next seven days, and the related work order data follows through relationships. Use it as your baseline and change it deliberately:
- Filter on bookings, not on everything: Let work orders and their child records follow the booking through relationships instead of giving each table its own broad filter.
- Limit columns: Only sync the columns that the mobile forms and views actually use. Wide tables slow down every sync.
- Include every lookup target: If a filter or form references a table that is not in the profile, technicians see blank fields or sync errors.
- Tune sync intervals: Bookings and work orders need frequent syncs; reference data such as products or incident types can sync far less often.
For more complex filters you can edit the FetchXML of a table filter directly in the profile editor (the FetchXML editor is in preview and does not support inner or outer joins, so related tables are linked with link-type="any"). The filter below expresses the same idea as the default booking filter: active bookings of the current user's bookable resource that start or end within the coming week.
<fetch>
<entity name="bookableresourcebooking">
<filter type="and">
<condition attribute="statecode" operator="eq" value="0" />
<filter type="or">
<condition attribute="starttime" operator="today" />
<condition attribute="starttime" operator="next-x-days" value="7" />
<condition attribute="endtime" operator="today" />
<condition attribute="endtime" operator="next-x-days" value="7" />
</filter>
</filter>
<link-entity name="bookableresource" from="bookableresourceid" to="resource" link-type="any">
<filter>
<condition attribute="userid" operator="eq-userid" />
</filter>
</link-entity>
</entity>
</fetch>Customized filters stop receiving updates
Microsoft updates the default profile with Field Service releases. Filters you have edited are no longer updated, and updates to filters you have not edited arrive unpublished, for you to review. Keep the profile in a solution, document every change, and remember that publishing profile changes in an environment creates an active layer.
Treat the offline profile as an ALM artifact. Add it to your solution, deploy it through your pipeline like any other component, and only create separate profiles when roles really differ, for example a supervisor who needs a wider view than a technician. Test sync on a real device, with a realistic data volume, before go-live. See Set up the mobile offline profile.
Inventory, warehouses and customer assets
Field Service has its own inventory layer: warehouses, product inventory per warehouse, inventory adjustments and transfers, purchase orders and returns. A service van can be modeled as a warehouse, so technicians consume parts from their own stock.
- Warehouses: Physical sites and vans that hold stock. Link a technician's van warehouse to their bookable resource so it defaults on work order products.
- Product inventory: Quantities on hand per product and warehouse, updated by work order consumption, adjustments, transfers and receipts.
- Work order product line status: Lines start as Estimated and only reduce inventory once they are set to Used with a warehouse.
- Customer assets: Products flagged to convert to a customer asset become assets at the service account when the work order is completed, so your installed base builds up as you work.
- Returns: Return merchandise authorizations (RMAs) cover three return types (to the warehouse, to the vendor and change of equipment ownership) and close the loop for faulty or unused parts; receiving the RMA finalizes the return.
Be clear about where inventory is mastered. If an ERP such as Dynamics 365 Finance and Operations already owns stock, decide early whether Field Service is the system of record for van stock or simply a consumer of ERP data. Running two inventory masters without an integration design is one of the most expensive mistakes you can make. Start with Microsoft's overview of inventory, purchasing and returns.
Common pitfalls
| Pitfall | What happens | What to do instead |
|---|---|---|
| Custom system status values | Booking and work order automation behaves unpredictably | Use substatuses, and relabel if needed |
| Unrealistic incident type durations | Overbooked or half-empty days; dispatchers stop trusting the board | Compare estimates with actual booking durations and adjust |
| Missing geocodes on addresses | No travel time, poor assistant results, RSO cannot optimize | Geocode on create and monitor records without coordinates |
| Overloaded offline profile | Slow first sync, large device databases, sync errors | Filter on bookings, limit columns, include lookup targets |
| Heavy synchronous plugins on bookings | Status updates from the app become slow or fail on poor connections | Keep booking logic light and move heavy work to asynchronous processing |
| Two inventory masters | Stock levels that nobody believes | Decide the system of record and design the integration first |
Conclusion
Field Service rewards discipline. Respect the system statuses and put your own process in substatuses, invest in accurate incident types, maintain territories, working hours and characteristics, and treat the offline profile as a carefully designed, versioned component. Get those foundations right and the schedule board, the mobile app and, later, optimization start to work for you instead of against you.
Above all, involve dispatchers and technicians early. Spend a day in the van, watch a dispatcher plan a Monday morning, and test the app where the work actually happens. That is where you find out whether your configuration works.