Choose a SaaS integration platform for ERP and factory data exchange by testing how it handles interrupted connections, rejected transactions, and inconsistent production data. A connector catalog helps establish compatibility, but it does not show whether a production confirmation will reach the ERP correctly after a network outage—or whether retrying it will create a duplicate inventory posting.

The strongest shortlist starts with the business transactions that must work, the conditions inside the plant, and the consequences of failure. Edge connectivity, transaction recovery, and operational visibility should carry more weight than the number of applications shown on a vendor’s website.

Define the exchange before comparing platforms

“Connect the factory to ERP” is too broad to evaluate. Sending equipment readings to an analytics service is different from posting finished goods, consuming materials, or releasing production orders. Each flow has its own timing, ownership, and recovery requirements.

Document a few representative exchanges before requesting demonstrations. For each one, identify the source, destination, expected volume, acceptable delay, and business consequence if the message is missing or wrong. Specify which system owns each field. The ERP may own material identifiers and production orders, while a manufacturing execution system owns execution status and production genealogy.

Separate business events from raw telemetry. A machine can generate many readings during one production cycle, but the ERP may need only a validated completion event with an order number, quantity, unit, and timestamp. Forwarding every reading increases processing costs and makes business transactions harder to distinguish.

Also define what “delivered” means. Acceptance by an integration service is different from acceptance by an ERP API, and both may precede the final business posting. Evaluation criteria should follow the transaction through to the outcome that production and finance actually depend on.

Decide where factory connectivity should live

A cloud integration service rarely connects directly to every machine. Factory environments may expose OPC UA, MQTT, industrial protocols, vendor interfaces, files, or databases. Some require a gateway or an existing manufacturing system to translate equipment data into usable events.

A common architecture places a gateway or integration runtime near the factory systems. It collects data locally, applies necessary filtering, and exchanges selected information with the cloud service through approved network paths. The SaaS platform then coordinates transformations and communication with the ERP.

The diagram for this architecture should distinguish the equipment network, local integration components, cloud service, and ERP. Mark where data is buffered, where credentials reside, and which connections cross security boundaries. Those details reveal more than a simple line between two application logos.

Three deployment patterns deserve consideration:

Keep time-critical machine control within systems designed for that purpose. A SaaS integration platform can exchange schedules, production results, and inventory events, but an internet connection should not become a dependency for a machine’s safety functions or deterministic control loop.

Test connector depth and data meaning together

A connector name does not establish functional coverage. An ERP connector might read master data but lack the supported operation needed to post a production receipt. Another may support the operation through an API that behaves differently from the plant’s existing import process.

Inspect the exact objects and actions required: production orders, material movements, batches, serial numbers, quality results, or maintenance notifications. Check authentication methods, pagination, rate limits, supported application versions, and how errors are returned. For outbound ERP events, determine whether the platform uses notifications, change capture, or polling; each affects latency and load differently.

Then test the meaning of the payload. A factory system may report pieces while the ERP expects cases. Equipment identifiers may be unique only within a plant. A timestamp may represent machine completion, operator confirmation, or message transmission. These differences require explicit mapping rules.

Useful transformation capabilities include reference lookups, unit conversion, schema validation, and versioned mappings. However, the platform also needs a controlled response when a lookup fails. Silently substituting a default material code can turn an interface problem into an inventory problem.

Assign responsibility for reference data and mapping changes. If a new production line introduces unfamiliar equipment codes, someone must decide whether to reject those events, hold them for correction, or update the mapping. Visual workflow tools do not remove that ownership requirement.

Make failure recovery a purchasing criterion

Manufacturing integrations must cope with interrupted connectivity, planned ERP maintenance, expired credentials, and valid messages arriving in an unexpected order. The decisive question is what happens to business transactions during those conditions.

Local buffering needs defined behavior. Ask whether the local runtime retains events durably during an outage, how storage capacity is managed, and what happens when that capacity is exhausted. Recovery should control the backlog so that reconnecting a plant does not overwhelm the ERP or delay current work indefinitely.

Retries need duplicate protection. A request may succeed in the ERP even when the response never reaches the integration service. Retrying can then create a second posting. Evaluate stable transaction identifiers, destination-side duplicate checks, and reconciliation logic. A claim of “exactly once” delivery needs a clearly defined boundary; messaging guarantees alone do not establish a single business posting across independent systems.

