M365.FM a Microsoft MVP Podcast by Mirko Peters

Mirko Peters - Founder of m365.fm, m365.show and m365con.net
  • 5.0 (3)
  • Tech News
  • Updated Daily

M365.FM is a podcast about Microsoft 365, Microsoft Copilot, AI, Modern Work, security, governance, Power Platform, Azure, and the technologies shaping the future of work.Hosted by Microsoft MVP Mirko Peters, M365.FM brings together Microsoft MVPs, Microsoft employees, product experts, architects, developers, and community leaders from around the world.Each episode goes beyond announcements and hype to explore what Microsoft technologies mean in practice. From Microsoft 365 Copilot and AI agents to Teams, SharePoint, Power Platform, Microsoft Fabric, Entra, Purview, security, governance, adoption, and automation, M365.FM focuses on real-world experience, implementation, strategy, and lessons learned.Expect expert interviews, technical deep dives, practical explainers, and conversations with people building, implementing, and shaping the Microsoft ecosystem.If you work with Microsoft 365, Copilot, AI, Modern Work, or the Microsoft Cloud, M365.FM helps you understand what matters, what works, and what is coming next.Hosted by Mirko Peters, Microsoft MVP. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

  1. 6h ago

    How Finite Capacity Scheduling Actually Works in Manufacturing

    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.

    How Finite Capacity Scheduling Actually Works in Manufacturing

  2. 17h ago

    Why Your Critical Path Changes When Production Changes

    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 availabilityMaterial availabilityQualified operatorsFixtures and toolingInspection resultsQuality releasesBatch windowsMaintenance schedulesShift calendarsProcess approvalsDownstream capacityPacking and dispatch requirementsThat 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: MachiningHeat treatmentSurface finishingFinal inspectionPackingDispatchPlanning 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 inspectionCertificate verificationQuality approvalDimensional checksLot releaseTraceability verificationMaterial 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 fixtureAn approved CNC programSpecific toolingA qualified machine configurationA certain product revisionA calibrated test systemA qualified operatorTwo 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: SetupFirst-piece inspectionProcess approvalFinal releaseQuality verificationSpecialized machine operationA 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 cyclesFixture changesTool checksProbe verificationCleaningCalibrationSetupProgram approvalMachine 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.

    Why Your Critical Path Changes When Production Changes

  3. Sep 3

    How AI Changed Software Development Forever — Building the Agentic Future with Andre Baltieri [MVP]

    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.

    How AI Changed Software Development Forever — Building the Agentic Future with Andre Baltieri [MVP]

  4. Sep 2

    Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP]

    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.

    Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP]

  5. Sep 1

    Copilot Inherits Your Mess: Modernizing Microsoft 365 for AI with Richard Harbridge [MVP]

    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.

    Copilot Inherits Your Mess: Modernizing Microsoft 365 for AI with Richard Harbridge [MVP]

  6. Aug 30

    Microsoft 365 Copilot: What Actually Makes People More Productive with Adrian Espes [MVP]

    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 Copilot: What Actually Makes People More Productive with Adrian Espes [MVP]

  7. Aug 29

    How Microsoft 365 & Copilot Are Redesigning the Way We Work with Tracy van der Schyff [MVP]

    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.

    How Microsoft 365 & Copilot Are Redesigning the Way We Work with Tracy van der Schyff [MVP]

  8. Aug 28

    Stop Reinventing SPFx- Building Better SharePoint Solutions with PnP React Controls with Siddharth Vaghasia [MVP]

    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.

    Stop Reinventing SPFx- Building Better SharePoint Solutions with PnP React Controls with Siddharth Vaghasia [MVP]
See All (980)

Ratings & Reviews

5
out of 5
3 Ratings

About

M365.FM is a podcast about Microsoft 365, Microsoft Copilot, AI, Modern Work, security, governance, Power Platform, Azure, and the technologies shaping the future of work.Hosted by Microsoft MVP Mirko Peters, M365.FM brings together Microsoft MVPs, Microsoft employees, product experts, architects, developers, and community leaders from around the world.Each episode goes beyond announcements and hype to explore what Microsoft technologies mean in practice. From Microsoft 365 Copilot and AI agents to Teams, SharePoint, Power Platform, Microsoft Fabric, Entra, Purview, security, governance, adoption, and automation, M365.FM focuses on real-world experience, implementation, strategy, and lessons learned.Expect expert interviews, technical deep dives, practical explainers, and conversations with people building, implementing, and shaping the Microsoft ecosystem.If you work with Microsoft 365, Copilot, AI, Modern Work, or the Microsoft Cloud, M365.FM helps you understand what matters, what works, and what is coming next.Hosted by Mirko Peters, Microsoft MVP. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Information

  • Creator
    Mirko Peters - Founder of m365.fm, m365.show and m365con.net
  • Years Active
    2025 - 2026
  • Episodes
    980
  • Rating
    Clean
  • Copyright
    © Copyright Mirko Peters / m365.fm - Part of the m365.show Network - News, tips, and best practices for Microsoft 365 admins
  • Show Website
    M365.FM a Microsoft MVP Podcast by Mirko Peters