Explorez tous les épisodes du podcast M365.FM a Microsoft MVP Podcast by Mirko Peters

Getting machine alarms, sensor values, production counters, and fault events into the cloud is easier than ever. OPC UA exposes the machine signal, an edge layer collects it, MQTT can distribute it locally, and Microsoft Fabric can ingest and analyze the resulting stream. The difficult part starts after the data arrives: how do you turn raw telemetry into enough production context to support an actual decision?

This episode follows one machine signal from the factory floor through the Microsoft industrial data stack. It starts with OPC UA, moves through the edge and MQTT, crosses securely into Azure and Microsoft Fabric, and then looks at how Eventstream, Eventhouse, KQL, Lakehouse, Power BI, MES, ERP, maintenance data, and production context fit together. The goal is not simply to show another telemetry pipeline. It is to explain what has to happen before machine data becomes useful for production, maintenance, quality, and planning.

FROM MACHINE STOPPAGE TO PRODUCTION CONSEQUENCE
A machine stoppage looks simple at the controller level. The state changes from running to faulted, a fault code appears, the part counter stops, and perhaps other values change around the same time. That information is useful, but production usually asks a different question: which work order is affected, how much quantity remains, can another machine take over, and does this delay threaten a delivery?

The machine understands its own condition, but it does not automatically understand the business consequence. MES may know the operation and work order. ERP may know the due date and demand. Maintenance may understand the equipment history. Quality may determine whether output can still be used. That is why a fast telemetry pipeline is only the beginning of the architecture.

OPC UA — WHERE THE SIGNAL ENTERS THE DATA PATH
OPC UA provides a standardized industrial interface for accessing information from equipment without requiring every cloud application to understand proprietary controller protocols. A server can expose variables, machine states, alarms, events, methods, timestamps, quality information, and sometimes structured equipment models.

That structure matters because a useful industrial event should carry more than a numeric value. Source timestamps, server timestamps, quality status, units, source identity, and the original OPC UA node information can all become important later when somebody asks where a number came from or why a production calculation looks wrong.

The episode also emphasizes that a tag name is not a data model. A field called “temperature” or “machine state” still needs context such as the asset, engineering unit, allowed range, state definition, and the production situation in which the signal was observed. 

KEEP THE OT BOUNDARY CONTROLLED
Machine connectivity should not turn the production network into an extension of the corporate or cloud environment. Industrial networks need controlled boundaries, typically including segmentation and an industrial DMZ, so that approved edge systems can communicate with equipment without giving enterprise applications direct access to controllers.

The recommended pattern is generally outbound-oriented. The edge layer connects to approved OPC UA endpoints and then sends selected information toward cloud services through controlled destinations, ports, protocols, and identities. Analytics platforms should receive data without inheriting broad rights to browse or modify production systems.

Certificates, firewall rules, trust relationships, expiry handling, and ownership also need to be treated as operational processes rather than one-time configuration work.

THE EDGE SHOULD IMPROVE DATA — NOT INVENT BUSINESS MEANING
The edge layer sits between the machine environment and the wider data platform. Its first responsibility is connection, but it can also filter, normalize, buffer, enrich, and route the information before it leaves the plant.

Useful edge responsibilities include:
• Selecting only signals required for defined use cases
• Filtering unnecessary high-frequency data
• Applying agreed unit conversions
• Preserving source timestamps and quality indicators
• Adding stable site, line, and asset identifiers
• Buffering during cloud outages
• Handling retry and back-pressure behavior
• Exposing connector and queue health
• Performing selected local calculations or AI inference where latency or disconnected operation requires it

The important boundary is that the edge should add facts it knows with confidence. It should not guess which production order is active based on stale information or quietly create business context that belongs to MES, ERP, planning, or quality systems. 

AZURE IOT EDGE VS AZURE IOT OPERATIONS
The episode compares two Microsoft approaches for running industrial edge workloads.
Azure IoT Edge works well when the requirement is focused around a gateway or individual device. Containerized modules can collect data, apply local logic, buffer information, and send it upstream through Azure IoT Hub. This can be a practical choice for a defined cell or smaller workload where the organization wants a lighter operating footprint.

Azure IoT Operations is positioned more as a site-level industrial data environment. It runs on an Azure Arc-enabled Kubernetes environment and includes capabilities around OPC UA connectivity, MQTT, data flows, and asset or device management. That can make more sense when a site has several lines, multiple machine vendors, local consumers, and a need to repeat a governed edge pattern across plants.

The decision should not be based on which platform has the longest feature list. It should be based on the operating model the organization is prepared to support. Azure IoT Operations provides broader site-level capabilities, but it also introduces Kubernetes, Arc, cluster operations, monitoring, storage, patching, and recovery responsibilities.

MQTT AS THE FACTORY EVENT BACKBONE
When several consumers need the same machine events, MQTT can dramatically simplify the architecture. The machine connector publishes once to a broker, and maintenance applications, local historians, cloud data flows, or other approved consumers subscribe independently.

That removes many point-to-point dependencies. A new application can subscribe to an approved topic without creating another direct link into the PLC or OPC UA server.

Topic design still matters. A hierarchy can represent site, area, line, cell, and asset, but the topic should not become the entire data model. Important facts such as event identity, source timestamp, asset ID, quality, contract version, and event type should remain in the message payload so the event stays understandable even when stored, replayed, or routed elsewhere.

THE UNIFIED NAMESPACE IS A CONTRACT — NOT JUST A TOPIC TREE
The Unified Namespace pattern can provide a shared operational contract across industrial systems. The useful part is not simply having one huge MQTT hierarchy. The value comes from agreeing how assets are identified, how events are shaped, who owns the data, how schemas change, and which systems are authoritative for different facts.

A good Unified Namespace can provide a stable way to identify assets and publish governed operational events while allowing source systems to keep ownership of their own records.

That contract should define things such as:
• Asset identity
• Event types
• Message shape
• Timestamp rules
• Quality information
• Ownership
• Security
• Versioning
• Change management

MQTT can transport the contract, but MQTT does not create the contract.

FROM OPC UA NOTIFICATION TO MQTT EVENT
Turning an OPC UA notification into an MQTT event is more than protocol translation. The connector needs to preserve evidence from the industrial source while transforming the message into a format that downstream systems can understand.

For a state event, that could include a stable asset ID, signal name, value, source time, source quality, event type, and the original OPC UA node reference. For an alarm, additional fields might include fault code, severity, and source text where appropriate.

Different event types should remain distinct. Machine state, fault events, production counts, quality rejects, and condition measurements are not all the same type of telemetry and should not be forced into a vague generic record if consumers need different behavior.

THE PACKAGING CELL EXAMPLE
The episode uses a packaging cell to show why context matters even when the source signals appear simple. Machine state, good count, reject count, speed, and fault information may look straightforward, but each needs interpretation.

A zero speed can mean failure, planned changeover, waiting for material, or another expected condition. A reject counter may not identify which product or inspection point caused the rejection. A machine speed value means very little without the product-specific expected speed. A fault code may help maintenance but still does not explain the impact on the current order.

The design therefore needs explicit states, source evidence, timestamps, and links to the production context that will be added later.



Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

A connected factory can move machine signals in milliseconds and still fail to answer the operational questions that actually matter. A packaging machine stops, the PLC reports the fault, OPC UA exposes the event, MQTT distributes it, and the dashboard updates immediately. Maintenance receives an alert and everything appears connected. Then the planner asks which customer shipment is now at risk, and suddenly the answer requires MES data, ERP records, maintenance history, quality status, production quantities, delivery commitments, and often a spreadsheet. That gap is the focus of this episode: connectivity moves signals, while integration connects meaning, constraints, ownership, timing, and consequences.  

CONNECTIVITY MOVES SIGNALS — INTEGRATION CONNECTS MEANING
OPC UA, MQTT, edge gateways, brokers, and modern industrial connectivity platforms solve important problems. They make machine data accessible, standardize transport, reduce point-to-point connections, and allow events to move between machines, applications, and cloud services. But transporting an alarm does not explain its business consequence.

A fault code can arrive perfectly, keep the correct timestamp, and reach every subscriber within seconds. That still does not tell a planner whether the stopped machine affects an urgent order, whether approved inventory already exists, whether the current output is on quality hold, or whether another resource can take over. To answer those questions, the architecture needs relationships between the machine, the active operation, the work order, the product, material status, quality state, maintenance information, and customer demand.

ONE ALARM, MULTIPLE SYSTEMS, NO COMPLETE ANSWER
The episode follows one packaging-machine alarm through the systems that typically hold different parts of the production story. The PLC knows what happened at the machine. MES understands which operation and work order are active. ERP knows demand, due dates, inventory, and customer commitments. Maintenance knows service history and outstanding work. Quality decides whether the produced output can actually be released.

Each system can be correct while the factory as a whole still cannot answer the operational question. This is where people become the integration layer: someone checks MES, someone else opens ERP, maintenance searches the service history, quality verifies release status, and somebody eventually pulls the information together manually. That approach works until decisions need to happen quickly, systems change, or the person who understands all the hidden mappings is unavailable.   

UNIFIED NAMESPACE: A BETTER HIGHWAY, NOT THE FACTORY MAP
A Unified Namespace can improve this situation significantly by replacing many direct system-to-system connections with a shared publish-and-subscribe environment. Machines and applications publish information once, consumers subscribe to what they need, and new systems can join without another custom connection back to the equipment.

That reduces plumbing, but it does not automatically create context. An MQTT topic structure can tell you where information came from, but it cannot determine which production order was active, which material was involved, which quality state applied, or which customer delivery depends on that order. Publishing MES, ERP, quality, and machine events into the same broker does not automatically create the relationships between them. Those relationships still have to be modeled and governed.    

THE TAG NAMING TRAP
Good naming conventions help people discover data, but names are not identities. One system may call a machine Packer7, maintenance may use PK07, ERP may use a production-resource code, and a cloud platform may know the same equipment through a device identity. All of those records can refer to the same physical asset.

Without governed identity, organizations gradually build mapping tables, custom scripts, report-specific translations, and undocumented assumptions. Then the machine gets moved, rebuilt, renamed, or receives a new controller and the data still flows while the relationships quietly become wrong. Friendly names are useful for people, but stable identity is what keeps systems connected over time.

ERP AND MES HAVE DIFFERENT JOBS
ERP and MES are related but they should not be treated as the same system. ERP works at the business and planning level with demand, supply, inventory, customer commitments, production orders, and financial consequences. MES works closer to execution with operations, production resources, operators, downtime, quantities, material consumption, and the actual progress of work on the floor.

The architecture becomes more reliable when those responsibilities remain clear and the systems are deliberately linked instead of forcing one platform to own everything. A machine can report that production is complete while quality still has the output on hold. MES may show an operation as finished while ERP has not yet posted the finished goods receipt. Those states can all be valid because they describe different moments in the same production process.    

DATA IS THE SIGNAL — CONTEXT IS THE SURROUNDING FACTORY
A temperature value is data. Context explains which sensor produced it, which machine contains that sensor, which product was running, which recipe applied, what unit was used, whether the sensor was calibrated, and what operating range was acceptable for that production run.

The same applies to a machine-down event. The signal tells you that something stopped. Context tells you which operation was affected, which order was running, what material was being used, whether the produced output is actually available, whether another resource could take over, and which customer commitment may now be at risk.

Useful industrial context usually includes:
• Asset context — what the physical thing is and where it sits
• Process context — what the resource can actually do
• Order context — what work is currently running
• Material context — which lots and components are involved
• Quality context — whether output is released, restricted, or held
• Time context — which relationships were valid when the event happened

Once those relationships exist, the same machine event becomes much more useful for planning and decision-making.    

SCHEMA, ONTOLOGY, AND GRAPH ARE DIFFERENT THINGS
A schema defines the shape of a record. It can require fields such as asset ID, event timestamp, fault code, work-order ID, or engineering unit. An ontology defines the shared meaning of the concepts and relationships used across the factory. A graph provides a practical way to store and query those connected entities.

For example, a machine can belong to a production line, a sensor can measure a component, an operation can belong to a work order, a material lot can be consumed during that operation, and finished output can have a quality status. A graph makes those connections easy to traverse, but simply choosing a graph database does not create meaningful relationships. The quality comes from the model, ownership, timing, identity, and governance around those links. 

FROM MACHINE ALARM TO A USEFUL PRODUCTION ANSWER
If those relationships are modeled, the packaging-machine alarm can be traced through the wider production context. The fault event identifies the physical asset, the asset connects to the production resource, the resource connects to the active operation, the operation connects to the work order, and the work order connects to product, quantity, demand, and delivery commitments.
Material relationships show what was consumed. Quality relationships show whether completed production is actually usable. Maintenance relationships provide service history and known issues. Instead of only saying “Packer 7 stopped,” the architecture can begin to explain which order was running, how much quantity remains, whether completed output is available, and which customer delivery may now be affected.

That is the difference between event monitoring and actual decision support.

SEMANTIC GOVERNANCE — WHO OWNS THE MEANING?
Once these relationships start supporting production decisions, ownership becomes critical. Someone has to define which record represents the asset, which machine can perform which operation, which system owns work-order execution state, which system owns quality release, and who approves mappings between maintenance, MES, ERP, and automation records.
The answer normally involves several business domains rather than one central IT team. That means the architecture needs clear ownership, source references, timestamps, version history, data contracts, and approval processes. AI can help suggest likely mappings between inconsistent records, but a suggested relationship should not automatically become a governed production fact without evidence and domain validation.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Continuous improvement is supposed to create learning that compounds over time. In many factories, however, improvement work still depends heavily on workshops, spreadsheets, isolated reports, and what people remember from the previous shift. A Kaizen event can create visible progress, but a few weeks later the same loss often appears again under slightly different production conditions. The issue is not always the quality of the improvement idea. The bigger problem is that teams often cannot prove whether the countermeasure actually worked, where it worked, and under which conditions it stopped working.

WHY KAIZEN IMPROVEMENTS OFTEN DISAPPEAR
A workshop creates focus for a few days. Teams map the process, identify waste, assign actions, move tools, change checklists, or adjust handoffs. Then normal production pressure returns. The supervisor has another urgent order, maintenance has another fault, planning changes the sequence, and quality puts another batch on hold. The improvement action remains somewhere in an Excel file or project tracker instead of becoming part of the operating rhythm. The important question is therefore not whether an action was completed, but whether the production condition actually improved.

PDCA NEEDS A REAL CHECK STEP
Plan, Do, Check, Act sounds simple, but many organizations effectively run Plan, Do, and Move On. PLAN should define a testable problem, the current condition, the expected improvement, and the hypothesis behind the countermeasure. DO means testing the countermeasure under real production conditions while recording enough context to understand what actually happened. CHECK means comparing the expected result with real production evidence. ACT means standardizing the change when the evidence supports it, or adapting, narrowing, or reversing it when it does not.   
• Did the loss actually decrease?
• Did the problem simply move somewhere else?
• Did the change improve availability while damaging quality?
• Did it work across different products, crews, and shifts?
• Did maintenance, material, scheduling, or another process change influence the result?
A single successful production run is not proof. Continuous improvement needs enough evidence to separate a repeatable improvement from a lucky shift.

GEMBA AND DATA NEED EACH OTHER
Data does not replace Gemba. Operators, supervisors, technicians, planners, and quality teams understand production conditions that systems often cannot capture. A machine record may show a ten-minute stop, while an operator knows that the stop happened because a component felt wrong, a normal material route was blocked, or the previous shift left the station in an unusual condition. At the same time, observation alone shows only one shift, one event, or one version of the problem. Connected operational data makes it possible to test whether an observation repeats across orders, products, machines, shifts, material batches, and longer periods of time.    

Gemba helps teams identify where to look and which questions matter. Operational data helps test those questions across the real production pattern. Standard work then carries the learning forward so the next shift does not start from zero.

START WITH THE IMPROVEMENT QUESTION
One of the biggest mistakes in manufacturing analytics is beginning with the data that happens to be available. A modern production line can generate huge volumes of information from PLCs, sensors, MES systems, ERP, quality systems, maintenance applications, and spreadsheets. More data does not automatically create better decisions. A useful improvement process starts with the production question the team actually needs to answer.

Instead of asking “What data do we have?”, ask “What production question are we trying to answer?” A statement such as “changeovers take too long” is still too broad. A better question would be: Why does changeover time vary significantly for the same product family on the same production line? That immediately helps define the context that matters.   
• Previous product
• Next product
• Production order
• Resource or line
• Tool configuration
• Material
• Shift or crew
• Setup start
• Restart time
• First acceptable unit
• Stable production
• Quality results
• Machine alarms
The goal is not to collect everything. The goal is to collect the smallest set of facts capable of changing the improvement decision.

ERP EXPLAINS THE PLAN
ERP provides the commercial and planning context around production. It can show planned quantities, routing, customer commitments, material requirements, order priority, and the intended production sequence. That context matters because production conditions constantly change. A countermeasure might genuinely reduce setup time while delivery performance still deteriorates because the production mix changed or planners introduced more frequent product transitions.
ERP therefore helps explain what was supposed to run, in what sequence, for which demand, with which routing and materials. But ERP primarily describes intent. It does not necessarily describe what physically happened on the shop floor.  

MES EXPLAINS WHAT ACTUALLY RANThe Manufacturing Execution System fills part of that gap. MES can provide the execution history behind an order, including actual operation start and finish, produced quantity, rejects, holds, rework, resources, operator transactions, material consumption, traceability, and reason codes. This allows improvement teams to connect losses with real orders and operations instead of relying on memory or daily averages.   

MES data still needs interpretation. Transactions may be entered late, different crews may use reason codes differently, and a timestamp may represent when an operator confirmed something instead of the exact physical moment when it happened. The system provides evidence, but the process gives that evidence meaning.

MACHINE AND IOT DATA EXPLAIN THE PHYSICAL PROCESS
When teams need to understand what happened inside an operation, machine data becomes important. PLC and IoT signals can expose machine states, cycle times, alarms, speed, temperature, pressure, interlocks, motor load, restart behavior, and time to stable production. MES may show that an operation restarted at a particular time, while machine data explains what happened during the minutes before stable output returned. 
• Repeated alarms
• Reduced speed after restart
• Temperature recovery
• Manual adjustments
• Interlocks
• Unstable cycle times
Machine data without production context can still be misleading. An alarm becomes much more useful when it can be connected to the work order, product, operation, resource, tool condition, material, and quality result surrounding the event.

THE SHOP FLOOR ADDS MEANING
Operators, maintenance technicians, supervisors, and quality teams fill the gaps that automated systems cannot. A reason code such as “material issue” may describe very different situations in practice. The material may have arrived late, behaved differently, carried an incorrect label, been damaged, or created a downstream problem that only became visible later.

Structured codes help categorize events. Human context helps explain them. Data capture therefore needs to fit the reality of production instead of interrupting it. The useful question is not how much information an operator can enter, but what is the smallest human input that would make the next improvement decision better.    

YOU NEED A SHARED FACTORY LANGUAGE
ERP, MES, maintenance systems, historians, and spreadsheets can all describe the same production event differently. One system may call a resource “Line 3,” another may use “LINE03,” maintenance may track several separate assets inside the line, and a historian may still use an old PLC tag. All of these identifiers can technically be correct while still making cross-system analysis unreliable.

The same problem applies to definitions. “Production complete” might mean the machine finished, MES posted the quantity, quality released the batch, the product was packed, or the order was ready to ship. A dashboard cannot decide which definition is correct. The organization has to define that shared meaning. Why Continuous Improvement Need…

THE DATA MODEL BEHIND CONTINUOUS IMPROVEMENT
A useful manufacturing data model preserves meaning as information moves between systems. Products, batches, work orders, resources, process steps, shifts, tools, materials, quality outcomes, maintenance conditions, production events, and timestamps need managed relationships so teams do not rebuild the same logic every time they investigate a problem.
• Product
• Product family
• Work order
• Batch
• Process step
• Resource
• Machine or asset
• Shift
• Tool
• Material
• Quality result
• Maintenance condition
• Production event
• Time
Definitions also need ownership and versioning. Downtime, scrap, rework, good count, target rate, and changeover duration should not quietly mean different things in different reports. Products change, recipes change, tools change, machines are upgraded, routes change, and approved target rates change. Without versioning, today's process rules can accidentally be applied to historical production data.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

A temperature reading, a vibration sample, a machine cycle, and a device disconnect may all be described as events, but they do not represent the same architectural problem. In industrial IoT and manufacturing environments, confusing continuous telemetry with discrete events can create noisy workflows, incomplete production histories, unnecessary processing, and systems that react without enough context.

In this episode, we break down the architectural difference between Azure IoT Hub Message Routing and Azure Event Grid by following a realistic manufacturing scenario. A press line continuously sends temperature, vibration, cycle count, energy consumption, and machine-state information through an industrial gateway. Those measurements create an operational history that engineers, data teams, maintenance teams, and production systems may need to analyze later. A device disconnect is different because it represents a change that may require another system or person to react.

TELEMETRY IS A RECORD, NOT AN ALERT
Telemetry represents repeated measurements over time. A single temperature value or vibration measurement usually tells you very little on its own. The real information exists in the sequence: how quickly values changed, what the machine was doing at that moment, what happened before a stop, whether measurements disappeared during a network interruption, and whether the same behavior appeared in earlier production runs.


Typical industrial telemetry includes:
• Temperature, vibration, pressure, energy consumption, and current draw
• Machine states such as running, idle, stopped, or faulted
• Cycle counts, production counters, and process measurements
• Source timestamps, device identifiers, sequence numbers, and correlation information

Those records may later support condition monitoring, quality investigations, energy analysis, OEE calculations, Microsoft Fabric analytics, Power BI reporting, and production optimization. That is why telemetry needs retention, replay, duplicate handling, independent consumers, and a reliable way to reconstruct the production timeline.

IOT HUB MESSAGE ROUTING AS THE TELEMETRY DATA PLANE
Azure IoT Hub provides the controlled device-to-cloud boundary. Devices and gateways authenticate with their own identities, send device-to-cloud messages, maintain device-management state, and can participate in controlled cloud-to-device communication.

Once a telemetry message reaches IoT Hub, Message Routing determines where that data should go. Routing can inspect message properties, system properties, parts of the message body, and device twin information. This makes it possible to separate production telemetry, energy measurements, diagnostics, or other message classes before they reach downstream consumers.
A common architecture might look like this: Industrial gateway → Azure IoT Hub → Message Routing → Event Hubs or Storage → Processing → Microsoft Fabric.

One consumer may perform near-real-time analysis while another keeps a raw archive. A third consumer may prepare curated operational data for Microsoft Fabric. Each consumer can work independently without turning every telemetry reading into a workflow invocation.

WHY ORDERING MATTERS
Industrial telemetry is particularly sensitive to sequence. Imagine a machine reporting that it entered a running state, then transmitting several cycle counts, followed by a process deviation and finally a stopped state. If those records are reconstructed incorrectly, a downstream system could conclude that the machine produced parts while stopped or that a process deviation happened after production had already ended.

The same problem affects downtime calculations, OEE, production counts, and condition monitoring. You therefore need to distinguish between when the source observed something, when IoT Hub received the message, and when a downstream system processed it.

A robust telemetry architecture should therefore consider:
• Source timestamps and cloud receipt timestamps
• Stable partitioning appropriate to the asset or workload
• Message IDs or sequence numbers for duplicate detection
• Idempotent consumers capable of handling at-least-once delivery

Network interruptions make this especially important. A gateway may buffer telemetry and send it when connectivity returns, which means Azure arrival time may be much later than the actual machine timestamp.

EVENT GRID SOLVES A DIFFERENT PROBLEM
Azure Event Grid is designed around publish-and-subscribe notifications. Instead of continuously reconstructing the state of a machine from thousands of readings, Event Grid tells interested systems that something changed and gives subscribers an opportunity to react.
Examples in an IoT environment include device creation, device deletion, connection, disconnection, or carefully selected telemetry-derived conditions. A device-created event might trigger an asset onboarding process. A device-disconnected event might start a technical investigation. A detected engineering condition might trigger a maintenance workflow.

Typical subscribers include:
• Azure Functions
• Logic Apps
• Webhooks
• Security workflows
• Asset-management systems
• Operational applications

The fundamental architectural difference is simple: telemetry asks what an asset has been doing, while an event asks what changed and whether something should react.

EVENTS SHOULD START INVESTIGATIONS, NOT DEFINE REALITY
Event Grid should generally be treated as a notification mechanism, not as the final authoritative state of the physical world. Event delivery can be repeated, and events are not something a subscriber should blindly interpret as the final current state without checking.
A device-disconnected event should therefore usually trigger a state check. An Azure Function might verify the current device state, inspect recent telemetry, check relevant registry information, and then decide whether the investigation should remain open.

Handlers should be designed around:
• Idempotent processing
• Current-state verification
• Event identity and timestamps
• Clearly defined ownership of the resulting action

This matters because duplicate events should not create duplicate tickets, duplicate alerts, or conflicting operational records.

A DEVICE DISCONNECT DOES NOT MEAN THE MACHINE STOPPED
One of the most important distinctions in industrial IoT is the difference between cloud connectivity, data-collection health, and production state. If an industrial gateway disconnects from IoT Hub, the cloud has lost visibility into that gateway. That does not automatically mean that the physical machine stopped.

The PLC may continue controlling the equipment locally while the gateway temporarily loses connectivity. Production may continue normally, and the gateway may even buffer telemetry and upload it later. The opposite can also happen: a gateway may remain connected to Azure while its connection to the PLC or local equipment has failed.

A useful architecture therefore separates cloud connection state, gateway health, machine production state, and MES work-order state. Only by combining those sources can the business determine whether a technical connectivity issue actually affected production.

FILTERING IN IOT HUB VS FILTERING IN EVENT GRID
Both technologies support filtering, but the purpose is different. IoT Hub Message Routing filtering answers which operational messages should enter a specific data path. Event Grid subscription filtering answers which notifications a particular subscriber should receive.

For example, production telemetry may go to one Event Hubs stream while energy data goes to another destination. At the same time, a support workflow may subscribe only to disconnected events from a particular group of gateways.

Confusing those two types of filtering often results in an architecture where every subscriber creates its own interpretation of the telemetry stream. A cleaner design keeps broad telemetry classification governed centrally and keeps Event Grid subscriptions focused on clearly defined reactions.

THE MANUFACTURING CONTEXT LIVES OUTSIDE THE MESSAGE BUS
Neither IoT Hub nor Event Grid knows what a machine means to the business. A device ID may identify a gateway, but it does not inherently know which production line the gateway belongs to, which machine it observes, which work order is running, whether a stop is planned, or whether production is already at risk.

That context usually comes from multiple systems. MES provides execution context such as work orders, operations, recipes, production state, and shift information. ERP provides demand, commitments, inventory, and planning information. An asset model connects devices, gateways, PLCs, machines, cells, lines, and sites.

In more advanced architectures, a digital twin or knowledge graph can help maintain those relationships. The result is a more reliable operational picture in which telemetry explains what the equipment reported, MES explains what production was doing, ERP explains why it matters, and the asset model explains how the technical components relate to the physical plant.



Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Azure architecture looks easy when everything works.The real test starts when dependencies fail, regions become unavailable, traffic spikes, assumptions turn out to be wrong, requirements change, and someone eventually asks the uncomfortable question: why did we design it this way in the first place?In this episode of M365.FM, Mirko Peters talks with Mike Martin [MVP] about what Azure architecture looks like when it has to survive real production conditions rather than just look good on a diagram.Mike brings decades of experience across development, infrastructure, architecture, leadership, coaching, training, and Microsoft Azure. One of his strongest observations is that many of the problems architects face today are not actually new. DNS still breaks. IP dependencies still matter. Costs still become a problem. Integrations still fail. Dependencies still disappear at the worst possible moment.What has changed is the level of complexity we build around those problems.

FROM VISUAL BASIC TO MODERN AZURE ARCHITECTURE
Mike looks back at nearly three decades in IT, starting as a Visual Basic developer in the 1990s and moving through distributed systems, networking, enterprise software, infrastructure, and eventually Azure.His key observation is simple: the industry keeps solving many of the same fundamental problems, but the architectures around them have become much more complex.Modern systems have moved from client-server applications to distributed architectures, cloud platforms, containers, microservices, Kubernetes, hybrid environments, and now AI-assisted development.That creates enormous possibilities, but it also creates a new risk: overengineering.Mike argues that many teams today make simple problems unnecessarily complicated. Good architecture is often not about adding more technology. It is about knowing what not to add.

WHAT DOES AN AZURE ARCHITECT ACTUALLY DO?
For Mike, architecture is not about choosing the largest number of Azure services or producing an impressive diagram.It is about understanding which components belong together, which ones should be avoided, which ones are necessary, and how to build something that remains maintainable, scalable, secure, and resilient.Architecture includes much more than compute.

• Identity
• Networking
• Data flows
• Security
• Monitoring
• Integration
• Dependencies
• Scalability
• Operations
• Recovery
• Deployment
• Cost

Mike also challenges the idea that cloud-native automatically means Kubernetes or containers.Azure provides many managed and native services that can solve problems without introducing unnecessary operational overhead.The architect’s role is to understand the complete solution and choose the simplest architecture that still satisfies the real requirements.

START WITH BUSINESS REQUIREMENTS, NOT AZURE SERVICES
One of the most important lessons in this episode is simple: do not start with technology.Before deciding between Azure Kubernetes Service, App Service, Azure Functions, containers, Service Bus, or another platform, teams should first understand what the solution actually needs to do.Questions to ask:

• Is it internal or customer-facing?
• How many users will depend on it?
• Does it need to scale globally?
• How long can it be unavailable?
• How much data can the business afford to lose?
• Which compliance requirements apply?
• What happens if the application disappears for several hours?
• Who is affected?
• What level of operational support is required?

These questions lead directly into concepts such as SLAs, SLOs, RTOs, and RPOs.They also determine whether the architecture should be single-region, multi-region, active-active, active-passive, or something much simpler.

RTO AND RPO WITHOUT THE BUZZWORDS
RTO and RPO are often discussed as technical acronyms, but their real meaning is business-oriented.

• RTO — Recovery Time Objective: How quickly must the system return after a failure?
• RPO — Recovery Point Objective: How much data loss is acceptable?

A system used for non-critical monitoring may tolerate several hours of downtime or lost data.A system supporting first responders, financial operations, commerce, or critical infrastructure may require recovery in minutes.The important point is that these numbers should not be invented by the architect.They should come from the actual business impact of failure.Once those requirements are understood, they can be translated into technical design decisions.

RESILIENCE IS NOT THE SAME AS HIGH AVAILABILITYMike uses a simple analogy to explain the difference between availability and resilience.A highly available system may have another component ready to take over when the primary one fails.A resilient system is designed to absorb problems, continue functioning, recover gracefully, and return to normal without collapsing completely.That distinction matters.An application can technically be available while still providing a poor experience.It may be:

• Slow
• Throttled
• Partially unavailable
• Dependent on a failing backend
• Affected by an integration issue
• Under regional pressure

Real resilience therefore requires more than uptime.It requires an architecture that can cope with load, application errors, partial failures, regional issues, broken dependencies, operational incidents, and recovery after the incident has passed.

AZURE DOES NOT MAKE YOUR APPLICATION RESILIENT AUTOMATICALLY
One dangerous assumption is that because Azure itself is highly available, any application running on Azure automatically inherits that resilience.It does not.Microsoft provides the services and capabilities that make resilient architectures possible.Customers still need to design for resilience.This is where architectural patterns matter:

• Circuit breakers
• Loose coupling
• Asynchronous processing
• Independent scaling
• Multiple availability zones
• Multiple regions
• Failover mechanisms
• Monitoring
• Infrastructure as Code
• Tested recovery procedures

Microsoft provides the building blocks.The architecture determines whether those building blocks actually create a resilient system.

WHY ASYNCHRONOUS DESIGN MATTERS
One of the strongest examples in the episode comes from systems that experience predictable traffic spikes, such as government tax portals.A common design problem occurs when every action depends on a synchronous backend operation.The user clicks a button.The frontend waits for the backend.The backend waits for another service.Another dependency slows down.Eventually the entire user experience is affected.Mike explains why loosely coupled systems are often more resilient.Instead of forcing the frontend to wait for every backend operation, applications can place work into queues or event-driven systems and allow components to process tasks independently.That creates several advantages:

• Different components can scale independently
• One service can fail without taking down the whole platform
• Backends can process work asynchronously
• Traffic spikes become easier to absorb
• User-facing components become less dependent on backend timing
• Failures become easier to isolate

THE MYTH OF 100 PERCENT UPTIME
Another major topic in the discussion is the obsession with 100 percent availability.Mike is very clear: 100 percent uptime is not a realistic architecture target.A solution is usually composed of multiple services.Each service has its own SLA.Once several dependencies are combined, the effective availability of the complete system changes.A better architecture focuses on:

• Fallback scenarios
• Recovery procedures
• Redundancy
• Failover
• Monitoring
• Mitigation strategies
• Tested recovery plans

The better question is not: how do we guarantee zero downtime?The better question is: what happens when something fails, and how quickly can the business continue operating

WHEN ANOTHER NINE BECOMES TOO EXPENSIVE
More availability is not automatically better.Every additional level of resilience introduces cost, infrastructure, monitoring, operational complexity, and management overhead.Whether that investment makes sense depends entirely on the business impact of failure.An internal holiday request system can probably tolerate several hours of downtime.An order-processing platform handling millions in transactions cannot.Questions that matter:

• How much money is lost during downtime?
• How many users are affected?
• What happens to customer trust?
• What happens if an API becomes slow?
• What happens if orders cannot be processed?
• What does another level of redundancy actually cost?
• Is the additional availability worth that cost?

Reliability is ultimately an economic decision as much as a technical one.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Your production schedule can look perfectly reasonable when it leaves the ERP system. Order dates line up, routing times make sense, capacity appears available, and material status suggests that production is ready to go. The problem is that the schedule is still only an assumption about the future.The moment production begins, the factory starts generating new facts. Material arrives later than expected, a batch is still waiting for quality inspection, a fixture is unavailable, an operator with a required qualification is missing, or a machine loses capacity because of a short interruption. The original schedule may have been correct when it was created, but the conditions behind it can change within minutes.This episode explores why static production schedules lose accuracy so quickly, why ERP planning is not necessarily the problem, and why modern manufacturing needs a closed feedback loop connecting planning, shop-floor execution, production data, learning, and replanning. The central argument is that a schedule is a decision about what production should try to do based on the information available at that moment. It is not a guaranteed description of what the factory will actually be able to execute. Why Your Production Schedule Is…

WHY PRODUCTION SCHEDULING BREAKS DOWN
Every scheduled production operation contains multiple hidden assumptions. A planned start time assumes that the previous job finishes on time, the machine remains available, the required material is usable, the correct tool or fixture is ready, and a qualified operator is present.It may also assume that setup duration remains realistic, that actual cycle time stays close to the routing standard, that quality releases the material as expected, and that another more urgent order does not suddenly compete for the same resource.That means a production schedule is not simply a table containing orders, dates, quantities, and machines. It is a collection of assumptions about future operating conditions.Typical assumptions include:

• Machine availability
• Material readiness
• Tool and fixture availability
• Operator qualifications
• Setup duration
• Cycle time
• Quality release
• Resource capacity
• Production sequence
• Customer priorities

The schedule becomes unreliable when those conditions change but the decision is not updated.

ERP PLANNING IS NOT THE PROBLEM
ERP remains one of the most important systems in manufacturing. It connects customer orders, inventory, bills of material, purchasing, routings, work centers, due dates, and business commitments.ERP provides the commercial intent behind production. It tells the organization what should be produced, which demand needs to be covered, which materials are required, and which customer commitments matter.The limitation appears when ERP planning is expected to understand every operational condition on the shop floor at every moment.A work center may appear available while the required fixture is still installed somewhere else. A material receipt may exist in ERP while the batch is still waiting for inspection. A person may appear on the workforce calendar while lacking the specific qualification required for the next operation.The ERP system is not necessarily wrong. The factory has simply produced newer information.

PRODUCTION PLAN VS DETAILED SCHEDULE VS DISPATCH LIST
One reason production planning becomes confusing is that several different decisions are often described using the same word: schedule.A production plan usually works at a broader level. It determines what demand needs to be covered, which product families should be produced, and whether enough capacity and material appear to exist across a longer planning horizon.A detailed production schedule moves closer to execution. It determines which operation should run on which resource, in what sequence, and within which time window.A dispatch decision operates even closer to the shop floor. It answers the practical question: what should this machine, operator, or work center run next based on the conditions we know right now?These decisions are connected, but they are not identical. The closer production gets to execution, the more important current operational conditions become.

WHY EXCEL BECOMES THE UNOFFICIAL MANUFACTURING CONTROL SYSTEM
When the official production schedule no longer matches the factory, planners frequently move into Excel. The reason is simple: Excel reacts faster.A planner can change priorities, reorder jobs, add comments, highlight material issues, record tooling problems, and send a revised sequence within minutes.That flexibility is valuable when the factory needs an operational decision immediately.The spreadsheet itself is therefore not necessarily the underlying problem. It often exposes a capability that the formal production system does not currently provide.The deeper issue appears when the production decision becomes fragmented across different places:

1. ERP contains the original production intent.
2. Excel contains exceptions and manual schedule changes.
3. Supervisors hold the immediate operational sequence.
4. Operators hold practical knowledge about what can actually run.
5. Emails, calls, whiteboards, and shift handovers carry additional context.

Once this happens, no single system represents the complete production state.The episode describes Excel as the place where exceptions, calls, and practical decisions accumulate because it can respond faster than the formal process. Why Your Production Schedule Is…

THE CLOSED-LOOP PRODUCTION MODEL
The solution is not simply to regenerate the schedule more often. Manufacturing needs a controlled feedback loop.A practical closed-loop production model follows five stages:

1. PLAN — Use demand, capacity, routings, material, and business priorities to create the initial production decision.
2. EXECUTE — Release work to the shop floor and observe what actually happens.
3. MEASURE — Capture events that materially change the assumptions behind the plan.
4. LEARN — Compare planned assumptions with repeated production behavior.
5. REPLAN — Use the current production state to create the next feasible dispatch decision.

This changes the objective of scheduling. Instead of trying to create one perfect schedule and defend it against reality, the organization builds a process capable of reacting when reality changes.

EXECUTION PRODUCES FACTS THAT PLANNING COULD NOT KNOW
Once production begins, every operation creates information that can change the remaining schedule.An operation may start late. A setup may take longer than expected. A machine may stop for twenty minutes. A quality issue may block a batch. Scrap may reduce the quantity available for the next operation. Rework may create additional demand on an already constrained resource.These are not just historical records for a weekly production report.They change what the factory can do next.For example, if an operation finishes one hour late, every downstream operation may shift. If a batch is blocked by quality, another work center may suddenly have unused capacity. If rework sends material back through an earlier operation, the rework now competes with planned production for the same machine.A useful scheduling system therefore needs execution feedback while the schedule is still active.

