Explore every episode of the podcast M365.FM a Microsoft MVP Podcast by Mirko Peters

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.

Dynamics 365 Financial Reporting turns the financial data already posted in Dynamics 365 Finance into structured reports that finance teams, managers, auditors, and executives can actually use. Instead of rebuilding financial statements in multiple spreadsheets every month, organizations can use the general ledger, main accounts, financial dimensions, reporting categories, and predefined report structures to create consistent income statements, balance sheets, cash flow reports, trial balances, and budget-versus-actual reports. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Financial Reporting works and how organizations can move from financial transactions to reports people can trust.ㅤ

WHAT IS DYNAMICS 365 FINANCIAL REPORTING?
Financial Reporting is the Dynamics 365 Finance capability used to create, maintain, generate, and view financial statements based on general ledger information.It isn't another accounting ledger. Transactions such as invoices, payments, journals, payroll entries, and inventory adjustments are posted in Dynamics 365 Finance first. Financial Reporting then reads those financial results and organizes them into meaningful statements.Think of the general ledger as the financial filing cabinet and Financial Reporting as the report room that organizes those records into something people can understand.ㅤ

THE GENERAL LEDGER IS THE FOUNDATION
Every useful financial report starts with correctly structured accounting data.The general ledger contains the financial impact of customer invoices, supplier bills, payroll, bank payments, inventory adjustments, and other business transactions. Each amount is assigned to a main account representing what happened financially.Cash, sales revenue, rent expense, wages, accounts receivable, accounts payable, loans, and taxes can each have their own main accounts.Financial statements don't create these numbers. They organize and summarize balances that already exist in the ledger.ㅤ

MAIN ACCOUNT TYPES AND CATEGORIES
Main account types provide broad accounting classifications. Profit and loss accounts represent revenue and expenses for a period, while balance sheet accounts represent assets, liabilities, and equity.Main account categories provide another reporting layer.Several individual bank accounts, petty cash accounts, and clearing accounts might all belong to a broader cash category. A financial report can therefore show one clean cash line while finance retains the detailed accounts underneath it.Correct account types and categories make financial statements significantly easier to build and maintain.ㅤ

FINANCIAL DIMENSIONS ADD BUSINESS CONTEXT
Main accounts explain what happened financially. Financial dimensions explain where, who, or which part of the organization was responsible.Dimensions might represent departments, cost centers, business units, regions, locations, or projects.For example, three transactions could all post to the same rent expense account while their dimensions identify Head Office, Warehouse, and Retail North.Finance can see total rent expense while individual managers can analyze the portion associated with their area of responsibility.ㅤ

FINANCIAL DIMENSIONS VS FINANCIAL TAGS
Not every piece of transaction information should become a financial dimension.Dimensions are most useful for reusable values organizations expect to report against repeatedly, such as department, cost center, region, or business unit.Financial tags are better suited to flexible transaction references such as invoice numbers, purchase order numbers, payment references, or external system IDs.Creating dimensions for thousands of unique transaction references can make the financial structure unnecessarily complicated.ㅤ

DEFAULT FINANCIAL REPORTS
Dynamics 365 Finance includes 22 default financial reports that organizations can use as starting points.These include common reports such as income statements, balance sheets, cash flow reports, detailed and summary trial balances, rolling expense reports, budget-versus-actual reports, and other financial views.Organizations don't necessarily need to design every statement from scratch. A default report can be opened, compared against actual ledger balances, and adjusted to match the company's account structure and reporting requirements.ㅤ

FINANCIAL REPORTING VS POWER BI, EXCEL AND OTHER TOOLS
Dynamics 365 Finance provides several reporting technologies, and each serves a different purpose.Financial Reporting is designed for structured general-ledger-based financial statements. Power BI is better suited to interactive dashboards, visual analysis, filters, trends, and management questions.Excel remains useful for additional analysis, calculations, checks, and familiar data exploration.SSRS is generally suited to fixed-format operational documents and detailed reports, while Electronic Reporting focuses on structured files such as tax submissions, bank files, XML, and CSV outputs.Using the appropriate tool reduces the need to force every reporting requirement into Excel.ㅤ

HOW ROW DEFINITIONS WORK
A row definition controls what appears down the left side of a financial statement.For an income statement, rows might include Revenue, Cost of Sales, Gross Margin, Operating Expenses, and Net Result.Rows can reference individual main accounts, ranges of accounts, account categories, dimension combinations, or calculated totals.Gross margin, for example, doesn't necessarily point directly to an account. It can be calculated by subtracting cost of sales from revenue.Row definitions therefore determine what the report is actually reporting.ㅤ

HOW COLUMN DEFINITIONS WORK
Column definitions determine how financial information is displayed across the report.Columns might show the current month, year-to-date results, previous-year results, budget, actuals, forecast figures, or variance between actual and budget.A management income statement could therefore contain Current Month, Year to Date, Budget, and Variance columns without requiring someone to export the report into Excel and manually create comparison formulas.ㅤ

REPORT DEFINITIONS
A report definition connects the row and column structures into a report users can generate.For example, finance might create an Income Statement Rows definition and combine it with a Monthly Actual, Budget and Variance column definition.The resulting report definition could become the Monthly Management Income Statement.This modular approach means organizations can reuse the same financial statement structure with different periods, comparisons, and reporting views rather than rebuilding reports repeatedly.ㅤ

REPORTING TREES
Reporting trees allow organizations to structure financial reports around different reporting units.These units might represent legal entities, regions, departments, business units, or other organizational structures.A company with subsidiaries could generate results for each individual subsidiary and then provide a combined group view. A regional organization might show North, South, and West individually while also producing a company-wide total.This allows the same reporting framework to serve both local managers and centralized finance teams.ㅤ

SUMMARY, DETAIL AND DRILL-DOWN
Financial reports don't need to remain static pages.Users can begin with a summary showing figures such as total revenue, costs, and net result and then move into additional detail when a number requires investigation.If operating expenses are significantly above budget, finance can drill into the amount and inspect the transactions behind it, including journal entries, dates, vouchers, and related details.This turns a financial statement into a starting point for analysis instead of simply a document distributed at month-end.ㅤ

FILTERING FINANCIAL REPORTS
The same report can answer different questions by changing parameters and filters.Users can change report dates, currencies, detail levels, financial dimensions, and other attributes.A finance manager might begin with a company-wide income statement and then filter the same structure to a specific business unit or another reporting period.This reduces the need to maintain separate spreadsheet versions for every department or management question.ㅤ

SCHEDULING AND MULTI-ENTITY REPORTING
Financial reports can be generated on recurring schedules such as daily, weekly, monthly, or annually.This can support regular management packs, budget reviews, period-close processes, and group reporting.Organizations operating several legal entities can also use Financial Reporting to create views spanning multiple companies and support reporting currency requirements while individual entities continue maintaining their own accounting records.ㅤ

REPORT RETENTION AND AUDIT COPIES
Generated financial reports have retention considerations. The script notes that newly generated reports receive a 90-day expiration date by default, which appropriately authorized users can modify.It also highlights an important consideration for historical reporting: when saved reports are rerun or users drill into their details, current transaction data can be used.Organizations requiring an immutable audit copy of a finalized reporting period should therefore export the finalized report to Excel or PDF and retain it according to their normal records-management process.ㅤ



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

Dynamics 365 General Ledger provides the central financial record behind Dynamics 365 Finance. Customer payments, supplier invoices, inventory movements, payroll, bank transactions, taxes, accruals, and other financial events ultimately affect the company's financial position, and the general ledger brings those accounting entries together in a structured and traceable way. In this episode of M365 FM, Mirko Peters explains the Dynamics 365 General Ledger in plain English, including the chart of accounts, financial dimensions, subledgers, posting profiles, vouchers, journals, allocations, tax, period close, and consolidation.ㅤ

WHAT IS THE GENERAL LEDGER IN DYNAMICS 365?
The general ledger is the company's master financial record. Instead of finance teams piecing together numbers from separate spreadsheets and systems, financial transactions come together in one consistent accounting structure.The ledger contains debit and credit entries organized into accounts such as cash, sales revenue, inventory, rent expense, and accounts payable. Every financial event has two sides, and total debits and credits must remain balanced.Dynamics 365 Finance maintains a ledger for each legal entity, allowing individual companies within a larger organization to maintain their own financial records, reporting responsibilities, currencies, and accounting periods.ㅤ

CHART OF ACCOUNTS EXPLAINED
The chart of accounts provides the structure used to organize financial transactions. Think of it as a financial filing cabinet where each main account represents a specific category.Cash, inventory, accounts payable, sales revenue, and rent expense are examples of main accounts. These accounts are grouped into categories used for financial statements.Assets, liabilities, and equity appear on the balance sheet, while revenue and expenses contribute to the income statement. Correct account structures therefore form the foundation for reliable financial reporting.ㅤ

FINANCIAL DIMENSIONS
A main account tells finance what happened, but organizations often need additional information about where or why it happened.Financial dimensions provide those additional labels. An organization might use dimensions for department, cost center, business unit, or location.A travel expense can therefore remain in one travel expense account while dimensions identify whether the cost belongs to Sales, Support, Finance, London, Berlin, or another organizational unit.This allows companies to analyze financial performance without creating hundreds of unnecessary main accounts.ㅤ

ACCOUNT STRUCTURES AND FINANCIAL CONTROLS
Dynamics 365 Finance can use account structures to control which combinations of main accounts and financial dimensions are permitted.For example, a travel expense might require both a department and cost center, while another account may require fewer dimensions.These rules help prevent incomplete or inconsistent financial information from reaching the ledger and improve the quality of reporting across the organization.ㅤ

GENERAL LEDGER VS SUBLEDGERS
The general ledger provides the overall accounting record, while subledgers maintain the detailed operational information behind specific types of transactions.Accounts Payable tracks vendor invoices and payments. Accounts Receivable tracks customer invoices and incoming payments. Inventory tracks stock movements and value, while Fixed Assets tracks long-term assets such as equipment, vehicles, and buildings.Tax and production processes can also maintain specialized details.These subledgers feed accounting entries into the general ledger, allowing operational teams to retain the detail they need while finance receives the accounting impact required for reporting.ㅤ

HOW POSTING PROFILES WORK
Employees processing normal business transactions shouldn't have to manually determine every debit and credit account.Dynamics 365 Finance uses posting profiles and related accounting rules to determine which main accounts should receive particular transactions.When Accounts Payable processes a vendor invoice, for example, posting rules can automatically direct the liability to the appropriate accounts payable account while the other side of the transaction is posted according to the underlying purchase or expense.This creates more consistent accounting than asking individual users to determine postings manually.ㅤ

VOUCHERS AND FINANCIAL TRACEABILITY
A voucher provides an important connection between source documents, subledger transactions, and the accounting entries appearing in the general ledger.If a finance manager sees an amount in an account and wants to understand where it came from, the voucher can help trace the financial posting back to the corresponding vendor invoice, product receipt, customer invoice, or other business event.This traceability works in both directions. Finance can move from the ledger toward the source document or from the original transaction toward its accounting impact.ㅤ

HOW A PURCHASE REACHES THE GENERAL LEDGER
The episode follows a practical example involving a company purchasing 100 office chairs.The process begins with a purchase order. When the chairs arrive, a product receipt confirms that the company has received them. If the chairs are worth $10,000, inventory can receive a $10,000 debit while purchase accrual receives the corresponding $10,000 credit.The purchase accrual acts as a temporary accounting position because the goods have arrived but the vendor invoice hasn't yet been processed.When the invoice arrives, Dynamics 365 can clear the temporary purchase accrual and record the $10,000 obligation in accounts payable.One purchase therefore creates connected operational and accounting records without repeatedly entering the same financial information.ㅤ

DOUBLE-ENTRY ACCOUNTING
Dynamics 365 Finance follows double-entry bookkeeping. Every financial posting needs balanced debit and credit entries.If $10,000 is debited to one side of a transaction, an equal $10,000 must be credited somewhere else.The accounts involved depend on the business event, but the fundamental principle remains the same: total debits and total credits must balance.This provides the accounting structure that keeps the company's financial records internally consistent.ㅤ

JOURNAL ENTRIES
Not every accounting transaction begins with a purchase order, customer invoice, or inventory movement. Finance teams sometimes need to create journal entries directly.Journals can be used for adjustments, accruals, corrections, or other financial events that originate within the finance function.For example, if electricity was consumed during March but the corresponding invoice won't arrive until April, finance can create an accrual so the expense is represented in the appropriate accounting period.ㅤ

FINANCIAL ALLOCATIONS
Allocations allow organizations to distribute costs across accounts, departments, cost centers, or other dimensions according to defined rules.A fixed allocation might distribute head-office rent 50% to Sales, 30% to Support, and 20% to Finance.Variable allocations can distribute costs according to changing measures. Warehouse expenses, for example, could be distributed according to how much each business unit actually used the warehouse.This helps organizations represent shared costs more accurately in management reporting.ㅤ

TAX MANAGEMENT
Dynamics 365 Finance uses sales tax codes to define how taxes should be calculated and posted.Tax requirements can differ between countries, regions, states, counties, and cities, so tax configuration provides structured rules instead of requiring users to manually calculate taxes for individual transactions.When tax requirements change, organizations can update the appropriate configuration rather than relying on individual employees to remember new calculations.ㅤ

FISCAL CALENDARS AND ACCOUNTING PERIODS
The fiscal calendar determines how an organization's financial year is divided into accounting periods.These periods are commonly months and provide the structure used for month-end, quarter-end, and year-end financial activities.Transactions need to be recorded in the correct period so finance teams can accurately understand what happened during a particular part of the financial year.ㅤ

YEAR-END CLOSING
At year-end, Dynamics 365 Finance supports the process of preparing financial accounts for the next fiscal year.Revenue and expense accounts represent activity during a particular year, so their completed result moves through the closing process into equity.Balance-sheet accounts behave differently. Cash, inventory, accounts payable, and similar balances carry forward because those assets and obligations continue to exist when the calendar moves into a new financial year.ㅤ

CONSOLIDATION ACROSS LEGAL ENTITIES
Larger organizations may operate multiple legal entities while still requiring a combined view of overall financial performance.Consolidation combines financial information from multiple companies into an organizational view while each underlying legal entity continues maintaining its own financial records.Organizations can therefore preserve separate company accounting while still producing consolidated financial information for the wider group.ㅤ

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

Dynamics 365 Autonomous Agents move AI beyond answering questions and generating content. Instead of waiting for someone to prompt them, autonomous agents can watch for specific business events, understand the context stored in Dynamics 365, choose between permitted actions, and continue a defined process within rules established by the organization. In this episode of M365 FM, Mirko Peters explains how autonomous agents differ from Copilot and traditional automation, where Microsoft is applying them across Dynamics 365, and why permissions, guardrails, approvals, and human oversight remain essential. ㅤ

WHAT ARE DYNAMICS 365 AUTONOMOUS AGENTS?
An autonomous agent is a specialized AI tool designed to perform a narrow business job. It can review business information, choose from allowed next steps, and carry out work toward a defined goal. The important word is defined. An autonomous agent isn't given unrestricted control of a business process. Organizations determine its job, the information it can access, the actions it can perform, and when it must involve a person. Think of it as a digital team member with a specific job description rather than a general-purpose AI system. ㅤ

COPILOT VS AUTONOMOUS AGENTS
Copilot typically waits for a person to request assistance. A user asks a question, requests information, generates a draft, or asks Copilot to summarize something. An autonomous agent works differently. It can react when something happens, such as a new customer case arriving, a customer sending another message, a new sales lead entering the system, or an order requiring confirmation. A useful analogy is an office building. Copilot works at the reception desk helping people who approach it, while autonomous agents work behind the scenes performing specific operational jobs. ㅤ

AUTONOMOUS AGENTS VS TRADITIONAL AUTOMATION
Traditional automation is extremely useful when processes follow predictable rules: if something happens, perform a predefined action. Agents add another layer by interpreting context. They can read customer messages, examine connected records, use approved knowledge, and select between actions their configuration permits. Generative AI provides the language understanding, while autonomous behavior connects that understanding to business actions. The agent might identify an issue, find relevant knowledge, update a record, prepare a response, or escalate the situation to a person. ㅤ

WHY DYNAMICS 365 DATA MATTERS
Generic AI can understand a sentence such as "my delivery still hasn't arrived," but it doesn't automatically know which customer, order, shipment, previous conversation, or support case that statement relates to. Dynamics 365 provides the business context. Customer records, cases, orders, sales leads, financial records, previous conversations, and other connected information allow an agent to understand the situation within the organization's actual business process. This context is what turns general AI capabilities into practical business assistance. ㅤ

