ERP Integration or Custom Workflow Layer? A Practical Decision Guide

An ERP can be the right system of record and still leave people with a frustrating operational gap. The issue may be an approval that happens in email, a dispatch decision spread across screens, or an exception that someone discovers only after a customer calls.

That does not automatically justify replacing the ERP or building a parallel platform. A more useful question is: what decision or hand-off is difficult today, and where should the information and responsibility for it live?

Start with one moment of work

Choose one repeated moment: approving a purchase, releasing an order, confirming a delivery, correcting a master-data issue or preparing an invoice. For that moment, record:

• the person who needs to act;
• the information they need before acting;
• the systems that currently hold it;
• the consequence of a late, missing or duplicated update; and
• the person who resolves an exception.

This separates a specific operational problem from a broad request to “make the ERP easier.” It also makes it easier to decide whether the missing piece belongs inside the ERP, between systems, or in a small supporting workflow.

Three approaches, with different responsibilities

Configure or extend the ERP when it already owns the work

Use supported configuration, reporting, workflow or vendor-approved extension points when the product can model the required event and the team can operate the result. This is usually the smallest technical surface to maintain.

It can be a poor fit when the desired process depends on a user experience, device context or cross-system decision that the ERP was not designed to provide. Forcing every need into the platform can create a brittle workaround that is difficult for the next owner to understand.

Integrate when a clear business event needs to move

An integration is appropriate when two systems have complementary responsibilities. An ERP might remain authoritative for inventory or finance while another system owns field progress, customer communication or delivery proof.

For each important field, decide which system is authoritative. Name how records are matched, when the event moves, what happens when it fails and who corrects it. “Two-way sync” is not a design decision on its own; it can leave both systems able to change the same fact without a rule for conflict.

The reliable integrations guide covers failure visibility, retries and day-to-day ownership in more detail.

Build a narrow workflow layer when people need context across systems

A focused layer can be useful when neither existing product provides the decision support people need. It might be an exception queue, an approval surface, a customer portal or an operations view that brings together only the relevant context.

The boundary matters. Keep core ledger, stock, fulfilment or other ERP behaviour in the system that already owns it unless there is a clear, deliberate reason not to. A good supporting layer helps people act; it should not quietly become a second ERP.

Design the exception path before the happy path is finished

Normal transfers are only part of the work. Record the states a person needs to recognise: missing reference, rejected record, duplicate event, changed master data, unavailable API or delayed approval. For each one, provide enough context to make a correction and a clear route to retry or reconcile the event.

Illustrative example: a logistics team might keep order and stock records in its ERP, receive delivery milestones from a transport system, and use a small operations view to identify deliveries missing proof of delivery. This describes a possible boundary, not a client implementation or a recommendation for every team.

A proportionate first release

Test one high-value path before committing to a program around the platform:

1. Name the source, destination and authoritative owner for the data involved.
2. Test permissions, identifiers and the real data shape with a small set of representative records.
3. Show the transfer state and an exception to the person who will operate it.
4. Define how a correction and retry are performed.
5. Document the accounts, assumptions and ownership before broadening the flow.

This work produces useful evidence whether the eventual answer is configuration, integration or custom software. For a broader operational view, explore ERP integration and workflow services or logistics software support.

If you are considering an ERP-adjacent improvement, describe the decision and systems involved in a project brief. We can help frame a bounded first question without assuming the platform itself needs replacement.