MEASURE AT THE LEVEL OF THE PRODUCTION DECISION
Manufacturing environments already generate huge volumes of machine and process data. The problem is not always a lack of data.The problem is often a lack of context.A machine reporting a twenty-minute stop tells you that capacity was lost. It does not automatically tell you which customer order was affected or which production decision should change.To support production scheduling, an event should ideally connect to information such as:

• Production order
• Operation
• Product
• Batch
• Resource
• Shift
• Event time
• Reason code
• Current queue
• Downstream dependency

The episode emphasizes that production measurement should operate at the same level where scheduling decisions happen: order, operation, resource, and time. Why Your Production Schedule Is…Department-level totals may tell you that output was below plan, but they cannot necessarily explain which operation consumed unexpected capacity or whether the next scheduled job is still feasible.

OEE DOES NOT DECIDE WHAT SHOULD RUN NEXT
Overall Equipment Effectiveness remains a useful manufacturing metric because it helps organizations understand equipment availability, performance, and quality.But OEE and production scheduling solve different problems.A machine can have strong OEE while production still misses an important customer delivery because the wrong work was placed in front of the bottleneck.Likewise, poor OEE does not automatically tell the planner what sequence should run for the rest of the shift.Production scheduling needs additional information such as actual cycle time, queue time, material readiness, tool availability, workforce qualifications, quality status, setup requirements, and customer priorities.OEE can help explain resource performance. Scheduling must determine how limited resources should be used across competing work.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Microsoft 365 Copilot can help people find information and get work done faster, but its answers depend on the content and permissions already in an organization’s Microsoft 365 tenant. In this episode of the M365 FM podcast, Mirko Peters speaks with Microsoft MVP Paul Keijzers, founder of KB Works, about preparing Microsoft 365 for Copilot in a practical, responsible way. They look beyond demos and licensing to the foundations that shape Copilot results: SharePoint, Microsoft Teams, OneDrive, data quality, access controls and governance. Copilot can make existing access issues more visible. Files that have been shared broadly, outdated documents, old versions and content with unclear ownership may all affect what employees can find. Paul explains why organizations should review their sharing settings and understand where sensitive or unnecessary access exists before rolling Copilot out widely. SharePoint oversharing reports can help identify potential issues across SharePoint, Teams and OneDrive, although organizations still need to check whether flagged sharing is appropriate for their business.

GOVERNANCE, LEGACY DATA AND INFORMATION PROTECTION
The conversation explores how to manage years of legacy SharePoint content. Old project files may need to be retained for legal or business reasons, but that does not always mean they should appear in everyday search or Copilot results. Organizations can consider archiving content or restricting access, depending on how often it needs to be used and how the tenant is structured. Paul also highlights the need to plan for Microsoft 365 backup and recovery, including how a company can retrieve its data if it changes backup providers. Microsoft Purview is part of the wider governance picture. Paul recommends reviewing sensitivity labels, checking whether they are applied consistently, and considering automatic labeling where appropriate. Data Loss Prevention policies can help protect personal and sensitive information, while Power Automate DLP policies need attention when Copilot uses connectors to work with services such as Jira. These controls should fit the organization’s actual needs, since a global company and a small business may require different policies.

SHAREPOINT STRUCTURE AND COPILOT ADOPTION
Good information architecture remains important even as AI becomes better at understanding natural language. Paul discusses using metadata and content types to make information easier to organize and retrieve, while keeping SharePoint libraries practical for employees. His guideline is to avoid overly deep folder structures and excessive metadata fields, since people are less likely to maintain a system that is too complicated. Copilot can help suggest or populate information, but organizations still need a clear structure and reliable content. Copilot adoption also requires ongoing support. Rather than delivering a single training session and expecting employees to figure out the rest, organizations can share regular tips, demonstrate useful prompts and agents, and help teams solve real daily frustrations. Paul recommends starting with the work people actually do, then identifying where Copilot could save time or improve an outcome. Adoption plans should be adapted to the size and working practices of each organization instead of copied wholesale from a framework designed for a different environment.

AI VALUE, AGENTS AND A PRACTICAL PATH FORWARD
Mirko and Paul also discuss how organizations can assess the value and cost of AI, how agents may increasingly work alongside employees, and why administrators need ways to discover and manage agents in their environments. Paul shares his Focus Week concept in Portugal, where teams spend dedicated time working on Microsoft 365, SharePoint, governance or Copilot challenges away from their usual workplace interruptions. The central message for IT leaders is that Copilot readiness starts with understanding the Microsoft 365 tenant: who can access what, how information is organized, which content should be retained or surfaced, and how employees will learn to use AI in their work. Review sharing settings, improve information governance and connect adoption to real business needs before treating Copilot as simply another license to deploy.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Microsoft Exchange and Microsoft 365 make it possible to run powerful messaging environments, but moving email to the cloud does not automatically make it secure. In this episode of the M365 Show, host Mirko Peters [MVP] talks with Thomas Stensitzki [MVP] about the security gaps that can hide in Exchange Server, Exchange Online, and hybrid deployments. Drawing on more than 25 years of messaging experience, Thomas explains how identity protection, careful configuration, secure mail flow, and operational discipline work together to protect an organization’s email.

FROM EXCHANGE SERVER TO HYBRID AND EXCHANGE ONLINE

Thomas shares how he built his career around Exchange and why email remains essential to business. He explains how a hybrid setup connects on-premises Exchange Server with Exchange Online, and why that connection needs careful planning across messaging, networking, and security teams. Microsoft 365 provides a working service with default settings, but organizations still need to configure protections such as anti-spam, anti-malware, and anti-phishing to fit their needs.

IDENTITY, ADMINISTRATOR ACCESS, AND BREAK-GLASS ACCOUNTS
Identity security comes first, including for service accounts and other non-human identities. Thomas discusses sensitive Exchange administrator roles, privileged access management, and why administrators should avoid using highly privileged accounts for everyday work. He also explains how to protect emergency or “break-glass” accounts, including the role of FIDO security keys and the need to plan how administrators can regain access during an outage.

LEGACY SMTP, PHISHING, AND COMPROMISED ACCOUNTS
Older applications and devices may still depend on basic authentication or legacy SMTP. Thomas recommends avoiding those methods where possible and describes how an on-premises relay can help route messages from systems that cannot use modern authentication. The conversation also follows a potential attack path from a malicious email to stolen credentials and unauthorized access, highlighting the value of email filtering, separate administrative accounts, and monitoring sign-in activity.

MAIL FLOW, SPF, DKIM, AND DMARC
Understanding the full route an email takes is essential, especially in complex environments that combine gateways, Exchange Server, Exchange Online Protection, and Microsoft Defender. Thomas explains the roles of SPF, DKIM, and DMARC in authenticating messages sent from an organization’s domain. He also recommends using dedicated subdomains for third-party services such as marketing platforms and CRM systems, and using DMARC reports to identify legitimate and suspicious senders.

MICROSOFT DEFENDER AND SECURITY MONITORING
Thomas discusses Microsoft Defender for Office 365 Safe Links and how link protection can help assess a URL when a user clicks it. He also covers Entra sign-in logs, suspicious sign-ins, and impossible-travel alerts. Security tools and scores can guide decisions, but administrators still need to understand what they measure, what their licenses include, and which protections their organization actually needs.

CONFIGURATION, GOVERNANCE, AND OPERATIONAL DISCIPLINE
The discussion moves beyond individual security settings to configuration management, least-privilege access for programmatic tools, and the risks of exposing Microsoft 365 content through APIs or agents. Thomas explains how configuration exports can help teams track changes. He also discusses Microsoft Purview sensitivity labels and data loss prevention (DLP), recommending that organizations plan their rollout carefully because these controls can be difficult to change once they are in production.

BUSINESS CONTINUITY, AI, AND KEEPING EXCHANGE SECURE
Backups alone may not be enough if an organization loses access to its Microsoft 365 tenant, domains, or configuration. Thomas stresses the importance of planning for business continuity before an incident occurs. He also considers how AI may help both defenders and attackers, and describes his consulting work helping organizations update Exchange Server environments and move to Exchange Online or hybrid configurations.

RAPID-FIRE QUESTIONS AND FINAL SECURITY ADVICE
In the rapid-fire round, Thomas chooses Exchange Server, a long-term hybrid architecture, and PowerShell. He also discusses Exchange Server certificate management and recommends Manfred Huber as a future guest. His closing advice is straightforward: keep Exchange environments up to date, follow the Exchange Product Group blog, apply patches, watch for default configuration changes, and prepare for the deprecation of Exchange Web Services in Exchange Online.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Invoices, contracts, receipts, forms, scanned PDFs, and email attachments contain valuable business information — but most automation still struggles to turn those documents into reliable, structured data.

In this episode of M365 FM – Simply Explained, we break down Microsoft Content Understanding, Document AI, OCR, AI Builder, Power Automate, Dataverse, and Power Apps and explain how they work together to transform documents into usable business data and automated processes.

You’ll learn why traditional OCR is only the beginning. OCR can recognize text such as an invoice number or amount, but it does not automatically understand whether a number represents an invoice ID, purchase order, bank account, tax value, or phone number. Document AI adds context, structure, and business meaning to extracted information.
We explain how Microsoft Content Understanding can take documents and images, extract defined fields, classify information, and return structured results that downstream systems can use. Instead of asking AI to summarize an entire document, organizations can define a schema containing fields such as supplier name, invoice date, invoice number, invoice total, document type, and line items.

The episode also shows how Microsoft Power Platform turns document extraction into a complete business workflow. Power Automate can detect new documents in email or SharePoint, send them for extraction, validate the returned information, create records, trigger approvals, and route exceptions to the right person.

Dataverse can store structured document records and process history, while Power Apps can provide a human review interface for correcting uncertain or missing information.
We also cover one of the most important parts of Document AI: confidence scores and human-in-the-loop review. A high confidence score does not automatically mean a value should be trusted.

Critical information such as invoice totals, payment instructions, bank details, or contract dates may still require additional validation against business rules and existing systems.
You’ll discover how validation can check whether suppliers exist, purchase orders match, totals make sense, dates are valid, and duplicate invoices have already been processed.
This combination of AI extraction, validation rules, governance, and human review is what turns Document AI from an impressive demo into a reliable business process.

We also look at practical first use cases including invoice processing, employee onboarding forms, claims, contract expiry dates, supplier documents, procurement workflows, HR documents, legal documents, service requests, and customer forms.

The key is to start with one document type, one clear decision, a defined owner, and a review path for exceptions.

By the end of this episode, you’ll understand the complete Document AI pattern:
Document → Content Understanding → Structured Data → Validation → Power Automate → Dataverse → Human Review → Business Action

The goal is not simply to process more PDFs. It is to stop people searching through documents for basic information and instead move structured, validated data directly into the business process where decisions happen.

Subscribe to M365 FM for practical episodes about Microsoft Content Understanding, Power Platform, Power Automate, AI Builder, Microsoft AI, automation, Copilot, document processing, and the future of work.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

A machine sends temperature readings, vibration data, cycle counts, power consumption, and operating states every few seconds. Then the gateway suddenly disconnects. Are all of those messages simply “events”? Technically, you could describe them that way. Architecturally, that can create serious problems. Azure IoT Hub Message Routing and Azure Event Grid solve different problems. One path is designed around preserving and distributing operational data. The other is designed around notifying systems that something changed and may require a response. Treating them as interchangeable can leave you with expensive workflows processing routine sensor data—or important signals buried inside a telemetry pipeline nobody is actively watching. In this episode of M365 FM, we follow a manufacturing machine through a real Azure IoT architecture and explain where IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions, and Logic Apps actually belong.

WHAT YOU WILL LEARN
In this episode, we explore:

• Why machine telemetry and discrete business or lifecycle events require different architecture patterns
• How Azure IoT Hub Message Routing works as part of a telemetry data plane
• Where Azure Event Grid fits into event-driven and reactive architectures
• Why message ordering matters for manufacturing telemetry
• Why Event Grid should not become your primary high-volume telemetry bus
• Why IoT Hub routing should not be forced into every notification workflow
• How IoT Hub and Event Grid can work together in the same architecture
• How Event Hubs can support independent stream-processing consumers
• Why raw telemetry should often be retained for traceability and later investigation
• How Microsoft Fabric and Power BI can consume prepared operational data
• Why MES, ERP, and asset models provide context that device data alone cannot provide
• How device disconnect events should be interpreted without automatically assuming production stopped
• How duplicate delivery, retries, timestamps, and idempotency affect reliable industrial architectures
• How to design condition monitoring, predictive maintenance, quality traceability, and production-disruption workflows
• How to decide whether a message belongs on the data plane, the response path, or both

TELEMETRY IS A RECORD OVER TIME
Telemetry is not valuable because one temperature reading arrived. It becomes valuable because thousands of readings together describe what happened. A production machine may continuously report:

• Temperature and vibration measurements
• Motor current and energy consumption
• Cycle counts and production counters
• Running, idle, stopped, or faulted states
• Source timestamps and sequence information
• Diagnostic and equipment-health information

A single temperature value might mean very little. The sequence around that reading tells the story. Was the machine warming up? Was it already producing? Was vibration increasing at the same time? Did cycle time begin to increase? Did the machine stop shortly afterward? Telemetry therefore needs a path designed around sequence, retention, replay, independent consumers, and traceability.

EVENTS EXIST TO START A RESPONSE
An event serves another purpose. An event says: Something changed. A system or person may need to react. Examples include:

• A new device was registered
• A gateway disconnected from IoT Hub
• A device reconnected
• A device was deleted
• A monitoring process detected a condition requiring investigation
• An inspection completed and another workflow can begin

The recipient usually does not need hours of telemetry before starting the first step. It needs enough information to identify what happened and determine the appropriate response. That response might involve:

• Starting an Azure Function
• Triggering a Logic App
• Opening a support investigation
• Updating an asset record
• Checking the current device state
• Calling an external application through a webhook
• Notifying the team responsible for the affected system

The event starts the investigation. It does not necessarily contain every fact needed to make the final operational decision.

WHY “EVERYTHING IS AN EVENT” BREAKS DOWN
Sending every sensor measurement into event-triggered workflows can look attractive during a proof of concept. Then production scale arrives. Every reading triggers another Function. Another Logic App evaluates something. Another integration receives another message. Maintenance creates its own subscription. Quality creates another. Energy management creates another. Soon, every team has slightly different filtering, state management, retry handling, and storage logic. A temperature measurement is not automatically an incident. It may contribute to an incident later, but the continuous measurements should remain available as evidence. When routine telemetry starts generating constant notifications, users can also begin ignoring alerts because the system has trained them to expect noise rather than actionable information. 

WHAT AZURE IOT HUB ACTUALLY DOES
Azure IoT Hub provides the device-facing cloud boundary. It supports areas such as:

• Secure device identities
• Device-to-cloud messaging
• Cloud-to-device communication
• Device management
• Device twins
• Controlled access between connected equipment and Azure services

IoT Hub knows that an authenticated device sent a message. It does not automatically understand what that message means to production. A gateway might report: state = running But “running” could mean:

• Producing approved parts
• Dry cycling
• Running setup
• Performing rework
• Moving without material

That context usually comes from additional systems such as the MES, ERP, asset model, or production application.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

AI was supposed to clear the backlog, accelerate decisions, and give every team a smarter way to work. Instead, many organizations now have Microsoft Copilot, Power BI, Microsoft Fabric, AI agents, and more data than ever before—while important decisions still crawl through meetings because nobody fully trusts the numbers or knows who can act on them. The technology spend keeps rising. The action does not. The problem is often not a lack of AI. It is the absence of an operating model connecting data, meaning, governance, technology, people, and accountability. In this episode of M365 FM – Simply Explained, we break down the five pillars organizations need to build a reliable foundation for data transformation and AI.

WHAT YOU WILL LEARN
In this episode, we explore:

• Why AI cannot compensate for unreliable data
• How data governance creates trust before automation begins
• Why data quality should depend on the decision being made
• How Microsoft Purview can support governance and data discovery
• How Microsoft Fabric supports modern analytics and data platforms
• Why semantic models matter for Power BI and AI
• How conflicting definitions create conflicting dashboards
• Why business glossaries matter for humans and AI agents
• How data ownership affects AI readiness
• Why access, security, and permissions must be defined before AI scales
• How Copilot and AI agents depend on trusted business context
• Why human accountability remains critical even when AI generates the answer

PILLAR 1: DATA GOVERNANCE – TRUST BEFORE AUTOMATION
Data governance often sounds like policies, compliance meetings, documentation, and bureaucracy. In practice, governance answers a few very simple questions:

• Who owns this data?
• Who is allowed to access it?
• Where did the data come from?
• Can we trust it for this particular use case?
• What are people allowed to do with it?
• What are AI systems allowed to do with it?

Without clear answers, AI does not solve a data problem. It can spread the problem faster. Imagine a leadership team preparing a sales forecast. Sales presents one revenue number. Finance presents another. Both numbers come from systems that appear authoritative. The meeting suddenly stops being about future decisions. Instead, everyone starts arguing about which spreadsheet or dashboard is correct. The underlying problem may be that:

• The CRM contains one version of revenue
• The finance system contains another
• Manual exports introduce additional differences
• Nobody owns the definition of revenue
• Nobody owns the quality of the source data
• Nobody can clearly explain which number should drive the forecast

The company ends up debating the past instead of deciding the future.

WHAT HAPPENS WHEN AI ENTERS THE PICTURE?
Now imagine someone asks an AI agent: “Which sales region is falling behind?” The answer may arrive within seconds. But it could be based on:

• Duplicate customer records
• Outdated account assignments
• Missing opportunities
• Incorrect forecast stages
• Old data
• Incorrect permissions
• Information the user should not have been able to access

The answer can sound confident. That does not automatically make it trustworthy. Governance creates the working agreement around the data before automation starts using it. A strong governance model typically establishes:

• Named data owners
• Clear responsibilities
• Data classifications
• Access rules
• Source-system documentation
• Data quality expectations
• Auditability
• Policies for sensitive information
• Rules for AI and automation

Microsoft technologies can support this process. Microsoft Purview can help organizations discover, classify, understand, and govern information. Microsoft Fabric can help bring data together, prepare it, analyze it, monitor it, and make it available for reporting and AI scenarios. But technology cannot decide everything. Organizations still need people to decide:

• Who owns customer data
• Which definitions are authoritative
• What data quality is acceptable
• Who should have access
• When an AI-generated answer is safe to use
• Who remains responsible for the final decision

DATA QUALITY MUST MATCH THE DECISION
Many organizations approach data quality as if every field in every system needs to be perfect. That is rarely realistic. Data quality should instead be evaluated against the business decision being made. For a sales forecast, the most important fields might include:

• Opportunity stage
• Expected close date
• Forecast amount
• Account owner
• Territory
• Probability
• Customer status

Other fields may be less important for that specific decision. The better question is therefore not: “How do we clean all of our data?” The better question is: “Which data must we trust for this decision?” That makes the problem smaller, more measurable, and much easier to manage.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Cloud storage may look cheap. Sending factory data to the cloud may look cheap. But the real cloud bill often starts when that data begins moving. In this episode, we break down the hidden costs behind modern Industrial IoT, manufacturing cloud, edge computing, and factory data architectures — from data egress and cross-region replication to NAT gateways, backups, dashboards, and high-frequency sensor data. A single MQTT stream from a factory can quickly become multiple data flows once telemetry is copied into storage, analytics platforms, dashboards, data science environments, disaster recovery systems, and external applications. The machine generated the data once — but your architecture may move it many times.

Why Factory Cloud Costs Grow So Quickly
One of the biggest mistakes in manufacturing IoT architecture is estimating data volume based on the number of machines or connected devices. The better calculation is: Samples × Bytes × Time × Assets A simple machine-state signal may generate very little data. A vibration sensor sampling at 32 kHz is completely different: a single 16-bit channel can generate roughly 5.5 GB of raw data per day before additional protocol and metadata overhead. This episode explores why an edge-first architecture can dramatically change that equation. Instead of continuously uploading every raw measurement, manufacturers can process data close to the machine, retain detailed evidence locally, detect meaningful changes, create aggregates, and send only the information required by cloud consumers. 

What You'll Learn

• Why cloud egress costs can become more important than storage costs
• How MQTT and IoT telemetry can create multiple downstream data flows
• Why device count is a poor way to estimate factory data volume
• How vibration monitoring can generate gigabytes or terabytes of data
• Why cross-region and cross-zone traffic matters
• How NAT gateways and network routing can increase cloud costs
• Why replication, backups, exports, and dashboards create additional data movement
• How to identify duplicate factory data pipelines
• When raw manufacturing data should remain at the edge
• How event filtering and aggregation reduce unnecessary cloud traffic
• Why edge computing should be a processing layer rather than a miniature cloud
• How to design an edge-to-cloud manufacturing architecture around business decisions rather than raw data volume

Edge Computing vs. Sending Everything to the Cloud
The key architectural question isn't:
“Can we send this factory data to the cloud?”
It's:
“What data actually earns the trip?”
High-rate raw signals such as vibration waveforms, diagnostic traces, and vision data can often remain close to the factory. Filtered events and aggregates can move selectively, while production records, quality outcomes, KPIs, and cross-plant analytics are stronger candidates for centralized cloud platforms. The result is not an argument against cloud computing. It is a more deliberate IT/OT architecture in which edge and cloud have different responsibilities.

Topics Covered
Industrial IoT, IIoT, Edge Computing, Cloud Computing, Manufacturing Data, Factory Data, MQTT, OPC UA, Data Egress, Cloud Costs, FinOps, Azure IoT, AWS IoT, Factory Automation, Predictive Maintenance, Vibration Monitoring, Data Architecture, IT/OT Integration, Smart Manufacturing, Industry 4.0, Data Replication, Cloud Networking, Manufacturing Analytics

Who Should Listen?
This episode is for manufacturing IT leaders, OT engineers, cloud architects, IoT architects, data engineers, plant managers, solution architects, and industrial digitalization teams designing or operating connected factory environments.
If your architecture contains a neat arrow labeled “Factory → Cloud,” this episode explains why that arrow deserves a much closer look.


Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

What happens when AI agents start making sense of financial and business data — not just displaying it?In this episode of M365.FM, Mirko Peters talks with Rishi Sapra Microsoft MVP about the architecture required to move beyond traditional dashboards and toward AI-powered, context-aware analytics with Microsoft Fabric, Power BI, Copilot Studio, semantic models, ontologies, and data agents.Organizations already have enormous amounts of information spread across ERP systems, Excel workbooks, Power BI reports, Microsoft Fabric, SharePoint, financial systems, budgets, forecasts, and operational applications.Adding AI on top of that data does not automatically mean the AI understands the business.What does “revenue” actually mean? Which definition of margin should an AI agent use? Which KPIs represent the official version of the truth? And how does an agent understand relationships between customers, products, regions, cost centers, contracts, and business processes?The answer increasingly lies in the context layer between raw data and AI.

FROM SELF-SERVICE BI TO SELF-SERVICE AI
Rishi explains his journey from financial modeling and Excel through Power Query and the early days of Power BI to today's Microsoft Fabric and AI ecosystem.Power BI helped bring business intelligence out of centralized IT departments and into the hands of business users.But the platform has also become significantly more sophisticated.Semantic models, DAX, lakehouses, OneLake, Direct Lake, Copilot Studio, data agents, ontologies, MCP-based tools, governance, and AI now create an architecture that can quickly become difficult for individual business users to understand.AI agents could change that relationship.Instead of requiring every business user to become a data engineer, BI developer, and AI engineer, agents could increasingly build and operate parts of the technical architecture while humans provide the business context.

WHY BUSINESS CONTEXT MATTERS FOR AI
One of the central questions of the episode is surprisingly simple:How well documented are your business processes and decisions?Much of an organization's real knowledge does not live in a database. It exists inside Excel formulas, Power BI measures, SharePoint files, business processes, documentation — and people's heads.For AI agents to produce meaningful business insights, organizations need to capture more than data.They need to capture context.Who is asking the question?What decisions does that person need to make?Which KPIs matter?Which business rules apply?What does a specific metric mean in that particular context?This leads to the concept of persona-driven insights: designing analytics around the decisions and questions of specific business users rather than simply exposing more data.

DATA MODELS VS SEMANTIC MODELS VS ONTOLOGIES
The conversation explores three increasingly important concepts in modern Microsoft analytics architecture.A data model structures the underlying data and relationships.A Power BI semantic model adds business logic, measures, calculations, relationships, and security — creating a governed analytical layer and a reliable source for KPIs.But AI often needs more.An ontology can describe business entities and relationships in a way that allows AI to reason about concepts such as customers, products, stores, employees, regions, contracts, revenue, and business processes.Semantic models help answer:“What is the number?”Ontologies and additional context can help AI investigate:“Why did the number change?”Together, these layers provide much stronger grounding for AI agents.

MICROSOFT FABRIC AS THE DATA FOUNDATION FOR AI
Microsoft Fabric plays a central role in this architecture.OneLake, Lakehouses, Delta tables, semantic models, Direct Lake, Fabric Data Agents, and integration with Copilot Studio can create a unified foundation for structured and unstructured organizational data.The episode also explains why Direct Lake matters.Instead of repeatedly importing and refreshing data into traditional Power BI semantic models, Direct Lake allows Power BI to work directly with data stored in Delta format while maintaining analytical performance.This can significantly simplify the path from enterprise data to analytics and AI.

THE FIVE LAYERS OF AN ORGANIZATIONAL BRAIN
Rishi describes an “organizational brain” built around five interconnected layers:Data — trusted enterprise information and source systems.Logic — DAX, SQL, Python, calculations, KPIs, and business rules.Tools — semantic models, APIs, MCP servers, applications, and other capabilities agents can use.Skills — instructions and business processes describing how agents should use those tools and interpret information.Governance — permissions, policies, security, controls, and rules governing what agents are allowed to do.The goal is not simply to give an LLM access to more data.The goal is to give AI a governed environment in which it understands which data, logic, tools, and processes should be used for a particular business question.

AI AGENTS NEED DETERMINISTIC DATA
Generative AI is powerful because it can reason flexibly.Financial reporting cannot rely entirely on flexibility.Revenue, margins, forecasts, costs, and other business metrics often require deterministic calculations and a governed source of truth.The episode explores why the future of enterprise AI may therefore depend on combining two worlds:Deterministic computing for trusted calculations and business logic.Generative AI for reasoning, interpretation, exploration, and natural-language interaction.Semantic models and Microsoft Fabric can provide the deterministic foundation while AI agents provide the flexible reasoning layer.

FROM DASHBOARDS TO PERSONALIZED INTELLIGENCE
Traditional dashboards tell users what happened.A dashboard might show that revenue decreased by seven percent. The user then needs to drill through dimensions, filters, reports, and datasets to understand why.AI agents can potentially perform much of this exploration automatically.But good storytelling still requires context.The most important number is not always the largest number. A business metric may need to be interpreted relative to revenue, budget, previous periods, organizational structure, or other factors.This is where persona-driven analytics becomes particularly important.The CFO, sales leader, and operational manager may all ask about the same KPI while requiring very different explanations and actions.

COPILOT STUDIO AND THE NEXT GENERATION OF AGENTS
The conversation also explores the evolution of Microsoft Copilot Studio from traditional topic- and knowledge-based chatbot experiences toward more capable agentic systems.Modern agents can potentially combine tools, skills, enterprise data, workflows, and reasoning.That additional capability also introduces additional risk.The more autonomy an agent receives, the more important grounding, permissions, governance, evaluation, and clearly defined instructions become.AI agents should not invent financial numbers or arbitrarily choose data sources.They need trusted semantic models, governed data, explicit skills, and clear guardrails.

MAKING GOVERNANCE GREAT AGAIN
Governance becomes even more important in an agentic organization.Instead of treating governance as a document that employees are expected to read, organizations can increasingly encode governance directly into the environments, policies, skills, and instructions used by AI agents.The discussion explores the idea of treating agents more like digital employees.They need defined responsibilities, approved tools, access permissions, business rules, performance expectations, and boundaries.Governance therefore becomes less about documentation and more about automated enforcement.

THE OPERATING MODEL FOR FABRIC AND AI
Finally, the episode examines how organizations can manage this architecture at scale.A Center of Excellence can provide the enablement layer while a hub-and-spoke model combines centralized governance with decentralized innovation.Certified enterprise data, semantic models, logic, governance policies, and reusable skills can live in governed hubs.Business teams can experiment within their own domains and promote successful assets into the governed enterprise layer.The result is neither completely centralized nor completely decentralized.It is a federated model designed to support both control and self-service.

IN THIS EPISODE
We discuss Microsoft Fabric, Power BI semantic models, data modeling, ontologies, OneLake, Lakehouses, Direct Lake, Delta tables, Fabric Data Agents, Microsoft Copilot Studio, AI agents, persona-driven insights, storytelling with data, deterministic computing, enterprise AI governance, Center of Excellence models, hub-and-spoke architectures, self-service BI, self-service AI, and the idea of building an organizational brain for AI.The bigger question is no longer simply:“How do we build better dashboards?”It is:“How do we give AI enough trusted business context to understand our organization — without allowing it to invent its own version of the truth?”

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Your ERP can calculate production dates, explode demand through MRP, manage routings, inventory, purchase orders, and production orders. But that does not automatically mean it can create a production schedule that your factory can actually execute. In this episode, we break down the gap between ERP planning and finite production scheduling — and explain why a schedule can look perfectly reasonable in the ERP while multiple orders are competing for the same machine at the same time.

THE INFINITE-CAPACITY PROBLEM
Traditional ERP planning can place demand against resources without reserving finite blocks of actual machine time. This “infinite capacity” assumption is useful for demand and material planning, but it becomes a problem when planned dates are treated as executable shop-floor commitments. A capacity report may show that a machining centre has 40 hours of demand against only 16 available hours. It identifies the overload — but it does not decide which orders should run first, which should move, or how those decisions affect downstream operations.

CAPACITY IS MORE THAN MACHINE HOURS
Real production capacity depends on much more than a work-centre calendar. Machines have downtime. Operators have qualifications and shift patterns. Fixtures and tooling may already be occupied. Quality inspections consume resources. Maintenance removes capacity. And an eight-hour shift rarely provides eight hours of usable production time. A feasible schedule therefore has to consider the combination of machines, people, tooling, fixtures, calendars, maintenance, and process rules.

WHY SEQUENCE MATTERS
Production sequence can dramatically change the result. Running similar product families together might require only one major setup. Alternating between families can create repeated tool changes, cleaning, inspections, or fixture changes. The same orders on the same machine can therefore consume very different amounts of capacity depending on their sequence.

THE BOTTLENECK SETS THE PACE
When many orders depend on one constrained resource, keeping every upstream machine busy can actually make performance worse. More work enters the system, queues grow, WIP increases, and priorities become harder to see. Effective scheduling instead protects bottleneck capacity and controls when work is released into production.

MATERIAL AVAILABLE DOESN’T MEAN READY TO RUN
MRP may show that material exists, but that material could be under quality hold, reserved for another order, waiting for inspection, or incompatible with a specific batch requirement. Finite scheduling needs to combine material readiness with resource availability. A component arriving Wednesday only helps if the required machine also has a legal production slot when the material becomes usable.

ROUTINGS DON’T RESERVE CAPACITY
A routing tells you what comes before what. It can define cutting → machining → inspection → assembly. But a routing does not necessarily reserve the actual resource time required to execute those operations. Several orders can follow perfectly valid routings and still collide at the same machine or work centre.

WHY EXCEL KEEPS SURVIVING
This gap explains why planners continue using spreadsheets, whiteboards, notes, and local priority lists. They are combining information from ERP, MES, maintenance, quality, production, and their own shop-floor knowledge to create the schedule the factory actually follows. Excel is often not the root problem — it is the workaround for scheduling logic that exists outside the ERP.

WHAT FINITE SCHEDULING CHANGES
Finite scheduling treats production time as something that must actually be reserved. If an operation needs four hours on a machining centre, those four hours occupy a real slot. Another job cannot use the same resource during that period. The same logic can include operators, tooling, fixtures, and other required resources. When there is no legal slot, the system has to expose the conflict instead of hiding it behind another planned date.

FROM FINITE SCHEDULING TO OPTIMISATION
Once several feasible schedules exist, constraint-based optimisation can compare them. Should the plant minimise late orders? Reduce setup time? Protect bottleneck throughput? Avoid overtime? Reduce WIP? Keep the near-term schedule stable? There is rarely one universally “optimal” production schedule. The best schedule depends on the constraints the factory cannot violate and the business objectives it chooses to prioritise.

ERP VS. MES VS. APS
ERP remains essential for demand, orders, inventory, purchasing, bills of material, and transactional planning. MES provides execution truth from the shop floor. APS adds the decision layer: combining demand, materials, routings, resource availability, constraints, and current production status to create a finite, constraint-aware schedule and test alternative scenarios.

IN THIS EPISODE
You’ll learn why ERP schedules become overloaded, what infinite capacity really means, why bottlenecks and sequence-dependent setups matter, how material availability differs from production readiness, why planners fall back to Excel, and how finite scheduling and constraint-based optimisation turn production dates into an executable plan. The key idea is simple: ERP tells you what needs to happen. A production schedule has to prove when and where it can actually happen.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

When does a manufacturer actually need dedicated production planning software? It is not when the company reaches a certain size. It is not when Excel suddenly becomes “unprofessional.” And it is definitely not because a software vendor showed you a beautiful Gantt chart. The real threshold comes when production complexity, constraints, and constant change become too difficult for planners to reliably coordinate through ERP dates, spreadsheets, whiteboards, calls, emails, and experience alone. In this episode, we explore the warning signs that indicate your manufacturing planning process may have reached that point.

WHEN MANUAL PRODUCTION PLANNING STILL WORKS
Not every manufacturer needs advanced planning software. A stable factory with predictable demand, repeatable routings, relatively few shared resources, and experienced planners may work extremely well with ERP, Excel, planning boards, and direct communication. Simple tools become a problem only when the planning environment changes faster than people can reliably evaluate the consequences. 

SIX WARNING SIGNS TO WATCH
We examine six signals that production planning may have outgrown its current tools: Plans change faster than people can replan. Machine breakdowns, rush orders, shortages, staffing changes, and changing customer dates create continuous replanning. Capacity exists on paper but not in reality. A machine may technically have available hours, but setups, maintenance, tooling, operator qualifications, material availability, and other constraints make that capacity unusable. The same order has different dates in different systems. ERP, MES, spreadsheets, sales, purchasing, and production may each have their own version of the expected completion date. Bottlenecks move but the plan doesn't. Today's constraint may be machining, tomorrow inspection, and next week a specific operator, tool, or downstream process. Expediting becomes the normal workflow. When almost every order becomes urgent, priorities begin replacing the production schedule. Critical dependencies live in people's heads. Experienced planners know which machines, tools, operators, routes, setups, and exceptions actually work — but the system doesn't. 

ERP VS. MES VS. PRODUCTION PLANNING SOFTWARE
ERP remains essential for customer orders, bills of material, inventory, purchasing, production orders, routings, and MRP. MES provides the execution reality: what started, what finished, quantities produced, machine status, quality information, and what's happening on the shop floor. But neither automatically answers the detailed scheduling question: Given the factory as it exists right now, what work should run next — and what happens to everything else if we change the sequence? That's where dedicated production planning and scheduling software can add value. 

WHAT PRODUCTION PLANNING SOFTWARE SHOULD ACTUALLY DO
A planning system should do more than display orders on a calendar. It should help planners create feasible schedules based on finite capacity, resource calendars, routing dependencies, setup requirements, material readiness, alternate resources, skills, tooling, maintenance windows, and current production conditions. More importantly, it should allow planners to test alternatives. If an urgent order moves forward, what gets delayed? If a machine goes down, where can the affected work move? If additional capacity becomes available, which orders benefit? If a supplier delivery slips, which customer commitments are now exposed? The goal isn't to remove human decision-making. It's to give planners better information about the consequences before they make the decision. 

PLANNING, SCHEDULING, OPTIMIZATION AND SIMULATION
These terms are often treated as interchangeable, but they solve different problems. Production planning asks whether demand fits available capacity over a planning horizon. Scheduling determines the actual sequence of operations and resources. Optimization compares feasible alternatives against defined objectives. Simulation lets manufacturers test possible future scenarios before changing the live production plan. Understanding which problem you're trying to solve should come before selecting software. 

COMPLEXITY MATTERS MORE THAN COMPANY SIZE
A large repetitive factory may have a relatively simple planning problem. A much smaller high-mix manufacturer can face enormous scheduling complexity because orders compete for shared machines, specialist operators, tools, inspection resources, alternate routings, and limited material. The need for production planning software therefore isn't primarily driven by employee count. It's driven by the number of dependencies and trade-offs planners need to evaluate — and how quickly those decisions change. 

START WITH ONE DECISION
Before buying an APS platform or another planning application, identify one production decision that repeatedly causes problems. For example: When two urgent orders need the same constrained machine, can we determine which sequence is feasible and understand the delivery impact before production starts? Solve that problem first. Then expand the planning model as the organization learns which data, constraints, and rules actually matter. Because the objective isn't to automate the planner. It's to stop skilled planners from spending their day manually doing work that a planning system should already be helping them calculate. Production Planning Software: When Does a Manufacturer Actually Need It? explores where that boundary lies — and how manufacturers can recognize it before buying another platform.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

What happens when you change a factory before you know how the rest of the production system will react? Adding a shift, buying a new machine, reducing buffers, changing staffing, or accepting a different product mix can look like obvious solutions. But factories are interconnected systems. Improving capacity at one resource can simply move the bottleneck somewhere else. In this episode, we explore factory simulation, production planning, Digital Twins, finite capacity, bottleneck management, and manufacturing optimization — and how manufacturers can test operational changes before introducing them on the real shop floor.

WHY FACTORY CHANGES ARE HARD TO PREDICT
More machine hours do not automatically mean more customer orders shipped. An additional shift may increase machining capacity while assembly, inspection, material handling, maintenance, or qualified labor remain constrained. The result can be higher utilization at one work center while queues simply grow somewhere downstream. This is why production decisions need to consider the entire manufacturing flow, rather than optimizing individual machines in isolation.

WHAT FACTORY SIMULATION ACTUALLY MEANS
Factory simulation does not have to mean an expensive 3D visualization of an entire plant. A useful simulation models how orders move through production over time. It can represent:

• Routings and production sequences
• Machine and labor capacity
• Shift calendars and maintenance windows
• Setup and changeover times
• Material availability
• Queues and WIP
• Quality holds and inspections
• Labor skills and qualifications
• Batch rules
• Downtime and disruptions
• Dispatching and priority rules

This allows manufacturers to test an extra shift without scheduling it, evaluate a machine before buying it, change buffer levels without disrupting production, or simulate a different product mix before customer orders are affected.

ERP VS MES VS FACTORY SIMULATION
ERP provides the commercial and production plan: demand, quantities, due dates, materials, routings, and planned capacity. MES provides evidence about what actually happened during production. Simulation adds another layer: What could happen if we change something? A work center may appear to have sufficient capacity in ERP while the real shop floor is constrained by setups, tooling, operator qualifications, material availability, inspection, or sequencing. MES history can help make simulation assumptions realistic, but historical data alone cannot answer what happens after a future shift change, capacity investment, or different dispatching rule.

FROM FACTORY DATA TO A DIGITAL TWIN
Data describes events. A factory model describes behavior. A useful Digital Twin connects products, processes, resources, people, tools, materials, quality conditions, and operating rules. It can represent the current production state and provide the starting point for testing alternative scenarios. The goal is not a perfect virtual copy of every object in the factory. The goal is a model accurate enough to support a real operational decision.

TEST CAPACITY BEFORE BUYING CAPACITY
Before investing in another machine, manufacturers can simulate alternatives such as: New machine → faster cycle time → additional shift → alternate resource → subcontracting → different sequencing rules. The important question is not simply whether machine capacity increases. It is whether throughput, lead time, queue behavior, and on-time delivery actually improve. A new machine may increase upstream output while creating an even larger queue at inspection or assembly.

PEOPLE ARE PART OF FINITE CAPACITY
Ten employees on a shift do not necessarily represent ten interchangeable units of capacity. Production may depend on specific operators who can perform setups, approve first-off parts, operate specialist equipment, or complete regulated processes. That means realistic manufacturing simulation needs to consider skills, certifications, shift coverage, supervision, support functions, and qualification constraints, not just headcount.

PRODUCT MIX AND SEQUENCING MATTER
Two production plans can contain the same number of orders and still create completely different factory loads. Different product families can require different cycle times, setups, tools, inspections, skills, and rework capacity. Average capacity figures can therefore hide the constraints that actually determine delivery performance. Sequence matters too. Grouping similar products can reduce changeovers, while prioritizing due dates may improve selected customer commitments but increase setup time. Factory simulation lets planners compare those rules against the same demand instead of relying only on averages.

START SMALL
You don't need to simulate the entire factory. Start with one decision, one constrained production area, and one measurable outcome. For example: If we add a late shift at this machining cell, can we improve due-date performance without creating an unmanageable queue at the next operation? Once the model reproduces normal production behavior credibly, alternative scenarios can be tested against that baseline. expensive capacity investment. This episode is for production planners, manufacturing leaders, operations managers, plant managers, industrial engineers, data teams, and anyone working with ERP, MES, APS, Digital Twins, or smart manufacturing.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Manufacturers often rely on ERP systems to manage orders, materials, inventory, purchasing, production orders, and financial transactions. But when a machine goes down, an urgent customer order arrives, or a critical operator is unavailable, a different question suddenly matters: Can the production plan actually run? That is where APS — Advanced Planning and Scheduling — differs fundamentally from ERP. ERP records and governs the business transaction. APS tests whether production can execute the plan under the real constraints of the factory. In this episode, we take a detailed look at APS software vs. ERP, why traditional ERP planning can create a false sense of certainty, and when manufacturers should consider adding finite-capacity scheduling to their production planning architecture.

ERP VS. APS: TWO DIFFERENT QUESTIONS
An ERP system provides the commercial and transactional backbone of manufacturing. It manages customer demand, bills of materials, routings, inventory, purchasing, production orders, costing, traceability, and financial records. APS looks at those same production requirements from another perspective: ERP asks: What needs to be produced? APS asks: Given our machines, people, materials, tools, calendars, setup rules, and existing workload, what can we actually produce — and when? That distinction becomes critical when several orders compete for the same constrained resources.

WHY ERP DATES AREN’T ALWAYS A FEASIBLE SCHEDULE
A production order can have a perfectly valid start date, finish date, routing, material list, and due date in ERP. That does not mean an empty machine exists at the required time. Traditional ERP and MRP planning often works with standard lead times, work-center capacity, calendars, and broader planning buckets. These assumptions are extremely useful for enterprise planning, material requirements planning, purchasing, and production control. But the real factory operates with much more specific constraints. A machine may already be occupied. The required operator may not be on shift. Material may technically be in inventory but still waiting for quality inspection. A fixture may be used somewhere else. Changing from one product family to another may require a long setup or cleaning process. This is the gap between a planned date and a feasible production schedule.

WHAT APS SOFTWARE ADDS
Advanced Planning and Scheduling software brings those physical constraints directly into the scheduling calculation. Instead of simply assigning work to dates, APS can consider finite machine capacity, resource calendars, operator qualifications, tools and fixtures, setup matrices, alternate machines, material readiness, maintenance windows, routing dependencies, campaign rules, changeovers, and production priorities. If a machine only has six available hours, a finite-capacity schedule cannot simply place ten hours of work into that shift and pretend the problem has disappeared. Something has to change. The order may move to another resource. Another order may be delayed. Overtime may be required. The production sequence may change. Or the customer promise may simply be impossible under the current constraints. APS makes those trade-offs visible before production discovers them.

FINITE CAPACITY SCHEDULING AND OPTIMIZATION
A major difference between APS and traditional production planning is finite capacity scheduling. But creating a feasible schedule is only the first step. A schedule can respect every physical constraint and still be commercially undesirable. Manufacturers may want to optimize for different objectives, including: On-time delivery, higher throughput, reduced setup time, lower work in process, bottleneck utilization, schedule stability, reduced changeovers, or protection of strategic customer orders. There is rarely one universally “best” production schedule. APS can calculate alternatives and expose their consequences. The business still has to determine which objectives matter most.

WHAT HAPPENS WHEN A MACHINE GOES DOWN?
The difference becomes particularly visible during disruptions. Imagine a critical machine fails on Monday morning while Sales simultaneously asks production to expedite an important customer order. ERP can show the production order, material availability, planned dates, purchasing status, inventory position, and customer commitment. But planners still need answers to operational questions. Can the order move to another machine? Does that machine require a different setup? Is the qualified operator available? Which existing orders would move? Would protecting this order create another late order downstream? Does the alternate machine become the new bottleneck? APS allows planners to test these scenarios against the current constraints instead of rebuilding the entire production sequence manually. 

ERP, APS AND MES: WHO DOES WHAT?
ERP and APS are not the only systems involved. A useful manufacturing architecture separates business transactions, planning decisions, and execution facts. ERP answers what the customer ordered, what supply is required, and which business transactions need to be controlled. APS determines what sequence is feasible under the available resources and constraints. MES captures what is actually happening on the shop floor. This creates a closed planning loop. ERP provides demand and governed business data. APS creates the constraint-aware production schedule. MES reports actual starts, completions, downtime, quantities, scrap, and other execution events. Those execution facts can then update the planning picture, while the corresponding governed transactions flow back into ERP.

ONE SOURCE OF RECORD DOESN’T MEAN ONE SYSTEM DOES EVERYTHING
Trying to make one platform own every manufacturing decision usually creates more problems than it solves. ERP should remain the source of record for commercial and supply transactions. MES should capture execution facts close to production. APS should own the constrained scheduling view and planning scenarios. This also explains why different systems may legitimately show different dates. ERP may contain the contractual due date, APS the currently feasible completion date, and MES an expected completion based on actual production progress. The important question is not whether every date is identical. It is whether everyone understands what each date means and who owns the decision to change it.

WHY GOOD DATA MATTERS MORE THAN THE APS ALGORITHM
Installing APS does not automatically fix production planning. The scheduling engine needs accurate information about how production really operates. Resource calendars must reflect actual shifts and maintenance. Routing data must identify usable resources. Setup rules need to reflect real changeovers. Labor qualifications, tools, fixtures, material readiness, alternate resources, and other restrictions must be modeled where they materially affect scheduling. A sophisticated optimizer using inaccurate constraints simply produces an inaccurate schedule faster. This is why APS implementations often expose something important: manufacturing knowledge that previously existed only inside the planner’s head or in spreadsheets. If the same manual workaround occurs every week, it is probably no longer an exception. It has become undocumented production logic. A practical APS implementation can therefore begin with one bottleneck, one product family, or one constrained planning horizon instead of trying to model the entire factory immediately.

WHY EXCEL SURVIVES MANUFACTURING PLANNING
Excel remains popular because planners can quickly change assumptions, add missing information, and understand exactly why a calculation changed. The problem is not necessarily the spreadsheet itself. The risk appears when the spreadsheet becomes the only place where the real production logic exists. If critical setup rules, priorities, capacity assumptions, or resource restrictions live exclusively inside one planner’s workbook, the organization has created an unofficial planning system. Understanding those spreadsheets can actually be an important step toward designing a better APS implementation.

WHEN ERP SCHEDULING MAY BE ENOUGH
Not every manufacturer needs dedicated APS software. ERP scheduling may be sufficient when production routes are stable, product variety is manageable, demand is relatively predictable, capacity headroom exists, setup complexity is low, alternate routing is limited, and disruptions do not constantly force planners to rebuild the schedule. In those environments, rough-cut capacity planning, basic finite scheduling, and strong planner routines may provide enough control. Adding another specialized system would then introduce integration, data preparation, training, and operational overhead without necessarily producing enough additional value.

WHEN DEDICATED APS BECOMES IMPORTANT
The case for APS becomes stronger when multiple orders constantly compete for shared bottlenecks and the production sequence itself changes available capacity. Typical signals include frequent rescheduling, complex setups and changeovers, scarce tools or fixtures, qualified-labor constraints, alternate resources with different processing times, material timing problems, frequent disruptions, multi-stage dependencies, customer-expedite requests, or planners spending large amounts of time manually rebuilding schedules. At that point, the real requirement is not simply “better planning software.” It is the ability to calculate the consequences of a decision before committing production or promising a customer date.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Your ERP says the customer order ships on Friday. The work order is released. The routing looks correct. Capacity appears available. Everything looks fine in the planning report. Then Monday morning arrives. A critical five-axis machining center goes down. One order is already in production. Another is waiting for material. A third could theoretically move to another machine — but only if the shared fixture is available, the correct program is approved, and a qualified operator is working that shift. The ERP plan still says Friday. But a date in ERP does not automatically mean the factory can physically deliver it. In this episode, we explore constraint-based production scheduling and the difference between a production plan that describes what the business wants and a finite production schedule that reflects what the factory can actually execute. Using a hypothetical precision-machining plant, we follow production demand from ERP through routings, machines, tooling, fixtures, labor, material, quality, MES, maintenance, and shop-floor events — and examine how a scheduling engine can combine these constraints into an achievable production schedule.

WHEN THE PRODUCTION PLAN MEETS THE PHYSICAL FACTORY
Production planning often begins with demand. Customers need products. Orders have quantities. Orders have due dates. ERP translates that demand into work orders, material requirements, routings, and broad capacity requirements. That is essential. But it is not the same as answering the question production needs answered every day: What can we actually run next? A production plan may reserve eight hours in a machining work center. The physical factory needs to know which machine will provide those eight hours. Is that machine available? Can it produce this exact part revision? Does it have the correct tooling? Is the fixture available? Has the material been released? Is the required operator qualification available during the planned setup? Will the order finish early enough to reach the next production step? Constraint-based scheduling takes the demand the business wants fulfilled and tests it against the conditions that actually exist in production.

PRODUCTION PLAN VS. PRODUCTION SCHEDULE
Production planning and production scheduling are closely related, but they answer different questions. A production plan focuses on demand, dates, quantities, materials, and broad capacity requirements. A production schedule goes deeper. It assigns an operation to a real resource, at a real time, in a real sequence. This distinction becomes especially important when planning systems use infinite capacity. An infinite-capacity plan can place more work into a time period than the physical factory can execute. Two urgent orders can both appear to require the same machine at the same time. On paper, both remain urgent. On the factory floor, one spindle can still run only one operation at a time. Finite capacity scheduling forces the conflict into the open. It accounts for resource calendars, maintenance, setup time, fixtures, tooling and other limitations rather than assuming the work center can absorb whatever demand is assigned to it.

FINITE CAPACITY DOESN’T CREATE CAPACITY
This is an important distinction. Finite capacity scheduling does not magically create another machine. It does not make material arrive earlier. It does not qualify another operator. It does not repair equipment. Instead, it exposes conflicts before production discovers them through delays, expediting, overtime, and customer escalations. Suppose two customer orders require the same five-axis machine. Both are urgent. Both have tight delivery dates. An infinite plan can put both into the same capacity bucket. A finite schedule must make a decision. One goes first. The other follows. Or one moves to an approved alternative. Or one becomes late. That can make the production schedule look worse than the ERP plan. But the schedule did not create the problem. The physical constraint already existed. The schedule simply made it visible.

WHAT IS A PRODUCTION CONSTRAINT?
A constraint is a condition that must be respected when production work is placed into time. Some constraints are hard. They cannot simply be ignored because an order is urgent. A machine cannot perform an operation if it lacks the required capability. A fixture cannot be attached to two machines simultaneously. Material on quality hold cannot be consumed. An operator without the required certification cannot perform a controlled setup. A maintenance window removes usable machine capacity. An operation cannot start before the required previous operation has produced the necessary output. Other constraints are soft. They represent preferences or business objectives. You may prefer fewer setups. You may want to minimize overtime. You may want to reduce Work in Progress. You may prioritize contractual customer dates. You may want to keep a bottleneck continuously productive. A useful scheduling principle is therefore: Feasibility first. Optimization second. First determine what production can physically and operationally execute. Then determine which feasible option best supports the business objectives.

DUE DATE IS NOT THE SAME AS PRIORITY
Production scheduling becomes especially interesting when several orders compete for the same resources. A due date tells you when something should finish. It does not automatically tell you the best sequence. An urgent order might require a long setup. Another order might already have material staged and use the machine's current setup. A third order might need to finish immediately because it must reach a batch process before a cutoff. Simply sorting the production queue by due date ignores these relationships. Constraint-based scheduling evaluates the complete production context. That makes priorities explicit instead of leaving them to whoever calls the planner first.

ROUTINGS AND OPERATION DEPENDENCIES
A production order is not a single block of work. It moves through operations. In the example explored in this episode, a machined housing needs five-axis milling, followed by heat treatment, inspection, and assembly. Those operations depend on each other. If milling finishes late, the problem does not necessarily remain in machining. The order may miss the next heat-treatment batch. That delay can move inspection. Inspection can move assembly. Assembly can move the final delivery date. This is why constraint-based scheduling needs to understand operation dependencies, not just individual machine utilization. The schedule needs to model the flow of production.

MATERIAL AVAILABILITY IS MORE THAN INVENTORY
A planning system might show that material exists. But can production actually consume it? Those are different questions. Material might physically be inside the factory while still waiting for incoming inspection. It may be allocated to another production order. It may be quarantined. It may require a customer-specific certificate. It may belong to the correct material grade but the wrong approved lot. A useful scheduling question is therefore not simply: “Do we have material?” It is: “Can this operation consume this approved material at this planned time?” If the answer is no, the operation is not ready — even if the machine is available. The episode shows how material and quality gates become time-based production constraints rather than simple inventory attributes.

MACHINE CAPABILITY VS. MACHINE AVAILABILITY
Another machine may have open capacity. That does not automatically make it an alternative. The resource must be capable of performing the operation. It may need the correct working envelope. Tolerance capability may matter. A specific controller or approved program may be required. Customer approval may restrict the operation to particular machines. Different machines that belong to the same ERP work center may therefore provide completely different executable capacity. Spare time does not create capability. This becomes critical after a machine breakdown. The scheduler cannot simply search for another empty slot. It needs to search for another valid production path.

MACHINE STATE AND TRUSTWORTHY AVAILABILITY
Machine data creates another challenge. Modern manufacturing equipment can produce enormous numbers of signals. Running. Idle. Stopped. Setup. Fault. Temperature changes. Vibration changes. Cycle completion. Door states. Warnings. But the production scheduler does not need every PLC signal. It needs an operational interpretation of those signals. A brief stop may require no planning response. A confirmed outage that removes several hours from a bottleneck resource probably does. The scheduling architecture therefore needs to transform raw shop-floor events into trusted capacity decisions. Real-time manufacturing does not mean every sensor event should instantly rebuild the production schedule. It means the right event reaches the scheduling decision loop before the decision window closes.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

A machine goes down. Maintenance receives the alarm. The operator stops production. The MES records an interrupted operation. But your ERP may still believe that the machine has capacity. And your production schedule may still promise that every order will be completed on time. That is where a machine breakdown stops being only a maintenance problem and becomes a production planning problem. In this episode, we explore what should actually happen to a production plan when a critical machine becomes unavailable — from detecting the disruption and estimating lost capacity to identifying affected orders, evaluating alternative resources, rescheduling with finite capacity, and releasing a production plan the factory can actually execute.

NOT EVERY MACHINE STOP REQUIRES REPLANNING
Modern factories generate enormous numbers of operational signals. PLCs report faults. IoT systems detect machine-state changes. MES platforms track interrupted operations. Maintenance systems record incidents. But a machine stopping for a few minutes does not automatically mean the entire production schedule should change. A short interruption might be caused by an operator clearing a jam. It might be a normal tool change. The machine could simply be waiting for material. Or a sensor could report a state that does not represent the actual production situation. The important distinction is between a machine signal and a planning event. A production plan should react when the interruption creates a meaningful loss of capacity that normal shop-floor recovery can no longer absorb. That threshold depends on the production environment. A ten-minute stop on a resource surrounded by large buffers may have almost no impact. The same ten-minute interruption on a bottleneck resource producing a make-to-order component with a tight customer deadline could require immediate attention. Good production planning therefore does not react to every signal. It reacts to operational consequences.

HOW LONG WILL THE MACHINE REALLY BE DOWN?
Once downtime becomes significant enough to affect production, one question becomes critical: How long will the capacity be unavailable? Unfortunately, maintenance rarely knows the exact answer immediately. A technician may know that a drive has failed but not whether a reset will solve the problem, whether a component needs replacement, or whether additional safety checks will be required. Production planning should therefore avoid building an entire schedule around an uncertain repair timestamp. Instead, planners can work with a recovery window and confidence level. For example: A short outage may require no schedule change. A medium outage may require selected orders to move. A full-shift outage may require active rescheduling. A longer outage may threaten customer commitments and require escalation. This turns maintenance information into a useful planning input without pretending that an early repair estimate is a guarantee.

A MACHINE IS MORE THAN AVAILABLE HOURS
One of the biggest mistakes in production planning is assuming that another machine with an empty calendar automatically provides replacement capacity. It does not. A resource needs the correct capability. The right fixture may be required. A qualified production program may need to exist. An operator with the necessary skills must be available. Quality may need to approve the alternate process. Material needs to be physically available. Tooling and inspection capacity may also be required. This creates an important distinction: Machine availability is not the same as executable production capacity. An empty four-hour window on another machine means very little if the product cannot actually be produced there. Production planning therefore needs a model connecting Product, Process and Resource. The product defines what needs to be manufactured. The process defines the operations required. The resource defines where those operations can actually run and under which constraints. That context becomes essential when production is disrupted.

WHICH ORDERS ARE ACTUALLY AFFECTED?
Once a machine failure is confirmed, planners need to identify the work that genuinely depends on that resource. Start with the order currently running. How much has already been completed? What quantity remains? Can the partially processed material safely wait? Does interrupted work require inspection, rework, or scrap approval? Then examine the queue. Which orders are physically waiting? Which orders are released? Which ones have tight downstream dependencies? Which have alternative routings? Which rely exclusively on the failed resource? Not every order scheduled on the machine carries the same risk. Some may easily move. Others may have enough delivery buffer to wait. Some may depend on a customer shipment. Others may feed a critical assembly operation. And some may have no realistic alternative at all. The goal is not to declare every order an emergency. The goal is to identify real production exposure.

THE BOTTLENECK CAN MOVE
Suppose Machine 4 fails. Machine 6 has available capacity. Moving urgent orders to Machine 6 appears to solve the problem. But what happens next? Perhaps Machine 6 feeds an inspection station that is already operating near capacity. The orders move successfully — and simply create another queue somewhere else. A machine breakdown can therefore move the production constraint. The new bottleneck could become another machine, an inspection station, a qualified operator, a furnace, a fixture, a transport resource, or even a tool. This is why production planners need to evaluate the entire local production flow, not simply find another empty machine slot. Moving work can move the problem. A good rescheduling decision considers what happens downstream and upstream after every significant schedule change.

WHAT SHOULD THE PRODUCTION PLAN PROTECT?
When capacity disappears, not every order can necessarily remain exactly where it was. Production therefore needs clear priorities. Customer delivery commitments matter. But so do internal milestones. Safety stock can matter. Material shelf life can matter. Campaign rules can matter. Setup costs can matter. Quality requirements can matter. An urgent-looking order may require a long changeover and material that has not yet arrived. Another order with a slightly later due date may already have material staged and require almost no setup. Blindly sorting everything by due date can therefore produce a worse production schedule. Priority rules should exist before the machine breaks down. Otherwise, disruption planning becomes a competition between whoever calls first, whoever complains loudest, and whoever has the most senior manager copied into an email. Production planning needs policy, not panic. 

POSSIBLE CAPACITY VS EXECUTABLE CAPACITY
Before moving an order to another resource, planners need to test the full chain of constraints. Can the machine technically perform the operation? Is the tooling available? Is a qualified operator available? Is the material physically ready? Has quality approved the alternative? Does the production sequence allow the change? Are batch rules respected? Does shelf life create another time constraint? Has maintenance actually released the resource for production? A resource can be theoretically capable without being operationally available. This distinction between a possible move and an executable move is fundamental to realistic manufacturing scheduling. A possible move says that another machine could perform the operation. An executable move means that machine, tooling, operator, material, process approval, sequence, safety requirements, and available time all align. Only then does that empty slot become real capacity.

BUILD SCENARIOS INSTEAD OF SEARCHING FOR ONE PERFECT ANSWER
Machine downtime introduces uncertainty. Trying to calculate one perfect replacement schedule can therefore create false confidence. A better approach is to generate a small number of realistic response scenarios. One scenario might keep the work on the failed resource and wait for repair. Another might move selected orders to approved alternative resources. A third could use overtime or an additional shift. Another possibility might involve splitting an order where production and quality rules permit it. Each scenario should explain: What changes? Which orders move? Which customer commitments are protected? Which setups are added? Which resources are required? What assumptions does the scenario depend on? And what happens if the repair takes longer? The objective is not to create dozens of simulations. Usually, production needs a preferred response, a fallback, and perhaps a more aggressive option if delivery risk becomes unacceptable. 

WHY EXCEL REPLANNING BREAKS UNDER PRESSURE
Excel remains extremely useful for local analysis. But problems begin when the spreadsheet becomes the new production schedule while the actual production environment continues changing elsewhere. Maintenance updates the repair estimate. A supervisor moves an order. Customer service changes a priority. MES records new production progress. Material moves. Another resource becomes unavailable. Suddenly several people have several different versions of the production plan. And everyone believes their version is correct. Then come the familiar filenames: Final. Final_v2. Final_v2_revised. The factory version of archaeology. The underlying problem is not Excel itself. The problem is the absence of a shared, controlled source of truth. Production needs one released schedule that clearly shows which facts were used, which orders changed, when the schedule was calculated, and which version the shop floor should actually execute.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Value Stream Mapping has been one of the most useful tools in Lean Manufacturing for understanding how material, information, and decisions move through a production system.But traditional Value Stream Mapping has a fundamental limitation.The factory keeps changing. The map does not.You can bring production, planning, quality, maintenance, supply chain, and operations into the same workshop. You can map cycle times, queues, batch sizes, handoffs, waiting times, information flows, and bottlenecks. At the end of the workshop, everyone may finally share the same picture of how the production system works.Then reality changes.A supplier shipment arrives late. A customer places an urgent order. A machine goes down. Quality blocks a batch. Maintenance removes a resource from production. A setup takes longer than expected. Material waits in the wrong location.The Value Stream Map hanging on the wall still describes yesterday's factory.So what if a Value Stream Map could become something more?In this episode, we explore how Value Stream Mapping could evolve from a static Lean Manufacturing document into a live manufacturing data model connected to ERP, MES, quality, maintenance, machine, and shop-floor data.The goal is not simply to digitize a Value Stream Map.The goal is to create a model that continuously reflects how production actually behaves.

THE PROBLEM WITH STATIC VALUE STREAM MAPPING
Traditional Value Stream Mapping captures an important snapshot of a production system.It helps teams understand the sequence of processes required to produce a product, but its real value goes much further than drawing boxes and arrows.A Value Stream Map can describe processing times, waiting times, queues, inventory, batch sizes, changeovers, information flows, replenishment signals, production control rules, and handoffs between different parts of the organization.That makes Value Stream Mapping extremely useful for understanding flow.But production is dynamic.The conditions captured during a workshop may already be different several days later.Demand changes.Resources become unavailable.Orders receive different priorities.Quality issues create rework.Material arrives late.Production schedules change.Actual cycle times differ from planning assumptions.These changes affect the real flow of production, but they are usually not reflected automatically in the Value Stream Map.This creates an interesting question for modern manufacturing:Can Value Stream Mapping become a continuously updated model of the factory?

FROM VALUE STREAM MAP TO LIVE DATA MODEL
A live Value Stream Model would be fundamentally different from simply putting a traditional Value Stream Map on a screen.Digitizing a diagram is relatively easy.Creating a model that understands the relationships between orders, operations, resources, materials, constraints, events, and production states is much harder.A live manufacturing model needs to understand questions such as:Where is an order right now?Which operation was completed last?What should happen next?Which resource is required?Is that resource actually available?Is material waiting?Is quality blocking production?Has maintenance reduced available capacity?Is the order waiting because of a physical constraint or because of an information delay?And most importantly:What evidence proves the current state of production?This moves Value Stream Mapping from documentation toward operational intelligence.

ONE ORDER, MANY MANUFACTURING SYSTEMS
Consider a make-to-order manufacturing environment.A customer order enters the business with a required delivery date.ERP creates the sales order, generates production requirements, checks material availability, and provides routing information describing the expected sequence of operations.But ERP only provides part of the picture.On the factory floor, the Manufacturing Execution System may dispatch work, record operator confirmations, track production progress, and maintain serial or batch information.Machine systems provide another perspective.A machining center might report whether it is running, idle, faulted, or currently being set up.A furnace might provide temperature information and cycle completion events.A test station might generate pass or fail results.Industrial gateways, historians, PLCs, and IoT systems may collect additional operational signals.Quality systems add another layer.An inspection result might place material on hold.A nonconformance could trigger rework.A quality release may happen hours after the physical inspection has already finished.Maintenance systems also influence the real production schedule.A machine might technically appear available in the planning system while scheduled maintenance makes it unavailable for several hours.Each system contains valuable information.But none of those systems alone necessarily describes the complete production flow.

WHERE DID THE LEAD TIME ACTUALLY GO?
Imagine an order that ships late.ERP knows when the order was created.ERP knows the planned delivery date.MES knows when individual operations were confirmed.Machine data may show when equipment was running.Quality systems know when inspections happened.Maintenance knows when resources were unavailable.But the planner asks a much simpler question:Why was this order late?Where did the lead time actually go?Maybe the order waited after machining.Maybe material was physically ready but transport did not move it.Maybe inspection was completed but the quality release happened hours later.Maybe a machine had capacity but the required material was waiting somewhere else.Maybe too much work was released upstream, creating a queue in front of the real constraint.Maybe the production schedule was already unrealistic when the order entered the shop floor.The data required to answer these questions may already exist.The problem is that it exists across multiple systems.

ERP DATA IS NOT THE SAME AS PRODUCTION REALITY
ERP systems are essential for manufacturing.They manage orders, materials, routings, requirements, inventory, purchasing, and many other business processes.But an ERP routing describes how production is expected to happen.It does not automatically describe what is physically happening on the factory floor right now.That distinction becomes critical when manufacturers want to optimize production.A production plan may say that an order can move to the next operation.The factory may say something completely different.The machine may be unavailable.Material may not have arrived.An operator may not be available.Quality may have blocked the batch.The previous operation may have taken longer than expected.Another urgent order may already occupy the resource.The planned production model and the actual production system can quickly diverge.A live Value Stream Model could help expose that difference.

WHY MES ALONE IS NOT ENOUGH
MES provides much deeper production visibility than ERP.It can track work orders, operations, confirmations, production progress, genealogy, and shop-floor execution.But MES also represents only part of the manufacturing environment.Production decisions may depend on information stored outside the MES.Quality systems.Maintenance systems.Warehouse systems.Industrial IoT platforms.Machine historians.Planning systems.Scheduling systems.ERP.Operator input.Transportation systems.Even spreadsheets may still contain operational information that influences production.A live manufacturing model therefore needs relationships between these systems rather than simply another isolated dashboard.

REAL-TIME DASHBOARDS ARE NOT LIVE VALUE STREAMS
Many digital manufacturing projects focus on real-time visibility.Machine states are collected.Production data enters a lakehouse.Dashboards display open orders.Power BI visualizes KPIs.Managers receive more current information.That can be extremely valuable.But real-time data alone does not automatically create a live Value Stream.Knowing that a machine is idle does not explain why material is waiting.Knowing that an order is open does not explain which constraint prevents it from progressing.Knowing that an operation is delayed does not automatically reveal whether the cause is capacity, material, quality, maintenance, sequencing, transportation, or information flow.A dashboard shows information.A model describes relationships.That distinction becomes increasingly important when manufacturers want to move from visibility toward optimization.

CONNECTING IT AND OT DATA
One of the biggest challenges in modern manufacturing is connecting Information Technology and Operational Technology.Business systems understand customers, orders, materials, costs, and delivery dates.Operational systems understand machines, process states, events, faults, temperatures, cycle times, and physical production.The production system sits between those worlds.A customer order eventually becomes physical work.A routing becomes machine operations.A production schedule becomes actual sequences.A planned cycle time becomes a measured cycle time.A planned resource becomes a real machine with downtime, maintenance, setups, and capacity constraints.A live Value Stream Model could provide a semantic layer connecting those perspectives.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Your ERP says the production order should finish next Thursday. The routing looks correct. Material is planned. Everything appears under control. Then you walk onto the shop floor and discover the machine is already overloaded, the required operator is booked elsewhere, the fixture is in use, or the material exists in ERP but has not actually been inspected and released. That is the gap between planning demand and scheduling reality. In this deep dive, we break down how finite capacity scheduling actually works in manufacturing — from ERP and MRP planning to a schedule that accounts for the physical constraints of machines, people, tools, materials, quality gates, maintenance and time.

INFINITE VS. FINITE CAPACITY PLANNING
Infinite capacity planning has an important purpose. ERP and MRP systems can quickly calculate demand, material requirements, planned orders and dates across thousands of products and long planning horizons. But a planned date does not prove that the factory has enough usable capacity to execute the work. Finite scheduling asks the harder question: Can this operation actually run at this time, on this resource, with everything required to execute it? That means looking beyond calendar hours to usable capacity and considering machines, qualified people, tooling, fixtures, released material and process conditions.

FROM PRODUCTION ORDER TO SCHEDULED OPERATIONS
A production order cannot simply be treated as one block between a start and finish date. A finite scheduler breaks the order into individual operations and calculates setup time, runtime, waiting and transfer time before searching for eligible resources and available slots. Once an operation occupies a slot, that capacity is no longer available to another order. Delays can therefore propagate through subsequent operations and expose a late order before it reaches the shop floor.

FORWARD VS. BACKWARD SCHEDULING
We examine the two fundamental scheduling perspectives. Forward scheduling asks: Given what is ready now and the capacity we actually have, when can this order realistically finish? Backward scheduling starts with the requested delivery date and asks: When must every preceding operation happen for us to keep this promise? Comparing the two can expose the critical decision gap between the customer promise and what current production conditions can actually deliver.

SEQUENCING, BOTTLENECKS AND CHANGEOVERS
Having enough capacity somewhere in the calendar does not automatically tell you which order should run next. We explore competing sequencing strategies including due-date priority, customer priority, shortest processing time, critical ratio and campaign-based sequencing. Changeovers are especially important. Switching fixtures, tools, programs, materials or product families consumes real bottleneck capacity. A schedule that ignores sequence-dependent setup time can look feasible while being impossible to execute.

MATERIAL, PEOPLE, TOOLS AND QUALITY ARE CAPACITY TOO
A free machine does not necessarily mean an operation can start. Material may still be awaiting inspection. The qualified operator may work another shift. A fixture may be installed on another machine. A gauge may require calibration. Quality may need to approve the first piece. Finite scheduling therefore becomes a model of relationships between products, operations, resources, skills, tooling, materials and process rules, rather than simply a machine calendar.

WHAT HAPPENS WHEN THE PLAN BREAKS?
Machines fail. Materials arrive late. Operators become unavailable. Quality holds appear. Priorities change. A useful finite schedule should respond without constantly reshuffling the entire factory. We discuss rescheduling, protected or “freeze” zones, schedule nervousness and how planners can evaluate alternative scenarios instead of blindly accepting a completely regenerated schedule. The objective is not to eliminate human decisions. It is to give planners better information about what each decision will displace.

ERP, MES, APS AND THE MICROSOFT DATA LAYER
The episode also examines where the different technology layers belong. ERP owns much of the commercial and transactional context. MES provides execution status from the shop floor. Maintenance and quality systems contribute additional constraints. The scheduling or APS layer combines those inputs with production rules to determine feasible options. Microsoft technologies can support the surrounding integration, analytics and decision architecture, but they do not automatically become the finite scheduling engine. The production logic still needs explicit constraints, ownership and scheduling rules.

WHERE AI ACTUALLY HELPS
AI can help planners retrieve information, summarize disruptions, explain scheduling outcomes and surface risks. Predictive models can estimate potential machine failures, material delays or changing cycle times. But AI should not invent production feasibility. The scheduling or optimization engine evaluates explicit constraints; AI supports the surrounding decision process; and the planner remains accountable for choices involving customers, quality, labor and production priorities.

THE KEY TAKEAWAY 
Finite capacity scheduling does not create capacity. If a resource has 70 usable hours and demand requires 100, an algorithm cannot manufacture the missing 30 hours. What a good schedule can do is expose that conflict early enough to decide whether to change the sequence, add capacity, use an approved alternative, subcontract work or renegotiate the customer commitment. The goal is not a factory where every machine looks busy. The goal is a plan that can actually run.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

A production plan can look perfectly reasonable — until production actually starts.One machine runs late. A material release slips. A qualified operator becomes unavailable. A quality inspection takes longer than expected. A batch misses its furnace window. Suddenly, a delay of only a few hours can put an entire customer delivery at risk.In this deep dive, we explore how the Critical Path Method (CPM) can be adapted from traditional project management to modern manufacturing and production planning.The central idea is simple: the critical path in manufacturing should not be treated as a fixed sequence created when the production order was released.Instead, manufacturers need to understand the live chain of dependencies that currently determines the earliest possible completion and shipment date.That chain can change throughout the production day.A machine breakdown may initially be the problem. Once the machine recovers, however, the critical dependency could move to a furnace slot, a qualified operator, an inspection queue, a missing fixture, a quality release, or even the carrier cutoff at the end of the process.This episode examines how manufacturers can connect production orders, machines, materials, people, quality states, ERP, MES, IoT, and shop-floor events into a dependency model capable of supporting more dynamic production scheduling.

WHY CRITICAL PATH METHOD MATTERS IN MANUFACTURING
Critical Path Method is normally associated with project management.A project contains tasks with durations and dependencies. Some activities can run in parallel, while others cannot begin until previous work has finished.The critical path represents the sequence of dependent activities that determines the earliest possible project completion date.Manufacturing has many of the same characteristics.A released production order contains operations that need to happen in a particular sequence. Those operations can depend on:

• Machine availability
• Material availability
• Qualified operators
• Fixtures and tooling
• Inspection results
• Quality releases
• Batch windows
• Maintenance schedules
• Shift calendars
• Process approvals
• Downstream capacity
• Packing and dispatch requirements

That effectively turns the production order into a dependency network.But manufacturing introduces an additional challenge: production orders don't operate independently.They compete for shared machines, people, tools, test equipment, forklifts, inspection resources, heat-treatment capacity, and sometimes even physical space.The result is a continuously changing network of dependencies across many orders.

WHEN ONE LATE OPERATION CHANGES THE DELIVERY DATE
Consider a machine assembly that must ship by the end of the week.Its route could include:

• Machining
• Heat treatment
• Surface finishing
• Final inspection
• Packing
• Dispatch

Planning initially places every operation into an appropriate time window.Then the machining center stops.Perhaps a spindle alarm requires maintenance and the remaining quantity cannot be completed for several hours.At first, this appears to be a simple machine delay.But the actual impact depends on what happens next.If machining misses the next scheduled furnace load, the order may have to wait until the following batch. That later heat-treatment completion could then miss the finishing shift.Inspection moves later. Packing moves later. Eventually, the order could miss the carrier collection.A few hours of machine downtime can therefore create a full day of delivery risk.This is why production planning cannot look only at the operation that originally became late.The more important question is:Which remaining dependency now controls whether the order can ship on time?

THE CRITICAL PATH IS NOT STATIC
In manufacturing, the critical path can move.Before a disruption, machining might control the completion date. After machining recovers, the next furnace window might become critical. After heat treatment, inspection could become critical because there is almost no time remaining before packing and dispatch.The operational constraint has moved.This distinction is important because simply expediting the operation that appears late doesn't necessarily recover the customer date.If an order has already missed the furnace slot required to protect its shipment date, pushing machining harder may achieve nothing unless the furnace schedule can also change.A live critical path therefore needs to follow the complete dependency chain rather than focusing only on individual late operations.

MATERIAL READINESS CAN BECOME THE CRITICAL PATH
Production problems can begin before a machine starts.A purchase order might show that material will arrive on Friday. Planning therefore schedules machining for Monday.But physical delivery does not necessarily mean production readiness.The material might still require:

• Incoming inspection
• Certificate verification
• Quality approval
• Dimensional checks
• Lot release
• Traceability verification

Material can physically exist inside the factory while still being unavailable to the production order.Manufacturers therefore need to distinguish between expected material availability and production-ready material availability.The same problem occurs when sufficient stock exists overall but the production order requires a specific lot, specification, quality status, or reservation.Total inventory and usable inventory are not necessarily the same thing.

