Integrating Manufacturing's Customers: The Patterns That Keep Showing Up

Over the years we’ve integrated a wide range of customer systems, ERPs, and manufacturing platforms. Each project looks different on the surface, but the underlying problems — and the solutions that endure — tend to repeat. One recent project in particular, which we deliberately built with no user interface at all, brought those patterns into sharp focus. With a lights‑off integration, there is nowhere for hidden assumptions to hide. No screens. No prompts. No operator quietly fixing bad data. The process either works end‑to‑end, or it doesn’t — and that clarity is extremely useful.
This article summarises what we’ve actually found when integrating customers directly into our clients’ manufacturing processes.

1. What lights‑off integration reveals immediately
In this recent integration, an orchestrator — Lobster, in our current development — called our application directly. We were exposing an API, and the orchestrator was responsible for passing validated messages into it. We weren’t just talking to one system; we were working with:

• The manufacturing system’s database
• The manufacturing system’s own API
• Occasionally several additional systems where data or scheduling originated

We're calling this 'lights-off integration', this might also be called 'Headless Integration' or 'Straight-through Processing' but the things we find are true in cases where there are user interfaces, but these are less extreme.
With no user interface (UI) to absorb ambiguity, every assumption had to be encoded explicitly. That clarity helped surface issues earlier and more reliably. We’ve found our programmers rely heavily on team members experienced in understanding what can go wrong.

2. The predictable failure modes we always see
Unstable identifiers
Different systems have their own ideas of what constitutes a unique reference. The customer is the customer, so you can't easily make them use your codes in their docs if they don't want to — we have to map across. Without stable identifiers, reconciliation quickly becomes difficult.
Operator judgement that software must now encode
In manual workflows, humans instinctively know what to do when:

• A customer sends a repeat order
• A product has been discontinued
• The data is incomplete or malformed but easily corrected
• A quantity doesn’t match the original order

Software can’t make judgement calls — so we must define the strategy upfront. The integration must either decide the correct behaviour autonomously or raise a structured exception to the right team.

Competing sources of truth

We regularly integrate customer ERPs with manufacturer ERPs and MES systems. When a customer believes their system is the source of truth, but the manufacturer’s scheduling system disagrees, the integration must reconcile the difference.

3. Designing identifiers that stay stable under pressure
One of the earliest lessons we’ve learned is simple: derive identifiers once, in one place, and never reinterpret them later. When multiple systems are involved, this means:

• Generating one canonical internal shipment/load identifier, controlled by the manufacturing system
• Treating customer‑provided identifiers as metadata
• Ensuring the same identifier is used consistently throughout the entire process — API, database, scheduling, documents, and outbound messages
• Stable identifiers prevent whole classes of downstream errors.

4. The Minimum Viable Event Model
To get clean, repeatable behaviour, the integration needs a small number of explicit business events. The exact names vary, but the structure might looks like:

1. OrderReceived
2. OrderValidated
3. AllocationCommitted
4. LoadPrepared
5. PalletisationCompleted
6. ShipmentConfirmed

Each event can be reasoned about, logged, replayed, and audited. When the events are clear, the process is clear.

5. Edge conditions: where most of the real work is
A manufacturing environment is full of complications that no ERP captures perfectly:

• The client sends a repeat order, expecting it to merge
• A product has been retired, but is still in the customer’s system
• Machines stop mid‑pallet, creating partial loads
• Operators consolidate pallets
• A quantity discrepancy is discovered during production

With lights‑off integration, every one of these situations needs a rule. A system that rejects everything is unusable; a system that silently accepts inconsistent data is dangerous.
Our approach:

• Define which conditions can auto‑correct
• Define which must trigger a human review — either sending an email or issuing a warning to the orchestrator
• Notify the right team with a clear, actionable message
• Keep the internal system consistent and traceable

6. Working with orchestrators (Lobster or otherwise)
Using an orchestrator is helpful when the boundary is clear. We have often worked on systems that are purely point‑to‑point. Larger clients might use an orchestrator such as Lobster. We are increasingly finding Microsoft’s Power Automate stepping in on smaller systems.
The orchestrator handles:

• Transport
• File ingestion
• Schema validation
• Basic routing

Our integration layer handles:

• Domain validation
• Business rules
• Identifier generation
• Load/pallet/schedule creation
• Exception classification
• Writing to the manufacturing system’s database/API

This separation prevents brittle business rules leaking into the orchestration layer.

7. A practical architecture that consistently works
We keep coming back to a simple structure:

1. Customer → Orchestrator — validate shape; forward messages (EDI, email, deposited document, or spreadsheet)
2. Orchestrator → Integration API — enforce business logic; derive identifiers
3. Integration API → Manufacturing Systems — commit the real operational work
4. Integration API → Outbound Messages — confirmations, exceptions, reconciled documents

8. Where we usually start with new integrations
When someone asks where to begin, we recommend:

• Write down the event model — rough but explicit; the right diagram helps
• Choose one canonical identifier — identify what represents each concept (order number, shipment reference, SKU, etc.) and how these differ between customer, manufacturing, sales, and logistics systems
• Define the exception rules first — especially repeats, discontinued products, and quantity ambiguities

Final thoughts
Lights‑off integration forces clarity. It exposes assumptions, surfaces edge cases early, and demands that every judgement call be turned into a rule. While it may feel strict at first, it ultimately produces cleaner, more reliable integrations — the kind that help manufacturers and their customers work together smoothly.

We may make it all seem tricky at times — and certainly the devil is in the detail. Even we, who work in this space all the time, are surprised by how much detail emerges during development. But the result is a more efficient, predictable, and dependable operation, linking customers to the manufacturing organisation or even production cells to each other.