Hello — the Dynamics 365 community, live

In my first article in this series I walked through the four roads out of D365 Finance and Operations for BI: OData, the entity store, BYOD, and the Synapse and Fabric links. I promised to come back to BYOD, because it is still the road most existing warehouses on F&O sit on, and because it is the one that fails most quietly. A BYOD feed rarely crashes. It keeps running green every hour while the numbers in the warehouse drift a little further from the ledger. Today I want to explain how BYOD really works under the covers, how I set it up, and why an incremental export can miss rows without ever reporting an error.

WHAT BYOD ACTUALLY IS

Bring your own database is not a replication service. It is the Data management framework, the same engine you use for imports and exports of files, pointed at an Azure SQL Database that you own instead of at a file. Every BYOD table you see in your database is the output of a data entity, exported by a data project, running as a batch job on the F&O batch servers. That one sentence explains almost every behaviour you will meet:

• The unit of export is the data entity, not the table. You get the entity's denormalised shape, with its joins, its computed columns, and its field names, not the raw AxDB tables.

• Exports consume F&O batch capacity. A heavy BYOD schedule competes with posting, master planning, and every other batch job on the same environment.

• Incremental export depends on SQL change tracking on the AxDB tables behind the entity. What change tracking is told to watch is exactly what incremental export can see, and nothing more.

Microsoft's direction for new builds is clearly the Synapse Link and Fabric route, which I will cover next. But BYOD is supported, it works with ordinary SQL tooling, and a well run BYOD feed is perfectly respectable. The trick is running it well.

SETTING IT UP: THE TARGET DATABASE

Start with an Azure SQL Database in the same Azure region as the F&O environment. Cross region exports work, but every row crosses the wire, and a large full push across regions turns a twenty minute job into an hour. Size the database for the write burst, not for the steady state: the busiest moment of a BYOD database is a full push of the general ledger or inventory transactions entities, and an undersized tier throttles the export, which in turn holds an F&O batch thread for longer.

In the Data management workspace, under Configure entity export to database, you register the target with an ADO.NET connection string and validate it. Two options matter at this point. Creating clustered columnstore indexes on the target tables is the right choice for almost every reporting workload, because BYOD tables are wide and your queries read a few columns across many rows. Enabling triggers in the target database lets triggers you create on the BYOD tables fire during the bulk insert; I only switch it on when I have a specific downstream reason, because it slows every export.

Then you publish the entities you need. Publishing creates the table in the target with the entity's columns, named after the entity's staging table. Publishing is also how you pick up schema changes after an update adds fields to an entity, and that has a consequence I will return to in the failure section: republishing drops and recreates the table.

In the pricing article I left the transfer price sitting on the intercompany sales order line and the matching cost on the purchase order line. That is where most projects stop paying attention, and where the finance team's problems begin. Today I follow the chain through posting: how the invoice in the selling company creates the invoice in the buying company, where each side lands in the ledger, why the due to and due from accounts are not where you reconcile trade, and what period end has to do before anyone can eliminate anything.

TWO INVOICES FOR ONE DELIVERY

An intercompany delivery is one physical movement and two commercial documents. In the selling company the intercompany sales order (the ICS order, in the naming from the order chain article) is packing slip updated and invoiced like any other sales order: inventory is issued, revenue and cost of goods sold post, and the intercompany customer gets an open transaction. In the buying company the intercompany purchase order (the ICP order) needs a product receipt and a vendor invoice, and D365 can create both for you.

The automation lives on the trading relationship from the trade setup article. The purchase order policies hold the two switches that matter: post the product receipt automatically when the intercompany packing slip posts, and post the vendor invoice automatically when the intercompany sales invoice posts. A companion option lets the product receipt carry the packing slip number and the vendor invoice carry the sales invoice number. Switch it on: it turns reconciliation from a hunt for matching amounts into a join on a document number.

The automatic posting runs in the buying company in the context of the user who posted the sales invoice. That sentence explains a surprising number of support tickets: the user needs rights in the buying legal entity, the fiscal period there must be open, and the vendor posting profile and inventory posting for the intercompany vendor must be complete, or the sales invoice posts and the purchase side quietly does not. The first symptom is a customer balance in one company that nobody can find in the other.

WHAT EACH SIDE POSTS

• Seller, invoice: debit the intercompany customer summary account from the customer posting profile, credit revenue, debit cost of goods sold, credit inventory at issue cost. Transferred charges post as charge revenue here too.

