What a Custom OMS integration gives you.
The integration ensures every order reaches the right warehouse, branch or 3PL based on stock, location rules and customer preference. Mis-routed orders drop dramatically.
The OMS sees real-time stock from ERP or WMS and reserves quantities at allocation time. Oversells across online, branch and wholesale channels are prevented.
Every order shows its current location, next milestone and any holds or exceptions. Customer service can answer 'where is my order' without guessing or escalating.
Return requests land in the OMS, the OMS directs them to the right receiving point, and refunds reconcile back to ERP. No orphaned returns or stuck RMAs.
Hold reasons, resolution owners and escalation paths are named upfront. Queued orders move through review and release quickly instead of accumulating as backlog.
Where a Custom OMS integration earns its place.
If two or more of these are true, the integration usually pays for itself quickly.
Where off-the-shelf connectors fall short.
Vendor connectors are fine for simple cases. Here's where the real ones need more.
Standard OMS templates assume a fixed set of locations and rules. Multi-site or dropship scenarios require custom routing tables, threshold logic and carrier integrations that generic systems don't support natively.
Off-the-shelf OMS typically holds its own stock cache and may not reconcile back to the true source in ERP or warehouse systems. Allocation decisions made on stale data lead to oversells or empty-slot fulfillment.
Most standard OMS send a single shipment notification per order. When orders split across locations or get held and released in tranches, customers don't see the full picture and customer service can't explain delays.
Orders on hold for manual review, payment disputes, address verification or inventory issues land in a queue but no one has named responsibility for checking and resolving them daily.
Generic OMS often lack the connectors to push dispatch to a specific 3PL, pull real-time tracking, or handle branch-initiated returns or stock moves. Custom mappings or middleware end up managing the seams.
Order orchestration often hides its true complexity until split shipments, dropship suppliers and multi-location stock create silent allocation conflicts; clear data ownership and daily exception review are the only defences against backlog.
Where this integration sits in your estate.
Custom OMS holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.
Built for your platform, not a specific one. Custom OMS integrates with any ecommerce core through the same contract.
- Order routing rules and location selection
- Stock allocation and reservation logic
- Order hold reasons and exception queues
- Fulfillment status and order events
- Returns and RMA orchestration
- Customer identity and account
- Shopping cart and checkout
- Order capture and submission
- Storefront order display and tracking notifications
- Return initiation by customer
Systems this integration usually sits next to.
Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.
- Adobe Commerce
- Magento Open Source
- Shopify Plus
- BigCommerce
- Other storefronts
- ERP (SAP, NetSuite, Sage, Infor)
- WMS (Körber, Blue Yonder, Manhattan)
- 3PL and fulfillment networks
- Branch POS and trade-counter systems
- Customer service and support portals
- Email and notification services
- Warehouse and scanning devices
- Carrier APIs (DPD, Royal Mail, Fedex, UPS)
Not sure if this works with your stack?
Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.
The data flows we wire.
Each flow has a direction and an owner. We agree both before a line of code is written.
How iWeb configures the integration around your business.
Same method on every integration. The decisions come before the code.
- 01Map the OMS data and ownership boundaries
iWeb documents what the OMS owns (routing rules, allocation state, order hold reasons, split-shipment tracking) versus what ERP owns (invoice, customer account, nominal codes). This clarity prevents duplicated logic or lost data.
- 02Design order routing and stock allocation logic
iWeb builds the decision trees for location selection, stock reservation thresholds, dropship handoff and priority-based allocation. These rules are version-controlled, monitored and auditable.
- 03Build OMS-to-ERP and OMS-to-WMS integrations
iWeb creates the inbound stock and pricing sync from ERP, the outbound dispatch-instruction flow to WMS or 3PL, and the inbound tracking / dispatch-confirmation loop. All flows have monitoring, retry logic and fallback paths.
- 04Integrate OMS status with storefront and support tools
iWeb pushes order status, tracking and hold notifications from the OMS to the customer account, email system and support portal. Agents and customers see a single version of truth.
- 05Build exception handling and escalation workflows
iWeb defines what triggers a hold (payment review, address check, stock shortage), who is notified, and how long the order waits before escalation. Queues are monitored continuously.
Who owns what.
The single most important table in any integration. One system owns each field; everything else reads it.
Built this before
iWeb has designed and built order orchestration and routing integrations for multi-location, dropship and marketplace scenarios. We understand how a custom OMS sits between the storefront, inventory and fulfilment systems, and what can go wrong when those boundaries are unclear.
What we test before launch.
Every one of these is rehearsed before a customer ever sees the integration.
Common risks and where they bite.
We name these on day one. A risk written down is a risk you can plan around.
If the OMS cache of stock is not refreshed in real time from ERP or WMS, allocation decisions reserve non-existent inventory. Multiple channels and high velocity make the drift worse.
An order that splits across two locations may generate two dispatch instructions but only one shipping notification to the customer. The second package arrives as a surprise or goes untracked.
If the OMS cannot push the PO to the supplier's EDI or API, or cannot pull acknowledgement and tracking back, the order orphans in the OMS with no visibility of supplier progress.
Orders on hold for payment review, address issues or inventory shortage accumulate in a queue. No one checks the queue daily, so holds extend for days without customer or support visibility.
If the integration from OMS to commerce or support system breaks or lags, customers and agents see a stale or missing order status. They assume the order is lost.
A return request may route to a branch that didn't originally fulfill the order, causing local stock loss and broken reconciliation. Or the return refund doesn't sync back to ERP, leaving a credit pending.
Relevant services and sectors.
Common questions about Custom OMS integrations.
Who decides where an order goes – the OMS, ERP or storefront?
The OMS owns routing decisions. It receives the order from the storefront, checks stock availability and location rules, and selects the warehouse, branch or 3PL that will fulfill it. ERP supplies the stock data; the storefront does not make the routing call. iWeb maps these roles upfront so no system duplicates the logic.
What happens if the OMS is down when an order arrives?
iWeb designs a fallback so orders either queue safely in the storefront or a middleware layer until the OMS is back online, or route to a manual review queue if the outage is prolonged. The fallback is defined before launch so there is no guesswork during an incident.
How does the OMS know current stock levels?
The OMS receives a stock feed from ERP or WMS at a cadence (real time, every few minutes, or hourly depending on your volume and risk tolerance). iWeb sets the refresh interval and monitors for staleness. If the feed breaks, the OMS can either halt allocations or use a safe buffer; the choice is yours.
How do split shipments work – does the customer see both?
Yes. When an order splits across locations, the OMS generates separate dispatch instructions for each. iWeb ensures each generates a tracking notification, and the storefront and customer account consolidate them so the customer sees one order with multiple shipments and arrival dates.
What happens when a dropship supplier doesn't acknowledge a purchase order?
The OMS holds the order in an exception queue with a reason code (supplier-ack-pending). iWeb sets an escalation timer; if the supplier doesn't acknowledge within a time window, an alert triggers so the fulfilment team can follow up or reroute the order.
How does customer service see order status in real time?
The OMS publishes order status (in-warehouse, picked, shipped, delivered, held, etc.) to your support or customer service portal via API. iWeb builds the integration so that system queries the OMS or receives push updates. Agents see the same status as the storefront.
How do returns flow back from the customer to the warehouse?
A customer initiates a return in the storefront or contacts support. The return request lands in the OMS, which assigns a receiving location (warehouse, branch or 3PL RMA depot) and sends instructions. The receiving location scans the return in, and the OMS confirms to ERP so the refund can be processed.
What triggers an order to be held instead of dispatched immediately?
Common holds are: payment not yet confirmed, address cannot be validated, stock became unavailable after allocation, or fraud / compliance review needed. iWeb defines the hold reasons and escalation timers upfront. Held orders live in a queue that the team checks daily.
How does the OMS integrate with our branch or trade-counter system?
If you have branches, the OMS needs to see branch stock and may route orders to the branch for click-and-collect or local fulfillment. iWeb builds a two-way sync: branch stock levels feed into OMS allocation, and dispatch instructions flow from OMS to the branch point-of-sale or till. Returns initiated at the branch also feed back to OMS.
Can the OMS allocate stock differently for wholesale versus retail orders?
Yes. The OMS routing logic can include channel-specific rules – for example, wholesale orders might reserve a dedicated pool of stock or always route to a specific location. iWeb builds these rules and monitors them so you can adjust allocation policy without re-coding.
How does the integration handle a breach in the service-level agreement – an order that should have shipped but didn't?
iWeb builds alerts and reports that flag orders exceeding time-in-hold or time-in-warehouse thresholds. These alerts trigger escalation so the team can investigate and either release the order, reroute it, or contact the customer with an update.
What monitoring and dashboards does iWeb set up to track OMS health?
iWeb builds dashboards showing order volume by routing destination, allocation success rate, exception-queue depth, hold durations, and dispatch time. Integration failures (stock feed lag, dispatch API errors, status sync delay) are logged and alerted. This visibility is critical to catching problems before customers are impacted.
Can we change routing rules or allocation thresholds without a code release?
Yes. iWeb designs the OMS integration so routing rules and thresholds live in a configuration layer that operations can adjust. Changes are logged, versioned and tested in a staging environment before production. This reduces the need for engineering releases and speeds up optimisation.
How does the OMS interact with our ERP's order-to-cash process?
The OMS owns orchestration and fulfillment status. ERP owns the invoice, revenue recognition and customer account. iWeb ensures the OMS sends a dispatch confirmation to ERP, which triggers invoicing. The financial order record stays in ERP; OMS status stays in OMS. Returns flow back the same way – OMS initiates, ERP books the credit.
Projects with a similar shape.
A craft community PIM project built around digital assets, enrichment and catalogue flexibility.
Craft product data managed through cleaner assets, faster enrichment and more adaptable workflows.
A wellness commerce platform rebuilt around subscriptions, advice and repeat purchasing.
Microsoft Dynamics ERP integration, subscription commerce.
A construction supplies commerce platform rebuilt around trade purchasing and product depth.
Trade product complexity handled through a faster, more effective ecommerce experience.