Where should each type of data live?
Business Central needed to remain authoritative for core commercial data while Sana handled web-specific presentation and merchandising.
← Selected work
01 / B2B E-COMMERCE
Rebuilding digital commerce around complex customer logic.
A B2B commerce ecosystem connecting ERP data, customer-specific pricing, procurement platforms, content, and the web experience.
ERP / Source DataBusiness Central
Products · customers · assortments
ProcurementAriba + Coupa
Enterprise punchout
Commerce PlatformSana Commerce
Storefront · content · customer experience
MarketingHubSpot
Content · forms · conversion
InfrastructureCloudflare
Domains · routing · delivery
Simplified view of the systems shaping the customer experience.
01 / The situation
The storefront was only one layer of a much larger system.
What a customer could see, purchase, and pay depended on a network of customer accounts, company groups, product assortments, ERP data, storefront data, and procurement relationships.
A request that looked simple from the website could have dependencies several systems upstream. Customer identity could influence branding and pricing. Business Central controlled core customer and product rules, while Sana translated those rules into the storefront and maintained web-specific merchandising data.
Enterprise buyers could also enter through procurement platforms such as Ariba and Coupa rather than through the traditional storefront.
The challenge was not simply improving an ecommerce site. It was understanding where data lived, how each system affected the next, and how to improve the customer experience without breaking the commercial logic underneath it.
↓ View Work02 / Customer logic
One login could trigger an entire chain of business rules.
I treated personalization as a dependency chain rather than a visual feature.
01User login
→02Company group
→03Assortment
→04Visibility
→05Price + experience
A signed-in user could be associated with a particular company group, which influenced the branded storefront and pricing they received. Business Central separately controlled customer assortment and whether individual items were eligible for the webstore.
Understanding that chain changed how I wrote requirements. Before asking development to change the interface, I could first determine whether the actual issue belonged to UX, storefront configuration, synchronization, master data, or ERP logic.
03 / Product decisions
The hardest decisions were about ownership and dependencies.
Three questions shaped much of the work.
How should customer-specific commerce behave?
Pricing, product access, company relationships, and storefront presentation had to resolve into one coherent experience.
How do we improve UX without breaking business rules?
Changes had to account for synchronization, cached data, customer assignments, assortment logic, and alternate procurement paths.
04 / My role
I worked between the business, the experience, and the technical system underneath both.
Turn business needs into decisions.
Defined requirements, evaluated tradeoffs, prioritized work, and translated broad requests into executable product decisions.
Understand the dependency chain.
Mapped relationships between Business Central, Sana, procurement platforms, customer records, and synchronization.
Coordinate execution across teams.
Led work across development, product staff, operations, internal stakeholders, and external platform partners.
Keep the customer visible inside the system.
Improved navigation, content, product discovery, and customer journeys while respecting the underlying commerce rules.
05 / The work
The work moved constantly between interface and infrastructure.
123Customer-specific commerce
Designing around the customer relationship, not just the catalog.
What appeared to be a standard storefront was actually the result of customer, pricing, assortment, and product rules resolving across multiple systems.
ERP / SOURCE OF TRUTH
Business Central
Customer recordsItem dataPricingCustomer assortmentsWebstore visibility
→SyncERP data cached into Sana←
COMMERCE / EXPERIENCE
Sana Commerce
Web titlesDescriptionsProduct imageryCategories + facetsStorefront presentation
Important dependency
Product synchronization could overwrite Sana-managed merchandising data, so defining system ownership was part of the product decision.
Master data
Defining the boundary between ERP data and web merchandising.
Business Central and Sana both held information that ultimately shaped the storefront, but they served different purposes.
Core commercial rules belonged upstream, while Sana gave the team more control over web-specific content and presentation. The challenge was knowing which system should own each field — and what a synchronization could change downstream.
Enterprise procurement
Supporting customers whose buying journey started somewhere else.
Not every customer entered through the public storefront. Enterprise buyers could begin inside procurement platforms such as Ariba or Coupa and access the catalog through a punchout connection.
That meant the commerce experience had to work as part of a larger purchasing workflow — not simply as a standalone ecommerce website.
Simplified enterprise buying path
01Ariba / Coupa
Buyer begins inside 3rd party procurement
→Punchout
02Sana Commerce
Customer-specific catalog experience
→Selection
03Purchasing workflow
Cart returns to enterprise process
Commerce dependencies
Business CentralProducts · customers · pricing · operational data
Simplified flow. Exact approval and order routing can vary by customer procurement configuration.
06 / Outcome
A commerce model built to support more than a standard online store.
ERP and storefront rules jointly determined customer access, products, and pricing.
Direct ecommerce operated alongside enterprise procurement through punchout integrations.
Company relationships could influence branding, assortment, pricing, and purchasing behavior.
07 / Reflection
What this changed about how I manage products
A UX problem is often a systems problem wearing a nicer shirt.
This work changed the way I approach product decisions. A request that appears to be a simple interface change may actually depend on data ownership, synchronization, customer relationships, integrations, or an upstream business rule.
I learned to map those dependencies before choosing the solution. That helps me ask better questions, give technical teams clearer requirements, identify risk earlier, and still keep the customer experience at the center of the decision.