Case Study · BioSteel Sports Nutrition · 2022–2023
Consolidating a fragmented integration stack onto one iPaaS
The problem
Selecting two new fulfillment partners created a question the org had been avoiding: how do we actually connect to them?
The existing answer was "however we did it last time." NetSuite sat at the center, but the integrations around it had sprawled across four separate middleware paths — a Boomi instance, a Celigo instance, and two different SPS Commerce setups — with seven partner endpoints hanging off them in no consistent pattern. Every new partner meant re-litigating the tooling choice. Mappings lived with vendors rather than with us, so changing a field meant filing a ticket and waiting. The result was sustained manual effort, a transaction error rate nobody was proud of, and cost accounting that couldn't be fully trusted.
The working conference
This is the part I'm proudest of, and it isn't technical.
Integration-pattern decisions have a way of dying in committee — everyone has a preference, nobody owns the call, and the question gets deferred until a go-live date forces a bad default. So I proposed a different mechanism: a single in-person working conference, and I built it end to end.
I set the agenda, wrote the material, and structured the session to walk the room from shared facts to a forced choice — RFP status and the selected partners, real order examples pulled from the live system, the most common eCommerce order profiles, the full inventory of transactions that would need to move, and the special cases that would break a naïve design. Then I facilitated it in person, and drove the group to an actual decision in the room, on the day.
The mechanism mattered more than my opinion did. Getting operations, finance, IT, and commercial in one room with the same evidence turned a months-long circular debate into a decision with owners attached.
The decision
The room landed on consolidating everything onto Celigo as a single iPaaS hub, on the merits:
- No caps on data volume — the cost of growth wouldn't scale against us
- Already proven in-house on the NetSuite–Shopify integration, so it wasn't a theoretical bet
- Mappings stay ours — the team could see and change its own field mappings without a vendor round-trip
- Adjacent leverage — the same platform could automate Amazon FBA settlement and FBM order flows we were handling manually
SPS Commerce was retained deliberately, but scoped down to the one job it was genuinely best at: EDI with retailers who require it.
The architecture
I specified the transaction set as a core group that every partner would implement identically, and a non-core group requiring NetSuite enhancement — each mapped to its EDI equivalent so the pattern stayed legible to partners already fluent in EDI.
- Core: sales order export (940) and fulfillment import (945); transfer order request (940), fulfillment (945), inbound shipment advice (943), and receipt advice (944)
- Non-core: inventory adjustment advice (947) for cycle-count reconciliation, master data creation (888) for new SKU setup, plus purchase-order shipment advice and receipt flows
Designing it as one repeatable pattern rather than seven bespoke connections is what made the fulfillment transition survivable — each new partner became an implementation of a known template instead of a fresh integration project.
Why it mattered
The flows themselves carry more weight than "data moving between systems" suggests. Fulfillment records drive revenue recognition and consume inventory at the lot level. Transfer-order receipts move inventory out of in-transit status. Getting these wrong doesn't produce a sync error — it produces a misstated balance sheet.
Consolidating them onto one governed pattern eliminated a standing manual workload, cut transactional errors, and gave cost accounting and inventory control a foundation that could be trusted.