CUSTOMER INTENT AGENT
Customer service provides some of the clearest examples of autonomous agents. The Customer Intent Agent can analyze customer conversations and cases to identify patterns in why customers are contacting an organization. Customer questions continually change as companies launch products, modify services, change delivery partners, or introduce new billing processes. The agent can help identify emerging topics instead of requiring managers to manually analyze hundreds of customer conversations. These insights can help organizations improve self-service experiences, knowledge content, and support processes. ㅤ
CASE MANAGEMENT AGENT
The Case Management Agent helps with routine activities across the customer service case lifecycle. It can assist with creating cases, updating information, progressing work toward resolution, following up, and closing cases according to the organization's configured processes. The objective isn't to remove customer service representatives. Instead, the agent can reduce repetitive administrative work surrounding cases so service professionals can spend more time understanding customer situations and handling exceptions. Organizations remain responsible for defining when cases require review, approval, or direct human intervention. ㅤ

CUSTOMER KNOWLEDGE MANAGEMENT AGENT
Useful support knowledge frequently becomes trapped inside closed cases, agent notes, and previous conversations. The Customer Knowledge Management Agent can examine completed case information to identify potentially reusable knowledge and gaps in existing support content. However, not everything contained within an old case should automatically become official guidance. A workaround may be outdated, customer-specific, or based on an exception. The agent can surface useful material while people determine what should become trusted organizational knowledge. ㅤ

SALES QUALIFICATION AGENT
Sales teams can receive large numbers of inbound leads with very different levels of potential. Researching every prospect and deciding where sellers should focus can consume significant amounts of time. The Sales Qualification Agent for Dynamics 365 Sales can help research and prioritize inbound leads and develop personalized sales emails to begin conversations. Salespeople still determine which opportunities deserve attention, review communications, contribute their own customer knowledge, and build the relationships required to actually close deals. ㅤ

SALES ORDER AGENT IN BUSINESS CENTRAL
Order processing provides another example of repetitive business work. Customer orders can arrive through email and other channels, requiring employees to interpret the request, enter information, verify details, and prepare confirmation. The Sales Order Agent in Dynamics 365 Business Central can support the order intake process from initial entry through confirmation. This reduces manual data entry while allowing people to concentrate on exceptions, unusual requests, and customer situations requiring judgment. ㅤ

FINANCIAL RECONCILIATION AGENTS
Finance teams perform substantial amounts of repetitive preparation and reconciliation work, particularly around financial period closing. The Financial Reconciliation Agent can assist with preparing and cleansing datasets used during period-close activities. The Account Reconciliation Agent in Dynamics 365 Finance can help match and clear transactions between subledgers and the general ledger. Accountants remain responsible for investigating discrepancies and determining whether the organization's financial information is correct. ㅤ

SUPPLIER COMMUNICATIONS AGENT
Procurement teams frequently spend time contacting suppliers to confirm purchase orders and expected delivery dates. The Supplier Communications Agent for Dynamics 365 Supply Chain Management can support this communication and help identify potential delivery delays earlier. Instead of procurement specialists manually chasing every routine confirmation, the agent can support standard follow-up while people concentrate on supplier relationships and problems requiring negotiation or intervention. ㅤ

SCHEDULING OPERATIONS AGENT
Field Service schedules rarely remain unchanged throughout the day. Traffic, cancellations, urgent jobs, and conflicting bookings can disrupt carefully planned technician schedules. The Scheduling Operations Agent for Dynamics 365 Field Service can help dispatchers adjust schedules as circumstances change. Dispatchers remain responsible for decisions involving customer priorities, difficult commitments, and other situations where business judgment matters. ㅤ

PERMISSIONS AND GUARDRAILS
The critical question isn't simply whether an autonomous agent can take action. Organizations need to determine exactly which actions it is permitted to take. Can the agent read a customer record? Can it update the record? Can it prepare an email? Can it send that email without approval? Can it recommend closing a case, or can it actually close one? Clear permissions and guardrails turn a broad AI capability into a controlled business process. Agents should only have access to the information and tools necessary for their assigned job. ㅤ

WHY HUMAN OVERSIGHT STILL MATTERS
Autonomous doesn't mean unsupervised. Agents can misunderstand customer requests, operate on incomplete information, or produce responses that don't fit a specific situation. Processes involving customer promises, financial transactions, exceptions, privacy, or consequential business decisions require appropriate human control. Organizations should review agent activity, analyze employee and customer feedback, inspect affected records, improve instructions and knowledge sources, and adjust permissions when necessary. ㅤ

HOW TO START WITH AUTONOMOUS AGENTS
A sensible first autonomous-agent project is a narrow, repetitive process where mistakes can be identified and corrected. Organizations might begin with drafting follow-up messages for review, sorting incoming requests, researching leads, or completing routine case information. Teams can then measure the results, improve instructions, refine permissions, and determine whether the agent should receive additional autonomy. Starting small provides an opportunity to understand how the agent behaves before connecting it to more consequential processes. ㅤ

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

Dynamics 365 Case Management gives customer service teams one central place to manage customer issues from the first contact through resolution. Instead of information being scattered across emails, calls, chats, notes, and separate systems, each customer problem becomes a structured case containing the issue, customer context, activities, ownership, priority, service commitments, and final resolution. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Customer Service uses cases, queues, routing, SLAs, knowledge articles, Copilot, entitlements, and automation to create a more consistent support experience. ㅤ

WHAT IS A CASE IN DYNAMICS 365?
A case represents one customer issue that requires an answer or resolution. It could be a damaged product, billing question, login problem, technical issue, or request for help. Customers can have multiple cases simultaneously because each problem is managed separately. Cases can be connected to contacts and accounts while recording information such as the subject, product, priority, case type, description, and responsible owner. This creates a single working record for the entire support issue rather than forcing agents to reconstruct the customer story from multiple systems. ㅤ

KEEPING THE COMPLETE CUSTOMER HISTORY TOGETHER
Emails, calls, notes, appointments, tasks, chats, and other activities can remain connected to the same case. When ownership changes, the next agent can understand what happened without asking the customer to explain everything again. This customer context becomes particularly important for complex cases involving several agents or previous troubleshooting attempts. The case shows the immediate problem while the broader customer record provides information about previous interactions, products, and support  history. ㅤ

ENTITLEMENTS AND CUSTOMER SUPPORT AGREEMENTS
Not every customer receives the same level of support. Dynamics 365 can use entitlements to represent the support terms associated with a customer. An entitlement might define warranty coverage, available support hours, permitted numbers of cases, or premium service conditions. Agents can therefore understand what support applies before committing resources or making promises to customers. ㅤ

KNOWLEDGE MANAGEMENT FOR FASTER RESOLUTION
Customer service teams frequently solve the same problems repeatedly. Dynamics 365 Knowledge Management allows organizations to maintain approved articles containing troubleshooting instructions, explanations, screenshots, standard answers, and other reusable support information. Agents can search these articles while working on cases instead of recreating solutions from memory. This can improve consistency and make organizational knowledge more accessible to less experienced support agents. ㅤ

COPILOT CASE SUMMARIES
Long-running cases can contain substantial amounts of information. Copilot can help agents understand that history by generating concise case summaries from information such as the customer, subject, product, priority, description, case type, and recent activities. The summary provides a faster starting point, particularly when a case changes ownership. Agents still review the underlying information and apply their own judgment before deciding what to do next. ㅤ

AUTOMATIC CASE CREATION
Customers can contact support through channels such as email, phone, chat, social media, and self-service portals. Dynamics 365 can use record creation rules to turn supported incoming communications into structured cases. For example, an email sent to a shared support address can automatically create a case rather than remaining unnoticed in a mailbox. Existing conversations can remain associated with their original cases while genuinely new problems receive separate records. ㅤ

QUEUES AND ROUTING
Once a case exists, it needs to reach the appropriate team. Dynamics 365 queues provide shared work areas where teams can manage incoming cases. Organizations might create separate queues for billing, technical support, returns, products, languages, regions, or different levels of urgency. Routing rules can evaluate information contained within a case and automatically direct it toward the appropriate queue or agent. Cases can also be manually reassigned when human judgment determines that a particular specialist is better suited to handle the problem. ㅤ

PARENT CASES, CHILD CASES AND DUPLICATES
Sometimes many customers report problems caused by the same underlying issue. Dynamics 365 can use parent and child cases to connect those individual customer reports to a larger problem. This allows teams to investigate the underlying issue centrally while maintaining individual customer records and communications. Duplicate cases can also be merged so multiple agents don't unknowingly work on the same problem. ㅤ

SERVICE LEVEL AGREEMENTS AND RESPONSE TIMES
Getting a case to the correct person isn't enough. Customers also expect organizations to meet agreed response and resolution times. Dynamics 365 Service Level Agreements, or SLAs, can attach time-based targets to cases. First-response targets measure how quickly the organization acknowledges the customer, while resolution targets measure how long the organization has to completely address the issue. Different support agreements, priorities, and case types can have different targets. Agents can see which cases are approaching deadlines, while alerts and escalation processes can help teams respond before service commitments are missed. ㅤ

BUSINESS PROCESS FLOWS FOR CONSISTENT SUPPORT
Business Process Flows provide agents with structured stages for handling cases. A process might move through intake, investigation, diagnosis, and resolution while requiring important information at each stage. This helps newer agents understand what information they need while providing experienced teams with a consistent process. Managers can also identify stages where cases frequently become delayed. ㅤ

RESOLVING AND REOPENING CASES
Sending an email doesn't automatically mean the customer's problem has been solved. Teams should record how the issue was resolved and then formally close the case. Resolution information creates useful history for future interactions. If the original solution doesn't work, the case can be reopened so the team continues with the existing history instead of creating another disconnected record. ㅤ

USING CASE DATA TO IMPROVE CUSTOMER SERVICE
Individual cases also become valuable operational data. Managers can analyze time to resolution, time spent in different stages, first-contact resolution, queue workloads, reopened cases, and recurring issue categories. Patterns can reveal broader problems. Increasing case volumes around one product could indicate a product issue, while repeated questions may indicate that documentation or knowledge articles need improvement. Case management therefore supports both individual customer service and continuous improvement across the support organization. ㅤ

CUSTOMER SELF-SERVICE
Some customers don't need direct assistance from an agent. Self-service experiences can allow customers to create requests, check case status, provide additional information, and access approved knowledge content themselves. This can reduce routine support demand while allowing customer service agents to concentrate on problems requiring investigation, explanation, or human judgment. ㅤ

MICROSOFT 365 AND POWER PLATFORM INTEGRATION
Dynamics 365 Case Management can work alongside familiar Microsoft technologies. Outlook can support email communication, Teams can help employees collaborate on difficult cases, SharePoint can manage related documents, Power BI can provide reporting and dashboards, and Power Platform can extend processes with additional forms and automation. The tools surrounding the process may change, but the Dynamics 365 case remains the central record connecting the customer problem, activities, ownership, service commitments, and resolution. ㅤ

THE KEY TAKEAWAY
Dynamics 365 Case Management isn't simply a ticketing system. It provides a structured lifecycle for customer issues from initial contact through routing, investigation, service commitments, knowledge, collaboration, resolution, and reporting. By keeping the customer, problem, communication history, support agreement, ownership, deadlines, and final answer connected to one record, customer service teams can reduce lost context, avoid duplicated work, and provide customers with a more consistent support experience. Subscribe to M365 FM for more Microsoft Knowledge Nuggets and Simply Explained episodes covering Dynamics 365, Microsoft 365, Power Platform, Copilot, AI, Azure, security, governance, and the Microsoft ecosystem.

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

Microsoft 365 licensing is often treated as a procurement problem: choose E3, E5, E7 or a collection of add-ons, assign the licenses, and move on. But licensing decisions directly influence security architecture, endpoint management, identity protection, and operational costs. In this episode of M365 FM, Mirko Peters talks with Videsh Chavan about building a unified Microsoft 365 strategy where licensing, Microsoft Intune, Microsoft Defender, identity, and endpoint security work together instead of operating as separate silos. ㅤ

MICROSOFT 365 LICENSING IS AN ARCHITECTURE DECISION
One of the central ideas of the conversation is that Microsoft 365 licensing shouldn't be treated purely as procurement. Organizations frequently purchase licenses without mapping the capabilities those licenses actually unlock. The result can be expensive features that nobody uses, duplicated security products, and security gaps that only become visible after an incident. Videsh recommends looking at licensing, Intune, Defender, and identity as parts of one connected architecture. Organizations should understand which capabilities they own, which capabilities they actually use, and where third-party products duplicate functionality already included in Microsoft licensing. ㅤ

A FIVE-STEP MICROSOFT 365 SECURITY FRAMEWORK
The discussion introduces a practical five-step approach for moving from disconnected Microsoft 365 tools toward a unified strategy. It starts with a licensing audit and capability mapping, followed by establishing an identity-first security baseline. Intune then becomes the enforcement layer, while Defender serves as the detection and response layer. The final component is continuous cost and coverage review, ensuring that licensing, security controls, and actual organizational requirements remain aligned. ㅤ

IDENTITY AS THE FOUNDATION OF MODERN SECURITY
As employees work from offices, homes, personal devices, mobile platforms, and Cloud PCs, the traditional corporate network becomes less useful as the primary security boundary. Identity therefore becomes a critical foundation. Users, groups, applications, connectors, access controls, and other resources depend heavily on identity. The conversation explores why organizations need strong identity controls, Conditional Access, MFA, and appropriate security guardrails as part of their Microsoft 365 architecture. ㅤ

AUDIT WHAT YOU ACTUALLY OWN
Before purchasing additional Microsoft security products, organizations should understand their existing entitlements. Videsh recommends inventorying assigned versus actively used licenses and mapping license tiers such as E3 and E5 against the Intune, Defender, identity, and security capabilities they unlock. This can expose features the organization already pays for but doesn't use. Regular reviews can also identify unused add-ons, capability gaps, and situations where upgrading or downgrading particular users makes more sense than applying the same licensing tier to everybody. ㅤ

WHY INTUNE IS MORE THAN MDM
Microsoft Intune has evolved far beyond traditional mobile device management. In the architecture discussed in this episode, Intune acts as an enforcement layer covering device configuration, application management, security policies, patching, provisioning, and endpoint security. Rather than maintaining large numbers of disconnected policies, organizations should consider structured security baselines and manageable policy architectures. The objective is to make endpoint management easier to understand, maintain, and continuously improve. ㅤ

WINDOWS AUTOPILOT AND ZERO-TOUCH PROVISIONING
Windows Autopilot fundamentally changes traditional corporate device provisioning. Instead of IT departments manually building and imaging every laptop before handing it to an employee, devices can be shipped directly from suppliers to users. The employee can unpack the device, connect it to the internet, authenticate, and allow organizational policies and configurations to provision the endpoint. This approach became particularly valuable as remote and hybrid work increased and organizations needed to onboard employees without requiring them to physically visit an office. ㅤ

INTUNE AS A SECURITY ENFORCEMENT LAYER
Intune increasingly sits at the intersection of endpoint management and cybersecurity. Security baselines, antivirus configurations, application policies, device configurations, and other endpoint controls can be centrally managed and enforced. This makes Intune an important part of the broader Microsoft security architecture rather than simply a tool for configuring laptops and smartphones. ㅤ

MICROSOFT DEFENDER AS DETECTION AND RESPONSE
Microsoft Defender represents a broader family of security capabilities rather than a single antivirus product. Organizations need to understand which Defender capabilities their licenses provide and how those capabilities fit into the wider endpoint security architecture. The episode discusses a practical security loop: detect suspicious activity, evaluate what happened, restrict the affected device or access when necessary, and restore normal operations after the problem has been addressed. Security teams remain responsible for investigating alerts and determining whether activity represents a genuine threat or a false positive. ㅤ

ZERO TRUST IS A STRATEGY, NOT A PRODUCT
Zero Trust isn't another Microsoft product organizations can simply purchase and enable. It is a cybersecurity strategy built around continuously verifying access instead of automatically trusting users, devices, or connections. Identity verification, application context, security controls, and least-privilege access all contribute to this model. Zero Trust therefore needs to influence architectural decisions across the organization rather than becoming another isolated security project. ㅤ

AI AND THE FUTURE OF ENDPOINT MANAGEMENT
AI introduces another layer to modern endpoint operations. Instead of waiting until users report that their device has a problem, telemetry and AI-assisted analysis can potentially identify deteriorating device health, recurring crashes, or other problems earlier. This creates an opportunity for more predictive and proactive IT operations. Videsh doesn't suggest handing endpoint management entirely to AI, but sees opportunities to shift some repetitive Level 1 activities toward AI-assisted operations while people remain responsible for more complex decisions. ㅤ

