That integration is now approaching retirement.
Field Service pricing and costing controls for the Project Operations integration. Source: Microsoft Learn.
Microsoft has confirmed that the existing Field Service integration with finance and operations applications will no longer be available after February 28, 2027.
This does not mean Field Service will stop integrating with Finance and Supply Chain Management. It means the architecture is changing.
Customers need to move towards the newer Field Service and Project Operations integration, where Project Operations provides the financial connection between field execution and finance and operations.
With roughly six months remaining, this should now be treated as an active migration project—not a future roadmap item.
What is happening to the existing integration?
Beginning with Field Service version 8.8.139.398, the Install Finance and Operations option is no longer available in environments where the integration was not already installed and configured.
Existing customers can continue using an enabled integration until its retirement date.
The current integration connects Field Service work order transactions with finance and operations through dual-write and asynchronous processing.
Depending on the transaction type, work order activity can create:
- Item journals for inventory products
- Expense journals for non-inventory products
- Hour journals for services
- Inventory and financial updates in finance and operations
This model is being replaced by an architecture centred on Project Operations.
What replaces it?
Under the new model, Field Service remains responsible for work order execution, scheduling and technician activity.
Project Operations becomes the financial interpretation layer.
| Area | Existing integration | Replacement architecture |
|---|---|---|
| Field execution | Field Service work orders | Field Service work orders |
| Financial container | Finance projects and journals | Project Operations projects and contract lines |
| Material consumption | Work order products create journals | Material Usage Logs become project journals and actuals |
| Labour | Work order services create hour journals | Approved time entries generate project actuals |
| Billing | Processed through finance and operations | Project Operations prepares financial actuals and invoices before downstream posting |
| Finance connection | Direct Field Service integration using dual-write | Project Operations integration journals transfer approved financial data to Finance |
| Inventory ownership | Supply Chain Management when integration is enabled | Depends on the Project Operations deployment model |
A work order is linked to a Project Operations project or project task.
Estimated products and services create project estimate lines. When a technician marks an item as Used, Field Service creates a Material Usage Log. Project Operations converts that usage into project journals and, after approval, financial actuals.
Those actuals can then support project billing, margin reporting and downstream posting into Dynamics 365 Finance.
Microsoft’s intention is that technicians continue working in Field Service. Most of the change takes place behind the operational experience—but it is a significant change for solution architecture, financial processing and administration.
Why Field Service inventory is being suppressed
Customers using Field Service and finance and operations frequently encounter two possible inventory models:
- Native Field Service inventory
- Supply Chain Management inventory
Allowing both systems to appear authoritative creates confusion over stock levels, transfers, adjustments, returns and purchase transactions.
With the existing finance integration enabled, Supply Chain Management becomes the inventory system of record. Field Service inventory navigation and functionality—including inventory adjustments, transfers, RMAs and returns to vendor—is suppressed.
Recent Field Service releases have strengthened this behaviour by hiding Field Service inventory capabilities in environments using the finance and operations dual-write integration.
This does not mean inventory is disappearing.
It means inventory ownership is moving clearly to one system.
Under the new Field Service–Project Operations architecture:
- Project Operations Core without Finance: Field Service remains the inventory system of record.
- Integrated Project Operations with Finance: Finance and Supply Chain Management become the systems of record for inventory and accounting, and Field Service inventory is disabled.
The deployment model therefore needs to be an explicit architecture decision—not simply an installation choice.
This is not just a technical upgrade
The replacement package requires the legacy Field Service–finance and operations integration to be uninstalled.
That makes this a migration rather than something customers should assume will be an automatic in-place upgrade.
The financial processing model also changes.
In the existing integration, Field Service transactions generate finance and operations project journals. In the replacement model, transactions first move through Project Operations estimates, Material Usage Logs, approvals, actuals and invoicing processes.
Any customisations, integrations or reports built around the existing journals and transaction-status records must be assessed.
What customers should review now
1. Identify whether the legacy integration is enabled
Confirm which environments and legal entities currently use the integration.
Do not rely only on the presence of dual-write. Document the actual Field Service transactions flowing into finance and operations, including products, services, journals, pricing, costs and inventory.
2. Review custom dependencies
Look for plugins, Power Automate flows, integrations and reports that depend on:
- Finance and operations transaction records
- Item, expense or hour journals
- Work order product posting
- Project and subproject creation
- Transaction status or retry processing
- Field Service inventory tables
- Custom billing or reconciliation logic
These dependencies might need to be redesigned around Project Operations estimates, Material Usage Logs and actuals.
3. Choose the future deployment model
Decide whether the organisation requires:
- Field Service with Project Operations Core
- Field Service, Project Operations, Finance and Supply Chain Management
- Field Service with Project Operations and another ERP system
This decision determines where inventory, pricing, costing, invoicing and accounting will be controlled.
4. Validate licensing and prerequisites
Microsoft’s current setup guidance requires:
- Field Service version 8.8.142.0 or later
- Project Operations version 4.162.0.0 or later
- A Project Operations licence for the user installing the integration
- Appropriate licensing for the recurring Power Automate flow installed with the package
Even customers that do not intend to use the full Project Operations application should review the licensing requirement.
5. Test company and legal-entity alignment
The service account’s company determines the company used by the work order and its transactions.
Products, services, warehouses and related records must belong to the correct company. Transactions do not synchronise when company values are misaligned.
Multi-company organisations should give this area particular attention during testing.
6. Revisit pricing, costing and approvals
The replacement integration can use either Field Service or Project Operations to calculate prices and costs.
Customers must also decide whether Material Usage Logs should be automatically approved or reviewed before they generate financial actuals.
These are business-process decisions, not simply configuration settings.
7. Test mobile and offline scenarios
The integration installs mobile offline profiles that can override the standard Field Service profiles.
Any existing mobile customisations, offline tables, filters and technician processes should be regression tested before production rollout.
Final thoughts
The retirement of the existing Field Service–finance and operations integration is more than a connector change.
Field Service remains the operational application, but Project Operations becomes the bridge between work performed in the field and its financial outcome.
The biggest questions for customers are:
- Which system owns inventory?
- Where are pricing and costs calculated?
- How will work order usage become financial actuals?
- Which existing customisations depend on the legacy transaction model?
Organisations that answer these questions now will have time to test the new architecture properly.
Official documentation:
