When there is no app for it, we build it.
Built to order means the engineering exists and we build it for you — on your own Power Platform, Dataverse and Azure, through the integration points Microsoft supports, without modifying the ERP core.
Your implementation partner keeps running your ERP. We build what sits beside it.
Five status words, never blurred
Shipped
Running for a customer today.
Built, demonstrated on request
Shown live against your own data.
Built to order
The engineering exists; no packaged app yet.
In development / Blueprint
Named as roadmap, or still a drawing.
Custom Power Apps, mobile and field
Built on your own governed stack.
Dataverse-native, your tenant
You keep ownership of code and data.
Integrated where you already run it
Fabric and Copilot Studio, when present.
Between a packaged app and a core modification
Most operational problems fall into a gap. There is no app on AppSource that does the thing, and the only route anybody offers is a change to the ERP itself — which is how estates end up with fields nobody can explain and upgrades nobody looks forward to.
The third option is to build it outside the ERP, on the platform Microsoft already gives you, reading and writing through documented integration points. The ERP stays standard. The capability is yours, and so is the code.
The honest version
Not everything we can build is something we have already built.
So the table below says which is which — shipped, built to order, or still only a blueprint. It is the question a sceptical buyer asks third, and it deserves a direct answer.
Five status words, and we do not blur them
“We can build that” is an easy sentence to write. What is worth knowing is which things already exist, which we build for you, and which are still a drawing.
| Status | What it means | Where it applies today |
|---|---|---|
| Shipped | Running for a customer today | Contract review, as Paralegent AI |
| Built, demonstrated on request | The software exists and is shown live against your own data | Pricing · pick-path and slotting · demand and inventory |
| Built to order | We have the engineering and build it for you; there is no packaged app yet | Reconciliation · mobile field apps · warehouse mapping · IoT and asset tracking · the ERP-side document build |
| In development | Being built now, named as roadmap | MCP server and Copilot extension |
| Blueprint | Architecture designed, nothing built | Supply-chain risk · the F&O planning-operations set |
If a capability moves up a level we change the word, not the emphasis. The full packaged family is on the optimizers page.
What gets built to order?
Six areas where the engineering exists and the packaged app does not.
Financial reconciliation
Matching and reconciling transactions across systems, with the evidence behind every match kept and shown. The point is not the match rate; it is that a controller can see why two rows were paired and disagree with it.
Mobile and field apps
Custom mobile Power Apps and AI extensions for Supply Chain Management — the jobs done standing up, on a device, by somebody who is not going to open a desktop client to do them.
Warehouse mapping and layout
Mapping the physical warehouse and optimising layout, alongside pick-path and slotting. The layout question is upstream of the routing question and is usually the one nobody has revisited.
IoT, asset and condition monitoring
Sensor and asset data feeding the ERP so a condition raises the right record rather than an email. Incoming-inspection apps that read images and sensor data sit beside this at blueprint stage.
Document intelligence, ERP side
Read, classify, extract and validate invoices, contracts and forms — with the source quote and page kept behind every extracted value, so a disputed figure can be traced rather than argued. The document pipeline is in active client use; the ERP-side app is built to order.
Approval routing and document-driven workflow
Getting a document to the person who must decide, with the context they need attached, and recording what happened. Built to order across the Dynamics estate.
Diagnose, architect, deploy, optimize
A scoped four-to-six week pilot on one workflow, one success metric agreed before anyone writes code, and a weekly readout. The pilot is the first production slice, not a prototype to be thrown away.
- 01
Diagnose
Scope before building. The first output is often that the answer is a report, better master data, or a configuration change — all cheaper than a build, and we would rather say so in week one than month four.
- 02
Architect
Architecture and acceptance criteria agreed up front, in writing, including which integration points are used and what happens at the next platform update.
- 03
Deploy
Milestones tied to working software and a weekly demo. No throwaway code — the pilot is the first production slice, not a prototype to be rebuilt.
- 04
Optimize
Every deployment ships with documentation, runbooks, monitoring and training, plus post-launch support. The measure is whether your team can run it without us.
Business Central and Finance & Operations are not one platform
Different product, different data layer, different environment model. Business Central leads on quoting and pricing, where the path to something working is shorter. Finance & Supply Chain Management carries warehouse and planning, where the data volumes and the environment topology are the hard part.
A team that treats them as one platform will be wrong about both, and the wrongness shows up late — usually at the first data migration or the first environment refresh.
Knowing the difference is not trivia. It is most of what makes an estimate on this work either honest or fictional.
Where we have written it down
- Business Central vs Finance & Operations for warehouse
- Which environments run the ERP MCP server
- How should an AI agent read Dynamics data?
- ERP agent permissions are invisible in Entra
- Data tools, form tools and action tools
- Why ERP agents report false success
What a build adds to your estate, and what remains if you remove it: AI without lock-in.
What buyers ask before commissioning a build
What does “built to order” actually mean?
It is one of five status words we use precisely. Built to order means the engineering exists and we build it for you, but there is no packaged app you can buy off a shelf. It is distinct from shipped, which means running for a customer today; from built and demonstrated on request, which means the software exists and is shown live against your own data; from in development; and from blueprint, which means the architecture is designed and nothing is built. We would rather use five words than one vague one.
Are you a Dynamics implementation partner?
No, and that is deliberate. The partner who implemented your ERP keeps running it — the configuration, the upgrades, the support model. We build the decision layer and the apps beside it, through documented integration points, so the two pieces of work stay separable. We have never competed for implementation work and the arrangement stops making sense if we do.
Where does a custom build run?
On your own governed stack: Power Platform and Power Apps, Dataverse, and Azure in your own tenant, with Azure OpenAI where a model is needed. Microsoft Fabric and Copilot Studio are integrated where your estate already runs them. AppSource is the distribution route where that suits procurement. You keep full ownership of code and data.
How is Business Central work different from Finance & Operations?
Different product, different data layer, different environment model — and knowing that difference is most of the expertise. Business Central leads on quoting and pricing, where time to value is shorter. Finance & Supply Chain Management carries warehouse and planning, where the data volumes and the environment topology are the harder part. A team that treats them as one platform will be wrong about both.
How does an engagement start?
A scoped four-to-six week pilot on one workflow, with a single explicit success metric agreed before we begin and a weekly readout. The pilot is the first production slice rather than a prototype. Commercial shape is agreed in the working session — bring the workflow and the person who owns it.
What about security and compliance?
Secure by design and least privilege: encryption in transit and at rest, role-based access, audit logging. Architectures are aligned with SOC 2, ISO 27001, GDPR, HIPAA and PCI-DSS practices. Aligned with — Cognilium does not claim formal certification.
Bring the workflow, not the requirements document
One workflow and the person who owns it. We will tell you in the session whether this is a build, a report, or a master-data job — and two of those three are shorter and cheaper than working with us.