Four workflows, each one a flow you can open.
Orders, fulfillment, inventory and refunds are the loop every Shopify store runs with its ERP or WMS. Each band below lists the flow templates that implement that step today, drawn from the bundle catalog — not a brochure list.
Orders
Shopify order → ERP sales order
A paid Shopify order becomes a sales order in the ERP with the customer, currency, line items and the Shopify order id as the external reference. Split-by-location templates create one sales order per fulfillment order so a warehouse only sees its own lines.
Flow templates in the catalog
2 templatesShopify order → NetSuite sales order
order.created → 1 step
InstallableShopify + NetSuiteShopify order → BrightPearl sales order (split by location)
order.created → 3 steps
InstallableShopify + BrightPearl
Fulfillment
ERP goods-out → Shopify fulfillment
When the ERP or WMS ships a goods-out note, Bindato creates the Shopify fulfillment with the tracking number and carrier. Where the order was split by location, the fulfillment is scoped to that fulfillment order, so many shipments to one order never double-fulfill it.
Flow templates in the catalog
2 templatesNetSuite fulfillment → Shopify fulfillment
itemFulfillment.created → 1 step
InstallableShopify + NetSuiteBrightPearl goods-out shipped → Shopify fulfillment (per location)
fulfillment.shipped → 1 step
InstallableShopify + BrightPearl
Inventory
ERP stock change → Shopify inventory level
A stock change in the ERP sets the available quantity on the matching Shopify inventory item at a location. Where the ERP only knows a SKU, a lookup step resolves the Shopify inventory item id first instead of assuming a shared identifier.
Flow templates in the catalog
2 templatesNetSuite inventory → Shopify inventory level
inventory.changed → 1 step
InstallableShopify + NetSuiteBrightPearl stock change → Shopify inventory level
inventory.changed → 2 steps
InstallableShopify + BrightPearl
Refunds and credits
Shopify refund → ERP sales credit
A refund in Shopify should land in the ERP as a sales credit or credit memo against the original sales order, so finance reconciles from one ledger. The connectors declare the credit actions; the templates that wire them to a refund trigger are not in the catalog yet.
Included in every flow
What every workflow gets
These are properties of the engine, not options on a plan. Each one names the file that implements it.
Retries with backoff
Each step carries its own retry policy. The default retries five times on 429, 500, 502 and 503 with exponential backoff capped at 30 seconds; a template can choose halt, skip-record or retry per step.
apps/api/src/engine/executor.ts
A run record per trigger, a step record per action
Every trigger firing writes a run, and every step writes its attempt count, input, output and error message. A failed run carries the real cause on the run itself, not only one click deeper.
packages/db/prisma/schema.prisma · model RunStep
Settings confirmed before a flow can run
A bundle installs with placeholders in it. Its flows refuse to be enabled until the merchant has worked through the Settings tab and confirmed it — and a confirmed configuration that is later edited into an invalid state is blocked again.
apps/api/src/lib/bundleGuard.ts
In-app notifications for failed runs and offline connections
A scan every five minutes raises one alert per failed run and one per unhealthy connection, deduplicated so the bell never stacks copies. Notifications are in-app only today; there is no email or Slack delivery.
apps/api/src/jobs/notifications.ts
Questions
Frequently asked
The ones that come up in the first demo.
Which systems do these workflows run against today?
Can I change a template after installing a bundle?
What happens when the ERP is down during peak trading?
Where are refunds?
See one order flow end to end.
Thirty minutes with a Shopify store you control. We connect it, install a bundle, and walk the run record together.