MODERNIZING A LARGE ENTERPRISE
For an enterprise operating Windows, macOS, iOS, Android, Windows 365, Active Directory, existing SCCM infrastructure, thousands of applications, BYOD, multiple Microsoft licensing tiers, and third-party security products, modernization should begin with discovery. Organizations need to understand their users, business requirements, existing technologies, licensing, regional restrictions, security requirements, and future use cases before redesigning the architecture. Modernization should then be controlled through documentation, peer review, architecture standards, and carefully managed implementation to minimize disruption. ㅤ

THE KEY TAKEAWAY
Microsoft 365 licensing, Intune, Defender, identity, Conditional Access, device health, and security policies shouldn't be managed as unrelated technologies. Together, they form a connected architecture in which identity and device signals influence access while Intune enforces policies and Defender provides detection and response. The starting point is understanding what the organization already owns and how those capabilities are being used. From there, organizations can identify security gaps, eliminate unnecessary licensing duplication, modernize endpoint management, and build a more coherent Microsoft 365 security strategy. As Mirko summarizes at the end of the conversation: licensing isn't simply procurement, Intune isn't simply device management, Defender isn't simply antivirus, and identity isn't simply a username and password.

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

Dynamics 365 Agents take AI beyond answering questions and generating drafts. Instead of waiting for someone to ask Copilot for help, agents can respond to defined business events, work with approved Dynamics 365 data, follow predefined rules, take permitted actions, and hand work to people when human judgment is required. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Agents work across sales, customer service, finance, supply chain, Business Central, Field Service, and Project Operations — and why permissions, guardrails, data quality, and human oversight are critical.
ㅤ
WHAT ARE DYNAMICS 365 AGENTS?
ㅤ
A Dynamics 365 Agent is AI configured to watch for a business event, understand approved information, follow defined rules, perform permitted actions, and report what happened.
The important difference is that an agent doesn't simply wait for a user to ask a question. A trigger such as a new lead, customer email, supplier response, order request, or financial mismatch can start the process automatically.
ㅤ
COPILOT VS DYNAMICS 365 AGENTS
ㅤ
Copilot typically works beside the user. You open a customer case and ask for a summary, request information, or generate a draft. The interaction begins because you asked Copilot to help.
An agent can continue working in the background according to its defined job. It can monitor an approved process, identify an event, collect relevant information, perform allowed actions, and escalate the work when necessary.
Think of Copilot as an assistant sitting beside you, while an agent is a specialized team member with a narrow job description, specific permissions, and clear rules.
ㅤ
HOW THE AI AGENT LOOP WORKS
ㅤ
The basic agent process can be understood as: notice, understand, act, check, and hand over.
The agent notices a defined event such as a new message or lead. It understands the situation using information and rules it has permission to access. It performs allowed actions, checks whether the result remains within its boundaries, and hands the work to a person when judgment or approval is required.
This creates supervised automation rather than unrestricted AI autonomy.
ㅤ
GUARDRAILS, PERMISSIONS AND HUMAN CONTROL
ㅤ
Guardrails define what an agent can see, change, create, or send. An organization might allow an agent to create a draft email but prevent it from sending that message automatically. An agent could categorize a customer case but be prevented from issuing a refund.
The same principle applies to supplier communication, financial transactions, customer promises, contracts, and other sensitive activities. The agent can prepare and route the work while people retain responsibility for higher-risk decisions.
ㅤ
DATAVERSE AND COPILOT STUDIO
ㅤ
Many Dynamics 365 applications use Microsoft Dataverse as the connected data foundation for customers, contacts, leads, cases, activities, products, and other business information.
For custom agents, Copilot Studio provides a place where organizations can define instructions, connect approved knowledge sources, configure actions, and determine how an agent should respond.
The quality of these agents depends heavily on the quality of the underlying data and processes.
ㅤ
SALES QUALIFICATION AGENTS
ㅤ
Sales agents can help close the gap between incoming interest and seller follow-up. A Sales Qualification Agent can research incoming leads, compare them against criteria established by the sales organization, prioritize potential opportunities, and prepare personalized outreach.
Instead of sellers spending significant time performing the first round of research for every new lead, the agent can prepare information while the salesperson decides whether the prospect deserves further attention.
ㅤ
SALES RESEARCH AND OPPORTUNITY AGENTS
ㅤ
Sales Research Agents can gather approved information before customer conversations, helping sellers understand companies, previous interactions, existing opportunities, and relevant account context.
Opportunity Agents operate later in the sales process. They can research active opportunities, surface deal context, identify potential risks, and highlight opportunities requiring attention.
Sales Close Agents can support the final stages through follow-ups, customer engagement, product suggestions, and handling common objections within defined business rules.
ㅤ
CUSTOMER SERVICE AGENTS
ㅤ
Dynamics 365 Customer Service Agents can reduce repetitive administrative work around customer cases. A Case Management Agent can interpret incoming customer communications, create cases, extract useful details, associate customers, and route cases appropriately.
Customer Intent Agents can identify why customers are contacting the organization and help direct requests toward appropriate queues, answers, or service representatives.
This can reduce the time agents spend manually creating and categorizing cases before they can begin solving the customer's actual problem.
ㅤ
KNOWLEDGE MANAGEMENT AND QUALITY AGENTS
ㅤ
A Customer Knowledge Management Agent can analyze completed cases to identify gaps in an organization's knowledge base and help prepare draft knowledge articles for human review.
Quality Evaluation Agents can evaluate larger numbers of customer interactions against standards established by service supervisors. This can help managers identify patterns and coaching opportunities without depending entirely on manually selected samples.
ㅤ
BUSINESS CENTRAL SALES ORDER AGENTS
ㅤ
In Dynamics 365 Business Central, a Sales Order Agent can process incoming customer order requests. It can read an order request received through email, identify the customer, extract requested products and quantities, and prepare order information for review.
People remain responsible for exceptions such as unusual pricing, missing products, incorrect customer information, or orders that don't match established patterns.
ㅤ
SUPPLY CHAIN AND SUPPLIER AGENTS
ㅤ
The Supplier Communications Agent in Dynamics 365 Supply Chain Management can support repetitive supplier follow-up activities.
It can request purchase order confirmations, ask suppliers for delivery updates, process incoming supplier communications, and associate responses with relevant orders. If a supplier reports a significant delay or another situation requiring a business decision, the agent can escalate the issue to a buyer or planner.
ㅤ
FINANCE AND RECONCILIATION AGENTS
ㅤ
Finance agents can support repetitive reconciliation work. An Account Reconciliation Agent can compare transactions and identify records that should match but don't, helping finance teams discover discrepancies earlier.
Financial Reconciliation Agents can support preparation and cleanup of information required for reconciliation and financial reporting. Accountants still determine what discrepancies mean and approve the appropriate resolution.
ㅤ
FIELD SERVICE AND PROJECT OPERATIONS AGENTS
ㅤ
Dynamics 365 Field Service can use scheduling-focused agents to help optimize technician schedules when appointments, availability, priorities, or other conditions change.
Project Operations can use agents to support administrative activities such as preparing time entries, processing expense information, and reviewing time, expense, and material records against organizational policies.
These capabilities target repetitive administrative work while keeping people responsible for exceptions and consequential decisions.
ㅤ
WHY DATA QUALITY MATTERS
ㅤ
An AI agent can only work with the information available to it. Duplicate customers, incomplete product records, outdated supplier contacts, and inconsistent business data can quickly reduce the reliability of automated processes.
Automation doesn't transform poor data into good decisions. Organizations need clean and consistent records before expecting agents to reliably connect incoming information with the correct customers, orders, cases, or suppliers.
ㅤ
HOW TO START WITH DYNAMICS 365 AGENTS
ㅤ
Start with one repetitive process that has clear steps, clear ownership, and a measurable result. Define what triggers the process, which records the agent can access, which actions it can perform, which actions require approval, and exactly when the agent must stop and involve a person.
Testing should include normal situations as well as difficult exceptions. Organizations should inspect what the agent reads, prepares, changes, and escalates before expanding its permissions or applying the approach to additional processes.
ㅤ
THE KEY TAKEAWAY
ㅤ
Dynamics 365 Agents turn repetitive business processes into supervised AI-powered actions. They can respond to events, understand approved business information, execute defined tasks, and escalate exceptions across sales, customer service, finance, operations, supply chain, and project workflows.
The objective isn't to give AI control of an entire department. Start with one clearly defined queue or process, establish permissions and guardrails, measure the result, and expand only after the process proves reliable.
An agent can only perform as well as the process, data, rules, and boundaries you give it.
Subscribe to M365 FM for more Microsoft Knowledge Nuggets and Simply Explained episodes covering Dynamics 365, Microsoft 365, Power Platform, Copilot, AI Agents, Azure, security, governance, and the Microsoft ecosystem.


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

Dynamics 365 Copilot brings AI directly into the business processes and records people already use across Dynamics 365. Instead of spending time searching through customer histories, sales opportunities, support cases, invoices, orders, emails, and reports, Copilot can summarize information, answer questions, prepare drafts, and help users determine what to do next. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Copilot works across sales, customer service, finance, operations, and Business Central — and why human approval remains essential when AI becomes part of business processes.
ㅤ
WHAT IS DYNAMICS 365 COPILOT?
ㅤ
Dynamics 365 Copilot is a collection of AI capabilities integrated into Dynamics 365 applications. Rather than replacing Dynamics 365, Copilot works with the business information users already have permission to access.
Dynamics 365 remains the system containing business records such as customers, opportunities, cases, invoices, orders, inventory, and suppliers. Copilot helps users understand and work with that information faster.
ㅤ
HOW DYNAMICS 365 COPILOT WORKS
ㅤ
Much of Copilot's everyday assistance falls into three areas: summarizing information, answering questions about business data, and preparing drafts or proposed actions.
A Dynamics 365 record can contain months of activities, notes, emails, meetings, changes, and other information. Copilot can summarize that history into a more manageable overview. Users can also ask questions using natural language rather than navigating through multiple screens and reports to locate information.
ㅤ
DYNAMICS 365 COPILOT VS MICROSOFT 365 COPILOT
ㅤ
Dynamics 365 Copilot and Microsoft 365 Copilot serve related but different purposes. Dynamics 365 Copilot operates close to business processes and records inside Dynamics 365 applications.
Microsoft 365 Copilot operates primarily across productivity applications such as Outlook, Teams, Word, and Excel. The two can work together, bringing business context into everyday communication, meetings, and document workflows.
ㅤ
COPILOT VS AI AGENTS
ㅤ
Copilot generally helps users understand information, ask questions, prepare drafts, and make decisions. AI agents can go further by performing defined pieces of work according to rules established by the organization.
Agents can support repeatable processes such as researching leads, preparing records, processing incoming information, or handling routine workflow steps. However, these agents still require clear boundaries, permissions, and human oversight.
ㅤ
COPILOT IN DYNAMICS 365 SALES
ㅤ
Dynamics 365 Sales Copilot can help sellers prepare for customer conversations by summarizing leads, accounts, opportunities, recent activities, and other relevant information.
Before a meeting, sellers can quickly understand what changed with an opportunity, review previous interactions, and identify information requiring attention. Copilot can also summarize email conversations and prepare draft responses, reducing the time required to reconstruct customer context manually.
ㅤ
AI AGENTS FOR SALES
ㅤ
Dynamics 365 can extend sales assistance through task-focused agents covering areas such as lead qualification, opportunity research, and sales closing activities.
For example, a qualification agent can research an incoming lead, collect relevant information, and help determine whether the prospect fits the organization's sales criteria. These capabilities can reduce repetitive work while allowing sellers to concentrate on higher-value customer conversations.
ㅤ
COPILOT IN DYNAMICS 365 CUSTOMER SERVICE
ㅤ
Customer service teams frequently work with cases containing long histories of emails, conversations, activities, and previous actions. Copilot can summarize this information so an agent taking over a case can quickly understand the customer's problem and what has already happened.
Copilot can also help draft customer responses, summarize conversations, and surface relevant knowledge content. This can help agents find approved guidance without manually searching through extensive knowledge libraries.
ㅤ
COPILOT FOR FINANCE AND OPERATIONS
ㅤ
Dynamics 365 Finance and Operations users often work with complex business records, approvals, invoices, suppliers, purchase orders, inventory, and workflow histories.
Copilot can help summarize processes and answer questions about structured business information using natural language. Instead of manually reviewing every workflow event, users can receive a concise explanation of where a process currently stands and what may require attention.
ㅤ
COPILOT IN BUSINESS CENTRAL
ㅤ
Microsoft Dynamics 365 Business Central also includes Copilot capabilities for finance, sales, and operational processes. Users can summarize customers, vendors, items, and sales orders or generate initial product marketing descriptions from existing item information.
Copilot can also assist with tasks involving matching and reconciliation, such as identifying possible matches between electronic vendor invoice lines and purchase orders or helping identify potential matches during bank reconciliation.
ㅤ
AI AGENTS IN BUSINESS CENTRAL AND SUPPLY CHAIN
ㅤ
Agents extend AI assistance into more defined operational workflows. A Sales Order Agent can analyze customer requests arriving through email and help prepare corresponding sales order information.
A Payables Agent can work with vendor invoices and prepare invoice drafts for review, while supplier-focused agents can support repetitive communication processes in supply chain operations.
These agents can automate parts of routine work, but people remain responsible for reviewing exceptions and approving actions affecting customers, inventory, payments, and other important business processes.
ㅤ
DATA SECURITY AND PERMISSIONS
ㅤ
Copilot doesn't provide unrestricted access to every Dynamics 365 record. Its access follows the permissions of the signed-in user. If a user cannot access particular business information, Copilot should not make that restricted information available simply because the user asks for it.
Dataverse plays an important role behind many Dynamics 365 applications by storing structured business information and supporting the access controls governing those records.
ㅤ
WHY HUMAN APPROVAL STILL MATTERS
ㅤ
Generative AI can summarize information and prepare useful drafts, but it can also misunderstand context, miss details, or generate inappropriate recommendations.
Customer communications, refunds, payments, contracts, business policies, and other consequential decisions should therefore remain subject to human review. Copilot can prepare information and reduce repetitive work, but the person approving an action remains responsible for the outcome.
ㅤ
THE KEY TAKEAWAY
ㅤ
Dynamics 365 Copilot brings AI closer to the business records where everyday work happens. Across Dynamics 365 Sales, Customer Service, Finance, Operations, and Business Central, it can reduce the time people spend searching, reading long histories, preparing drafts, and completing repetitive tasks.
The goal isn't to let AI run the business. Copilot provides context, drafts, summaries, and assistance while AI agents handle clearly defined tasks. People remain responsible for the decisions, customer promises, approvals, and exceptions that matter.
Subscribe to M365 FM for more Microsoft Knowledge Nuggets and Simply Explained episodes covering Dynamics 365, Microsoft 365, Power Platform, Azure, Copilot, AI, security, governance, and the Microsoft ecosystem.


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

