Retail software, and AI agents that never see a card number.

We'd design the rules in before the agent is built. An assistant that answers "where's my order" or proposes a refund works under its own identity and Unity Catalog permissions, never sees a card number, reads the consent field before anything goes to marketing, and has every action it proposes checked against policy and recorded, in testing as in production.

How a refund check works is in the Field Guide's chapter on governed actions, and it's the pattern our AI agent services build on.

Yes, and often we are the ones implementing it. The warehouse work at /case-studies/funko was built on Dynamics 365 Business Central with Azure Data Factory moving data around it, and the AmTab modernisation at /case-studies/amtab sat on Dynamics 365 and Power Automate.

Where the ERP already exists, integration with the system of record is the first design constraint rather than a later phase.

If every question is answered by the ERP and the store platform, reports on those are enough. Once stock, orders and customers have to be joined across channels, or a forecast needs years of history, we'd put them on Databricks under one definition each.

Funko's warehouse system and AmTab's store-to-ERP integration both run on Business Central, so we know the records that would feed it.

With what is actually running rather than what the documentation claims: which processes are manual, where throughput is lost, and which integrations are load bearing. AmTab came to us when pandemic demand outgrew an order process run on paper and spreadsheets, and the sequencing mattered more than the rewrite.

Yes, though the scope shrinks. A hosted payment form keeps the card number off your servers, and for merchants who qualify for SAQ A, the PCI Security Standards Council took requirements 6.4.3 and 11.6.1 on payment-page scripts out of scope; those merchants can rely on their payment provider's confirmation that the scripts are protected instead.

The rest of the standard still applies to a retail site, and the page that loads the form is still yours. We'd list the scripts that load next to the payment form and who added each, and ask marketing what each is for before removing any, since some of them carry order tracking.

Shopify where the catalogue and the pricing fit it, because paying to rebuild what it already does well is money spent twice.

B2B is where it strains, once each customer has its own prices and entitlements and a quote has to turn into an order. We'd tell you which side of that line you're on before you commit, and the longer answer is at /software/ecommerce.

Ship within the time you state, or within 30 days if you state none, and when you can't, offer the buyer a choice between the delay and a refund.

A seller without records showing its systems ship on time is presumed to have had no reasonable basis for the promise. We'd hold one promise date per order line, computed from stock across every channel, and log each change to it, so the records exist before anyone asks for them.

Yes, once the order history is governed. We'd land orders from every channel under one definition of a sale, build the forecast on those tables with the model and its runs tracked in MLflow, and feed it into the replenishment report the buyers already read, so the forecast and the ERP never argue about what was sold.