SHARED MACHINES CONNECT DIFFERENT PRODUCTION ORDERS
Finite capacity introduces another layer of dependency.Imagine four production orders waiting for the same five-axis machining center.Every individual routing might look feasible. But the machine can process only one job at a time.The sequencing decision at that machine can therefore change the delivery dates of several unrelated customer orders.A short machining job can even delay another order by an entire day if it prevents that second order from reaching a time-sensitive downstream process.This means production orders can become indirectly connected through shared resources.The live critical path may therefore include not only operations belonging to the affected order, but also other work occupying the resource that order requires.

AVAILABLE CAPACITY IS NOT ALWAYS USABLE CAPACITY
A machine appearing available in the planning system doesn't necessarily mean an operation can begin.The operation might require:

• A particular fixture
• An approved CNC program
• Specific tooling
• A qualified machine configuration
• A certain product revision
• A calibrated test system
• A qualified operator

Two machines might technically appear capable of performing an operation while only one is actually qualified for the current product, process, or customer requirement.The difference between theoretical capacity and usable capacity is fundamental to realistic manufacturing scheduling.

PEOPLE, SKILLS, AND SHIFT CALENDARS MATTER
The same principle applies to labor.A machine can be available while no qualified person is available to operate it.An operation might require a specialist for:

• Setup
• First-piece inspection
• Process approval
• Final release
• Quality verification
• Specialized machine operation

A generic pool of available labor hours cannot necessarily represent these constraints.The real scheduling question becomes:When are the machine, material, qualified person, tooling, and required approvals available at the same time?That overlap determines the earliest practical start of the operation.

MACHINE STATUS IS NOT PRODUCTION READINESS
Another major challenge is interpreting shop-floor machine data.A machine may report that it is available or running. That does not necessarily mean it is ready for the next production order.After maintenance, the equipment may still require:

• Warm-up cycles
• Fixture changes
• Tool checks
• Probe verification
• Cleaning
• Calibration
• Setup
• Program approval

Machine status therefore needs operational context.Even a machine that never stops can create scheduling problems if its actual cycle time begins drifting away from the standard time used by planning.Small losses on a heavily constrained resource can accumulate across multiple jobs and eventually cause an order to miss an important downstream window.Metrics such as Overall Equipment Effectiveness (OEE) remain useful for understanding equipment performance, but OEE alone does not calculate a feasible production schedule or determine whether a specific customer order will ship on time.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Artificial intelligence is changing software development at a speed we have rarely seen before.Developers have already moved from writing every line of code themselves to working with AI assistants that can generate code, explain unfamiliar systems, create tests, debug applications, and automate repetitive work.But according to Microsoft MVP Andre Baltieri, that is only the beginning.In this episode of M365.FM, Mirko Peters sits down with Andre for a deep dive into the transition from traditional software development to AI-assisted development, coding agents, agentic architectures, Microsoft Agent Framework, .NET, RAG, context engineering, security, and the economics of generative AI.

FROM .NET IN 2003 TO THE AI ERA
Andre takes us back to the early days of .NET and C#, when learning a new Microsoft technology often meant purchasing official training and traveling to another city.Since then, software development has moved through desktop, web, mobile, cloud, containers, microservices, and serverless computing.Andre argues that the transition to AI feels fundamentally different. Instead of simply introducing another platform or framework, AI introduces a new way for humans to interact with software.

AI ASSISTANTS VS. AI CODING AGENTS
There is an important difference between having an AI assistant inside your IDE and delegating work to an agent.An assistant can explain code, suggest refactoring, answer questions, and help developers understand their applications.An agent can receive a goal, create a plan, divide the work into smaller tasks, use tools, coordinate additional agents, and implement significant parts of the solution.Andre explains how this is already changing his own development workflow, with AI now generating much of the code he previously would have written manually.

SPEC-DRIVEN SOFTWARE DEVELOPMENT
As agents become more capable, specifications become increasingly important.Instead of describing every implementation detail, developers can define requirements, architecture, constraints, and expected behavior and allow agents to determine how parts of the implementation should be completed.This shifts developer attention from simply producing code toward defining what should be built and why.

MICROSOFT AGENT FRAMEWORK
The conversation moves into Microsoft Agent Framework and its role in bringing AI capabilities into existing applications.Andre explains how the framework brings together capabilities associated with Semantic Kernel and AutoGen and provides developers with tools for connecting models, orchestrating workflows, using MCP, implementing RAG, handling data ingestion, and exposing application functionality to AI.For .NET developers in particular, this can significantly reduce the amount of integration code required.

WHY .NET STILL MATTERS IN THE AI ERA
Python remains one of the dominant languages in AI development, but Andre argues strongly that .NET and C# are extremely well positioned for enterprise AI applications..NET continues to evolve rapidly, while Microsoft's AI tooling increasingly gives C# developers native access to modern AI capabilities.Organizations with years of business logic already implemented in .NET may therefore have a major advantage: they do not necessarily need to rebuild everything before introducing AI.Existing functionality can instead be selectively exposed to agents and AI-powered applications.

FROM DETERMINISTIC SOFTWARE TO AGENTIC SYSTEMS
Traditional applications are largely deterministic:If X happens, execute Y.Agentic systems introduce another model:Here is the goal. Determine which actions are required to accomplish it.That represents a significant architectural shift.Instead of explicitly defining every possible path, developers increasingly define goals, tools, context, permissions, constraints, and boundaries within which AI can operate.

DESIGN PATTERNS ARE NOT DEAD
AI-generated code does not eliminate decades of software engineering knowledge.Clean code, maintainability, testing, architecture, and design patterns remain important because AI frequently learns how to implement new functionality by examining the existing codebase.Messy code can therefore lead to more messy code.Developers still need to understand architecture and engineering principles even when an AI agent performs much of the implementation.

THE STOCHASTIC SOFTWARE PROBLEM
Traditional developers expect identical inputs to produce identical outputs.Generative AI is probabilistic.The same request can produce different implementations, answers, or behavior across multiple executions.Andre discusses why this requires developers to rethink testing and validation and why strong guardrails become increasingly important when AI functionality is exposed to large numbers of users.

CONTEXT ENGINEERING IS MORE IMPORTANT THAN PROMPTING
Choosing the latest model is not necessarily the most important decision.Andre argues that context is everything.Developers need to understand both the business problem and the technical environment well enough to provide AI with the right information.Too little context produces weak results.Too much context can overwhelm the model.The challenge is finding the information that actually matters.

RAG, DATA AND THE CONTEXT WINDOW
Retrieval-Augmented Generation becomes especially important when organizations want AI systems to work with their own knowledge.But building a RAG system is not simply about putting documents into a vector database.Data needs to be cleaned, structured, chunked, retrieved, and inserted into the model's context intelligently.Andre shares an example from his own education platform, where video lessons were transcribed and indexed so users could search for concepts and jump directly to the relevant point in a video.

MEMORY AND MANAGING AI CONTEXT
Long-running AI conversations create another challenge: memory.As context windows fill, conversations need to be summarized or compacted.Andre explains why developers should actively manage this process instead of assuming that an AI system will always preserve the most important information.Sometimes the best solution is surprisingly simple: finish a task, close the conversation, and start again with a clean context.Specifications and Markdown files can also provide persistent project context for coding agents.

SECURITY, PERMISSIONS AND LEAST PRIVILEGE
Giving an AI agent access to tools and company data creates significant security implications.Andre recommends treating agents according to principles similar to human identities: close everything by default and expose only what the agent genuinely requires.Instead of giving an AI system unrestricted database access, developers should expose carefully controlled functions that return only the information required for a particular task.This becomes particularly important when agents can read or modify enterprise data.

PROMPT INJECTION AND AI GUARDRAILS
Prompt injection creates a new attack surface for AI-powered applications.Users can intentionally manipulate prompts, attempt to retrieve information outside the intended context, consume company resources, or persuade an AI system to perform actions its designers never anticipated.The discussion explores the importance of system instructions, application-level restrictions, controlled functions, identity, permissions, and platforms such as Azure AI Foundry for establishing additional security boundaries.

AI FINOPS — DON'T USE GENERATIVE AI FOR EVERYTHING
One of the most practical lessons from the conversation is that just because AI can perform a task does not mean AI should perform that task.Andre distinguishes between generative and deterministic workloads.If something must happen the same way every time, traditional programming may be faster, cheaper, and more reliable.He gives the example of his video workflow: Python scripts can extract audio and perform deterministic processing locally, while generative AI is reserved for tasks such as translation where generation actually adds value.The result is a hybrid architecture that can dramatically reduce unnecessary token consumption.

BUILDING THE AGENTIC FUTURE
Software development is moving beyond developers manually defining every individual step.Increasingly, developers will define goals, specifications, context, tools, permissions, architecture, and guardrails while AI systems determine how portions of the work should be accomplished.That does not eliminate the developer.It changes where the developer creates value.Understanding the business, designing maintainable systems, controlling context, securing tools and data, validating AI-generated work, and deciding when not to use AI may become some of the most important software engineering skills of the agentic era.RAPID FIRESingle agent or multi-agent?For complex workloads, Andre sees significant potential in multi-agent architectures and sub-agents.Prompt engineering or context engineering?Context engineering.And what comes next?More capable models, more powerful agents, better code generation, stronger architectures, and continued evolution of the tools developers use to build software.We are still at the beginning of the generative AI era.

ABOUT THE GUEST
Andre Baltieri is a Microsoft MVP and software development specialist with more than two decades of experience in the industry.His work focuses on .NET, C#, artificial intelligence, Microsoft Agent Framework, software architecture, and modern AI-assisted development.In this conversation, he brings together more than twenty years of software engineering experience with a practical view of how AI agents are changing the developer profession.



Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Microsoft Power Platform is often described as a low-code platform. But what happens when the applications you build become business-critical, highly integrated, and too complex for a simple maker-first approach?In this episode of M365 FM, Mirko Peters talks with Power Platform Solution Architect Ian Tweedie about what happens when Power Platform moves beyond simple low-code applications and becomes part of a serious enterprise architecture.

LOW-CODE DOESN’T MEAN LOW ARCHITECTURE
Power Platform can deliver a large percentage of business value quickly, but enterprise solutions almost always contain requirements that go beyond standard low-code capabilities.Ian explains why low-code should never be confused with no-code — and why traditional software architecture principles still matter when building with Power Apps, Power Automate, Dataverse, custom connectors, APIs, and Azure services.

WHEN POWER PLATFORM BECOMES ENTERPRISE SOFTWARE
There isn’t necessarily a clean line between “low-code” and “enterprise.”Complexity starts increasing when applications involve multiple user journeys, development teams, integrations, security requirements, business-critical processes, and interconnected services.At that point, architecture becomes essential.Ian explains why solutions should be divided into clearly defined features and modules with clean interfaces instead of becoming one large interconnected application.

ESCAPING THE WHACK-A-MOLE DEVELOPMENT PROBLEM
Fix one bug and another appears somewhere else.That familiar development problem is often a symptom of tightly coupled architecture.Ian discusses how modular design can isolate functionality and reduce unintended dependencies. Using email delivery as an example, he explains how separating business processes from delivery mechanisms can make applications easier to test, maintain, replace, and scale.

LOW-CODE + PRO-CODE = HYBRID ARCHITECTURE
Power Platform doesn’t have to compete with traditional software development.A Power Apps frontend might represent only a small part of a much larger application using Azure, AWS, GCP, APIs, or custom services.The important architectural question isn’t whether something is “low-code” or “pro-code.”It’s which technology is best suited to each feature.

CITIZEN DEVELOPERS, MAKERS AND ARCHITECTURE
Citizen developers bring something extremely valuable: deep knowledge of the business processes they work with every day.But business expertise doesn’t automatically translate into good application architecture.Ian discusses the balance between empowering makers and introducing enough architecture, governance, normalization, and technical review to prevent solutions from becoming difficult to maintain.

GOVERNANCE WITHOUT KILLING INNOVATION
Too little governance creates chaos.Too much governance creates friction — and can drive employees toward unsupported workarounds, spreadsheets, VBA, and shadow IT.The challenge is finding the right level of governance based on organizational risk, application criticality, users, and business impact.

POWER PLATFORM, APIs AND AZURE
Where should business logic live?Should secrets be stored inside Power Platform? When should Azure Key Vault, Azure Functions, or API Management become part of the architecture?Ian explains why architecture should always begin with the problem being solved rather than adding Azure services simply because they are available.

GIT, SOURCE CONTROL AND CI/CD
As Power Platform development becomes more collaborative, traditional development practices become increasingly relevant.The conversation explores Git, repositories, development environments, pipelines, source control, feature isolation, cross-dependencies, and CI/CD.There may not always be a perfect approach to source control in Power Platform — sometimes the goal is choosing the “least worst option” for the project.

IAN’S POWER PLATFORM ARCHITECTURE PLAYBOOK

Ian’s core principle is straightforward:Break solutions into features and modules.Each feature should have a clear reason to exist and ideally perform one specific responsibility.Then determine how those features communicate, where logic should execute, how they should be tested, and which technology is best suited to implementing them.

THE RAPID-FIRE ROUND
Mirko puts Ian through a series of quick questions:Should every enterprise application use Dataverse?Can Power Platform build mission-critical applications?Can Power Automate replace Logic Apps?Does low-code automatically reduce technical debt?Can Power Platform replace traditional application development?And perhaps most importantly: what should you order when visiting Newcastle?

KEY TAKEAWAY
Low-code does not mean low architecture.As Power Platform solutions become larger, more connected, and more important to the business, the fundamentals of software engineering remain relevant.Architecture matters.Data modeling matters.Governance matters.Security matters.API design matters.DevOps matters.And successful enterprise Power Platform development is increasingly about understanding how low-code, pro-code, Azure, APIs, automation, and traditional software engineering practices work together.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Microsoft 365 Copilot doesn’t arrive in a clean Microsoft 365 tenant. It arrives in an environment that organizations have been building for years — full of SharePoint sites, Teams, OneDrive content, duplicate documents, historic migrations, guest accounts, inconsistent permissions, forgotten workspaces, broken ownership models, and content nobody has reviewed in years.For traditional Microsoft 365 management, much of this technical debt could remain relatively hidden. AI changes that.In this episode of M365.FM, Mirko Peters talks with Richard Harbridge, Microsoft MVP and industry advisor at ShareGate, about why AI readiness is fundamentally connected to Microsoft 365 modernization and governance.The conversation moves beyond the question of how to deploy Copilot and focuses instead on a more important question: What kind of Microsoft 365 environment are we actually giving AI access to?

COPILOT DOESN’T CREATE THE MESS — IT AMPLIFIES IT
One of the central ideas in this conversation is that Microsoft Copilot is not necessarily creating entirely new governance problems. Instead, AI makes existing problems significantly more visible and consequential.Organizations have accumulated years of decisions around permissions, sharing, workspace creation, ownership, migrations, external access, inactive content and collaboration.Richard describes this accumulation using the concept of “sprawl.”Sprawl itself is not automatically bad. A growing number of Teams, SharePoint sites and other resources can be evidence that people are successfully adopting Microsoft 365.The problem begins when that growth happens faster than the organization’s ability to manage it.Temporary permissions become permanent. Old collaboration spaces remain accessible. Ownership changes. Business structures evolve. Content stays online long after its original purpose has disappeared.Copilot then operates on top of that existing environment.

MICROSOFT 365 SPRAWL IS BIGGER THAN TEAMS AND SHAREPOINT
When people hear “Microsoft 365 sprawl,” they often immediately think about too many Teams or SharePoint sites.But Richard argues that sprawl is multidimensional.Organizations can experience workspace sprawl, permission and access sprawl, ownership problems, inactive resources, lifecycle problems, administrative complexity, conditional access sprawl and increasingly integration and connector sprawl.The rise of AI adds another dimension.Microsoft 365 environments increasingly connect data, applications, AI systems and agents. That means organizations need to think beyond individual workloads and start looking at Microsoft 365 as an interconnected ecosystem.Governance can no longer be treated purely as “SharePoint governance” or “Teams governance.”

THE CONFIDENCE GAP IN MICROSOFT 365 GOVERNANCE
Richard shares an especially interesting finding from ShareGate’s research.A very large percentage of IT leaders report being highly confident in their Microsoft 365 governance. Yet a significant portion of those same organizations report that Copilot has surfaced content that users arguably should not have been able to discover — or they suspect this may have happened but do not know how to verify it.That creates an important distinction between having governance controls available and actually having a continuously governed environment.Policies, configuration options and administrative controls alone do not guarantee that an organization understands its current Microsoft 365 state.AI can expose that gap very quickly.

DID MICROSOFT MAKE COLLABORATION TOO EASY?
Microsoft Teams, SharePoint and OneDrive are successful partly because Microsoft has made collaboration extremely easy.But easy collaboration also makes it easy to create more resources.One response organizations have traditionally used is restricting workspace creation. Richard explains why that alone does not solve the problem.A workspace created today may serve an entirely different purpose six months, one year or two years later.Its owners may change.The organization may restructure.The project may finish.The content may become irrelevant.The people who originally understood why the workspace existed may leave.Governance therefore cannot stop at provisioning.Organizations need lifecycle processes, reviews, attestations and signals that continuously determine whether resources are still appropriate.

GOVERNANCE HAS TO BECOME CONTINUOUS
One-time cleanup projects are not enough.An organization can spend months cleaning its Microsoft 365 environment before deploying Copilot, but without continuous governance, the same problems will gradually return.That means organizations need repeatable processes around ownership, permissions, inactivity, lifecycle management, archiving and retirement.The objective is not to eliminate Microsoft 365 sprawl completely.It is to turn unmanaged sprawl into managed sprawl.

WHERE SHOULD ORGANIZATIONS START BEFORE SCALING COPILOT?
Imagine an enterprise with 10,000 employees, thousands of Teams and SharePoint sites, years of accumulated content and inconsistent permissions.Where should it begin?Richard recommends looking at the specific types of sprawl and identifying where the organization carries the greatest risk.For one company, that might be access control and oversharing.For another, it might be inactive content and lifecycle management.For another organization, privileged identities or administrative management may represent the larger problem.Instead of treating Microsoft 365 governance as one enormous cleanup exercise, organizations can break the problem into measurable categories and prioritize the areas where improvement matters most.

COPILOT ADOPTION SHOULD BE TEAM-BASED
The conversation also challenges one traditional Microsoft technology adoption model.Organizations frequently deploy new technologies through distributed champions.Richard argues that Copilot benefits from a more team-oriented adoption model.Rather than distributing a small number of licenses across unrelated champions throughout an organization, companies can benefit from saturating teams with AI capabilities so that people learn together, develop shared practices and integrate Copilot into collaborative workflows.AI adoption is not only about giving individuals another productivity tool.It changes how teams work together.

MAKING MICROSOFT 365 RISK MEASURABLE
Governance initiatives often struggle because their value is difficult to communicate to business leaders.The conversation explores ShareGate’s Risk Radar, which is designed to help organizations evaluate different categories of Microsoft 365 sprawl, compare maturity against benchmarks and understand which areas deserve attention.An important part of this approach is translating governance risk into financial terms.Instead of asking leadership for time and resources simply because “we need better governance,” IT teams can connect improvements to the potential cost of unmanaged risk.That makes Microsoft 365 modernization and governance easier to position as a business investment rather than another administrative IT project.

AI AGENTS MAKE GOVERNANCE EVEN MORE IMPORTANT
Copilot is only part of the story.As organizations begin creating and deploying more AI agents, governance becomes substantially more complex.Agents can change over time. They can interact with tools, data and other systems. Their ownership can become unclear. Permissions can evolve, and organizations will eventually have to deal with agent lifecycle management at scale.Who owns an agent?Who reviews it?What resources can it access?What happens when its original owner leaves?When should an agent be retired?When should multiple agents be consolidated?These questions look remarkably similar to problems organizations already experience with Teams, SharePoint sites and other Microsoft 365 resources — except AI increases both the speed and potential impact.

GOVERNANCE FROM THE RESOURCE UP
Richard discusses the importance of looking at governance from the underlying resources upward.An AI experience may sit on top of SharePoint, Microsoft 365 data, Power Platform resources, connectors, permissions and other systems.Organizations therefore cannot govern only the visible AI interface.They need to understand the complete chain of resources, data and permissions supporting it.This becomes increasingly important as agents gain more capabilities and organizations move from relatively simple assistants toward agents that can take action.

THE FUTURE IS “EVERYTHING GOVERNANCE
”Looking several years ahead, Richard expects Microsoft governance to become significantly more holistic.Instead of separate conversations about SharePoint governance, Teams governance, Power Platform governance and AI governance, organizations increasingly need to understand how all of these layers interact.Microsoft Purview is highlighted as an important part of this evolution, particularly as Microsoft expands capabilities around data security and posture management.Governance professionals therefore need to broaden their perspective beyond the administration interface or workload they traditionally specialized in.AI sits across boundaries.Governance increasingly has to do the same.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Does Microsoft 365 Copilot really make people more productive?In this episode of the M365 FM podcast, Mirko Peters speaks with Microsoft MVP Adrian Espes about what Copilot actually delivers in everyday work—not in a polished demo, but during a normal working day filled with meetings, emails, documents, Teams messages, deadlines, and constant interruptions.Adrian brings a practical perspective shaped by his experience in training, business analytics, modern workplace consulting, and Microsoft 365 adoption. Together, Mirko and Adrian look beyond the marketing and explore where Copilot is genuinely useful, where expectations are still unrealistic, and what organizations need to consider before rolling it out.

MICROSOFT 365 COPILOT IN THE REAL WORLD
Adrian explains why Microsoft 365 Copilot’s biggest advantage is its position inside the Microsoft ecosystem. Unlike standalone AI tools, Copilot can work directly with the applications people already use every day, including Outlook, Teams, Word, PowerPoint, Excel, and Edge.The conversation explores how Copilot can help users summarize meetings, catch up on conversations, identify follow-up tasks, work with documents, and create useful outputs without constantly moving information between different tools.

PROMPTING WITHOUT BECOMING A PROMPT ENGINEER
Do employees really need to become prompt engineers?Adrian shares a realistic approach to prompting. Users do not need to learn complicated formulas or memorize a perfect prompt structure. Instead, they should practice explaining their goal clearly, provide relevant context, describe the desired outcome, and refine their requests over time.The discussion also covers why different departments and roles may need different prompting approaches. A financial analyst, a marketing professional, a manager, and a frontline worker will all use Copilot differently because their goals and daily tasks are different.

PRODUCTIVITY, EFFICIENCY, AND THE HUMAN FACTOR
One of the central themes of this episode is the difference between productivity and efficiency.Adrian explains why the word “productivity” can create anxiety among employees. When companies talk about productivity, many workers may fear that AI is being introduced to measure performance or replace jobs.Instead, Adrian suggests focusing on efficiency, better work quality, reduced friction, and making AI a natural part of everyday work. The real question is not simply whether someone completes more tasks, but whether Copilot helps them work with less effort, better information, and more time for meaningful activities.

DATA QUALITY, GOVERNANCE, AND SECURITY
Copilot can only be as useful as the information available to it. That makes data quality, permissions, governance, and information architecture essential parts of any Microsoft 365 Copilot project.Mirko and Adrian discuss the importance of reviewing the Microsoft 365 environment before implementation. This includes checking permissions, overshared information, tenant configuration, data protection, sensitivity labels, and the way users store and access content.Adrian also explains the importance of using enterprise accounts and understanding how enterprise data protection works when employees use Microsoft Copilot in a business environment.

MICROSOFT 365 COPILOT AND AI MODELS
The conversation also looks at the growing number of AI tools and models available today, including Microsoft Copilot, ChatGPT, Claude, Gemini, Perplexity, and different models available through GitHub and Microsoft platforms.Rather than asking which AI tool is universally the best, Adrian recommends choosing the right tool for the task. Some tools may be stronger for coding, reasoning, image creation, or creative work, while Microsoft 365 Copilot’s major strength is its integration with business data and workplace applications.

A PRACTICAL COPILOT IMPLEMENTATION ROADMAP
Buying Copilot licenses is only the beginning.Adrian outlines the considerations organizations should address when planning a Microsoft 365 Copilot rollout. Before investing in additional licenses, companies should first understand what is already available through their existing Microsoft 365 plans and evaluate whether users genuinely need the full Copilot experience.The implementation process should also include:Reviewing the Microsoft 365 tenant and existing configurationsChecking permissions and data governanceUnderstanding regulatory and regional requirementsEvaluating which users and roles will benefit mostDefining realistic use casesSupporting employees through training and experimentationMeasuring efficiency and adoption instead of relying only on license usage

WILL COPILOT ELIMINATE MEETINGS?
During the rapid-fire section, Mirko asks Adrian whether Copilot will eliminate most meetings.Adrian’s answer: for now, this is still mostly hype. Copilot can make meetings easier to follow, summarize discussions, and identify actions, but it does not automatically solve the organizational reasons why too many meetings exist.They also discuss whether AI agents will replace traditional business applications. Adrian believes agents will become increasingly important, but they will work alongside business applications rather than replace them entirely. Strong governance, security, visibility, and management will be essential as organizations create more agents.

IS COPILOT USEFUL FOR FRONTLINE WORKERS?
The value of Copilot for frontline workers depends heavily on their role and daily responsibilities.For employees who regularly work with email, Teams, documents, or operational information, Copilot may provide real benefits. However, not every frontline worker uses Microsoft 365 applications in the same way as an office-based employee.Adrian explains why organizations should avoid assuming that one Copilot strategy will work for every employee group. Adoption needs to be connected to real tasks, real users, and real business needs.

KEY QUESTIONS DISCUSSED IN THIS EPISODE
Does Microsoft 365 Copilot really improve productivity?What makes Microsoft 365 Copilot different from ChatGPT, Claude, Gemini, and other AI tools?Do employees need to become prompt engineers?How can users improve their prompts?Why do data quality and governance matter so much?How should organizations prepare for a Copilot rollout?What should companies evaluate during the first 30, 60, and 90 days?Can Copilot reduce meetings?Will AI agents replace traditional business applications?Is Copilot useful for frontline workers?How can organizations measure efficiency without creating fear among employees?

ABOUT ADRIAN ESPES
Adrian Espes is a Microsoft MVP focused on Microsoft 365 and Copilot. He works as a consultant and trainer, helping organizations understand, adopt, and use Microsoft technologies in practical business environments.His background includes sales, training, data analytics, business workflows, and modern workplace consulting. Adrian is passionate about helping people use AI more naturally and effectively in their daily work.

FINAL THOUGHTS
Microsoft 365 Copilot is not a magic productivity button. Its value depends on the quality of an organization’s data, the clarity of its use cases, the preparation of its environment, and the willingness of employees to experiment and learn.The most successful Copilot implementations will not focus only on buying licenses or showcasing impressive demos. They will focus on helping people work more efficiently, make better decisions, reduce repetitive effort, and use AI as a practical part of the modern workplace.Listen to this episode to discover what Microsoft 365 Copilot can really do beyond the hype.

ABOUT THE M365 FM PODCAST
The M365 FM podcast explores the people, ideas, and technologies shaping the future of work across Microsoft 365, Copilot, AI, security, governance, Power Platform, and the modern workplace.Hosted by Mirko Peters, every episode features conversations with Microsoft MVPs, product experts, consultants, architects, and practitioners from across the global Microsoft ecosystem.Subscribe to M365 FM for practical conversations about what works, what does not, and what organizations need to know next.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Microsoft 365 has given organizations more tools than ever to communicate, collaborate, automate, and manage information. Now Microsoft 365 Copilot adds an entirely new layer of AI capability. But behind all the discussion about productivity, automation, agents, and AI, there is a much bigger question: are these technologies simply helping us work faster, or are they fundamentally changing the way we think, learn, communicate, collaborate, and work?In this episode of m365.fm, Mirko Peters sits down with Tracy van der Schyff to explore the human side of Microsoft 365 and Copilot. Tracy has spent years working at the intersection of technology, productivity, digital literacy, training, adoption, and organizational change. Her focus is not simply on teaching people which buttons to click. It is about helping people understand technology, use it with purpose, and become more capable because of it.The conversation goes far beyond Copilot features. Mirko and Tracy discuss digital fluency, Microsoft 365 adoption, information management, AI readiness, change management, responsible AI, the broken digital workplace, and a powerful idea that runs throughout the episode: we design technology, but the technology we create and use also shapes us.

FROM DIGITAL LITERACY TO DIGITAL FLUENCY
For many years, organizations talked about PC literacy and later digital literacy. But Tracy believes those terms no longer fully describe the skills people need in a modern workplace.Knowing how to operate a computer is not enough. Knowing where a button is inside Microsoft Teams or how to upload a document to SharePoint does not necessarily mean somebody understands how to work effectively in a digital environment.Digital fluency goes further. It means understanding the purpose of a technology, knowing when it should be used, understanding how your actions affect other people, and using technology responsibly and intentionally.This becomes even more important as AI enters everyday work. Tracy explains how her original model of eight pillars of digital literacy has evolved into eleven pillars of digital fluency, now incorporating responsible AI use and the additional skills people need when working alongside AI systems.The important distinction is that these are not simply Microsoft 365 skills. They are becoming life skills.AI is also creating unexpected opportunities to develop human skills. Communicating effectively with Copilot requires people to explain what they actually want. Better questions can produce better answers, and those answers can help people formulate better questions the next time. In that sense, working with AI can improve communication, creativity, critical thinking, and the ability to express intent clearly.

THE MICROSOFT 365 TOOL OVERLOAD PROBLEM
Teams, Outlook, SharePoint, OneDrive, Loop, Planner, Lists, Power Platform, Copilot and countless other applications give employees enormous capabilities. But providing access to tools does not automatically teach people how those tools should fit together.Organizations often deploy technology and expect employees to figure out the rest.That can result in departmental information being shared from personal OneDrive accounts, Teams being created simply for individual meetings, documents being stored in inappropriate locations, and employees constantly switching between tools without understanding where work actually belongs.When that happens, Tracy argues that blaming users is the wrong response.If an employee was never taught the intent behind Teams, SharePoint, OneDrive, Outlook, or another application, they will naturally choose whatever tool helps them complete the immediate task. The underlying problem is often not the employee. It is the absence of a clear digital strategy.

ME, WE, US: SIMPLIFYING THE DIGITAL WORKPLACE
One framework Tracy uses to make the Microsoft 365 environment easier to understand is ME, WE, US.The ME space represents the individual. These are the tools and information primarily associated with your personal work.The WE space begins when people collaborate around a common goal. Microsoft Teams and collaborative SharePoint environments become particularly relevant here.The US space represents information intended for the broader organization, such as publishing environments and intranets.This sounds simple, and that is precisely the point.Employees should not need to understand every architectural detail behind Microsoft 365 before they can make a sensible decision about where their work belongs. Organizations need to translate complicated technology landscapes into models that ordinary employees can understand and apply.

COPILOT DOES NOT FIX A BROKEN DIGITAL WORKPLACE
One of the strongest messages from the conversation is that Microsoft 365 Copilot should not be treated as a solution for an already broken digital workplace.Copilot does not magically repair years of poor information architecture, excessive sharing, unmanaged Teams, confusing permissions, duplicated documents, abandoned SharePoint sites, or inconsistent working practices.Instead, Tracy describes AI as an amplifier.If an organization has a healthy digital environment, Copilot can amplify that healthy environment. If the underlying environment is unhealthy, AI can make those existing problems significantly more visible.In that sense, Copilot acts like a huge spotlight.Information that may previously have been difficult to discover can suddenly become much easier to surface. That can make organizations believe Copilot created a problem when, in reality, the underlying permissions, sharing practices, or information-management problems may have existed for years.The AI did not necessarily create the mess. It exposed it.

ONTOLOGICAL DESIGN: THE THINGS WE CREATE CHANGE
USA fascinating part of the conversation explores ontological design.The concept sounds complicated, but Tracy explains it in a very practical way: we create things, and the things we create eventually change us.That applies to software, applications, intranets, processes, social media, Microsoft Teams, Copilot, and almost every digital environment people interact with.When someone designs an application, they make decisions about how users will interact with it. Those decisions influence the behavior of the people using the application.The same principle applies at a much larger scale to the modern workplace.Employees can spend many hours every day inside Teams, Outlook, SharePoint, OneDrive, Microsoft 365, and increasingly Copilot. Those environments are therefore not neutral. They influence how people communicate, how quickly they expect responses, how they organize information, how they collaborate, and even how they think about work.The intention behind what we design matters because what people consume eventually influences them.

WHEN ACTIVITY BECOMES CONFUSED WITH PRODUCTIVITY
Microsoft Teams and other collaboration tools have dramatically reduced the friction required to communicate. But reducing friction can also create enormous amounts of noise.Tracy raises an interesting problem: people can begin to use visible activity as proof that they are productive.More messages. More notifications. More updates. More documents. More meetings. More channels.But every communication creates work for somebody else.A message that takes one person a few minutes to write might interrupt dozens or hundreds of other employees. Individually, that interruption may seem insignificant. Across an organization, the cumulative cost can become substantial.The question therefore should not simply be whether Microsoft 365 allows us to communicate faster. Organizations also need to ask whether all of that communication is necessary in the first place.

AI CAN BE MORE THAN A PRODUCTIVITY TOOL
Many discussions about Copilot focus on straightforward productivity scenarios.Summarize my emails. Summarize this meeting. Create a presentation. Rewrite this document. Analyze this information. Help me find something.Those capabilities are useful, but Tracy argues that AI can become something much more interesting.People can use AI to learn.Someone who struggles with delegation can ask Copilot how to become better at delegating. Someone intimidated by AI can ask AI how to begin learning about AI. Someone concerned about cybersecurity can ask how to protect themselves and their family. Someone who lacks confidence with a technology can use AI as a private environment for experimentation and learning.This moves the conversation from simply asking, “How much time can Copilot save?” toward asking, “How can Copilot increase human capability?”That distinction is important.The most valuable use of AI may not always be automating another task. Sometimes it may be helping someone become better at performing that task themselves.

AI DOES NOT REMOVE HUMAN RESPONSIBILITY
Copilot might summarize hundreds of emails, but responsibility does not disappear if an important message is missed.AI can generate a document quickly, but somebody still needs to understand why that document exists.AI can retrieve organizational information, but companies still need to understand permissions, ownership, governance, security, and information management.AI can produce an answer, but people still need the judgment required to evaluate that answer.For Tracy, this is another reason digital fluency becomes more important as AI becomes more capable.Organizations should not respond to increasingly powerful technology by investing less in human skills. They should invest more.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Modern SharePoint development does not mean building every component from scratch. In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP Siddharth Vaghasia about building production-ready SharePoint Framework (SPFx) solutions by combining the right Microsoft 365 technologies with reusable community components.Siddharth brings nearly 18 years of experience across the Microsoft technology stack, from .NET and the early days of SharePoint Server to SharePoint Online, Microsoft 365, Power Platform, Azure, and modern SPFx development.

WHEN SHOULD YOU ACTUALLY USE SPFx?
Not every SharePoint requirement needs custom development. Siddharth explains a simple principle: first determine whether Microsoft already provides the functionality. If the requirement can reasonably be solved with standard SharePoint capabilities, avoid unnecessary customization.SPFx becomes valuable when organizations need experiences, integrations, or interfaces that cannot be delivered effectively with out-of-the-box functionality.

SPFx VS POWER PLATFORM
Should you build the solution with SPFx or Power Apps?The discussion explores where each approach fits. Power Apps can be effective for relatively straightforward forms, conditional fields, business rules, and scenarios where citizen development and low-code maintainability matter.SPFx becomes particularly powerful when developers need greater control over the user interface, complex data handling, reusable components, APIs, or sophisticated application experiences directly inside SharePoint. Siddharth also argues that generative AI coding tools are changing the traditional assumption that pro-code development necessarily takes longer than low-code development.

THE MODERN SPFx TECHNOLOGY STACK
A modern SPFx project brings together several technologies rather than relying on one framework.Siddharth breaks down the roles of TypeScript, React, Fluent UI, PnPjs, and PnP React Controls. TypeScript provides stronger typing and compile-time checks, while Fluent UI helps custom solutions retain the familiar Microsoft user experience.PnPjs simplifies interaction with SharePoint, Microsoft Graph, and other Microsoft 365 services by replacing repetitive REST request code with reusable abstractions.

STOP REBUILDING CONTROLS THAT ALREADY EXIST
One of the central lessons of the episode is simple: professional development does not mean writing everything yourself.PnP React Controls provide SharePoint-aware and Microsoft 365-aware components for common development requirements. Instead of repeatedly creating the UI, API calls, data binding, and associated logic for components such as file pickers, developers can use established community controls.Siddharth's preferred approach is to check existing capabilities first: use Microsoft functionality when available, then Fluent UI or PnP React Controls where they satisfy the requirement, and create a custom component only when the required functionality does not already exist.

THE FIVE PnP REACT CONTROLS DEVELOPERS SHOULD KNOW
If Siddharth had to choose only five controls, his selection would be People Picker, Taxonomy Picker, List View, File Picker, and Live Persona.These components cover several recurring requirements in enterprise SharePoint applications, including selecting users, working with managed metadata, presenting SharePoint data, selecting or uploading files, and displaying Microsoft 365 user information.

BUILDING REAL APPLICATIONS INSIDE SHAREPOINT
The conversation moves from individual controls to application architecture with the example of a sophisticated project management solution.SharePoint lists can provide the underlying data layer for projects, customers, resources, and tasks, while SPFx can deliver a unified application experience containing dashboards, project views, charts, CRUD operations, role-specific interfaces, task management, and navigation.The result can feel much more like a dedicated business application while remaining embedded inside the SharePoint environment users already know.

SHAREPOINT DOESN'T HAVE TO BE YOUR DATABASE
SPFx applications are not restricted to SharePoint data.Siddharth discusses retrieving information from Dataverse and integrating external systems. When data resides in systems such as Azure SQL, a backend API can provide the secure middle layer between the client-side SPFx application and the database.He also describes a real example where an SPFx web part surfaces Power Automate approvals directly inside SharePoint and allows users to approve or reject requests without moving to another application.

MICROSOFT GRAPH AND SPFx
Microsoft Graph expands SPFx far beyond SharePoint itself.Applications can interact with Microsoft 365 services including OneDrive, Planner, Outlook, meetings, and other resources exposed through Graph. Siddharth explains when SharePoint REST APIs remain appropriate and when Graph becomes the better or necessary option.

SECURITY, PERMISSIONS AND LEAST PRIVILEGE
Security is a major part of professional SPFx development.SPFx solutions calling Microsoft Graph typically operate using delegated permissions and therefore respect the identity and access rights of the currently signed-in user. Requested API permissions also require administrative approval.One of the most common mistakes Siddharth sees is requesting more permissions than the application actually requires. His recommendation is to start with the minimum permissions necessary rather than granting broad access by default.Developers also need to test solutions from the perspective of real users instead of assuming that permissions available during development will also exist in production.

