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

Mirko Peters - Founder of m365.fm, m365.show and m365con.net

Welcome to the M365.FM — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365.FM brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. M365.FM is part of the M365-Show Network. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

  1. -12 h

    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-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

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

    SharePoint Isn't Boring Anymore: How Copilot Is Reinventing the Modern Workplace with Marcin Siewnicki [MVP]

    For years, SharePoint has carried a reputation for complicated document libraries, outdated intranets, confusing navigation, too many sites, and information that employees simply cannot find. But Microsoft 365 is changing, and Copilot is making SharePoint more important than it has been in a long time.In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP Marcin Siewnicki about how SharePoint is evolving from a traditional document and intranet platform into a central information and knowledge layer for the modern workplace. Marcin has worked with SharePoint since the SharePoint 2003 era, giving him more than two decades of perspective on how the platform has changed. WHY SHAREPOINT GOT A BAD REPUTATION Much of SharePoint’s reputation was created by the way organizations implemented it. Intranets were often designed by IT, heavily customized, difficult to use, and disconnected from what employees actually needed.Instead of continuously gathering feedback and improving the experience, many companies delivered an intranet and expected employees to adapt to it. The result was complex navigation, outdated content, overloaded pages, and systems people avoided whenever possible. INFORMATION ARCHITECTURE BEFORE TECHNOLOGY One of the biggest problems is not SharePoint itself but how information is organized inside it. Without a clear information architecture, SharePoint can quickly become a huge shared folder filled with duplicated files, outdated information, unclear ownership, and multiple versions of the same document.Marcin explains why organizations should start with a simple structure, understand their data, remove unnecessary content, and introduce basic metadata. Information architecture does not have to be complicated to make SharePoint significantly easier to use. BUILDING A MODERN SHAREPOINT WORKPLACE A modern SharePoint homepage should not become an endless collection of web parts, corporate announcements, applications, and links. It should be simple, personalized, visually clear, and focused on what employees actually need.Communication sites can provide departments and organizations with modern, mobile-friendly publishing experiences without requiring the enormous custom intranet projects that were common in the past. The focus should be on useful information, important applications, relevant documents, straightforward navigation, and strong search capabilities. SOLVING THE SHAREPOINT NAVIGATION PROBLEM Navigation remains one of SharePoint’s biggest challenges. Organizations frequently attempt to expose every department, application, resource, and internal page through a single navigation structure.Marcin explains why simpler navigation usually works better. Global navigation should focus on the most important destinations, while detailed navigation can be provided closer to individual departments, sites, and business areas. Otherwise, navigation itself becomes another information problem. SHAREPOINT AND TEAMS SPRAWL Microsoft Teams and SharePoint are deeply connected. Every new Team and many Teams channels can introduce additional SharePoint resources, which means uncontrolled Teams creation can quickly become uncontrolled SharePoint growth.Organizations therefore need simple creation processes, templates, basic metadata, lifecycle management, and user education. Employees should understand when they need a Team, when a SharePoint site is sufficient, and what happens behind the scenes when these collaboration environments are created.One useful way of looking at the relationship is to think of Microsoft Teams as the collaboration interface while SharePoint provides much of the document and information layer underneath it. GOVERNANCE WITHOUT KILLING INNOVATION Governance does not need to mean preventing employees from using new technology. The goal is to provide enough freedom for people to work effectively while maintaining control over information, permissions, external sharing, security, and lifecycle management.Marcin discusses periodically reviewing inactive SharePoint sites and Teams, identifying environments that are no longer needed, checking ownership, reviewing permissions, and archiving or removing obsolete workspaces.Governance also cannot remain exclusively an IT exercise. Business stakeholders and users need to be involved because overly complicated policies often lead employees to find their own workarounds. PERMISSIONS, SHARING AND SECURITY Permissions become increasingly difficult to understand as SharePoint environments grow. Users add colleagues, external partners, vendors, and sharing links over time, but access is rarely reviewed with the same frequency.Regular permission reviews should therefore become part of the governance model. Site and Team owners need responsibility for checking who still requires access and whether external sharing remains necessary.Microsoft Purview sensitivity labels can add another security layer by helping organizations classify and protect information based on its sensitivity. AUTOMATING SHAREPOINT GOVERNANCE Governance does not have to be completely manual. PowerShell, Microsoft Graph, Power Automate, Azure Logic Apps, and specialized third-party platforms can automate many administrative and governance processes.Marcin sees PowerShell and Microsoft Graph as fundamental tools for administrators, while Power Automate can provide practical automation for provisioning, approvals, notifications, lifecycle processes, and many other SharePoint scenarios. MODERN DOCUMENT MANAGEMENT SharePoint is still heavily associated with documents, and documents remain an important part of the platform. The challenge is managing them properly.Metadata, naming conventions, permissions, versioning, storage management, and sensitivity labels all contribute to a healthier information environment. Versioning deserves particular attention because large documents with many retained versions can consume significant amounts of SharePoint storage. METADATA VS. FOLDERS The old SharePoint debate between folders and metadata has not completely disappeared. Marcin argues that metadata remains extremely valuable, but organizations need to keep their metadata models simple.If users need to spend too much time deciding how to classify every document, adoption will suffer. Metadata should support the way employees work rather than creating another administrative task. COPILOT CAN AUTOMATE METADATA Copilot changes this equation because AI can reduce the manual work associated with metadata. SharePoint can analyze documents, extract relevant information, and populate columns based on the content.Organizations still need to decide which metadata is useful, but employees no longer necessarily have to enter everything manually. This can make structured information much more practical at scale. COPILOT CHANGES SHAREPOINT Copilot significantly lowers the amount of SharePoint knowledge employees need before they can start accomplishing useful work.Users can increasingly create content, work with documents, extract information, generate pages, and interact with organizational knowledge using natural language instead of understanding every technical SharePoint concept.Many of the repetitive tasks traditionally associated with maintaining SharePoint environments can therefore become easier. FROM FINDING DOCUMENTS TO GETTING ANSWERS This may be the biggest change of all.Traditional SharePoint experiences required employees to find the right site, navigate to the right library, locate the correct document, open it, and search for the information they needed.Copilot changes that interaction. Instead of only finding documents, employees can increasingly ask questions and receive answers based on information stored across their Microsoft 365 environment.SharePoint therefore starts moving from document storage toward becoming an enterprise knowledge layer. COPILOT CAN UNDERSTAND MORE THAN OFFICE DOCUMENTS Organizational knowledge is not limited to Word documents, Excel files, and PowerPoint presentations.Copilot can work with different types of information, including text, HTML, Markdown, SharePoint lists, and content extracted from video transcripts.That means training videos, recorded meetings, presentations, and other media stored within the Microsoft 365 environment can become part of the knowledge available through AI. WHAT HAPPENED TO SHAREPOINT AGENTS? SharePoint Agents provide dedicated AI experiences grounded in selected SharePoint sites, document libraries, or information sources.Marcin discusses where these agents fit into the current Copilot landscape and why the concept has become less prominent as Copilot itself gains broader capabilities for interacting directly with SharePoint information. IS SHAREPOINT REALLY COPILOT’S KNOWLEDGE LAYER? There is certainly marketing around the idea, but there is also a strong technical reality behind it.Organizations already store enormous amounts of business information in SharePoint and Microsoft Teams. Copilot can use this information, which means the quality of the underlying environment directly affects the quality of the AI experience.Poor permissions, outdated documents, duplicated information, weak metadata, and uncontrolled SharePoint sprawl do not disappear because Copilot has been introduced. They potentially become even more important Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    SharePoint Isn't Boring Anymore: How Copilot Is Reinventing the Modern Workplace with Marcin Siewnicki [MVP]
  3. -2 j

    Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]

    Microsoft Fabric brings data engineering, analytics, business intelligence, governance and increasingly AI together in one platform. But what does an end-to-end Fabric architecture actually look like when you move beyond individual features and start connecting everything?In this episode of the M365 FM Podcast, Mirko Peters is joined by Amit Chandak [Microsoft Data Platform MVP] for a practical journey through Microsoft Fabric — starting with raw organizational data and ending with trusted information that business users can use to make decisions. WHY MICROSOFT FABRIC? Before Fabric, organizations could already build sophisticated analytics architectures using Azure, Power BI and other platforms. The problem wasn't a lack of technology. In many cases, it was the opposite: organizations had too many choices, separate storage technologies, different compute models and multiple copies of essentially the same data.Amit explains how Microsoft Fabric attempts to simplify this architecture by bringing workloads together around shared foundations such as OneLake, common Fabric capacity and the Delta format. Lakehouses, warehouses, Power BI and other Fabric experiences can therefore operate as parts of a broader platform instead of completely isolated services. ONELAKE AS THE FOUNDATION OneLake is one of the central concepts behind Fabric. Amit compares it conceptually to OneDrive: instead of every analytics workload creating completely independent storage environments, OneLake provides a virtualized storage foundation across the Fabric tenant.Organizations can still separate data through workspaces, Lakehouses, Warehouses and domains, but those resources exist within a common Fabric storage architecture. This becomes particularly important when organizations want to reduce unnecessary duplication while maintaining security and organizational boundaries. CENTRALIZED DATA OR DATA MESH? Fabric doesn't automatically mean putting everything into one giant centralized analytics environment.For smaller organizations, a centralized architecture may still work well. As organizations become larger, Amit sees increasing value in domain-oriented architectures where areas such as sales, finance and purchasing can have their own workspaces and responsibilities.IT can remain responsible for availability, governance and the technical foundation while business domains increasingly take ownership of how their data is analyzed and consumed. SHORTCUTS INSTEAD OF COPYING DATA One of the recurring themes throughout the conversation is avoiding unnecessary copies of data.Fabric Shortcuts allow teams to reference data stored elsewhere rather than physically copying it into every environment that needs it. That can apply both inside Fabric and to supported external storage.Amit also explains an interesting architectural benefit of shortcuts: they can help separate workloads across capacities. This can become important when organizations want Power BI consumption workloads isolated from intensive data engineering workloads while still working with the same underlying information. LAKEHOUSE VS. WAREHOUSE One of the biggest Fabric architecture questions remains: Should you use a Lakehouse or a Warehouse?A Lakehouse can work with structured and unstructured data and is naturally aligned with Spark. A Fabric Warehouse focuses on structured data and provides the familiar T-SQL experience.Both ultimately use Delta for structured data inside Fabric, which means the decision increasingly comes down to the type of data, preferred technologies and workloads.Organizations with strong SQL teams don't necessarily need to abandon their existing skills. Teams working with very large datasets, advanced engineering scenarios, unstructured information or extensive data science workloads may find the Lakehouse and Spark approach more attractive. GETTING DATA INTO FABRIC Once the architecture is defined, organizations still need to bring data into Fabric.Amit walks through several approaches, including Shortcuts, Mirroring, Pipelines, Copy Activity, Copy Jobs, Dataflow Gen2 and notebooks.The right option depends heavily on the source and use case. Dataflow Gen2 remains particularly useful because of its broad connector support and familiar Power Query experience. For Power BI professionals entering Fabric, this can provide a natural starting point before moving toward more engineering-oriented approaches. WHEN PYSPARK BECOMES IMPORTANT Power Query and Dataflow Gen2 can work very well for small and medium-sized workloads, but scale changes the equation.For larger transformation workloads, Amit sees significant advantages in Spark-based processing. PySpark and Spark notebooks provide greater flexibility and are designed for distributed processing at scale.SQL and Power BI professionals don't necessarily have to make that transition immediately. Spark SQL can provide a familiar entry point for SQL developers, while many PySpark operations have conceptual similarities to transformations Power Query users already understand. DO YOU REALLY NEED BRONZE, SILVER AND GOLD? The Medallion Architecture has become almost synonymous with modern data engineering: Bronze for raw data, Silver for cleaned and transformed data, and Gold for business-ready information.But Amit argues that organizations shouldn't create layers simply because an architecture diagram says they should.If an organization already has excellent master data management and high-quality source data, every intermediate layer may not provide enough value to justify another copy and another transformation step. Where source data quality is inconsistent, however, the traditional Bronze-Silver-Gold structure remains highly valuable. WHERE SHOULD BUSINESS LOGIC LIVE? Another important architecture decision is determining where calculations and business rules belong.Amit prefers keeping measures and KPIs in the semantic model where possible because they remain dynamic and easier to change. Heavy row-level calculations across millions of records, however, are generally better handled earlier in the Gold layer.The result is not an either-or decision. A mature Fabric architecture distributes business logic deliberately between the transformation layer and semantic model depending on the type and cost of the calculation. SEMANTIC MODELS ARE BECOMING MORE IMPORTANT The semantic model was traditionally viewed primarily as the foundation for Power BI reports. AI is changing that role.Relationships, measures, KPIs and business definitions encoded within a semantic model represent organizational knowledge. That knowledge can increasingly be consumed by experiences beyond traditional dashboards.Amit discusses how Data Agents, ontology-driven solutions and Fabric Apps can build on semantic models. Instead of being merely a Power BI component, the semantic model can become a reusable business layer between organizational data and multiple human or AI-driven experiences. DOES DAX STILL MATTER IN THE AI ERA? AI can already generate DAX, SQL, PySpark and other code remarkably quickly. Does that mean professionals no longer need to learn these languages?Amit argues that expertise still matters, particularly when generated solutions don't work correctly or need optimization. AI can dramatically reduce the amount of syntax professionals need to write manually, but understanding the underlying logic remains valuable for debugging and improving what AI creates.Over time, the skill may shift from remembering syntax toward understanding architecture, algorithms, business logic and how to describe requirements precisely. SECURITY FROM WORKSPACE TO DATA Putting more organizational data into a unified platform makes security increasingly important.The discussion covers security across multiple layers, beginning with Fabric workspace roles and continuing through item-level access, OneLake security and semantic-model security.For larger organizations, Amit recommends using security groups rather than managing individual users wherever possible. Microsoft Entra provides the identity and group foundation, while Fabric applies those identities and groups to workspaces, items and data access. FROM DATA ENGINEERING TO BUSINESS DECISIONS Ultimately, most business users don't care whether their information came through PySpark, a Lakehouse, Delta tables or Dataflow Gen2. They care about getting reliable answers.This is where Amit sees Data Agents, ontology and AI-driven analytics becoming increasingly important.Instead of every user receiving the same predefined dashboard, future analytics experiences could become far more dynamic. Users may interact conversationally with organizational data and eventually have personalized reports or applications generated around their specific questions and responsibilities. RAPID FIRE The episode closes with a rapid-fire round.SQL or PySpark? PySpark.Dataflow Gen2 or Notebook? Notebook.DAX or SQL? DAX.Most underrated Fabric feature? Fabric Apps.Biggest Power BI modeling mistake? Many-to-many relationships.And perhaps the most provocative answer of the episode:Are Fabric Apps the new Power BI?Amit's answer: Yes. THE BIG PICTURE Microsoft Fabric isn't simply another analytics product to add to the Microsoft stack.Its larger opportunity is connecting ingestion, engineering, storage, Lakehouse and Warehouse architectures, semantic models, security, Power BI and emerging AI experiences into one coherent analytics platform.The technical architecture matters, but the endpoint isn't OneLake, PySpark or even Power BI.The endpoint is trusted information that people — and increasingly AI agents — can turn into better business decisions. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]
  4. -4 j

    Beyond Copilot: Building Enterprise AI Agents That Actually Work with Copilot Studio with Manpreet Singh [MVP-MCT]

    Enterprise AI is moving beyond chatbots that simply answer questions. The next generation of AI agents can understand business context, connect to enterprise systems, orchestrate workflows, and take action on behalf of users.But building an impressive AI agent demo is easy. Building an agent that works reliably across a global enterprise—with sensitive data, complex business processes, governance requirements, thousands of users, and measurable outcomes—is a very different challenge.In this episode of the M365 FM Podcast, Mirko Peters talks with Manpreet Singh [MVP/MCT] about what it actually takes to build production-ready enterprise AI agents with Microsoft Copilot Studio and the wider Microsoft AI ecosystem.Manpreet explains how organizations are evolving from individual departmental agents toward multi-agent architectures where specialized agents collaborate behind a single interface. The discussion explores when to use Microsoft 365 Copilot, Copilot Studio, and Azure AI Foundry—and how these technologies can work together rather than becoming isolated AI platforms. FROM ANSWERS TO ACTIONS The real transformation begins when an AI agent can do more than retrieve information.Using practical examples, Manpreet explains how agents can connect with systems such as Workday, Salesforce, SAP, ServiceNow, Jira, Confluence, and PeopleSoft. Instead of navigating several applications manually, employees can interact with an agent through Microsoft Teams or another conversational interface.An employee requesting leave, for example, could have an agent check available leave, consult HR policies, initiate the request in the underlying HR system, ask the manager for approval, and return the final result—all without the employee opening the individual applications. KNOWLEDGE, TOOLS AND TRIGGERS A useful enterprise agent requires more than a good prompt.Manpreet breaks the architecture down into essential elements: knowledge sources that provide organizational context, tools and connectors that allow the agent to interact with enterprise systems, and triggers that determine when processes should begin.SharePoint can become an important knowledge layer, while Power Platform connectors and APIs enable agents to perform actions across business applications. WHY DATA QUALITY MATTERS Connecting an agent to twenty years of SharePoint content is not necessarily a good strategy.Manpreet strongly recommends cleaning and curating organizational knowledge before exposing it to AI. Thousands of outdated PDFs, duplicate documents, missing metadata, and obsolete policies can undermine the quality of agent responses.A smaller, carefully maintained knowledge base with current documents, useful metadata, tags, descriptions, and version management can produce significantly better results than simply indexing everything an organization owns. HUMAN-IN-THE-LOOP AI Autonomous does not have to mean uncontrolled.For low-risk transactions, organizations may allow an agent to complete an action automatically. Higher-value or sensitive decisions can introduce human approval.Manpreet discusses examples including financial claims, invoice processing, access requests, and infrastructure changes where humans remain part of the decision-making process while AI handles much of the repetitive work surrounding the decision. GOVERNANCE BEFORE SCALE As agents gain access to multiple enterprise applications, governance becomes critical.The conversation explores Microsoft Purview, Data Loss Prevention policies, security controls, sensitivity labels, Microsoft Defender, identity, environment strategies, and the importance of establishing an AI Center of Excellence before allowing agent development to expand throughout an organization.Governance should protect enterprise information without creating policies so restrictive that agent performance and usability suffer. CONTROLLING AGENT SPRAWL Organizations can quickly move from a handful of experimental agents to hundreds or thousands.Manpreet discusses agent lifecycle management, parent-child agent relationships, centralized inventories, ownership, connected data sources, permissions, consumption, and emerging management capabilities around Agent 365.The goal is to give administrators visibility into which agents exist, who owns them, what they can access, and how they are being used. THE AI COMMAND CENTER One of the most interesting concepts discussed in the episode is a unified AI Command Center.Instead of agent creation happening without oversight, organizations can establish a central process for requesting agents, connectors, APIs, MCP integrations, environments, and permissions.The command center can combine approval workflows, auditing, monitoring, governance, usage information, and cost controls—creating a central operational layer for enterprise AI. OBSERVABILITY AND TROUBLESHOOTING Traditional applications have logs. Enterprise AI needs observability.When an employee reports that an agent produced an unexpected result, administrators need to understand which knowledge sources were accessed, which tools were called, what actions occurred, and where the process failed.Copilot Studio's tracing and evaluation capabilities can help teams investigate these execution paths and understand how an agent arrived at an outcome. TESTING NON-DETERMINISTIC AI Testing AI agents requires a different mindset from testing traditional applications.Manpreet discusses evaluation features, generated test cases, structured datasets, indexing, user feedback, and repeated validation. Organizations should continuously test their agents against realistic questions and expected outcomes rather than deploying an agent once and assuming it will behave correctly forever. MULTI-AGENT ARCHITECTURES Instead of forcing employees to find the correct agent for every task, organizations can create an orchestration layer.A primary agent can understand the user's intent and delegate work to specialized agents for HR, travel, marketing, sales, IT, or other functions.The user interacts with one interface while multiple specialized agents operate behind it. ADOPTION IS WHERE AI ROI HAPPENS The final challenge is not technical.Organizations can build thousands of sophisticated agents and still fail to generate meaningful business value if employees do not understand when, why, and how to use them.Manpreet argues that adoption, persona-based training, practical use cases, and helping employees integrate agents into their daily work are essential to realizing ROI from Microsoft 365 Copilot and enterprise AI investments. IN THIS EPISODEMicrosoft Copilot Studio and enterprise AI agentsMicrosoft 365 Copilot vs. Copilot Studio vs. Azure AI FoundryAutonomous agents and action-oriented AIEnterprise knowledge groundingSharePoint as an AI knowledge sourceData quality, metadata, and indexingPower Platform connectors and enterprise integrationsHuman-in-the-loop architecturesMulti-agent systems and orchestrationMicrosoft Purview and DLPAI security and governanceAgent lifecycle managementAgent inventories and Agent 365AI Centers of ExcellenceUnified AI Command CentersAI observability and tracingAgent testing and evaluationHallucination reductionAI consumption and cost managementEnterprise AI adoption and ROIKEY TAKEAWAY The next phase of enterprise AI is not simply about adding better chatbots. It is about moving from answers to outcomes.AI agents can connect organizational knowledge, applications, workflows, and business processes—but the fundamentals of enterprise technology remain essential: identity, security, governance, data quality, architecture, testing, observability, cost control, and adoption.And ultimately, the technology only creates value when people actually use it. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Beyond Copilot: Building Enterprise AI Agents That Actually Work with Copilot Studio with Manpreet Singh [MVP-MCT]
  5. -5 j

    From Copilot Rollout to AI Workplace: Adoption, Agents & Real Business Value with Christoffer Besler Hansen [MVP]

    Microsoft 365 Copilot has moved beyond the question of “What can generative AI do?” The harder challenge is now turning AI into something thousands of employees actually use, trust, and derive measurable business value from. In this episode of M365 FM, Mirko Peters talks with Microsoft MVP Christoffer Besler Hansen, Head of AI Workplace at Atea Group, about what it takes to move from a Copilot rollout to a genuine AI-powered workplace. Drawing on experience supporting AI adoption across more than 8,000 employees, Christoffer shares lessons on Microsoft 365 Copilot adoption, training, agents, Copilot Studio, Microsoft Foundry, governance, security, extensibility, FinOps, and measuring business value. WHAT IS AN AI WORKPLACE? An AI workplace is much broader than simply giving employees Microsoft 365 Copilot licenses. At Atea, the AI Workplace team is responsible for how more than 8,000 users incorporate AI into their daily work. Microsoft Copilot is a major component, but the strategy also includes Copilot Studio, agentic AI, Foundry, experimentation with other technologies, and—critically—continuous user adoption. The objective is not to deploy one AI product. It is to change how people work with information, applications, and business processes. TECHNOLOGY MOVES FAST. PEOPLE NEED TIME. New AI models and capabilities can appear every week. Human working habits don't change at the same speed. Christoffer explains why organizations need to spend substantial effort helping employees feel comfortable changing established workflows. At Atea, this includes training throughout the year, sometimes every other week, with sessions designed for different audiences such as managers, consultants, salespeople, beginners, and advanced users. AI adoption therefore isn't a launch event. It is an ongoing organizational capability. BUYING 5,000 COPILOT LICENSES ISN'T A STRATEGY What should happen after an organization purchases thousands of Microsoft 365 Copilot licenses? According to Christoffer, the organization first needs to determine why it purchased them. What is the objective? What should employees accomplish differently? How will the organization support adoption? How will success be measured? Simply assigning licenses and expecting employees to teach themselves isn't enough. Employees already have jobs to perform and cannot realistically follow every weekly change across rapidly evolving AI products. WHY EARLY COPILOT ADOPTION OFTEN DROPS AI naturally generates curiosity. When users initially received Copilot without structured adoption support, Christoffer observed strong engagement for approximately the first four weeks. Employees experimented with the technology. But when they struggled to turn those experiments into new working habits, usage declined. After structured training was introduced, users were more likely to continue using Copilot over time—and began asking for additional training as the products evolved. Initial excitement gets people through the door. Continuous education helps keep them there. HOW DO YOU MEASURE COPILOT ROI? One of the hardest enterprise AI questions is determining whether Copilot is actually creating value. Usage alone isn't enough. An employee opening Copilot 50 times doesn't necessarily mean the organization has become more productive. Christoffer argues that organizations need to identify what matters to their particular business and then measure whether AI improves those outcomes. That could include completing work faster, handling more customer cases, improving quality, or increasing business capacity. MEASURE OUTPUT, NOT JUST AI USAGE One example discussed in the episode involves an employee who previously handled two cases simultaneously but could use AI to work across six while still receiving better customer feedback. That represents something more meaningful than a Copilot usage statistic. The employee is producing more output while maintaining or improving quality. The right KPI therefore depends on what the organization actually produces. AI metrics should ultimately connect with business metrics. COPILOT AS A THINKING PARTNER Meetings were one of the earliest areas where Microsoft 365 Copilot delivered obvious value. Transcription, summaries, and meeting intelligence can reduce administrative effort. But Christoffer highlights another important pattern: using AI as a thinking partner. Instead of asking AI to do all the thinking, start with your own ideas. Speak or dictate those thoughts. Let Copilot structure them. Review the result. Give feedback. Iterate until you have something useful. This approach can save time while simultaneously improving the quality of emails, presentations, documents, and other knowledge work. RESEARCH AGENT CHANGES KNOWLEDGE WORK Christoffer highlights Microsoft's Research Agent as one of the particularly valuable additions to Copilot. For large projects involving significant amounts of information, an agent capable of working through numerous sources can dramatically reduce research effort. It can also help users find information they may previously have struggled to discover manually. Importantly, users can review the underlying sources and verify whether the resulting information is correct. YOUR AI IS ONLY AS GOOD AS YOUR INFORMATION Enterprise AI quickly exposes existing information-management problems. Organizations need to think about how information is structured across SharePoint, OneDrive, CRM systems, and other repositories. Microsoft Purview can play an important role in identifying and protecting confidential information. Retention policies also matter because outdated documents can lead AI toward outdated answers. Simply giving an agent access to more information doesn't automatically make it better. Sometimes the correct approach is to clean the data before connecting the agent. WHEN SHOULD YOU BUILD AN AGENT? ㅤ Christoffer recommends encouraging employees to start thinking about potential agent use cases early. Initially, organizations may create many simple agents that primarily retrieve information. Some will provide little long-term value. But experimentation changes how employees think about automation. The next maturity step is building agents that don't merely answer questions but perform actions—sending messages, updating CRM systems, triggering processes, or interacting with other applications. Eventually, organizations can move toward more autonomous agents working alongside employees. AGENT BUILDER VS COPILOT STUDIO Not every employee needs to begin with Copilot Studio. Christoffer sees many non-technical employees using Agent Builder directly inside Copilot to create simpler agents. More technical users move toward Copilot Studio when they require additional capabilities. This can create a useful progression: Idea → Simple Agent → Validation → Copilot Studio → Advanced Enterprise Agent An employee can prove the concept without becoming a professional developer, then involve technical specialists when the solution needs to become more sophisticated. FROM ANSWERS TO ACTIONS An HR agent answering “How many vacation days do I have?” is useful. An agent that can actually book next Friday as vacation represents a fundamentally different capability. This transition from information retrieval toward actions changes the architecture and security requirements surrounding AI. Christoffer expects users to interact less directly with traditional application interfaces as agents increasingly perform tasks on their behalf. Instead of navigating several administrative screens, users may simply describe the desired outcome to an agent. AGENT SECURITY BECOMES CRITICAL Once agents can take actions, organizations need strong guardrails. What can the agent do automatically? What requires explicit approval? What can it delete? Which systems can it access? What permissions does it receive? Christoffer emphasizes least privilege and approval controls, particularly when agents interact with administrative environments. Giving an autonomous agent Global Administrator privileges and allowing it to operate without restrictions would create obvious risks. The more capable agents become, the more important their permission architecture becomes. ENTERPRISE AGENTS NEED AN INTAKE PROCESS A personal agent used by one employee is different from an agent deployed to thousands of users. Enterprise-wide agents need quality control. Organizations should review instructions, permissions, connectors, integrations, and data access before allowing large numbers of employees to use them. Christoffer suggests establishing an intake process where employee ideas can be evaluated. Some agents may be returned to their creators for improvement. Strategically important ideas can instead be developed by a dedicated internal agent team. COPILOT EXTENSIBILITY AND AGENT 365 The conversation also explores Copilot extensibility and the Agent 365 SDK. Christoffer describes experimenting with personal agents that have their own identities in Microsoft Entra. Such an agent could appear within an organizational structure, have its own email and Teams presence, and receive carefully controlled permissions. His example involves building an agent that can act as a personal assistant and potentially answer appropriate questions when he is away from work. The important architectural shift is that the agent begins looking less like a chatbot and more like another identity participating in the organization. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    From Copilot Rollout to AI Workplace: Adoption, Agents & Real Business Value with Christoffer Besler Hansen [MVP]
  6. -6 j

    Azure Local and Landing Zones: How to Build Hybrid Cloud the Right Way with Christoffer Klarskov Jakobsen [MVP]

    What happens when your cloud strategy cannot live entirely in the public cloud? Organizations are modernizing infrastructure with Azure, platform services, Infrastructure as Code, automated deployment pipelines, and Azure Landing Zones. At the same time, some workloads still need to remain close to factories, offices, regulated environments, existing infrastructure, or latency-sensitive systems. In this episode of M365 FM, Mirko Peters talks with Microsoft MVP Christoffer Klarskov Jakobsen about how Azure Local can become part of a broader Azure architecture rather than another isolated on-premises platform. They explore Azure Local, Azure Landing Zones, Azure Arc, governance, Infrastructure as Code, Bicep, Azure DevOps, modernization, and the realities of building hybrid cloud environments. WHAT IS AZURE LOCAL? Azure Local combines familiar infrastructure technologies with Azure-based management, governance, and security capabilities. At its core, organizations can run workloads such as virtual machines locally while connecting the environment back to Azure. Christoffer explains that the major difference compared with a traditional Windows Server environment is the Azure experience surrounding the infrastructure. Organizations can keep workloads and data locally while using Azure capabilities to manage and govern the environment. IS AZURE LOCAL JUST AZURE IN YOUR DATA CENTER? Not exactly. Azure provides a significantly larger catalog of cloud services, but Azure Local can bring selected Azure experiences closer to local infrastructure. Christoffer discusses running virtual machines and Kubernetes on Azure Local as well as scenarios involving SQL Managed Instance and Azure Virtual Desktop. The result isn't a complete copy of Azure running inside your building. It's a hybrid platform combining local compute requirements with selected Azure services and management capabilities. WHEN DOES AZURE LOCAL MAKE SENSE? Several scenarios stand out. Organizations may have regulatory requirements requiring data to remain locally. Others need extremely low latency between applications, machines, factories, or other infrastructure. Some organizations simply have workloads that cannot yet move completely into the public cloud. Christoffer also sees increasing potential around local AI workloads, including scenarios where organizations need AI capabilities while maintaining local control over their data. AZURE LOCAL IS A LOCAL CLOUD One of the important architectural lessons from the conversation is that Azure Local shouldn't be treated as simply another pair of servers. The environment includes multiple infrastructure and Azure-connected layers. Organizations therefore need people who understand the underlying hardware and operating technologies as well as Azure management. Christoffer describes Azure Local as effectively operating a local cloud rather than simply installing another traditional virtualization cluster. WHY AZURE LANDING ZONES MATTER Moving workloads into Azure doesn't automatically create a well-designed cloud environment. Organizations need structure, security boundaries, governance, permissions, networking, logging, and clear separation between workloads. Azure Landing Zones provide an architectural approach for establishing those foundations. Instead of placing unrelated applications, development environments, production systems, networking components, and shared services inside the same subscription, organizations establish clearer boundaries around workloads and responsibilities. THINK DIFFERENTLY ABOUT AZURE SUBSCRIPTIONS A subscription shouldn't simply become a container for everything an organization deploys. Christoffer recommends thinking about subscriptions as boundaries for specific environments and workloads. A development environment can have its own subscription. Testing can have another. Production can have another. Shared connectivity, logging, identity, and other platform services can be separated appropriately. This makes environments easier to secure, govern, understand, and eventually decommission. MANAGEMENT GROUPS CREATE STRUCTURE Management groups provide another layer for organizing Azure environments. They allow organizations to establish a hierarchy above subscriptions and apply governance at broader scopes. Policies and permissions can then be assigned at the management-group level rather than repeatedly configuring every individual subscription. Christoffer also discusses the local management group, which makes Azure Local increasingly relevant within the same Landing Zone architecture. AZURE POLICY AS THE GUARDRAIL Azure Policy plays a major role in this architecture. Policies can audit environments against organizational or regulatory requirements. They can identify non-compliant resources. They can deploy required configuration when something doesn't already exist. They can also deny configurations that organizations don't want users to create. Examples discussed include controlling Azure regions and preventing insecure storage configurations. Instead of relying entirely on documentation telling employees what they should do, organizations can encode many requirements directly into the platform. DENTITY, RBAC AND ZERO TRUST Landing Zones also provide a foundation for stronger access control. Christoffer emphasizes the principle of least privilege. Users and automated deployment identities should receive only the permissions required to perform their responsibilities. Application owners shouldn't automatically have access to connectivity infrastructure. Support personnel shouldn't automatically be able to modify logging systems. The objective is to establish clear security boundaries instead of making everybody an owner simply because that configuration is easier. AZURE LOCAL MEETS AZURE LANDING ZONES This is where the hybrid architecture becomes particularly interesting. Azure Local previously had limitations around how organizations could structure subscriptions and resources. Christoffer explains that newer capabilities make it possible to use multiple subscriptions and resource groups, enabling Azure Local to align much more closely with Landing Zone design principles. The Azure Local cluster itself can live within one subscription while different workloads use additional subscriptions. That enables organizations to apply clearer boundaries between the control plane and workloads. TIER 0, TIER 1 AND TIER 2 The conversation goes deeper into separating workloads according to security requirements. For example, domain controllers can be treated as Tier 0 resources and placed into a dedicated subscription with particularly strict access controls. Member servers can occupy another tier. End-user workloads such as Azure Virtual Desktop can be separated again. This creates an architecture where local workloads don't simply exist inside one giant infrastructure bucket—they participate in a structured Azure governance model. AZURE ARC CONNECTS THE TWO WORLDS Azure Arc is one of the technologies making the traditional boundary between cloud and on-premises infrastructure increasingly less important. Arc can connect servers running outside Azure with Azure management capabilities. That can include Windows and supported Linux systems running locally, on virtualization platforms, or even with other infrastructure providers. Once connected, organizations can use Azure capabilities including Microsoft Defender for Cloud, Azure Policy, and Azure Update Manager across infrastructure that isn't physically running inside an Azure datacenter. ONE MANAGEMENT PLANE FOR HYBRID INFRASTRUCTURE Traditionally, organizations often accumulated separate products for monitoring, patching, security, configuration, and infrastructure management. Azure Arc changes that model. Instead of treating every location as an entirely separate environment, administrators can increasingly manage distributed infrastructure through Azure. The physical location of the workload still matters for latency, compliance, hardware, and availability—but it doesn't necessarily require an entirely separate management model. INFRASTRUCTURE AS CODE FOR AZURE LOCAL Infrastructure as Code isn't limited to Azure public cloud resources. Christoffer explains that Azure Local infrastructure and workloads can also be deployed using Infrastructure as Code. His principle is straightforward: If you're going to do something more than once, automate it. The initial investment may take additional time, but repeatable deployment becomes particularly valuable for environments requiring ongoing maintenance and consistent configuration. WHY BICEP? Christoffer primarily uses Bicep for Infrastructure as Code. Coming from a PowerShell background, he found the transition into Bicep relatively natural. Visual Studio Code and its supporting extensions also make the development experience easier by identifying syntax issues and helping developers understand available configuration. He doesn't argue that Bicep is universally better than Terraform—rather, Bicep fits naturally into the Microsoft-focused environments and workflows he works with. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Azure Local and Landing Zones: How to Build Hybrid Cloud the Right Way with Christoffer Klarskov Jakobsen [MVP]
  7. -6 j

    Dynamics 365 Business Central AL Development

    Business Central handles finance, customers, sales orders, inventory, and invoices out of the box. But what happens when your company needs one additional field, a custom approval step, a new business rule, or functionality that doesn't exist in the standard application? In this episode of M365 FM, Mirko Peters explains Dynamics 365 Business Central AL Development—how developers use Microsoft's AL language and extensions to customize Business Central without directly modifying the standard application.    WHAT IS BUSINESS CENTRAL AL DEVELOPMENT?  AL stands for Application Language. It is Microsoft's programming language for developing functionality specifically for Dynamics 365 Business Central. AL allows developers to add and change business functionality involving records, pages, reports, calculations, validations, and processes. The important concept isn't only AL itself. It's the extension model. Instead of rewriting Microsoft's standard Business Central application, developers create separate extensions containing their custom functionality. WHY BUSINESSES CUSTOMIZE BUSINESS CENTRAL Business Central already covers many standard business processes. But no two organizations operate exactly the same way. A food distributor might require additional batch information. A service business could require another approval before invoicing. A retailer might need customer reward levels. Another organization could require specific fields, forms, or internal validation rules. These requirements don't necessarily justify changing an entire ERP process. Sometimes the business simply needs Business Central to understand one additional piece of information or enforce one additional rule. WHY EXTENSIONS EXIST Older development approaches frequently involved modifying the original application code. That could work until the underlying application was updated. Microsoft's new code and the organization's modifications then had to be compared and reconciled. Business Central extensions use a different model. The standard application remains in place while custom functionality sits beside it as a separate application. Updates still require testing, but developers don't need to recreate every customization inside Microsoft's original source code. THINK OF BUSINESS CENTRAL AS AN OFFICE BUILDING The episode uses an office-building analogy. Business Central is the building. Instead of knocking holes through the existing structure whenever somebody needs another room, the platform provides approved connection points for extending it. Microsoft maintains the main building. The organization maintains its additional functionality. This separation makes the resulting environment easier to understand and maintain over time. STANDARD FIRST, CUSTOMIZE SECOND Not everything should be customized. Changing Business Central simply because its standard process looks different from an organization's previous ERP can create unnecessary maintenance. Good customization begins with three questions: What problem are employees experiencing? What should happen instead? Can standard Business Central already solve it? AL development becomes relevant when the standard product genuinely doesn't meet the business requirement.  WHAT CAN AL DO? AL can work with Business Central data and application behavior. Developers can use it to add or change records, calculate values, control pages, create reports, validate information, display messages, and automate business rules. But AL isn't intended as a general-purpose language for building every kind of software. You wouldn't normally choose AL for a public shopping website, mobile game, or standalone desktop application. Its focused job is extending Dynamics 365 Business Central. WHAT IS A BUSINESS CENTRAL EXTENSION? An extension is a separate application Business Central can install. It contains the organization's custom functionality while Microsoft's standard Business Central application remains separate. An extension can be extremely small. It might add one additional field to the customer record. Another extension could contain an entire industry-specific solution with its own data, processes, pages, reports, and business rules. Both follow the same fundamental extension architecture. AL VS THE OLDER C/AL MODEL The episode also discusses C/AL, associated with older Dynamics NAV development. In that development model, developers frequently modified original application objects directly. Many organizations successfully operated systems this way, but customizations became closely tied to the standard application. AL moved Business Central toward an app-based extension model, separating custom functionality from Microsoft's standard application. MULTIPLE EXTENSIONS Business Central can contain more than one extension. An organization might have an extension from a software partner handling payroll, another extension providing shipping functionality, and an internally developed extension implementing company-specific rules. Business Central brings those applications together as long as they follow the platform's rules and don't conflict. This modular approach allows organizations to assemble the functionality their particular business requires. THE MAIN AL BUILDING BLOCKS Inside an AL extension, developers work with objects. An object is a named piece of the application responsible for a particular job. The episode introduces several important AL object types: Tables → Store information Pages → Present information to users Table Extensions → Add information to existing tables Page Extensions → Add functionality to existing pages Codeunits → Contain reusable business logic Reports → Present information in documents or layouts Queries → Retrieve focused information XMLports → Exchange structured information TABLES Tables store information in Business Central. Think of a table as a digital filing cabinet. A customer table contains customer records. An item table contains products. Sales-related tables contain information associated with sales transactions. If an organization needs information that doesn't belong in an existing standard table, an extension can create its own table. Examples from the episode include reward levels, equipment inspections, and project approvals. FIELDS Fields are the individual pieces of information stored inside records. A customer can have a name, address, payment term, telephone number, and other details. Custom fields could contain information such as a reward ID, delivery instruction, internal risk score, membership level, or link to another system. Fields can contain different types of information including text, dates, amounts, yes/no values, and predefined choices. PAGES Pages are the screens users interact with inside Business Central. A customer card is a page. A list of sales orders is another page. Different page types support different activities. A Card Page focuses on one record. A List Page displays multiple records. A Worksheet Page supports scenarios where employees need to enter or process several lines of information together. Tables store the information while pages determine how employees interact with it. TABLE EXTENSIONS Suppose Business Central's standard customer table already contains almost everything the organization requires, but the business needs one additional Reward ID. Creating another customer table would unnecessarily duplicate the existing customer information. Instead, a developer creates a Table Extension. The standard customer table remains intact while the extension adds the additional company-specific field. PAGE EXTENSIONS Adding a field to the underlying table doesn't automatically display it to employees. A Page Extension adds the field to an existing Business Central page. The Reward ID could therefore appear directly on the standard Customer Card. Page Extensions can also add groups, actions, buttons, or menu commands. Employees continue working on the familiar Business Central page while the extension adds the functionality required by the organization. CODEUNITS Codeunits provide a home for business logic. Suppose the selected customer reward level determines the discount percentage. Instead of putting the discount calculation directly into the Customer Card page, the calculation can live inside a Codeunit. Other pages, reports, and business processes can then call the same procedure. This avoids maintaining several different versions of the same business rule. ㅤ TRIGGERS ㅤ A trigger is a defined location inside an AL object where code can execute when something happens. For example, code can run when a field value changes or when a page opens or closes. Suppose somebody selects a Reward ID for a customer. A validation trigger could check whether the reward level exists, whether the customer is blocked, or whether another value should be updated. The rule executes when the relevant action occurs. EVENTS Events allow extensions to react to processes occurring inside Business Central without copying those complete processes. Think of an event as a notification from the standard application. Business Central might announce that a record is about to be inserted, a document is about to be posted, or another process has completed. An extension can listen for the event and execute its own functionality at the appropriate point.tes Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Dynamics 365 Business Central AL Development
  8. -6 j

    Dynamics 365 Dual-write - Simply Explained

    A salesperson updates a customer address in Dynamics 365 Sales. Later, someone in finance opens the same customer and still sees the old address. Which one is correct? When sales, service, finance, and operations work in different applications, shared business data can quickly become duplicated or inconsistent. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Dual-write connects Finance and Operations apps with Microsoft Dataverse so supported records such as customers, addresses, contacts, products, and orders can remain synchronized as teams work. WHAT IS DYNAMICS 365 DUAL-WRITE? Dual-write is Microsoft's built-in connection between Dynamics 365 Finance and Operations apps and Microsoft Dataverse. Think of an organization as having a front office and a back office. The front office includes salespeople, service agents, field workers, and other customer-facing teams. The back office handles finance, inventory, purchasing, orders, fulfillment, and other operational processes. Both sides work with many of the same customers and products, but they need different applications for their jobs. Dual-write creates a controlled connection between those environments so selected shared records can remain synchronized without employees manually copying information between applications. THE BUSINESS PROBLEM DUAL-WRITE SOLVES Without integration, one customer can quietly become two different records. Sales might have Northwind Bikes with the customer's new address. Finance might have Northwind Bicycle Company with the previous address. Both records can look correct when viewed independently, but they no longer describe exactly the same business relationship. Employees then become the integration layer. They export spreadsheets, send emails, compare records, re-enter information, and investigate which version is correct. Dual-write is designed to reduce that manual handoff. FRONT OFFICE AND BACK OFFICE Dynamics 365 applications support different types of work. Dynamics 365 Sales focuses on leads, opportunities, customer relationships, and sales conversations. Customer Service manages customer questions and cases. Field Service supports technicians and work performed at customer locations. Finance and Supply Chain Management handle areas such as accounting, inventory, products, purchasing, orders, and fulfillment. The objective isn't to force every employee into one giant application. Instead, employees continue using the application appropriate for their role while selected business information remains connected behind the scenes. MICROSOFT DATAVERSE Dataverse is the shared data foundation behind many Microsoft business applications. Dynamics 365 Sales, Customer Service, Field Service, parts of Project Operations, Power Apps, and Power Automate can work with Dataverse. For understanding Dual-write, think of Dataverse as the common data area on the customer-application side. Finance and Operations remains the operational foundation on the other side. Dual-write connects selected records between these environments. THINK OF DUAL-WRITE AS AN INTERNAL DOOR Imagine an office building with customer-facing teams on one side and finance and operations on the other. Without integration, somebody has to carry information between them. They might send an email, move a spreadsheet, or manually enter the information again. Dual-write acts like a staffed internal door. When a supported record changes on one side, Dual-write can pass the related change through that door according to predefined rules. Each team keeps its own workspace while shared information remains connected. WHAT ARE TABLE MAPS? Dual-write doesn't blindly synchronize every piece of information. It works through defined connections called table maps. A table stores a particular type of record. A customer table contains customer records. A product table contains products. An address table contains address information. A table map tells Dual-write which table in Finance and Operations corresponds with which table in Dataverse. It also defines how relevant fields relate to each other. Think of the table map as the translation sheet between the two systems. TWO-WAY SYNCHRONIZATION The word dual reflects the ability of supported maps to synchronize changes in both directions. A supported update in Dataverse can update the corresponding record in Finance and Operations. A supported update in Finance and Operations can also update the related Dataverse record. However, this doesn't mean every table or every field should automatically move in both directions. Organizations still need clear rules about which system owns particular information. NEAR REAL-TIME DATA Dual-write is designed for business information employees need while they're actively working. Instead of waiting for an overnight synchronization job, supported changes can move between the environments in near real time. Near real time doesn't mean absolutely zero delay. It means the connection supports live operational processes rather than relying primarily on scheduled file exchanges. A salesperson shouldn't need to wait until tomorrow morning before finance sees an important customer update. WHAT DATA CAN DUAL-WRITE CONNECT? Common examples include customers, addresses, contacts, products, vendors, company information, organizational structures, and finance or tax reference information. The exact records depend on the Dynamics 365 applications and business processes an organization uses. The important principle is not to synchronize everything possible. Synchronize information that genuinely needs to represent the same business record across both environments. ㅤ  CUSTOMER RECORDS  Customers are one of the clearest examples. Sales needs information such as customer names, contacts, phone numbers, and delivery information. Finance needs the legal customer record, billing information, and the details required for orders and invoices. Dual-write can keep supported customer information connected while allowing each team to continue working inside the Dynamics 365 application designed for its responsibilities. ADDRESSES AND CONTACTS Customer information is more complicated than one company name. A customer can have a billing address, shipping address, and service location. The organization might also work with buyers, Accounts Payable contacts, service managers, and other people within the same customer organization. Connected address and contact structures help sales, service, finance, and operations work with related information without independently rebuilding those relationships in every application. PRODUCT INFORMATION Products provide an example where ownership frequently becomes important. Finance and Operations often owns product creation because operations controls product master information, stock units, and other details required to sell and deliver products. Once the product is prepared for customer-facing work, Dual-write can send related product information into Dataverse. Sales users can then work with those products without somebody manually recreating the product catalog in another application. ONE-WAY VS TWO-WAY MAPS Not every business record needs two-way synchronization. Some maps support changes in both directions because both sides have a legitimate reason to maintain information. Other records have a clearer owner. Products provide a useful example: operations might create and govern the product while sales simply receives and uses that information. The correct synchronization direction should follow the organization's actual data ownership model. DATA OWNERSHIP MATTERS Before synchronizing information, organizations need to answer: Where does this record begin? Who can change it? Which system wins when information conflicts? Who corrects an incorrect value? For example, sales might own relationship and contact information while finance owns payment-related information and operations owns products and inventory. The exact ownership model depends on the business. What matters is that the ownership is clearly defined before automation begins moving changes between applications. HOW A CHANGE TRAVELS Imagine a salesperson speaking with a customer who recently moved. The salesperson updates the customer's street address in Dynamics 365 Sales and saves the record. Sales stores that change in Dataverse. Dual-write checks the relevant table map and identifies the corresponding customer and address information in Finance and Operations. The supported update travels across automatically. When finance later opens the customer record, the updated address is available without somebody manually entering it again. SYNCHRONOUS BUSINESS PROCESSES For normal day-to-day operations, the connection is designed to process related updates as part of the current working process instead of placing everything into a background synchronization job that might execute much later. This matters because employees make decisions based on what they see now. Customer addresses, product details, and other shared information shouldn't quietly drift apart for hours before somebody discovers the difference. When synchronization fails, that failure needs attention rather than remaining hidden until another team discovers inconsistent data. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Dynamics 365 Dual-write - Simply Explained

Notes et avis

5
sur 5
3 notes

À propos

Welcome to the M365.FM — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365.FM brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. M365.FM is part of the M365-Show Network. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

Vous aimeriez peut‑être aussi