M365 FM Podcast

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.

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

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

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

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

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

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

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

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

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

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

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

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

IN THIS EPISODE

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

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

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.