How-toTulip with any ERPTulip / Connectors and Tables

How to integrate Tulip with your ERP

Question

how to integrate Tulip with ERP

Also searched as

Tulip connector function ERP work order
Tulip Apps sync with SAP NetSuite SyteLine
Tulip Tables to ERP data sync
Tulip on-prem connector host ERP

Short answer

Tulip talks to an ERP through Connectors: you define an HTTP or SQL connector with functions that your Apps call as triggers. Use Tulip Tables as a local cache of work orders and as an outbox of completions, and let an integration layer or the ERP's API do the actual posting. Keep ERP credentials in the connector, not in the App logic.

Applies to: Tulip Frontline Operations Platform with Connectors (HTTP and SQL), Connector Functions, Tulip Tables, and the On-Prem Connector Host; any ERP with an API, database interface or middleware.

Connect a Tulip App to an ERP

1List what the App needs from the ERP (open work orders, routing steps, item data, operators) and what it must return (completed quantity, scrap, labor time, lot numbers).
2Create a Connector in Tulip (Settings, Connectors) of the right type: HTTP for REST/SOAP-style APIs or SQL for a database view, and store the credentials there.
3If the ERP is not reachable from the cloud, install the On-Prem Connector Host inside your network so Tulip reaches the ERP through it, and restrict it to the specific endpoints required.
4Define Connector Functions, for example GetOpenWorkOrders and PostCompletion, with typed inputs and outputs, and test each in the connector editor with real sample data.
5Create Tulip Tables such as WorkOrders (cache) and CompletionOutbox (events to post). Add a status column and a unique event key to the outbox.
6In the App, use Triggers to call GetOpenWorkOrders on a schedule or button and upsert into the WorkOrders table, and write a CompletionOutbox record when the operator finishes a step.
7Run the posting call from an Automation or an integration layer that reads the outbox, calls the ERP, and writes back POSTED or ERROR with the response message.
8Show the operator or supervisor the post status in the App so errors are corrected at the station, not discovered later.

Connector Functions: how they work

A Connector Function is a named, typed call defined once and reused across Apps. For an HTTP connector you set method, path, headers, query parameters and body template, then map the JSON response to output fields such as work order number, quantity and due date. In the App editor, a Trigger calls the function and writes results into variables or Tables.

Keep functions small and single purpose. A GetWorkOrder function by order number is easier to test and cache than a function returning every order. Handle pagination on the ERP side or in the function, because very large responses slow Apps on tablets and can hit platform limits.

Errors matter: build the trigger so a non-success response is captured and shown, rather than assuming the call worked. A silent failure is the main reason operators finish a job in Tulip and find no record in the ERP.

POST /api/v1/production-completions
Headers: Authorization: Bearer <token>, Idempotency-Key: {{event_key}}
Body: {"workOrder":"{{wo}}","operation":{{op}},"qtyGood":{{good}},"qtyScrap":{{scrap}},"completedAt":"{{ts}}"}

Using Tulip Tables as cache and outbox

Tulip Tables are good for data that Apps share across stations: a cache of released work orders and routing steps, and a record of events. Treat the work order table as a copy refreshed from the ERP, not the master, and store the ERP's last-modified time so an App can warn when an order changed after the operator started.

The outbox pattern matters because tablet networks drop and ERPs go down for maintenance. Writing the completion to a Table first guarantees the event exists, then a posting process retries until the ERP accepts it. Include a unique event key and send it as an idempotency key or reference field so retries cannot double-post.

Do not store sensitive data you do not need. If the ERP holds controlled technical data, keep drawings and specs referenced by link or ID and enforce the ERP or PLM permissions, rather than copying files into Tulip.

Which system owns what

Common split: the ERP owns orders, routings, items, inventory and cost. Tulip owns operator guidance, data capture (checks, measurements, photos), station state and step timing. The quality and inspection results captured in Tulip often feed a QMS or the ERP's quality module, so decide early where the record of truth lives.

Labor and time posting is where disputes arise. Tulip can capture step start and stop to the second, but the ERP may expect labor by operation and employee. Agree the rule: post total labor per operation from Tulip steps, or keep punch-based labor in the ERP and use Tulip times for analysis only.

For aerospace, defense and medical environments, attach the evidence the audit needs, such as serial or lot, operator ID, tool or gauge ID and measured values, to the same event key as the ERP completion so the two records can be traced together.

Security, hosting and change control

Use a dedicated integration account with only the permissions needed: read on open orders, create on completions. Never reuse an administrator login. Rotate tokens and keep a list of which connector uses which credential.

