Cloudshelf and Cin7 Core
Integration Agency & Consultants
Inventory latency between the showroom and the warehouse becomes an operational risk when high-street traffic peaks. If a Cloudshelf kiosk sells the last unit of a SKU before Cin7 Core can signal a stock depletion to other channels, the result is overselling and manual reconciliation. This setup targets retailers using in-store kiosks to provide an 'endless aisle' experience where physical stock must stay in sync with the central ERP ledger. Cogent2 designs the data flow so showroom sales and stock levels move between systems to prevent sales cancellations and fragmented inventory reporting.
Mapping stock truth and showroom workflows
Upfront diagnosis determines if the integration will hold up under showroom pressure. We examine the source of truth for stock levels and where pricing is managed to prevent customer frustration at the kiosk. Consulting identifies current manual workarounds, such as staff manually adjusting Cin7 after a showroom sale, and where duplicated data causes reporting contradictions. We decide the integration design here, including the sequencing of data flows and how finance and operations will agree on stock depletion models. Skipping this discovery leads to bad architectural decisions that later require expensive rework or cause inventory drift that damages the customer experience. This work ensures that when the technical build begins, most operational risks have already been mitigated.
Solution Design
Design for the Cloudshelf and Cin7 Core pair focuses on showroom stock accuracy and ledger integrity. We establish Cin7 Core as the master of inventory and price, with Cloudshelf pulling live availability to the showroom floor. A key design decision is the trade-off regarding sync frequency: real-time inventory lookups protect against overselling high-demand items but can increase API pressure during peak trading. We typically sequence the inventory sync as the priority to ensure kiosk reliability, while financial postings for completed sales are batched to simplify daily reconciliation and VAT reporting. This opinionated choice allows store staff to trust kiosk levels while finance closes the month off a clean Cin7 ledger. What stays manual on day one is defined to prevent ownership leakage during the rollout phase.
Connecting showroom sales to the ledger
This integration establishes Cin7 Core as the master of inventory, price, and financial ledger data. Cloudshelf operates as the showroom interface, pulling live availability to the floor and pushing completed sales back to Cin7 for stock depletion. The sync runs on a defined cadence to ensure store stock reflects warehouse reality. We map SKU identifiers 1:1 between systems so that showroom staff cannot sell a product that the warehouse cannot fulfil. By monitoring the boundary, we detect stalled syncs or SKU mismatches early, preventing 'orphaned sales' where a physical transaction occurs but fails to register in the central ERP ledger.
Orchestrating resilient data flows at scale
A controlled integration layer governs data flow between Cloudshelf and Cin7 Core, ensuring that showroom browsing translates into accurate back-office ledger entries. This layer manages the movement of product catalogues, live inventory availability, and completed sales orders. A common failure in high-street environments is a dropped webhook during peak traffic, which could leave a kiosk showing 'available' for an item that just sold out in the warehouse. Our integration layer prevents this through schema validation and a defined retry schedule that catches malformed payloads before they reach the ERP. Failures are handled through threshold-based alerting to the operations team and full payload logging for rapid diagnosis. The infrastructure maintains enterprise-grade security standards, including ISO 27001 and SOC 2, and is actively managed by Cogent consultants alongside operational monitoring agents.
Monitoring sync health and pricing drift
A 'connected' status does not guarantee that the stock level on a kiosk matches the actual balance in Cin7 Core. Real visibility requires monitoring the delta between the Cloudshelf cache and the Cin7 warehouse ledger. We focus on surfacing issues like pricing drift, where a kiosk displays an outdated promotional price, or sync queues that stall during peak showroom hours. By detecting these discrepancies early, we prevent compounding errors that often lead to manual stock adjustments. Our approach prioritises these exceptions, alerting your team to data mismatches before they lead to lost sales or customer frustration on the showroom floor.
Handing over the new operating model
Success depends on the retail, operations, and finance teams owning the new workflow once the kiosks go live. Handover focuses on the operating model: how Cloudshelf pulls availability from Cin7 Core and where the final sale record sits. Teams learn to interpret alerts from the integration layer and understand who owns specific exception types, such as a SKU mismatch between the kiosk and the warehouse. We define what to check daily to ensure showroom tablets are synced and how to verify weekly that kiosk sales have correctly depleted stock in the main ledger. Documentation is provided as a practical operational reference written for those running the business, rather than a technical archive. This ensures the team can resolve common sync issues without external support.
Operational oversight and hypercare monitoring
Support means monitoring for operational latency. We track the flow of data between Cloudshelf and Cin7 Core to ensure showroom stock reflects true warehouse availability. If a sync stalls or a pricing update fails to reach the kiosks, we aim to flag the deviation before it leads to overselling in the showroom. This provides ongoing operational oversight, ensuring the integration remains stable during peak trade.
Common failures
Inventory latency and overselling
Operational impact: Cloudshelf's kiosk cache may not update immediately after stock adjustments in Cin7 Core. During peak traffic, a customer can purchase the last unit at a kiosk, but before Cin7 Core confirms the depletion, a web customer buys the same SKU. This results in negative stock, forcing teams to handle cancellations and process refunds against unfulfillable Sales Orders.
Prevention: Minimising stock latency is the priority. This involves configuring frequent syncs from Cin7 Core to the kiosk layer. In some implementations, the sale-capture process can be configured to verify availability in the central ledger before the order finalises.
Incorrect financial reconciliation
Operational impact: Sales Orders from Cloudshelf often land in Cin7 Core with incorrect tax treatments. This creates manual labour for finance, who must correct records before month-end to ensure VAT journals are accurate. It also complicates the reconciliation of payment processor reports against the ledger.
Prevention: Cin7 Core should be the master for tax rules. Before launch, kiosk payment types must be mapped to corresponding general ledger accounts. The integration logic should post transaction values clearly so Cin7 Core can apply the correct tax rules automatically.
Incorrect fulfilment location assignment
Operational impact: A showroom sale is incorrectly assigned to the main warehouse in Cin7 Core. This causes the warehouse team to attempt a wasted pick for an item that is already gone. Meanwhile, the physical showroom stock is not depleted, leading to stock count variances and operational confusion.
Prevention: A dedicated showroom stock location should be created in Cin7 Core. The integration must assign all Sales Orders from Cloudshelf to this location to ensure stock is depleted correctly at the point of sale and prevent unnecessary pick lists.
Frequently asked questions
How quickly does a sale on a Cloudshelf kiosk update inventory in Cin7 Core to prevent overselling?
A completed sale in Cloudshelf creates a sales order that is pushed to Cin7 Core to deplete stock from the master inventory record. While this sync is typically fast, a short delay can exist, meaning an online channel could sell the last unit just before the kiosk sale fully processes. This small risk of inventory latency during peak traffic is a key factor to manage during implementation.
What happens if our product SKUs in Cloudshelf don't perfectly match the item SKUs in Cin7 Core?
The integration requires an exact SKU-to-SKU match to connect products between Cloudshelf and Cin7 Core. If a SKU has a different format or does not exist in Cin7 Core, the inventory sync will fail for that item record. This means your Cloudshelf kiosks will show incorrect stock information, leading to failed sales or overselling.
We use special price lists in Cin7 Core. Can Cloudshelf show the correct showroom prices?
Yes, because Cin7 Core is treated as the master for pricing, the integration can pull from a specific price list for display on Cloudshelf kiosks. This ensures that any price adjustments made to item records in Cin7 Core are automatically reflected on the showroom floor. It avoids having to manage prices in two separate systems.
If a customer returns an item to the showroom, is the stock automatically added back into Cin7 Core?
This depends on the configuration, as it is a common failure point if not explicitly designed. A refund processed via Cloudshelf might not trigger a restock in Cin7 Core by default, even if a credit note is created. The returns handling process must ensure a 'restock' action correctly updates the master inventory level in Cin7 Core to make the SKU available again.
Why can't our showroom staff just manually update stock levels on the Cloudshelf kiosks?
Manual updates create two conflicting sources of truth for your inventory, which is a major operational risk. For example, a web customer could buy the last unit, but the kiosk would still show it as available because its local stock was not updated. Using Cin7 Core as the single master for the item record and syncing it to Cloudshelf is the correct way to manage stock across all channels.
Our SKUs often have leading zeros. Can this cause issues with the Cin7 Core sync?
Yes, this is a common data-related failure. Cin7 Core may treat the SKU as a number and strip the leading zeros, so a SKU like '00123' in Cloudshelf becomes '123' in the ERP. This mismatch breaks the SKU-to-SKU link, causing the inventory sync to fail for that product and creating inaccurate stock levels on the kiosk.