Dynamics 365 Opportunity Management gives sales teams a structured way to manage serious sales conversations from the first qualified interest through to a clear outcome: won or lost. Instead of keeping deal information across spreadsheets, emails, personal notes, and individual inboxes, Dynamics 365 Sales creates a shared opportunity record containing the customer, expected revenue, products, activities, probability, expected close date, ownership, and sales history. In this episode of M365 FM, Mirko Peters explains how opportunities work and how they connect the entire sales process.
ㅤ
WHAT IS AN OPPORTUNITY IN DYNAMICS 365?
ㅤ
A lead represents early interest, while an opportunity represents a potential sale with enough information to manage as a real sales conversation. An opportunity connects the possible deal to an account or contact and records what the customer might buy, how much the deal could be worth, who owns it, and when it could close.
Think of an opportunity as a shared deal folder. Every serious buying conversation can have its own opportunity, even when multiple opportunities belong to the same customer.
ㅤ
HOW OPPORTUNITIES ENTER DYNAMICS 365 SALES
ㅤ
Many opportunities begin as leads. When a lead develops into a genuine buying conversation, the seller can qualify it and Dynamics 365 creates an opportunity while maintaining the connection to the original lead information.
Opportunities can also be created directly. Existing customers may request additional products or services, partners may introduce potential buyers, or account managers may discover expansion and renewal opportunities during customer conversations.
ㅤ
THE FOUR SALES PIPELINE STAGES
ㅤ
Dynamics 365 Sales uses a Business Process Flow to guide opportunities through four standard stages: Qualify, Develop, Propose, and Close.
During Qualify, sellers establish important facts such as the customer, timeframe, potential budget, purchasing process, and decision maker. Develop focuses on understanding customer needs, identifying stakeholders and competitors, and defining the proposed solution.
During Propose, the sales team develops and reviews the proposal before presenting it to the customer. Close represents the final stage of the buying conversation, where the final proposal, expected decision date, and outcome become increasingly clear.
ㅤ
BUILDING AN OPPORTUNITY RECORD YOU CAN TRUST
ㅤ
The opportunity record becomes the central workspace for managing the deal. Estimated revenue shows how much the opportunity could generate, while the potential close date indicates when the customer is expected to make a decision.
Probability provides additional context about the team's confidence in winning the opportunity. These values should change whenever the customer situation changes. Accurate opportunity information is essential because these records ultimately influence sales pipeline reporting and forecasting.
ㅤ
PRODUCTS, PRICING AND REVENUE
ㅤ
Opportunities can contain individual product line items representing what the customer may purchase. A software opportunity might include licenses, implementation services, training, and additional support.
Products can include quantities, prices, and discounts, allowing expected revenue to reflect the actual proposed solution rather than simply an estimated number. Dynamics 365 also maintains consistent currency between the opportunity and its related product records.
ㅤ
ACTIVITIES, NOTES AND OWNERSHIP
ㅤ
Sales opportunities aren't only about numbers. Calls, emails, meetings, tasks, and notes provide the context behind the deal. Recording these activities helps everyone understand what happened with the customer and what needs to happen next.
Each opportunity also has an owner responsible for keeping the sales conversation moving. Other specialists and managers can participate, but clear ownership prevents important actions from disappearing between team members.
ㅤ
WHY OPPORTUNITY DATA MATTERS FOR FORECASTING
ㅤ
Opportunity values and expected close dates contribute directly to the organization's view of potential future revenue. Outdated opportunity information therefore creates misleading forecasts.
If a customer moves their decision from June to September, the opportunity should reflect that immediately. Keeping an old close date doesn't make the deal happen sooner; it simply gives sales management an inaccurate picture of the pipeline.
ㅤ
CLOSING OPPORTUNITIES AS WON OR LOST
ㅤ
Every opportunity should eventually reach a clear outcome. When the customer buys, the opportunity is closed as Won. When the customer decides not to proceed, it should be closed as Lost.
Closing opportunities properly removes completed deals from the active pipeline while preserving their history inside Dynamics 365. Won opportunities show how successful deals developed, while lost opportunities can provide useful information about competitors, budget problems, delayed projects, or other reasons customers decided not to buy.
ㅤ
LEARNING FROM LOST OPPORTUNITIES
ㅤ
A lost opportunity still contains valuable sales intelligence. Recording meaningful loss reasons can help sales managers identify patterns across multiple deals.
If several customers select the same competitor, postpone projects, or raise similar pricing concerns, leadership gains evidence that can inform future sales conversations, positioning, and strategy. Leaving unsuccessful opportunities permanently open hides these signals and artificially inflates the pipeline.
ㅤ
KEEPING THE SALES PIPELINE HONEST
ㅤ
Good opportunity management depends on continuously updating the record as the customer conversation changes. Sellers should update expected revenue, probability, decision dates, products, stakeholders, competitors, and activities when new information becomes available.
When customers say yes, opportunities should be closed as Won. When customers say no, they should be closed as Lost. Deals shouldn't remain open simply because the sales team hopes circumstances might change.
ㅤ
THE KEY TAKEAWAY
ㅤ
Dynamics 365 Opportunity Management gives every serious sales conversation a structured home. From lead qualification and pipeline stages to products, revenue, activities, forecasting, and the final outcome, the opportunity record creates a shared picture of what is actually happening with the customer.
Keep the deal record current and Dynamics 365 can provide sellers, managers, and leadership with a much more reliable view of the sales pipeline and potential future revenue.
Subscribe to M365 FM for more Microsoft Knowledge Nuggets and Simply Explained episodes covering Dynamics 365, Microsoft 365, Power Platform, Azure, Copilot, AI, security, governance, and the Microsoft ecosystem.


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

Dynamics 365 Knowledge Management helps customer service teams create a single, trusted source of knowledge that agents can use while supporting customers. Instead of searching through old emails, shared folders, spreadsheets, or relying on individual experience, teams can create approved knowledge articles that provide consistent answers across customer service channels. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Knowledge Management works and why a structured knowledge base can improve both agent productivity and the customer experience.
ㅤ
WHY CUSTOMER SERVICE TEAMS NEED KNOWLEDGE MANAGEMENT
ㅤ
Customer service teams accumulate knowledge quickly, but that knowledge is often scattered across documents, inboxes, shared folders, and individual employees. This makes it difficult for agents to find reliable information when customers need an immediate answer. Dynamics 365 Knowledge Management creates a shared knowledge base where approved information can be stored, maintained, and accessed by the entire support organization.
A centralized knowledge base also helps organizations provide more consistent customer service. Whether customers contact a company through phone, email, chat, or self-service, agents can work from the same approved information instead of creating their own answers.
ㅤ
WHAT IS DYNAMICS 365 KNOWLEDGE MANAGEMENT?
ㅤ
Dynamics 365 Knowledge Management provides teams with a central place to create, organize, review, search, publish, and improve knowledge articles. These articles can contain answers to common customer questions, troubleshooting instructions, internal procedures, policies, links, screenshots, and step-by-step guidance.
Knowledge is integrated into the Dynamics 365 Customer Service environment, allowing agents to search for relevant information while working on customer cases. Instead of switching between multiple applications and repositories, agents can access approved guidance directly within their customer service workflow.
ㅤ
CREATING EFFECTIVE KNOWLEDGE ARTICLES
ㅤ
A useful knowledge article starts with a real customer or agent problem. Clear titles, relevant keywords, categories, and straightforward language make articles easier to discover. Articles should provide the main answer quickly and then explain the necessary steps in the order agents or customers need to follow them.
Organizations can also connect related articles and organize knowledge around subjects such as billing, account access, delivery, returns, or product support. Using terminology that customers actually use can significantly improve knowledge search and discovery.
ㅤ
KNOWLEDGE ARTICLE REVIEW AND APPROVAL
ㅤ
Creating an article is only the beginning. Knowledge should be reviewed by appropriate subject matter experts before it becomes trusted guidance. Approval processes help ensure that instructions follow company policies, security requirements, and operational procedures.
After approval, articles can be published for the appropriate audience. Some knowledge should remain available only to employees, while other articles can be made available through customer self-service experiences.
ㅤ
SEARCHING KNOWLEDGE INSIDE DYNAMICS 365
ㅤ
Agents can search the knowledge base while working with customer cases in Dynamics 365 Customer Service. Search can use article titles, content, categories, labels, and other information to identify relevant guidance.
Dynamics 365 can also suggest articles based on information contained within a case. These suggestions help narrow the search, while the agent still determines whether the article actually applies to the customer's situation.
ㅤ
INTERNAL KNOWLEDGE AND CUSTOMER SELF-SERVICE
ㅤ
Not every knowledge article should be public. Internal articles can contain procedures, escalation instructions, account checks, and information intended specifically for employees. Customer-facing articles can provide safe, simplified instructions that customers can follow themselves.
This allows organizations to use the same overall knowledge management approach for both assisted customer service and self-service while maintaining appropriate access to internal information.
ㅤ
KEEPING KNOWLEDGE ACCURATE AND CURRENT
ㅤ
Knowledge management requires continuous maintenance. Products change, policies are updated, processes evolve, and application interfaces can change. Without regular reviews, previously correct knowledge can eventually become outdated.
Assigning article ownership, defining review processes, managing permissions, and collecting feedback help keep the knowledge base reliable. Search misses and repeated support cases can also reveal where articles are missing, difficult to find, or need improvement.
ㅤ
HOW KNOWLEDGE MANAGEMENT IMPROVES CUSTOMER SERVICE
ㅤ
A well-managed Dynamics 365 knowledge base can reduce the time agents spend searching for information and decrease their dependence on experienced colleagues. New employees gain access to established organizational knowledge, while experienced agents spend less time repeatedly answering the same questions.
Customers benefit from faster and more consistent answers. Self-service knowledge can also help customers solve common problems before they need to contact the service team.
ㅤ
A PRACTICAL DYNAMICS 365 KNOWLEDGE MANAGEMENT EXAMPLE
ㅤ
The episode follows practical customer service scenarios including billing questions and password-reset problems. An agent can search for an approved article, follow a structured checklist, explain the correct next steps to the customer, and escalate the case when necessary.
Agent feedback can then improve the article for future cases. In this way, every support interaction can potentially identify missing information and contribute to a stronger organizational knowledge base.
ㅤ
THE KEY TAKEAWAY
ㅤ
Dynamics 365 Knowledge Management turns scattered support information into a structured and reusable source of trusted guidance. By combining knowledge articles, search, approval workflows, permissions, self-service, feedback, and ongoing review, organizations can make useful knowledge available exactly where customer service teams need it.
The goal isn't simply to create more documentation. It's to make accurate, current, and easy-to-find answers available to agents and customers when they need them.
Subscribe to M365 FM for more Microsoft Knowledge Nuggets and Simply Explained episodes covering Dynamics 365, Microsoft 365, Power Platform, Azure, Copilot, AI, security, governance, and the Microsoft ecosystem.


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

A customer starts a website chat because an order has not arrived. They explain the problem, provide the order number, and answer several questions. Later, they call the company—and the person on the phone asks them to explain everything again. For the customer, this makes little sense. They did not start a new problem. They simply changed the way they contacted the company. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Microsoft Dynamics 365 Omnichannel in plain English and shows how organizations can connect customer conversations across chat, voice, SMS, social messaging, and other service channels. We explore the unified agent workspace, customer identification, queues, Unified Routing, skills-based routing, agent presence, capacity, transfers, consultations, knowledge articles, quick replies, Copilot, Smart Assist, sentiment analysis, customer history, cases, transcripts, and supervisor analytics. The central idea is simple: customers can enter through many different doors, while agents work from one connected customer service desk.

WHY SEPARATE CUSTOMER SERVICE CHANNELS CREATE PROBLEMS
Traditional customer service often treats every communication channel as a separate system. Website chats appear in one application. Emails arrive in a shared mailbox. Calls are handled through another platform. Social messages may even be managed by a completely different department. Each system may work perfectly well individually, but the customer's story becomes fragmented. An agent answering the phone may not know that the customer already spent twenty minutes chatting with another employee earlier that day. The result is repetition, longer handling times, unnecessary searching, and frustrated customers. Dynamics 365 Omnichannel attempts to connect those pieces into a more consistent service experience.

WHAT IS DYNAMICS 365 OMNICHANNEL?
Think of Dynamics 365 Omnichannel as an office building with several front doors but one reception desk. Customers can enter through different communication channels. One person might use website chat. Another calls. Another sends a text message. Another contacts the organization through a supported social messaging channel. Behind those different entry points, Dynamics 365 provides a common customer service environment. The channel still matters because a live telephone call behaves differently from an asynchronous text conversation. But agents do not necessarily need completely separate working environments for every channel.

THE UNIFIED AGENT WORKSPACE
The agent workspace is where customer conversations come together. Instead of switching continually between a chat application, telephone system, CRM, knowledge base, and customer records, agents can work with conversations alongside relevant Dynamics 365 information. Each active piece of work can appear as a session or conversation. An agent might handle one customer chat and later move to another session without losing the original context. The workspace can also provide access to customer details, previous cases, activities, knowledge, notes, and other service information. This changes the agent's starting point from: "Can you explain everything again?" to: "I can see your previous interaction. Let's continue from there."

IDENTIFYING THE CUSTOMER
Connected customer history depends on knowing who the customer is. Sometimes Dynamics 365 already knows. For example, a customer may begin a conversation while authenticated through a connected customer experience. In other situations, somebody starts as an unknown website visitor. The agent can then request information such as an email address or order number and search for an existing contact. Once the conversation is associated with the correct customer or case, the transcript, notes, activities, and related service work can contribute to that customer's history. Customer identification is therefore an important part of making omnichannel actually feel connected.

CASES KEEP CUSTOMER ISSUES TOGETHER
Some questions can be solved during a single conversation. Others require follow-up. A case provides a structured Dynamics 365 record for an issue that needs to be tracked until resolution. Imagine a customer contacts support about a missing delivery. The initial chat does not solve the problem because another department needs to investigate. The agent creates or associates a case. When another employee later works on the issue, they can open that case and review the information already collected. The customer problem now has a persistent home instead of existing only inside one temporary conversation. 

ROUTING: GETTING CUSTOMERS TO THE RIGHT TEAM
A unified workspace is useful only when customer requests reach appropriate employees. This is where routing becomes important. Dynamics 365 can place incoming work into queues representing different areas of responsibility. An organization might have queues for: Billing, deliveries, technical support, sales, or another service function. Routing rules can use information collected from the customer to determine where the conversation belongs. A billing question can go toward billing. A delivery problem can go toward the delivery team. The customer does not need to understand the queue architecture. They simply describe what they need.

SKILLS-BASED ROUTING
Being available does not automatically make somebody the correct agent. A customer may need assistance in German. Another customer may require an employee who understands a particular product. Another request may require specialized account knowledge. Dynamics 365 can use skills to describe what agents can handle and match those capabilities with customer requirements. Instead of routing work only according to who happens to be free, the system can consider whether the employee is actually suitable for the conversation. This can reduce transfers and improve the chance that the first agent receiving the request can help.

PRESENCE AND AGENT CAPACITY
The correct agent also needs to be available. Presence indicates whether an employee is available, busy, away, offline, or in another configured state. Capacity helps represent how much work that employee can handle. A voice call may require almost complete attention. Messaging conversations can behave differently because customers frequently pause between messages. An organization can therefore define workload rules appropriate to its service model. This helps avoid situations where one qualified employee receives conversation after conversation while another suitable agent remains available.

TRANSFERS VS CONSULTATIONS
Sometimes a conversation reaches the wrong team. An agent discovers that a customer actually needs billing rather than technical support. In that situation, the conversation can be transferred to another appropriate queue or person. But not every specialist question requires transferring the customer. A consultation allows the original agent to involve another employee for assistance while remaining responsible for the customer conversation. Instead of saying: "I'll transfer you." the agent can effectively say: "I'm checking this with our specialist." That distinction can reduce unnecessary handoffs and provide customers with a more continuous service experience. 

KNOWLEDGE ARTICLES AND QUICK REPLIES
#Agents answer many similar questions every day. How do I reset my password? How do I return an item? Where can I download an invoice? What does this error message mean? Knowledge search allows employees to find approved information while the customer conversation remains open. Agents can use the article to guide their answer and, where appropriate, provide relevant information to the customer. Quick replies provide another productivity tool. Frequently used messages can be prepared in advance so employees do not need to type identical responses repeatedly. The agent still needs to review the response and make sure it actually fits the customer's situation.

COPILOT AND SMART ASSIST
AI capabilities can provide additional assistance where the organization has enabled them. Smart Assist can surface potentially useful knowledge articles, related information, or guidance. Copilot can help summarize longer conversations and, depending on the configured capabilities, assist with suggested responses. Imagine a customer spending ten minutes interacting before reaching a human agent. Instead of forcing the agent to read the complete conversation before understanding the problem, a summary can provide a faster overview of what the customer requested and what has already happened. These capabilities support the agent. They do not remove the need for review. The employee remains responsible for making sure information provided to the customer is appropriate and accurate. 

VOICE, TRANSCRIPTION AND SENTIMENT
Voice scenarios can also include additional assistance. When supported voice capabilities are configured, live transcription can convert spoken conversation into text. This can help agents review product numbers, customer concerns, or commitments made during a call. Sentiment signals can provide another indicator. If a conversation appears increasingly negative, the agent may decide to slow down, clarify the problem, or acknowledge the customer's frustration more explicitly. But sentiment should not be treated as a definitive interpretation of someone's emotions. Sarcasm, language differences, communication style, and context can all affect the signal. Sentiment is therefore best treated as another piece of information—not a verdict about the customer. 

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

A Dynamics 365 Sales opportunity can look healthy on paper. The deal is still open, the estimated close date is in the future, and the timeline contains emails, meetings, calls, and tasks. But there is a much more important question: Is the customer still talking to you? A salesperson may have sent several emails without receiving a response. The last customer meeting may have happened weeks ago. Another employee inside the company may already know an important decision-maker, but the salesperson has no idea that relationship exists. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Microsoft Dynamics 365 Relationship Intelligence in plain English and explores how Dynamics 365 Sales can turn everyday customer communication into useful relationship signals. We look at Relationship Analytics, Relationship Health, Who Knows Whom, Microsoft Exchange integration, communication activity, response times, engagement, customer sentiment, similar opportunities, warm introductions, opportunity management, and sales pipeline prioritization. The goal is not to let Dynamics 365 decide whether a deal will close. The goal is to give sellers better context for deciding which customer relationship needs attention and what conversation should happen next.

