Sana Commerce on Business Central, past the brochure.

Every page you have read opens with the same claim: real time, no synchronisation, no middleware. It is accurate for the order side and it is not the whole picture for the catalogue, and Sana's own administration guide is where you find that out.

Sana publishes a default cache table for ERP data. The cached data is, in Sana's words, "product details, prices and stock". Product details, product lists, bulk product data, the basket and order history each default to twenty minutes. The site menu defaults to sixty.

Separately, the storefront catalogue is not read from the ERP at all. It is built by a scheduled product import task that maintains an index, and Sana states that "Webstore search functionality, sorting and filtering of products, phonetic search and product sets configuration depends on the product information that is indexed."

So the accurate model is this. Customer-specific pricing, taxes, charges, credit and order validation are calculated live in Business Central at basket and checkout time. Everything you browse, search and filter is an index refreshed on a schedule. Both halves matter, and only one of them is on the brochure.

Sana is candid about why, which is the part worth quoting in full because it tells you what kind of decision you are making: "Performance of your application will drop when the duration is set less. This is because the amount of calls to your ERP system will increase, which is much slower then retrieving the cache." The spelling is theirs.

That reframes the question for your project. It is not whether the integration is real time. It is how fresh your stock and price display needs to be, because that is a dial with a documented performance cost on the other end. If you sell scarce inventory where a twenty-minute-old stock figure causes a real problem, that is a conversation to have before contract, not during user acceptance testing.

Sana Commerce Cloud is described as SaaS that updates itself, and separately described as customisable. Sana's own documentation says those are alternatives rather than companions: "Customizing Sana Commerce Cloud using the SDK means abandoning SaaS and thus no automatic upgrades."

The line falls at where the work happens. Sana states that "custom projects cannot be automatically updated to a newer Sana version because customizations are done in the Sana core code", and that "If all customizations can be done using the extension points of Sana, you can still receive updates automatically."

Which makes one question the most consequential in any Sana scoping conversation, and it should be asked of every requirement on the list:

• You move to a long-term-support branch that does not receive automatic updates.
• You start a support clock. Sana actively supports a framework version for three years from release, then passively for two more, with passive support limited to showstopper hotfixes and, in Sana's words, "always on time and material".
• You lose self-service administration. On customised projects, users "need to contact their Sana Commerce representative" to install an app that a standard customer installs themselves in Sana Admin.

Sana documents no return path from a customised project back to the standard track. We are not aware of one, and we would want that in writing before anyone signs.

You do not own either release calendar, and there are more of them than most projects plan for.

• The Sana framework ships roughly every two weeks, with rollout taking up to two weeks after the release date. You do not schedule that.
• The Sana ERP connector ships on its own roughly quarterly train.
• Sana apps version separately again.
• Microsoft ships a Business Central major update every April and October, and force-advances the installed extension. There is no setting that pins an AppSource app through a major wave.

Sana ships a Compatibility Level setting inside Business Central specifically to absorb the mismatch between its connector and the Microsoft version underneath, which tells you the drift is expected rather than exceptional.

There is also a contractual obligation that does not usually come up at sales time, and is worth reading in full: "All standard Sana Commerce Cloud customers have the obligation in their license agreement to update the Sana ERP connector at least every two years." Sana documents no consequence for non-compliance anywhere we can find, so we will not invent one. But it is an obligation you are signing, and it exists because the unsupported direction is an old connector against a newer framework.

One correction to something you may have read, including an earlier draft of our own thinking. A Microsoft-forced Business Central update does not push a Cloud customer into an unsupported state. There is a carve-out for Business Central Cloud, and the two-year connector obligation is the mechanism that prevents the failure people worry about. The genuine operational facts are narrower and still worth planning for: a successfully applied wave cannot be rolled back, extensions that block an enforced update can be uninstalled automatically, and realistic rehearsal against your own data does not start until general availability unless your partner holds a Partner Sandbox licence, which does grant early access.

AppSource availability reads as self-service. The extension by itself does nothing: a working system needs a separately contracted Sana environment, and on Business Central on-premises the extension cannot be obtained without a Sana partner at all.

What it does land in your tenant is worth knowing before the Business Central administrator finds out from a ticket.

• Permission sets have to be granted to people who never touch the webshop. Sana adds custom fields to the Item table, and without the permission set those fields stop finance and warehouse staff editing items. That is a tenant-wide rollout landing on your BC administrator, not on the ecommerce project.
• Products can be missing from the site with no error anywhere. Items and customers containing characters Sana disallows are excluded silently. They are visible only in two Business Central overview windows, which nobody checks unless they know to.
• The detection for that has a performance cost. Sana's automatic indexability checks "can significantly impact performance, especially when there is a large number of items", and frequent item master updates "may cause session locks". Sana's own remedy is to disable the checks, which means choosing between an ERP performance problem and losing the detection of silently excluded products.
• Order lines Sana does not recognise are ignored rather than blocked. That includes G/L Account lines, which is ordinary Business Central practice for freight and surcharges. If the total on the website has to match the total in BC without manual reconciliation, prove this out before contract.

None of these are defects. They are all documented. They are simply on a different page from the one the buying decision gets made on.

Two things gate functionality in ways that surface mid-project rather than during evaluation.