NEVER PUT SECRETS IN CLIENT-SIDE SPFx CODE
Because SPFx executes client-side, sensitive secrets should never be embedded directly into the application code.For scenarios requiring secrets or credentials, Siddharth recommends introducing a backend API that can securely access services such as Azure Key Vault while the SPFx frontend communicates only with that API.

SECURITY REVIEW DOESN'T END WITH YOUR OWN CODE
SPFx relies heavily on the modern JavaScript and npm ecosystem. Organizations therefore need to consider the security and maintenance status of third-party packages as well as their own application logic.Siddharth recommends reviewing dependencies, paying attention to package warnings and vulnerabilities, and including security assessment as part of the deployment process rather than assuming every dependency is safe simply because it is available through npm.

WHY IS YOUR SPFx SOLUTION SO SLOW?
When an SPFx application performs badly, Siddharth starts with the browser's network tools.Developers should examine how many API calls occur during page load, identify unnecessary requests, look for API calls accidentally executed inside loops, and inspect React components for excessive rendering or state changes.A seemingly simple application can generate dozens of requests when data retrieval is implemented inefficiently.

BATCH YOUR REQUESTS
Once unnecessary API traffic has been identified, batching can significantly improve how requests are handled.Instead of sending multiple individual operations from the client, developers can combine appropriate SharePoint operations into batch requests and reduce client-side request overhead.

FROM DEVELOPMENT TO THE SHAREPOINT APP CATALOG
Siddharth also walks through the SPFx deployment process, from packaging the solution into an .sppkg package to deploying it through the SharePoint App Catalog and approving required API permissions.Importantly, deploying a package does not automatically mean installing it everywhere. Organizations can control which SharePoint sites receive the application, and site collection App Catalogs can provide an even narrower deployment scope.

SPFx MEETS COPILOT AND AI AGENTS
SPFx is also moving into the agent era.Siddharth discusses SharePoint Copilot apps and how SPFx can provide interactive user-interface components inside Microsoft 365 Copilot experiences. Instead of returning only text or Markdown, an agent can potentially surface richer interfaces that users can interact with directly.He describes the concept as similar to taking the idea behind Adaptive Cards much further by enabling richer, more customizable application experiences.

THE BIG TAKEAWAY
The strongest SharePoint developers are not necessarily the developers who write the most code.They know when to use SharePoint out of the box, when Power Platform is sufficient, when SPFx provides the necessary flexibility, when Microsoft Graph is required, and when existing Fluent UI and PnP components can eliminate unnecessary development.The goal is not to reinvent another component. It is to combine the Microsoft 365 ecosystem into solutions that are secure, maintainable, performant, accessible, and capable of solving an actual business problem.

ABOUT SIDDHARTH VAGHASIA
Siddharth Vaghasia is a Microsoft MVP, consultant, founder, speaker, blogger, and community contributor specializing in Microsoft 365, SharePoint, Power Platform, Azure, and related technologies. He also discusses his company Binary Roots and its work with customers across multiple international markets.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

For years, SharePoint has carried a reputation for complicated document libraries, outdated intranets, confusing navigation, too many sites, and information that employees simply cannot find. But Microsoft 365 is changing, and Copilot is making SharePoint more important than it has been in a long time.In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP Marcin Siewnicki about how SharePoint is evolving from a traditional document and intranet platform into a central information and knowledge layer for the modern workplace. Marcin has worked with SharePoint since the SharePoint 2003 era, giving him more than two decades of perspective on how the platform has changed.

WHY SHAREPOINT GOT A BAD REPUTATION
Much of SharePoint’s reputation was created by the way organizations implemented it. Intranets were often designed by IT, heavily customized, difficult to use, and disconnected from what employees actually needed.Instead of continuously gathering feedback and improving the experience, many companies delivered an intranet and expected employees to adapt to it. The result was complex navigation, outdated content, overloaded pages, and systems people avoided whenever possible.

INFORMATION ARCHITECTURE BEFORE TECHNOLOGY
One of the biggest problems is not SharePoint itself but how information is organized inside it. Without a clear information architecture, SharePoint can quickly become a huge shared folder filled with duplicated files, outdated information, unclear ownership, and multiple versions of the same document.Marcin explains why organizations should start with a simple structure, understand their data, remove unnecessary content, and introduce basic metadata. Information architecture does not have to be complicated to make SharePoint significantly easier to use.

BUILDING A MODERN SHAREPOINT WORKPLACE
A modern SharePoint homepage should not become an endless collection of web parts, corporate announcements, applications, and links. It should be simple, personalized, visually clear, and focused on what employees actually need.Communication sites can provide departments and organizations with modern, mobile-friendly publishing experiences without requiring the enormous custom intranet projects that were common in the past. The focus should be on useful information, important applications, relevant documents, straightforward navigation, and strong search capabilities.

SOLVING THE SHAREPOINT NAVIGATION PROBLEM
Navigation remains one of SharePoint’s biggest challenges. Organizations frequently attempt to expose every department, application, resource, and internal page through a single navigation structure.Marcin explains why simpler navigation usually works better. Global navigation should focus on the most important destinations, while detailed navigation can be provided closer to individual departments, sites, and business areas. Otherwise, navigation itself becomes another information problem.

SHAREPOINT AND TEAMS SPRAWL
Microsoft Teams and SharePoint are deeply connected. Every new Team and many Teams channels can introduce additional SharePoint resources, which means uncontrolled Teams creation can quickly become uncontrolled SharePoint growth.Organizations therefore need simple creation processes, templates, basic metadata, lifecycle management, and user education. Employees should understand when they need a Team, when a SharePoint site is sufficient, and what happens behind the scenes when these collaboration environments are created.One useful way of looking at the relationship is to think of Microsoft Teams as the collaboration interface while SharePoint provides much of the document and information layer underneath it.

GOVERNANCE WITHOUT KILLING INNOVATION
Governance does not need to mean preventing employees from using new technology. The goal is to provide enough freedom for people to work effectively while maintaining control over information, permissions, external sharing, security, and lifecycle management.Marcin discusses periodically reviewing inactive SharePoint sites and Teams, identifying environments that are no longer needed, checking ownership, reviewing permissions, and archiving or removing obsolete workspaces.Governance also cannot remain exclusively an IT exercise. Business stakeholders and users need to be involved because overly complicated policies often lead employees to find their own workarounds.

PERMISSIONS, SHARING AND SECURITY
Permissions become increasingly difficult to understand as SharePoint environments grow. Users add colleagues, external partners, vendors, and sharing links over time, but access is rarely reviewed with the same frequency.Regular permission reviews should therefore become part of the governance model. Site and Team owners need responsibility for checking who still requires access and whether external sharing remains necessary.Microsoft Purview sensitivity labels can add another security layer by helping organizations classify and protect information based on its sensitivity.

AUTOMATING SHAREPOINT GOVERNANCE
Governance does not have to be completely manual. PowerShell, Microsoft Graph, Power Automate, Azure Logic Apps, and specialized third-party platforms can automate many administrative and governance processes.Marcin sees PowerShell and Microsoft Graph as fundamental tools for administrators, while Power Automate can provide practical automation for provisioning, approvals, notifications, lifecycle processes, and many other SharePoint scenarios.

MODERN DOCUMENT MANAGEMENT
SharePoint is still heavily associated with documents, and documents remain an important part of the platform. The challenge is managing them properly.Metadata, naming conventions, permissions, versioning, storage management, and sensitivity labels all contribute to a healthier information environment. Versioning deserves particular attention because large documents with many retained versions can consume significant amounts of SharePoint storage.

METADATA VS. FOLDERS
The old SharePoint debate between folders and metadata has not completely disappeared. Marcin argues that metadata remains extremely valuable, but organizations need to keep their metadata models simple.If users need to spend too much time deciding how to classify every document, adoption will suffer. Metadata should support the way employees work rather than creating another administrative task.

COPILOT CAN AUTOMATE METADATA
Copilot changes this equation because AI can reduce the manual work associated with metadata. SharePoint can analyze documents, extract relevant information, and populate columns based on the content.Organizations still need to decide which metadata is useful, but employees no longer necessarily have to enter everything manually. This can make structured information much more practical at scale.

COPILOT CHANGES SHAREPOINT
Copilot significantly lowers the amount of SharePoint knowledge employees need before they can start accomplishing useful work.Users can increasingly create content, work with documents, extract information, generate pages, and interact with organizational knowledge using natural language instead of understanding every technical SharePoint concept.Many of the repetitive tasks traditionally associated with maintaining SharePoint environments can therefore become easier.

FROM FINDING DOCUMENTS TO GETTING ANSWERS
This may be the biggest change of all.Traditional SharePoint experiences required employees to find the right site, navigate to the right library, locate the correct document, open it, and search for the information they needed.Copilot changes that interaction. Instead of only finding documents, employees can increasingly ask questions and receive answers based on information stored across their Microsoft 365 environment.SharePoint therefore starts moving from document storage toward becoming an enterprise knowledge layer.

COPILOT CAN UNDERSTAND MORE THAN OFFICE DOCUMENTS
Organizational knowledge is not limited to Word documents, Excel files, and PowerPoint presentations.Copilot can work with different types of information, including text, HTML, Markdown, SharePoint lists, and content extracted from video transcripts.That means training videos, recorded meetings, presentations, and other media stored within the Microsoft 365 environment can become part of the knowledge available through AI.

WHAT HAPPENED TO SHAREPOINT AGENTS?
SharePoint Agents provide dedicated AI experiences grounded in selected SharePoint sites, document libraries, or information sources.Marcin discusses where these agents fit into the current Copilot landscape and why the concept has become less prominent as Copilot itself gains broader capabilities for interacting directly with SharePoint information.

IS SHAREPOINT REALLY COPILOT’S KNOWLEDGE LAYER?
There is certainly marketing around the idea, but there is also a strong technical reality behind it.Organizations already store enormous amounts of business information in SharePoint and Microsoft Teams. Copilot can use this information, which means the quality of the underlying environment directly affects the quality of the AI experience.Poor permissions, outdated documents, duplicated information, weak metadata, and uncontrolled SharePoint sprawl do not disappear because Copilot has been introduced. They potentially become even more important

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Microsoft Fabric brings data engineering, analytics, business intelligence, governance and increasingly AI together in one platform. But what does an end-to-end Fabric architecture actually look like when you move beyond individual features and start connecting everything?In this episode of the M365 FM Podcast, Mirko Peters is joined by Amit Chandak [Microsoft Data Platform MVP] for a practical journey through Microsoft Fabric — starting with raw organizational data and ending with trusted information that business users can use to make decisions.

WHY MICROSOFT FABRIC?
Before Fabric, organizations could already build sophisticated analytics architectures using Azure, Power BI and other platforms. The problem wasn't a lack of technology. In many cases, it was the opposite: organizations had too many choices, separate storage technologies, different compute models and multiple copies of essentially the same data.Amit explains how Microsoft Fabric attempts to simplify this architecture by bringing workloads together around shared foundations such as OneLake, common Fabric capacity and the Delta format. Lakehouses, warehouses, Power BI and other Fabric experiences can therefore operate as parts of a broader platform instead of completely isolated services.

ONELAKE AS THE FOUNDATION
OneLake is one of the central concepts behind Fabric. Amit compares it conceptually to OneDrive: instead of every analytics workload creating completely independent storage environments, OneLake provides a virtualized storage foundation across the Fabric tenant.Organizations can still separate data through workspaces, Lakehouses, Warehouses and domains, but those resources exist within a common Fabric storage architecture. This becomes particularly important when organizations want to reduce unnecessary duplication while maintaining security and organizational boundaries.

CENTRALIZED DATA OR DATA MESH?
Fabric doesn't automatically mean putting everything into one giant centralized analytics environment.For smaller organizations, a centralized architecture may still work well. As organizations become larger, Amit sees increasing value in domain-oriented architectures where areas such as sales, finance and purchasing can have their own workspaces and responsibilities.IT can remain responsible for availability, governance and the technical foundation while business domains increasingly take ownership of how their data is analyzed and consumed.

SHORTCUTS INSTEAD OF COPYING DATA
One of the recurring themes throughout the conversation is avoiding unnecessary copies of data.Fabric Shortcuts allow teams to reference data stored elsewhere rather than physically copying it into every environment that needs it. That can apply both inside Fabric and to supported external storage.Amit also explains an interesting architectural benefit of shortcuts: they can help separate workloads across capacities. This can become important when organizations want Power BI consumption workloads isolated from intensive data engineering workloads while still working with the same underlying information.

LAKEHOUSE VS. WAREHOUSE
One of the biggest Fabric architecture questions remains: Should you use a Lakehouse or a Warehouse?A Lakehouse can work with structured and unstructured data and is naturally aligned with Spark. A Fabric Warehouse focuses on structured data and provides the familiar T-SQL experience.Both ultimately use Delta for structured data inside Fabric, which means the decision increasingly comes down to the type of data, preferred technologies and workloads.Organizations with strong SQL teams don't necessarily need to abandon their existing skills. Teams working with very large datasets, advanced engineering scenarios, unstructured information or extensive data science workloads may find the Lakehouse and Spark approach more attractive.

GETTING DATA INTO FABRIC
Once the architecture is defined, organizations still need to bring data into Fabric.Amit walks through several approaches, including Shortcuts, Mirroring, Pipelines, Copy Activity, Copy Jobs, Dataflow Gen2 and notebooks.The right option depends heavily on the source and use case. Dataflow Gen2 remains particularly useful because of its broad connector support and familiar Power Query experience. For Power BI professionals entering Fabric, this can provide a natural starting point before moving toward more engineering-oriented approaches.

WHEN PYSPARK BECOMES IMPORTANT
Power Query and Dataflow Gen2 can work very well for small and medium-sized workloads, but scale changes the equation.For larger transformation workloads, Amit sees significant advantages in Spark-based processing. PySpark and Spark notebooks provide greater flexibility and are designed for distributed processing at scale.SQL and Power BI professionals don't necessarily have to make that transition immediately. Spark SQL can provide a familiar entry point for SQL developers, while many PySpark operations have conceptual similarities to transformations Power Query users already understand.

DO YOU REALLY NEED BRONZE, SILVER AND GOLD?
The Medallion Architecture has become almost synonymous with modern data engineering: Bronze for raw data, Silver for cleaned and transformed data, and Gold for business-ready information.But Amit argues that organizations shouldn't create layers simply because an architecture diagram says they should.If an organization already has excellent master data management and high-quality source data, every intermediate layer may not provide enough value to justify another copy and another transformation step. Where source data quality is inconsistent, however, the traditional Bronze-Silver-Gold structure remains highly valuable.

WHERE SHOULD BUSINESS LOGIC LIVE?
Another important architecture decision is determining where calculations and business rules belong.Amit prefers keeping measures and KPIs in the semantic model where possible because they remain dynamic and easier to change. Heavy row-level calculations across millions of records, however, are generally better handled earlier in the Gold layer.The result is not an either-or decision. A mature Fabric architecture distributes business logic deliberately between the transformation layer and semantic model depending on the type and cost of the calculation.

SEMANTIC MODELS ARE BECOMING MORE IMPORTANT
The semantic model was traditionally viewed primarily as the foundation for Power BI reports. AI is changing that role.Relationships, measures, KPIs and business definitions encoded within a semantic model represent organizational knowledge. That knowledge can increasingly be consumed by experiences beyond traditional dashboards.Amit discusses how Data Agents, ontology-driven solutions and Fabric Apps can build on semantic models. Instead of being merely a Power BI component, the semantic model can become a reusable business layer between organizational data and multiple human or AI-driven experiences.

DOES DAX STILL MATTER IN THE AI ERA?
AI can already generate DAX, SQL, PySpark and other code remarkably quickly. Does that mean professionals no longer need to learn these languages?Amit argues that expertise still matters, particularly when generated solutions don't work correctly or need optimization. AI can dramatically reduce the amount of syntax professionals need to write manually, but understanding the underlying logic remains valuable for debugging and improving what AI creates.Over time, the skill may shift from remembering syntax toward understanding architecture, algorithms, business logic and how to describe requirements precisely.

SECURITY FROM WORKSPACE TO DATA
Putting more organizational data into a unified platform makes security increasingly important.The discussion covers security across multiple layers, beginning with Fabric workspace roles and continuing through item-level access, OneLake security and semantic-model security.For larger organizations, Amit recommends using security groups rather than managing individual users wherever possible. Microsoft Entra provides the identity and group foundation, while Fabric applies those identities and groups to workspaces, items and data access.

FROM DATA ENGINEERING TO BUSINESS DECISIONS
Ultimately, most business users don't care whether their information came through PySpark, a Lakehouse, Delta tables or Dataflow Gen2. They care about getting reliable answers.This is where Amit sees Data Agents, ontology and AI-driven analytics becoming increasingly important.Instead of every user receiving the same predefined dashboard, future analytics experiences could become far more dynamic. Users may interact conversationally with organizational data and eventually have personalized reports or applications generated around their specific questions and responsibilities.

RAPID FIRE
The episode closes with a rapid-fire round.SQL or PySpark? PySpark.Dataflow Gen2 or Notebook? Notebook.DAX or SQL? DAX.Most underrated Fabric feature? Fabric Apps.Biggest Power BI modeling mistake? Many-to-many relationships.And perhaps the most provocative answer of the episode:Are Fabric Apps the new Power BI?Amit's answer: Yes.

THE BIG PICTURE
Microsoft Fabric isn't simply another analytics product to add to the Microsoft stack.Its larger opportunity is connecting ingestion, engineering, storage, Lakehouse and Warehouse architectures, semantic models, security, Power BI and emerging AI experiences into one coherent analytics platform.The technical architecture matters, but the endpoint isn't OneLake, PySpark or even Power BI.The endpoint is trusted information that people — and increasingly AI agents — can turn into better business decisions.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Enterprise AI is moving beyond chatbots that simply answer questions. The next generation of AI agents can understand business context, connect to enterprise systems, orchestrate workflows, and take action on behalf of users.But building an impressive AI agent demo is easy. Building an agent that works reliably across a global enterprise—with sensitive data, complex business processes, governance requirements, thousands of users, and measurable outcomes—is a very different challenge.In this episode of the M365 FM Podcast, Mirko Peters talks with Manpreet Singh [MVP/MCT] about what it actually takes to build production-ready enterprise AI agents with Microsoft Copilot Studio and the wider Microsoft AI ecosystem.Manpreet explains how organizations are evolving from individual departmental agents toward multi-agent architectures where specialized agents collaborate behind a single interface. The discussion explores when to use Microsoft 365 Copilot, Copilot Studio, and Azure AI Foundry—and how these technologies can work together rather than becoming isolated AI platforms.

FROM ANSWERS TO ACTIONS
The real transformation begins when an AI agent can do more than retrieve information.Using practical examples, Manpreet explains how agents can connect with systems such as Workday, Salesforce, SAP, ServiceNow, Jira, Confluence, and PeopleSoft. Instead of navigating several applications manually, employees can interact with an agent through Microsoft Teams or another conversational interface.An employee requesting leave, for example, could have an agent check available leave, consult HR policies, initiate the request in the underlying HR system, ask the manager for approval, and return the final result—all without the employee opening the individual applications.

KNOWLEDGE, TOOLS AND TRIGGERS
A useful enterprise agent requires more than a good prompt.Manpreet breaks the architecture down into essential elements: knowledge sources that provide organizational context, tools and connectors that allow the agent to interact with enterprise systems, and triggers that determine when processes should begin.SharePoint can become an important knowledge layer, while Power Platform connectors and APIs enable agents to perform actions across business applications.

WHY DATA QUALITY MATTERS
Connecting an agent to twenty years of SharePoint content is not necessarily a good strategy.Manpreet strongly recommends cleaning and curating organizational knowledge before exposing it to AI. Thousands of outdated PDFs, duplicate documents, missing metadata, and obsolete policies can undermine the quality of agent responses.A smaller, carefully maintained knowledge base with current documents, useful metadata, tags, descriptions, and version management can produce significantly better results than simply indexing everything an organization owns.

HUMAN-IN-THE-LOOP AI
Autonomous does not have to mean uncontrolled.For low-risk transactions, organizations may allow an agent to complete an action automatically. Higher-value or sensitive decisions can introduce human approval.Manpreet discusses examples including financial claims, invoice processing, access requests, and infrastructure changes where humans remain part of the decision-making process while AI handles much of the repetitive work surrounding the decision.

GOVERNANCE BEFORE SCALE
As agents gain access to multiple enterprise applications, governance becomes critical.The conversation explores Microsoft Purview, Data Loss Prevention policies, security controls, sensitivity labels, Microsoft Defender, identity, environment strategies, and the importance of establishing an AI Center of Excellence before allowing agent development to expand throughout an organization.Governance should protect enterprise information without creating policies so restrictive that agent performance and usability suffer.

CONTROLLING AGENT SPRAWL
Organizations can quickly move from a handful of experimental agents to hundreds or thousands.Manpreet discusses agent lifecycle management, parent-child agent relationships, centralized inventories, ownership, connected data sources, permissions, consumption, and emerging management capabilities around Agent 365.The goal is to give administrators visibility into which agents exist, who owns them, what they can access, and how they are being used.

THE AI COMMAND CENTER
One of the most interesting concepts discussed in the episode is a unified AI Command Center.Instead of agent creation happening without oversight, organizations can establish a central process for requesting agents, connectors, APIs, MCP integrations, environments, and permissions.The command center can combine approval workflows, auditing, monitoring, governance, usage information, and cost controls—creating a central operational layer for enterprise AI.

OBSERVABILITY AND TROUBLESHOOTING
Traditional applications have logs. Enterprise AI needs observability.When an employee reports that an agent produced an unexpected result, administrators need to understand which knowledge sources were accessed, which tools were called, what actions occurred, and where the process failed.Copilot Studio's tracing and evaluation capabilities can help teams investigate these execution paths and understand how an agent arrived at an outcome.

TESTING NON-DETERMINISTIC AI
Testing AI agents requires a different mindset from testing traditional applications.Manpreet discusses evaluation features, generated test cases, structured datasets, indexing, user feedback, and repeated validation. Organizations should continuously test their agents against realistic questions and expected outcomes rather than deploying an agent once and assuming it will behave correctly forever.

MULTI-AGENT ARCHITECTURES
Instead of forcing employees to find the correct agent for every task, organizations can create an orchestration layer.A primary agent can understand the user's intent and delegate work to specialized agents for HR, travel, marketing, sales, IT, or other functions.The user interacts with one interface while multiple specialized agents operate behind it.

ADOPTION IS WHERE AI ROI HAPPENS
The final challenge is not technical.Organizations can build thousands of sophisticated agents and still fail to generate meaningful business value if employees do not understand when, why, and how to use them.Manpreet argues that adoption, persona-based training, practical use cases, and helping employees integrate agents into their daily work are essential to realizing ROI from Microsoft 365 Copilot and enterprise AI investments.

IN THIS EPISODE

• Microsoft Copilot Studio and enterprise AI agents
• Microsoft 365 Copilot vs. Copilot Studio vs. Azure AI Foundry
• Autonomous agents and action-oriented AI
• Enterprise knowledge grounding
• SharePoint as an AI knowledge source
• Data quality, metadata, and indexing
• Power Platform connectors and enterprise integrations
• Human-in-the-loop architectures
• Multi-agent systems and orchestration
• Microsoft Purview and DLP
• AI security and governance
• Agent lifecycle management
• Agent inventories and Agent 365
• AI Centers of Excellence
• Unified AI Command Centers
• AI observability and tracing
• Agent testing and evaluation
• Hallucination reduction
• AI consumption and cost management
• Enterprise AI adoption and ROI

KEY TAKEAWAY
The next phase of enterprise AI is not simply about adding better chatbots. It is about moving from answers to outcomes.AI agents can connect organizational knowledge, applications, workflows, and business processes—but the fundamentals of enterprise technology remain essential: identity, security, governance, data quality, architecture, testing, observability, cost control, and adoption.And ultimately, the technology only creates value when people actually use it.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Microsoft 365 Copilot has moved beyond the question of “What can generative AI do?” The harder challenge is now turning AI into something thousands of employees actually use, trust, and derive measurable business value from. In this episode of M365 FM, Mirko Peters talks with Microsoft MVP Christoffer Besler Hansen, Head of AI Workplace at Atea Group, about what it takes to move from a Copilot rollout to a genuine AI-powered workplace. Drawing on experience supporting AI adoption across more than 8,000 employees, Christoffer shares lessons on Microsoft 365 Copilot adoption, training, agents, Copilot Studio, Microsoft Foundry, governance, security, extensibility, FinOps, and measuring business value.

WHAT IS AN AI WORKPLACE?
An AI workplace is much broader than simply giving employees Microsoft 365 Copilot licenses. At Atea, the AI Workplace team is responsible for how more than 8,000 users incorporate AI into their daily work. Microsoft Copilot is a major component, but the strategy also includes Copilot Studio, agentic AI, Foundry, experimentation with other technologies, and—critically—continuous user adoption. The objective is not to deploy one AI product. It is to change how people work with information, applications, and business processes.

TECHNOLOGY MOVES FAST. PEOPLE NEED TIME.
New AI models and capabilities can appear every week. Human working habits don't change at the same speed. Christoffer explains why organizations need to spend substantial effort helping employees feel comfortable changing established workflows. At Atea, this includes training throughout the year, sometimes every other week, with sessions designed for different audiences such as managers, consultants, salespeople, beginners, and advanced users. AI adoption therefore isn't a launch event. It is an ongoing organizational capability.

BUYING 5,000 COPILOT LICENSES ISN'T A STRATEGY
What should happen after an organization purchases thousands of Microsoft 365 Copilot licenses? According to Christoffer, the organization first needs to determine why it purchased them. What is the objective? What should employees accomplish differently? How will the organization support adoption? How will success be measured? Simply assigning licenses and expecting employees to teach themselves isn't enough. Employees already have jobs to perform and cannot realistically follow every weekly change across rapidly evolving AI products.

WHY EARLY COPILOT ADOPTION OFTEN DROPS
AI naturally generates curiosity. When users initially received Copilot without structured adoption support, Christoffer observed strong engagement for approximately the first four weeks. Employees experimented with the technology. But when they struggled to turn those experiments into new working habits, usage declined. After structured training was introduced, users were more likely to continue using Copilot over time—and began asking for additional training as the products evolved. Initial excitement gets people through the door. Continuous education helps keep them there.

HOW DO YOU MEASURE COPILOT ROI?
One of the hardest enterprise AI questions is determining whether Copilot is actually creating value. Usage alone isn't enough. An employee opening Copilot 50 times doesn't necessarily mean the organization has become more productive. Christoffer argues that organizations need to identify what matters to their particular business and then measure whether AI improves those outcomes. That could include completing work faster, handling more customer cases, improving quality, or increasing business capacity.

MEASURE OUTPUT, NOT JUST AI USAGE
One example discussed in the episode involves an employee who previously handled two cases simultaneously but could use AI to work across six while still receiving better customer feedback. That represents something more meaningful than a Copilot usage statistic. The employee is producing more output while maintaining or improving quality. The right KPI therefore depends on what the organization actually produces. AI metrics should ultimately connect with business metrics.

COPILOT AS A THINKING PARTNER
Meetings were one of the earliest areas where Microsoft 365 Copilot delivered obvious value. Transcription, summaries, and meeting intelligence can reduce administrative effort. But Christoffer highlights another important pattern: using AI as a thinking partner. Instead of asking AI to do all the thinking, start with your own ideas. Speak or dictate those thoughts. Let Copilot structure them. Review the result. Give feedback. Iterate until you have something useful. This approach can save time while simultaneously improving the quality of emails, presentations, documents, and other knowledge work.

RESEARCH AGENT CHANGES KNOWLEDGE WORK
Christoffer highlights Microsoft's Research Agent as one of the particularly valuable additions to Copilot. For large projects involving significant amounts of information, an agent capable of working through numerous sources can dramatically reduce research effort. It can also help users find information they may previously have struggled to discover manually. Importantly, users can review the underlying sources and verify whether the resulting information is correct.

YOUR AI IS ONLY AS GOOD AS YOUR INFORMATION
Enterprise AI quickly exposes existing information-management problems. Organizations need to think about how information is structured across SharePoint, OneDrive, CRM systems, and other repositories. Microsoft Purview can play an important role in identifying and protecting confidential information. Retention policies also matter because outdated documents can lead AI toward outdated answers. Simply giving an agent access to more information doesn't automatically make it better. Sometimes the correct approach is to clean the data before connecting the agent.

WHEN SHOULD YOU BUILD AN AGENT? ㅤ Christoffer recommends encouraging employees to start thinking about potential agent use cases early. Initially, organizations may create many simple agents that primarily retrieve information. Some will provide little long-term value. But experimentation changes how employees think about automation. The next maturity step is building agents that don't merely answer questions but perform actions—sending messages, updating CRM systems, triggering processes, or interacting with other applications. Eventually, organizations can move toward more autonomous agents working alongside employees.

AGENT BUILDER VS COPILOT STUDIO
Not every employee needs to begin with Copilot Studio. Christoffer sees many non-technical employees using Agent Builder directly inside Copilot to create simpler agents. More technical users move toward Copilot Studio when they require additional capabilities. This can create a useful progression: Idea → Simple Agent → Validation → Copilot Studio → Advanced Enterprise Agent An employee can prove the concept without becoming a professional developer, then involve technical specialists when the solution needs to become more sophisticated.

FROM ANSWERS TO ACTIONS
An HR agent answering “How many vacation days do I have?” is useful. An agent that can actually book next Friday as vacation represents a fundamentally different capability. This transition from information retrieval toward actions changes the architecture and security requirements surrounding AI. Christoffer expects users to interact less directly with traditional application interfaces as agents increasingly perform tasks on their behalf. Instead of navigating several administrative screens, users may simply describe the desired outcome to an agent.

AGENT SECURITY BECOMES CRITICAL
Once agents can take actions, organizations need strong guardrails. What can the agent do automatically? What requires explicit approval? What can it delete? Which systems can it access? What permissions does it receive? Christoffer emphasizes least privilege and approval controls, particularly when agents interact with administrative environments. Giving an autonomous agent Global Administrator privileges and allowing it to operate without restrictions would create obvious risks. The more capable agents become, the more important their permission architecture becomes.

ENTERPRISE AGENTS NEED AN INTAKE PROCESS
A personal agent used by one employee is different from an agent deployed to thousands of users. Enterprise-wide agents need quality control. Organizations should review instructions, permissions, connectors, integrations, and data access before allowing large numbers of employees to use them. Christoffer suggests establishing an intake process where employee ideas can be evaluated. Some agents may be returned to their creators for improvement. Strategically important ideas can instead be developed by a dedicated internal agent team.

COPILOT EXTENSIBILITY AND AGENT 365
The conversation also explores Copilot extensibility and the Agent 365 SDK. Christoffer describes experimenting with personal agents that have their own identities in Microsoft Entra. Such an agent could appear within an organizational structure, have its own email and Teams presence, and receive carefully controlled permissions. His example involves building an agent that can act as a personal assistant and potentially answer appropriate questions when he is away from work. The important architectural shift is that the agent begins looking less like a chatbot and more like another identity participating in the organization.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

What happens when your cloud strategy cannot live entirely in the public cloud? Organizations are modernizing infrastructure with Azure, platform services, Infrastructure as Code, automated deployment pipelines, and Azure Landing Zones. At the same time, some workloads still need to remain close to factories, offices, regulated environments, existing infrastructure, or latency-sensitive systems. In this episode of M365 FM, Mirko Peters talks with Microsoft MVP Christoffer Klarskov Jakobsen about how Azure Local can become part of a broader Azure architecture rather than another isolated on-premises platform. They explore Azure Local, Azure Landing Zones, Azure Arc, governance, Infrastructure as Code, Bicep, Azure DevOps, modernization, and the realities of building hybrid cloud environments.

WHAT IS AZURE LOCAL?
Azure Local combines familiar infrastructure technologies with Azure-based management, governance, and security capabilities. At its core, organizations can run workloads such as virtual machines locally while connecting the environment back to Azure. Christoffer explains that the major difference compared with a traditional Windows Server environment is the Azure experience surrounding the infrastructure. Organizations can keep workloads and data locally while using Azure capabilities to manage and govern the environment.

IS AZURE LOCAL JUST AZURE IN YOUR DATA CENTER?
Not exactly. Azure provides a significantly larger catalog of cloud services, but Azure Local can bring selected Azure experiences closer to local infrastructure. Christoffer discusses running virtual machines and Kubernetes on Azure Local as well as scenarios involving SQL Managed Instance and Azure Virtual Desktop. The result isn't a complete copy of Azure running inside your building. It's a hybrid platform combining local compute requirements with selected Azure services and management capabilities.

WHEN DOES AZURE LOCAL MAKE SENSE?
Several scenarios stand out. Organizations may have regulatory requirements requiring data to remain locally. Others need extremely low latency between applications, machines, factories, or other infrastructure. Some organizations simply have workloads that cannot yet move completely into the public cloud. Christoffer also sees increasing potential around local AI workloads, including scenarios where organizations need AI capabilities while maintaining local control over their data.

AZURE LOCAL IS A LOCAL CLOUD
One of the important architectural lessons from the conversation is that Azure Local shouldn't be treated as simply another pair of servers. The environment includes multiple infrastructure and Azure-connected layers. Organizations therefore need people who understand the underlying hardware and operating technologies as well as Azure management. Christoffer describes Azure Local as effectively operating a local cloud rather than simply installing another traditional virtualization cluster.

WHY AZURE LANDING ZONES MATTER
Moving workloads into Azure doesn't automatically create a well-designed cloud environment. Organizations need structure, security boundaries, governance, permissions, networking, logging, and clear separation between workloads. Azure Landing Zones provide an architectural approach for establishing those foundations. Instead of placing unrelated applications, development environments, production systems, networking components, and shared services inside the same subscription, organizations establish clearer boundaries around workloads and responsibilities.

THINK DIFFERENTLY ABOUT AZURE SUBSCRIPTIONS
A subscription shouldn't simply become a container for everything an organization deploys. Christoffer recommends thinking about subscriptions as boundaries for specific environments and workloads. A development environment can have its own subscription. Testing can have another. Production can have another. Shared connectivity, logging, identity, and other platform services can be separated appropriately. This makes environments easier to secure, govern, understand, and eventually decommission.

MANAGEMENT GROUPS CREATE STRUCTURE
Management groups provide another layer for organizing Azure environments. They allow organizations to establish a hierarchy above subscriptions and apply governance at broader scopes. Policies and permissions can then be assigned at the management-group level rather than repeatedly configuring every individual subscription. Christoffer also discusses the local management group, which makes Azure Local increasingly relevant within the same Landing Zone architecture.

AZURE POLICY AS THE GUARDRAIL
Azure Policy plays a major role in this architecture. Policies can audit environments against organizational or regulatory requirements. They can identify non-compliant resources. They can deploy required configuration when something doesn't already exist. They can also deny configurations that organizations don't want users to create. Examples discussed include controlling Azure regions and preventing insecure storage configurations. Instead of relying entirely on documentation telling employees what they should do, organizations can encode many requirements directly into the platform.

DENTITY, RBAC AND ZERO TRUST
Landing Zones also provide a foundation for stronger access control. Christoffer emphasizes the principle of least privilege. Users and automated deployment identities should receive only the permissions required to perform their responsibilities. Application owners shouldn't automatically have access to connectivity infrastructure. Support personnel shouldn't automatically be able to modify logging systems. The objective is to establish clear security boundaries instead of making everybody an owner simply because that configuration is easier.

AZURE LOCAL MEETS AZURE LANDING ZONES
This is where the hybrid architecture becomes particularly interesting. Azure Local previously had limitations around how organizations could structure subscriptions and resources. Christoffer explains that newer capabilities make it possible to use multiple subscriptions and resource groups, enabling Azure Local to align much more closely with Landing Zone design principles. The Azure Local cluster itself can live within one subscription while different workloads use additional subscriptions. That enables organizations to apply clearer boundaries between the control plane and workloads.

TIER 0, TIER 1 AND TIER 2
The conversation goes deeper into separating workloads according to security requirements. For example, domain controllers can be treated as Tier 0 resources and placed into a dedicated subscription with particularly strict access controls. Member servers can occupy another tier. End-user workloads such as Azure Virtual Desktop can be separated again. This creates an architecture where local workloads don't simply exist inside one giant infrastructure bucket—they participate in a structured Azure governance model.

AZURE ARC CONNECTS THE TWO WORLDS
Azure Arc is one of the technologies making the traditional boundary between cloud and on-premises infrastructure increasingly less important. Arc can connect servers running outside Azure with Azure management capabilities. That can include Windows and supported Linux systems running locally, on virtualization platforms, or even with other infrastructure providers. Once connected, organizations can use Azure capabilities including Microsoft Defender for Cloud, Azure Policy, and Azure Update Manager across infrastructure that isn't physically running inside an Azure datacenter.

ONE MANAGEMENT PLANE FOR HYBRID INFRASTRUCTURE
Traditionally, organizations often accumulated separate products for monitoring, patching, security, configuration, and infrastructure management. Azure Arc changes that model. Instead of treating every location as an entirely separate environment, administrators can increasingly manage distributed infrastructure through Azure. The physical location of the workload still matters for latency, compliance, hardware, and availability—but it doesn't necessarily require an entirely separate management model.

INFRASTRUCTURE AS CODE FOR AZURE LOCAL
Infrastructure as Code isn't limited to Azure public cloud resources. Christoffer explains that Azure Local infrastructure and workloads can also be deployed using Infrastructure as Code. His principle is straightforward: If you're going to do something more than once, automate it. The initial investment may take additional time, but repeatable deployment becomes particularly valuable for environments requiring ongoing maintenance and consistent configuration.

WHY BICEP?
Christoffer primarily uses Bicep for Infrastructure as Code. Coming from a PowerShell background, he found the transition into Bicep relatively natural. Visual Studio Code and its supporting extensions also make the development experience easier by identifying syntax issues and helping developers understand available configuration. He doesn't argue that Bicep is universally better than Terraform—rather, Bicep fits naturally into the Microsoft-focused environments and workflows he works with.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Business Central handles finance, customers, sales orders, inventory, and invoices out of the box. But what happens when your company needs one additional field, a custom approval step, a new business rule, or functionality that doesn't exist in the standard application? In this episode of M365 FM, Mirko Peters explains Dynamics 365 Business Central AL Development—how developers use Microsoft's AL language and extensions to customize Business Central without directly modifying the standard application.
 
 WHAT IS BUSINESS CENTRAL AL DEVELOPMENT?
 AL stands for Application Language. It is Microsoft's programming language for developing functionality specifically for Dynamics 365 Business Central. AL allows developers to add and change business functionality involving records, pages, reports, calculations, validations, and processes. The important concept isn't only AL itself. It's the extension model. Instead of rewriting Microsoft's standard Business Central application, developers create separate extensions containing their custom functionality.

