D365 F&O Innovation & Architecture
Virtual Entities in D365 F&O are not an integration strategy
They're a convenience feature and too many teams mistake the two.
On paper, Virtual Entities promise:
In reality?
You create a sales order with 100 lines from Power Apps. You must use ForAll. That means:
If the network drops on line 47? Congrats! You now have a partially created order. In D365, partial transactions are operational risks.
Here's the real breaking point: Virtual Entities only expose standard entities. But serious D365 extensions rely on:
So you build a Custom Connector anyway. At that point, you have to ask: Why not design a proper API layer from the start?
Virtual Entities are fine for simple apps. But if you are designing serious D365 connected apps, treat Virtual Entities as a convenience feature, not as your foundation.
Table-first integration leads to technical debt. API-first architecture scales.
Trade Counters: The million-dollar problem in D365 F&O implementations
Not because D365 isn't capable. But because trade counters run on speed, not ERP workflows. At a busy counter staff need to:
All while the customer is standing there waiting. Yet most implementations rely on either:
Both approaches eventually create the same problems:
And sometimes millions spent trying to make it work.
The Real Cost
Most trade counter inefficiencies don't show up during go-live. They show up every day afterwards:
The cost isn't just technical. It's operational friction.
The Customisation Trap
The real issue isn't functionality. It's operational usability. And this is where things get expensive:
What if the trade counter experience could be purpose-built instead? Built by your own team using AI and Power Platform, without breaking the bank? That's exactly what I'm going to show next.
Implementing D365 F&O and feeling friction mid-project?
For years, people have assumed that ERP success comes from following the "proven playbook." You know the one:
Millions get spent. Projects drag on for 18-36 months, and far too many end up going live but delivering little ROI or sitting on life support. Because the playbook wasn't designed for outcomes. It was designed for consulting revenue.
The Fastlane / AI-era opportunity:
The result: faster implementations, lower cost, teams that actually innovate, and M&A integrations that take weeks instead of years.
The old playbook assumed information scarcity. AI just destroyed that:
The future of D365 is everyone can build safely, fast, and on top of a clean core.
If you're tired of stalled D365 projects, this is the mental shift you need: Treat D365 as a platform to build on, not a project.
The old playbook is dead. The AI-era D365 requires building on top, not inside.
The most expensive sentence in D365 F&O projects: "Don't customize. Your business isn't unique."
If you've worked on a D365 implementation, you've probably heard this before. Ironically, this mindset often leads to millions in unnecessary complexity.
A regional wholesaler with 45 branches needed just two simple things:
Pretty standard for a B2B distributor.
The recommendation? Use the Retail module and Unified Pricing framework. Both are powerful but for this scenario, they were massive overkill. Implementing them properly requires:
…and usually comes with a poor user experience:
The consequences are predictable:
A lightweight app, built in React or Power Apps sitting on top of D365 could have handled this simply:
No pricing framework overhaul. No massive configuration project. No operational complexity explosion. Just a fast execution layer doing the job.
Instead, what followed was predictable. 15 months later:
All this for something that could realistically have been built in a few months for under $200k.
Unified Pricing may become the next "Retail module trap" in D365 projects. D365 is a powerful ERP but it's not always the best place to build operational user experiences.
The companies that move faster take a different approach:
The $5M mistake companies keep making with D365 F&O
Most companies running D365 F&O make the same mistake and it costs $2M–$5M every time.
It starts with: "We need a better system." Maybe it's CRM, FP&A, Procurement, Financial Close. So they evaluate software: Salesforce, Anaplan, BlackLine, Coupa… then the machine kicks in:
12-18 months later:
Why? The real business logic already lives in Excel. Revenue models, planning, reconciliation, pricing rules—all built by the business.
AI changes everything
Code is no longer the barrier. Instead of buying software, companies can build custom apps on D365 using Power Apps, React, and APIs.
Buy SaaS:
Build apps: 3-6 months, $200-$500K:
The smartest organizations are starting to treat D365 differently: not as a product but as a platform to build on.
And in the AI era, it's time to rethink talent too. Upskill your existing staff—the same people who have been building logic in Excel for years—to become real builders.
Think of it as Excel 2.0: turning years of spreadsheet expertise into real, maintainable software on top of D365.
Stop wasting money on vendors. Start investing in your people. That shift changes everything.
