Realsy's tech stack looked reasonable on paper. Cin7 for inventory management and accounting. Extensiv for warehouse management at their 3PL, RAD 3PL. CartRover as the middleware connecting their wholesale channels to both.
These are all reputable platforms. Each one does its job. The problem was that nobody had configured the connection between them correctly, and when something breaks at the integration layer, the failure looks like almost anything other than an integration layer failure.
What the symptom looked like
Purchase orders from wholesale channels (UNFI, Jewel Osco, Target) weren't flowing through to RAD 3PL for fulfillment. EDI orders were coming in through the Crystal wholesale system, and they were sitting.
The first working theory was a CartRover configuration issue. Then a Cin7 setup issue. Then a permissions problem. Then a CartRover issue again. This is what integration layer debugging looks like: the failure is in the gap between systems, so each system's support team points at the other one.
For weeks, wholesale orders that should have been flowing automatically were being worked around manually. Someone would identify a stuck order, figure out why it hadn't synced, and push it through by hand. The workaround worked well enough that the root cause stayed hidden. The orders got fulfilled. The system appeared to be functioning. The actual problem, that every PO created when inventory was on backorder was silently failing to sync, wasn't visible until someone asked why the manual interventions kept being necessary.
The actual problem
Deep inside Extensiv's configuration, there's a setting called a lock code. Lock codes determine whether a PO can be released for fulfillment based on inventory status. The specific setting that mattered was the one governing what happens when a PO is created and the ordered quantity isn't fully in stock.
The setting was configured as "Ordered." What it needed to be was "Ordered and Backordered."
That distinction sounds minor. It isn't. With the setting on "Ordered," any PO that was created when inventory was on backorder, meaning the warehouse didn't have enough stock on hand to immediately fulfill it, would fail to sync between Cin7 and Extensiv. The PO would exist in Cin7. It would not appear in Extensiv. CartRover, which was routing orders between the two, had nothing to relay.
For a food brand that regularly runs lean on inventory and expects orders to queue against incoming stock, "Ordered and Backordered" is the correct behavior. The PO should exist in the warehouse management system regardless of current stock levels, waiting for inventory to arrive. The "Ordered" setting effectively said: only sync this PO if we already have the stock. Which meant that every order that required any degree of backorder processing was invisible to the 3PL.
Why this kind of failure is so hard to find
Platform-specific configuration knowledge is not general knowledge. The lock code setting in Extensiv is not something you'd encounter unless you'd worked with Extensiv specifically, at this depth, in a multi-system integration context. Cin7's support team doesn't know Extensiv's lock code behavior. CartRover's support team sees orders passing or not passing and can tell you which, but can't diagnose why the Extensiv side isn't accepting them.
The only way to find this was to sit with an Extensiv support specialist and go through the configuration settings one by one, asking what each one does and what happens in edge cases. That conversation eventually surfaced the lock code issue. Before that conversation, there was no obvious path to the right answer.
The broader point is about what integration layer failures feel like from the outside. They don't announce themselves as integration problems. They look like fulfillment delays, stuck orders, unexplained manual interventions, inconsistent sync behavior. The symptom set is diffuse enough that you can spend significant time investigating the wrong system.
What the fix enabled
One dropdown change in Extensiv: from "Ordered" to "Ordered and Backordered."
After that, POs started syncing correctly between Cin7 and Extensiv regardless of inventory availability at the time of order creation. The 3PL received the orders, queued them against expected stock, and fulfilled them when inventory arrived. No more manual interventions for the backorder case.
The orders to UNFI, Jewel Osco, and Target that had been stuck or manually worked around were now processing automatically. The volume those accounts represent was significant. This wasn't a minor edge case. These were Realsy's major wholesale relationships.
The lesson isn't "check your lock codes." Most people don't know what lock codes are. The lesson is that integration-layer problems require someone who has built this specific integration before, not someone who knows each individual platform. General platform expertise doesn't transfer. You need someone who's been in that exact configuration before and knows where the edge cases live.
One dropdown. Weeks of stuck orders. That ratio, one setting change unlocking an entire channel's order processing, is more common than it should be.