If data residency or network rules prevent a cloud connection to the ERP, the On-Prem Connector Host and outbound-only firewall rules are the usual answer. Confirm with your security team what data leaves the plant to the Tulip cloud and document it.

Version your connectors and test functions in a non-production ERP company or test environment before changing an App used on live lines, since an API field rename in an ERP upgrade will break a mapped function.

Common pitfalls

!Calling the ERP directly from every App step without an outbox, so one network blip loses a completion.
!No idempotency key, causing double-posted quantities on retry.
!Treating the cached work order Table as the master and ignoring ERP changes after release.
!Returning huge payloads to a tablet instead of narrow, paged functions.
!Using an ERP admin credential in the connector.
!Leaving error responses unhandled so operators think a post succeeded.

How an ERP-grounded AI assistant handles this

An assistant grounded in the ERP and in an export of the Tulip Tables can answer which completions are stuck in ERROR, which orders were completed in Tulip but not in the ERP, and why a post was rejected, using the ERP's own message text. With ERPray it works read-only on live ERP data, shows the query behind each answer and respects ERP roles. It does not post to the ERP; reposting remains your integration layer or a human action.

See ERPray

Frequently asked questions

Does Tulip have a prebuilt connector for my ERP?

Tulip provides generic HTTP and SQL connectors and a library of Connector Functions, and may offer templates for some systems. Availability and depth vary by ERP and release, so confirm with Tulip or a partner. Many plants build a thin custom connector against their ERP's API.

Do I need middleware between Tulip and the ERP?

Not always. For simple read and post flows, Connector Functions calling the ERP API can be enough. Add middleware or an integration platform when you need queuing, transformation across several systems, heavy retry logic or monitoring beyond what Tulip provides.

How do I stop duplicate completions?

Generate a unique event key in the App when the operator completes a step, store it in the outbox Table, and send it to the ERP as a reference or idempotency value. The poster should skip any key already marked posted, and the ERP interface should reject duplicates where it can.

Can Tulip run when the ERP is down?

Yes if you design for it. Cache the released work orders in a Table and queue completions in the outbox. Operators keep working, and the posting process drains the queue once the ERP returns. Test this by deliberately blocking the ERP during a pilot.

How-to

How to Send Production and Labor Reporting from MES to ERP

Treat the ERP work order as the system of record for cost and quantity, and the MES as the system of record for what physically happened. Send one confirmation message per operation (or per shift or lot) containing work order, operation sequence, good quantity, scrap quantity with reason, and labor start/stop per employee and work center, post it through the ERP's supported transaction API, and make the message idempotent so a retry never double-posts.

How-to

How to integrate Ignition with your ERP

Do not let Ignition write straight into ERP tables. Put a staging layer between them: Ignition writes production events to a staging table or calls an ERP API through a gateway script, and a controlled poster validates and posts them to the ERP. Pull work orders the other way with a scheduled gateway script or Named Query against a read-only view or API.

How-to

How to replace paper travelers with a digital traveler

Treat the digital traveler as a view of the ERP work order and routing, plus a record of what was actually done. Pull released orders and operations from the ERP, add controlled instructions and required data captures per step, post completions back, and keep the signed record as an auditable artifact. Pilot on one cell before changing the whole plant.

Advanced

ISA-95 and B2MML: How to Integrate ERP with MES

ISA-95 defines the boundary between business systems (Level 4, the ERP) and manufacturing operations (Level 3, the MES) and the information that crosses it. B2MML is the XML implementation of those models. In practice you exchange a ProductionSchedule from ERP to MES, and ProductionPerformance, plus material and equipment information, back, mapping each element to your ERP's work order and confirmation APIs.

How-to

How to Calculate OEE from MES Data and ERP Standards

OEE equals Availability times Performance times Quality. Availability comes from MES run and stop events against planned production time, Performance compares actual output to the ideal cycle time (usually the routing standard from the ERP), and Quality is good units divided by total units. The numbers are only trustworthy if planned time, ideal cycle time and the good/scrap split are defined once and used consistently.

Advanced

How to Connect OPC UA Machine Data to Your ERP

Do not connect OPC UA servers straight to the ERP. Read machine tags through an edge gateway or MES, convert signals into business events (cycle complete, stop, state change, count), attach the work order context, and post summarised confirmations to the ERP through its supported API. The ERP wants quantities, times and reasons per order, not millions of raw tag values.

AI for ERP