Reads and writes
don't take the same road.
From the data lake to read. Through the APIs to write.
Microsoft Dynamics exposes its data on a data lake: that is where we read from. Writes go the other way - straight out, through the APIs. It is not a complication: they are two roads because they do two different jobs, reading has to carry volume without leaning on the ERP, writing has to arrive at once.
What moves, and which way.
The technical question isn't which protocol. It is who owns the truth: for every piece of data you decide once, and you write it down in the mapping before writing any code. With Dynamics, Dynamics owns everything that gets read; the only thing born outside is the order.
- Items and variantsfrom Dynamics
- The season catalogue with sizes, colours and attributes, recomposed into a shape a B2B platform can build a grid on.
- Price lists and termsfrom Dynamics
- Per-client prices, tiers, currencies, terms. They stay configured in Dynamics; outside they get applied, not reinvented.
- Stock and warehousefrom Dynamics
- Availability and movements. They come from the lake, so they carry the age of the last run - and the project is designed knowing that, rather than pretending they are current.
- Customer recordsfrom Dynamics
- Codes, terms, holds. A customer is not created outside Dynamics: it is read, so there are never two versions of the same company.
- Ordersinto Dynamics
- The only thing born outside. An order taken in the showroom or by the client is written into Dynamics through the APIs, synchronously: the long road would be wrong here, because whoever just confirmed it wants to see it land.
These are the flows we have already put into production: examples, not a catalogue. In principle anything held in Dynamics can be read; whatever has to get into Dynamics is decided case by case, and that is one of the things the mapping puts in writing before anyone starts.
Two roads, because they do two different jobs.
- // data lake
To read, from the lake
Dynamics exposes its data on a data lake, and we read from there. Two benefits you feel: the volume never goes through the ERP, so no heavy read slows it down while the company is working in it; and you take data in bulk instead of the thousands of single-record calls it would otherwise cost. There is one cost, and it should be said out loud: the data carries the age of the last run.
- // apis
To write, the direct road
An order cannot wait for a pipeline run: whoever just confirmed it has to see it arrive. Writes therefore go out through the APIs, synchronously, and that is the only road that changes Dynamics - which is why the list of what may be written lives in the mapping rather than in a blanket permission.
Writes are designed to be repeatable without harm: if the network drops halfway, the order doesn't land in Dynamics twice. And every call stays in the log - when someone asks why that order came through the way it did, the answer is a record and not a reconstruction from memory.
Data half an hour old is not a problem. Data pretending to be current is.
Data has an age. Better to declare it.
When reads travel down a pipeline, the temptation is to say nothing and let everyone assume it is all real time. That is the choice you pay for on the day a sales rep sells a size that is gone. Better the opposite: you declare how often it runs, whoever reads it knows, and the decisions that cannot tolerate a delay go another way.
- // freshness
The age of the data is written down
Every flow has a known refresh, and whoever consumes it can see it. Data that is a declared half-hour old is usable; data that looks current and isn't, is not.
- // permissions
Per-role permissions
Who reads and who writes what is decided outside Dynamics. The platform sees items, price lists and stock, not costs; an AI agent sees what it was granted and nothing else.
- // log
A log of every call
Both the API writes and the pipeline runs stay written down. It earns its keep on the day an order arrived looking odd and someone needs to know what data it was built from.
- // no-copies
What we read is not a second truth
The data coming off the lake is a working copy, declared as one: you read from it so as not to weigh on the ERP, but the truth stays in Dynamics. If the two diverge, Dynamics is right - and that is written down, not implied.
We are not Microsoft resellers and we take no commission on licences: we connect to Dynamics the way we'd connect to any other system. If the problem is connecting it to other systems, the logic is the middleware one; if it is making its data readable and cross-referenceable, it is the data layer one. And if you work in fashion B2B, the sector page tells the year all of this runs around.
A real project, not a diagram.
The European arm of a global sportswear brand had just adopted Dynamics as its ERP. The wholesale platform we built on top of it - pre-order, stock orders, carryover and multi-season price lists - reads items, price lists and stock from its data lake and writes orders back through the APIs, and it went into production shortly after the ERP rather than waiting for it to settle.
The questions we always get.
Is stock real time?
No, and anyone telling you otherwise with this architecture is not telling you everything. Coming down through the data lake, availability carries the age of the last run: you declare what that is, and the platform shows it for what it is. If one specific figure genuinely has to be instant, it takes another road, and that gets decided in the mapping - not at go-live.
Why go through a data lake instead of reading from Dynamics?
For two practical reasons. The volume never passes through the ERP, so no heavy read slows it down while the company is working in it; and data comes in bulk instead of thousands of single-record calls. The price is latency, and it is a price you can pay knowingly.
And where does the lake data end up?
It depends on the project, and it gets decided in the mapping. The layer can query the lake directly; in one case we landed the data on a SQL Server, because there it needed querying in SQL with tools the client already had. It is an option, not a required step: it is one more piece to maintain, so it gets added when it genuinely helps.
Are you a Microsoft partner or reseller?
No, and we take no commission on licences. We connect to Dynamics the way we'd connect to any other system. That is the whole advantage for you: when we say something isn't worth doing, we aren't defending a margin.
What if we change ERP later?
The connector to Dynamics changes - the pipeline on one side and the calls on the other - not the platform sitting on top. That is why the point in the middle exists. And the code is yours either way.