• Buyer, product receipt: debit inventory, credit the purchase accrual. An unmatched receipt therefore shows up as an accrual balance, not a vendor balance.

I have spent most of my career on the other side of the ERP: not configuring Dynamics 365, but getting numbers out of it that finance, operations and leadership can trust. This article opens a series on exactly that. Over the coming posts I will work through Dynamics 365 from the BI, data warehousing and database point of view: how the data is shaped, how to extract it, how to model it, and how to make the figures in a report tie back to what the ERP says. My colleagues here write about how the processes run inside D365; I want to write about what those processes leave behind in the database and how to turn it into reporting.

The first question on every BI workstream for Finance and Operations is the same: where do we read the data from? Teams arriving from on-premises AX are used to pointing SSIS at the production database and getting on with it. In the cloud that road is closed, and the replacements each have a very different character. This article is the map I wish I had been handed the first time: the four ways out of the F&O database, what each one is really for, and how I decide which to use.

THE STARTING POINT: AXDB AND WHY YOU CANNOT TOUCH IT

Underneath every F&O environment is a transactional Azure SQL database, still called AxDB in development and tooling. It is a classic OLTP schema: several thousand tables, heavy normalisation, every row keyed by RecId, company data separated by a DataAreaId column, and a Partition column that is almost always the same value but still sits in every index. Enumerations are stored as integers, financial dimensions are stored as RecId references into DimensionAttributeValueCombination rather than as readable strings, and date and time fields are stored in UTC while pure date fields are not converted at all.

In production you have no direct SQL access to this database, and that is deliberate. Microsoft runs it as a managed service and protects the transactional workload from heavy analytical queries. In a tier 2 sandbox you can request just in time read access for diagnostics, and on a developer box you have the whole database locally, which is invaluable for learning the schema. But neither is a production BI source. I treat the AxDB as something to study, not something to query, and every extraction design starts from that rule.

ROAD ONE: DATA ENTITIES OVER ODATA

The planning article ended with planned purchase orders firmed into an intercompany chain. From that moment a number appears on the intercompany sales order and on the intercompany purchase order that nobody typed: the transfer price. In my experience it is the least understood field in the chain: supply chain assumes finance owns it, finance assumes it falls out of the trade agreements, and whoever built the trading relationship in the setup article clicked past the price search policy. This article covers where that number comes from, three ways to decide what it should be, and what each choice does to the margin in each legal entity.

WHY THE TRANSFER PRICE IS NOT JUST A NUMBER

Within one legal entity, moving stock between warehouses is a transfer order with no revenue or cost of sales involved. Across legal entities the same movement is a sale in one company and a purchase in the other, and D365 treats it as exactly that. The selling company books revenue at the transfer price and cost of sales at its own inventory cost. The buying company receives at the transfer price, which becomes its inventory cost and later its cost of sales. So the transfer price does three jobs at once: it splits group profit between two entities, it sets the cost basis of the receiving company, and it is the number a tax authority may one day ask you to justify.

WHERE THE PRICE IS ACTUALLY SEARCHED

When the intercompany purchase order is created in the buying company, the intercompany sales order is created in the selling company and the two documents exchange fields through the synchronisation described in the order chain article. Price is one of the synchronised fields, but only one side is allowed to find it; the other side copies it. Which side searches is decided by the price and discount search setting in the purchase order policies of the intercompany vendor in the buying company. The default is the intercompany sales order: the selling company runs its normal sales price search for the intercompany customer, finds the price in its sales trade agreements, and the result is written back onto the purchase order line. The alternative points the search at the intercompany purchase order, so the buying company's purchase trade agreements for the intercompany vendor decide and the sales order copies the result. A third option, original sales order, applies to direct delivery chains and carries the external sales price onto the intercompany documents, which is only right when the group wants the transfer price to equal the external price.

The first two articles in this intercompany series dealt with documents: the trading relationship and its policies, and then the order chain that those policies produce once a purchase order is confirmed. Today I want to go one step earlier in time, to the point before any order exists, because this is where most intercompany implementations quietly underperform. The selling entity plans, sees it needs stock from the sister company, and creates planned purchase orders. The supplying entity plans and sees nothing, because nobody has firmed anything yet. Intercompany master planning exists to close that gap: what it does, how to set it up with Planning Optimization, why the run order matters, and what still goes wrong.

THE PROBLEM: EACH LEGAL ENTITY PLANS ALONE