THE HIDDEN PROBLEM INSIDE CRM DATA
A CRM system can contain enormous amounts of customer information. Contacts. Accounts. Opportunities. Activities. Emails. Tasks. Meeting notes. Phone calls. But having information does not automatically mean understanding the relationship. A salesperson can open an opportunity containing ten recent activities and assume the deal is moving forward. But what if nine of those activities came from the salesperson? What if the customer stopped replying? What if no future meeting is scheduled? What if the last meaningful conversation happened a month ago? The CRM record may look active while the actual customer relationship has become quiet. Relationship Intelligence attempts to expose that difference.

ACTIVITY DOES NOT AUTOMATICALLY MEAN ENGAGEMENT
One of the most important ideas behind Relationship Intelligence is that activity needs context. Ten unanswered emails do not necessarily represent a strong relationship. Several internal tasks do not mean the customer is engaged. A large number of activities may simply mean the salesperson has been busy. By contrast, one meaningful conversation with the right decision-maker may move an opportunity significantly further than dozens of unanswered messages. Relationship Intelligence therefore looks beyond the existence of activities and helps sellers understand the communication patterns behind them. Is communication recent? Is the customer responding? Are both sides participating? Has the relationship suddenly become quiet? Those questions can reveal considerably more than a simple activity count.

WHAT IS DYNAMICS 365 RELATIONSHIP INTELLIGENCE?
Think of Relationship Intelligence as a relationship radar inside Dynamics 365 Sales. It brings together communication signals associated with leads, contacts, accounts, and opportunities and turns them into information sellers can use while working inside Dynamics 365. The supplied episode focuses on two major capabilities. The first is Relationship Analytics and Relationship Health. These capabilities help sellers understand communication patterns and identify relationships that may require attention. The second is Who Knows Whom. This capability helps identify colleagues inside the organization who may already know a lead or contact the seller wants to reach. Together, these capabilities answer two different but related questions: How healthy is the relationship we already have? and Who inside our organization can help us create a new relationship?

RELATIONSHIP ANALYTICS
Relationship Analytics takes activities associated with a sales record and transforms them into a communication picture that is easier to interpret. Instead of manually opening every email, appointment, and call, sellers can examine the overall pattern. Relationship Analytics can be relevant across contacts, accounts, leads, and opportunities. Each provides a slightly different perspective. A contact focuses on the relationship with an individual person. An account provides a broader view of communication with the customer organization. A lead can show whether an early sales conversation remains active. An opportunity connects communication signals with a potential deal. The purpose is not to reduce the relationship to a number. It is to help sellers notice communication patterns that deserve closer investigation.

BASIC RELATIONSHIP INSIGHTS
The episode distinguishes between Basic Relationship Insights and enhanced capabilities. Basic insights use emails, phone calls, and appointments that have been sent, received, or recorded in Dynamics 365. When a related activity is completed, those basic measures can update close to real time. That makes activity tracking extremely important. If a customer call occurs but nobody records it against the correct Dynamics 365 record, Relationship Intelligence cannot properly include that conversation. If an activity is connected with the wrong account or opportunity, the resulting picture becomes less useful. Relationship Intelligence can analyze captured communication. It cannot analyze conversations that the organization never captured.

ENHANCED RELATIONSHIP INSIGHTS
Organizations with the appropriate Dynamics 365 Sales licensing and configuration can use enhanced relationship insights. The episode explains that these capabilities can combine information from Dynamics 365 with email and meeting information from Microsoft Exchange when server-side synchronization is configured. This gives Dynamics 365 access to a broader communication picture. There is an important timing difference. Basic insights can update close to real time when relevant Dynamics 365 activities are completed. Enhanced insights operate on a 24-hour update cycle according to the supplied episode. That means sellers should not necessarily expect a message sent several minutes ago to immediately affect every enhanced relationship measure.

EMAIL SENT VS EMAIL RECEIVED
One useful relationship measure compares emails sent by the organization with emails received from the customer. Imagine a salesperson sends eight emails. The customer replies once. That does not automatically mean the opportunity is failing. Perhaps the customer prefers meetings or telephone calls. But the pattern raises a useful question: Are we having a conversation, or are we repeatedly sending messages without meaningful engagement? The opposite pattern can also expose problems. Perhaps the customer repeatedly sends questions while the sales team responds slowly. In that situation, the customer may be highly engaged while the organization itself is creating friction. The metric does not provide the answer. It tells the seller where to investigate.

THE 60-DAY RELATIONSHIP ACTIVITY VIEW The episode describes a Relationship Activities view that looks across 60 days of communication activity. Instead of showing only a total number, the view separates activities by date and type. Sellers can examine patterns involving emails sent and received, meetings sent and received, and phone calls made and received. This makes the rhythm of the relationship visible. A customer relationship containing regular communication across the entire period looks very different from one containing intense activity during the first week followed by several weeks of silence. The quiet period could mean many things. Perhaps a proposal was delivered and nobody followed up. Maybe a meeting was cancelled. Perhaps the customer deliberately asked the seller to wait until another date. Relationship Analytics shows the pattern. The salesperson provides the business context.

RESPONSE TIME AS A SALES SIGNAL
Enhanced insights can also include response time. This compares how quickly sellers respond to customers with how quickly customers respond to sellers. Slow customer responses can indicate reduced attention. But slow seller responses can create exactly the same problem from the opposite direction. If an interested customer repeatedly waits several days for answers, they may eventually stop asking questions. Response time can therefore expose small problems before they become larger sales issues. It gives sellers and managers another signal for understanding whether communication is moving naturally or becoming increasingly difficult.

HOURLY INVESTMENT
Another enhanced measure discussed in the episode is hourly investment. This compares the amount of time the organization spends around a sales record with the amount of time customer contacts spend. Imagine two opportunities. In the first, the sales team spends many hours on meetings, calls, and communication while the customer contributes relatively little time. In the second, both sides regularly participate. Those represent different engagement patterns. Hourly investment does not determine which opportunity will close. A short conversation with a senior decision-maker may be considerably more important than several long meetings. But the metric can highlight situations where effort appears heavily one-sided. 

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

A customer sends an email, starts a chat, calls support, or contacts a company through another service channel. When an agent picks up that request, they need the complete customer story quickly. What did the customer already tell us? Which product do they own? Has somebody else worked on this problem? Is there an existing case? What was promised previously? Is there a service deadline approaching? Without a unified workspace, answering those questions can mean jumping between browser tabs, inboxes, CRM records, notes, knowledge bases, and communication applications. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Dynamics 365 Customer Service Workspace, now known as Copilot Service Workspace, in plain English. We explore sessions and tabs, cases and timelines, omnichannel customer service, the agent inbox, Smart Assist, knowledge management, agent scripts, macros, quick replies, Copilot, Microsoft Teams collaboration, Unified Routing, queues, presence, capacity, SLA management, escalation, self-service, dashboards, and customer service analytics. The central idea is straightforward: give customer service agents one organized workspace where the customer, the problem, the history, the knowledge, and the tools required to solve it remain connected.

WHAT IS DYNAMICS 365 CUSTOMER SERVICE WORKSPACE?
Dynamics 365 Customer Service Workspace was designed as a focused working environment for customer service agents. Microsoft now refers to this newer agent experience as Copilot Service Workspace, so organizations may encounter both names in documentation, videos, training materials, or existing environments. Think of it as a browser designed specifically around customer service. Instead of opening a completely separate browser window for every customer, case, knowledge article, product record, and conversation, the workspace organizes related information around the piece of customer work currently being handled. The objective is not simply to display CRM records. It is to help agents move between multiple customer issues without repeatedly losing and rebuilding context.

WHY CUSTOMER SERVICE AGENTS NEED A DIFFERENT WORKSPACE
Imagine an agent halfway through a customer call. A high-priority email arrives. Another customer replies to yesterday's chat. A different case is approaching its promised response deadline. This is normal customer service work. Agents frequently manage several customers, several communication channels, and substantial histories for each customer simultaneously. They need to understand what the customer purchased, what already happened, who previously worked on the issue, and whether somebody promised a response. When that information lives across multiple systems, the agent becomes an information detective. Customer Service Workspace attempts to remove some of that detective work.

THE PROBLEM WITH CONSTANT CONTEXT SWITCHING
Consider the traditional workflow. An agent searches an email inbox for an old customer message. They open the customer record in another browser tab. They find a case. Another application contains internal notes. A knowledge base contains troubleshooting instructions. Then another customer contacts them. The agent changes context. Ten minutes later, they return to the first customer and need to remember why several browser tabs are open. The applications may all work correctly individually. The problem is that the customer story is fragmented across them. That fragmentation becomes visible to customers when they hear: "Can you tell me that again?" or: "Let me find the previous update." Customer Service Workspace attempts to keep more of that story together.

FROM CUSTOMER SERVICE HUB TO COPILOT SERVICE WORKSPACE
Many Dynamics 365 users will be familiar with the older Customer Service Hub experience. Customer Service Hub supported core service activities such as working with cases, customer records, activities, knowledge articles, and dashboards. Customer Service Workspace introduced a different style of agent experience focused more heavily on handling several active pieces of work while preserving the context associated with each one. The supplied episode describes Microsoft subsequently naming this experience Copilot Service Workspace. The underlying concept remains an agent-focused workspace where customer service information and tools are organized around active work. 

THE AGENT DESK, NOT THE ADMINISTRATION CONTROL ROOM
Copilot Service Workspace is primarily where agents perform their daily customer service work. It is not where every customer service rule is designed. Administrators configure areas such as channels, queues, routing rules, permissions, skills, capacity, and other service settings through the relevant administration experiences. The agent experiences the result of that configuration inside the workspace. Think of the distinction like this: The administration environment is the control room. Copilot Service Workspace is the service desk. Agents should be able to focus primarily on customers rather than the technical configuration behind how customer work reached them.

SESSIONS: ONE CUSTOMER ISSUE, ONE WORKING CONTEXT
One of the most important concepts inside the workspace is the session. Think of a session as a labeled desk drawer. One drawer contains everything associated with one customer's active issue. Another drawer contains another customer's conversation. Opening one drawer should not mix its contents with another. Inside Copilot Service Workspace, a session provides a boundary around a particular piece of customer work. That makes it easier for agents to manage several active issues without mixing their records, notes, and supporting information.

TABS: EVERYTHING RELATED TO THE CUSTOMER ISSUE
Inside each session are tabs. The first tab might contain the case. The agent clicks the customer and opens the customer record as another tab. They might then open the associated account. Another tab could contain the product. Another could contain a knowledge article. Another might contain an email. These are separate records, but they belong to the same customer story. Instead of scattering those records across unrelated browser windows, the workspace keeps them grouped inside the session. This gives agents the freedom to explore connected information without losing the original customer issue. ㅤ 

A SIMPLE SESSION EXAMPLE
Imagine a customer contacts support because their coffee machine stopped working. The agent opens the case. That becomes the working session. The case contains the reported problem and current status. The agent clicks the customer's name. The customer record opens as another tab inside the same session. The agent reviews previous support interactions. Next, they open the product record to determine which coffee machine model the customer owns. Then they find an approved troubleshooting article. That article opens in another tab. The agent can move between the case, customer, product, and knowledge article while everything remains associated with the same customer issue.

MULTIPLE CUSTOMERS WITHOUT MIXING THEIR INFORMATION
Now imagine another customer contacts support. Their problem has nothing to do with the coffee machine case. Instead of adding more unrelated tabs to the existing workspace, the second customer receives a separate session. That session has its own tabs, records, and context. The first customer remains in one drawer. The second remains in another. This separation can reduce simple but potentially serious mistakes. When agents handle several cases simultaneously, it can be easy to type a note on the wrong record, lose track of which customer owns which information, or accidentally continue working from the wrong context. Sessions provide clearer boundaries between those customer stories.

SESSION AND TAB LIMITS
The supplied episode states that Copilot Service Workspace supports up to nine sessions at one time, with up to ten tabs within each session. The important point is not that agents should spend their day counting tabs. It is that a customer case rarely exists alone. A service issue can connect to contacts, accounts, products, activities, emails, knowledge articles, notes, and other business information. The workspace gives those connected records somewhere to remain together while the agent works.

SESSION RESTORE
A browser refresh during a complicated customer case can be disruptive. The supplied material describes a session restore feature in preview that administrators can enable. With session restore enabled, supported records and tabs can be restored following a browser refresh rather than forcing the agent to begin again from an empty home page. The episode notes that supported cases, accounts, related tabs, and the agent's previous focus can return after presence loads, while active conversations such as chats and calls can also return. This can help preserve context when a refresh occurs at exactly the wrong moment. Agents still need to save their work appropriately. A workspace can restore supported context, but it cannot protect information that was never saved. 

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

Dynamics 365 Forecasting helps sales teams answer one of the most important questions in business: are we going to hit our sales target? Instead of collecting numbers from spreadsheets, emails, and individual sales reports, Dynamics 365 Sales brings opportunities, expected revenue, close dates, forecast categories, quotas, and sales performance into one shared forecasting view. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Forecasting works, how forecast categories represent confidence, and why accurate opportunity data is essential for reliable revenue forecasting.
ㅤ
WHAT IS DYNAMICS 365 FORECASTING?
ㅤ
Dynamics 365 Forecasting turns the opportunities your sales team already manages in Dynamics 365 Sales into a structured view of expected revenue. A sales forecast isn't a guarantee of future revenue. It's a continuously changing estimate based on what the sales organization currently knows about its open opportunities.
The forecast combines important information including expected deal value, expected close dates, sales quotas, ownership, and confidence. This allows sellers and sales managers to understand not only how much potential revenue exists, but how realistic that revenue is for the current forecasting period.
ㅤ
FROM SPREADSHEETS TO A SHARED SALES FORECAST
ㅤ
Traditional forecasting often depends on individual spreadsheets that sellers update at different times. Managers then collect those files, consolidate the numbers, and try to determine which version contains the latest information.
Dynamics 365 Sales changes this process by building forecasts from opportunity data already maintained by the sales organization. Instead of creating another reporting process, forecasting becomes part of everyday sales management. Everyone can work from the same underlying opportunity information.
ㅤ
UNDERSTANDING THE FORECAST GRID
ㅤ
The Dynamics 365 forecast grid acts like a shared sales scorecard. Depending on how forecasting is configured, rows can represent individual sellers, teams, territories, or products. Columns can show quota, forecast amounts, and different levels of forecast confidence.
Managers can move beyond headline revenue numbers and drill into the opportunities behind those totals. This makes forecast conversations more practical because teams can discuss specific deals, changes in close dates, customer decisions, and pipeline risks instead of debating spreadsheet numbers.
ㅤ
FORECAST CATEGORIES EXPLAINED
ㅤ
Forecast categories provide a common language for describing the confidence behind each opportunity. Pipeline represents opportunities that are still relatively early or uncertain. Best Case represents opportunities showing meaningful progress but which are not yet reliable enough to treat as expected revenue.
Committed represents opportunities where the customer has provided a strong verbal or contractual commitment, although the sale has not officially closed. Omitted removes an opportunity from forecast totals without deleting the opportunity from Dynamics 365 Sales.
Won and Lost are handled differently. When opportunities are formally closed, Dynamics 365 updates their final status accordingly. Together, these categories allow teams to see the difference between potential revenue, realistic upside, and high-confidence opportunities.
ㅤ
FORECASTING FOR SELLERS AND SALES MANAGERS
ㅤ
Different roles can use the same forecasting data for different decisions. Individual sellers can compare their current forecast against quota and identify where they need to focus their attention. A seller who has a large gap between expected revenue and target can determine whether existing opportunities need attention or whether additional pipeline must be created.
Sales managers can view the entire team and then drill into individual sellers and opportunities. This makes coaching more specific. Instead of simply asking why someone's forecast is low, managers can discuss actual opportunities, customer activity, delayed close dates, missing proposals, and the next actions required to move deals forward.
ㅤ
FORECAST HIERARCHIES AND ROLLUPS
ㅤ
Dynamics 365 Forecasting can aggregate opportunity information through different organizational structures. An organizational hierarchy can follow reporting relationships, while territory-based forecasts can organize revenue around geographic or assigned markets. Product forecasts can show expected revenue based on what the company sells.
These rollups allow sellers, managers, directors, and leadership to work from connected sales data while viewing the information at the level appropriate to their responsibilities.
ㅤ
AI AND SALES FORECASTING
ㅤ
AI can provide additional signals around sales opportunities, but it doesn't know exactly which customers will buy. Opportunity scoring and related sales intelligence can analyze patterns such as customer interactions, meetings, emails, sales stages, opportunity values, and previous sales activity.
These signals can help sellers and managers identify opportunities that may require attention. A low score should therefore be treated as another piece of information rather than a final decision about whether an opportunity will close.
ㅤ
WHY DATA QUALITY MATTERS
ㅤ
Even sophisticated forecasting technology cannot compensate for inaccurate sales data. If an opportunity has an outdated close date, incorrect expected revenue, or an unrealistic forecast category, those errors can flow directly into the forecast.
Sellers should keep opportunity amounts, expected close dates, ownership, and forecast categories current whenever the customer situation changes. Accurate forecasting starts with accurate opportunity management.
ㅤ
HUMAN JUDGMENT STILL MATTERS
ㅤ
Sales data cannot capture every detail of a customer relationship. Budget changes, competitors, internal customer reorganizations, new decision makers, delayed projects, and changing priorities can dramatically affect an opportunity.
The strongest forecasting process combines structured Dynamics 365 data with the knowledge of the people actually speaking with customers. Managers can use forecast reviews to understand what changed, challenge assumptions, and determine whether opportunities still belong in their current forecast categories.
ㅤ
BUILDING A RELIABLE FORECASTING RHYTHM
ㅤ
Reliable forecasting depends on regular updates rather than a last-minute cleanup before a leadership meeting. Sellers should review open opportunities throughout the week and update values, expected close dates, ownership, and forecast categories when circumstances change.
Forecast reviews can then focus on meaningful questions: Which deals moved forward? Which opportunities slipped? Where is revenue at risk? Is there enough pipeline to reach quota? Which opportunities need immediate attention?
This turns forecasting from a reporting exercise into an active sales management process.
ㅤ
THE KEY TAKEAWAY
ㅤ
Dynamics 365 Forecasting transforms everyday sales opportunity data into a shared view of expected revenue, confidence, quota performance, and pipeline risk. Sellers can understand where to focus their effort, managers can identify problems earlier, and leadership gains a clearer picture of expected business performance.
But the quality of the forecast ultimately depends on the quality of the information behind it. Keep opportunity data accurate, use forecast categories consistently, and combine the numbers with human judgment. That's when Dynamics 365 Forecasting becomes a practical tool for sales planning rather than another report.
Subscribe to M365 FM for more Microsoft Knowledge Nuggets and Simply Explained episodes covering Dynamics 365, Microsoft 365, Power Platform, Azure, Copilot, AI, security, governance, and the Microsoft ecosystem.


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