WHY BUSINESSES CUSTOMIZE BUSINESS CENTRAL
Business Central already covers many standard business processes. But no two organizations operate exactly the same way. A food distributor might require additional batch information. A service business could require another approval before invoicing. A retailer might need customer reward levels. Another organization could require specific fields, forms, or internal validation rules. These requirements don't necessarily justify changing an entire ERP process. Sometimes the business simply needs Business Central to understand one additional piece of information or enforce one additional rule.

WHY EXTENSIONS EXIST
Older development approaches frequently involved modifying the original application code. That could work until the underlying application was updated. Microsoft's new code and the organization's modifications then had to be compared and reconciled. Business Central extensions use a different model. The standard application remains in place while custom functionality sits beside it as a separate application. Updates still require testing, but developers don't need to recreate every customization inside Microsoft's original source code.

THINK OF BUSINESS CENTRAL AS AN OFFICE BUILDING
The episode uses an office-building analogy. Business Central is the building. Instead of knocking holes through the existing structure whenever somebody needs another room, the platform provides approved connection points for extending it. Microsoft maintains the main building. The organization maintains its additional functionality. This separation makes the resulting environment easier to understand and maintain over time.

STANDARD FIRST, CUSTOMIZE SECOND
Not everything should be customized. Changing Business Central simply because its standard process looks different from an organization's previous ERP can create unnecessary maintenance. Good customization begins with three questions: What problem are employees experiencing? What should happen instead? Can standard Business Central already solve it? AL development becomes relevant when the standard product genuinely doesn't meet the business requirement. 

WHAT CAN AL DO?
AL can work with Business Central data and application behavior. Developers can use it to add or change records, calculate values, control pages, create reports, validate information, display messages, and automate business rules. But AL isn't intended as a general-purpose language for building every kind of software. You wouldn't normally choose AL for a public shopping website, mobile game, or standalone desktop application. Its focused job is extending Dynamics 365 Business Central.

WHAT IS A BUSINESS CENTRAL EXTENSION?
An extension is a separate application Business Central can install. It contains the organization's custom functionality while Microsoft's standard Business Central application remains separate. An extension can be extremely small. It might add one additional field to the customer record. Another extension could contain an entire industry-specific solution with its own data, processes, pages, reports, and business rules. Both follow the same fundamental extension architecture.

AL VS THE OLDER C/AL MODEL
The episode also discusses C/AL, associated with older Dynamics NAV development. In that development model, developers frequently modified original application objects directly. Many organizations successfully operated systems this way, but customizations became closely tied to the standard application. AL moved Business Central toward an app-based extension model, separating custom functionality from Microsoft's standard application.

MULTIPLE EXTENSIONS
Business Central can contain more than one extension. An organization might have an extension from a software partner handling payroll, another extension providing shipping functionality, and an internally developed extension implementing company-specific rules. Business Central brings those applications together as long as they follow the platform's rules and don't conflict. This modular approach allows organizations to assemble the functionality their particular business requires.

THE MAIN AL BUILDING BLOCKS
Inside an AL extension, developers work with objects. An object is a named piece of the application responsible for a particular job. The episode introduces several important AL object types: Tables → Store information Pages → Present information to users Table Extensions → Add information to existing tables Page Extensions → Add functionality to existing pages Codeunits → Contain reusable business logic Reports → Present information in documents or layouts Queries → Retrieve focused information XMLports → Exchange structured information

TABLES
Tables store information in Business Central. Think of a table as a digital filing cabinet. A customer table contains customer records. An item table contains products. Sales-related tables contain information associated with sales transactions. If an organization needs information that doesn't belong in an existing standard table, an extension can create its own table. Examples from the episode include reward levels, equipment inspections, and project approvals.

FIELDS
Fields are the individual pieces of information stored inside records. A customer can have a name, address, payment term, telephone number, and other details. Custom fields could contain information such as a reward ID, delivery instruction, internal risk score, membership level, or link to another system. Fields can contain different types of information including text, dates, amounts, yes/no values, and predefined choices.

PAGES
Pages are the screens users interact with inside Business Central. A customer card is a page. A list of sales orders is another page. Different page types support different activities. A Card Page focuses on one record. A List Page displays multiple records. A Worksheet Page supports scenarios where employees need to enter or process several lines of information together. Tables store the information while pages determine how employees interact with it.

TABLE EXTENSIONS
Suppose Business Central's standard customer table already contains almost everything the organization requires, but the business needs one additional Reward ID. Creating another customer table would unnecessarily duplicate the existing customer information. Instead, a developer creates a Table Extension. The standard customer table remains intact while the extension adds the additional company-specific field.

PAGE EXTENSIONS
Adding a field to the underlying table doesn't automatically display it to employees. A Page Extension adds the field to an existing Business Central page. The Reward ID could therefore appear directly on the standard Customer Card. Page Extensions can also add groups, actions, buttons, or menu commands. Employees continue working on the familiar Business Central page while the extension adds the functionality required by the organization.

CODEUNITS
Codeunits provide a home for business logic. Suppose the selected customer reward level determines the discount percentage. Instead of putting the discount calculation directly into the Customer Card page, the calculation can live inside a Codeunit. Other pages, reports, and business processes can then call the same procedure. This avoids maintaining several different versions of the same business rule. ㅤ TRIGGERS ㅤ A trigger is a defined location inside an AL object where code can execute when something happens. For example, code can run when a field value changes or when a page opens or closes. Suppose somebody selects a Reward ID for a customer. A validation trigger could check whether the reward level exists, whether the customer is blocked, or whether another value should be updated. The rule executes when the relevant action occurs.

EVENTS
Events allow extensions to react to processes occurring inside Business Central without copying those complete processes. Think of an event as a notification from the standard application. Business Central might announce that a record is about to be inserted, a document is about to be posted, or another process has completed. An extension can listen for the event and execute its own functionality at the appropriate point.tes

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

A salesperson updates a customer address in Dynamics 365 Sales. Later, someone in finance opens the same customer and still sees the old address. Which one is correct? When sales, service, finance, and operations work in different applications, shared business data can quickly become duplicated or inconsistent. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Dual-write connects Finance and Operations apps with Microsoft Dataverse so supported records such as customers, addresses, contacts, products, and orders can remain synchronized as teams work.

WHAT IS DYNAMICS 365 DUAL-WRITE?
Dual-write is Microsoft's built-in connection between Dynamics 365 Finance and Operations apps and Microsoft Dataverse. Think of an organization as having a front office and a back office. The front office includes salespeople, service agents, field workers, and other customer-facing teams. The back office handles finance, inventory, purchasing, orders, fulfillment, and other operational processes. Both sides work with many of the same customers and products, but they need different applications for their jobs. Dual-write creates a controlled connection between those environments so selected shared records can remain synchronized without employees manually copying information between applications.

THE BUSINESS PROBLEM DUAL-WRITE SOLVES
Without integration, one customer can quietly become two different records. Sales might have Northwind Bikes with the customer's new address. Finance might have Northwind Bicycle Company with the previous address. Both records can look correct when viewed independently, but they no longer describe exactly the same business relationship. Employees then become the integration layer. They export spreadsheets, send emails, compare records, re-enter information, and investigate which version is correct. Dual-write is designed to reduce that manual handoff.

FRONT OFFICE AND BACK OFFICE
Dynamics 365 applications support different types of work. Dynamics 365 Sales focuses on leads, opportunities, customer relationships, and sales conversations. Customer Service manages customer questions and cases. Field Service supports technicians and work performed at customer locations. Finance and Supply Chain Management handle areas such as accounting, inventory, products, purchasing, orders, and fulfillment. The objective isn't to force every employee into one giant application. Instead, employees continue using the application appropriate for their role while selected business information remains connected behind the scenes.

MICROSOFT DATAVERSE
Dataverse is the shared data foundation behind many Microsoft business applications. Dynamics 365 Sales, Customer Service, Field Service, parts of Project Operations, Power Apps, and Power Automate can work with Dataverse. For understanding Dual-write, think of Dataverse as the common data area on the customer-application side. Finance and Operations remains the operational foundation on the other side. Dual-write connects selected records between these environments.

THINK OF DUAL-WRITE AS AN INTERNAL DOOR
Imagine an office building with customer-facing teams on one side and finance and operations on the other. Without integration, somebody has to carry information between them. They might send an email, move a spreadsheet, or manually enter the information again. Dual-write acts like a staffed internal door. When a supported record changes on one side, Dual-write can pass the related change through that door according to predefined rules. Each team keeps its own workspace while shared information remains connected.

WHAT ARE TABLE MAPS?
Dual-write doesn't blindly synchronize every piece of information. It works through defined connections called table maps. A table stores a particular type of record. A customer table contains customer records. A product table contains products. An address table contains address information. A table map tells Dual-write which table in Finance and Operations corresponds with which table in Dataverse. It also defines how relevant fields relate to each other. Think of the table map as the translation sheet between the two systems.

TWO-WAY SYNCHRONIZATION
The word dual reflects the ability of supported maps to synchronize changes in both directions. A supported update in Dataverse can update the corresponding record in Finance and Operations. A supported update in Finance and Operations can also update the related Dataverse record. However, this doesn't mean every table or every field should automatically move in both directions. Organizations still need clear rules about which system owns particular information.

NEAR REAL-TIME DATA
Dual-write is designed for business information employees need while they're actively working. Instead of waiting for an overnight synchronization job, supported changes can move between the environments in near real time. Near real time doesn't mean absolutely zero delay. It means the connection supports live operational processes rather than relying primarily on scheduled file exchanges. A salesperson shouldn't need to wait until tomorrow morning before finance sees an important customer update.

WHAT DATA CAN DUAL-WRITE CONNECT?
Common examples include customers, addresses, contacts, products, vendors, company information, organizational structures, and finance or tax reference information. The exact records depend on the Dynamics 365 applications and business processes an organization uses. The important principle is not to synchronize everything possible. Synchronize information that genuinely needs to represent the same business record across both environments. ㅤ 

CUSTOMER RECORDS 
Customers are one of the clearest examples. Sales needs information such as customer names, contacts, phone numbers, and delivery information. Finance needs the legal customer record, billing information, and the details required for orders and invoices. Dual-write can keep supported customer information connected while allowing each team to continue working inside the Dynamics 365 application designed for its responsibilities.

ADDRESSES AND CONTACTS
Customer information is more complicated than one company name. A customer can have a billing address, shipping address, and service location. The organization might also work with buyers, Accounts Payable contacts, service managers, and other people within the same customer organization. Connected address and contact structures help sales, service, finance, and operations work with related information without independently rebuilding those relationships in every application.

PRODUCT INFORMATION
Products provide an example where ownership frequently becomes important. Finance and Operations often owns product creation because operations controls product master information, stock units, and other details required to sell and deliver products. Once the product is prepared for customer-facing work, Dual-write can send related product information into Dataverse. Sales users can then work with those products without somebody manually recreating the product catalog in another application.

ONE-WAY VS TWO-WAY MAPS
Not every business record needs two-way synchronization. Some maps support changes in both directions because both sides have a legitimate reason to maintain information. Other records have a clearer owner. Products provide a useful example: operations might create and govern the product while sales simply receives and uses that information. The correct synchronization direction should follow the organization's actual data ownership model.

DATA OWNERSHIP MATTERS
Before synchronizing information, organizations need to answer: Where does this record begin? Who can change it? Which system wins when information conflicts? Who corrects an incorrect value? For example, sales might own relationship and contact information while finance owns payment-related information and operations owns products and inventory. The exact ownership model depends on the business. What matters is that the ownership is clearly defined before automation begins moving changes between applications.

HOW A CHANGE TRAVELS
Imagine a salesperson speaking with a customer who recently moved. The salesperson updates the customer's street address in Dynamics 365 Sales and saves the record. Sales stores that change in Dataverse. Dual-write checks the relevant table map and identifies the corresponding customer and address information in Finance and Operations. The supported update travels across automatically. When finance later opens the customer record, the updated address is available without somebody manually entering it again.

SYNCHRONOUS BUSINESS PROCESSES
For normal day-to-day operations, the connection is designed to process related updates as part of the current working process instead of placing everything into a background synchronization job that might execute much later. This matters because employees make decisions based on what they see now. Customer addresses, product details, and other shared information shouldn't quietly drift apart for hours before somebody discovers the difference. When synchronization fails, that failure needs attention rather than remaining hidden until another team discovers inconsistent data.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

A supplier invoice arrives. The goods may already be sitting in your warehouse or the service may already be complete—but what actually needs to happen before money leaves the company? Dynamics 365 Accounts Payable connects vendor records, invoices, purchase orders, receiving, invoice matching, approvals, payment runs, bank accounts, and settlement into one controlled financial process. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Finance manages the complete journey from receiving a vendor bill to recording the final payment.

WHAT IS DYNAMICS 365 ACCOUNTS PAYABLE?
Accounts Payable tracks money your company owes vendors for goods and services it has already purchased. Think of it as the payment office inside a large company. Bills arrive, somebody verifies them, the appropriate people approve them, finance determines when they should be paid, and finally the payment is sent to the supplier. Dynamics 365 keeps these individual activities connected so finance can follow the complete history of each vendor invoice.

WHY ACCOUNTS PAYABLE MATTERS
Most businesses don't pay suppliers immediately when they place an order. A supplier delivers goods or completes a service and then sends an invoice. The company now owes that amount, but the money hasn't left the bank account yet. That unpaid amount becomes a liability. A business can therefore have significant cash in its bank account while simultaneously owing substantial amounts to suppliers. Accounts Payable gives finance visibility into both what has already been paid and what will need to be paid in the future.

ACCOUNTS PAYABLE VS ACCOUNTS RECEIVABLE
The names sound similar, but they represent opposite sides of company cash flow. Accounts Payable = Money your company owes vendors. Accounts Receivable = Money customers owe your company. If your company buys printers from a supplier, the supplier invoice belongs in Accounts Payable. If your company sells desks to a customer and sends them an invoice, that customer invoice belongs in Accounts Receivable. One tracks money leaving the business. The other tracks money expected to enter it.

THE GOAL OF ACCOUNTS PAYABLE
The objective is straightforward: Pay the right vendor, the right amount, on the agreed date. Paying too early reduces available cash sooner than necessary. Paying too late can create supplier problems, reminders, disputes, or less favorable payment terms. Paying the wrong amount creates additional administrative work. Dynamics 365 provides the records and controls finance teams need to manage these decisions consistently.

THE VENDOR RECORD
Before Dynamics 365 can process an invoice, it needs to know who should receive the money. The vendor record acts as the supplier's file inside Dynamics 365. It can contain the vendor's name, address, contact information, currency, payment terms, payment method, and other financial settings. These settings don't simply describe the supplier. They influence what happens later when invoices and payments are processed.

PAYMENT TERMS
Payment terms determine when an invoice becomes due. One supplier might require payment within 14 days. Another might allow 30 days. Some vendors may offer discounts for early payment. Dynamics 365 uses the configured payment terms to calculate invoice due dates. That means employees processing invoices for the same vendor don't need to remember individual agreements or search old emails to determine when payment is required.

PAYMENT METHODS
Payment terms answer when the supplier should be paid. Payment methods answer how the money should reach them. Depending on the organization's processes, vendor payments can use methods such as electronic payments, cheques, or promissory notes. Dynamics 365 allows organizations to configure payment methods according to the financial processes they actually use.

VENDOR GROUPS
Large organizations can have hundreds or thousands of vendors. Creating every financial setting independently for every supplier would create unnecessary work and increase the risk of inconsistent configuration. Vendor groups allow organizations to group suppliers sharing common finance rules. The individual vendor still maintains its own identity and transaction history, while the group provides a common starting point for shared financial configuration.

VENDOR POSTING PROFILES
Posting profiles tell Dynamics 365 where vendor transactions belong in the General Ledger. When an invoice is posted, Dynamics 365 needs to record what the organization owes while also connecting the transaction with the appropriate financial accounts. The posting profile provides the accounting map behind this process. Finance employees therefore don't need to manually determine the relevant vendor ledger account every time they process an invoice.

HOW VENDOR INVOICES ENTER DYNAMICS 365
Invoices can enter the Accounts Payable process in several ways. A finance employee can manually enter information from an invoice received through email, paper, or another channel. The invoice record can contain the vendor, invoice number, invoice date, currency, amounts, lines, tax information, purchase order references, and supporting documents. For higher invoice volumes, invoice information can also enter electronically through data entities and connected invoice-processing solutions.

INVOICE NUMBERS AND DUPLICATE DETECTION
The vendor's invoice number is particularly important. Suppose Northwind Office Supplies sends invoice NWO148. If the same invoice enters the system again, Dynamics 365 can use the combination of vendor and invoice number to identify a potential duplicate. This matters because suppliers sometimes resend invoices when they aren't sure the first copy arrived. Employees can also accidentally process the same document twice. Duplicate detection helps prevent the same bill from being paid twice.

INVOICE ATTACHMENTS
Supporting documents can remain connected with the transaction. A PDF invoice, scanned document, or other supporting paperwork can be attached to the invoice record. The finance employee reviewing the transaction can therefore compare the information entered into Dynamics 365 with the original document without searching through shared mailboxes or filing cabinets. This also creates a clearer record when somebody needs to review the transaction later.

AUTOMATED INVOICE IMPORT
Organizations processing large numbers of invoices don't necessarily need employees to manually type every invoice. External invoice capture systems can send invoice information into Dynamics 365 using data entities. The invoice header contains information such as the vendor, invoice number, dates, currency, total amount, and purchase order reference. Invoice lines explain exactly what the supplier is charging for. Supporting documents can travel alongside the structured invoice information.

VENDOR INVOICE POLICIES
Before an invoice proceeds, Dynamics 365 can check whether it follows the organization's configured rules. Missing vendors, invalid dates, duplicate invoice numbers, incorrect totals, or imported data problems can prevent an invoice from proceeding normally. The objective isn't to automate every decision. Automation handles routine checks while finance employees investigate exceptions requiring human judgment.

INVOICE APPROVAL WORKFLOWS
Workflow determines who needs to approve an invoice. Instead of emailing a PDF to a manager and waiting for somebody to respond, Dynamics 365 can route the invoice according to predefined organizational rules. A small invoice might require a simple approval. A large invoice might require a senior manager. An invoice associated with a particular department can be routed toward the manager responsible for that department. The approval route follows configured rules instead of relying on somebody remembering who should receive the invoice. 

AUTOMATION AND EXCEPTIONS
Invoices that satisfy established rules can move through routine parts of the process more efficiently. Invoices containing problems become exceptions. Perhaps the vendor is missing, an invoice number already exists, or imported information contains an error. Finance employees can investigate those exceptions rather than spending the same amount of time manually checking every invoice. The system handles repetition. People handle situations requiring judgment.

INVOICE MATCHING
Approval answers: Has the appropriate person approved this invoice? Invoice matching answers another question: Does the supplier's invoice agree with what the company actually ordered and received? When a purchase originates from a purchase order, Dynamics 365 already has information describing the agreed vendor, products, quantities, prices, and terms. That gives finance something concrete against which the vendor invoice can be checked.

PURCHASE ORDERS
A purchase order records what the organization agreed to purchase before the invoice arrives. Suppose the company orders ten office chairs at an agreed price. The purchase order establishes that agreement. When the supplier invoice eventually arrives, finance can compare the bill against the original purchase order instead of reviewing the invoice without any purchasing context.

PRODUCT RECEIPTS
For physical goods, another important record exists: the product receipt. When goods arrive, warehouse employees record what was actually received. If ten chairs were ordered but only eight arrive because two are backordered, the product receipt can record those eight units. Dynamics 365 now has three important pieces of information: What was ordered. What actually arrived. What the supplier wants the company to pay.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

What happens when your sales team works in Dynamics 365, but inventory lives in a warehouse system, invoices live in finance, and product information lives in an ERP? You could copy all that information into Dataverse, but then you create duplicate records, synchronization jobs, delays, and another place where information can become outdated. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Virtual Tables, formerly known as Virtual Entities, provide live access to external business data without requiring Dynamics 365 to store another copy.

WHAT ARE DYNAMICS 365 VIRTUAL TABLES?
A Virtual Table is a table definition inside Microsoft Dataverse that points to records stored somewhere else. Dataverse understands what the information looks like—such as product name, available quantity, price, or invoice status—but the actual records remain in the external system. Think of it as a window into another business system. Dynamics 365 provides the familiar interface while the external application remains responsible for storing and managing the data.

VIRTUAL ENTITIES VS VIRTUAL TABLES
You may still encounter the term Virtual Entities in older documentation, implementations, and conversations. The current terminology is Virtual Tables. The underlying concept remains the same: Dynamics 365 and Dataverse can expose external information as though users were working with another Dataverse table, while the records themselves remain outside Dataverse.

WHY COPYING DATA CREATES PROBLEMS
Imagine your warehouse has ten units available when an overnight synchronization runs. The following morning, Dynamics 365 shows ten. At lunchtime, the warehouse ships all ten units. The warehouse system immediately knows inventory has reached zero, but Dynamics 365 could continue displaying ten until the next synchronization occurs. Your salesperson is now making decisions using outdated information. The problem isn't necessarily that synchronization failed. The problem is that the copied information became outdated between synchronization runs.

THE DUPLICATE RECORD PROBLEM
Copying information also creates another question: Which system owns the truth? The product exists in the ERP system, but another copy exists in Dataverse. Someone changes the description, price, status, or availability. Now somebody needs to determine which version should win. Virtual Tables avoid this problem by allowing the original business system to continue owning the record while Dynamics 365 users access that information when required.

THINK OF TWO FILING CABINETS
Imagine keeping identical documents in two filing cabinets. One cabinet belongs to sales and another belongs to the warehouse. Whenever somebody changes a document in one cabinet, they need to carry the updated copy to the other. Miss one update and the cabinets disagree. Traditional synchronization follows a similar pattern. Virtual Tables provide another approach: instead of maintaining the second copy, give the sales team a secure way to see information from the original cabinet.

ONE PLACE TO WORK DOESN'T REQUIRE ONE DATABASE
Organizations frequently say they want "one system." What employees often actually need is one place to work. A salesperson shouldn't need to open Dynamics 365, switch to the ERP to check inventory, open another application to check an invoice, and then return to the customer record. Virtual Tables can bring selected external information into the Dynamics 365 experience while allowing specialized systems to continue managing their respective business processes.

A LIVE WINDOW INTO EXTERNAL DATA
Suppose an account manager is discussing a large opportunity with a customer. The customer wants 500 units next month. While remaining inside Dynamics 365, the account manager opens related product availability information showing the item number, warehouse, available quantity, and expected replenishment date. That information can come directly from the external warehouse or ERP system rather than yesterday's imported inventory list. Dynamics 365 becomes the workspace while the warehouse system remains the inventory authority.

NORMAL DATAVERSE TABLE VS VIRTUAL TABLE
With a normal Dataverse table, the records are stored inside Dataverse. Accounts, contacts, opportunities, and cases are common examples. With a Virtual Table, Dataverse defines how the external information should appear and how to retrieve it, but the actual records remain somewhere else. The difference can be summarized as: Standard Table → Dataverse stores the record Virtual Table → Dataverse accesses the record from another system

THINK OF A LIBRARY CATALOG
A library catalog contains information describing a book. It tells you the title, author, and where to find it. But the catalog isn't the book. A Virtual Table works similarly. Dataverse understands the structure and knows how to request the record, but the external system contains the actual business data.

RUNTIME DATA ACCESS
Virtual Tables retrieve information when the application needs it. A user might open a view, search for particular records, apply a filter, or select an individual row. Dataverse then requests the relevant information from the external system. The objective isn't to fetch every external record and permanently store it. Instead, the application requests the information required for the current interaction.

THE THREE BUILDING BLOCKS
The episode explains three important components behind a Virtual Table: Data Provider → translates requests Data Source → identifies and connects to the external service Virtual Table → maps external information into a Dataverse table structure Together, these components allow Dynamics 365 to request external records and present them through a familiar user experience.

WHAT IS A DATA PROVIDER?
The Data Provider acts as a translator. Dynamics 365 and Dataverse send requests using their own concepts—tables, columns, filters, and record IDs. The external system might use another API or data format. The provider translates between those two sides. Users don't need to understand that conversation. They interact with the resulting records through the Dynamics 365 application.

WHAT IS A DATA SOURCE?
If the provider knows how to communicate, the Data Source identifies where to communicate. The Data Source contains connection information for the external service. This can include the service address, authentication information, and connection-related settings. Think of the Data Provider as knowing the language and the Data Source as containing the address and connection details required to reach the correct system.

ODATA V4
Dataverse includes support for an OData Version 4 provider. OData provides a standardized approach for exposing and requesting data over the web. An external service might expose products containing fields such as product number, description, unit price, and available quantity. The provider can request those records and return them in a structure Dataverse understands. This provides a common integration approach when the external application already supports OData V4.

CUSTOM DATA PROVIDERS
Not every external business application supports OData. Organizations can use custom Data Providers when another integration method is required. A developer might create a provider connecting Dataverse with a REST API, database, or proprietary company service. The custom provider still performs the same fundamental job: Receive the Dataverse request → communicate with the external system → translate the response → return records to Dataverse.

MAPPING EXTERNAL COLUMNS
The Virtual Table defines how external fields should appear inside Dataverse. The warehouse application might call a field Available Quantity, while Dynamics 365 users see Stock on Hand. The mapping tells Dataverse that these fields represent the same information. This allows organizations to provide user-friendly terminology inside Dynamics 365 without requiring the external system to rename its own fields.

UNIQUE RECORD IDS
Dataverse needs to distinguish one external record from another. Virtual Table records therefore require dependable unique identifiers that Dataverse can recognize. Without a reliable ID, Dataverse can't confidently determine which exact product, invoice, customer, or other external record the user selected. Record identity is therefore an important technical requirement when evaluating whether an external data source can work effectively through Virtual Tables.

FOLLOWING A VIRTUAL TABLE REQUEST
Imagine a salesperson opens a product list and filters for available items. Dataverse recognizes that the request targets a Virtual Table. The Data Provider receives the request. The Data Source provides the information required to contact the external service. The provider translates the filter into something the external service understands. The source system returns matching records. The provider converts those results into Dataverse rows. Dynamics 365 displays them in the familiar interface. The user sees a normal-looking product list while the data remains in the external system.

WHERE VIRTUAL TABLES FIT BEST
Virtual Tables work particularly well when another system clearly owns the information but Dynamics 365 users need that information during their normal work. Examples include live inventory, product information, purchase status, invoice status, finance information, supplier catalogs, and selected marketing information. The external application remains responsible for managing the lifecycle of the record. Dynamics 365 provides contextual access to that record alongside the customer's sales or service information.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

What happens when sales, purchasing, warehouse teams, and your online store all have different information about the same product? A supplier changes a specification, one spreadsheet gets updated, another system doesn't, and suddenly customers receive outdated information or employees order the wrong item. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Product Information Management (PIM) creates a shared product definition across the business and manages products, product masters, variants, dimensions, configurations, categories, attributes, legal entities, and integrations.

WHAT IS DYNAMICS 365 PRODUCT INFORMATION MANAGEMENT?
Dynamics 365 Product Information Management provides a central place for defining and maintaining product information. Purchasing needs supplier information and units. Warehouse teams need accurate information for receiving, storing, and picking. Sales needs understandable product names. Finance needs the correct product setup, while commerce channels need descriptions, images, and specifications. Without a shared product definition, each department can create its own version of the same information. PIM provides the common product record those different business processes can use.

ONE PRODUCT RECORD ACROSS THE BUSINESS
Consider an insulated water bottle originally sold as a 500-milliliter product. The supplier changes it to 750 milliliters. Purchasing receives the new specification, but the online store still shows 500 milliliters. Sales sends customers an outdated specification sheet, while warehouse employees see labels that don't match their orders. Nobody intentionally created incorrect information. The problem is that different departments were working from different copies. Product Information Management creates one central product definition where agreed product information can be maintained and reused.

WHAT INFORMATION DOES A PRODUCT RECORD CONTAIN?
The product number provides a consistent identifier even when different teams use different terminology. The record can also contain names, descriptions, units, images, attachments, categories, attributes, and translations. Units are particularly important because organizations might buy, sell, store, or count products as pieces, boxes, kilograms, liters, or pallets. Attachments can provide supplier documents or specifications, while images help employees and customers recognize products. Translations allow the same underlying product to have appropriate names and descriptions for different languages and markets.

SIMPLE PRODUCTS VS PRODUCT MASTERS
Dynamics 365 distinguishes between a simple product and a product master. A simple product represents one fixed item without choices that create separate variants. A product master represents an entire family of related products. A pair of jeans provides a useful example. Customers might consider it one product, but a warehouse needs to distinguish blue medium jeans from black large jeans. The product master contains the shared information for the jeans range. Individual variants represent the exact products employees purchase, stock, sell, and ship.

PRODUCT VARIANTS EXPLAINED
A variant is a specific sellable or manageable version of a product master. Blue medium jeans can represent one variant. Black large jeans can represent another. Although both belong to the same product family, they're not interchangeable. Each variant can have different inventory availability, labels, barcodes, and operational requirements. The product master therefore acts as the parent definition while variants represent the individual members of that family.

PRODUCT DIMENSIONS
Dynamics 365 Supply Chain Management includes five product dimensions discussed in the episode: Color, Size, Style, Configuration, and Version. Color and size are straightforward examples for clothing. Style can distinguish variations such as regular fit and slim fit. Configuration can identify a particular build or setup, such as different equipment specifications. Version can distinguish engineering changes to a product over time. Organizations choose the dimensions appropriate for each product family rather than applying every dimension to every product.

PRODUCT DIMENSIONS VS PHYSICAL DIMENSIONS
Product dimensions shouldn't be confused with physical dimensions. Weight, height, width, length, and volume describe the physical characteristics of a product. They don't necessarily create another sellable variant. Product dimensions identify which specific variant somebody wants. Physical dimensions describe what that product is physically like. For warehouse operations, physical dimensions can help determine how much space something requires. For a customer ordering black jeans in size large, product dimensions identify the correct variant.

THREE WAYS TO CONFIGURE PRODUCT VARIANTS
Dynamics 365 Supply Chain Management supports three approaches covered in the episode: Predefined variants, dimension-based configuration, and constraint-based configuration. The appropriate method depends on whether the organization already knows every valid product combination or whether the final product is configured according to customer choices and business rules. Choosing the appropriate configuration model early is important because it shapes how the product family is managed afterward.

PREDEFINED VARIANTS
Predefined variants work well when the organization already knows which combinations it will sell. A retailer might sell jeans in several colors and sizes but not offer every mathematically possible combination. Instead of generating unnecessary variants, the business creates only the combinations that actually exist. This keeps the catalog cleaner and prevents somebody from ordering a combination the organization doesn't sell.

DIMENSION-BASED CONFIGURATION
Dimension-based configuration can be useful in manufacturing. Imagine a company producing industrial pumps where different configurations require different components. The organization can use a shared Bill of Materials while associating particular components with specific configurations. A pump requiring one voltage might need one motor, while another configuration requires a different motor. The configuration determines which relevant component lines should be used for the resulting product.

CONSTRAINT-BASED CONFIGURATION
Constraint-based configuration becomes useful when customers can select many options but not every combination is technically possible. A custom machine might provide choices for its housing, motor, voltage, safety equipment, and control panel. Some combinations work together. Others don't. A product configuration model defines available choices and the rules controlling them. The system can therefore prevent an impossible product configuration before the order reaches manufacturing.

CHOOSING THE RIGHT CONFIGURATION MODEL ㅤ The key question is: Does the business know every valid product combination before an order arrives, or does the customer create a valid product through a controlled set of choices? A retailer with a fixed clothing range probably doesn't require a sophisticated configurable-product model. A manufacturer producing made-to-order equipment might. The product configuration approach should follow the real purchasing, sales, and production process rather than simply choosing the most flexible technology available.

PRODUCT CATEGORIES
Categories provide structure around product information. Think of them like aisles inside a well-organized store. A company might organize products into clothing, tools, office supplies, or more specialized categories. One product can also participate in multiple categories when those categories serve different business requirements. Categories make products easier to find, organize, and manage while providing structure for related product information.

PRODUCT ATTRIBUTES
Attributes provide additional details describing a product. For a water bottle, attributes might include material, capacity, lid type, insulation, brand, and care instructions. For industrial equipment, attributes might describe physical dimensions, power requirements, temperature ranges, or technical standards. Categories can carry attributes appropriate for the products they contain. This gives organizations a structured way to capture useful product information rather than inventing unrelated fields for individual products.

IMAGES, ATTACHMENTS AND TRANSLATIONS
Product information isn't limited to structured fields. Images can help warehouse employees, salespeople, and customers recognize an item. Attachments can contain supplier documentation, specifications, and other supporting information. Translations allow product names and descriptions to be presented appropriately across different languages while retaining the same underlying product definition. Together, these capabilities make the product record a richer source of information than a simple item number and description.

CONTROLLING ACCESS TO PRODUCT DATA
Not every employee should be allowed to modify every product record. Changes to product names, specifications, categories, or other information can affect multiple downstream teams and systems. Dynamics 365 can apply product-data access rules at category or individual-product level. Different teams can therefore manage the product areas for which they're responsible while sensitive or restricted products can receive tighter controls.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

A customer wants 100 bicycles next month. You already have some finished bicycles in stock, wheels are arriving from a supplier, frames are stored somewhere else, and your production line is booked for the next two weeks. What should you buy, what should you build, what should you move—and when does each action need to happen? In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Master Planning connects customer demand, inventory, purchasing, production, bills of materials, lead times, capacity, forecasts, and planned orders to create one connected supply plan.

WHAT IS DYNAMICS 365 MASTER PLANNING?
Dynamics 365 Master Planning is the part of Supply Chain Management that determines how future demand should be covered. Think of your business as an office building with a stockroom attached. Customer orders enter through one door. Inventory sits on shelves. Suppliers deliver materials. Production converts components into finished products. Master Planning looks across all of these activities instead of allowing each team to maintain its own disconnected plan. It combines current demand and available or expected supply, identifies shortages, and suggests actions for planners to review.

WHY A STOCK COUNT ISN'T ENOUGH
Imagine a customer orders 100 bicycles and your warehouse currently contains 30. You still need 70. But those 70 bicycles require frames, wheels, chains, seats, bolts, packaging, employees, machines, and enough production time. A simple inventory report tells you what exists now. It doesn't tell you whether the missing components can arrive before production needs them or whether the factory has enough time to complete the order. Master Planning connects quantity with time.

FROM SPREADSHEETS TO CONNECTED PLANNING
Without connected planning, sales might maintain customer orders in one system while warehouse employees check inventory somewhere else. Purchasing tracks supplier dates in spreadsheets and emails. Production maintains another schedule describing what the factory can build. Each individual list might be correct, but somebody still needs to connect everything to answer one question: Can we deliver what the customer ordered by the promised date? Dynamics 365 Master Planning brings these demand and supply signals together.

MASTER PLANNING VS A SPREADSHEET
Think of a spreadsheet as a photograph. It can provide a useful snapshot of inventory at a particular moment. Master Planning is closer to a forward-looking schedule. It considers quantities alongside dates, future demand, incoming supply, production requirements, and existing inventory. When one of those elements changes, the planning picture can change as well.

THE THREE PLANNING MODES
Dynamics 365 doesn't provide only one way to plan. The episode explains three different planning scenarios: Master Planning focuses on day-to-day and shorter-term requirements. Forecast Planning looks at expected future demand. Intercompany Master Planning connects demand and supply requirements between legal entities. Each starts with demand but answers a different planning question.

MASTER PLANNING AND NET REQUIREMENTS
Master Planning calculates net requirements. The basic concept is straightforward: Demand – Available or Expected Supply = Remaining Requirement Suppose a customer orders 100 units and the warehouse has 30 available. The remaining requirement is 70. If another 20 units are already scheduled to arrive from a supplier before the customer's required date, the uncovered requirement becomes smaller again. Dynamics 365 therefore doesn't simply suggest purchasing or producing the complete customer quantity. It considers supply that already exists or is expected to arrive.

WHY DATES CHANGE THE ANSWER
Having enough inventory eventually isn't the same as having enough inventory when it's required. Suppose 20 additional bicycles arrive from a supplier. If they arrive before the customer needs them, they can help satisfy the demand. If they arrive afterward, they don't solve this particular shortage. Master Planning therefore considers quantity and timing together. A total inventory number without dates can provide a misleading picture of whether customer demand can actually be fulfilled.

THE PLANNING HORIZON
The appropriate planning horizon depends on the business. A company purchasing simple products locally might only need to look several weeks ahead. A manufacturer using components with long supplier lead times may need to plan months ahead. The important principle is that planning needs to look far enough forward to identify shortages while there is still time to respond. Discovering a shortage after the required purchasing or production date has already passed provides very little value.

FORECAST PLANNING
Forecast Planning begins with expected demand rather than confirmed customer orders. A bicycle manufacturer might expect demand to increase during summer. A retailer might anticipate significantly higher sales during a promotion. Waiting until every customer order arrives could leave insufficient time to purchase materials or reserve production capacity. Forecast Planning gives organizations an earlier view of the workload they expect to face.

GROSS REQUIREMENTS
Forecast Planning calculates gross requirements based on expected demand. If the forecast predicts demand for 500 bicycles in July, planning begins with that expected requirement. The organization can then consider the materials, supplier capacity, warehouse space, and production resources potentially required to support that volume. Forecasts aren't guaranteed customer orders. They provide a planning signal allowing the business to prepare before confirmed demand arrives.

INTERCOMPANY MASTER PLANNING
Large organizations may operate several legal entities. One company might manufacture a product while another sells that product in another country. The selling company sees customer demand. The manufacturing company needs visibility into the supply requirements created by that demand. Intercompany Master Planning carries planning signals across company boundaries so each legal entity doesn't plan as though it operates completely independently.

FROM ONE ORDER TO A CHAIN OF SUPPLY
A finished product can create demand for many lower-level components. Suppose a customer orders 70 bicycles. Dynamics 365 can examine the structure of the finished bicycle and determine which components are required to produce those 70 units. That might create requirements for 70 frames, 140 wheels, 70 chains, 70 seats, and hundreds of smaller components. This is where the Bill of Materials becomes critical.

BILL OF MATERIALS EXPLAINED
A Bill of Materials, commonly called a BOM, is essentially the recipe for a manufactured product. For a bicycle, it identifies the frames, wheels, chains, seats, handlebars, brakes, bolts, and other components required for production. Master Planning can expand demand for the finished product into requirements for the components underneath it. Planners therefore don't need to manually calculate every component requirement whenever customer demand changes.

