SAP PM and Dynamics 365 Field Service: which system owns what

If your plant runs SAP, the maintenance question is never “which system should we buy”. SAP Plant Maintenance is already there. Functional locations are already modelled, equipment already has a history, notifications and orders already drive the planning cycle, and the finance team already reconciles against it. Nobody sensible proposes replacing that.

The question is narrower and more awkward: why does so little of that reach the person holding the spanner? Planners work in SAP. Technicians work on paper, in WhatsApp, and on a whiteboard in the maintenance office. The gap between them is where schedule slips, where contractor hours go unchallenged, and where the plant finds out about a problem a week after it happened.

This article sets out how we divide responsibility between SAP PM and Dynamics 365 Field Service when both are in play, what the integration actually consists of, and the three things that catch people out.

Two wrong answers, first

Replace SAP PM. This fails on data, not on function. Plant maintenance history is a decade of failure codes, measurement points, task lists and cost settlement rules that finance depends on. Migrating it is a multi-year programme with no operational upside, and the day you finish you own a maintenance system that no longer agrees with your ERP.

Build the field experience inside SAP. Possible, and occasionally right. But it means your mobile experience, your offline behaviour, your scheduling board and your permit workflow are all constrained by the release cycle and the extension model of your ERP. For a plant that already owns Microsoft 365 and the Power Platform, that is a harder road than it needs to be.

The answer that works in practice is the boring one: leave the system of record where it is, and put the execution layer next to it. Microsoft frames this the same way, describing the Power Platform as “an agility layer to extend your SAP investments” rather than a replacement for them.

Who owns what

The division only works if it is decided once, written down, and enforced. Ambiguity about which system owns a field is what turns an integration into a reconciliation problem.

SAP PM keeps

• The asset register. Functional locations, equipment, the hierarchy, characteristics, measurement points. This is master data and it has exactly one home.
• The maintenance plan. Strategies, task lists, cycles, scheduling of preventive orders.
• Cost. Order settlement, cost centres, the plant’s actual maintenance spend. Finance does not want a second version of this and should not be given one.
• Materials. Reservations, goods issue, stock. Inventory is an ERP problem.
• The audit record. What was done, to what, when, and against which order.

Field Service takes

• Execution. The work order a technician actually opens, with tasks, safety steps, photographs, readings and a signature.
• Scheduling and dispatch. Who goes where, with what skills, in what order, with the schedule board and resource booking that field organisations expect.
• Mobile and offline. A plant has areas with no signal. Work carries on there, and syncs when the technician walks back into coverage.
• The permit. Permit to work attached to the job, visible before the technician starts, expiring on schedule. More on this below.
• Contractors. The people who are not in your SAP user population and should not be given a licence there.

The rule of thumb: SAP owns what the asset is and what it cost. Field Service owns what happened today.

What the integration is actually made of

Microsoft publishes two supported routes into SAP from the Power Platform, and most plants end up using both.

The SAP ERP connector calls RFCs and BAPIs. It runs over the SAP .NET Connector (NCo 3.1) through an on-premises data gateway, and Microsoft states it is validated against ECC and S/4HANA. This is the route for transactional work: confirming an operation, creating a notification, reading an order.

The SAP OData connector uses OData v4.01 and suits anything SAP already exposes as a service, which on S/4HANA is a great deal. Where an OData service exists, prefer it. It is easier to secure, easier to test and does not need the gateway.

A typical shape in a plant:

• Functional locations and equipment replicate one way, SAP to Dataverse, on a schedule. They change rarely and read constantly.
• A notification raised in the field creates the SAP notification, and the SAP number comes back and is stamped on the Dataverse record.
• An SAP order releases and becomes a Field Service work order, carrying its operations as tasks.
• Completion, time and confirmations flow back to SAP, where cost settles.
• Photographs, readings, permits and signatures stay in Dataverse, linked by the SAP key.

That last line matters. Do not push everything back into SAP because it feels tidier. Push back what SAP needs to settle cost and keep the audit record, and leave the rest where it is useful.

