Power Automate + Power Apps Close the ERP Gap

Your SAP ByDesign implementation cost £400,000 and 14 months. Your shift supervisors manage the line on WhatsApp and a spreadsheet they built in 2019. Both things are true simultaneously — and the spreadsheet is winning.

This is not an unusual situation. It is the default state at most mid-market manufacturers, FMCG operations, and 3PL warehouses after an ERP go-live. The ERP is configured for finance and procurement. Operations works around it.

ERP systems are designed for transaction integrity. SAP ByDesign, SAP S/4HANA, Microsoft Dynamics 365 — all of them are built around the principle that every action produces a structured, auditable record that flows through to the financial ledger. This is the right design for the functions those systems were built to serve.

It is the wrong design for a shift supervisor standing at a packaging line who needs to log a downtime event, check the next four hours of production schedule, raise a material deviation, and approve a contractor's permit-to-work before the line restarts — in under three minutes.

The ERP transaction for each of these actions requires navigation through multiple screens, knowledge of item codes and cost centre numbers, and often a desktop or laptop that is not physically near the line. So the shift supervisor uses WhatsApp to notify the maintenance team, writes the downtime reason on a clipboard, and catches up on the ERP entries at the end of the shift — by which point the information is stale and the decision context is gone.

The instinctive response from IT is to customise the ERP. Add a mobile interface. Build a transaction-entry shortcut. This approach has a consistent failure mode: ERP customisations are expensive to build, expensive to maintain, and they break at every system upgrade. The mid-market industrial that has been customising SAP ByD for six years is now running a modified system that the standard SAP support path cannot service cleanly.

Most BI projects fail not because of the tool — because the data underneath it isn't live. The same principle applies to ERP adoption: most ERP adoption failures are not data quality failures — they are interface failures.

The architecture that works for mid-market industrials is a clean separation between what ERP is for and what Power Platform is for.

ERP remains the system of record for inventory, production orders, procurement, and financial transactions. That is what it was designed to do, and it does it well when you stop asking it to do things it was not designed to do.

Power Apps sits at the frontline — on a tablet mounted at the line, on a supervisor's mobile device, on a screen in the warehouse picking zone. It presents only the information and actions relevant to the person in front of it, in the format that matches how they actually work. A Power Apps canvas application for shift handover, downtime logging, and material deviation reporting can be built and iterated in days, not months. It does not require a change request to the ERP core.

Dataverse is the operational data store that sits between Power Apps and the ERP. It holds the operational records — shift logs, downtime events, quality holds, permit-to-work records — that Power Apps generates. Azure Data Factory pipelines move the relevant data between Dataverse and the ERP in the appropriate direction: production orders from SAP ByD into Dataverse for display in Power Apps; confirmed downtime events from Dataverse back into SAP ByD for maintenance cost tracking.

Power Automate handles the approval flows — maintenance work orders, material deviation sign-offs, overtime authorisations — routing to the right approver, escalating after defined timeouts, and writing the outcome back to both Dataverse and the ERP.

Copilot Studio handles the routine queries that would otherwise consume supervisor time: SOPs for non-standard procedures, shift schedule queries, equipment-specific troubleshooting guides. The agent is trained on your own documented procedures, not on generic knowledge.

The Power Platform architecture described above is most valuable when it is connected to the operational technology layer — MES, SCADA, and WMS systems — that holds the real-time production and logistics data that ERP sees only at transaction completion.

Power Automate has native connectors for OPC-UA and MQTT protocols, which are the standard interfaces for SCADA and MES data streams in manufacturing environments. This means a Power Automate flow can listen for a SCADA event — a temperature exceedance, a counter reaching a batch completion threshold, an equipment fault code — and trigger a downstream action: a Power Apps notification to the shift supervisor, a maintenance work order in SAP ByD, an alert to the quality team.

For 3PL and warehouse operations, Power Automate connectors to WMS platforms can surface picking accuracy data — mis-pick rates by picker, by zone, by shift — into a Power BI report that the warehouse manager reviews in real time, rather than discovering picking errors at the point of customer complaint.

This is not the same as a full MES implementation. It is not a SCADA replacement. It is a data-flow layer that connects the operational technology environment to the Power Platform and ERP ecosystem — capturing events that currently disappear into nothing, or get written on a clipboard and never entered.

A mid-market FMCG manufacturer running SAP ByDesign for production and finance had a 14% mis-pick rate in their finished-goods warehouse, attributed to manual pick-list generation and paper-based confirmation. A Power Apps application presenting digital pick lists — connected to Dataverse, with Power Automate flows writing confirmed picks back to SAP ByD — reduced the mis-pick rate to the 3–6% range within two months of go-live. The warehouse manager's Power BI dashboard, pulling data from Dataverse via a Direct Lake connection in Microsoft Fabric, gave real-time visibility of picking accuracy by shift and zone for the first time.

The SAP ByDesign system was unchanged. The improvement came entirely from the layer between the ERP and the people using it.

This is not how you replace your ERP. If your ERP is genuinely unfit for purpose — if the underlying data model is wrong, if the chart of accounts is a mess, if the master data was never cleaned after the original implementation — building a Power Platform layer on top of it will surface those problems more visibly, not resolve them.

It is also not appropriate for organisations where the primary constraint is process discipline rather than tooling. If your shift supervisors are not following the current paper-based processes consistently, a Power Apps application will not automatically improve that. Process adherence is a management problem. The digital tool supports a process that is already functioning, or it helps enforce a new process through structured data capture — but it cannot substitute for management accountability.

And for very small sites — fewer than 50 operational staff, one or two production lines — the implementation overhead may outweigh the benefit. The right threshold is roughly where the coordination cost of the manual process starts to exceed the cost of building and maintaining the digital layer.

In a Discover workshop, we identify the two or three highest-friction points between your ERP and how operations actually runs — typically shift handover, downtime logging, or approval workflows. Within six weeks, a working Power Apps application connected to Dataverse and your ERP via Azure Data Factory is live with a defined user group on the floor. Power BI reporting from the Dataverse operational data follows in the Deploy phase.