Field Service vs Project Operations

Field Service and Project Operations look similar from a distance — both schedule people to do work for customers, both track time, both invoice for what was done. Every services-heavy Dynamics 365 conversation eventually asks which one is right, and the honest answer is that they solve different problems. This guide walks the difference in a shape that helps the decision.

The two mental models

Field Service is built around the work order — a discrete, dispatched unit of work with a schedule, a technician, an asset, a location, and a completion. The unit of value is a visit or a series of visits. Even a maintenance agreement that runs for years is executed as many individual work orders.

Project Operations is built around the project — a bounded engagement with phases, deliverables, a team, and a budget-to-completion. The unit of value is a project outcome. Time and expenses are tracked against project tasks; billing runs on contract terms; margin is measured project by project.

If the mental model your business uses is "we dispatch people to jobs and they close each job," Field Service is the right architectural fit. If the mental model is "we deliver projects with defined outcomes over weeks or months," Project Operations is the right fit.

Where each wins

Field Service wins when:

• Work is dispatched to a technician who arrives, does the work, and closes it — often within a day, sometimes across a small number of visits.
• The asset being worked on matters — service history, warranty, model, serial, location.
• Scheduling optimisation across many technicians and many bookings is a first-class business problem (RSO, skill-based routing, travel-time-aware planning).
• Truck-stock inventory of parts is meaningful.
• Preventive maintenance and IoT-driven work-order generation are part of the story.
• Typical customers: equipment manufacturers with maintenance contracts, facilities management, utilities, telecoms, medical-device servicing, home-service businesses.

Project Operations wins when:

• Work is a bounded project with deliverables, a scope, and a defined completion.
• The team is a mix of roles working together over weeks or months, not individual technicians dispatching independently.
• Billing terms are contract-driven (fixed-price milestones, capped T&M, retainers) rather than per-visit.
• Resource utilisation across a bench (billable hours per consultant) is the primary operational KPI.
• Project margin (revenue minus consultant cost minus expenses) is the primary financial KPI.
• Typical customers: consulting firms, agencies, IT services firms, engineering practices, architecture firms.

Where the boundary blurs

Two customer types genuinely sit near the line and either product can work.

Complex maintenance projects. A three-week shutdown at an industrial plant to refurbish major equipment — dispatched crew, coordinated across trades, hundreds of individual tasks, a project-level budget. Field Service can model this through complex work orders; Project Operations can model it through a project with team assignments. If the same crew is dispatched to daily maintenance the rest of the year, Field Service is probably the right platform overall. If the equipment refurbishment is a rare project-shaped engagement in an otherwise project-driven business, Project Operations is right.

Installation-heavy services businesses. A firm that sells and installs equipment (industrial machinery, IT infrastructure, HVAC systems) has both project-shaped work (design, deliver, install) and field-shaped work (ongoing maintenance, break-fix). This is the classic run both scenario.

Running both

For customers who genuinely need both, they can coexist cleanly. Both apps run on Dataverse, share Account and Contact tables, share Sales as the front-end sales motion, and integrate to the same back-office ERP (BC or F&O).

The pattern that works:

• Project Operations for the installation project. The customer's opportunity is a mix of hardware (billed as material) and services (design, integration, commissioning). The project runs through to handover.
• Field Service for the post-handover maintenance contract. On handover, a customer asset is registered, a maintenance agreement is created, and preventive maintenance work orders start flowing on the contracted cadence.
• Both feed the same customer timeline in Dataverse. The customer sees one account manager, one billing relationship, one support entry point.

Licensing works — Field Service Enterprise and Project Operations are separate licences per user, but attach licensing keeps the cost of a user who lives in both apps reasonable. The users who cross between the two apps (delivery leads, account managers) are usually a small subset of the total headcount; most Field Service users don't touch Project Operations and vice versa.

Where each would be a mismatch

Trying to run projects in Field Service. Field Service can model a multi-day, multi-task engagement through work order groups. Below a certain complexity it works. Above it, you hit the ceiling — no project-level budget, no bench utilisation reporting, no milestone billing, no revenue recognition. Once the "project" concept becomes central, Field Service is fighting the shape of the work.

Trying to run dispatched service in Project Operations. Project Operations does not have a schedule board, RSO, mobile technician app, or an asset model. Building a services business that dispatches technicians to hundreds of small jobs on Project Operations means recreating the missing pieces — not a fight worth picking.

Trying to use one for both across the whole business. This is the most common mistake. A CIO decides "we'll standardise on one product to save licence cost" and forces the wrong shape onto half the workflow. The productivity hit on the mis-matched half outweighs the licence savings by a large margin.

The short version

Field Service is dispatch, work orders, assets, technicians. Project Operations is projects, teams, milestones, utilisation. If the business does one shape, pick the matching product. If the business genuinely does both — installation projects followed by ongoing maintenance is the archetype — run both, because they coexist cleanly and forcing one to do the other's job costs more than the licence saved.