What a Sana Commerce integration gives you.
Merchandisers and product teams see that Sana storefronts are fed from a single PIM source, and changes propagate without manual re-entry or duplication.
Wholesale orders arrive in ERP with full context, customer account validation already applied, and no re-keying or approval delays in the back office.
Customers see their contract price, tiered discounts and credit status correctly on every visit. Account team can trust that pricing rules from ERP flow through to storefront.
Stock changes in ERP or OMS flow to Sana without delay. Wholesale customers can plan around availability without discovering stock outs at checkout.
Credit holds, payment-term changes and account status updates from ERP reach Sana fast enough to prevent checkout failures or stale customer data.
Where a Sana Commerce 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.
Sana supports customer account structures, but ERP master-data rules, delegation hierarchies and approval workflows often need custom logic. Generic integration cannot handle multi-level account governance without configuration.
Sana can display pricing from external sources, but ERP-owned tiered pricing, volume discounts and contract terms often require mapping logic. Price calculation rules need to be explicit.
Sana shows available stock, but allocation across online, B2B, wholesale and physical channels often lives in OMS or ERP. Oversell prevention and channel rules need separate governance.
Sana can route orders, but complex approval chains, cost-centre validation and delegated authority often live in ERP procurement or OMS. Integration needs to enforce upstream rules.
Sana handles multiple currencies and markets, but regional cost price, tax and promotional rules often belong to ERP. Currency conversion and regional logic need separate design.
The integration boundary between Sana and ERP is often unclear until ownership of customer accounts, credit validation and order capture is named explicitly.
Where this integration sits in your estate.
Sana Commerce is the commerce platform - the customer-facing experience, catalogue, checkout and account area. The iWeb integration layer wires it into the ERP, PIM, OMS, WMS and payments systems it depends on. The estate map helps agree ownership before anything is built.
Sits at the front of your estate. We wire Sana Commerce into the finance, stock and product systems it depends on.
- Storefront experience and merchandising presentation
- Customer portal and account visibility
- Basket, checkout and order submission
- Sana-specific customer session and preferences
- Product data flow from PIM to storefronts
- Stock availability and pricing publication from ERP
- Order validation against ERP account rules
- Customer account master and credit governance from ERP
- Dispatch, invoicing and status visibility back to customers
Systems this integration usually sits next to.
Examples, not a closed list. iWeb wires Sana Commerce into whatever ERP, PIM, OMS, WMS, payments and operational systems your estate already runs.
- SAP, NetSuite, Sage, Microsoft Dynamics or other ERP
- Salsify, Informatica or other PIM
- Blue Yonder, Manhattan or other OMS
- NetSuite WMS or warehouse management system
- Elasticsearch or other search platform
- Stripe, Adyen or other payment processor
- Klaviyo or Salesforce for CRM and marketing
- Business intelligence and reporting warehouse
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 ERP and PIM ownership
iWeb defines which product attributes, pricing, stock and account rules live in ERP, which live in PIM, and how Sana consumes each as a governed feed.
- 02Design order capture flow
iWeb works out how orders move from Sana into ERP with full context, how customer credit and approval rules are validated, and how exceptions are surfaced.
- 03Build pricing and tiering logic
iWeb implements customer-specific pricing, volume discounts, contract terms and regional rules so Sana shows the right price for every account and channel.
- 04Set up stock synchronisation
iWeb chooses the right sync frequency and fallback logic so stock on Sana stays fresh without creating oversell risk or transaction load on ERP.
- 05Implement account governance
iWeb handles customer master sync, credit-limit updates, payment-term changes and account hierarchy so Sana and ERP stay in step and checkout respects ERP rules.
- 06Run live monitoring and support
iWeb sets up observability, exception alerting and playbooks so order capture, pricing publishes, stock syncs and account changes can be owned operationally.
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 Sana integrations alongside ERP, PIM and OMS platforms. We understand the patterns for product data, stock, pricing and order flows in B2B and wholesale commerce, and how to keep Sana and the back office in step.
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 stock sync is infrequent or falls silent, Sana shows available quantities that no longer match ERP. Wholesale customers over-order and orders fail validation at ERP receipt.
If order flow from Sana to ERP has no monitoring, orders can queue invisibly, customers see no confirmation, and back-office teams do not know orders are waiting.
If tiered pricing, contract pricing or promotional pricing breaks during a sync or rule change, customers see stale or incorrect prices and may reject orders at checkout.
If credit limits, payment terms or account status changes from ERP do not reach Sana fast enough, customers experience checkout failures or can place orders they should not be able to.
If Sana and PIM drift (missing attributes, outdated descriptions, wrong images), customers on Sana see incomplete or incorrect product information and merchandisers cannot trust storefronts.
If Sana depends on real-time ERP calls for stock or pricing and ERP experiences downtime, Sana checkout fails or shows stale data with no graceful degradation.
Relevant services and sectors.
Common questions about Sana Commerce integrations.
How does product data flow from PIM to Sana storefronts?
iWeb sets up a scheduled feed or API push from PIM into Sana. Product attributes, descriptions, images and category assignments flow at a cadence the merchandising team can control. Sana receives complete, tested product records ready for customer view.
Where does stock come from and how often does Sana see updates?
Stock is owned in ERP or WMS. iWeb determines the sync frequency based on the business model and stock volatility. Real-time sync, hourly, or daily batches are all valid depending on customer expectations and transaction load. iWeb also designs fallback behaviour when source systems are unavailable.
How does customer-specific pricing get published to Sana?
ERP owns the tiered pricing, contract pricing and promotional pricing rules. iWeb maps customer account attributes from ERP to pricing tiers in Sana so each customer sees their correct price. Price changes flow as ERP pricing rules are updated.
What happens to orders when they arrive in Sana?
Sana validates the order against ERP customer account rules (credit limit, approval authority, payment terms, blocked accounts). If validation passes, the order is sent to ERP or OMS for fulfillment and invoicing. If validation fails, Sana rejects or queues the order for manual review.
How are credit limits and payment-term changes enforced?
ERP owns customer account master data, including credit limits and payment terms. iWeb syncs these to Sana at regular intervals. When a customer checks out, Sana validates the order value against their current credit limit. If credit holds change in ERP, those changes flow to Sana so checkout respects the latest rules.
What happens if ERP or stock source is unavailable?
iWeb designs explicit fallback behaviour. Options include serving cached stock, displaying a warning, queuing the order, or disabling checkout entirely depending on business risk. The choice is made before launch and monitored operationally.
How do we prevent overselling across channels?
If Sana is one of multiple sales channels (physical stores, B2B, marketplace), stock allocation is owned in ERP or OMS. iWeb designs the reservation flow so stock committed to Sana is not sold through other channels. This may involve real-time reservation or interval-based allocation depending on the business model.
Can order approval workflows live in Sana or do they need ERP?
Sana has basic order-routing capabilities, but complex approval workflows (cost-centre validation, delegated authority, multi-level sign-off) usually belong in ERP or OMS. iWeb designs which rules live where and ensures Sana enforces upstream approvals before order handoff.
How do we monitor that orders are being captured correctly?
iWeb sets up observability on the order-capture flow: how many orders arrived in Sana, how many were sent to ERP, how many failed validation, what exceptions are waiting. Alerts surface silent failures so the order-management team can intervene.
What happens during a Sana or ERP upgrade?
iWeb documents the integration so upgrades do not break data flows. Critical areas include order capture, stock sync, pricing logic and customer account validation. Testing before launch covers upgrade scenarios so the team can upgrade independently.
How do we handle multi-currency or regional pricing?
iWeb designs currency and regional logic as part of the pricing feed. ERP pricing rules may be currency or region-specific. Sana displays the correct price based on customer location or selection. FX rates and regional markups are managed in ERP and flowed to Sana as attributes or overrides.
Who owns the integration and what is their role day-to-day?
iWeb names an integration owner before launch. They own monitoring dashboards, exception queues, sync schedules and incident response. They escalate to merchandising, finance, operations and customer service teams when data quality or sync issues arise.
Can Sana be the source of product images or does PIM own them?
PIM owns the master product images and is the source of truth for governance, brand compliance and variant photography. Sana can display images, but iWeb ensures all images originate from PIM and Sana does not become a shadow source that diverges over time.
How do dispatch confirmations and invoices get back to customers?
Once an order is in ERP or OMS, dispatch, tracking and invoice data flow back to Sana. Sana shows order status, tracking links and invoice documents in the customer portal. iWeb designs the data flow so customers on Sana see the same visibility as any other channel.
Other commerce platforms integrations.
Adjacent integrations in the same category. Same shape of work, different vendor.
Projects with a similar shape.
A home department store replatform built around catalogue depth, product data and connected ERP fulfilment.
Home retail trading supported by Adobe Commerce, Akeneo PIM and Microsoft Dynamics ERP integration.
A sports equipment PIM project built around product data, launch speed and catalogue accuracy.
Product launches supported by cleaner data, better completeness and less manual product work.
A classic VW and Porsche parts platform built around stock, localisation and fulfilment.
Classic vehicle parts trading supported by localisation, stock visibility and fulfilment control.