Integration Patterns

Workflow Architecture 101 describes the basic shapes a single workflow can take. This page is one level up: recurring integration problems and the way they have been solved on Vince Platform at customers running Infor M3 alongside warehouse, e-commerce, POS and other systems.

Each pattern is written the same way — the problem as it appeared, the solution that was implemented, and the platform pieces it is built from. Use them as starting points, not blueprints; most real integrations combine two or three.

Pattern	One-liner
On-demand data composition	Fetch and compose data from several systems when a user asks, instead of pre-loading it
Workflow as a service	Expose multi-step business logic as one endpoint any system can call
Stateful orchestration	Hold a message until conditions in several systems are met, then release it
Event-driven correction	Let a status change in one system drive a corrective sequence in others
High-volume event storage with search	Store a high-frequency event stream in a searchable layer for audit and replay
Conditional message routing	Pass standard messages through untouched; route exceptions to their own workflow

1. On-demand data composition

Fetch and compose data from multiple systems in real time when a user requests it, rather than pre-loading large static datasets.

The problem. Users needed to look up live data across a large number of entities and several data sources. Pre-loading everything into one place would have meant maintaining an enormous static dataset that was hard to keep current and slow to query.

The solution. A workflow is triggered on user request. It fetches from the relevant sources — M3 through MI programs, the WMS through its API — composes the answer, and returns it. Users see current, contextual data on demand, and can act on it directly, for example by pushing an update back to one of the systems, without involving IT.

Built from. Manual trigger or an API-triggered workflow · M3 API and REST API steps · Transform to merge the responses · surfaced through App Builder or VXL Live.

Good fit when the data is only valuable at the moment someone looks at it, the entity count is large, or freshness matters more than query speed over the whole set. Compare Scheduled snapshot for the opposite trade-off.

2. Workflow as a service

Expose complex multi-step business logic as a single, system-agnostic endpoint any external system can call.

The problem. Each time a new external system needed to trigger a business process in the ERP, the integration logic had to be rebuilt from scratch. Knowing how to sequence the API calls, handle validation and manage the edge cases lived in bespoke code per system — expensive to build and fragile to maintain.

The solution. The workflow logic was built once and exposed as a single endpoint. External systems call it in their own format; the workflow translates, sequences the M3 transactions and handles the result. Adding a new consumer means adding a mapping, not reimplementing the logic.

Built from. A workflow called synchronously as an API (see Combine M3 API Calls) · Transform for the inbound mapping · a sequence of M3 API steps · API clients for the callers.

Good fit when more than one system needs the same business operation, or when the operation is a multi-step sequence in M3 that should be correct everywhere it is used.

3. Stateful orchestration

Hold messages in flight and release them automatically once conditions across multiple systems are satisfied.

The problem. A business process required approval from an external party (customs, in this case) before a downstream system could be updated, but the two systems had no shared way to track that dependency. Messages were either sent too early, causing errors, or held manually, causing delays and operational risk.

The solution. A table acts as the intermediary. The in-flight object is stored and flagged as pending. When the external confirmation arrives, a second workflow updates the record; that update fires an event trigger, and the downstream message goes out automatically. No manual follow-up.

Built from. The land, then react shape · Table Updater · Event trigger with a condition such as status changed to confirmed · see Designing Tables for the table shape.

Good fit when two or more independent systems must each say "yes" before something can happen, and none of them knows about the others.

4. Event-driven correction

A status change in one system automatically triggers a corrective sequence across connected systems.

The problem. When a record had to be corrected after it had already been sent downstream, there was no native way to update it — the receiving system treated it as immutable. Teams deleted and recreated records by hand, adding risk and slowing operations.

The solution. The status change is monitored and acted on automatically. The workflow locates the record in the downstream system — in the original case an advance shipping notice (ASN) in the WMS — removes it, and lets the corrected version come through as a new record. The whole sequence runs without manual intervention.

Built from. An M3 event as trigger — a BOD through Infor ION or a table event · REST API steps against the downstream system · Transform to check each response's statusCode before continuing.

Good fit when a downstream system cannot update in place, or when "correct it manually" has become a recurring task in someone's day.

5. High-volume event storage with search

Ingest high-frequency events and store them in a queryable layer for auditing, replay or investigation.

The problem. A high-throughput integration from a retail POS platform produced up to ten events per second, each with a large payload. The team needed to search historical records for auditing and error recovery, but no storage option could handle the volume at a reasonable cost.

The solution. Events are stored in a table as they flow through. The table holds more than 40 million records, and searches complete in milliseconds. The team has a reliable audit trail and can find, inspect and resend any individual event.

Built from. An inbound API or event trigger · Table Updater · a resend workflow on top of the table, typically from an App Builder app that lets operations search and replay.

Good fit when volume is high, payloads are large, and the main consumer of the history is a person investigating a problem rather than a report.

6. Conditional message routing

Intercept a message flow, pass standard cases through untouched, and handle exceptions in a separate workflow.

The problem. A standard message format (an M3 BOD) worked well for most cases, but a set of edge cases fell outside what the specification supported. The alternatives — wait for a vendor fix, accept a less efficient workaround, or go fully custom — all carried significant cost or delay.

The solution. Messages are intercepted before they reach the target system and evaluated against a ruleset. Standard cases pass through unchanged. Edge cases are rerouted to a dedicated workflow that handles them, for example through direct MI calls. If the vendor later extends the spec, only the ruleset changes.

Built from. The message flow routed through the platform · a Transform holding the ruleset as a JSONata expression · the pass-through path and the exception path as separate workflows, so the standard flow stays simple.

Good fit when a standard integration covers 95 % of cases and you want to keep it standard, while the remaining 5 % still needs to work today.

Combining patterns

These patterns are rarely used alone:

• Workflow as a service often sits in front of conditional routing — one endpoint, with exceptions branching off inside.
• High-volume event storage is what makes event-driven correction safe: when a correction goes wrong, the original event is still there to replay.
• Stateful orchestration is land, then react with more than one writer to the table.

When you recognise one of these shapes in a requirement, start from the pattern, then adjust. For more ideas, browse the Concept Catalog.