Master planning in D365 is scoped to one legal entity. It reads one company's demand, supply, and coverage settings and creates planned orders in that company. To the engine, an intercompany supply chain is two or three independent planning problems. The selling entity's plan output is planned purchase orders on an intercompany vendor, and in the supplying entity those do not exist. The only demand the supplier sees from its sister company is the demand that has already been turned into intercompany sales orders, which, as I showed in the order chain article, only happens when the planned purchase order downstream is firmed and the resulting purchase order synchronises a sales order upstream.

The consequence is a planning horizon that shrinks as you move upstream. The sales entity may plan twelve months out, but the factory only sees the slice that has already been firmed into orders, typically a few weeks. Beyond that the factory covers demand with a forecast of its own, built by a different team on different assumptions. Two forecasts for the same end demand, in two companies, is the most common root cause of both excess stock and shortages in intercompany groups.

PLANNED INTERCOMPANY DEMAND: WHAT THE FEATURE ACTUALLY ADDS

Intercompany planning solves this by letting the supplying entity read the planned purchase orders of the selling entity before they are firmed. When the upstream plan runs, every unfirmed planned purchase order in the downstream company whose vendor is the intercompany vendor representing the upstream company becomes a demand line in the upstream company's net requirements. The reference type is planned intercompany demand, carrying the downstream company, planned order number, quantity, and requirement date. The upstream engine treats it like any other demand: it nets it against on-hand and existing supply and, if there is a shortfall, creates planned production orders, planned purchase orders, or planned transfers according to the item's default order settings and coverage group upstream.

I've been quietly enjoying the fact that the ERP MCP server has form tools, not just data tools. Data tools are the obvious half: read, create, update, delete. Fine. But form tools let an agent do the other thing — open a page, set a control, click an action — the way a person would, with all your posting logic and validation firing exactly as designed. No parallel API surface to build. That still feels slightly magical to me.

What I hadn't thought about until this week is that "drive the form like a user" means the agent has to find your controls. By name. And that puts a design decision I made three years ago, half-asleep, directly in the critical path of an AI workflow.

The bit that got me

Buried in the 10.0.49 platform notes is a set of form-tool fixes that are much more interesting than their one-line summaries suggest:

• Group option button controls — your FrameOptionButton = Radio and Check groups — were a control family the agent couldn't read or set at all. Not "worked badly." Couldn't touch. If a required step on your form is a radio group, that flow just didn't work.
• Control resolution hardening: find-by-name, grid group resolution, and a preference for non-lookup controls when setting a value. That last one is the tell — if you've got a lookup and a plain field with similar names, the agent was picking wrong and failing ambiguously.
• Menu item label resolution (including via search), plus document upload and viewer support.

So a whole class of "the agent kind of works on this form, sometimes" was really just naming collisions and one blind spot.

Why I care, and what I'm doing about it

This is the first time control naming has had a functional consequence for me. FormStringControl1 never hurt anyone before — it does now. Vague, duplicated, or near-identical control names are the difference between an agent completing a task and giving up in a way nobody can debug.

