An order for insulin is not a row in a system. It can end up on a hospital ward, in someone’s kitchen, or in temporary accommodation — and the person ordering is almost never the one receiving. When ExFlow Sales Order shipped in January 2024, that was the business I designed the flow for.
I designed the whole flow: how an order is received, what gets checked before it becomes an order, when a human has to answer, and how it leaves the building as a delivery and an invoice. The starting point was not a demo. It was a medical supplier whose products keep people alive, delivering to hospitals, private homes and temporary accommodation.
The case
A standard sales order flow assumes the buyer and the recipient are the same person, at a fixed address, on a planned delivery date. For life-critical diabetes medicine that assumption does not hold.
The region or the hospital buys. The patient, the home-care service or a temporary accommodation receives. The address can change late in the process, and a misaddressed or delayed delivery is not an annoyance — it is a healthcare problem. At the same time the price has to match the right agreement, and nobody may promise a delivery the warehouse cannot pick.
Three things shaped the design: the recipient is not the buyer, the exception is the normal case, and an order you cannot follow is an order you do not have.
What it solves
- Every order into one queue. EDI from regions, email with PDFs and whatever arrives by phone land in the same list with the same status. No order lives only in someone’s inbox.
- Validation before the order becomes an order. Customer agreement and price, item, quantity and delivery address are checked on receipt. What matches moves on; what deviates goes to a human — with the reason written out, not silently onwards.
- Approval that escalates. An order that needs approval routes to the right person and moves up the chain if nobody answers. Life-critical medicine must not sit still because someone is on holiday.
- Recipient per order, not per customer. The delivery address belongs to the order: hospital ward, private home or temporary accommodation. Straight from stock to the recipient, with no layover.
- A promise against real stock. A date is only given if the warehouse can pick it. Otherwise it shows now instead of three days later.
- One flow all the way. Pick, delivery, invoice and credit are linked. No line is entered twice, and no step depends on someone remembering a phone call.
- Traceability. Who changed what, and when. In a business where a wrong delivery is a patient-safety matter, that is not compliance theatre — it is the point.
The other customer: a manufacturer of precision rifle triggers
TriggerTech in Canada makes triggers for bolt-action rifles, AR platforms and crossbows, and sells them worldwide. There the problem was different: orders arrived in many different shapes and landed with different people, and stitching them together took twelve hours a week.
The same solution — every order into one flow — took that work from twelve hours a week to one. Not because anyone worked faster, but because there was no longer anything to go looking for.
Why the flow looks the way it does
Three rules drove the work more than any interface did.
The recipient is not the buyer. The address and the recipient belong to the order, not to the customer record. It sounds like a detail until you notice how many systems are built on the opposite.
The exception is the normal case. In this business it is ordinary for something not to match: a changed address, a price that doesn’t align with the agreement, an order that has to go out today. So I designed the exceptions first and the happy path last.
Status has to be true. An order that looks like it is on its way, but isn’t, is worse than no status at all. Every step should be trustworthy without a phone call to confirm.
None of this is sophisticated. Most of the work was choosing steps to leave out, not adding them.
Who stands behind it
ExFlow was built by SignUp Software in Solna, Sweden — founded in 1999, ExFlow launched in 2003 — and the sales order part is one piece of that portfolio for Microsoft Dynamics 365 Business Central. In 2026 the company renamed itself Truvio, after gathering four Microsoft ISVs into one portfolio: ExFlow (AP automation, data capture, e-invoicing, sales order), Axtension (production, projects, shipping), SKsoft (banking and treasury) and DynamicWeb (commerce and PIM).
All of it is built inside Dynamics 365 F&O and Business Central rather than on top of it, and Truvio describes its mission as closing the “ERP Value Gap”: the distance between what the ERP can do and what the business actually gets out of it. On top of the portfolio sits agentic AI under the name TruvioSense. Sales order is a small part of a large portfolio. It is the part I designed.
If your business has an order flow still held together by email, phone calls and a spreadsheet — where the recipient never quite matches the customer record — that is exactly what I build. The consulting page says what I do; email [email protected] with the flow you are still patching up.