Enterprise integration is everywhere, yet most people only notice it when something stops working. Applications need to communicate, APIs need to exchange information, ERP systems need to connect with business processes, and data needs to move reliably across organizational boundaries. For decades, integration has largely followed a deterministic model: when this happens, do that. Developers and architects define triggers, conditions, transformations, retries, exceptions, and destinations in advance. But what happens when AI becomes part of that integration layer? In this episode of M365 FM, Mirko Peters talks with Sonny Gillissen [MVP], an Azure Integration Services specialist with a particular focus on Azure Logic Apps, about a concept he calls “Organism as a Service.” The idea is that enterprise integration can evolve from static workflows into systems capable of interpreting context, responding to unexpected situations, choosing appropriate actions, and potentially recovering from failures more intelligently. The conversation covers Azure Logic Apps, Azure Integration Services, API Management, Azure Functions, Azure Service Bus, Event Grid, managed connectors, managed identities, Azure Key Vault, Infrastructure as Code, Bicep, Terraform, CI/CD, observability, Log Analytics, security, least privilege, network isolation, AI agent loops, self-healing integrations, and the future of intelligent enterprise integration.

WHY ENTERPRISE INTEGRATION MATTERS
Integration has effectively become infrastructure. Employees open an application and expect the information they need to appear. Customers place orders and expect them to reach the correct systems. Financial transactions move through ERP platforms. APIs exchange information. Events trigger downstream processes. From the user's perspective, this often feels automatic. Sonny compares it to turning on a water tap: people expect water to flow without thinking about everything happening behind the wall. Enterprise integration works similarly. The complexity becomes invisible until something fails. Behind seemingly simple processes can be dozens of applications, APIs, business rules, security controls, identities, transformations, queues, monitoring systems, and organizational responsibilities. Integration therefore isn't simply about connecting application A with application B. It is about keeping business processes operating across systems that were often never originally designed to work together.

WHY ENTERPRISE INTEGRATION BECOMES SO COMPLEX
The technology itself is not always the primary source of complexity. Enterprise business processes are complicated. ERP environments such as SAP and Microsoft Dynamics contain extensive transactional processes because financial and operational activities need control, consistency, and auditing. Multiple departments participate. Business knowledge remains distributed among employees. Organizations accumulate years of architectural decisions. Eventually, integration architecture begins reflecting all of that organizational complexity. Sonny argues that a good integration consultant therefore needs to look beyond the technical request. Instead of simply asking “How do we connect these systems?”, the more important question is: “What is the organization actually trying to accomplish?” Simplifying integration starts by understanding the business process behind it.

WHAT MAKES A GOOD INTEGRATION ARCHITECTURE?
An integration that works today is not necessarily a good integration. Sonny highlights reusability and security as particularly important characteristics. Modern integration architectures should become increasingly composable. Instead of rebuilding the same functionality repeatedly, organizations should be able to reuse components in different processes. Security is equally fundamental. Integration services frequently connect highly privileged business systems. Poorly designed access can turn an integration platform into an extremely attractive attack path. A successful request is therefore only one measure of integration quality. The architecture also needs to remain reusable, supportable, secure, observable, and adaptable as business requirements change.

WHAT ARE AZURE INTEGRATION SERVICES?
Azure Integration Services is not one product. It is a collection of Microsoft Azure capabilities that can be combined to build enterprise integration architectures. During the conversation, Sonny and Mirko discuss five major technologies: Azure Logic Apps provides workflow orchestration and low-code integration. Azure API Management provides an API gateway and management layer. Azure Functions provides serverless code for scenarios where pro-code functionality is appropriate. Azure Service Bus supports messaging and helps decouple systems. Azure Event Grid provides event-driven integration capabilities. Different services solve different pieces of the integration problem, and real enterprise architectures frequently combine several of them.

AZURE LOGIC APPS VS AZURE FUNCTIONS
One recurring architectural question is whether a particular integration should use Azure Logic Apps or Azure Functions. There is no universal answer. Organizations with strong low-code expertise may find Logic Apps particularly effective because developers and integration specialists can visually construct workflows. Organizations with experienced .NET development teams may prefer Azure Functions for scenarios where custom code provides greater flexibility. The important point is that this does not need to become an ideological choice between low code and pro code. An enterprise integration architecture can use both. Logic Apps can orchestrate processes while Functions provide specialized code where required.

WHY AZURE SERVICE BUS MATTERS
Azure Service Bus plays an important role in decoupling enterprise systems. Without a messaging layer, application A may directly depend on application B being available. That creates tight coupling. Introducing Service Bus can separate those systems. Application A can send information to Service Bus, while application B processes it according to the architecture. This can make backend integrations more resilient and provide opportunities for reprocessing. Sonny notes that Service Bus is not automatically appropriate for every synchronous scenario because adding asynchronous messaging can affect response time and user experience. But for backend processing and decoupled architectures, he considers it an important component. 

WHY SONNY SPECIALIZES IN AZURE LOGIC APPS
One reason Sonny focuses heavily on Azure Logic Apps is visibility. Traditional code requires developers to deliberately implement logging and monitoring. A Logic App provides a visual workflow and run history. After executing a workflow, developers can inspect what happened, which actions executed, what results were produced, and where failures occurred. This allows integration specialists to spend more time thinking about the business process and less time building basic troubleshooting infrastructure. For people who naturally think visually about processes rather than primarily through code, this can make Logic Apps particularly effective.

THE DEVELOPER MISUNDERSTANDING ABOUT LOGIC APPS
Developers sometimes assume that writing custom code will always be faster or more powerful than using a visual integration platform. For some scenarios, that may be true. But the calculation needs to include more than the time required to write the core functionality. Monitoring matters. Logging matters. Deployment matters. Error handling matters. Operations matter. Maintenance matters. Logic Apps provides significant platform functionality around the workflow itself. Sonny also discusses codeful workflows as an attempt to bridge the gap between visual Logic Apps development and traditional pro-code development approaches.

LOGIC APPS SHOULD BE TREATED AS CODE
Low code does not mean organizations should abandon software engineering practices. Sonny recommends treating Logic Apps as code and deploying them through CI/CD. An organization could manually create something in development, export it, and reproduce it in another environment. But manual deployment creates an obvious risk: Eventually, somebody forgets something. Development and production begin to differ. Those differences become operational problems. Automated deployment provides repeatability and helps organizations maintain consistent environments.

INFRASTRUCTURE AS CODE WITH LOGIC APPS
Azure Logic Apps can be deployed as part of an Infrastructure as Code strategy. The episode discusses ARM templates, Bicep, and Terraform. Infrastructure as Code describes the desired Azure environment deterministically. The configuration can define resources, SKUs, locations, resource groups, and other infrastructure properties. Bicep provides a more concise Azure-focused authoring experience while ultimately relating closely to ARM deployment. Terraform provides another approach for defining and deploying infrastructure. The important architectural principle is repeatability. Integration infrastructure should not depend entirely on somebody remembering which buttons they clicked in the Azure portal.

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

A machine stops in the middle of a shift. The technician standing beside it can see the problem, but the person with the deepest knowledge of that machine may be hundreds or thousands of kilometers away. Traditionally, solving that problem could involve telephone calls, photographs, emails, unclear descriptions, repeated questions, or eventually sending a specialist to the site. The challenge is not necessarily that expertise does not exist. The challenge is getting that expertise to the place where the work is happening. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Microsoft Dynamics 365 Remote Assist in plain English and explores how frontline workers can connect with remote experts through live video, visual guidance, Microsoft Teams, mobile devices, mixed reality, and connected Dynamics 365 processes. We look at how Remote Assist supports field service, manufacturing, maintenance, inspections, troubleshooting, training, remote collaboration, Microsoft Teams, Dynamics 365 Field Service, Microsoft 365 identity and security, and mixed reality scenarios. The central idea is simple: instead of trying to describe a physical problem to someone who cannot see it, let the expert see what the frontline worker sees.

THE PROBLEM WITH REMOTE TECHNICAL SUPPORT
Many frontline jobs happen far away from a desk. Maintenance employees work beside production equipment. Field technicians visit customer locations. Inspectors examine physical components. Engineers install machinery. Service teams troubleshoot equipment in warehouses, factories, offices, hospitals, or other facilities. When something unexpected happens, the employee on site can see the problem directly. They might hear an unusual sound. They might notice a loose cable. A warning light might appear. A component may not fit correctly. The difficulty begins when the employee needs help from someone who is somewhere else. The remote expert cannot initially see any of those details. The technician has to translate a physical situation into words. That translation creates opportunities for misunderstanding. 

WHY PHONE SUPPORT HAS LIMITATIONS
Imagine calling an expert and saying: "There's something wrong with the connector at the back." The sentence makes perfect sense to the technician standing beside the machine. But the remote expert immediately has several questions. Which connector? Which side of the machine? What is connected to it? What does the surrounding equipment look like? Is there visible damage? Is another component positioned incorrectly? The technician describes the situation. The expert tries to reconstruct the machine mentally. Both people may eventually understand each other, but valuable time can disappear simply establishing which physical object they are discussing. Dynamics 365 Remote Assist was designed to reduce that gap by creating a shared visual context.

PHOTOS ARE USEFUL BUT STATIC
Photographs improve remote support because the expert can finally see something. But a photograph represents one moment from one angle. The expert might reply: "Can you send another picture from the side?" The technician takes another photograph. Then the expert needs a close-up. Another photograph. Then they need to understand where that component sits relative to another part. Another photograph. Meanwhile, the technician may have moved, removed another panel, or discovered a different problem. Live video changes this interaction because the expert can ask the technician to move the camera immediately. Instead of exchanging snapshots of the problem, both people can explore the physical environment together.

WHAT IS DYNAMICS 365 REMOTE ASSIST?
Dynamics 365 Remote Assist is a Microsoft application designed to connect a frontline worker with a remote expert while keeping the conversation focused on the physical work being performed. The worker can share live video of the equipment, environment, or problem. The remote expert sees the same physical scene and can provide guidance while the technician remains beside the equipment. The worker might use a supported smartphone or tablet. For appropriate hands-free scenarios, supported mixed reality headsets can provide another experience. The objective is not to make the remote expert physically present. It is to give that expert enough visual context to provide more useful assistance without immediately traveling to the location. ㅤ

LIVE VIDEO CHANGES THE SUPPORT CONVERSATION
Imagine an expert sitting in a central support office. Without Remote Assist, they might receive a service ticket containing several sentences and a photograph. They need to interpret the problem from that limited information. With Remote Assist, the worker's camera becomes a window into the work environment. The technician can show the complete machine. Then the control panel. Then the component producing the problem. The expert can ask the technician to move closer, change the viewing angle, show a label, follow a cable, or inspect another component. The conversation becomes interactive. The expert no longer needs to imagine the physical environment entirely from a written description.

USING REMOTE ASSIST ON MOBILE DEVICES Not every remote support scenario requires mixed reality hardware. Supported smartphones and tablets can provide a practical option for many everyday service situations. A field technician can take out a device, contact an expert, show the equipment, receive guidance, and continue working. This makes Remote Assist relevant to organizations that want visual remote support without deploying specialized headsets to every employee. For quick inspections, customer-site troubleshooting, equipment identification, or occasional expert assistance, familiar mobile devices can be sufficient. The important element is not the device. It is the shared visual context.

MIXED REALITY AND HANDS-FREE SUPPORT
Mixed reality becomes particularly interesting when employees need both hands available. Imagine a technician working inside a machine while holding tools. Repeatedly putting down the tools to pick up a smartphone interrupts the process. With an appropriate mixed reality headset, the worker can continue looking at the equipment while the remote expert sees the worker's perspective. The technician's hands remain available for the task. Guidance can remain connected to the physical work environment. This makes hands-free remote assistance potentially useful for complicated maintenance, manufacturing, inspection, and service processes.

MICROSOFT TEAMS AND REMOTE ASSIST
Microsoft Teams plays an important role in the Remote Assist experience. Teams provides familiar communication capabilities including calls, meetings, chat, and contacts. Remote Assist uses that communication foundation while focusing the interaction on frontline work. A technician can connect with an expert already working within the organization's Microsoft environment. Another specialist can potentially join when additional expertise becomes necessary. The organization does not necessarily need to build a completely separate communication network specifically for remote support. The people employees already collaborate with through Teams can become part of the support process.

REMOTE ASSIST VS A NORMAL TEAMS CALL
At first glance, Remote Assist may sound like a Microsoft Teams video call. There is an important difference. A traditional Teams meeting primarily connects people. Remote Assist focuses that connection on the physical work environment. The remote expert is not simply watching another person's face through a webcam. They are looking at the machine, equipment, installation, component, or physical environment the frontline worker is trying to understand. Visual guidance can then help both people focus on the same physical object. That makes the conversation considerably more useful for hands-on technical work.

VISUAL ANNOTATIONS
One of the most useful concepts behind Remote Assist is visual annotation. Imagine an electrical cabinet containing several rows of nearly identical connectors. The remote expert says: "Check the connector beside the blue cable." There may still be several possible components. Instead, the expert can visually indicate the relevant area. They might circle a connector, place an arrow near a switch, or mark another part of the scene. The technician can then see exactly which area the expert is discussing. A small visual mark can eliminate several minutes of verbal explanation. This becomes particularly valuable when machinery contains many visually similar components

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

When a customer sends a chat message, email, phone request, or support case, they usually expect one thing: the right person should help them as quickly as possible. But customer service becomes complicated as organizations grow. A shared inbox that worked perfectly for five agents can quickly turn into a bottleneck when hundreds of requests arrive through multiple channels, in different languages, with different priorities, and requiring different technical skills. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Microsoft Dynamics 365 Unified Routing in plain English. We explore how Unified Routing classifies incoming customer requests, determines priority, identifies required skills, considers agent availability and workload, and then routes the work to the most appropriate person. We also explain workstreams, queues, skills, capacity profiles, presence, push assignment, pick assignment, machine learning, fallback queues, and Copilot Service workspace.

