M365.FM - Modern work, security, and productivity with Microsoft 365

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 componen

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 b

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 importa

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

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

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 virt

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 previ

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. Finan

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 do

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 a