The edition. Sana's own Business Central documentation marks a list of capabilities Unavailable on the entry edition: B2B customer registration, Represent a Customer (a sales agent ordering on behalf of a customer), return orders, blanket sales orders, prospects, and showing stock in the webshop. Sales agent settings under order processing strategies are available on the higher tiers only. It is entirely possible to be quoted a plan that cannot do the thing you are buying a B2B storefront for, so map your requirement list against the edition before the commercial conversation closes.

We are not publishing tier pricing or plan comparisons here, because Sana publishes plan names without list pricing and the tier table is a rendered marketing page we could not read reliably enough to quote. Ask Sana for the feature availability matrix in writing.

The order processing strategy. There is a mode built for high line-count baskets, and it is the one a distributor typically needs. Under it, Sana does not support sales agreements, quote-to-order conversion, order editing (the edit button disappears), mix and match discounts, extended texts on order lines, bill of materials explosion, or coupons on Business Central.

That is a genuine fork rather than a tuning option. If your workflow needs both large baskets and anything on that list, the platform makes you choose, and it is much cheaper to discover that in scoping than in user acceptance testing.

"Your ERP is the single source of truth" is sold as a benefit, and it is one. It is also a governance constraint, and Sana states it plainly on the subject where it bites hardest: "All taxes must be configured in ERP. Sana Commerce Cloud has no influence on tax calculation as it all done by ERP." Sana can change how tax is presented in the cart, and nothing else.

Generalise that and you have the most reliable predictor of scope surprise on a Sana Business Central project:

The same line runs through support. Sana's service agreement targets a one business day fix for showstoppers, and states that "Sana Commerce cannot guarantee a 1 business day fix time for show stoppers caused by 3rd parties (ERP, PSP, etc.)". On an architecture whose defining feature is that the ERP serves the storefront, the most likely class of severe incident is the class with no guaranteed fix time. That is not a criticism of the SLA. It is a reason to budget for a Business Central partner alongside the ecommerce budget rather than after it.

If your ERP data or pricing setup is untidy, the site inherits it, and the fix is a Business Central project. We have written separately about cleaning the customer master before a replatform, and on this architecture that work is not optional preparation, it is the storefront.

This is the part we get asked about most, because it is where a design brief meets a product boundary. We build storefronts, so we would rather set the expectation early than discover it at design sign-off.

The theme editor works in tokens: logo, favicon, background, header and footer colours, element colours, fonts, placeholder images. Beyond that you are into HTML injections, which Sana does not support and disclaims responsibility for, and which are constrained further when server-side rendering is disabled, a switch standard projects do not control. The product detail page ships with two layouts, and choosing the variant matrix drops the write-a-review element.

If the visual brief is cosmetic, the theme editor is genuinely fine and quick. If it is structural, you are looking at the SDK route, and the section above on the customization fork is the one that matters.

On headless, Sana's own architecture note is unusually direct about what you are taking on: Sana "will not be able to provide support for your custom storefront (web store)", it "might be very expensive in terms of money and time", "your project becomes custom", and you "may miss out on the benefits of the standard Sana Commerce Cloud product, including regular updates". There is also no public first-party storefront API reference to evaluate before committing, so ask Sana for it directly rather than assuming it will be there.

One observation from enumerating Sana's public documentation, offered as an observation rather than as a Sana statement: Sana publishes consolidated Limitations pages for SAP Business One, Dynamics GP, AX Retail and D365 Commerce, and Supported ERP Versions pages for several ERPs. Neither exists for Business Central. That absence is most of the reason this page is worth writing.

Every item here traces to something Sana documents. Most are solvable with a different plan, a different scope, or a different order of work, so read them as fit conditions rather than as reasons not to buy. We build on Sana, and we would still rather you find these now.

• You need B2B basics and you are being quoted the entry edition. See above. The gap between what the edition includes and what a B2B buyer assumes is the product is the single most common commercial surprise.
• You need large baskets and order editing, quotes or promotions. The large-order mode and that feature set are mutually exclusive.
• Your commercial rules need to differ online from what Business Central does. Tax is the documented case and the general rule follows.
• Your catalogue depends on merchandising content the ERP cannot hold. Rich descriptions, imagery, video, marketing attributes. That means a second master system in the architecture, and product information management is a plan or add-on decision rather than something included by default. We have written on when you actually need a PIM.
• You need a design-led storefront. If the brief is structural rather than cosmetic, price the SDK route and read the fork section first.
• You want a headless front end. If it is a requirement rather than a preference, this is not the platform to buy it on.
• You have hosting, residency or network-isolation requirements. Self-hosting, virtual private clouds and the Sana upgrade toolkit were all withdrawn in the move to Sana Commerce Cloud.
• Your change control cannot accept vendor-scheduled updates. No setting pins an AppSource app through a major wave, a successfully applied wave cannot be rolled back, and rehearsal timing depends on your partner's licence.
• You run a large legacy catalogue with a busy item master. The indexability checks and session locks above make this a real trade-off rather than a tuning exercise.
• Your sales orders routinely carry freight, fee or surcharge lines from other add-ons. Unsupported line types are ignored rather than blocked.
• You are on Business Central on-premises and want to control your own procurement. The extension is downloadable only by registered Sana partners, deployed by manual PowerShell, with compatibility information behind a partner login you cannot audit.
• You are still on Sana 9.3. There is no upgrade toolkit for the move to Sana Commerce Cloud, which makes it a re-implementation rather than an upgrade. That is a different conversation from the renewal you may think you are having, and we cover the support side on Sana 9.3 support.