My takeaway: if you're building agent flows over custom forms, the fix isn't in the agent. Get onto PU73 PQU-1 (7.0.8199.29+; it's backported to 10.0.48 and 10.0.47 too), then go read your own form designs out loud. Would you know which control to click from the names alone? If not, neither will the agent.

I've got a PurchTableExt form I'm suddenly not proud of. Tomorrow's problem.

In the trade setup article I stopped at the moment the trading relationship exists and the policies are saved. Nothing has been ordered yet. Today I want to follow one order all the way through the chain, because the setup only makes sense once you have watched what it does: which document is created from which, which fields travel in which direction, what confirmation really does, how direct delivery pulls the original customer order into the picture, and, the question I get asked most, what you are still allowed to change once the chain exists.

THE THREE DOCUMENTS AND WHO CREATES THEM

A full intercompany chain in D365 has up to three documents. The buying legal entity (I will call it entity A) raises a purchase order to a vendor that is flagged as intercompany. The moment that purchase order is saved, D365 creates an intercompany sales order in the supplying legal entity (entity B) against the customer account that is paired with A. That pairing is the trading relationship from the previous article; without it you get an ordinary purchase order and nothing on the other side.

The third document is optional and sits in front of the other two: the original sales order. When A is selling to an external customer and wants B to supply the goods, the chain starts with A's sales order to that customer, and the intercompany purchase order is created from it, either by a direct delivery action or by master planning firming a planned intercompany order. In that case the intercompany sales order in B carries a reference to the original sales order and, if you choose, to the original customer, so B can see who the goods are ultimately for.

Two points about creation. First, the intercompany sales order is created on save, not on confirmation. Second, the sales order number in B follows the numbering policy on the relationship: it can be B's own sequence, the same number as A's purchase order, or A's company code plus the purchase order number. I argued last time for the company plus number option; in the chain the reason is obvious, because both entities end up talking about the same number.

FIELD OWNERSHIP: WHICH SIDE IS THE MASTER OF WHAT

The cleanest way to think about synchronisation is ownership: each field has one document that owns it, and D365 copies the value to the other. Fight the ownership and you create the differences that surface at reconciliation.

With the asset management thread wrapped up in the asset analytics article, I am starting a new series on a subject that touches almost every multi-entity D365 implementation and is still set up badly more often than well: intercompany trade in Finance and Supply Chain Management. Over the coming articles I will walk the order chain, planning, pricing, accounting and reconciliation, returns, warehouse flows, and the failure patterns. Today is the foundation: what a trading relationship is, how the intercompany customer and vendor pair works, what the order policies do, and where the values on an intercompany order come from. Get this layer right and the rest of the series is about behaviour; get it wrong and every later article becomes a troubleshooting guide.

WHAT INTERCOMPANY TRADE MEANS IN D365 TERMS

Two legal entities in the same D365 environment trade with each other. The selling entity sees the buying entity as a customer; the buying entity sees the selling entity as a vendor. Intercompany trade ties those two master records together so that a purchase order in the buying entity produces a matching sales order in the selling entity, and so that documents posted on one side (confirmation, packing slip, invoice) update the other side without anyone retyping anything. It is not a consolidation feature, not a transfer order, and not a substitute for intercompany accounting in the general ledger, which comes later in the series. It is a document synchronisation mechanism between a customer and a vendor who happen to be the same group, and because both live in one database, D365 can create the counterpart order and post documents in both companies from a single action. Those conveniences are what the setup governs.

THE PREREQUISITES PEOPLE SKIP

Before you touch the intercompany form, four things need to be true.

• The products are released in both legal entities with the same item number. Intercompany does not translate item numbers; the two sides must agree on the product identity, its dimension groups, and its unit of measure.

• The buying entity has a warehouse with a real address. The intercompany sales order takes its delivery address from the purchase order, which takes it from the receiving warehouse (or from the original customer in direct delivery). Warehouses without addresses produce orders without addresses.

• Number sequences exist on both sides and you have decided how intercompany orders should be numbered (more below). If both entities share one sales order sequence, some options will collide.

• Currency, exchange rates, sales tax groups, and posting profiles are in place on both master records. If the vendor has no payment terms, the intercompany purchase order has none either, and the invoice fails at the end of a chain that otherwise worked.

CREATING THE CUSTOMER AND VENDOR PAIR

Start with the master records. In the selling entity, create a customer that represents the buying entity with a proper customer group, currency, and terms. In the buying entity, create a vendor that represents the selling entity in the same way. I name both records after the legal entity they represent and put the entity ID in the account number, because in a group with ten entities and forty relationships you will otherwise spend your life hovering over account numbers.

Then open the Intercompany action on either record. The form is the same from both sides, and once saved it appears on both records. On the trading relationship tab you mark the relationship active and point the record at its counterpart: from the customer you choose the vendor company and the vendor account that represents this selling entity there; from the vendor you choose the customer company and customer account. Save, and you have a trading relationship.

Every maintenance article I have written in this series ends at the same point: the work order is ended and the cost posts. In the work orders article I made the case that ending orders promptly is a discipline, not a formality, because the ledger only sees the cost at that moment. Today I want to follow that cost after it posts, because the whole reason to run maintenance through D365 instead of a spreadsheet is what the history lets you do afterwards: see what an asset has really cost over its life, see how often it fails and how long it stays down, and decide with numbers rather than instinct when it is time to stop repairing something and replace it.

WHERE THE COST GOES AFTER THE ORDER ENDS

Three cost types flow through a maintenance work order: labour hours priced at the worker's cost price, spare parts issued from inventory at their inventory cost, and expenses such as external services or vendor invoices attached to the order. While the order is open, these sit as posted journals against the work order. When the order is ended, D365 posts the ledger side and, just as importantly for this article, stamps the cost into the maintenance cost history of the asset the order was raised on.

That history is what the cost control inquiries read. Asset management offers cost control views at three levels: per asset, per functional location, and per work order. The asset view is the one I use most, because it lets you pick a period and see the split between hours, items, and expenses for one asset, and compare it against a budget if you have created one. The functional location view rolls up every asset installed underneath it, which is why I keep saying that the hierarchy you designed in the functional locations article is not just a filing system: it is your cost roll-up structure. If a packaging line is a functional location with six assets under it, the line's cost is one click, and it is correct without anyone building a report.

Two practical points here. First, cost history is only as good as the ending discipline: an asset with five open orders looks cheap until the month someone closes them all at once and the trend jumps. Second, if you move an asset between functional locations, the cost follows the asset, but the location roll-up changes from the move date onward. That is usually what you want, but it surprises people who compare a location's cost across a year in which equipment was shuffled.

BUDGETS GIVE THE NUMBERS SOMETHING TO BE COMPARED AGAINST

When making a GRN in system my entries are getting posted in the stock variance account. I want to know the reason for this issue. My current item model group is FIFO. Thanks in advance!

Every company wants real time visibility into their supply chain. Fewer companies actually trust that visibility enough to act on it.

I've noticed this pattern again and again around Dynamics 365 Supply Chain Management implementations. The system is set up, inventory is tracked, demand forecasting is running, planners have a dashboard that shows exactly what's on hand, what's in transit, and what's projected to be needed next month. And yet, in a lot of warehouses and planning offices, someone is still keeping a personal spreadsheet, still calling a supplier directly to double check a number, still adjusting the system's forecast based on gut feel built up over years on the job.

That gap between what the software shows and what people actually rely on is worth paying attention to. It rarely comes from the technology being wrong. Dynamics 365 Supply Chain Management can genuinely pull together procurement, inventory, warehouse, and manufacturing data in a way that legacy point systems never managed. The gap comes from trust, and trust in supply chain data is earned slowly and lost quickly. One bad forecast during a demand spike, one inventory count that didn't match reality during a physical audit, and a planner remembers that moment for years. After that, the system becomes a reference point instead of a decision maker, and the spreadsheet on the side quietly becomes the real source of truth.

This matters more now than it used to, because supply chains have spent the last several years absorbing shocks that made careful planners even more cautious. Disruption after disruption taught a lot of supply chain professionals that clean historical data does not always predict what happens next, and that lesson does not disappear just because a new planning engine got implemented. So the honest challenge for any Dynamics 365 Supply Chain Management rollout isn't only technical configuration. It's proving, transaction by transaction, that the numbers hold up when it counts, and that takes longer than any go live date usually allows for.

There's also an organizational layer to this. In many companies, the people closest to physical inventory, warehouse staff, floor supervisors, receiving teams, are the ones whose daily actions determine whether the data in the system stays accurate. If those teams see data entry as a task imposed on them rather than something that protects their own planning decisions later, small inaccuracies creep in constantly, and no amount of forecasting sophistication can fix data that was wrong at the source.

The demo always goes the same way. Someone types "create a purchase requisition for 200 units of the steel bracket from our usual vendor and route it for approval" into a chat pane, and the AI agent finds the item, picks the vendor, fills the form, and submits the workflow. But three weeks later, that agent is in production, and the questions start: Why can this thing see payroll? Who approved it, touching the ledger? It just edited a record nobody asked it to; was that allowed?

I've now deployed enough Copilot agents for Dynamics 365 Finance & Operations to say the quiet part out loud. Building the agent is only 20% of the journey. The remaining 80%, which entails deploying, governing, monitoring, and running it safely at scale, is where the real complexity begins. This article is about the 80%.

The Demo Problem

Demos optimize for the happy path. A scripted prompt, clean data, one user, no edge cases, and a presenter who knows exactly what the agent will do because they rehearsed it. Production is the opposite of all of that. You get prompts nobody anticipated, users with wildly different permissions, dirty data, and an agent that's now allowed to act, not just answer.

The business challenge isn't "can the agent do the task?" It demonstrably can. The challenge is ownership: who is accountable for what the agent is permitted to see and do, who watches it, who gets paged when it misbehaves, and who can prove to an auditor that it stayed inside its lane. That's an operations discipline, and it's one most teams haven't built yet because the technology only made autonomous action practical very recently. 

What Actually Changed 

If you wired an agent to F&O over the last year, you probably used the static Dynamics 365 ERP MCP server, a fixed set of 13 tools built on the Dataverse connector framework. It worked, but it was rigid, and Microsoft is retiring it during the 2026 calendar year. The replacement, the “dynamic” Dynamics 365 ERP MCP server, went generally available in February 2026.

Instead of a frozen tool list, it exposes living tool categories: data tools for create/read/update/delete against entities, action tools that invoke business logic, and metadata tools the agent uses to discover your schema, including custom entities and extensions. Per Microsoft's documentation, this surfaces hundreds of thousands of ERP operations across tens of thousands of forms, without a custom connector or bespoke API. The data tools also moved off chatty form-level interactions toward direct, optimized entity operations, which is why agent responses got both faster and more reliable.

Here's the line from Microsoft Learn that matters more than any of that: when you add the MCP server to an agent, it gets access to data and business logic that matches the agent's security role and environment context. This means it gets exactly the permissions you assign it, no more, no less. 

Two years ago, Copilot in Dynamics 365 was essentially a helpful colleague who could summarize a record or draft an email. The 2026 release wave 1 marks the point where that changed. Microsoft now ships agents across Sales, Customer Service, Finance and Supply Chain that do not simply answer questions. They take a business goal expressed in plain language, break it into concrete steps, and carry those steps out inside the system. 

The clearest example is the Contact Center, which Microsoft is turning into a fully agentic environment. Cases get triaged, routed, drafted and in many instances resolved before a human ever opens them. Containment rates, the share of inquiries handled entirely without human involvement, have become a headline metric in customer service projects. On the finance side, the new autonomous Payflow Agent takes over payment processing tasks that used to consume hours of accounts payable time every week.

Anyone who has sat through a Dynamics implementation knows the traditional shape of the work: requirements, configuration, data migration, training, support. Agents add a layer that behaves differently from anything consultants have deployed before. An agent is not a workflow. It does not follow a fixed path, and its behavior depends on the quality of the data and knowledge it can reach. 

That has practical consequences. Data hygiene, long treated as a cleanup task to squeeze in before migration weekend, is now a precondition for the headline features working at all. An agent drafting customer responses from a knowledge base full of outdated articles will confidently produce outdated answers. Teams that skipped the unglamorous work of curating their content are discovering that the bill has arrived. 

Scoping also changes. Clients increasingly arrive with expectations set by consumer AI tools and assume the same fluency will appear in their ERP on day one. Part of the consultant's job in 2026 is expectation management: being clear about what agents do well today, where they still need human review, and which processes are genuinely ready to hand over. 

The conversation in the Dynamics world has changed. Nobody is asking whether to adopt AI anymore. The question on every project board is how to put agents to work without breaking what already runs the business. 

Two years ago, Copilot in Dynamics 365 was essentially a helpful colleague who could summarize a record or draft an email. Useful, certainly, but nobody would have trusted it to act on its own. The 2026 release wave 1 marks the point where that changed. Microsoft now ships agents across Sales, Customer Service, Finance and Supply Chain that do not simply answer questions. They take a business goal expressed in plain language, break it into concrete steps, and carry those steps out inside the system. 

The clearest example is the Contact Center, which Microsoft is turning into a fully agentic environment. Cases get triaged, routed, drafted and in many instances resolved before a human ever opens them. Containment rates, the share of inquiries handled entirely without human involvement, have become a headline metric in customer service projects. On the finance side, the new autonomous Payflow Agent takes over payment processing tasks that used to consume hours of accounts payable time every week. 

What this changes for implementation work 

Anyone who has sat through a Dynamics implementation knows the traditional shape of the work: requirements, configuration, data migration, training, support. Agents add a layer that behaves differently from anything consultants have deployed before. An agent is not a workflow. It does not follow a fixed path, and its behavior depends on the quality of the data and knowledge it can reach. 

That has practical consequences. Data hygiene, long treated as a cleanup task to squeeze in before migration weekend, is now a precondition for the headline features working at all. An agent drafting customer responses from a knowledge base full of outdated articles will confidently produce outdated answers. Teams that skipped the unglamorous work of curating their content are discovering that the bill has arrived. 

Scoping also changes. Clients increasingly arrive with expectations set by consumer AI tools and assume the same fluency will appear in their ERP on day one. Part of the consultant's job in 2026 is expectation management: being clear about what agents do well today, where they still need human review, and which processes are genuinely ready to hand over. 

Augmentation, not replacement 

When people talk about Microsoft Dynamics 365, the conversation usually stays within CRM, sales or ERP territory. The EV industry almost never comes up. In my opinion that is a missed opportunity, because the operational problems holding back charging networks today are exactly the kind of problems this platform was designed to solve. I believe integrating Dynamics 365 into the EV world would shape it in a clearly positive way, and this article explains why.

The industry has an operations problem, not a technology problem

EV charging has grown fast, and the software behind it has not kept up. Most operators run on a patchwork of systems. Asset records sit in one platform, fault tickets in another, contractor management in a spreadsheet, and customer support somewhere else entirely. None of these talk to each other properly.

The result is familiar to anyone who has dealt with public charging. A charger goes down, nobody notices until a driver complains, an engineer is sent out with the wrong information, and the fix takes days instead of hours. Every one of these failures’ chips away at public confidence in EVs. If drivers cannot trust that a charger will work, they hesitate to switch from petrol. So poor operations are not just a cost issue, they slow down the energy transition itself.

One view of the asset changes everything

The core value of Dynamics 365 in this industry would be a single view of every asset. One record per charger that holds its installation details, maintenance history, fault patterns, contractor visits and customer complaints. Today that information is scattered, and decisions suffer for it.

With a unified view, an operator can spot that a particular charger model fails twice as often in coastal locations, that a certain contractor closes jobs faster than others, or that a site with repeated complaints also has a grid connection issue. These insights exist in the data already, they just cannot surface when the data lives in five places.

Field service is where the biggest gains sit

Field work is one of the largest cost centres for any charging operator, and slow charging makes it worse. The assets are cheap and spread across hundreds of small sites, so a single wasted site visit can wipe out months of revenue from the unit it was meant to fix.

What actually happened

The 2026 pattern for this is the "AI tool" (Microsoft's word for it — you'll also hear "AI plugin"). You write a normal X++ class, deploy it, and decorate it with a couple of attributes. AIPluginOperationAttribute marks the class as something an agent is allowed to call. CustomAPIAttribute ties it to a Dataverse Custom API. Your inputs and outputs are just data contract members with plain-language descriptions:

X

[CustomAPIRequestParameter('The customer account number', true),
    DataMember('accountNumber')]
public CustAccount parmAccountNum(CustAccount _accountNum = accountNum)

That description string is the part I want you to notice. It's not a comment — the orchestrator actually reads it to decide when to call your action and how to fill the parameter from someone's messy sentence. You're basically writing prompt hints in your method signatures now. Weird. Kind of great.

Why this matters to you and me

Here's the shift. These are headless operations — no form context, no client. Once your class is deployed with the right menu-item security, the Dynamics 365 ERP MCP server picks it up automatically through its find_actions / invoke_action tools. Same code, reachable from the in-app sidecar, from a custom Copilot Studio agent, or from any agent speaking MCP. You write the logic once; the surface area is enormous.

The honest catch: it's still preview, you need the unified developer environment, and there's Dataverse plumbing (the Custom API, request params, response props) plus the classic flush the cache with SysFlushAOD or nothing works gotcha that cost me twenty minutes.

My takeaway: stop thinking of your X++ classes as things only a form can call. Pick one small, useful calculation you already trust — a balance, an eligibility check, a status lookup — wrap it as an AI tool, and let Copilot reach it. It's the most direct line I've found from "code I already have" to "AI that does something real."

When people talk about Microsoft Dynamics 365, the conversation usually stays within CRM, sales or ERP territory. The EV industry almost never comes up. In my opinion that is a missed opportunity, because the operational problems holding back charging networks today are exactly the kind of problems this platform was designed to solve. I believe integrating Dynamics 365 into the EV world would shape it in a clearly positive way, and this article explains why.

The industry has an operations problem, not a technology problem

EV charging has grown fast, and the software behind it has not kept up. Most operators run on a patchwork of systems. Asset records sit in one platform, fault tickets in another, contractor management in a spreadsheet, and customer support somewhere else entirely. None of these talk to each other properly.

The result is familiar to anyone who has dealt with public charging. A charger goes down, nobody notices until a driver complains, an engineer is sent out with the wrong information, and the fix takes days instead of hours. Every one of these failures’ chips away at public confidence in EVs. If drivers cannot trust that a charger will work, they hesitate to switch from petrol. So poor operations are not just a cost issue, they slow down the energy transition itself.

One view of the asset changes everything

The core value of Dynamics 365 in this industry would be a single view of every asset. One record per charger that holds its installation details, maintenance history, fault patterns, contractor visits and customer complaints. Today that information is scattered, and decisions suffer for it.

With a unified view, an operator can spot that a particular charger model fails twice as often in coastal locations, that a certain contractor closes jobs faster than others, or that a site with repeated complaints also has a grid connection issue. These insights exist in the data already, they just cannot surface when the data lives in five places.

Field service is where the biggest gains sit

Field work is one of the largest cost centres for any charging operator, and slow charging makes it worse. The assets are cheap and spread across hundreds of small sites, so a single wasted site visit can wipe out months of revenue from the unit it was meant to fix.

Over the last two articles I built the asset management picture from the ground up: first the foundation of functional locations, assets, and asset types, then the preventive side, where maintenance plans, rounds, and triggers project a forecast of work. I kept making the same promise at the end of each one, that the work order is the thing that finally posts cost when it is ended, and I kept deferring the detail. Today I pay that debt. I want to follow a maintenance work order all the way through execution and into money: where it comes from, how it schedules against the people and the equipment, how it picks up labour hours and spare parts from the same inventory the shop floor draws on, and the exact moment the cost becomes a financial fact that finance can see.

WHERE THE WORK ORDER COMES FROM

A maintenance work order in Dynamics 365 has two parents. The first is preventive: the forecast I described last time generates work orders from due plan lines, so a calendar trigger or a counter reading quietly turns into a scheduled job without anyone typing it in. The second is corrective: something breaks or someone notices a problem, a maintenance request is raised, and that request is converted into a work order. Either way you land on the same object, and that is the design intent. Whether the work was planned a year out or reported five minutes ago, it flows through one consistent lifecycle so the maintenance team has a single backlog to schedule and a single place where cost accumulates. A work order carries one or more work order jobs, and each job names a job type and a trade, exactly the controlled vocabulary the plan lines use, which is why the taxonomy decisions from the foundation article keep paying off here.

THE WORK ORDER LIFECYCLE

The work order moves through a sequence of lifecycle states, and the states are not cosmetic. They gate what you are allowed to do and, crucially, when cost is recognised. A new order is created, then scheduled, then it goes in progress while the work is actually done, then it is completed when the technician is finished on the floor, and finally it is ended. That last transition is the one that matters financially. Until the order is ended, the hours and parts on it are estimates and commitments; they show you what the job is expected to consume and they let you plan, but they have not yet hit the ledger. Ending the order is the act that posts the real cost. I labour this point because it is the single most common source of confusion I see: people look at an in-progress order, see numbers, and assume finance has them, when in fact nothing has posted until the order reaches the ended state.

In my last article I walked through engineering changes and how to get a revision into BOMs and production orders cleanly. I ended on a promise: the costing side. Because every BOM change is also a cost change, and if engineering and finance do not coordinate their cutovers, the result is a month of variance analysis meetings where nobody can explain the numbers.

This article is about standard cost specifically. If your manufactured items run on moving average or FIFO, BOM changes flow into cost through actual consumption and you have a different (easier) life. Standard cost is where timing discipline matters.

HOW STANDARD COST GETS BUILT

A manufactured item's standard cost in D365 is not entered; it is calculated. The BOM calculation rolls up component costs from the item cost prices, labor from the route (run time and setup against cost categories), and overhead through the costing sheet's indirect cost nodes. The result lands in a costing version as a pending cost with an effective date, and it does nothing until someone activates it.

That separation between pending and active is the whole control mechanism. You can calculate as often as you like, review the calculation details level by level, and only the activation moves the number that values inventory and measures production.

Three configuration points worth checking on your costing version setup before any of this matters: the blocking flag (prevents accidental activation), the fallback principle (where the calculation finds component prices that have no pending cost themselves), and whether your costing version records cost by site, because multi-site manufacturers with different routes per site need site-specific standards.

A BOM CHANGE DOES NOT CHANGE COST (UNTIL YOU MAKE IT)

Here is the point people miss: activating a new BOM version changes what production consumes. It does not change the standard cost of the parent. The standard stays whatever was last activated, calculated from the old structure. From the moment the engineering cutover happens until the moment a new standard is activated, you are deliberately running with a standard that no longer matches the build.

That is not automatically a problem. It is a measurable, explainable state, as long as you know what it does to variances.

THE VARIANCE MECHANICS

When a production order on the new BOM finishes and you run end-of-order costing against the old standard, the difference between what the order actually consumed and what the standard says it should contain shows up as production variances. The useful ones to watch in this scenario: