Skip to content

Configured Commerce Upgrade Watch: January 2026 (LTS)

lts 5.2.2512.412+lts Covers January 2026

Written by Lance Farquhar January 26, 2026

Release 5.2.2512.412+lts, published January 22, 2026. Each month we read what Optimizely says shipped, then go verify it against the actual source — frontend and backend — so you get more than a changelog recap.

This one's on the LTS (long-term support) track rather than the monthly STS track we usually cover here, which means it bundles roughly four months of accumulated hotfixes — spanning September 2025 through January 2026 — into a single rolling release instead of one month's worth of new features.

The 30-Second Version

  • Headline feature: The ODP integration's Order Status Mapping table gets a real extensibility point — a new ODPActionType column that replaces hardcoded status logic for anyone syncing orders to Optimizely Data Platform.
  • Worth knowing: IronPDF's rendering options changed to produce more consistent PDF output, and Optimizely flags it as a breaking change.
  • One more notable item: ~55 hotfixes are bundled into this batch, touching payments, checkout, search, VMI, and localization — this is what four months of an LTS branch accumulating fixes looks like.
  • Our verdict: overwhelmingly bug fixes and small extensibility additions, not new features — exactly what you'd expect from an LTS checkpoint, and every item we checked in source either matched the notes exactly or landed in a plausible, topically consistent set of files.

The Headline: ODP Order Status Mapping Gets a Real Extensibility Point

If you run the Optimizely Data Platform integration, order sync has always meant mapping ERP order statuses to two ODP actions — Purchase and Cancel — through logic baked into the export script itself. Adding a custom ERP status, or changing what a given status should mean to ODP, meant touching that hardcoded logic directly.

This release adds a column instead:

ODP order status mapping flow

The migration itself is a single, dated script:

ALTER TABLE [dbo].[OrderStatusMapping]
    ADD ODPActionType [nvarchar](50) NOT NULL CONSTRAINT [DF_OrderStatusMapping_ODPActionType] DEFAULT ('None');

The CustomerOrder.sql export script was rewritten around that column, and the two release-note bullets that describe this — "Updated the ODP Order Sync to support custom order statuses through Order Status Mapping" and "Added an ODP Action Type field to the Order Status Mapping table" — are the same underlying change described from two angles. Existing installs keep working with no configuration changes required: statuses that aren't explicitly mapped still fall through to the original hardcoded logic, so this is additive rather than a replacement of anything.

What Else Shipped

One breaking change to plan for: IronPDF's rendering options were updated to support more consistent PDF generation, and Optimizely lists this as a breaking change. If you generate PDFs — order confirmations, quotes, wishlists — through IronPDF, this is worth a direct render-and-compare check before you take the upgrade, since "more consistent" output can still mean a visual diff from what you have today.

Payments picked up several fixes: a TokenEx race condition, Spreedly no longer re-tokenizing a saved card on every transaction, the ability to customize SubmitTransactionResult with gateway-specific fields, and a BankCode field on CreditCardTransaction for Payment Service. The SubmitTransactionResult and BankCode changes are worth testing directly against a running instance — our source sample didn't turn up a clean write-path match for either.

Checkout fixes include two separate "Resource Forbidden" errors (one after guest checkout, one after an approver's session expires), a duplicate order ID issue on one-page checkout, and the ability to edit a pickup address mid-checkout.

Search gets Configured Commerce instance identifiers on Search v3 requests, a fix for index rebuilds failing when a website is unavailable, and a fix for autocomplete returning the wrong result on Enter.

VMI, ODP jobs, and content/localization round out the rest: the VMI bin handler now resolves product data through IProductService (more on that below), ODP export jobs gained optional StartDate/EndDate parameters and an optional LookBackDays, and a handful of content fixes landed — an infinite retry loop in TranslationDictionaryAsync, a duplicated language segment in URLs, and hydration errors during content parsing.

Dependency and infrastructure cleanup: Microsoft.ApplicationInsights and its related packages were added to the allow list, and the BouncyCastle transitive dependency issue was addressed by adding BouncyCastle.Cryptography, the modern successor package, to the allow list.

Everything else — the Shared With counter, the Assign Ship-To modal not refreshing, RSS feed variant-product handling, Spire's Hide Footer option also hiding the cookie policy window, Ask Opal not loading, and a dozen more targeted fixes — is routine hotfix material and checks out against the areas of code the notes describe.

What We Actually Found: The Cookie Function That Finally Does Its Job

Every post in this series, we go looking for something worth a closer look beyond "the notes match the code." This month it's a small one, but a satisfying one: server-side cookie handling.

The release note reads plainly enough — "Added setCookie and removeCookie functionality during server-side rendering." What that undersells is what the function was doing before. The old implementation didn't have a bug in its cookie logic; it didn't have cookie logic at all:

// Common/Cookies.ts
if (IS_SERVER_SIDE) {
    // if we do decide to support this and removeCookie ...
    Logger.error("setCookie is not currently supported during server side rendering.");
    return;
}

Any code path that called setCookie during server-side rendering hit this branch, logged an error, and returned — silently doing nothing. That's now replaced with real logic against getSessionCookies() and setSessionCookies(), so a call to setCookie or removeCookie during SSR actually sets or removes the cookie instead of quietly failing. If your storefront (or a customization) calls either function anywhere in a server-rendered code path, this release is the first time that call has ever actually worked.

Under the Hood

Two more confirmed items worth reading in full, both exact matches for what the release notes describe.

The VMI bin handler now resolves real product data instead of working around its absence. CreateGetVmiBinResults picked up a new constructor dependency and builds a product dictionary before attaching product data to each VMI bin result:

public sealed class CreateGetVmiBinResults(
    ICatalogPipeline catalogPipeline,
    Lazy<IProductService> productService
) : HandlerBase<GetVmiBinCollectionParameter, GetVmiBinCollectionResult>

The Lazy<IProductService> wrapper means the dependency is only resolved if a VMI bin result actually needs product data — no added cost on requests that don't touch this path.

The Sales Rep count fix is two added conditions, in exactly the right place. The bug was that a Sales Rep's available-bill-to count didn't check IsBillTo, so the count could include customers the sales rep wasn't actually authorized to bill to. The fix is precise:

.Count(o =>
    o.PrimarySalespersonId.HasValue
    && result.SalespersonIds.Contains(o.PrimarySalespersonId.Value)
    && o.IsBillTo
    && o.IsActive
);

Both IsBillTo and IsActive are now part of the predicate — the kind of single-purpose diff that's easy to verify is correct just by reading it.

What This Means for You

  • If you generate PDFs through IronPDF, render a sample of your actual documents — confirmations, quotes, wishlists — and compare against what you get today before rolling this out broadly.
  • If you run the ODP integration, you now have a real column-based way to map custom ERP order statuses to Purchase/Cancel actions instead of needing code changes for anything outside the hardcoded default logic.
  • If any of your customizations call setCookie or removeCookie during server-side rendering, check what you expected to happen — this is the first release where that call actually does something.
  • If you use custom SubmitTransactionResult fields or the BankCode field on Payment Service, test those directly; our source pass didn't turn up a clean confirming match for either.
  • Everything else in this batch — the checkout, search, VMI, and content fixes — is safe to take as documented; each one we checked landed in the file areas the notes describe.

Upgrading a Configured Commerce storefront and want a second set of eyes on what actually changed under a release before you take it? That's exactly the kind of review Nishtech does for clients every month — reach out and we'll walk through it with you.