Three things that catch people out

1. Licensing is not just Microsoft licensing

This is the one that arrives late and badly. Microsoft documents it plainly: users of Power Platform apps integrated with SAP need both a Power Apps Premium licence and an SAP indirect-named user licence. Indirect access is cheaper than a direct-named user, and Digital Access licensing is an option, but it is not free and it is not optional.

Budget it at the start. A field organisation of eight hundred technicians and contractors has a real SAP licensing consequence, and discovering it during user acceptance testing is an unpleasant conversation.

2. The gateway has limits, and plants hit them

The on-premises data gateway enforces a 2 MB payload limit on write operations and an 8 MB compressed limit on reads. A photograph set from a confined-space inspection will exceed that without trying. Attachments belong in Dataverse, with a reference in SAP, not streamed through the connector.

The same section of Microsoft’s documentation notes that stateful SAP actions are not supported by gateway clusters in load-balancing mode. If you need stateful calls, the cluster must be failover-only. That is an infrastructure decision, so make it before the infrastructure exists.

3. Master data drift

The failure mode is not a broken interface. It is a functional location that was renamed in SAP six weeks ago and still carries the old description on four hundred open work orders, so nobody can find anything. Decide up front what happens when master data changes: whether in-flight work follows the change, what happens to a work order whose equipment was decommissioned, and who is allowed to create a functional location in the first place. The answer to the last one is almost always “nobody, in Dataverse”.

What this looks like in a refinery

The generic version of this article would stop here. The plant version has three specifics worth naming.

Functional location is not optional. In a process plant the location is the identity of the work. Field Service models this natively: functional locations form a hierarchy and place assets within it, so a work order can be pinned to a unit, a train or a specific vessel rather than to a site. Mirror the SAP hierarchy rather than inventing a parallel one, and enforce the rule that a work order carries a functional location, an equipment reference, or both. A job with neither cannot be planned, costed or found again.

Permit to work belongs with the job, not beside it. A permit that lives in a separate system is a permit somebody works around. Modelled in Dataverse as its own record, linked to the work order and the functional location, it can carry the permit type, the issuing authority, the expiry, a barcode for the board, and an expiry state the mobile app can refuse to work past. Field Service does not ship this out of the box, which is precisely why it is worth building once and properly.

Notification to order to execution has to be one chain. An operator raises a notification against a piece of equipment. Planning turns it into work. A crew executes it. If those three steps live in three systems, the plant’s own people cannot answer “what is happening about that leak” without asking three departments.

When you should not do this

If your maintenance organisation is small, mostly planned, mostly in-house, and already works comfortably in SAP GUI or Fiori, you may not need a second system at all. SAP’s own mobile options have improved. The case for a Field Service layer gets strong when some combination of the following is true: you have a large contractor population, you run turnarounds, you need genuine offline capability, you want scheduling that a dispatcher can actually operate, or you already own the Power Platform and are not using it.

We will tell you which of those applies to you, including when the answer is none of them.

Where we come in

We are a Microsoft partner. We implement Dynamics 365 Field Service and Project Operations, and we build on the Power Platform where the standard products stop. Our current work is a maintenance management programme for one of the largest refiners in the United States: the notification-to-work-order chain, functional location and equipment rules, electronic permits, turnaround scheduling and the SAP integration underneath all of it.

If you are working out where the line between SAP and the field should sit, talk to us. We will map the division of responsibility against your actual processes and tell you what it costs, including the SAP licensing you had not budgeted for.

Related reading: Field Service and Project Operations, natively connected, and our energy, oil and gas practice.

Sources

• Microsoft Learn: Power Platform and SAP documentation
• Microsoft Learn: Explore Power Platform and SAP integration (connectors, licensing)
• Microsoft Learn: SAP ERP connector reference (RFC/BAPI, gateway prerequisites, limits)
• Microsoft Learn: Create functional locations in Dynamics 365 Field Service
• Microsoft Learn: Overview of Dynamics 365 Field Service
• Microsoft Learn: On-premises data gateway