WHAT IS DYNAMICS 365 UNIFIED ROUTING?
Dynamics 365 Unified Routing is an intelligent routing capability designed to automatically distribute incoming customer service work to appropriate agents. Think of it as a smart front desk. Imagine a large office building where visitors arrive with completely different needs. One person needs accounting. Another needs technical support. Another speaks Spanish and needs someone who can communicate with them. Another has an urgent appointment. A good receptionist does not simply point everybody toward the same waiting room. They understand what each visitor needs and direct them toward the right person. Unified Routing performs a similar function for customer service requests. Instead of simply asking "Which agent is next?", the system can consider what the customer needs, who has the necessary skills, who is available, how much work each agent already has, and how urgently the request should be handled. 

WHY BASIC CUSTOMER SERVICE QUEUES STOP WORKING
Imagine a small customer service department with five employees. Customers send emails to one shared support address. Every email enters the same queue. When an agent finishes their current task, they take the next request. For a small organization with one product, one language, and relatively few requests, this can work perfectly well. Then the organization grows. Customers begin contacting support through email, live chat, voice, messaging, web forms, and case records. Some customers have billing questions. Others need technical assistance. Some require support in another language. Some have routine questions. Others have critical problems affecting their business. Suddenly, the shared queue looks less like an organized support process and more like a pile of papers sitting on somebody's desk.

THE PROBLEM WITH FIRST-COME, FIRST-SERVED ROUTING
Traditional queues frequently focus on when a request arrived. But arrival time is only one factor. Imagine an experienced technical specialist spending an hour answering basic password questions. Meanwhile, a customer with a serious technical problem waits because nobody noticed that their case requires specialist knowledge. Eventually, another agent opens the case, realizes they cannot solve it, and transfers it. The customer waits again. The organization creates additional work. The specialist eventually receives the request anyway. Unified Routing attempts to reduce these unnecessary handoffs by considering the requirements of the request before assigning it. The goal is to get closer to: Right customer request → right team → right agent → right time.

BASIC ROUTING VS UNIFIED ROUTING
Basic routing can already provide useful structure. An organization might create a simple rule: Billing cases go to the billing queue. Technical cases go to the support queue. For straightforward customer service environments, that may be sufficient. But a queue answers only part of the routing question. It tells the system where the request should wait. It does not necessarily determine which person inside that queue has the appropriate expertise, who is currently available, who already has several active conversations, or whether another request should receive higher priority. Unified Routing addresses this larger assignment problem.

ONE ROUTING APPROACH ACROSS CUSTOMER SERVICE CHANNELS
One of the important ideas behind Unified Routing is applying a common routing approach across different types of customer work. A live chat and an email are obviously different interactions. A telephone call has different timing requirements from a case created through a web form. But they share the same fundamental routing problem: Who should handle this request? Unified Routing can evaluate incoming work according to the organization's configured rules and requirements. The channel becomes one part of the decision rather than requiring an entirely disconnected routing philosophy for every customer interaction.

SKILLS-BASED ROUTING
Skills are one of the most important concepts in Unified Routing. A skill represents something an agent knows how to handle. That might be: A language. A particular product. A technical area. A customer service specialization. A business function. A support level. Incoming work can also receive required skills. Dynamics 365 can then match the requirements of the customer request with the skills associated with available agents. 

A SIMPLE SKILLS-BASED ROUTING EXAMPLE
Imagine two agents. Maria understands the company's advanced product line and speaks Spanish. David specializes in account questions and currently has capacity for another email. A Spanish-language request about an advanced technical problem should not automatically go to David simply because he happens to be the next available person. The work requires Spanish and advanced product knowledge. Maria is therefore a much stronger match when she is available and has sufficient capacity. This illustrates the fundamental difference between basic distribution and intelligent routing. Availability alone does not necessarily make somebody the right agent.

THE TWO DECISIONS BEHIND UNIFIED ROUTING
Unified Routing essentially performs two connected operations. First, it determines what the incoming request needs. Then it determines who should receive it. Microsoft's routing process can therefore be understood as: Classification → Assignment Classification adds useful information to the work item. Assignment compares those requirements with available agents. Keeping these two stages separate makes the overall routing process easier to understand.

WHAT IS CLASSIFICATION?
Imagine an email entering Dynamics 365. Initially, it may contain a customer name, subject line, message, and other basic information. That alone may not tell the routing system enough. Is this a billing problem? A product failure? An account question? Which language does the customer require? Does the customer have premium support? Does the case require specialist knowledge? How urgent is the problem? Classification adds the information required to answer those questions. It turns a relatively vague customer request into structured work that the routing system can understand. 

CLASSIFICATION RULES
Organizations can configure rules that examine information associated with incoming work. For example, a rule might determine that a customer has a premium support agreement and therefore assign a higher priority. Another rule could inspect the case category and require a billing skill. Another could identify the customer's language and add that language as a routing requirement. The important point is that these decisions become repeatable. Instead of every agent manually deciding how a request should be categorized, the routing configuration applies the organization's service rules consistently.

MACHINE LEARNING AND ROUTING
Rules work particularly well when customer information is structured and predictable. But customers do not always describe the same problem using the same words. One customer might say: "My device won't start." Another writes: "The screen stays black." Another says: "I can't turn it on." These sentences may describe the same underlying problem. Creating manual rules for every possible variation quickly becomes difficult. The supplied episode explains that machine-learning-based capabilities can help predict the skills required for a request by examining patterns in customer text. Instead of creating a separate rule for every phrase, a model can help determine whether a request appears to require product expertise, billing knowledge, or another support skill. 

YOU DO NOT ALWAYS NEED MACHINE LEARNING
More intelligence does not automatically mean better routing. A small customer service team with clear case categories may be perfectly successful using straightforward rules. Machine learning becomes more relevant when volumes increase, customer descriptions vary significantly, and maintaining manual routing rules becomes increasingly difficult. The routing architecture should match the complexity of the actual service operation. Organizations should not create an AI problem where a simple business rule already solves the requirement. 

PRIORITY IS DIFFERENT FROM SKILLS Skills and priority answer two different questions. Skills ask: Who can solve this? Priority asks: How quickly should we deal with it? A routine request may safely wait behind a serious service disruption. A customer with a premium support agreement may require a faster response. An urgent operational problem may need to move ahead of several normal requests even when those requests arrived earlier. Unified Routing can use classification information to establish priority before an agent receives the work.

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

Imagine standing beside a large industrial machine and seeing the next repair instruction appear directly beside the panel you need to open. Instead of putting down your tools, walking back to a laptop, searching through a PDF, or trying to remember what an experienced technician told you during training, the information appears directly inside your field of view. That was the central idea behind Microsoft Dynamics 365 Guides. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Dynamics 365 Guides in plain English: what the mixed reality application was designed to solve, how Microsoft HoloLens brought instructions into the physical workplace, how companies could capture expert knowledge, how Microsoft Teams enabled remote assistance, and how Dynamics 365, Dataverse, Power Platform, Power BI, and AI could extend the experience. There is also an important strategic issue organizations need to understand: Microsoft has set December 31, 2026 as the end-of-availability date for Dynamics 365 Guides and Dynamics 365 Remote Assist. For organizations still using the technology, preserving the knowledge contained inside their Guides is therefore becoming just as important as understanding the technology itself.

WHAT IS DYNAMICS 365 GUIDES?
Dynamics 365 Guides is a Microsoft mixed reality application designed to bring step-by-step work instructions directly into the physical environment where employees perform a task. Instead of requiring a technician to repeatedly move between a machine and a manual, Guides could display digital instruction cards, images, videos, and 3D objects through a Microsoft HoloLens headset. The employee could still see the real machine, tools, equipment, coworkers, and surrounding environment. Digital information appeared alongside that physical world. This made Guides particularly interesting for scenarios involving manufacturing, maintenance, inspections, field service, training, assembly, and other repeatable physical processes. The fundamental concept was simple: Bring the instruction to the work instead of forcing the worker to leave the work to find the instruction.

THE PROBLEM: INSTRUCTIONS ARE OFTEN FAR FROM THE WORK
Physical work frequently happens far away from the information required to perform it. A technician may be servicing a pump. An operator may be assembling equipment. A maintenance employee may need to inspect dozens of components in a particular sequence. A quality inspector may need to compare a finished component against an approved standard. Traditionally, those employees might rely on paper manuals, PDFs, laptops, classroom training, or experienced colleagues. All of those methods can work. But they create a separation between where the knowledge lives and where the work happens. A technician reads the manual, returns to the machine, remembers as much as possible, completes part of the task, and then potentially returns to the documentation. That constant context switching creates friction.

WHY TRADITIONAL MANUALS CAN BECOME A PROBLEM
Imagine a new technician standing beside a machine they have never repaired. The manual refers to components by technical names and part numbers. The actual machine contains cables, covers, grease, connectors, labels, bolts, and dozens of components that look similar. The technician reads the manual. Then they look at the machine. Then they return to the diagram. Then they try to determine whether the component shown on the page is actually the component in front of them. An experienced technician may perform the same task almost automatically because years of experience have created practical knowledge that the manual does not fully communicate. Dynamics 365 Guides attempted to reduce that gap by putting visual guidance directly beside the physical object.

CAPTURING EXPERT KNOWLEDGE
Experienced employees often possess enormous amounts of undocumented knowledge. They know which cover should come off first. They know which tool fits into a difficult space. They recognize what a correctly installed component should look like. They know where common faults occur. They know which warning signs inexperienced employees frequently overlook. The problem is that much of this information exists primarily inside people's memories. When those employees are busy, working at another location, changing jobs, or retiring, organizations can lose valuable operational knowledge. Dynamics 365 Guides provided a way to convert some of that experience into structured digital instructions. An experienced technician, process engineer, or trainer could create a repeatable sequence that another employee could follow while standing directly beside the equipment. 

WHAT IS MIXED REALITY?
Mixed reality combines the physical environment with digital information. With Dynamics 365 Guides, an employee could wear a Microsoft HoloLens headset while continuing to see the real world. Digital elements could then appear within that environment. Those elements might include instructions, arrows, photographs, videos, or 3D models. This differs from a completely immersive virtual reality experience. The employee is not transported into a simulated factory. They remain inside the real factory looking at the real machine. The digital information appears alongside it. Think of a traditional manual as a document stored in another room. Mixed reality turns parts of that manual into signs positioned directly beside the equipment.

HOLOLENS AND HANDS-FREE WORK
One of the practical advantages of HoloLens was the ability to keep the worker's hands available. Physical jobs frequently require both hands. A technician may be holding a tool. An operator may need to stabilize a component. Someone may be wearing protective equipment. Trying to operate a smartphone or balance a laptop while performing that work can interrupt the process. With HoloLens, the headset becomes the display. The employee can continue looking at the equipment while digital information remains visible. This sounds like a relatively small change, but it can significantly alter the workflow for tasks where repeatedly stopping to check documentation creates delays.

TEXT, PHOTOS, VIDEO AND 3D OBJECTS
A Dynamics 365 Guide could combine several forms of instructional content. Text could explain what action the employee should perform. A photograph could show what the correctly completed step should look like. A short video could demonstrate a movement that would be difficult to describe clearly in several paragraphs. A 3D model could help the employee identify the component they need to inspect. The important difference was spatial placement. The content was not simply another video playing somewhere inside the headset. Authors could position digital elements inside the physical workspace. An arrow could appear near a particular panel. A 3D model could appear beside the component it represents. The employee could therefore connect the instruction with the real object more directly.

WHY SPATIAL PLACEMENT MATTERR
Consider the instruction: "Inspect the filter housing." That sentence may be perfectly clear to an experienced technician. A new employee may have no idea which of several similar components is the filter housing. A photograph can help. A 3D model can help further. But mixed reality can go another step by placing the guidance near the actual component. The employee does not need to mentally translate a two-dimensional diagram into the complicated physical machine standing in front of them. That reduction in interpretation is one of the most interesting aspects of mixed reality instructions.

CREATING A DYNAMICS 365 GUIDE
Guides did not automatically understand how a company's equipment worked. Someone needed to create the instructions. The process typically started with a subject matter expert such as an experienced technician, process engineer, or trainer. Using the Dynamics 365 Guides PC application, the author could create a sequence of steps. Each step could contain concise instructions and supporting media. The author could then use HoloLens inside the actual work environment to position relevant digital elements around the equipment. This combined two types of knowledge: Process knowledge — what needs to happen. Spatial knowledge — where it needs to happen. Together, those elements created the mixed reality guide.

GOOD GUIDES REQUIRE GOOD INSTRUCTIONS
Mixed reality does not automatically make bad documentation useful. If an instruction is unclear, putting it inside a headset does not solve the problem. If an arrow points vaguely toward several similar components, the employee still does not know which component matters. If a hologram blocks the worker's view of the equipment, the technology may create another problem. Good Guides therefore required concise wording, careful spatial placement, appropriate media, and genuine understanding of the physical workspace. Instructions needed to reflect how people actually performed the work rather than how someone sitting at a desk imagined the process worked.

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

How many sales opportunities disappear because somebody intended to follow up but lost the email, missed the task, or simply forgot? Modern sales teams rarely suffer from a lack of customer data. They have CRM records, emails, meetings, notes, opportunities, tasks, forecasts, and relationship information. The bigger problem is understanding which information matters right now and what the seller should do next. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Microsoft Dynamics 365 Sales Insights in plain English and explores how Microsoft uses AI, activity signals, relationship data, predictive scoring, conversation intelligence, and forecasting to help sales teams focus their attention. We look at the Sales Insights assistant, Auto Capture, Email Engagement, predictive lead and opportunity scoring, Sales Accelerator, relationship intelligence, Who Knows Whom, Talking Points, Conversation Intelligence, notes analysis, forecasting, Microsoft 365 integration, Microsoft Teams, and LinkedIn Sales Navigator. ㅤ

WHAT IS DYNAMICS 365 SALES INSIGHTS?
Dynamics 365 Sales Insights is a collection of AI-powered and intelligence capabilities designed to make the information inside Dynamics 365 Sales more actionable. Dynamics 365 Sales remains the CRM foundation. It contains accounts, contacts, leads, opportunities, activities, customer information, pipeline records, and sales history. Sales Insights sits on top of this information and looks for useful signals. An important activity might be overdue. A lead might resemble previous leads that successfully converted. Communication with an important account might have declined. An opportunity may show patterns associated with previous successful deals. Instead of expecting sellers to manually search thousands of records for these signals, Sales Insights can bring relevant information closer to their daily work. The objective is not more data. The objective is better guidance from the data the sales organization already has. 

WHY SALES TEAMS NEED INSIGHTS, NOT JUST MORE DATA
Imagine the traditional sales process. A salesperson keeps one spreadsheet containing prospects, searches Outlook for the latest customer email, writes notes after telephone calls, creates calendar reminders, and tries to remember which customer requested pricing last week. Then the sales manager asks: Which opportunities are likely to close this month? The answer can quickly become dependent on memory and intuition. The salesperson is not necessarily doing anything wrong. Sales simply generates enormous amounts of information. Every call creates notes. Every email creates another conversation. Every meeting creates potential follow-up actions. Opportunities move through stages. New people enter buying groups. Customer requirements change. Dynamics 365 Sales gives this information a structured home. Sales Insights attempts to turn that growing information into useful signals.

THE SALES INSIGHTS ASSISTANT
One of the everyday capabilities discussed in the episode is the Sales Insights Assistant. The assistant uses cards inside Dynamics 365 Sales to surface work that may require attention. That could include overdue tasks, upcoming meetings, or suggested next actions. Think of it like an inbox tray sitting on a salesperson's desk. Important items can rise closer to the top without making everything else disappear. Suppose you promised to send pricing information after Tuesday's customer call. Wednesday becomes unexpectedly busy. Two new leads arrive. A meeting runs longer than expected. Another customer calls. The promised pricing email never gets sent. An assistant card can bring that overdue follow-up back into view. That simple reminder can matter because customers rarely contact a salesperson to explain that the salesperson followed up too slowly. They may simply begin talking to somebody else.

ASSISTANT CARDS AND NEXT ACTIONS
Assistant cards should not be confused with automated sales decisions. The system can identify something potentially important. The salesperson still determines whether and how to act. An overdue task may still be relevant. Another task may no longer make sense because the customer situation changed. An upcoming meeting may require preparation. Another customer may suddenly require immediate attention. Sales Insights provides the signal. The salesperson provides the context and judgment. This distinction runs throughout the entire Sales Insights experience. The technology is designed to support the seller rather than replace the seller. 