PRODUCTION ROUTES
Having every component available still doesn't automatically create a finished product. Production requires work. A route describes the steps required to manufacture the item. For a bicycle, those steps might include assembling the frame, installing wheels, checking brakes, and packing the finished product. Each operation can require resources such as employees, assembly lines, workbenches, machines, or specialized equipment.

PLANNING BACKWARD FROM THE CUSTOMER DATE
Suppose the customer needs the bicycles on Friday. Production might need to finish Thursday so the warehouse has time to prepare the shipment. Assembly might therefore need to begin Tuesday. Components might need to be available Monday. If a supplier requires ten days to deliver wheels, the purchase order must be placed considerably earlier. The customer delivery date therefore creates a chain of dependent dates stretching backward through production and purchasing.

LEAD TIMES
A lead time represents how long an activity takes. A supplier might require ten days to deliver components. A warehouse transfer could require two days. A production process might require three days. Master Planning uses these lead times when calculating when supply needs to become available. Incorrect lead times can therefore produce incorrect planning suggestions even when the planning calculation itself works perfectly.

PLANNED ORDERS
When existing supply can't cover demand, Dynamics 365 can create a planned order. A planned purchase order suggests buying something from a supplier. A planned production order suggests manufacturing something internally. A planned transfer order suggests moving inventory from another site or warehouse. These planned orders contain suggested quantities and dates based on the information available to the planning engine.

PLANNED ORDERS ARE SUGGESTIONS
A planned order isn't automatically a commitment. Dynamics 365 doesn't need to silently send a purchase order to the supplier or begin production simply because the planning calculation identified a shortage. The planner reviews the suggestion. Is the proposed supplier appropriate? Is the delivery date realistic? Does the quantity make sense? Can production actually handle the work? Master Planning provides the recommendation while the planner remains responsible for the decision.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

A customer clicks Buy, but the product could be sitting in a central warehouse, a nearby store, another legal entity, or with a fulfillment partner. The customer doesn't care about that complexity. They expect a clear delivery promise and their package to arrive. Dynamics 365 Intelligent Order Management coordinates that journey across sales channels, inventory locations, fulfillment systems, warehouses, carriers, and billing platforms. In this episode of M365 FM, Mirko Peters explains how Intelligent Order Management uses orchestration flows, inventory visibility, fulfillment optimization, providers, Dataverse, Power Automate, and Power BI to coordinate orders from initial capture through fulfillment and billing.

WHAT IS DYNAMICS 365 INTELLIGENT ORDER MANAGEMENT?
Dynamics 365 Intelligent Order Management is a cloud application designed to coordinate an order across the different systems involved in fulfilling it. Think of it as a central dispatch desk. It isn't another online store. It doesn't physically pick products from warehouse shelves, drive delivery vehicles, or replace the finance system. Instead, it receives orders, determines what needs to happen next, passes work to the appropriate connected systems, and tracks the updates coming back. The specialist systems continue doing their jobs while Intelligent Order Management coordinates the journey between them.

WHY MODERN ORDER MANAGEMENT BECOMES COMPLICATED
A company might sell the same product through its website, physical stores, online marketplaces, and a call center. From the customer's perspective, these are simply different ways to buy the same product. Behind the scenes, however, each channel might use a different system and format. The website has one order record. The point-of-sale system has another. The marketplace sends information differently. A call-center employee might create the order somewhere else. One customer transaction can therefore create several disconnected processes.

INVENTORY MAKES THE PROBLEM HARDER
Stock might exist across several locations. The main warehouse could have twenty units. A nearby store might have five. Another warehouse could have additional inventory but be significantly farther from the customer. Simply knowing that inventory exists isn't enough. Some inventory could already be reserved. Some locations might not support shipping. Another location might have the product but be unable to meet the customer's promised delivery date. Order management therefore needs to answer more than "Do we have it?" It needs to answer "Which available inventory should fulfill this particular order?" 

THE PROBLEM WITH DISCONNECTED SYSTEMS
When order information moves slowly between systems, employees frequently become the integration layer. Customer service checks one system, emails the warehouse, contacts the carrier, and then checks another application for billing information. Meanwhile, another sales channel could sell the same inventory before the stock update reaches it. That's how overselling, slow fulfillment decisions, duplicated work, and unclear customer updates can occur. Intelligent Order Management creates a coordination layer across those systems rather than forcing employees to manually connect them.

ONE ORDER JOURNEY ACROSS MULTIPLE SYSTEMS
The underlying idea is straightforward. Sales systems capture the order. Inventory systems maintain stock information. Warehouse and fulfillment systems handle picking and packing. Delivery partners transport the products. Billing systems handle the financial transaction. Intelligent Order Management coordinates the handoffs between these systems and maintains visibility into where the order currently sits in its journey.

DATAVERSE AS THE DATA FOUNDATION
Dynamics 365 Intelligent Order Management is built on Microsoft Dataverse. Dataverse provides a common data foundation used across Dynamics 365 and Power Platform applications. In practical terms, this gives Intelligent Order Management a structured place for order and fulfillment information even when the original transactions came from different systems. Organizations also don't need to replace every existing business application with another Dynamics 365 product before they can coordinate orders.

MICROSOFT AND NON-MICROSOFT SYSTEMS
An organization might already use Dynamics 365 Finance or Supply Chain Management. Another organization might use a third-party warehouse platform, e-commerce solution, marketplace, or logistics provider. Intelligent Order Management is designed to coordinate information across Microsoft and non-Microsoft business applications. The connection points between these systems are called providers.

PROVIDERS EXPLAINED
Think of a provider as a translator standing at the door between Intelligent Order Management and another system. One application sends order information in its own format. The provider translates and passes that information into Intelligent Order Management. Information can also travel back toward the connected system when another action needs to happen. This allows different applications to continue doing their specialist jobs while participating in the same coordinated order journey.

FOLLOWING THE ORDER JOURNEY
Imagine a customer orders two products from an online store and requests delivery tomorrow. The online store captures the customer information, delivery address, products, quantities, and delivery choice. A provider brings that order into Intelligent Order Management. Before fulfillment begins, the order can be validated. The system can check whether the necessary customer information, delivery details, product lines, quantities, and other required information are present before sending the order farther downstream.

WHY ORDER VALIDATION MATTERS
Suppose the customer's apartment number is missing. If the order travels directly through warehouse and carrier systems, the problem might not become visible until somebody attempts delivery. Validation provides an opportunity to identify incomplete or invalid information earlier. The order can then be held or routed appropriately instead of allowing incorrect information to move automatically through every downstream system.

ORCHESTRATION FLOWS EXPLAINED
An orchestration flow defines how an order should move through the organization's process. Think of it as a visual map of the order journey. A basic flow might receive an order, validate its header and lines, send it toward fulfillment, wait for the relevant events, and eventually send information to a billing provider. Instead of every employee remembering what should happen next, the process itself defines the route.

CONDITIONS IN ORDER FLOWS
Real-world orders don't always follow one straight path. An online consumer order might follow one process while a B2B order follows another. A particular product might require another approval. A failed validation could require the order to stop. Conditions allow orchestration flows to create different paths depending on what happens. A successful action can continue along one route while an unsuccessful result can send the order somewhere else for additional handling.

SPLITTERS AND MULTIPLE ORDER PATHS
Splitters allow an orchestration flow to branch into multiple paths according to rules established by the organization. Different order sources could require different checks. Different parts of an order might need different fulfillment routes. Some paths can eventually reconnect while others continue separately. This gives organizations a way to model more complicated order processes without hiding those decisions inside emails and manual handoffs.

CUSTOM ACTIONS
Not every business requirement fits a standard action. A company might have a specialized manufacturing platform, partner application, or internal system requiring another step in the order journey. Custom actions allow those organization-specific requirements to become part of the orchestration flow. The complete process therefore remains visible even when part of the work depends on a specialized business system.

PUBLISHING ORCHESTRATION FLOWS
Orchestration flows remain unpublished while teams build and test them. Incoming data doesn't execute through an unpublished flow. Once the organization is satisfied with the process, the flow can be published and incoming information begins moving through it. If the process needs modification, the published flow can be stopped, returned to an unpublished state, changed, tested, and published again. This provides a controlled approach to changing the routes used by live customer orders.

INVENTORY VISIBILITY
An order orchestration process only works effectively when it has useful inventory information. Inventory Visibility provides a consolidated view of stock across the organization's supply network. Inventory might exist in warehouses, stores, partner locations, or across different legal entities. Instead of manually checking several separate inventory systems, the wider order process can use connected inventory information when making fulfillment decisions.

INVENTORY DOESN'T ALWAYS MEAN AVAILABLE
Seeing ten units in a location doesn't necessarily mean those ten units can fulfill the current order. Inventory might already be reserved. A store could have stock but not support shipping. A warehouse might have the item but be too far away to satisfy tomorrow's delivery promise. Intelligent order management therefore needs to distinguish between inventory that physically exists and inventory that can realistically fulfill a particular customer order.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Dynamics 365 Business Central already provides capabilities for finance, sales, purchasing, inventory, projects, and other core business processes. But no two organizations operate exactly the same way. A company might need specialized shipping, local financial reports, additional approval rules, bank integrations, electronic invoicing, or a connection to another business system. In this episode of M365 FM, Mirko Peters explains how Business Central extensions add these capabilities without directly modifying the standard application—and what organizations should check before installing them.

WHAT ARE BUSINESS CENTRAL EXTENSIONS?
A Business Central extension is an add-on package that adds capabilities to Dynamics 365 Business Central or changes how part of the standard application works for a particular organization. An extension can be extremely small. It might add one required field to a customer card or introduce a new validation rule. It can also support an entire business process. A shipping extension might generate carrier labels, send parcel information to a shipping provider, and return tracking numbers to Business Central. The objective is to add the missing capability while keeping the standard Business Central foundation intact.

THINK OF EXTENSIONS LIKE APPS ON YOUR PHONE
A smartphone already contains core functionality such as calling, messaging, and a camera. You then install additional apps based on what you need. Business Central extensions follow a similar principle. Business Central provides the standard ERP foundation. Extensions add capabilities required by a particular organization, industry, country, or process. Instead of rebuilding the underlying application, organizations extend it with modular functionality.

WHAT CAN AN EXTENSION CHANGE?
Extensions can add fields, pages, reports, actions, rules, integrations, and business logic. For example, an extension could add a new button to a sales order, introduce another column to a list, change an invoice layout, or connect Business Central with an external service. Business logic allows extensions to enforce company-specific rules. An organization could prevent an order from being released until somebody enters a purchase order number or automatically start an approval process when an order exceeds a particular amount.

WHY EXTENSIONS ARE BETTER THAN CHANGING THE CORE CODE
Historically, organizations frequently customized ERP systems by directly changing the standard application code. That can create problems when the software vendor releases updates. The updated standard application expects the underlying system to behave in a particular way, while custom modifications may conflict with those changes. Extensions take a different approach. Their code remains separate from the standard Business Central application. Microsoft can update the core application while the organization's extensions remain separate packages. Extensions can still require compatibility testing, but this architecture provides a cleaner foundation for maintaining custom functionality.

STANDARD FIRST, EXTEND SECOND
Extensions shouldn't become an excuse to recreate an organization's old ERP system inside Business Central. Business Central already handles significant amounts of standard business functionality. Before creating or installing an extension, organizations should therefore ask whether a genuine business gap exists. Sometimes the right extension contains an entire integration. Sometimes the best solution is simply one additional field and one validation rule. The goal is to preserve the standard foundation while adding only what the business genuinely requires.

THE MAIN TYPES OF BUSINESS CENTRAL EXTENSIONS
Business Central extensions can originate from different sources. Some are packaged applications designed for common requirements. Others come from Microsoft or independent software vendors. Organizations can also create extensions specifically for their own Business Central environment. Understanding where an extension comes from helps determine how it should be evaluated, supported, maintained, and updated.

APP EXTENSIONS
An app extension is a packaged add-on designed to perform a particular job inside Business Central. A shipping app might connect orders with a carrier. A payment application could integrate with a payment provider. A reporting extension might add specialized financial reports. Once configured, users generally interact with these capabilities directly inside Business Central. The extension can add its own pages or introduce additional functionality into familiar areas such as sales orders, purchase orders, customer cards, and invoices.

MICROSOFT EXTENSIONS
Microsoft itself provides extensions for requirements that don't necessarily belong in the standard application for every customer. Localization is one example. Tax requirements, invoices, payments, and statutory documents differ between countries. Functionality required by organizations in one country might be completely irrelevant somewhere else. Extensions allow Microsoft to provide these capabilities without adding every possible country-specific requirement to the standard application.

ISV EXTENSIONS
ISV stands for Independent Software Vendor. These are software companies creating Business Central applications that can be used by multiple customers. An ISV might specialize in warehouse management, manufacturing, retail, payroll integrations, document management, electronic invoicing, banking, shipping, or industry-specific reporting. Instead of every Business Central customer developing the same functionality independently, an ISV creates a reusable application that multiple organizations can purchase or subscribe to.

MICROSOFT APPSOURCE
Many third-party Business Central applications can be found through Microsoft AppSource. AppSource acts as a marketplace where organizations can discover applications designed to extend Microsoft business applications. This can be particularly useful when the business requirement is common. If hundreds of companies need to connect Business Central with the same shipping company, bank, payment provider, or electronic invoicing platform, purchasing an established application may make more sense than developing another integration from scratch.

PER-TENANT EXTENSIONS
A per-tenant extension is developed specifically for one organization's Business Central environment rather than being published for every customer. This approach can make sense when the business requirement is genuinely unique. A distributor might have an unusual process for calculating delivery charges based on temperature-controlled transportation, delivery zones, returnable containers, and customer-specific agreements. If no existing application fits that requirement, a Business Central partner or developer can create a dedicated extension around the company's process.

CUSTOM DOESN'T AUTOMATICALLY MEAN BETTER
A custom extension can closely match the organization's process, but somebody must own it. Documentation needs to be maintained. Updates need testing. Problems need support. Changes to the business process may require development work. If an existing ISV application already solves the requirement, it may provide a more maintainable option. The decision should therefore begin with the business requirement—not with an assumption that custom development is always more powerful.

HOW EXTENSIONS CHANGE DAILY WORK
Users frequently experience extensions directly on Business Central pages they already know. An extension might add another field to a customer card, another action to a sales order, or additional information to an item card. Imagine a company requiring a delivery window for every customer. An extension could add that information to the customer record and then display it directly on the sales order. Employees don't need another spreadsheet or email containing the delivery requirement because the information appears where they perform the work.

PAGE EXTENSIONS
Page extensions modify the Business Central user experience without replacing the complete standard page. They can introduce fields, buttons, actions, and other elements. A new button might create a shipping label, send a payment reminder, open a related document, or initiate an approval request. The user continues working inside the familiar Business Central interface while the extension provides additional functionality directly within the relevant business record.

REPORT EXTENSIONS
Organizations frequently require documents and reports that differ from Business Central's standard output. An invoice might need additional legal text, another reference number, specific company information, or different layouts for domestic and international customers. Report extensions can add information or provide alternative layouts while preserving the standard report. Extensions can also enhance internal management, finance, and inventory reports with additional company-specific information.

PERMISSION SET EXTENSIONS
Adding functionality doesn't mean every employee should automatically receive access to it. Permissions determine what users can view, modify, post, or delete. An extension might introduce a new payment process required by finance employees or a shipping action required by warehouse workers. Permission set extensions can provide the necessary access structure for those new capabilities. The organization still determines which employees or groups should receive those permissions based on their responsibilities.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

What happens when someone at work needs a new laptop, raw materials for production, safety equipment, consulting services, or even a cleaning contract? In many organizations, purchasing still involves emails, spreadsheets, approval messages, vendor quotes, delivery notes, and invoices spread across different systems. Dynamics 365 Procurement and Sourcing connects these activities into one controlled source-to-pay process. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Supply Chain Management connects purchase requisitions, sourcing, vendors, RFQs, purchase orders, receiving, invoice matching, approvals, Accounts Payable, and vendor payments.

WHAT IS DYNAMICS 365 PROCUREMENT AND SOURCING?
Procurement and sourcing are closely related, but they describe different parts of the purchasing process. Sourcing focuses on finding and selecting the right vendor. The organization considers products, prices, delivery dates, terms, discounts, and the vendor's ability to meet its requirements. Procurement manages what happens when the organization actually buys something: the request, approval, purchase order, receipt, invoice, and eventually payment. Together, these activities create the source-to-pay process.

SOURCE-TO-PAY EXPLAINED
Source-to-pay describes the complete journey from identifying a business requirement to paying the supplier. The organization identifies what it needs, finds or selects an appropriate vendor, creates an order, receives the goods or services, processes the vendor invoice, and eventually pays the supplier. The individual steps aren't particularly unusual. The value comes from keeping them connected. Instead of approvals disappearing into email and invoices arriving without context, Dynamics 365 maintains the purchasing trail from the original request through payment.

DIRECT VS INDIRECT PROCUREMENT
Businesses typically purchase two broad categories of goods and services. Direct procurement covers goods or services directly connected to what the company produces or sells. A furniture manufacturer purchasing wood, screws, and fabric is buying direct materials. Indirect procurement covers products and services required to operate the business but which don't become part of the finished product. Examples include laptops, office furniture, training, repairs, cleaning, software, and legal services. Dynamics 365 can support both types while maintaining controlled purchasing processes.

PURCHASE REQUISITIONS
A purchase requisition is an internal request to buy something. An employee can specify what is required, the quantity, and potentially where the purchase should be delivered. Importantly, the requisition doesn't yet create a commitment with a vendor. That gives the organization an opportunity to review the requirement, check budgets, apply purchasing policies, and obtain the appropriate approvals before money is committed.

PROCUREMENT CATALOGS
Common purchases can begin through procurement catalogs. Think of the catalog as the organization's approved internal shopping shelf. Instead of somebody entering a vague request for "safety gloves," employees can select an approved product with an established description, supplier option, and price. Catalogs simplify purchasing for employees while helping the organization guide demand toward products and suppliers it already understands.

PROCUREMENT CATEGORIES
Not every purchase belongs in a product catalog. Organizations also purchase consulting, repairs, training, legal services, and other requirements that might not have a traditional item number. Procurement categories allow these purchases to be classified according to what the organization is buying. Examples could include safety supplies, computer equipment, professional services, building repairs, or training. This allows purchasing controls and spend analysis to work even when the purchase isn't a physical inventory item.

APPROVAL WORKFLOWS
A purchase shouldn't automatically proceed simply because somebody requested it. Dynamics 365 can use approval workflows, spending limits, purchasing policies, and budget controls to determine who needs to review a request. A small purchase might require one manager's approval. A larger expenditure could additionally require a budget owner or purchasing manager. The approval path can depend on factors such as amount, department, category, and company policy. Dynamics 365 records those approvals as part of the purchasing history.

REQUEST FOR QUOTATION
When the organization hasn't already selected a supplier, purchasing can create a Request for Quotation, commonly called an RFQ. Several vendors can receive the same requirements and provide their prices and commercial terms. One vendor might offer the lowest price but require three weeks for delivery. Another might cost slightly more but deliver next week. Dynamics 365 keeps those responses connected with the sourcing process so buyers can compare options before making a decision.

VENDOR MANAGEMENT
Vendor records contain information required for the organization's purchasing relationship with suppliers. Vendor catalogs can describe products available from particular suppliers, while approved vendor lists can identify which suppliers are permitted for specific products. This helps organizations control where employees and buyers purchase goods. Instead of choosing a supplier simply because somebody found one online, the purchasing process can guide users toward vendors the organization has already approved.

PURCHASE AGREEMENTS
A purchase agreement records longer-term commercial arrangements between the organization and a vendor. For example, the business might agree to purchase a particular quantity or spend a certain amount over an established period in return for agreed commercial terms. When purchases occur under that agreement, buyers don't need to renegotiate the complete arrangement every time. This is particularly useful for frequently purchased goods and strategic vendor relationships.

TRADE AND REBATE AGREEMENTS
Trade agreements can record vendor prices or discounts that apply during particular periods. If a supplier agrees to provide safety gloves at a discounted price for six months, Dynamics 365 can maintain that pricing arrangement. Rebate agreements address another scenario: the supplier returns money when agreed purchasing quantities or spending thresholds are reached. Together, these capabilities help organizations maintain negotiated commercial conditions within the purchasing process instead of relying on individual buyers to remember them.

THE PURCHASE ORDER
Once the organization knows what it needs and who will supply it, the purchasing decision becomes a Purchase Order, or PO. The purchase order formally describes what the organization intends to buy. It identifies the vendor, products or services, quantities, prices, delivery requirements, and payment terms. The PO becomes the central commercial record that purchasing, warehouse employees, finance teams, and the supplier can work against.

HOW PURCHASE ORDERS ARE CREATED 
Purchase orders can originate from several sources. An approved purchase requisition can become a PO. A buyer can release purchases against an existing purchase agreement. Planned demand can create planned purchase orders that later become real orders. Buyers can also manually create purchase orders when they already know exactly what needs to be purchased and which supplier should provide it. Different purchasing scenarios can therefore enter the process differently while ultimately creating the same controlled purchase record.

PURCHASE ORDER APPROVAL AND CONFIRMATION
The organization can require internal approval before a purchase order becomes an external commitment. This separates two important decisions. First, the organization approves spending its own money. Then the purchase order can be confirmed with the vendor, establishing the agreed products, quantities, prices, delivery dates, and terms. This creates a clearer purchasing process than sending an order externally before the appropriate internal approval has occurred.

DELIVERY SCHEDULES
Not every purchase order arrives in one delivery. A supplier might deliver part of an order immediately and the remainder the following week. Delivery schedules allow one purchase order to contain planned deliveries across multiple dates. The organization maintains one connected purchasing record while representing what is actually expected to happen operationally.

DIRECT DELIVERY
Some purchased goods never need to enter the organization's own warehouse. With direct delivery, a supplier ships products directly to the organization's customer. Dynamics 365 can connect the customer sales order with the corresponding vendor purchase order. This eliminates an unnecessary warehouse stop while maintaining the relationship between the customer demand and the supplier fulfilling that demand.

SUPPLEMENTARY ITEMS AND CHARGES
Purchase orders can contain more than the primary item being purchased. Dynamics 365 can suggest supplementary products that may be required, optional, or included with another item. Charges such as freight and handling can also be associated with the purchase order or individual lines. This matters because the advertised product price doesn't necessarily represent the complete purchasing cost. Keeping additional charges connected to the order provides a clearer view of what the purchase actually costs.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

You made the sale and sent the invoice—but when does the money actually reach your account, and what happens when it doesn't? Dynamics 365 Accounts Receivable connects customer accounts, invoices, payment terms, incoming payments, settlement, credit management, collections, disputes, and overdue balances inside Dynamics 365 Finance. In this episode of M365 FM, Mirko Peters follows one customer balance from the original sale through invoicing and payment—and shows what happens when payment arrives late.

WHAT IS DYNAMICS 365 ACCOUNTS RECEIVABLE? 
Accounts Receivable tracks money customers owe the business and the payments received against those debts. Think of it as a financial filing cabinet. Every customer has a folder containing invoices, payments, due dates, payment terms, credit information, and follow-up activities. A spreadsheet can list outstanding invoices. Dynamics 365 Finance goes further by connecting those invoices with sales transactions, customer agreements, bank payments, credit decisions, and collection activities. The result is a connected view of the financial relationship with each customer.

THE CUSTOMER ACCOUNT
Every Accounts Receivable process begins with the customer account. The customer account contains more than contact information. It defines many of the financial rules governing how the organization does business with that customer. That can include the invoice address, payment terms, payment method, credit limit, customer group, and other financial settings. For example, products might be delivered to a customer's factory while invoices are sent to its finance office. Dynamics 365 can maintain those differences as part of the customer relationship.

PAYMENT TERMS AND DUE DATES
Payment terms answer a straightforward question: How long does the customer have to pay? One customer might pay immediately, another within 30 days, and a larger customer might negotiate 60-day payment terms. Once those rules exist on the customer account, Dynamics 365 can use them when calculating invoice due dates. Employees don't need to search through email conversations every time an invoice is created to determine what was agreed with the customer.

CUSTOMER CREDIT LIMITS
A credit limit defines how much the organization is willing to let a customer owe at one time. A strong customer relationship doesn't automatically mean unlimited financial exposure. If a customer already has a substantial outstanding balance and places another large order, Dynamics 365 can help finance and sales determine whether the new transaction requires additional attention. Credit limits therefore establish agreed financial boundaries before unpaid balances become larger problems.

CUSTOMER GROUPS AND POSTING PROFILES
Customer groups allow organizations to organize customers with similar characteristics. Retail customers might belong to one group while wholesale customers belong to another. Posting profiles handle an accounting requirement behind the scenes. They determine which financial accounts should record customer debt when transactions are posted. Employees outside finance might rarely interact with these configurations, but they help ensure customer transactions reach the correct places within the organization's financial records.

FROM SALES ORDER TO CUSTOMER INVOICE
An order and an invoice aren't the same thing. A sales order records what the customer wants to purchase. An invoice establishes what the customer needs to pay. When the invoice is posted, Dynamics 365 creates an open balance against the customer account. Accounts Receivable can then track that amount until payment closes it or somebody needs to take action.

INVOICING FROM SALES ORDERS
Many customer invoices originate directly from sales orders. Because the sales order already contains information about the customer, products, quantities, prices, and other agreements, finance doesn't need to recreate those details inside a separate billing system. Depending on the organization's process, invoicing might happen when products ship or when another agreed billing milestone occurs. The important point is that the invoice remains connected to the underlying business transaction.

PACKING SLIP INVOICING
Sometimes an organization wants to invoice based on what actually shipped rather than everything originally ordered. Imagine a customer orders ten units but only eight are currently available. If eight units ship, invoicing based on the confirmed delivery information allows the organization to bill for those eight rather than charging the customer for products that haven't yet been delivered. This creates a closer connection between warehouse execution and financial billing. 

FREE TEXT INVOICES
Not every invoice begins with a sales order. An organization might need to invoice a customer for training, a service charge, a project-related fee, or another one-off amount. Dynamics 365 Finance supports free text invoices for these situations. Despite the name, these are still formal invoices. The difference is that they aren't linked to a sales order. Once posted, the amount becomes part of the customer's outstanding balance just like other customer invoices.

RECURRING AND SUBSCRIPTION BILLING
Recurring services introduce another Accounts Receivable requirement. If a customer pays a monthly maintenance fee, manually recreating the same invoice every month wastes time and increases the possibility of errors. Billing schedules can support recurring charges according to the agreed arrangement. Instead of rebuilding every invoice manually, the organization establishes the billing schedule and uses that structure as billing periods arrive.

WHAT POSTING AN INVOICE MEANS
Posting is an important financial moment. Before posting, the invoice hasn't yet become the same kind of finalized financial transaction. Once posted, Dynamics 365 records the amount against the customer's account as money owed and sends the transaction into the organization's financial records. Accounts Receivable can now see the outstanding balance, due date, and customer responsible for paying it.

RECEIVING CUSTOMER PAYMENTS
Money arriving in the company's bank account doesn't automatically complete the Accounts Receivable process. Finance still needs to answer two questions: Who sent the money, and which invoice—or invoices—does that payment belong to? Without connecting the payment to the correct customer debt, the bank could show that cash arrived while Dynamics 365 still reports the customer's invoice as unpaid. The financial records therefore need to meet.

CUSTOMER PAYMENT JOURNALS
A customer payment journal provides a controlled place for finance teams to enter and review customer payments. Information can include the customer, payment amount, payment method, receiving bank account, and references associated with the transaction. Customers might pay through bank transfers, cards, checks, cash, or other supported payment mechanisms. The payment journal helps finance record those transactions before they become part of the posted financial records.

SETTLEMENT EXPLAINED
Settlement sounds technical, but the basic concept is simple: Settlement matches a payment with the invoice it pays. If a customer pays exactly the amount owed on an invoice, finance can match the payment against that open invoice. Once processed, the invoice no longer remains outstanding and the customer's open balance decreases accordingly. Without correct settlement, an organization can receive the money while still incorrectly showing that the customer owes it.

PARTIAL PAYMENTS
Customers don't always pay an invoice in full. If a customer pays only part of the outstanding amount, Dynamics 365 can settle the amount received while keeping the remaining balance open. Finance can therefore see precisely how much has been paid and how much remains outstanding. This is significantly clearer than marking an invoice as completed and attempting to track the remaining amount through notes or external spreadsheets.

PAYMENT RECONCILIATION
Organizations receiving large numbers of bank payments need a more efficient way to match incoming transactions with customer invoices. Dynamics 365 can use payment reconciliation processes to help match bank information against open customer transactions. References, amounts, customer information, and matching rules can help identify likely matches. Finance still reviews the results. Automation reduces manual searching, but the team remains responsible for ensuring that payments settle the correct invoices.

CENTRALIZED PAYMENTS
Organizations operating several legal entities can face additional payment complexity. A central finance organization might receive payments on behalf of several companies within the wider group. Dynamics 365 supports centralized payment scenarios where a payment can be recorded in one legal entity while settling customer debt associated with another. This allows the accounting records to reflect how the organization actually manages its centralized finance operations.

CREDIT MANAGEMENT
Receiving payment closes an existing debt. Credit management asks whether the organization should allow the customer to create more debt. Dynamics 365 can consider the customer's credit limit, outstanding invoices, overdue amounts, and the value of a new sales order. A customer might technically remain below its credit limit but have significantly overdue invoices. Another customer might pay reliably but place an unusually large new order. Credit management provides structured rules for identifying transactions requiring review.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Dynamics 365 Warehouse Management turns inventory records into guided physical work on the warehouse floor. Knowing that 200 units exist is only the beginning. Warehouse teams need to know exactly where those units are stored, whether they are available, which customer orders they belong to, and what workers should do with them next. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Warehouse Management connects receiving, put-away, storage, replenishment, picking, packing, shipping, cycle counting, returns, quality management, barcode scanning, and warehouse automation with the wider Dynamics 365 Supply Chain Management platform.

WHAT IS DYNAMICS 365 WAREHOUSE MANAGEMENT?
Dynamics 365 Warehouse Management focuses on the physical work taking place inside a warehouse. It guides employees through receiving deliveries, moving products into storage, replenishing picking locations, picking customer orders, packing shipments, and preparing goods for dispatch. Each completed warehouse action can update the same connected business system used by purchasing, sales, production, inventory, quality, transportation, and finance. Instead of relying on paper lists or recording movements later, warehouse employees can confirm activities while they happen using mobile devices and barcode scans.

INVENTORY MANAGEMENT VS WAREHOUSE MANAGEMENT
Inventory Management and Warehouse Management solve related but different problems. Inventory Management answers questions such as: How much inventory does the company have? What is it worth? Is it available? Warehouse Management focuses on questions such as: Where exactly is that inventory, and what should a warehouse worker do with it next? Knowing that 200 boxes exist in Warehouse A isn't enough for efficient warehouse operations. Employees need to know that 80 are in one rack, 60 are in bulk storage, 20 are near packing, and another quantity is already reserved. Inventory Management provides the stock record. Warehouse Management converts that information into physical work.

SITES, WAREHOUSES AND LOCATIONS
Dynamics 365 needs a digital representation of the physical warehouse environment. A site can represent a broader business location such as a factory campus or distribution center. A site can contain one or more warehouses. Inside those warehouses are individual locations representing receiving docks, racks, shelves, bins, packing stations, staging areas, and quarantine areas. This hierarchy gives inventory a precise digital location rather than simply recording that the product exists somewhere inside a building.

BATCH AND SERIAL NUMBER TRACKING
Warehouse Management can maintain additional information about individual products. Batch numbers identify groups of products from the same production run or delivery. This becomes particularly important for food, pharmaceuticals, chemicals, and other products requiring traceability. Serial numbers identify individual units. Machines, laptops, and high-value components can therefore maintain their individual identities as they move through the warehouse and eventually reach customers. This creates a traceable history that can become valuable for returns, quality problems, servicing, and recalls.

LICENSE PLATES EXPLAINED
A warehouse license plate isn't a vehicle registration. In Dynamics 365, a license plate provides a unique identifier for a pallet, carton, tote, or another container. Think of it like a luggage tag. Scanning the identifier tells Dynamics which container the worker is handling and what that container contains. Instead of scanning every individual box on a pallet repeatedly, employees can work with the license plate representing the complete pallet when the underlying inventory record is accurate.

RECEIVING INBOUND GOODS
Warehouse activity frequently begins with a purchase order. The purchase order tells the organization which products it expects from a supplier, the expected quantities, and usually the expected arrival time. When the truck reaches the warehouse, employees can scan the products or pallets and compare the physical delivery with the expected purchase order. If 100 cases were expected but only 98 arrived, the discrepancy can become visible immediately instead of waiting for somebody to manually enter paperwork later.

QUARANTINE AND QUALITY CONTROL
Not everything entering a warehouse should immediately become available. Products might require inspection, testing, or approval before they can be used or shipped. Dynamics 365 can direct those goods toward quarantine locations. The inventory physically exists inside the warehouse, but employees cannot treat it like ordinary available stock. Once the appropriate quality process has been completed, the products can either be approved for normal use or rejected and handled appropriately.

PUT-AWAY
After receiving, products need somewhere to go. This process is called put-away. Instead of asking workers to decide where a pallet should fit, Dynamics 365 can direct them toward an appropriate storage location. The decision can consider the product, warehouse zone, physical size, storage requirements, available space, and intended use of the location. The worker receives a straightforward instruction while the underlying warehouse configuration handles the decision logic.

LOCATION DIRECTIVES
Location directives are the rules Dynamics 365 uses to determine where inventory should go or where inventory should be picked from. Heavy inventory might need a ground-level rack. Fast-moving products might belong close to packing areas. Temperature-sensitive products may only be stored in approved locations. Location directives translate these warehouse policies into executable instructions. Instead of expecting every employee to memorize every storage rule, Dynamics can determine an appropriate location and present that destination through the worker's device. 

WORK TEMPLATES
Work templates determine the steps employees need to perform. For inbound inventory, a work template might contain two straightforward steps: pick the inventory from the receiving location and put it into its designated storage location. For outbound operations, templates can define picking, movement to packing, and staging. These repeatable workflows help create consistent warehouse processes across employees and shifts.

MOBILE DEVICES AND BARCODE SCANNING
Warehouse employees can receive instructions directly on mobile devices. The device can ask the worker to scan a location, scan a product, confirm a quantity, and proceed to the next step. These scans create immediate validation. If somebody scans the wrong product while picking a customer order, the system can identify the problem before the incorrect item reaches the customer's package. The scan also updates the warehouse record while the physical activity occurs rather than requiring information to be entered later. 

           REPLENISHMENT
Many warehouses separate bulk inventory from smaller locations used for daily order picking. When a picking location begins running low, employees need to move additional inventory from bulk storage before somebody encounters an empty shelf while fulfilling an order. Dynamics 365 can create replenishment work directing employees to move inventory into the appropriate picking location. This turns replenishment into planned warehouse activity rather than an emergency search for missing products.

OUTBOUND WAREHOUSE MANAGEMENT
Outbound warehouse activity begins when customer demand needs to become a physical shipment. A sales order identifies what the customer ordered and how much they require. Inventory can be reserved for that order so the same limited stock isn't accidentally promised to somebody else. Warehouse Management then converts the requirement into physical activities such as picking the products, moving them to packing, preparing containers, staging the shipment, and eventually moving the goods toward the loading dock.

WAVES EXPLAINED
Large warehouses don't necessarily process every customer order independently. Dynamics 365 can use waves to group outbound work. Orders might be grouped because they leave on the same truck, share a delivery date, belong to a similar warehouse zone, or follow another operational rule. Grouping work can reduce unnecessary movement and help warehouses process large quantities of orders more efficiently.

PICKING CUSTOMER ORDERS
Once warehouse work is released, employees receive picking instructions. The mobile device can direct someone toward the appropriate location, ask them to scan the location, verify the product, and confirm the quantity. This creates several validation points before the product leaves its storage location. Instead of relying on a paper list and discovering errors at the end of the process, Dynamics can identify some mistakes while the worker is still standing at the shelf.

CLUSTER PICKING
Cluster picking allows one employee to pick products for several customer orders during a single journey through the warehouse. The worker might use a cart containing multiple totes, with each tote associated with a different order. When an item is picked, the mobile device tells the employee which tote should receive it. This can reduce unnecessary walking while keeping products belonging to different customer orders separated. 

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Dynamics 365 Transportation Management connects the movement of physical goods with sales orders, purchase orders, warehouse operations, carriers, routes, rates, loads, and freight costs. Instead of managing transportation through separate spreadsheets, emails, carrier rate sheets, and phone calls, organizations can create a connected transportation plan directly inside Dynamics 365 Supply Chain Management. In this episode of M365 FM, Mirko Peters explains how Transportation Management works from the moment goods need to move through load planning, carrier selection, warehouse execution, delivery, and freight reconciliation.

WHAT IS DYNAMICS 365 TRANSPORTATION MANAGEMENT?
Dynamics 365 Transportation Management is the transportation planning capability inside Dynamics 365 Supply Chain Management. It connects warehouses, vendors, customers, carriers, orders, shipments, and freight costs. Think of it as the transportation desk inside the organization. Sales creates customer demand, purchasing manages incoming goods, warehouse teams prepare inventory, and Transportation Management determines how those goods should move between locations. The objective is to create one connected transportation process instead of maintaining separate lists and manual handoffs between departments.

WHY TRANSPORTATION MANAGEMENT MATTERS
A sales order doesn't physically move inventory. Goods still need a truck, trailer, container, or another form of transportation. Someone needs to determine where those goods originate, where they need to arrive, how much space they require, when they need to leave, and what transportation should cost. The challenge becomes significantly larger when a business manages hundreds of orders, several warehouses, multiple carriers, incoming supplier deliveries, customer shipments, and transfers between its own locations. Transportation Management provides a shared system for coordinating these movements.

INBOUND TRANSPORTATION
Inbound transportation covers goods moving into the organization. A purchase order might contain products expected from a supplier. Depending on the agreement, either the supplier or the purchasing organization may arrange transportation. When the organization manages that transportation, Dynamics 365 can connect the expected goods with a planned inbound load. Warehouse teams therefore gain visibility into what should arrive before the truck reaches the loading dock.

OUTBOUND TRANSPORTATION
Outbound transportation covers goods leaving the organization. A customer places a sales order, the warehouse prepares the products, and a carrier transports them to their destination. Transportation Management connects that sales demand with the shipment, load, carrier, route, service, and expected transportation cost. This allows warehouse and transportation teams to work around the same movement rather than independently planning different parts of the shipment.

