Field Service Is Gone: Working Inside Planning in Odoo 20

If you go looking for the Field Service app in Odoo 20, you will not find it — and this time the release notes say so in plain language: “The Field Service app has been discontinued. Its features are now integrated into the Planning app.” No features were deleted in the move. The live technician map, route planning, travel fees and worksheets all still exist; they now live inside Planning, expressed in Planning's vocabulary of shifts, resources and roles. For companies that run technicians, installers or inspectors out of Odoo, Odoo 20 therefore changes the front door of the working day even though the rooms behind it are largely the same size. This article maps where everything went, how a dispatcher's and a technician's day actually work in the new arrangement, and what to check before you upgrade.

Diagram showing former Field Service features — live map, route planning, travel fees, and worksheets — now inside Odoo 20 Planning

Why Odoo merged the two apps

Field Service and Planning had been drifting toward each other for years: both assign people to time slots, both care about availability, and field work was already being scheduled through Planning views. Maintaining two scheduling engines meant two concepts for the same act — putting a named person on a job at a time. Odoo 20 resolves that duplication by making Planning the single scheduling engine for the whole system, and field service becomes a way of using it: a shift linked to a customer, at the customer's location, with materials, a worksheet and a fee structure attached. The Planning section of the release notes is where the field service features now appear, each item prefixed “Field Service:” — the clearest possible sign of the new ownership.

Where each Field Service feature lives now

Live map. Planning gains a live map that tracks technicians' locations, plus a map view showing both shift locations and technician availability together.
Route planning. Routing in the map view now offers two modes: ordered, which respects the sequence of addresses as planned, and optimized, which calculates the shortest path between them. The Gantt view can also connect to the Mapbox integrator to display travel times, so a dispatcher sees drive time inside the schedule rather than guessing it.
Travel fees. Customers can be invoiced for distance-based travel fees or a fixed travel-time fee, as before — now configured against the shift's work.
Worksheets. Worksheets attach to shifts and to shift templates. One real change hides here: worksheet templates now use property fields instead of Studio fields, and property fields are also what the field service report now displays. Custom worksheet templates built on Studio fields need attention during the upgrade, not after it.
Auto-planning with locations. The Auto Plan feature takes customer locations into account when assigning shifts automatically, and priority shifts are scheduled first when it runs.
Customer equipment and history. Shifts carry the customer's equipment context: whether equipment is covered by a maintenance contract via Subscriptions, direct access to documentation for equipment installed at the customer's location, and tracked equipment and intervention history.
Customer communication. You can choose whether publishing a shift automatically emails the customer an intervention confirmation, collect service requests through a website form, and track customer ratings for on-site interventions afterwards.
On-shift materials. Products can be added to a shift by scanning barcodes, and employee-specific materials are handled as first-class planning data: assign materials to employees, and when an employee is assigned to a shift, their assigned material is automatically added to the shift's resources.

The dispatcher's day: shifts, resources, roles

The Planning documentation for 20.0 defines the working vocabulary. Shifts are dispatched to resources, which can be human (employees) or material (equipment — a crane, a van, a specialised tool). Resources carry roles — the qualification the work requires — and roles do real work in the system: Auto Plan only assigns open shifts to resources holding the corresponding role, honours each resource's default role first, and refuses collisions, time off, public holidays, working hours and contract boundaries when it plans.

The schedule itself is a Gantt view where shifts can be reassigned, rescheduled, resized, split and duplicated by dragging, and unpublished shifts stay visible only to planning administrators until they are published — publishing being the act that notifies the assigned employees by email and makes the schedule visible. In 20, shifts can also be sent to employees via WhatsApp, scheduled by dragging them from a side panel into the calendar or Gantt, linked to a specific project task, and staffed with multiple resources on the same shift for two-person jobs.

From sale to site visit: the sales order path

The most important workflow survived intact, and the 20.0 documentation describes it step by step. Field work is sold, then scheduled:

Configure the service product with Product Type set to Service, enable Plan Services, and select the role the work requires.
Confirm the sales order. A To Plan smart button appears on the order.
From To Plan, pick the day in the appropriate resource's schedule and select the shift from the open shifts for that role — only resources whose role matches the product's configured role are offered.
On the shift form, set the fields that turn a generic shift into an intervention: the Customer for an on-site job, and the Worksheet template if worksheets are configured.
Publish the shift — the technician is notified, and, if you enabled it, the customer receives the intervention confirmation email.
Afterwards, the order's Planned smart button shows the shifts created for it.

Work that does not start as a sale has a front door too: customers submit service requests through the website form, and dispatchers create shifts directly on any schedule. Either way, everything converges on the same shift record — which is precisely the consolidation Odoo was after.

The technician's day on site

For the person in the van, the day is a published schedule: shifts with a customer, a location visible on the map, and the equipment documentation for that site one tap away. On the job, products used are added to the shift by barcode scan; the assigned worksheet — now built from property fields — structures the report of what was done; materials that belong to the technician were attached to the shift automatically at assignment time, so the parts list does not depend on anyone remembering it at 7 a.m. When the work closes, the customer rates the intervention, and the visit joins the customer's equipment and intervention history, which is what the next technician reads before driving out.

Two wider Odoo 20 changes support this work. The new offline mode — create, edit, archive and delete records without a connection, syncing on reconnect — is pitched by Odoo at exactly these users: warehouse floors, construction sites and field technicians. And the redesigned mobile interface, with files shareable from the phone straight into Odoo records, shortens the path from a photo taken on site to documentation attached to the job.

What to check before and after upgrading

Worksheet templates. The Studio-fields-to-property-fields change is the one genuine migration task in this merge. Inventory your templates, confirm they render on shifts and on the field service report, and test one end to end in a staging database.
Roles and resources. Auto Plan is only as good as the role data. Every technician needs correct roles (and a default role), working hours and contract dates before you rely on automatic assignment — employees with no role cannot be auto-planned at all.
Menus, bookmarks and training. The app icon people clicked for years is gone. Update internal runbooks, pinned bookmarks and dispatcher habits to start in Planning, and brief crews that “your jobs” are now “your shifts.”
Payroll expectations. Separately in Odoo 20, work entries and the Planning-to-Payroll integration have been removed from the payroll flow. If your field operation fed payroll from planning data, verify your new path with whoever runs pay before the first cycle, not after.
Access rights. Odoo 20 also rebuilds access rights — record rules are replaced by a domain on each access right — so re-check that dispatchers see all shifts while technicians see only their own under the new model.
Customer-facing settings. Decide deliberately on the intervention confirmation email (it is a choice, per shift publication), the website request form, and how travel fees — distance-based or fixed travel-time — are presented on invoices.

The fair summary is that Odoo traded an app for an idea: there is no longer a separate field service silo, just planned work that happens to occur at a customer's site, with the map, the routing, the fees and the worksheets attached to the shift. Companies that embrace the shift-based model get one scheduling engine for office, warehouse and road. Companies that merely mourn the old icon will find everything they used still present — one menu over.