AUTO CAPTURE
One of the biggest problems with CRM systems is keeping activity information current. Salespeople spend significant amounts of time inside email and meetings rather than filling out CRM forms. If every useful customer interaction needs to be manually copied into Dynamics 365 Sales, information inevitably gets missed. Auto Capture helps identify emails and meetings that appear related to customers already inside Dynamics 365 Sales. Those interactions can then be brought to the salesperson's attention for review. The important point is that finding an interaction does not necessarily mean every email should automatically become a permanent CRM record. Sales information still needs appropriate review. A private message, unrelated conversation, or incorrectly associated email should not become part of a customer history simply because software detected a possible relationship.

PREMIUM AUTO CAPTURE
The episode also discusses additional Auto Capture capabilities. Imagine a customer replies to an email and includes a colleague the salesperson has never previously met. That person may be part of the customer's buying group but does not yet exist inside Dynamics 365 Sales. Premium Auto Capture can help identify this situation and suggest creating a contact. The salesperson can then review the person's name, role, and context before deciding whether they actually belong inside the CRM. This illustrates an important principle: Automation can reduce data entry without eliminating data quality controls. The system helps prepare the work. The seller still confirms whether the information belongs in the customer record.

EMAIL ENGAGEMENT
Email Engagement provides sellers with additional information about tracked sales emails. Depending on the configuration, sellers can see signals such as whether a recipient opened an email or clicked a link. These signals need careful interpretation. An email open does not mean a customer intends to purchase. A customer not opening an email does not automatically mean they have no interest. But engagement information can provide useful context around timing. Imagine sending a proposal Monday morning. The prospect opens the message and clicks through to the pricing information but does not reply. Instead of simply sending exactly the same follow-up several days later, the salesperson now has another signal suggesting that a conversation might be useful. The signal provides context. The salesperson still needs to decide what an appropriate interaction looks like.

PREDICTIVE LEAD SCORING
Salespeople can only make a limited number of calls and conduct a limited number of meetings each day. When hundreds of leads exist inside the CRM, the obvious question becomes: Where should I start? Predictive lead scoring attempts to help answer that question. The system looks at patterns from previous sales information and compares those patterns with current leads. Depending on the organization's data, those patterns might involve lead sources, company information, job roles, activities, or other fields used during the sales process. The underlying question is relatively simple: When leads with similar characteristics appeared previously, how often did they move forward? The resulting score can help sellers prioritize a crowded lead list. ㅤ

PREDICTIVE SCORES ARE SIGNALS, NOT GUARANTEES
Suppose 200 leads arrive after an industry event. Without scoring, the salesperson might work through those leads alphabetically, according to registration time, or simply according to personal instinct. Predictive scoring can provide another method of prioritization. Leads resembling previous successful customers may receive greater attention earlier. That does not mean lower-scoring leads should be ignored. A new market may behave differently from historical customers. A promising prospect might have incomplete information. A new product could attract buyers unlike those in the historical training data. The score should therefore be treated as a priority signal rather than a final sales decision. ㅤ 

PREDICTIVE OPPORTUNITY SCORING
Predictive opportunity scoring applies a similar concept to deals already moving through the sales pipeline. An opportunity can contain information such as estimated revenue, expected closing dates, customer contacts, sales activities, and sales stages. Sales Insights can compare the active opportunity with patterns from previous sales outcomes. The result can provide an indication of how strongly the current opportunity resembles previous successful deals. Sellers can also look at how the score changes. A rising score may correspond with increased engagement or positive progress. A falling score can provide a reason to investigate what changed. Again, the score does not know whether the customer's budget has actually been approved or whether a competitor has suddenly changed the situation. It provides another piece of evidence.

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

Salespeople rarely struggle because they do not have enough tasks. The real challenge is deciding which customer deserves attention next, what action should happen, and what context is needed before reaching out. Emails arrive in Outlook. Meetings fill the calendar. Customer information lives inside CRM records. Leads respond to marketing activities. Colleagues leave notes. Opportunities change. Follow-up reminders compete with urgent customer requests. The result can be a busy sales day that still misses the most important opportunities. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Microsoft Dynamics 365 Sales Accelerator in plain English and explores how its guided selling capabilities help sales teams prioritize leads and opportunities, organize daily activities, create repeatable sales sequences, and keep customer context close to every interaction. We look at Up Next, the Sales Accelerator work list, sequences, predictive scoring, customer engagement, sales insights, Copilot, Microsoft Teams, Outlook integration, and guided selling—and explain where automation helps and where human judgment remains essential.

WHAT IS DYNAMICS 365 SALES ACCELERATOR?
Dynamics 365 Sales Accelerator is a guided selling experience inside Dynamics 365 Sales. It does not replace Dynamics 365 Sales. Dynamics 365 Sales remains the larger CRM environment where organizations maintain accounts, contacts, leads, opportunities, activities, pipeline information, and sales history. Sales Accelerator provides a more focused working experience on top of that information. Think of it as the seller's daily desk. Instead of opening Dynamics 365 and looking through thousands of CRM records, Sales Accelerator helps answer a much more practical question: Who should I work with today, and what should I do next? It brings together leads, opportunities, activities, suggested actions, and customer context so sellers have a clearer starting point for their day.

WHY SALES WORK BECOMES FRAGMENTED
Consider a typical sales morning. You open Outlook and find customer emails, internal conversations, newsletters, meeting invitations, and a response from someone who requested a proposal last week. Your calendar says you have another call in 30 minutes. Your phone shows a missed call. A spreadsheet contains leads that never reached the CRM. Dynamics 365 contains another list of opportunities. Meanwhile, a colleague asks about a customer and your sales manager wants an updated forecast. None of these activities is particularly difficult individually. The difficulty comes from determining what deserves attention first. Traditional approaches rely heavily on personal memory, Outlook flags, calendar reminders, CRM tasks, spreadsheets, and sometimes sticky notes. When the day becomes busy, the next important customer action can disappear inside all that activity. ㅤ

BUSY SALES TEAMS ARE NOT ALWAYS PRODUCTIVE SALES TEAMS
A salesperson can spend an entire morning sending emails, updating CRM records, attending meetings, completing tasks, and still spend too little time with customers who are actually ready to move forward. This is one of the fundamental problems Sales Accelerator tries to address. Imagine two prospects. One has recently replied to an email, visited pricing information, and asked another question. The other has not responded for several weeks. If both appear inside the same unfiltered task list, the salesperson may simply work from top to bottom. That does not necessarily represent the real business priority. Sales Accelerator attempts to bring activity, timing, sales information, and planned actions together so sellers can make better prioritization decisions.

THE THREE CORE PARTS OF SALES ACCELERATOR
The episode focuses on three important components of Dynamics 365 Sales Accelerator: Up Next and the work list help sellers determine which leads and opportunities require attention. Sequences create repeatable follow-up processes around leads and opportunities. Customer context gives sellers the background they need before making the next call or sending the next message. These components work together. The work list identifies a customer requiring attention. The sequence suggests the next planned activity. The CRM record provides the history and context required to perform that activity appropriately. That combination turns Dynamics 365 from a large collection of customer records into a more practical daily selling workspace.

WHAT IS THE SALES ACCELERATOR WORK LIST?
The Sales Accelerator work list provides sellers with a focused collection of leads and opportunities requiring attention. Instead of looking at every record inside the CRM, sellers see active sales work relevant to their day. Each item can point toward an appropriate activity such as making a call, sending an email, or completing another follow-up action. The difference sounds simple, but it can significantly change how sellers begin their working day. Instead of asking: "Where should I start?" the seller has a guided list of potential priorities. The underlying customer information remains available so the seller can review context before taking action.

UP NEXT IN DYNAMICS 365 SALES
Up Next focuses attention on the next activities associated with leads and opportunities. The objective is not simply to produce another task list. Up Next connects the task with the customer record and the surrounding sales information. A task saying "Call Priya" provides very little useful context by itself. But that task becomes considerably more useful when the seller can also see that Priya attended a meeting, responded to a previous email, asked about pricing, or is connected with an active opportunity. The seller can then begin the conversation from the customer's actual situation rather than treating every interaction like a cold first contact. 

PRIORITIZING LEADS AND OPPORTUNITIES
The work list can consider several signals when determining which records deserve attention. The episode discusses areas including predictive scoring, organizational rules, recent customer activity, overdue work, and planned sequence activities. For example, an organization might decide that a new website lead should receive attention within a defined number of hours. An opportunity approaching its expected closing date might require review. A customer response might deserve immediate attention even if the originally scheduled follow-up was planned for later. These signals allow organizations to turn successful sales habits into processes the system can help surface consistently.

PREDICTIVE LEAD SCORING
Predictive scoring helps sellers identify leads that may have a higher probability of progressing based on patterns within available sales information. The important word is signal. A predictive score is not a guarantee. If one lead recently opened an email, followed a link, and scheduled a conversation while another has remained inactive for weeks, the first lead may appear more promising. That does not mean the system knows with certainty who will purchase. It means the available information suggests that one record currently deserves closer attention. Salespeople still need to apply business knowledge and relationship context when determining actual priorities. ㅤ

OVERDUE SALES ACTIVITIES
Sales Accelerator can also keep overdue activities visible. An overdue call should not simply disappear because several newer activities arrived. The salesperson can see that the activity requires attention and determine what to do. Perhaps the call still needs to happen. Perhaps it should be rescheduled. Perhaps the customer situation has changed and the original activity no longer makes sense. The important point is that the salesperson makes an explicit decision rather than relying entirely on memory to remember forgotten follow-ups.

SALES PRIORITIZATION STILL NEEDS HUMAN JUDGMENT
Sales Accelerator does not automatically understand every customer relationship. Imagine the work list identifies one opportunity as the highest priority. At the same time, a strategic customer calls with an urgent problem. The customer problem may obviously deserve immediate attention regardless of what the score says. Similarly, a salesperson may have personally promised a customer that they would call before lunch. The CRM algorithm may not fully understand the importance of that commitment. Sales Accelerator should therefore be viewed as guidance rather than an unquestionable command system. The seller remains responsible for deciding what actually happens next. 

WHAT ARE SALES SEQUENCES?
Knowing who to contact solves only part of the problem. The seller also needs to know what follow-up should happen. This is where sequences become important. A sequence is a planned series of sales activities connected to a lead or opportunity. Think of it as a sales follow-up blueprint. A sequence could contain an introductory email, followed by a telephone call, followed by a waiting period, another follow-up task, and then another email if the customer has not responded. The objective is to create a repeatable sales process without forcing every salesperson to manually recreate the same follow-up plan for every new lead.

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

HR teams manage some of the most important and sensitive information inside an organization. Employee records, organizational structures, leave requests, benefits, compensation information, skills, certifications, training, performance, approvals, and onboarding tasks all need to remain accurate and accessible to the right people. The problem begins when that information is spread across spreadsheets, email conversations, shared folders, HR applications, manager-maintained lists, and disconnected systems. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Microsoft Dynamics 365 Human Resources and how it creates a connected environment for core HR information and everyday people processes. We explore employee records, organizational structures, employee and manager self-service, leave and absence management, benefits, compensation, learning and development, HR workflows, onboarding, automation, reporting, Microsoft Teams, Power BI, and integrations with payroll and other HR systems.

WHAT IS DYNAMICS 365 HUMAN RESOURCES?
Microsoft Dynamics 365 Human Resources is a cloud-based HR solution designed to give organizations a central place for employee information and common HR processes. Think of it as the digital HR floor inside an organization. Employee records live in one controlled environment. Requests can follow predefined approval processes. Managers can access information about their teams. Employees can perform appropriate self-service activities. HR can manage policies and maintain the underlying people information. Instead of employees and managers carrying information between disconnected systems, the organization can create clearer HR processes around a shared employee record. The goal is not necessarily to put every people-related process into one application. Organizations may still use specialized solutions for payroll, recruitment, learning, or other functions. Dynamics 365 Human Resources provides the central people information and HR processes those connected systems can depend on.

THE PROBLEM OF FRAGMENTED HR DATA
Consider what happens when a new employee joins a company. HR enters the employee's information into one system. Their manager adds them to a separate team list. Payroll needs information in another application. Training materials are stored somewhere else. Benefits information arrives through email. Initially, everything may appear to work. But every additional copy of the employee record creates another opportunity for information to become outdated. The employee changes departments. Their manager changes. They move to another address. Their working hours change. They complete another certification. Suddenly, several systems contain different versions of the same person. Dynamics 365 Human Resources addresses this problem by providing a shared employee record around which HR processes can operate.

THE EMPLOYEE RECORD
At the center of Dynamics 365 Human Resources is the employee profile. This is considerably more than a digital contact card containing someone's name, telephone number, and job title. An employee profile can contain job information, contact details, work history, skills, certifications, interests, accomplishments, and training information. This creates a more complete professional record. Two employees may have exactly the same job title while possessing very different skills and experience. One project manager might hold a particular certification. Another may speak several languages. Another may have completed training required for a future role. Keeping this information connected to the employee record gives HR and managers a better foundation for staffing, development, training, and workforce decisions.

ORGANIZATIONAL STRUCTURES
Dynamics 365 Human Resources also helps organizations describe how their workforce is structured. The system can record departments, jobs, positions, managers, and reporting relationships. These concepts have different purposes. A department identifies where work takes place within the organization. A job describes a type of work. A position represents a particular place within the organization that can be filled by an employee. For example, an organization could employ many people with the job "Warehouse Associate," while every employee occupies a particular position connected with a specific department and reporting structure. Connecting these elements allows the organizational structure to become a working part of HR processes rather than a static organizational chart updated occasionally.

SKILLS AND CERTIFICATIONS
Employee skills and certifications are another important part of the employee profile. Imagine a manager asking HR: Who on my team currently holds the certification required for this project? Without structured HR information, answering that question might require searching spreadsheets, old training documents, emails, or individual employee records. Dynamics 365 Human Resources provides a more direct starting point by connecting skills and certifications with employee profiles. Certification dates can also matter. Some professional certifications or mandatory training requirements expire. Keeping those dates connected with employee information helps HR and managers identify when qualifications require attention. This becomes especially valuable in environments where particular jobs or projects require specific certifications.

SECURITY AND ROLE-BASED ACCESS 
HR systems contain sensitive information. That means not everyone should have access to everything. Employees may need access to their own information. Managers may require information about their teams. HR professionals may require broader access for legitimate HR responsibilities. Dynamics 365 Human Resources uses roles and permissions to control who can view or modify different areas. The source describes this like different doors inside a staff-only office. Not everyone receives the master key. Organizations need to determine which employees require access to particular information and configure security, privacy, and compliance controls accordingly. Technology provides the controls, but organizations remain responsible for establishing appropriate policies around employee data. 

EMPLOYEE SELF-SERVICE
A good HR platform should not require employees to email HR every time they need basic information. Employee self-service gives people a clearer way to handle routine HR activities themselves. Depending on the organization's configuration, employees can review their profiles, update permitted information, check leave details, complete assigned tasks, and submit HR requests. Instead of emailing: "How many vacation days do I have left?" the employee can check their available balance. Instead of wondering whether HR received a request, the employee can submit it through a defined process and follow its status. This can reduce repetitive administrative work for HR while giving employees more direct access to appropriate information.

MANAGER SELF-SERVICE
Managers need a different perspective. They need to understand who works within their team, reporting relationships, upcoming absences, employee information relevant to their responsibilities, and requests waiting for approval. Manager self-service gives managers access to appropriate information without requiring HR to manually answer every routine question. This can make common management processes significantly more efficient. The important point is that managers and HR are working from connected people information instead of maintaining separate team spreadsheets that gradually become inconsistent.

LEAVE AND ABSENCE MANAGEMENT
Leave management demonstrates how connected HR processes can improve a routine employee experience. Imagine an employee named Maya requesting three days of annual leave. The system can consider the employee's available balance and the company's configured leave rules. The request is routed to Maya's manager. The manager reviews the dates and approves or declines the request. Maya can see the result. The leave record reflects the decision. HR can review the request history. Instead of the approval existing only as an email saying "approved," the complete process becomes part of a structured HR workflow.

LEAVE POLICIES AND COMPANY RULES
Leave is more complicated than selecting several dates on a calendar. Organizations have policies covering working days, weekends, public holidays, leave categories, balances, eligibility, and other conditions. Dynamics 365 Human Resources can apply configured company rules when processing leave requests. For example, if a public holiday occurs during an employee's requested absence, the system can handle that date according to the organization's configured leave policy. This helps move policy enforcement away from manual interpretation for every routine request.

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