TRANSPORTATION FOR TRANSFER ORDERS
Goods don't always move between a company and a customer or supplier. Organizations frequently transfer inventory between their own warehouses or sites. Dynamics 365 Transportation Management can include transfer orders within outbound transportation planning. From the loading dock's perspective, inventory still needs vehicle capacity, loading, transportation, and receiving regardless of whether the destination is a customer or another company warehouse.

WHAT IS A LOAD?
A load is the digital record representing a planned movement of goods. You can think of it as one truck, trailer, container, or collection of shipments traveling together. Several customer shipments might share one truck, while one particularly large customer order could require an entire trailer. The important idea is that Dynamics 365 doesn't require businesses to treat every individual order as a completely separate transportation job. Compatible shipments can be grouped into a shared transportation plan.

CONSOLIDATING SHIPMENTS
Imagine six customer orders are leaving the same warehouse for approximately the same destination on Friday. Booking six separate partially filled trucks would waste capacity and potentially increase transportation costs. Instead, compatible shipments can be grouped into one load. Compatibility can depend on factors such as departure location, shipping time, vehicle capacity, weight, volume, destination, and organizational transportation rules. This gives transportation planners an opportunity to use available vehicle capacity more efficiently.

LOAD TEMPLATES
Physical vehicles have limits. A truck can only carry a certain amount of weight and volume. Containers and trailers also have physical restrictions. Dynamics 365 uses load templates to represent reusable limits for different types of vehicles or containers. Organizations could create templates for small delivery trucks, large trailers, or shipping containers. These templates can include limits such as maximum weight, volume, and height. This helps planners determine whether a proposed load realistically fits the transportation capacity available.

VOLUME-BASED LOAD BUILDING
Dynamics 365 also supports volume-based load building. Despite the technical name, the concept is straightforward: Dynamics uses information from the load template to help determine whether goods fit within the configured transportation limits. The planner can still override values when real-world circumstances require an exception. The system therefore provides a standard planning framework without pretending transportation always follows perfectly predictable conditions.

CARRIERS EXPLAINED
The carrier is responsible for physically moving the goods. That could be an external transportation company collecting freight from the warehouse, or it could represent the organization's own fleet. Even businesses operating their own trucks still require transportation planning. They need to determine which goods travel together, where the vehicle travels, and potentially how transportation costs should be allocated. Dynamics 365 Transportation Management can support both scenarios.

ROUTES AND SERVICES
A route describes how goods travel between their starting point and destination. Different services might provide different combinations of speed, availability, and cost. A standard road freight service might be less expensive but take longer, while an expedited option might cost considerably more while helping the organization meet an urgent customer commitment. Transportation planning therefore isn't simply about finding a vehicle. It is about selecting a transportation option that balances delivery requirements with cost.

TRANSPORTATION RATES
Rates represent the expected transportation charges associated with carrier services and routes. Organizations can maintain rate tables containing agreed carrier prices and transportation rules. Instead of searching through old emails or spreadsheets every time transportation needs to be booked, planners can use structured rate information already maintained inside Dynamics 365. When carrier contracts and prices change, those rate records can be updated accordingly.

THE RATE ROUTE WORKBENCH
The Rate Route Workbench gives transportation planners a place to compare route and rate options for a shipment. One option might be faster while another costs less. Dynamics 365 provides the available transportation information, but the business still determines which trade-off makes sense. An urgent customer order might justify an expensive expedited service. Another customer might accept a longer delivery time in exchange for lower transportation costs.

DYNAMICS 365 IS NOT A LIVE CARRIER MARKETPLACE
An important distinction is that the built-in Transportation Management module doesn't automatically behave like a live marketplace comparing real-time prices across every available carrier. Its built-in planning processes use the carrier, route, and rate information maintained by the organization. Companies requiring live multi-carrier rate shopping, extensive booking integrations, or deeper shipment tracking can connect specialized third-party transportation management solutions. Dynamics 365 remains the internal transportation planning layer while external platforms can extend the carrier-facing capabilities.

FROM SALES ORDER TO CUSTOMER DELIVERY
For outbound transportation, the process begins with customer demand. The sales order defines what the customer purchased, where the products need to go, and when delivery is expected. Those products become part of a shipment, and shipments can be assigned to a planned load. Warehouse employees then pick, pack, stage, and load the products. Because the warehouse work connects with the transportation plan, employees can see which goods belong together and which carrier is expected to collect them.

CONNECTING TRANSPORTATION AND WAREHOUSE MANAGEMENT
Transportation planning and warehouse execution are closely connected. Transportation Management determines how goods should travel. Warehouse operations physically prepare those goods for movement. Instead of warehouse employees preparing pallets without knowing which transportation plan they belong to, shipments can remain connected to their loads. This reduces the need to reconcile separate transportation spreadsheets, warehouse lists, emails, and paper documents at the loading dock.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Microsoft 365 Copilot is moving far beyond prompt engineering. As organizations adopt AI more seriously, the challenge becomes connecting Copilot and AI agents to business applications, Microsoft Graph, organizational knowledge, APIs, workflows, and enterprise data while maintaining security and governance. In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP and AI Tech Lead Yves Habersaat about Microsoft 365 Copilot extensibility, Copilot Studio, Microsoft Foundry, Model Context Protocol (MCP), RAG, multi-agent architectures, enterprise search, permissions, governance, AI readiness, and what it takes to build production-grade AI solutions.

FROM PROMPT ENGINEERING TO AI ARCHITECTURE
Prompt engineering can help employees get more value from generative AI, but enterprise AI requires much more than better prompts. Organizations need people who understand the underlying technologies, customer requirements, architecture, security, business applications, data, and implementation decisions. Yves argues that human architects and engineers remain important because AI can generate technical material and provide guidance, but organizations still need people capable of validating whether a solution actually addresses the business requirement.

WHERE COPILOT EXTENSIBILITY BEGINS
Microsoft 365 Copilot has evolved considerably since its earliest versions. Many capabilities that previously required extensions are now available directly within the platform. Extensibility becomes particularly relevant when organizations need greater control. This could mean customizing orchestration, creating specialized agent experiences, integrating an agent into a website rather than only Microsoft 365 Copilot Chat, or building capabilities that aren't available through the standard experience. The more specialized the requirement becomes, the more important extensibility and custom development become.

WHY ONE GIANT COPILOT ISN'T THE ANSWER
Instead of building one enormous Copilot containing every instruction, tool, knowledge source, and responsibility, Yves recommends thinking in terms of multi-agent architectures. Individual agents can have clearly defined scopes and responsibilities. An IT support architecture, for example, could contain a front-facing agent responsible for understanding the user's request and routing it to specialized agents for Microsoft 365, Salesforce, or other platforms. Each specialized agent can then maintain its own instructions, knowledge, and tools.

THE ANATOMY OF AN ENTERPRISE AI AGENT
A typical enterprise agent starts with a clearly defined objective. The agent then requires instructions defining its responsibilities and boundaries, knowledge sources containing relevant organizational information, tools allowing it to perform actions, and an orchestration layer deciding how requests should be processed. In a multi-agent architecture, a front agent can delegate tasks to specialized agents. Those agents can then access internal knowledge sources, external systems, APIs, and MCP servers depending on the task they need to perform.

COPILOT STUDIO VS CUSTOM DEVELOPMENT
Copilot Studio provides a low-code approach to building agents. Organizations can define instructions, connect tools, integrate knowledge sources, and use MCP servers without building every component themselves. Custom development provides significantly greater control but also introduces more architectural responsibility. Developers may need to manage authentication, security, hosting, orchestration, external services, and integration patterns themselves. The decision therefore isn't simply low-code versus code. It depends on how much control the solution actually requires.

WHEN COPILOT STUDIO REACHES ITS LIMITS
One of the major questions is whether the organization needs to customize orchestration. If standard orchestration satisfies the requirement, Copilot Studio can provide a fast route to building an agent. If developers need deeper control over how plans are created, tasks are prioritized, workflows are executed, or models are selected, custom development becomes more relevant. Custom solutions can also integrate models hosted outside Microsoft's ecosystem, giving organizations additional flexibility over their AI infrastructure.

MICROSOFT FOUNDRY AND THE CHANGING AI STACK
Microsoft Foundry has evolved from its earlier role around model deployment into a broader AI development platform. Yves describes a platform increasingly supporting agent creation, governance, model management, MCP integration, and other capabilities. This creates some overlap with Copilot Studio, while custom development continues to provide greater flexibility around models, orchestration, hosting, and architecture. The Microsoft AI development landscape is therefore evolving rapidly, making architectural decisions increasingly dependent on the specific use case.

WHAT IS MODEL CONTEXT PROTOCOL?
Model Context Protocol, or MCP, addresses one of the major challenges in agent development: providing a standardized way for AI systems to discover and interact with external tools and services. Historically, developers integrated individual APIs using different authentication mechanisms, protocols, documentation, and implementation approaches. MCP provides a more standardized interface through which agents can understand which tools are available and how those tools can help accomplish a task. Yves describes it as an increasingly important part of modern AI architecture.

MCP VS TRADITIONAL API INTEGRATION
MCP doesn't eliminate APIs. Instead, an MCP server can sit in front of existing APIs, databases, and internal services and expose those capabilities in a way AI systems can understand. A company might already have APIs for finance, HR, CRM, or operational systems. An MCP server can expose appropriate tools around those services while the existing APIs continue performing the underlying operations. This makes MCP an AI-oriented integration layer rather than a replacement for the systems underneath it.

HOW AGENTS CHOOSE TOOLS
An enterprise agent might eventually have access to dozens or hundreds of tools. The agent's orchestration layer, working with the language model, can inspect the available capabilities and determine which tools are relevant to the user's request. It can then create a plan containing the actions required to complete the task and potentially invoke several tools in sequence. This ability to discover and select tools dynamically is one reason MCP has become important in agentic architectures.

MICROSOFT GRAPH REMAINS CENTRAL
MCP doesn't make Microsoft Graph irrelevant. Yves explains that Microsoft 365 MCP capabilities can rely on Microsoft Graph behind the scenes. An agent interacts with the MCP capability while Graph provides access to Microsoft 365 information and services underneath it. Graph also remains important to Microsoft 365 Copilot because organizational context across Microsoft 365 can be accessed through Microsoft's underlying graph and search capabilities. The integration layer is evolving, but Graph remains a major foundation of the Microsoft 365 ecosystem.

SECURING ORGANIZATIONAL KNOWLEDGE
Microsoft 365 contains enormous amounts of organizational context: documents, meetings, emails, people, Teams conversations, OneDrive files, and SharePoint content. Connecting AI to that information without proper governance creates obvious risks. Yves recommends beginning by understanding the organization's data. Companies need to know where confidential information exists, who should have access, and what information requires additional protection. Microsoft Purview capabilities such as sensitivity labels and Data Loss Prevention can then become part of the governance architecture.

DATA QUALITY IS AN AI PROBLEM
AI governance isn't only about preventing unauthorized access. Poorly organized SharePoint sites, duplicated files, outdated documents, inconsistent Teams environments, and unclear information ownership can reduce the quality of AI responses. Connecting an agent to organizational knowledge doesn't automatically make that knowledge useful. Organizations therefore need to consider data cleanup, information architecture, permissions, classification, and governance as part of AI readiness.

DELEGATED VS APPLICATION PERMISSIONS
Permissions become especially important when agents can take actions. Yves recommends delegated user permissions as the general starting point. This means an agent operates according to the permissions of the person using it. If the user doesn't have access to particular information or functionality, the agent shouldn't automatically gain that access on their behalf. Where application permissions are genuinely necessary, Yves suggests isolating them behind a controlled service or MCP layer rather than exposing broad application permissions directly to the user-facing agent.

RAG IN ENTERPRISE AI ARCHITECTURE
Retrieval-Augmented Generation, or RAG, allows AI systems to retrieve relevant organizational information before generating an answer. Instead of expecting the language model itself to contain current company-specific information, the system retrieves appropriate content from organizational knowledge sources. That information can come from documents, knowledge bases, Microsoft 365 content, or other enterprise systems. For many users, this happens invisibly because platforms such as Copilot Studio abstract the underlying retrieval architecture. ㅤ

RELATED M365.FM RESOURCES
Agentic RAG and Microsoft Copilot: https://www.m365.fm/agentic-rag/
MCP architecture for Microsoft AI agents: https://www.m365.fm/the-architects-guide-to-mcp-building-the-connectivity

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Related M365.FM resources: For more on AI coding agents and clean repository context, see https://www.m365.fm/blog/copilot-not-responding-troubleshooting-guide-for-microsoft-users/ and https://www.m365.fm/the-monorepo-myth-why-your-architecture-is-fragmented/. For Microsoft AI agent architecture and Copilot extensibility, see https://www.m365.fm/understanding-microsoft-copilot-enterprise-architecture/ and https://www.m365.fm/copilot-studio-vs-azure-ai-foundry-pick-your-poison/.

AI-assisted development is moving beyond autocomplete and chat. Modern AI coding agents can inspect repositories, modify files, run tests, analyze failures, create pull requests, and execute increasingly complex development tasks. In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP Lars Gyrup Brink Nielsen about GitHub Copilot, AI coding agents, developer experience, automated testing, TypeScript, JavaScript, Nx, monorepos, Polygraph, GitHub Actions, Playwright, and the architectural foundations required to make agentic software engineering work at enterprise scale.

FROM AI ASSISTANCE TO AI CODING AGENTS
For the last few years, AI development tools have primarily helped developers generate code, autocomplete functions, answer technical questions, and accelerate individual programming tasks. Agentic engineering changes that model. AI coding agents can potentially inspect an existing repository, understand an issue, modify multiple files, run automated tests, analyze failures, make corrections, and prepare a pull request. That changes the central question from "Can AI generate code?" to "Can AI safely perform engineering work inside a real software architecture?"

MEET LARS GYRUP BRINK NIELSEN
Lars Gyrup Brink Nielsen is a Microsoft MVP in Developer Technologies, author, international speaker, tech writer, open-source maintainer, community organizer, and former GitHub Star. His experience spans frontend development, cloud-native systems, developer experience, automated testing, continuous delivery, deployment, and open-source software. He has also worked with GitHub Copilot since its early days and has spent more than a year experimenting with AI coding agents in open-source development.

WHY DEVELOPER EXPERIENCE MATTERS
Developer experience is fundamentally about removing friction from software development. That includes choosing and integrating development frameworks, testing tools, build systems, CI pipelines, documentation, reusable packages, development environments, architectural standards, and automation. Lars contrasts modern developer tooling with earlier workflows involving FTP deployments, directly editing production systems, shared ZIP files, and environments without proper source control. Modern developer experience replaces these fragile processes with repeatable, automated, and verifiable workflows.

ARCHITECTURE SHOULD BE ENFORCED
Documentation alone isn't enough for large software architectures. Lars explains how tooling such as Nx can attach metadata to projects and enforce architectural boundaries. Organizations can define which types of projects may depend on other projects and use linting rules to automatically detect violations. Generators can also scaffold components, services, projects, tests, and configurations according to organizational standards. This becomes particularly important with AI coding agents. Instead of expecting an agent to remember every architectural rule, organizations can make those rules automatically enforceable.

MONOREPOS EXPLAINED
A monorepo stores multiple projects or systems inside a shared source-control repository. Microservices and micro-frontends don't necessarily require separate repositories. They can exist within one monorepo while still being independently built and deployed. The advantage is that dependencies between projects become easier to understand and changes spanning multiple systems can be tested together. However, Lars also explains that moving hundreds or thousands of developers from established repositories into one monorepo can be extremely difficult organizationally.

MONOREPO VS MULTIPLE REPOSITORIES
Separate repositories don't eliminate dependencies between teams. They simply manage those dependencies differently. When two teams maintain dependent systems in different repositories, changes can require coordination, separate environments, cross-repository testing, and synchronized deployments. A monorepo can make those dependencies more visible because the relevant source code exists within the same repository. The larger challenge is often organizational rather than technical: teams still need to communicate, coordinate ownership, and manage dependencies regardless of repository strategy.

WHAT IS NX?
Nx is a development toolchain that helps teams manage complex codebases, project dependencies, tasks, testing, builds, linting, generators, and development workflows. Lars explains how Nx has evolved beyond its earlier JavaScript-focused roots. It can integrate development tools, automate migrations, understand project relationships, orchestrate tasks, and support multiple technologies. It can also determine which projects are actually affected by a change rather than unnecessarily rebuilding or retesting an entire large codebase.

CACHING CAN DRAMATICALLY ACCELERATE DEVELOPMENT
Large codebases can contain hundreds of projects and enormous test suites. Repeatedly running every build, test, linting operation, and compilation task wastes significant developer and CI time. Nx can cache task results. If the relevant source files and dependencies haven't changed, developers can reuse previous results instead of executing the same work again. Remote caching can also allow teams and CI systems to share those results. For AI agents, faster verification becomes especially valuable because an agent may repeatedly modify, test, inspect, and correct code during a single task. 

POLYGRAPH AND MULTI-REPOSITORY AI AGENTS

Not every enterprise can move hundreds of existing repositories into a monorepo. Lars discusses Polygraph as a newer approach for helping AI coding agents operate across multiple related repositories. Instead of an AI coding session being isolated to one repository, Polygraph can provide a harness around multiple repositories and their dependencies. This can allow an agent to work across frontend, backend, microservice, and other repositories during the same development task and potentially prepare coordinated pull requests across those systems.

GITHUB ACTIONS AND CONTINUOUS INTEGRATION
Automation is a major part of the development environment discussed throughout the episode. GitHub Actions can provide the CI foundation for building, testing, validating, and deploying changes. Nx can work alongside CI workflows and delegate tasks through its own cloud capabilities. During the rapid-fire round, Lars gives GitHub Actions a particularly strong endorsement, calling it the best CI system.

PLAYWRIGHT FOR AUTOMATED TESTING
Automated verification becomes more important as AI writes a larger percentage of software. When asked to choose between Playwright and Cypress during the rapid-fire round, Lars chooses Playwright. The broader point is significant for agentic development: organizations need reliable automated feedback loops. If an agent changes code, it needs tools capable of determining whether those changes still satisfy the expected behavior.ㅤ

GITHUB COPILOT AND THE AGENTIC SHIFT
Lars was an early GitHub Copilot user through his involvement with the GitHub Stars program and provided feedback during Copilot's earlier development. His development workflow has now moved significantly beyond traditional Copilot autocomplete. He explains that he rarely writes code manually anymore and instead instructs coding agents to perform much of the implementation work. The challenge increasingly becomes reviewing and ensuring the quality of the code produced by those agents.

CONTEXT IS THE NEW ENGINEERING PROBLEM
An AI model may understand TypeScript, JavaScript, Angular, React, .NET, testing frameworks, and popular development tools from its training. What it doesn't automatically understand is your organization. Every large software environment contains internal naming conventions, architectural decisions, team standards, project-specific rules, historical constraints, and unique development practices. Those rules need to become accessible to AI agents through mechanisms such as agent instructions, skills, automated checks, architectural boundaries, and repository-specific context.

CLEAN CONTEXT FOR AI CODING AGENTS
Giving an AI agent more information isn't automatically better. Large repositories can contain enormous amounts of source code, documentation, configuration, legacy decisions, and irrelevant files. The challenge is providing the agent with the information required for its current task without overwhelming its working context. Development tooling, dependency graphs, repository structures, project metadata, agent instructions, and automated validation can help narrow that context. The objective is to give agents enough information to make architecturally correct decisions rather than merely locally correct code changes.

CODIFY YOUR TEAM STANDARDS FOR AI
Organizations don't necessarily need to fine-tune an AI model on their complete private codebase. Lars points instead toward codifying team-specific knowledge into agent skills and instruction files such as AGENTS.md. These instructions can explain how a particular team performs common tasks, which conventions should be followed, and how the codebase should be approached. This transforms knowledge that previously existed mainly inside experienced d

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Related M365.FM resources: To explore connected Dynamics 365 capabilities, see https://www.m365.fm/dynamics-365-supply-chain-management-simply-explained/, https://www.m365.fm/dynamics-365-inventory-management-simply-explained/, and https://www.m365.fm/dynamics-365-finance-simply-explained/.

A conveyor stops in the middle of a shift, a forklift won't start, or a pump suddenly begins leaking. Before anyone can repair the equipment, the business needs answers: Who is responsible? When was it last serviced? Which parts are required? What happened during the previous repair? Dynamics 365 Asset Management provides one central place for this information. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Asset Management helps organizations track physical equipment, preventive maintenance, work orders, spare parts, costs, service history, functional locations, condition-based maintenance, and connected maintenance processes.

WHAT IS DYNAMICS 365 ASSET MANAGEMENT?
Dynamics 365 Asset Management is part of Dynamics 365 Supply Chain Management and focuses on the physical equipment businesses rely on every day. That could include production machines, conveyor belts, motors, pumps, forklifts, trucks, generators, heating and cooling systems, and other equipment requiring regular inspection, servicing, or repair. Instead of maintenance information being distributed across spreadsheets, folders, emails, invoices, and individual employees' knowledge, Asset Management creates a shared record around the equipment and its maintenance history. 

WHY PHYSICAL ASSETS BECOME A BUSINESS PROBLEM
A machine doesn't only affect the maintenance department. When equipment fails, operations can lose production capacity, maintenance teams need to diagnose the fault, purchasing may need to urgently source replacement parts, and finance eventually receives the resulting costs. Emergency maintenance can become particularly expensive because organizations may need expedited shipping, urgent purchasing, overtime, or temporary workarounds. Dynamics 365 Asset Management connects these different parts of the maintenance story so teams can understand what happened and why money was spent. ㅤ

THE ASSET RECORD
Every piece of equipment can have its own digital asset record. The record can contain information such as the asset name, product or model number, serial number, description, technical details, and warranty information. This becomes particularly useful when several machines look almost identical but use different components, have different warranty periods, or require different maintenance procedures. Instead of relying on somebody remembering which machine is which, the asset record provides a consistent reference point.

FUNCTIONAL LOCATIONS EXPLAINED
Dynamics 365 Asset Management uses functional locations to describe where equipment performs its job. A functional location can represent a site, building, warehouse, workshop, production line, or another operational location. These locations can also form hierarchies. For example, an organization might have a plant containing a packing area, which contains a conveyor line, which contains individual motors, sensors, and rollers. When a motor fails, technicians therefore don't simply see a serial number. They can understand exactly where that motor operates and which wider process could be affected. 

PARENT AND CHILD ASSET STRUCTURES
Complex equipment frequently consists of smaller components that need their own maintenance history. Dynamics 365 can represent parent-and-child relationships between equipment and components. A conveyor can contain a motor, while the motor itself might contain another component requiring individual maintenance attention. This structure helps maintenance teams understand how individual assets relate to larger equipment and operational systems. ㅤ

TRACKING EQUIPMENT AS IT MOVES
Physical equipment doesn't necessarily remain in the same location forever. Forklifts can move between warehouses. Pumps can move from storage into buildings. Machines can be reassigned between production lines. Asset Management can track these movements through functional locations. This also matters financially because maintenance costs can follow the equipment to the location currently using it. Managers can therefore understand which plant, department, or operational area is responsible for the costs associated with an asset.

BUILDING A COMPLETE SERVICE HISTORY
The real value of an asset record grows over time. Inspections, repairs, replaced parts, technician notes, labor time, faults, downtime, and other maintenance information can become part of the equipment's history. A technician investigating a recurring problem can review previous repairs instead of starting from zero. The history might reveal that the same motor has been repaired several times, that a particular component repeatedly fails, or that an earlier technician identified something that needs additional monitoring.

ASSET MANAGEMENT VS IT ASSET MANAGEMENT
Dynamics 365 Asset Management focuses on physical operational equipment requiring maintenance, inspections, servicing, and repair. It isn't primarily designed for tracking office laptops, smartphones, or software licenses. Production machinery, vehicles, pumps, motors, building equipment, and similar physical assets create a different maintenance requirement because downtime, replacement parts, labor, inspections, and equipment condition all need to be managed over time.

REACTIVE VS PREVENTIVE MAINTENANCE
Reactive maintenance begins after something fails. The equipment stops, operations are affected, and the maintenance team needs to restore service as quickly as possible. Preventive maintenance attempts to perform appropriate maintenance before a small problem becomes an unexpected failure. Dynamics 365 Asset Management helps organizations plan recurring inspections, cleaning, lubrication, safety checks, testing, and replacement of components that wear out over time.

MAINTENANCE PLANS
Maintenance plans help organizations turn preventive maintenance into repeatable work. A forklift might require regular inspections of its brakes, tires, fluid levels, lights, and battery condition. A production line might require weekly sensor cleaning, monthly belt inspections, and component replacement after a particular amount of use. These tasks aren't dramatic individually, but performing them consistently can reduce the likelihood of equipment failing during critical operations.

MAINTENANCE BASED ON EQUIPMENT USAGE
Calendar schedules aren't always enough. Two identical machines might have very different workloads. One could operate for a single shift every day while another operates continuously. Technical readings such as running hours, distance traveled, temperature, pressure, or other measurements can provide additional information about when maintenance should occur. This allows organizations to combine scheduled maintenance with the actual usage and condition of equipment.

MAINTENANCE ROUNDS
Maintenance rounds provide technicians with planned routes or groups of inspections across multiple assets. Instead of treating every inspection as a separate activity, a technician can inspect related equipment during one routine visit. For example, someone could walk through a packing area checking several conveyor motors, listening for unusual sounds, inspecting fittings, and recording relevant technical readings. This creates a more consistent inspection process even when different technicians perform the work. 

CONDITION-BASED MAINTENANCE
Condition-based maintenance uses equipment measurements to identify when something may require attention. Imagine vibration readings from a conveyor motor gradually increasing over several weeks. The motor still operates, but the changing measurement indicates that something may be developing. When a reading crosses a threshold established by the organization, the maintenance team can investigate before the equipment necessarily fails. The objective isn't to perfectly predict every breakdown. It is to provide earlier warning and give maintenance teams more time to respond.

FROM MAINTENANCE NEED TO WORK ORDER
When maintenance becomes actual work, Dynamics 365 uses a work order. The work order acts as the job ticket connecting the problem, required activities, responsible workers, schedule, parts, safety instructions, labor, costs, and final outcome. Work orders can originate from scheduled maintenance, inspections, equipment breakdowns, or follow-up work identified by technicians. Regardless of the source, the work order turns a maintenance requirement into something that can be assigned, scheduled, tracked, completed, and reviewed.

PLANNING THE MAINTENANCE JOB
A work order can describe the job and the tasks required to complete it. For a conveyor motor showing unusual vibration, technicians might need to isolate the equipment, inspect the mounting, check bearings, complete the repair, test the machine, and return it to service. Checklists can help technicians perform required activities in the correct sequence. Safety instructions can also be associated with the work so requirements such as power isolation, protective equipment, or stopping moving equipment are visible during the job.

SPARE PARTS AND INVENTORY
Maintenance work frequently depends on replacement parts. A work order can identify required items such as bearings, filters, bolts, grease, or replacement motors. Because Asset Management connects with Dynamics 365 Supply Chain Management, teams can determine whether the required part is already available in inventory. If stock can't cover the requirement, purchasing can ord

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Dynamics 365 Dataverse Integration is easier to understand once you stop thinking about Dynamics 365 and Dataverse as two completely separate systems that constantly need to synchronize customer data. For Dynamics 365 applications such as Sales and Customer Service, Dataverse provides the shared data foundation underneath the applications. Accounts, contacts, leads, opportunities, cases, activities, relationships, permissions, and business rules can all live within this structured environment. In this episode of M365 FM, Mirko Peters explains what Dataverse actually is, how Dynamics 365 uses it, and how the same business data can power Power Apps, Power Automate, Power BI, and other connected processes.

WHAT IS MICROSOFT DATAVERSE?
 Microsoft Dataverse is Microsoft's cloud data platform for structured business information. Instead of keeping customer and operational data across disconnected spreadsheets, lists, emails, and applications, Dataverse provides a common place where approved business applications can work with structured information. Think of Dynamics 365 as an office building. Sales, Customer Service, and other applications are the rooms where employees work. Dataverse is the filing system, structure, and rules behind those rooms. The objective is to reduce unnecessary copies of the same business information and provide applications with a shared foundation.

ONE CUSTOMER INSTEAD OF MULTIPLE COPIES
Consider a company where Sales stores customer information in one system, Support maintains another customer list, Finance keeps another version, and additional information lives inside shared mailboxes and spreadsheets. When the customer's address or contact information changes, those copies quickly become inconsistent. With Dataverse, approved applications can work with the same customer information. A customer used by Dynamics 365 Sales can also provide context when that customer contacts Dynamics 365 Customer Service. Instead of asking which customer list is correct, teams can work around a shared reference point.

DATAVERSE TABLES EXPLAINED
Dataverse organizes business information into tables. An Account table can contain companies. Contacts can contain individual people. Leads represent potential customers, Cases can represent customer support requests, and Activities can represent calls, emails, appointments, and tasks. Microsoft provides standard tables for common business concepts, while organizations can create custom tables when they need to represent information specific to their business. A training company, for example, could create tables for courses and certificates, while a property company might create tables for buildings and inspections.

ROWS AND COLUMNS
Each table contains rows representing individual pieces of business information. One Contact row might represent a particular person. Columns then describe the information associated with that person, such as first name, last name, email address, phone number, job title, company, owner, and status. This structured approach gives information a predictable shape. Applications know what each value represents, reports can analyze it consistently, and automation can react when specific information changes.

STANDARD VS CUSTOM TABLES
Organizations should generally start with standard Dataverse tables when those structures already represent the business concept they need. Creating several custom tables that all represent slightly different versions of "customer" can recreate the same data fragmentation Dataverse is intended to reduce. Custom tables become valuable when the organization genuinely has business information that doesn't fit existing standard structures. The objective is a data model people can understand and reuse across applications.

RELATIONSHIPS CONNECT BUSINESS INFORMATION
Tables become significantly more useful when they are connected through relationships. A Contact can belong to an Account. A Case can connect to the customer who created the support request. An Opportunity can connect to calls, emails, appointments, and tasks associated with the sales process. Instead of repeatedly copying company information into every related record, relationships maintain connections between the information. If a company's address changes, the Account can be updated while related Contacts continue pointing toward the same company.

TABLES, COLUMNS AND ROWS VS OLDER TERMINOLOGY
Older Dynamics 365 and Dataverse documentation may use different terminology. What Microsoft now calls a table was previously commonly called an entity. A column was called a field, and a row was commonly called a record. Understanding both sets of terminology can make older documentation and training material easier to follow. ㅤ

SECURITY STARTS WITH IDENTITY
Shared information doesn't mean everybody should have access to everything. Microsoft Entra ID provides the identity used to determine who is working with Dataverse. Dataverse can then apply additional security controls governing what that person is permitted to do with business information. Think of Entra ID as the reception desk verifying who entered the building, while Dataverse security determines which rooms, filing cabinets, and information that person can access after entering. ㅤ

SECURITY ROLES
Security roles provide permissions associated with different jobs and responsibilities. Sales representatives might receive permissions for Accounts, Contacts, Leads, and Opportunities. Customer service agents might work with Cases without receiving the same permissions over sales opportunities. Permissions can govern operations such as reading, creating, updating, and deleting information. Because these controls exist around the underlying data, security doesn't need to depend exclusively on hiding buttons inside individual applications. ㅤ

ROW AND COLUMN LEVEL SECURITY
Access can become more granular than simply allowing or denying access to an entire table. Row-level security can determine which individual rows a person can access. A salesperson might only work with customers they own, while a sales manager can access customers belonging to the wider team. Column-level security can protect particularly sensitive information within an otherwise accessible row. This provides organizations with more control over who can access particular business information. ㅤ














Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Dynamics 365 Inventory Management gives businesses one shared record for the products, materials, parts, and other stock moving through their organization. Instead of purchasing, warehouse, sales, production, and finance maintaining separate versions of inventory information, Dynamics 365 connects quantities, locations, availability, ownership, movements, and financial value. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Inventory Management works from supplier receipt to customer shipment — including inventory dimensions, reservations, transfers, costing, cycle counting, safety stock, consignment inventory, and the connection between inventory and finance. ㅤ

WHAT IS DYNAMICS 365 INVENTORY MANAGEMENT?
Inventory Management provides a shared stock record across the business. For every item, organizations need to answer five fundamental questions: How many do we have? Where are they? Can we use or sell them? Who owns them? And what are they worth? Dynamics 365 brings those answers together. Purchasing records incoming goods, warehouse teams record movements, sales records what leaves, production records materials consumed, and finance receives the financial value associated with those transactions. ㅤ

WHY INVENTORY MANAGEMENT MATTERS
Too little inventory creates stockouts, delayed customer orders, lost sales, and potentially interrupted production. Too much inventory creates a different problem: money becomes trapped on warehouse shelves. Products also carry risks while sitting in inventory. They can expire, become damaged, go out of style, or simply stop selling. Inventory management therefore isn't about maximizing stock. The objective is maintaining enough inventory to satisfy demand without unnecessarily tying up working capital. ㅤ

MORE THAN FINISHED PRODUCTS
Inventory doesn't only mean products waiting to be sold. A manufacturer might track raw materials such as wood, screws, fabric, or components. Materials being transformed into products can become work in progress, while completed products become finished goods. Businesses may also track spare parts, packaging, replacement components, cleaning supplies, and materials required for service operations. Dynamics 365 provides a common inventory structure for these different types of stock. ㅤ

THE DIGITAL RECORD BEHIND EVERY ITEM
Every inventory item needs an identity inside Dynamics 365. This normally includes an item number, description, and unit of measure. Units of measure become particularly important when organizations purchase and sell products differently. A supplier might sell something by the box while customers purchase individual packs. Dynamics needs to understand the relationship between those units so purchasing, sales, warehouse, and finance teams interpret inventory quantities consistently. ㅤ

PRODUCT VARIANTS
Some products have multiple variations. Clothing might differ by size and color, while manufactured products can have different styles or configurations. Dynamics 365 can distinguish between these combinations rather than treating them as one generic quantity. The organization can therefore know that it has twelve black medium shirts in one warehouse and six white large shirts somewhere else rather than simply knowing that eighteen shirts exist. ㅤ

INVENTORY DIMENSIONS EXPLAINED
Inventory dimensions are labels that help Dynamics distinguish where inventory is located and exactly which inventory is being tracked. Storage dimensions describe location. These can include site, warehouse, and the specific location within a warehouse. Tracking dimensions identify particular inventory through information such as batch numbers and serial numbers. Together, these dimensions transform a generic stock quantity into information people can actually use operationally. ㅤ

SITES, WAREHOUSES AND LOCATIONS
A site represents a broader business location such as a factory or distribution center. Within a site, organizations can operate multiple warehouses. Locations provide another level of detail by identifying where inventory physically sits inside the warehouse. Instead of telling someone that a component is somewhere inside Warehouse A, Dynamics can provide a specific aisle, rack, shelf, or bin location. This becomes increasingly important as warehouse size and inventory complexity increase. ㅤ

BATCH AND SERIAL NUMBER TRACKING
Batch numbers identify groups of products received or produced together. They become important when organizations need to track expiration dates, quality information, supplier history, or product recalls. Serial numbers identify individual units. A laptop, medical device, or industrial machine can therefore maintain its own identity throughout inventory processes. This can support warranty claims, servicing, returns, and precise traceability. ㅤ

FROM PURCHASE ORDER TO GOODS RECEIPT
Inventory can begin its operational journey with a purchase order. The purchase order records what the organization expects to receive, the quantity ordered, the supplier, and the intended destination. When the shipment arrives, employees compare the physical delivery with that expectation. Once the goods receipt is recorded, Dynamics knows the inventory has physically arrived. This creates an important distinction between inventory that has merely been ordered and inventory that is actually present. ㅤ

QUARANTINE AND INVENTORY STATUS
Physically receiving inventory doesn't necessarily mean it should immediately become available. Some goods require quality inspection, expiry checks, testing, or regulatory verification. Dynamics can represent inventory in quarantine or assign a status preventing it from being used prematurely. Warehouse employees can see that the inventory exists while sales and production understand that it isn't currently available for consumption or customer orders. ㅤ

PUT-AWAY AND INTERNAL MOVEMENTS
After receiving and inspection, goods normally need to move from the receiving area into their appropriate storage locations. Dynamics records these internal movements so the system reflects where inventory physically resides. This means the inventory history doesn't stop when a delivery enters the building. It continues as stock moves between receiving areas, storage locations, warehouses, and sites. ㅤ

TRANSFER ORDERS
Organizations frequently move inventory between warehouses or sites. A transfer order records this movement. When goods leave the sending warehouse but haven't yet arrived at the destination, Dynamics can represent them as inventory in transit. The stock therefore hasn't simply disappeared from the system. The sending location knows what left, the receiving location knows what to expect, and discrepancies can be investigated against a documented movement. ㅤ

INVENTORY RESERVATIONS
When a customer places an order, inventory can be reserved specifically for that demand. Reservation means the quantity is no longer simply available for anyone to promise. It has been allocated to a particular requirement. This reduces the risk of two salespeople promising the same limited stock to different customers and becomes especially valuable when availability is low or delivery commitments are important. ㅤ

PICKING, PACKING AND SHIPPING
Once inventory is committed to an order, warehouse employees can pick the goods from their storage locations, prepare them for shipment, and dispatch them to the customer. When the goods ship, Dynamics records that inventory has left the warehouse and updates the available quantity. The transaction history can therefore provide a connected chain from supplier receipt through internal storage and eventually customer delivery. ㅤ

RETURNS, CORRECTIONS AND ADJUSTMENTS
Real inventory processes aren't perfect. Customers return products, items become damaged, workers discover incorrect quantities, and physical stock sometimes differs from the quantity recorded in the system. Dynamics can record returns, counting differences, movement corrections, and inventory adjustments. These records provide a history showing what changed and can help organizations identify recurring problems such as inaccurate receiving, damaged stock, incorrect locations, or missing warehouse movements. ㅤ

THE FINANCIAL VALUE OF INVENTORY
Inventory isn't only a physical quantity. It represents money the organization has already invested. When goods arrive, warehouse teams see additional units while finance needs to understand the corresponding inventory value. When inventory leaves, finance needs to recognize the financial impact of that movement. Dynamics connects the operational inventory record with the company's financial records so quantity and value remain connected. ㅤ

ITEM GROUPS AND THE GENERAL LEDGER
Item groups help organize similar products and influence how inventory transactions connect with financial accounts. Organizations might create separate groups for raw materials, spare parts, and finished products. The associated financial configuration determines which general ledger accounts receive the accounting impact of purchases, sales, adjustments, production activities, and other inventory transactions. This connection helps warehouse operations and finance work from the same underlying item activity. ㅤ



Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.