Event order needs explicit rules. A completion message may arrive before an order update, or a delayed correction may arrive after a shift closes. Determine whether ordering is required per order, machine, or batch. Broad ordering guarantees can create unnecessary bottlenecks, while missing dependency checks can produce invalid postings.

Recovery must be safe for operators. Failed messages should retain the context needed to diagnose and correct them. Authorized staff should be able to replay a selected transaction without resending an entire file or backlog. Replays must preserve transaction identity and produce an audit record.

Reconciliation deserves its own mechanism. Comparing source events with accepted ERP transactions can uncover gaps that dashboards miss, especially when a message passed through the integration service successfully but failed during downstream processing.

Inspect security boundaries and support responsibilities

Evaluate the platform against the actual IT and operational technology architecture. Map connection initiation, permitted destinations, certificate handling, service accounts, and access to production resources. Where outbound connections are used, examine what remote actions they allow; connection direction alone does not establish an adequate security boundary.

Apply least privilege to the business operation. An integration that posts production quantities should not automatically receive broad ERP administration rights. Similarly, access to an edge runtime should not imply unrestricted access to controllers or other equipment networks.

Look for separate development and production environments, controlled deployment approvals, secret management, and audit logs for configuration changes. If support personnel can inspect payloads or access local runtimes, establish how that access is authorized, recorded, and revoked.

Data location also extends beyond the primary database. Payloads may appear in diagnostic logs, failed-message queues, backups, and support exports. Evaluate retention and access controls across those locations, particularly when production records contain customer, recipe, or commercially sensitive information.

Choose observability that follows the business transaction

A green workflow indicator is insufficient if production staff cannot find a missing receipt. Operational visibility should connect a source event, its transformations, delivery attempts, destination response, and final processing status where that status is available.

Search by identifiers people use: production order, batch, serial number, plant, and transaction ID. Correlation should survive retries and movement between local and cloud components. Otherwise, support teams must reconstruct the exchange from unrelated logs during an incident.

Alerts should distinguish connectivity failures, accumulating backlogs, mapping errors, and ERP business-rule rejections. These conditions require different owners and remedies. Repeatedly retrying an invalid material number adds load without fixing the problem.

Ask a plant support engineer and an ERP support engineer to diagnose the same failed transaction during the demonstration. Their ability to locate the issue, understand responsibility, and recover safely is a useful measure of operational fit.

Compare costs using the proposed data flow

Subscription prices are difficult to compare until the architecture is defined. Platforms may meter tasks, messages, data volume, connector access, runtime capacity, or combinations of these. A single production event can trigger several billable steps through lookups, transformations, retries, and downstream calls.

Request estimates based on normal operation, production peaks, and outage recovery. Include test environments, local runtimes, high availability, log retention, support, and additional plants. Establish whether filtering telemetry at the edge changes chargeable consumption.

Implementation and ongoing maintenance also belong in total cost of ownership. Consider who builds mappings, updates certificates, tests ERP upgrades, and maintains custom code. A low subscription can become expensive when routine changes depend on scarce specialists.

For multiple factories, examine reusable deployment templates alongside local exceptions. Centralized templates can reduce repeated work, but plants may have different ERP versions, operating calendars, or equipment interfaces. The platform should support controlled variation without requiring a separate integration estate for every site.

Run a proof of concept that exposes the tradeoffs

Use one representative business process, such as a production completion that updates inventory. Include its real dependencies: order validation, material mapping, quantity conversion, ERP posting, and confirmation. A successful demonstration should produce evidence that the business transaction completed correctly.

Build the evaluation around a short set of scenarios:

1. Normal processing: Follow a valid event from the factory source through to the resulting ERP record.
2. Connection loss: Interrupt connectivity, accumulate events, and observe controlled recovery.
3. Ambiguous success: Simulate a lost response after acceptance and verify duplicate handling.
4. Invalid data: Submit an unknown material or inconsistent unit, then correct and replay the event.
5. Operational change: Modify a mapping through the proposed approval and deployment process, including rollback.

Agree on acceptance criteria before testing. These should cover permitted delay, tolerated data loss, duplicate prevention, diagnostic visibility, and recovery ownership. Record which capabilities are native, which require configuration, and which depend on custom development or another product.

Shortlist platforms that pass the nonnegotiable requirements before scoring convenience features. If a candidate cannot preserve required events during an outage or safely recover an uncertain ERP posting, an easier workflow designer will not resolve that weakness. Purchase against a demonstrated transaction path, with clear operating responsibilities and a cost model that reflects how the factory actually runs.